64. Это параметр MAX_FRAMES, предложенный в EIP‑8141: число, которое превращает монолитную транзакцию Ethereum в последовательность, по шагам исполняемую протоколом. Он указывает на пост‑EOA модель: валидация, одобрение газа и выполнение больше не слиты в единый блоб, а оркестрируются по кадрам. Такое решение открывает пространство для нативной абстракции аккаунта, нетрадиционных схем подписи и гибкой оплаты газа — основу, на которой могли бы развиться кошельковый UX следующего поколения и on‑chain приватность. Но хотя механизм существует на бумаге, обновление Hegotá сейчас опирается на другую ставку: принудительное включение.
Frame Transactions рефакторят транзакцию на до 64 фреймов
EIP‑8141 определяет новый тип FRAME_TX, который разлагает действие пользователя на дискретные фреймы, каждый из которых имеет свою роль: фрейм валидации для проверки намерения и авторизации, фрейм одобрения газа для определения того, кто платит и по каким правилам, и фрейм выполнения для применения изменений состояния. Предложение задаёт MAX_FRAMES = 64 и присоединяет явные затраты на каждый фрейм, чтобы сложные сценарии можно было разбить на ограниченные, тарифицируемые шаги, а не на самодельные обходные решения контрактов.
Практическая выгода — нативная абстракция аккаунта. Вместо жёсткой привязки к модели внешне управляемого аккаунта и ECDSA фреймы позволяют кошелькам и контрактам задавать пользовательские схемы подписи, ротировать ключи или мигрировать на подписи, устойчивые к постквантовым атакам, не полагаясь на L2 или сторонний relayer. Абстракции оплаты газа тоже становятся сущностью первого класса: пользователь может определить в протоколе политики о том, кто платит и как — от спонсорских моделей до правил для многокомпонентных активов — кодируя это фреймом, а не внецепочечным соглашением.
Для инструментов приватности важны фреймы, потому что они отделяют логику доказательства и авторизации от записей, меняющих состояние. Кошелёк может валидировать нулевое знание-доказательство в одном фрейме по выбранной им схеме, одобрить газ в другом, а затем зафиксировать приватный перевод в фрейме выполнения. Протокол получает стандартную, проверяемую последовательность; команды приложений не обязаны воспроизводить контракт-обёртки для каждого нового сценария использования.
Всё это зависит от включения в сетевое обновление. И здесь приоритеты Hegotá ставят включение выше рефакторинга.
Главный акцент Hegotá — принудительное включение, а не приватность
В своём обновлении для разработчиков от 10 апреля 2026 года Фонд Ethereum подтвердил, что FOCIL (EIP‑7805) — главный акцент Hegotá. Списки принудительного включения по выбору форка (Fork‑Choice Enforced Inclusion Lists) — это механизм консенсуса и выполнения, предназначенный для обеспечения своевременного включения транзакций и смягчения цензуры на уровне строителей (builder), которая может тихо «застрять» транзакции вне канонической цепочки.
В том же обновлении Фонд отметил, что Frame Transactions (EIP‑8141) перешли в статус «Considered for Inclusion» («рассматривается для включения») как не-«головной» элемент. Эта метка обязывает протокольные команды работать над функцией, но без повышения до статуса ключевого компонента. Сроки неясны, и вместе с ними — график нативной абстракции аккаунта и выгод на уровне кошельков, которые фреймы разблокировали бы.
Упорядочивание говорит о базовых принципах. Гарантии включения — обязательное условие для любой серьёзной прослойки приватности. Если разработчики или производители блоков могут подавлять или бесконечно задерживать транзакции, то приватная запись остаётся приватной лишь до тех пор, пока она вообще не попадёт в сеть. Закрепляя FOCIL, Hegotá стремится усилить гарантию того, что приватные отправки — будь то экранированные переводы или обновления, богатые доказательствами — действительно доходят до цепочки.
Канонические экранированные переводы в L1 нацелены на то, чтобы устранить фрагментированную анонимность
Вторая «приватная» опора в дорожной карте Ethereum — это один экранированный пул, управляемый протоколом, развёрнутый через форк. EIP‑8182 предлагает системный контракт, способный выполнять приватные переводы ETH и поддерживающий совместимые переводы ERC‑20, используя архитектуру с раздельным доказательством: доказательство пула, чтобы показать, что перевод согласуется с экранированным состоянием, и отдельное доказательство авторизации, чтобы продемонстрировать право расходования. Цель — встроить один канонический пул в L1, а не полагаться на мозаичную смесь миксеров на уровне приложений с небольшими фрагментированными множествами анонимности. В дорожной карте приватности Ethereum EIP‑8182 указана как рассматриваемая для Hegotá наряду с Frame Transactions, и отмечается, что только изменения протокола недостаточны для обеспечения сквозной приватности.
Приватность зависит от цепочки, выходящей за рамки изменений протокола
Дорожная карта обновлена 27 июля 2026 года и разбивает задачу на три исхода — приватное чтение (private reads), приватную запись (private writes) и приватное доказательство (private proving) — и прямо указывает, что отправка нового типа транзакций или системного пула не завершит картину. Несколько взаимодополняющих слоёв должны появиться вместе:
Приватный поиск информации для приватных чтений, чтобы кошельки могли находить и получать релевантные данные, не раскрывая свои интересы серверам.
Frame Transactions плюс FOCIL для отправки, устойчивой к цензуре, так что приватные записи структурированы и не могут быть бесконечно исключены.
Доказательства на стороне клиента и zkVM для конфиденциальной семантики, чтобы пользователи могли генерировать доказательства локально, не раскрывая чувствительные детали третьим сторонам.
Только когда эти компоненты складываются чисто, пользовательский путь становится действительно приватным: обнаружить баланс, не сигнализируя об этом, подготовить перевод, не передавая секреты на сторону, и отправить его под протоколом, который не сможет ни «переоценить» (second‑guess), ни остановить транзакцию. Hegotá может проложить рельсы для частей этой последовательности, но слой доступа и стек доказательств должны успевать.
Эта цепочка зависимостей также формирует UX кошельков. Фреймы обещают нормализовать то, как выражаются авторизация и политика по газу, но разработчикам всё ещё нужны проверенные в бою библиотеки для локального создания доказательств и эффективных схем, а пользователям нужно клиентское ПО, которое сможет генерировать доказательства с приемлемыми задержками и в рамках бюджета по мощности. Без этого канонический пул рискует остаться мощным примитивом, который сможет использовать лишь небольшая доля обычных пользователей.
Над протокол‑нативным экранированным пулом нависает регуляторный прецедент
Есть ещё одно ограничение — соответствие требованиям (комплаенс). 8 августа 2022 года Управление по контролю за иностранными активами (Office of Foreign Assets Control) Министерства финансов США санкционировало миксер Tornado Cash, обозначив точку отсчёта для того, как регуляторы могут относиться к приватности и инфраструктуре для смешивания. Пресс‑релиз и последующие судебные преследования подчеркнули, что инструменты, позволяющие выполнять анонимизированные переводы, могут привлекать меры принудительного характера.
Форк‑управляемый пул L1 не эквивалентен стороннему сервису, но прецедент всё равно важен. Биржи, поставщики кошельков и операторы инфраструктуры, которым нужно интерпретировать риски санкций, могут смягчать или ограничивать взаимодействие с нативным пулом даже при том, что он канонический и прошёл аудит. Это влияет не только на «картинку», но и на практический охват приватных переводов, и вводит операционные решения для организаций, которые выступают посредниками при доступе пользователей к Ethereum.
Упорядочивание у Hegotá понятно: принудительное включение зафиксировано, а рефакторинг транзакций на основе фреймов находится в статусе «Considered for Inclusion». Ethereum, вероятно, сможет гарантировать, что приватные записи не будут цензурированы, прежде чем сможет нативно разложить и авторизовать их в рамках нового типа транзакций. Доставит ли форк‑управляемый экранированный пул практическую приватность — зависит от этого порядка, а также от того, что такие не протокольные компоненты, как PIR и доказательства на стороне клиента, прибудут вовремя.
Отказ от ответственности: эта статья предоставляется только в информационных целях. Она не предлагается и не предназначена для использования в качестве юридической, налоговой, инвестиционной, финансовой или иной консультации.