Усі будують агентів і гаманці. Майже ніхто не питає, чи доходять транзакції до ланцюга.
Агенти вже платять за речі в Ethereum. Не в демо. x402 перетворив HTTP 402 на живий платіжний потік, а гаманці агентів тепер постачаються з ключами та лімітами витрат. Команди будують рішення, виходячи з припущення, що машина може самостійно виконувати свої зобов’язання без участі людини поруч.
Індустрія дуже швидко дала агентам засоби для оплати, але пропустила те, що під ними. Платіжна магістраль передбачає, що платіж проходить, а Ethereum ніколи не будувався на такому припущенні. Включення — це «краще з можливого»: ви надсилаєте й сподіваєтесь, що транзакція потрапить у наступний блок. Людина може обійти це, спостерігаючи, як транзакція зависає, підвищуючи комісію й повторюючи спробу. Ви можете побудувати агента, який робитиме те саме. Чого ви не можете побудувати — це визначеність: повторна спроба — це те саме парі, зроблене ще раз, у ринку, який уже змінився.
Усе це мало важить на одній транзакції. Але має величезне значення на десяти тисячах на день, коли кожна дія чекає на завершення попередньої.
Ethereum здійснює розрахунок вартості. Він ще не вміє її планувати.
В Ethereum блоковий простір розподіляється через живий аукціон, який завершується приблизно кожні дванадцять секунд. Коли ви надсилаєте транзакцію, ви не купуєте гарантоване місце в наступному блоці. Ви входите в змагання, і його результат — як щодо самого факту включення, так і щодо того, скільки ви врешті заплатите, — залишається невідомим, доки все вже не завершилося. Такий дизайн елегантний для бездозвільної мережі. Але він чужий тому, як працюють інституційні фінанси.
Інституції вже в Ethereum. Чого вони не можуть робити — це запускати стратегії, яким потрібні гарантії. Коли трейдинговий стіл не може заздалегідь знати, чи буде транзакцію виконано вчасно або скільки вона коштуватиме, він не може виставити великий обсяг, тому така активність залишається офчейн або переміщується туди, де дадуть зобов’язання.
Протягом років відповіддю на обмеження Ethereum була пропускна здатність: більше транзакцій на секунду, більше ролапів, які розносять попит. Пропускна здатність — це міра «скільки». Вона нічого не каже про «коли». Це проблема часу, а не простору, й додавання простору її не розв’язує.
Закриття розриву
Зараз до етапу реалізації виходять кілька підходів, кожен із яких бере на себе різний шар цієї проблеми.
Преконфірмації дозволяють пропоненту блоку зобов’язатися включити або виконати транзакцію до фіналізації блоку. Це найпряміша відповідь на проблему часу: агенту більше не потрібно надсилати й сподіватися. Але зобов’язання має щось означати. Потрібна широка участь валідаторів, достовірна економічна підтримка й примусові наслідки, коли пропонент не виконує обіцянку. Системи, які поєднують преконфірмації із застейканим забезпеченням і умовами слешингу, перетворюють обіцянку на відповідальне зобов’язання.
Списки включення працюють на рівні протоколу, обмежуючи те, що білдер може залишити поза блоком. Це робить їх потужним інструментом проти цензури. Але вони розв’язують іншу задачу: зробити транзакцію складнішою для виключення — це не те саме, що зобов’язатися щодо часу її виконання. Список включення задає «підлогу». Він не задає розкладу.
Форвардні ринки розширюють цей розклад далі в майбутнє. Вони дозволяють інституціям та застосункам резервувати блоковий простір до того, як він їм знадобиться, так само, як енергія, пропускна здатність і обчислювальні ресурси контрактуються заздалегідь до попиту. Це перетворює майбутню місткість на щось, навколо чого покупець може планувати, а не конкурувати в реальному часі. Питання дизайну тут стосуються структури ринку: прозорий доступ, відповідальна доставка з боку валідаторів і механізми, які не дають можливості небагатьом великим покупцям загнати можливість у кут.
У кожного підходу можуть бути обмеження, які доведеться обійти дизайном. Разом вони утворюють форму ринку, на основі якого агенти та інституції справді можуть будувати: зобов’язання пропонента, які щось означають, протокольні гарантії проти виключення й форвардна місткість, що масштабується до інституційного попиту. Окремі підходи мають власні дизайнерські питання. Напрям очевидний.
Агент, що розкручує позицію на двох майданчиках, має знати, що другий «ніжка» буде проведена до того, як він зобов’яжеться на першу. Без цього він не запускає стратегію. Він робить ставку й чекає результату.
Ethereum уже побудував достовірний розрахунок. Наступний виклик — зробити доступ до цього розрахунку програмованим наперед. Якщо агенти збираються координувати капітал на швидкості машин, блоковий простір не може лишатися чимось, за що вони лише торгуються й сподіваються отримати. Він має стати тим, що вони можуть планувати за розкладом.