"V současné době je x402 pouze "loli" 😅 v platební stopě V posledních dnech jsem zažil x402, z pohledu inženýra je v této věci stále hodně prostoru pro zlepšení a bude několik problémů, které budou bránit celkovému vývoji x402. Pokud je nelze vyřešit, myslím, že mohou zůstat pouze ve fázi konceptu a nelze je aplikovat ve velkém měřítku. 1. Složitost inženýrského ⚙️ zabudování x402 poskytuje sadu fetch SDK a některé HTTP middleware pro implementaci této platební funkce. Ale balíček fetch je ve skutečnosti speciální balíček, pokud jej potřebujete použít, pak v kódu můžete použít pouze jejich fetch pro snadný přístup, jinak musíte ručně dokončit velmi složitou logiku přístupu. Zároveň je upřednostňován přístup k middlewaru, i když již podporuje běžné rámce, ale stále je třeba jej zdokonalit. To je samozřejmě nejmenší problém a s rozvojem ekosystému jsou tyto problémy přece jen maličkosti. 2. Nedošlo k žádným podstatným změnám 🧩 I když stavový kód 402 zní blafující a úžasný, ve skutečnosti vůbec nezáleží na tom, co vrátí, může vrátit 402, 200 s json nebo cokoli a hromadu dat. V podstatě se jedná pouze o inženýrské zapouzdření, které přidává platební proces. 3. Nespolehlivost ⏱️ při vysokofrekvenčních hovorech V případě druhého článku nastane problém, kterým je tzv. vysokofrekvenční problém. Víme, že současný mainstreamový koncept je, že AI Agent volá API pro získání dat nebo jiného obsahu, ale s přidáním této platební logiky se celý proces stává velmi dlouhým. Nízkofrekvenční požadavky AI Agenta jsou v pořádku (protože Agenti jsou již pomalí v zadávání požadavků...... Jakmile vstoupí do vysokofrekvenčního požadavku, doba požadavku API se zdvojnásobí a požadavek API může být prodloužen na 3 až 10násobek původního požadavku (oficiální test je, že každý požadavek je zpožděn o 2 sekundy, ale myslím, že jsou to optimistická data). Pokud potřebuji získat velké množství dat, je doba celého procesu zničující. Vzhledem k tomu, že se počet požadavků zvyšuje a vy také musíte čekat na potvrzení transakce v řetězci a zpoždění RPC, vysokofrekvenční rozhraní API v podstatě nemohou zvolit aktuální režim x402 (samozřejmě jej lze v budoucnu upravit). 4. Extrémně nedokonalé procesy 🔁 Jako protokol orientovaný na platby vůbec nevidím přísnost tohoto produktu jako finančního middlewaru. Netuším, jak se vyřizuje se samotným požadavkem po zaplacení kvůli výkyvům sítě, a nevidím žádný závazný vztah mezi požadavky API a záznamy transakcí. V tradičním případě Web2 má platba nejen metodu zpětného volání (po dokončení platby bude přesměrována na stránku určenou obchodníkem), ale také pravidelný opakovaný požadavek (pokud se zpětné volání neprovede, bude to trvat 3 sekundy, 5 sekund, 1 minutu,。。。 Počkejte určitou dobu, než se pokusíte o zpětné volání, dokud se úspěšně nezabrání ztrátě transakce). V x402 to vůbec nevidím. Je to, jako byste byli malým obchodníkem u pouličního stánku a něco si kupovali v supermarketu. Něco si koupíte u stánku, není tam žádná faktura, žádné informace o produktu, žádné množství, a když jdete domů, zjistíte, že věci, které jste koupili, jsou shnilé, a chcete jen hájit svá práva a zjistit, hele, ten stánek už utekl. Ale když si něco koupíte v supermarketu, je tam alespoň fyzický, je tam faktura, je tam monitorování, a pokud potkáte tlustého Donglai, můžete se dokonce těšit na bezpodmínečné vrácení peněz. x402 jako B-end produkt, nyní je tato věc zcela nekvalifikovaná a nezodpovědná. 5. Neexistuje téměř žádný regulační proces ⚖️ Vím, že mnoho lidí si myslí, že žádný dohled je dobrá věc, tzv. decentralizace, za co se platí, není žádný KYC a žádný dohled, nebudeme zde mluvit o častém výskytu bezpečnostních incidentů způsobených zaváděním nových technologií, pojďme se bavit o tzv. poskytovateli API, pokud z důvodu různých problémů poskytuje nevyhovující data, nebo proto, že počet požadavků je příliš velký, což má za následek chybu v určitém požadavku obchodníka, nebo je řada požadavků špatná, ale již jste zaplatili, jak vrátíte otázku zpět. V tuto chvíli nevidím žádný relevantní mechanismus, to znamená, že pokud jednoho dne budete mít smůlu a po zaplacení se zaseknete v síti, nebo se zaseknou v síti, nebo se zaseknou ve službě, nebo ji obnovíte, pak gratulujeme, vaše platba je neplatná. Pak hledáte, jak vrátit peníze, a poté, co se hodně rozhlížíte, zjistíte, že hehe, neexistuje žádný, nikdo nemůže být zodpovědný za toto platební chování, nanejvýš jdete k poskytovateli, řeknete, že jste zaplatili, ale neposkytli službu, a pak hrajete míč měsíce. Pokud máte smůlu, poskytovatel služeb nemá dostatečné monitorování kódu a nebude schopen najít ani záznam vašeho požadavku.

@taowang1 @Cloudflare Chybně napsané jménocheap