Je to január 1997. na (Internet Engineering Task Force) práve uvoľnil Oficiálne definované Špecifikáciu vytvorili weboví priekopníci , , , , , , , a Architekti, ktorí formovali spôsob komunikácie internetu. IETF Názov RFC 2068 HTTP/1.1 Režisér Roy Fielding Jim Gettys Jeffrey Mogulová HENRIK FRYSTYK Tým Berners-Lee IETF Názov RFC 2068 Režisér Roy Fielding Jim Gettys Jeffrey Mogulová HENRIK FRYSTYK Tým Berners-Lee Špecifikácia zavádza : predtým, každá jediná požiadavka HTTP vyžadovala nové pripojenie TCP. Perzistentné pripojenia to vyriešia, čo umožňuje viacerým požiadavkám HTTP prúdiť cez jediné, dlhotrvajúce pripojenie TCP. persistent connections Existuje tiež Nie je už potrebné, aby server vypočítal celkovú veľkosť dynamicky generovaného obsahu vopred, je teraz zadarmo dodávať dáta postupne, ako sa produkuje. chunked transfer encoding ale Nový stavový kód: RFC 2068 quietly introduces something intriguing HTTP 402 Payment Required This code is reserved for future use. To ukazuje, ako zakladatelia World Wide Web predpovedali, ako sa peniaze nakoniec stanú veľkou časťou internetu. . even if they had no clear path on how it would actually play out Dnes, v roku 2025, takmer tri desaťročia a viacero verzií HTTP neskôr ( V roku 2015, v roku 2022, Napriek fintech revolúcii, vzostupu online platieb a celej ekonomike založenej na internetových transakciách, nikto nevie, čo s tým má robiť. HTTP/2 HTTP/3 Status Code 402 still sits there with the exact same note: 'reserved for future use.' Until now. Posledný mesiac (máj 2025), oslobodený Open Source protokol, ktorý umožňuje jeho prvá skutočná práca: umožnenie domorodca platby v rámci HTTP požiadaviek. Coinbase → x402 HTTP 402 onchain V dnešnej dobe musia zamestnanci vytvoriť (stroj-na-stroj) platby cez web so zníženou (človek v kruhu) zásahy, ale tradičné platobné toky nefungujú dobre v tomto prípade. vyžadujú viaceré ľudské interakcie, presmerovania a manuálne kroky, ktoré jednoducho nefungujú, keď agent AI potrebuje vykonať transakciu autonómne. M2M HITL navrhuje automatizovaný platobný tok v reťazci implementovaný natívne v rámci protokolu HTTP, . x402 making them as seamless as any other web request Ako to však vyzerá v praxi? Architektúra a komponenty x402 x402 → Skladá sa zo štyroch základných komponentov: x402 → a Pôsobí ako iniciátor platieb, objavuje to, čo je potrebné na prístup a konštrukciu príslušnej platobnej záťaže. Jednoducho povedané, to je to, čo robí požiadavku HTTP na zdroj s platobnou stenou. Mohlo by to byť prehliadač, ktorý robí žiadosť o prémiový obsah, AI agent kupujúci API prístup, alebo mobilná aplikácia odomknutie funkcie. Klient spracováva kryptografické podpísanie pomocou užívateľského súkromného kľúča a automaticky obnovuje žiadosti, keď sa vyžaduje platba. client na presadzuje platobné politiky pre svoje koncové body, pričom zostáva zameraný na svoju základnú obchodnú logiku. Toto je webový server alebo API, ktorý hosťuje zakúpený obsah alebo službu. Udržuje jednoduché cenové tabuľky, ktoré mapujú koncové body na náklady, ale deleguje logiku overenia platieb na facilitátora. resource server Blockchain logika je implementovaná v komponent: overovanie kryptografických podpisov, prevencia replay útokov prostredníctvom nonce sledovania a riadenie skutočného vyrovnania na reťazci.Umožňuje klientom aj serverom pracovať s platbami na reťazci bez pochopenia podrobností implementácie blockchain. facilitator je spočíva v konečnej vrstve vyrovnania, ktorá zaisťuje, že platby sú nemenné a transparentné. umožňuje programovateľné peniaze prostredníctvom inteligentných zmlúv a stabilných mincí, . blockchain but its complexity is completely hidden from the application layer by the facilitator : Client Primárna zodpovednosť: iniciácia platby Kľúčové vlastnosti:EIP-712 podpisovanie, automatické retries, platobné objavovanie Čo robí: Robí požiadavky, zaobchádza s peňaženkami, retries s platbou : Resource Server Primárna zodpovednosť: vykonávanie platieb Kľúčové funkcie: Cenové tabuľky, HTTP 402 odpovede, integrácia middleware Čo robí: nastavuje ceny, kontroluje platby, poskytuje obsah : Facilitator Hlavná zodpovednosť: overenie platby Kľúčové vlastnosti: overovanie podpisov, sledovanie nonce, abstrakcia plynov Čo robí: Overuje podpisy, rozpráva s blockchainom : Blockchain Primárna zodpovednosť: Vyrovnanie platieb Kľúčové vlastnosti:USDC prevody, inteligentné zmluvy, nemenné záznamy Čo robí: Vyrovnáva platby v reťazci Princípy Táto architektúra demonštruje niekoľko základných princípov softvérového inžinierstva. Každá zložka má jednu, dobre definovanú zodpovednosť. . separation of concerns Resource servers focus purely on business logic, facilitators handle payment complexity, and clients manage user interaction Systém dosahuje komponenty interagujú iba prostredníctvom štandardizovaných rozhraní HTTP a REST. Táto izolácia znamená, že môžete vymieňať komponenty (napríklad použiť inú blockchain, zmeniť poskytovateľov facilitátorov alebo zmeniť logiku servera) bez toho, aby ste ovplyvnili zvyšok systému. loose coupling A resource server doesn't need to understand how blockchain transactions work, and a client doesn't need to know the server's internal implementation Prevádzkovateľ uľahčuje To zabraňuje úniku platobnej logiky do obchodných aplikácií a udržuje obavy správne oddelené. single responsibility principle V neposlednom rade táto architektúra Komponenty na vysokej úrovni závisia od abstrakcií namiesto konkrétnych implementácií.Servery a klienty závisia od HTTP rozhraní, nie od špecifických blockchain API.To umožňuje, aby rovnaký aplikačný kód pracoval cez rôzne blockchains a platobné schémy bez zmeny. dependency inversion Platobný tok Keď agent alebo používateľ narazí na -enabled API, tu je tok štyroch krokov, ktorý sa deje: x402 Počiatočná požiadavka: Klient urobí štandardnú požiadavku HTTP na prístup k niektorým zdrojom Ak nie je pripojená žiadna platba, server reaguje HTTP 402 a obsahuje podrobnosti o platbe Autorizácia platieb: Klient vytvorí kryptograficky podpísanú platbu a žiadosť obnoví Overenie a prístup: Server overuje platbu, vysiela ju do blockchainu a udeľuje prístup To, čo to robí mocným, je to, že sa to všetko deje na úrovni protokolu HTTP. Žiadne presmerovania na tretie strany platobných procesorov, nie toky, žiadne vytvorenie účtu. OAuth Just standard HTTP with extra headers: X-PAYMENT prúdi od klienta k serveru a obsahuje podpísaný platobný náklad. To zahŕňa platobné údaje (výška, príjemca, token) plus kryptografický podpis preukazujúci, že klient autorizoval platbu. X-PAYMENT-RESPONSE prúdi zo servera na klienta po úspešnej platbe a obsahuje informácie o transakčnom príjme, ktoré poskytujú transparentnosť o tom, čo sa stalo v reťazci. → Implementácia serverovej strany Platobná architektúra Middleware Základná implementácia na strane servera sa točí okolo platobného filtra (AKA middleware), ktorý zachytáva požiadavky HTTP a presadzuje požiadavky na platbu.Keď je integrovaný do vášho webového servera, tento middleware kontroluje prichádzajúce požiadavky proti cenovej tabuľke, ktorá mapuje koncové body na ich náklady. Medziprodukt sa riadi jednoduchým rozhodovacím stromom: ak požiadavka zasiahne chránený koncový bod bez platby, reaguje a podrobné platobné pokyny. Ak je platba zahrnutá v header, overí platbu s facilitátorskou službou predtým, ako umožní žiadosť pokračovať. HTTP 402 X-PAYMENT Tu je základná štruktúra z implementácie Java: public class PaymentFilter implements Filter { private final String payTo; private final Map<String, BigInteger> priceTable; // path → amount private final FacilitatorClient facilitator; public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { String path = req.getRequestURI(); String paymentHeader = req.getHeader("X-PAYMENT"); if (!priceTable.containsKey(path)) { chain.doFilter(request, response); // Free endpoint return; } if (paymentHeader == null) { send402Response(resp, path); // Request payment return; } // Verify payment, process request, then settle VerificationResponse verification = facilitator.verify(paymentHeader, requirements); if (verification.valid) { chain.doFilter(request, response); facilitator.settle(paymentHeader, requirements); } } } Jednoducho pridáte platobný filter do zásobníka stredného tovaru a definujete, ktoré koncové body vyžadujú platbu. The beauty of this approach is that it requires minimal changes to existing applications. odpoveď PaymentRequirements When a client hits a protected endpoint without payment, the server constructs a detailed payment requirements object. This includes the payment amount, accepted tokens (like ), adresu prijímajúcej peňaženky, sieť blockchain a čas vypršania platnosti na zabránenie opätovným útokom. USDC private void send402Response(HttpServletResponse response, String path) throws IOException { response.setStatus(HttpStatus.PAYMENT_REQUIRED); response.setContentType("application/json"); PaymentRequirements requirements = PaymentRequirements.builder() .paymentRequirement(List.of( PaymentRequirement.builder() .kind(new Kind("exact", "base-sepolia")) // Payment scheme + blockchain network .receiver(payTo) // Wallet address to receive payment .amount(priceTable.get(path)) // Cost for this specific endpoint .asset("<USDC_TOKEN_CONTRACT>") // USDC token contract .expiry(Instant.now().plus(Duration.ofMinutes(5))) // Payment window .nonce(UUID.randomUUID().toString()) // One-time use identifier .build() )) .build(); response.getWriter().write(Json.MAPPER.writeValueAsString(requirements)); } Každé pole v je opísaný nasledovne: PaymentRequirements typ: Definuje platobnú schému (presné pre pevné sumy) a cieľovú sieť blockchain (base-sepolia pre Base testnet). príjemca: Adresa peňaženky, kde má byť platba odoslaná. Toto je vaša obchodná peňaženka, ktorá dostane finančné prostriedky. množstvo: Náklady na prístup k tomuto konkrétnemu koncovému bodu, získané z vašej cenovej tabuľky. Pre USDC je to zvyčajne vyjadrené v wei (najmenšia jednotka). : The smart contract address of the token to be used for payment. The example shows USDC on Base Sepolia testnet. asset Vypršanie platnosti: Časový štítok, po ktorom sa táto požiadavka na platbu stáva neplatnou.Tým sa zabráni opätovnému použitiu starých požiadaviek na platbu a pridáva sa zabezpečenie proti replay útokom. nonce: Jedinečný identifikátor (UUID), ktorý zabezpečuje každú platobnú požiadavku, môže byť splnený iba raz, aj keď rovnaký klient urobí viacero požiadaviek na ten istý koncový bod. Implementácia klientskej strany Automatické spracovanie platieb Zákaznícke knižnice zabalené štandardné HTTP klientov automaticky spracovať 402 odpovede.Keď klient dostane žiadosť o platbu, (1) vytvorí platobné užitočné zaťaženie, (2) podpíše ho so súkromným kľúčom používateľa, a (3) obnoví pôvodnú žiadosť s pripojenou platbu. public HttpResponse<String> makeRequest(String url, String method) throws Exception { HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(url)) .method(method, HttpRequest.BodyPublishers.noBody()) .build(); HttpResponse<String> response = httpClient.send(request, HttpResponse.BodyHandlers.ofString()); // Handle 402 Payment Required if (response.statusCode() == 402) { PaymentRequirements requirements = Json.MAPPER.readValue( response.body(), PaymentRequirements.class); // Create payment payload matching the requirements PaymentPayload payment = PaymentPayload.builder() .receiver(requirements.getPaymentRequirement().get(0).getReceiver()) .amount(requirements.getPaymentRequirement().get(0).getAmount()) .asset(requirements.getPaymentRequirement().get(0).getAsset()) .nonce(requirements.getPaymentRequirement().get(0).getNonce()) .expiry(requirements.getPaymentRequirement().get(0).getExpiry()) .build(); // Sign using EIP-712 structured data signing String signature = signer.sign(payment.toSigningMap()); // Retry with payment header String paymentHeader = encodePaymentHeader(payment, signature); HttpRequest paidRequest = HttpRequest.newBuilder() .uri(URI.create(url)) .method(method, HttpRequest.BodyPublishers.noBody()) .header("X-PAYMENT", paymentHeader) .build(); return httpClient.send(paidRequest, HttpResponse.BodyHandlers.ofString()); } return response; } Podpisovací proces používa Štandard, ktorý vytvára štruktúrovanú, ľudsky čitateľnú reprezentáciu platobných údajov pred hashovaním a podpisovaním, čím zabezpečuje, že platba je kryptograficky zabezpečená a viazaná na konkrétnu požiadavku. EIP-712 Overenie platobného toku Facilitátor integrácie Služba facilitátora je tam, kde žije zložitosť blockchainu, abstraktne ju od klientov aj serverov.Keď server dostane platbu, odovzdáva platobné užitočné zaťaženie facilitátorovi na overenie. public class HttpFacilitatorClient implements FacilitatorClient { private final HttpClient http; private final String baseUrl; @Override public VerificationResponse verify(String paymentHeader, PaymentRequirements requirements) throws Exception { // Construct verification request with payment and requirements VerifyRequest body = VerifyRequest.builder() .paymentHeader(paymentHeader) // The X-PAYMENT header from client .requirements(requirements) // What the server expects .build(); HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(baseUrl + "/verify")) .POST(HttpRequest.BodyPublishers.ofString(Json.MAPPER.writeValueAsString(body))) .header("Content-Type", "application/json") .build(); String json = http.send(request, HttpResponse.BodyHandlers.ofString()).body(); return Json.MAPPER.readValue(json, VerificationResponse.class); } @Override public SettlementResponse settle(String paymentHeader, PaymentRequirements requirements) throws Exception { // Settlement happens after successful verification SettleRequest body = SettleRequest.builder() .paymentHeader(paymentHeader) .requirements(requirements) .build(); HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(baseUrl + "/settle")) .POST(HttpRequest.BodyPublishers.ofString(Json.MAPPER.writeValueAsString(body))) .header("Content-Type", "application/json") .build(); String json = http.send(request, HttpResponse.BodyHandlers.ofString()).body(); return Json.MAPPER.readValue(json, SettlementResponse.class); } } Sprostredkovateľ kontroluje niekoľko vecí: Je podpis platný? Zodpovedá výška platby požiadavkám? Bola táto platba použitá predtým? Is the payment still within its expiration window? Ak overenie prebehne, sprostredkovateľ tiež spracováva vyrovnanie vysielaním transakcie na blockchain podľa výberu. Rozhranie definuje zmluvu, ktorú musí každý facilitátorový klient implementovať: FacilitatorClient public interface FacilitatorClient { VerificationResponse verify(String paymentHeader, PaymentRequirements requirements); SettlementResponse settle(String paymentHeader, PaymentRequirements requirements); } Vaša aplikácia musí poskytnúť konkrétnu implementáciu tohto rozhrania. Príklad integrácie Teraz, keď sme videli jednotlivé komponenty (platobné filtre, integrácia facilitátorov a manipulácia s klientmi), pozrime sa, ako sa tieto kúsky spájajú do reálnej aplikácie. Príklad, ktorý ukazuje úplný tok. Spring Boot Najprv vytvorte a Anotácia : @PaymentRequired @Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface PaymentRequired { String price(); String currency() default "USDC"; String network() default "base-sepolia"; } Následne upravte na skenovanie pre tieto poznámky na štarte: PaymentFilter @Component public class PaymentFilter implements Filter { private final Map<String, BigInteger> priceTable; private final String payTo; private final FacilitatorClient facilitator; public PaymentFilter(ApplicationContext context, String payTo, FacilitatorClient facilitator) { this.payTo = payTo; this.facilitator = facilitator; this.priceTable = buildPriceTableFromAnnotations(context); } private Map<String, BigInteger> buildPriceTableFromAnnotations(ApplicationContext context) { Map<String, BigInteger> prices = new HashMap<>(); // Scan all @RestController beans for @PaymentRequired annotations Map<String, Object> controllers = context.getBeansWithAnnotation(RestController.class); for (Object controller : controllers.values()) { Method[] methods = controller.getClass().getMethods(); for (Method method : methods) { PaymentRequired payment = method.getAnnotation(PaymentRequired.class); if (payment != null) { String path = extractPathFromMapping(method); BigInteger amount = new BigInteger(payment.price().replace(".", "")); prices.put(path, amount); } } } return prices; } } Teraz môžete anotovať svoje metódy ovládača priamo: @RestController public class WeatherController { @GetMapping("/weather") @PaymentRequired(price = "0.001", currency = "USDC", network = "base-sepolia") public WeatherData getWeather(@RequestParam String city) { // Your existing business logic return weatherService.getWeatherForCity(city); } @GetMapping("/premium-forecast") @PaymentRequired(price = "0.01", currency = "USDC", network = "base-sepolia") public ExtendedForecast getPremiumForecast(@RequestParam String city) { return weatherService.getExtendedForecast(city); } } @Configuration public class PaymentConfig { @Bean public PaymentFilter paymentFilter(ApplicationContext context) { return new PaymentFilter( context, "<WALLET_ADDRESS>", // Your wallet address new HttpFacilitatorClient("<FACILITATOR_URL>") ); } @Bean public FilterRegistrationBean<PaymentFilter> paymentFilterRegistration(PaymentFilter filter) { FilterRegistrationBean<PaymentFilter> registration = new FilterRegistrationBean<>(); registration.setFilter(filter); registration.addUrlPatterns("/*"); registration.setOrder(1); return registration; } } na anotácia zaobchádza s cenovou konfiguráciou deklaratívne, zatiaľ čo automaticky zisťuje tieto poznámky pri spustení a vytvára cenovú tabuľku. Vaša existujúca obchodná logika v metódach ovládača zostáva úplne nezmenená. Konfigurácia prepojí všetko zaregistrovaním platobného filtra a pripojením na službu sprostredkovateľa. cena 0,001 USDC a Cena je 0,01 USDC, pričom všetky platby sa spracúvajú transparentne na úrovni HTTP. @PaymentRequired PaymentFilter /weather /premium-forecast Bezpečnostné a výrobné úvahy je jednoduchý a elegantný, skrýva zložitosť. Toto je pro a con. Uľahčuje integráciu, ale tiež skrýva dôležitý aspekt: . x402 putting AI agents in charge of money creates new attack vectors Kým signatures and nonce management handle replay attacks, what happens when an agent gets compromised? Traditional fraud detection relies on human behavioral patterns, but Kompromitovaný agent by mohol vyčerpať finančné prostriedky rýchlejšie ako akýkoľvek ľudský podvodník. EIP-712 AI agents don't follow human spending habits Komponent facilitátora sa stáva ďalším cieľom s vysokou hodnotou, pretože overuje podpisy a spravuje nonce. Na rozdiel od tradičných platobných procesorov, ktoré môžu zvrátiť transakcie, . blockchain settlements are final Odvtedy je založená na transakciách na reťazci, zdedí prevádzkové riziká transakcií blockchain. Plynové poplatky kolíšu divoko, niekedy robia mikroplatby ekonomicky nepríjemné. Sieťová kongescia môže oddialiť transakcie. Čo by mal AI agent robiť, keď potrebuje údaje v reálnom čase, ale platba je uviaznutá v mempool? x402 Ďalším dôležitým aspektom je regulácia. Súlad sa líši v rôznych jurisdikciách s rôznymi pravidlami týkajúcimi sa automatizovaných platieb, používania kryptomien a uchovávania údajov. Agent AI, ktorý vykonáva veľké množstvo mikrotransakcií cez hranice, môže spustiť upozornenia AML alebo porušiť miestne predpisy bez toho, aby si to niekto uvedomil. Čo je nasledujúce Čo je zaujímavé o AI agenti potrebujú autonómne platobné schopnosti, stablecoins poskytujú programovateľnú vrstvu peňazí a infraštruktúra blockchain je dostatočne zrelá na to, aby zvládla škálovateľné aplikácie. Tieto kusy sa predtým nevyrovnali. internet teraz potrebuje novú formu platieb a tradičné toky neboli postavené pre autonómnych agentov alebo mikroplatby. x402 je presvedčivý vďaka svojmu pragmatickému prístupu. Namiesto opätovného vymýšľania platieb od začiatku, rozširuje existujúcu infraštruktúru HTTP. Namiesto toho, aby vyžadovala nové integrácie, pracuje so štandardnými vzormi, ktoré už chápeme. x402 Bezpečnostné a operačné výzvy sú reálne, ale sú to inžinierske problémy s možnými riešeniami. Po takmer troch desaťročiach, Možno konečne urobiť to, na čo bol navrhnutý: urobiť platenie za veci na internete tak jednoduché, ako požiadať o ne. HTTP 402 The foundation is set. Now it's time to build. Poďakovanie Erik Zvolen, Ronnie Caspersová, Kevin Leffewová → Danny Organ a celý tím Coinbase → Otvorené zdroje tohto protokolu. Erik Reppelová Ronnie Caspersová Názov Kevin Leffew Dánske orgány Coinbase → . Poďakovanie Erik Reppelová a Yuga Cohlerová Pre preskúmanie Môj príspevok Dvojica x402 Erik Reppelová Yuga Cohlerová Môj príspevok Zdroje a ďalšie čítanie Požadovaná platba HTTP 402 - RFC 2068 - Originálna špecifikácia HTTP 1997 x402 Špecifikácia protokolu - oficiálna dokumentácia protokolu x402 GitHub Repository - Open Source implementácia Coinbase x402 Java implementácia - PR, ktorá predstavila implementáciu Java protokolu EIP-712: Ethereum Typed Structured Data Hashing and Signing - Podpisovací štandard používaný v x402 Základná sieťová dokumentácia - Layer 2 blockchain platforma použitá v príkladoch USDC Dokumentácia - Podrobnosti o zmluve USD Coin stablecoin Spring Boot Filter Documentation - implementácia Java middleware Java HTTP Client API - Správa HTTP na strane klienta Komunikačné štandardy Machine-to-Machine (M2M) - autonómne komunikačné systémy Autonómne architektúry AI agentov - výskum vzorcov dizajnu AI agentov Google's Approach to Secure AI Agents - Návrhy spoločnosti Google na bezpečný, ľudsky riadený rámec AI agentov
