"На даний момент х402 - це лише "лолі" 😅 в платіжному треку Я зіткнувся з x402 за останні кілька днів, з точки зору інженера, в цій справі ще є багато можливостей для вдосконалення, і буде кілька проблем, які заважають загальному розвитку x402. Якщо їх не можна вирішити, я думаю, вони можуть залишатися лише на стадії концепції і не можуть бути застосовані у великих масштабах. 1. Складність інженерного ⚙️ вбудовування x402 надає fetch SDK та деяке проміжне програмне забезпечення HTTP для реалізації цієї платіжної функції. Але пакет fetch насправді є спеціальним пакетом, якщо вам потрібно його використовувати, то в коді ви можете використовувати тільки їх fetch для легкого доступу, в іншому випадку вам потрібно вручну виконувати дуже складну логіку доступу. У той же час, доступ до middleware є пріоритетним, хоча воно вже підтримує мейнстрімні фреймворки, але його все одно потрібно відточувати. Звичайно, це найменша проблема, а з розвитком екосистеми ці проблеми все-таки дрібниці. 2. Суттєвих змін 🧩 не відбулося Хоча код статусу 402 звучить блефовано і приголомшливо, насправді зовсім не важливо, що він повертає, він може повертати 402, 200 з json, або що завгодно і купа даних. По суті, це просто інженерна інкапсуляція, яка додає процес оплати. 3. Ненадійність ⏱️ при високочастотних дзвінках У випадку з другою статтею виникне проблема, яка є так званою високочастотною проблемою. Ми знаємо, що поточна основна концепція полягає в тому, що AI Agent викликає API для отримання даних або іншого контенту, але з додаванням цієї логіки оплати весь процес стає дуже довгим. Низькочастотні запити AI Agent цілком прийнятні (тому що агенти вже повільно роблять запити...... Як тільки він введе високочастотний запит, час запиту API збільшиться вдвічі, а запит API може бути продовжений до 3 до 10 разів порівняно з оригіналом (офіційний тест полягає в тому, що кожен запит затримується на 2 секунди, але я думаю, що це оптимістичні дані). Якщо мені потрібно отримати багато даних, час всього процесу є руйнівним. У зв'язку з тим, що кількість запитів збільшується, а також потрібно чекати підтвердження транзакції в ланцюжку і затримки RPC, високочастотні API в принципі не можуть вибрати поточний режим x402 (звичайно, він може бути змінений в майбутньому). 4. Вкрай недосконалі процеси 🔁 Як протокол, орієнтований на платежі, я взагалі не бачу строгості цього продукту як фінансового проміжного програмного забезпечення. Я поняття не маю, як він обробляє фактичний запит після оплати через коливання мережі, і я не бачу жодних зобов'язуючих відносин між запитами API та записами транзакцій. У традиційному випадку Web2 оплата має не лише метод зворотного дзвінка (після завершення платежу він буде перенаправлений на вказану сторінку мерчанта), а й періодичний повторний запит (якщо зворотний дзвінок не виконаний, то це буде 3 секунди, 5 секунд, 1 хвилина,。。。 зачекати деякий час, щоб спробувати повторно здійснити зворотний дзвінок, доки це не вдасться запобігти втраті транзакції). У х402 я його взагалі не бачу. Це все одно, що ви маленький торговець у вуличному кіоску і купуєте щось у супермаркеті. Ви купуєте щось у кіоску, немає ні рахунку, ні інформації про товар, ні кількості, а коли йдете додому, виявляєте, що куплені вами речі прогнили, і ви просто хочете відстояти свої права і з'ясувати, агов, цей ларьок вже втік. Але коли ви купуєте щось у супермаркеті, як мінімум є фізичне, є рахунок-фактура, є моніторинг, і якщо ви зустрінете товстого Донглая, ви навіть можете насолоджуватися беззастережним поверненням коштів. x402 як продукт B-end, зараз ця річ абсолютно некваліфікована і не відповідальна. 5. Регуляторний процес ⚖️ майже відсутній Я знаю багато хто думає, що відсутність нагляду - це добре, так звана децентралізація, що платно - це немає KYC і немає нагляду, ми не будемо говорити про часте виникнення інцидентів безпеки, викликаних впровадженням нових технологій, тут ми говоримо про так званого постачальника API, якщо через різні проблеми надаємо невідповідні дані, або тому, що кількість запитів занадто велика, в результаті чого виникає помилка в певному запиті мерчанта, або серія запитів неправильна, але ви вже оплатили, як повернути гроші питання. Я не бачу якогось відповідного механізму на даний момент, тобто якщо в один прекрасний день вам не пощастить і ви застрягнете в мережі після оплати, або вони застрягнуть в мережі, або вони застрягли на сервісі, або ви його оновите, то вітаємо, ваш платіж недійсний. Потім ви шукаєте, як повернути гроші, і після довгих пошуків виявляєте, що хе-хе, такого немає, ніхто не може відповідати за таку платіжну поведінку, максимум ви йдете до провайдера, говорите, що оплатили, але не надавали послугу, а потім місяцями граєте в м'яч. Якщо вам не пощастить, постачальник послуг не зможе достатньо стежити за кодом, і він навіть не зможе знайти запис вашого запиту.

@taowang1 @Cloudflare Ім'я з помилками в написанні