🚨Alpha-Alarm 🚨 @tempo ist vor ein paar Minuten live gegangen. Mit dem Start des Mainnets wird auch die Spezifikation des Machine Payments Protocol (MPP) veröffentlicht. Ich habe frühzeitigen Zugang zur Spezifikation erhalten und habe einige erste Gedanken dazu. Zunächst einmal ist die MPP-Spezifikation ein neuer, alternativer Ansatz für den HTTP-Code 402 "Zahlungsanforderung". Sie unterscheidet sich grundlegend von x402, da sie den Facilitator aus der Architektur entfernt. Einerseits ist es normalerweise eine gute Idee, einen Vermittler aus dem Ablauf zu entfernen. Andererseits verlagert es die Verarbeitungslogik, die vom Facilitator gehandhabt wird, auf den Server des Händlers. Die Zeit wird zeigen, ob das gut oder schlecht ist, aber ich vermute, dass man glaubt, dass der serverseitige Agent in der Lage sein wird, die Händlerflüsse zu optimieren, sodass es überflüssig ist, einen Dritten damit zu beauftragen. Jetzt müssen wir abwarten und sehen… Die MPP-Spezifikation sieht auch verschiedene Zahlungsmethoden über Stablecoins hinaus vor, einschließlich Unterstützung für Fiat-Zahlungen über Kreditkarten, was ich als Gewinn betrachte. Hinzu kommt ein PSP-agnostischer Ansatz, was ich als doppelten Gewinn ansehe. Händler sollten in der Lage sein, die Zahlungsmethode ihrer Wahl zu wählen, die von dem Zahlungsdienstleister ihrer Wahl verarbeitet wird. Jetzt zu den Fragen, die ich habe. Erstens hat die Spezifikation für Kartenzahlungen eine neuartige Verschlüsselungsmethode, bei der der Server (d.h. der Händler) die Entschlüsselung der Nutzlast des Clients kontrolliert. Leider wirft dies Fragen zur PCI-Konformität auf. Der Server kontrolliert nicht, wie der Client (der kaufende Agent) mit seiner Kartendelegation umgeht. Der vorgeschriebene Weg scheint DPANs zu sein, aber auch rohe PANs sind laut Spezifikation im Geltungsbereich. Da der Server die CHD-Nutzlast nicht kontrolliert, können rohe PANs verschlüsselt und an den Server gesendet werden, um an den PSP des Servers weitergeleitet zu werden. Dies würde wiederum erfordern, dass der Server PCI-konform ist, es sei denn, er kann garantieren, dass die Nutzlast immer nur ein DPAN ist. Es ist nicht skalierbar, von jedem Server zu verlangen, PCI SAQ A oder, schlimmer noch, SAQ D-konform zu sein. Zweitens ermöglicht die Spezifikation mehrere Zahlungsmethoden, löst jedoch Transaktionen nicht global. Auch wenn das normal erscheinen mag, ist es meiner Meinung nach der optimale Ansatz, ein globales Hauptbuch zu haben, in das alle Agenten einsteigen können, damit Zahlungen von Agent zu Agent skalieren können. Warum fragen Sie? Aus mehreren Gründen, aber ein spezifischer Grund ist die Identitätsfeststellung. Die Identität des Agenten wird teilweise an statistische Modelle gebunden, die auf der Transaktionshistorie basieren. Ein zeitgenössisches Beispiel dafür ist die Kreditrisikoprofilierung. Allerdings werden compartmentalisierte Transaktionsnetzwerke zu unterschiedlichen Transaktionshistorien führen, was Probleme verursachen wird, wenn es darum geht, Verhalten zu klären. Herzlichen Glückwunsch an alle Beteiligten, einschließlich unserer Partner bei Visa und VGS. Der Bereich macht massive Fortschritte. Die Dinge beginnen zusammenzukommen, und wir freuen uns darauf, die Teile an ihren Platz zu bringen.