"For øyeblikket er x402 bare en "loli" 😅 i betalingssporet Jeg har opplevd x402 de siste dagene, fra en ingeniørs synspunkt er det fortsatt mye rom for forbedring i denne tingen, og det vil være flere problemer som hindrer den generelle utviklingen av x402. Hvis de ikke kan løses, tror jeg de bare kan forbli i konseptstadiet og ikke kan brukes i stor skala. 1. Kompleksiteten ved ⚙️ ingeniørinnbygging x402 tilbyr en fetch SDK og noe HTTP-mellomvare for å implementere denne betalingsfunksjonen. Men hentepakken er faktisk en spesiell pakke, hvis du trenger å bruke den, kan du i koden bare bruke hentingen deres for enkel tilgang, ellers må du manuelt fullføre en veldig kompleks tilgangslogikk. Samtidig prioriteres tilgang til mellomvare, selv om den allerede støtter vanlige rammeverk, men den må fortsatt finpusses. Dette er selvfølgelig det minste problemet, og med utviklingen av økosystemet er disse problemene tross alt små ting. 2. Ingen vesentlige endringer 🧩 skjedde Selv om statuskoden 402 høres bløffende og fantastisk ut, spiller det faktisk ingen rolle hva den returnerer i det hele tatt, den kan returnere en 402, 200 med en json eller hva som helst og en haug med data. I hovedsak er det bare en teknisk innkapsling som legger til en betalingsprosess. 3. Upålitelighet ⏱️ under høyfrekvente samtaler Når det gjelder den andre artikkelen, vil det oppstå et problem, som er det såkalte høyfrekvente problemet. Vi vet at det nåværende mainstream-konseptet er at AI Agent kaller en API for å innhente data eller annet innhold, men med tillegg av denne betalingslogikken blir hele prosessen veldig lang. AI Agents lavfrekvente forespørsler er greit (fordi agenter allerede er trege med å komme med forespørsler...... Når den kommer inn i en høyfrekvent forespørsel, vil forespørselstiden for en API bli doblet, og en API-forespørsel kan utvides til 3 til 10 ganger den opprinnelige (den offisielle testen er at hver forespørsel er forsinket med 2 sekunder, men jeg tror det er optimistiske data). Hvis jeg trenger å få tak i mye data, er tiden for hele prosessen ødeleggende. Fordi antall forespørsler øker, og du også må vente på transaksjonsbekreftelse på kjeden og RPC-forsinkelse, kan høyfrekvente APIer i utgangspunktet ikke velge gjeldende x402-modus (selvfølgelig kan den endres i fremtiden). 4. Ekstremt ufullkomne prosesser 🔁 Som en betalingsorientert protokoll ser jeg ikke strengheten til dette produktet som en finansiell mellomvare i det hele tatt. Jeg aner ikke hvordan han håndterer den faktiske forespørselen etter betaling på grunn av nettverkssvingninger, og jeg ser ikke noe bindende forhold mellom API-forespørsler og transaksjonsposter. I det tradisjonelle tilfellet med Web2 har betalingen ikke bare en tilbakeringingsmetode (etter at betalingen er fullført, vil den bli omdirigert til selgerens angitte side), men også periodisk ny forespørsel (hvis tilbakeringingen ikke utføres, vil det være 3 sekunder, 5 sekunder, 1 minutt,。。。 Vent en stund for å prøve å tilbakekalle på nytt til du forhindrer at transaksjonen går tapt). Jeg ser det ikke i det hele tatt i x402. Det er som om du er en liten kjøpmann i en gatebod og kjøper noe i et supermarked. Du kjøper noe i boden, det er ingen faktura, ingen produktinformasjon, ingen mengde, og når du går hjem, oppdager du at tingene du kjøpte er råtne, og du vil bare forsvare rettighetene dine og finne ut, hei, denne boden har allerede stukket av. Men når du kjøper noe i supermarkedet, er det i det minste en fysisk, det er en faktura, det er overvåking, og hvis du møter en feit Donglai, kan du til og med nyte en ubetinget refusjon. x402 som et B-end-produkt, nå er denne tingen helt ukvalifisert og ikke ansvarlig. 5. Det er knapt noen reguleringsprosess ⚖️ Jeg vet at mange tror at ingen tilsyn er en god ting, den såkalte desentraliseringen, det som betales til er ingen KYC og ingen tilsyn, vi vil ikke snakke om den hyppige forekomsten av sikkerhetshendelser forårsaket av implementering av ny teknologi her, la oss snakke om en såkalt API-leverandør, hvis det på grunn av ulike problemer, gir ikke-samsvarende data, eller fordi antall forespørsler er for stort, noe som resulterer i en feil i en bestemt forespørsel fra selgeren, eller en rekke forespørsler er feil, men du har allerede betalt, hvordan refunderer du spørsmålet. Jeg ser ingen relevant mekanisme for øyeblikket, det vil si at hvis du en dag er uheldig og blir sittende fast på nettverket etter å ha betalt, eller de blir sittende fast på nettverket, eller de blir sittende fast på tjenesten, eller du oppdaterer den, så gratulerer, betalingen din er ugyldig. Da leter du etter hvordan du refunderer, og etter å ha sett deg mye rundt, finner du ut at hehe, det er ingen, ingen kan være ansvarlig for denne betalingsatferden, på det meste går du til leverandøren, sier at du har betalt, men ikke levert tjenesten, og spiller deretter ballen i flere måneder. Hvis du er uheldig, har ikke tjenesteleverandøren nok overvåking for koden, og de vil ikke engang kunne finne forespørselsposten din.

@taowang1 @Cloudflare Stavefeil navnbillig