🚨Alertă 🚨 alfa @tempo fost lansat acum câteva minute. Odată cu lansarea mainnet-ului, lansează și specificația Machine Payments Protocol. Am primit acces anticipat la specificație și am câteva gânduri inițiale. În primul rând, specificația MPP este o abordare nouă, alternativă, a codului http 402 "request for payment". Se diferențiază fundamental de x402 prin faptul că elimină Facilitatorul din arhitectură. Pe de o parte, îndepărtarea unui intermediar din flux este de obicei o idee bună. Pe de altă parte, mută logica de procesare gestionată de Facilitator către serverul comerciantului. Timpul va arăta dacă acest lucru este bun sau rău, dar bănuiala mea este că există credința că agentul de pe partea serverului va putea optimiza fluxurile comercianților, așa că să ai o terță parte care să facă asta este redundant. Acum trebuie să așteptăm și să vedem... Specificația MPP prevede, de asemenea, metode de plată diferite dincolo de stables, inclusiv suport pentru fiat prin plată cu cardul de credit, ceea ce cred că este un avantaj. La asta se adaugă o abordare independentă de PSP, ceea ce cred că este un dublu câștig. Comercianții ar trebui să poată alege orice metodă de plată doresc, procesată de furnizorul de servicii de plată pe care îl doresc. Acum să trecem la întrebările mele. În primul rând, pentru plățile cu card, specificația are o metodă nouă de criptare în care serverul (adică comerciantul) controlează decriptarea payload-ului clientului. Din păcate, acest lucru ridică întrebări despre conformitatea PCI. Serverul nu controlează modul în care Clientul (agentul de cumpărare) își gestionează delegarea cardurilor. Calea prescrisă pare să fie DPAN-uri, dar PAN-urile brute sunt și ele în sfera de aplicare în funcție de specificație. Deoarece serverul nu controlează încărcătura utilă CHD, PAN-urile brute pot fi criptate și trimise către server pentru redirecționare către PSP-ul serverului. Acest lucru, la rândul său, ar necesita ca serverul să fie conform PCI, cu excepția cazului în care poate garanta că sarcina utilă este întotdeauna doar un DPAN. A cere ca fiecare server să fie PCI SAQ A sau, și mai rău, conform SAQ D nu este scalabil. În al doilea rând, specificația permite mai multe metode de plată, dar nu rezolvă tranzacțiile la nivel global. Deși acest lucru poate părea normal, pentru ca plățile agent-la-agent să se scaleze, după părerea mea, a avea un registru global la care toți agenții se pot conecta este abordarea optimă. De ce, întrebi? Din mai multe motive, dar unul specific este stabilirea identității. Identitatea agentului va fi legată de modelarea statistică bazată, parțial, pe istoricul tranzacțional. Exemplul contemporan este profilarea riscului de credit. Totuși, rețelele de tranzacții compartimentate vor duce la un istoric disparat al tranzacțiilor, ceea ce va cauza probleme la încercarea de a rezolva comportamentul. Felicitări tuturor celor implicați, inclusiv partenerilor noștri de la Visa și VGS. Spațiul face progrese uriașe. Lucrurile încep să se lege și așteptăm cu nerăbdare să punem piesele la locul lor.