Все строят агентов и кошельки. Почти никто не спрашивает, дойдут ли транзакции до сети.
Агенты уже оплачивают что‑то в Ethereum. Не в демо. x402 превратил HTTP 402 в реальный платежный поток, а агентские кошельки теперь поставляются с ключами и лимитами расходов. Команды всё чаще исходят из того, что машина может самостоятельно исполнять свои обязательства без человека рядом.
Индустрия быстро дала агентам средства для оплаты, но пропустила фундаментальный слой. Платёжный рельс предполагает, что платёж проходит, а Ethereum изначально не строился на таком предположении. Включение — это best effort: вы отправляете транзакцию и надеетесь, что она попадёт в следующий блок. Человек может обойти это ограничение, заметив, что транзакция застряла, повысив комиссию и повторив отправку. Вы можете построить агента, который сделает то же самое. Но вы не можете построить определённость: повтор — это та же ставка ещё раз в рынке, который уже сдвинулся.
При одной транзакции это почти не важно. Это становится критично при десяти тысячах в день, когда каждое действие ждёт предыдущего.
Ethereum рассчитывает стоимость. Он ещё не умеет её планировать.
В Ethereum пространство блока распределяется через живой аукцион, который завершается примерно каждые двенадцать секунд. Когда вы отправляете транзакцию, вы не покупаете гарантированное место в следующем блоке. Вы вступаете в соревнование, и его исход — как по факту включения, так и по итоговой цене — остаётся неизвестным до тех пор, пока всё уже не завершится. Этот дизайн элегантен для permissionless‑сети. Но он чужд тому, как устроены институциональные финансы.
Институты уже в Ethereum. Чего они не могут — так это запускать стратегии, которым нужны гарантии. Если трейдинговый стол не может заранее знать, выполнится ли транзакция вовремя и сколько придётся заплатить за её проведение, он не может поставить за ней крупный объём. Такая активность остаётся off‑chain или уходит туда, где готовы дать обязательство.
Годами ответом на ограничения Ethereum был «только пропускная способность»: больше транзакций в секунду, больше rollup’ов, рассеивающих спрос. Пропускная способность — это мера «сколько». Ничего не говорит о «когда». Это проблема времени, а не пространства, и добавление пространства её не решает.
Сближение разрыва
Сейчас в реализацию входят несколько подходов, каждый из которых решает свой слой проблемы.
Предподтверждения (preconfirmations) позволяют предложителю блока (proposer) заранее взять на себя обязательство включить или исполнить транзакцию до финализации блока. Это самый прямой ответ на проблему времени: агенту больше не нужно отправлять и надеяться. Но обязательство должно что‑то значить. Нужны широкое участие валидаторов, надёжная экономическая подпитка и поддающиеся исполнению последствия, если proposer не выполнит обещание. Системы, которые связывают предподтверждения с застейканным залогом и условиями для slashing, превращают обещание в подотчётное обязательство.
Списки включения (inclusion lists) работают на уровне протокола, ограничивая то, что билдеру разрешено исключать. Это делает их мощным инструментом против цензуры. Но они решают другую задачу: усложнить исключение транзакции — не то же самое, что зафиксировать время её исполнения. Список включения задаёт «пол». Он не задаёт расписание.
Форвард‑рынки (forward markets) расширяют это расписание дальше в будущее. Они позволяют институтам и приложениям резервировать blockspace заранее, так же как энергия, пропускная способность и вычислительные ресурсы контрактуются до возникновения спроса. Это превращает будущую пропускную способность в то, вокруг чего покупатель может планировать, а не конкурировать в режиме реального времени. Вопросы дизайна здесь — о структуре рынка: прозрачный доступ, поставка, за которую валидатор несёт ответственность, и механизмы, не позволяющие небольшой группе крупных покупателей «зауглить» мощность.
У каждого подхода есть ограничения, которые нужно обойти дизайном. Вместе они формируют контуры рынка, под который агенты и институты действительно могут строиться: значимые обязательства со стороны proposers, протокольные гарантии против исключения и форвард‑мощность, масштабируемая под институциональный спрос. Отдельные подходы ещё несут в себе нерешённые вопросы дизайна. Направление уже ясно.
Агент, который сворачивает позицию на двух площадках, должен знать, что вторая нога сделки «приземлится» до того, как он возьмёт обязательство по первой. Без этого он не реализует стратегию. Он делает ставку и ждёт исхода.
Ethereum уже построил надёжный слой расчётов. Следующий вызов — сделать доступ к этим расчётам программируемым заранее. Если агенты собираются координировать капитал на машинной скорости, blockspace не может оставаться чем‑то, за что они просто торгуются и надеются получить. Он должен стать тем, что можно планировать по расписанию.