Разработчики Ethereum обсуждают, как спрятать содержимое транзакций до того, как их поставят в блок. Цель — лишить ботов возможности видеть чужую сделку заранее и вставлять свои операции до и после неё. Обсуждение назначено на 19 августа, готового решения нет ни у кого.

Коротко: что предлагают

Основное предложение носит номер EIP-8184 и название LUCID. Смысл в модели «сначала обязательство, потом раскрытие»: сборщик блока обязуется включить запечатанную транзакцию, ещё не зная, что она делает, и только после фиксации порядка содержимое расшифровывается.

Есть и альтернатива — EIP-8105, где вместо криптографической схемы предлагается граф доверия между зарегистрированными поставщиками услуг, а принуждение вынесено за пределы правил консенсуса.

За продвижение выступает коалиция «Зашифруй мемпул» во главе с Shutter Network, к которой присоединились Fairblock и Nillion.

Как устроен механизм LUCID

Зачем это нужно

Пока транзакция ждёт включения в блок, её видно всем. На этом построен целый класс атак: бот замечает крупный обмен, ставит свою сделку перед ним, а вторую — сразу после, и снимает разницу. Мы разбирали механику фронтраннинга и влияние такой добычи стоимости на доходность протоколов отдельно.

Нынешнее лекарство хуже болезни с точки зрения децентрализации: чтобы не показывать сделку публично, пользователи отправляют её через закрытые каналы к отдельным сборщикам блоков. Защита работает, но поток заявок концентрируется у нескольких игроков — а это ровно то, чего сеть старается избежать.

Шифрование мемпула должно вернуть транзакции в общий публичный канал, сохранив приватность до момента включения.

Что мешает внедрению

Насколько я это вижу, честность этих предложений в том, что они прямо называют нерешённое.

Главное признание содержится в самом документе: сегодня не существует криптографической конструкции, которая удовлетворяла бы всему набору требований на масштабе Ethereum. То есть предлагается не готовая схема, а рамка, куда её потом можно вставить.

Вторая проблема — ответственность. Если ключ для расшифровки не появился вовремя, система не может отличить злой умысел от сбоя программы, задержки в сети или пропущенного срока. А сейчас в конструкции наказывается отправитель транзакции, а не тот, кто должен был опубликовать ключ.

И здесь возникает трезвое наблюдение о цене приватности. Каждая такая схема добавляет шаг между отправкой и исполнением, а любой дополнительный шаг — это новая точка отказа, которую кто-то должен оплачивать. LUCID отвечает на это резервным сбором: заплати вперёд, получи назад при успехе. По сути пользователю предлагают страховать своей же комиссией работу третьей стороны — и ограничение зашифрованной части одной восьмой блока показывает, насколько осторожно к этому подходят даже авторы.

Когда это может заработать

Сроков нет. Развёртывание придётся согласовывать с механизмом принудительного включения транзакций, который сам ещё готовится к одному из будущих обновлений сети. Коалиция добивается попадания в один из ближайших хардфорков, но решения не принято.

Открытыми остаются и практические вопросы: сложность реализации в клиентах, риски на уровне сетевого обмена, время распространения запечатанных грузов и согласование между сборщиками, кошельками и валидаторами. Ближайшее по времени обновление Ethereum, к слову, уже грозит сломать часть кошельков — и это изменение куда проще обсуждаемого.

Источники

Материал подготовлен на основе публикаций CryptoSlate и EtherWorld.