Виталик о возможном будущем Ethereum (шестая часть): The Splurge

В дизайне протокола Ethereum примерно половина содержания касается различных типов улучшений EVM, а остальная часть состоит из различных нишевых тем — в этом и заключается суть «Splurge» (процветания).

Оригинальное название: «Possible futures of the Ethereum protocol, part 6: The Splurge»

Автор: Vitalik Buterin

Перевод: zhouzhou, BlockBeats

Ниже приведён оригинальный текст (для удобства понимания и чтения он был немного переработан):

Некоторые вещи сложно отнести к одной категории, и в дизайне протокола Ethereum существует множество «деталей», которые крайне важны для успеха Ethereum. На самом деле, примерно половина содержания касается различных типов улучшений EVM, а остальная часть состоит из различных нишевых тем — в этом и заключается суть «Splurge» (процветания).

Дорожная карта 2023: Splurge

Splurge: ключевые цели

• Сделать EVM высокопроизводительным и стабильным «финальным состоянием»
• Внедрить абстракцию аккаунтов в протокол, чтобы все пользователи могли пользоваться более безопасными и удобными аккаунтами
• Оптимизировать экономику комиссий за транзакции, повысить масштабируемость и снизить риски
• Исследовать передовую криптографию для значительного долгосрочного улучшения Ethereum

Улучшения EVM

Какую проблему это решает?

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

Что это такое и как работает?

Первый шаг в текущей дорожной карте улучшения EVM — это EVM Object Format (EOF), который планируется включить в следующий хардфорк. EOF — это серия EIP, определяющих новую версию кода EVM с рядом уникальных особенностей, наиболее заметные из которых:

• Разделение кода (исполняемого, но недоступного для чтения из EVM) и данных (читаемых, но не исполняемых)
• Запрет динамических переходов, разрешены только статические переходы
• Код EVM больше не может наблюдать информацию, связанную с gas
• Добавлен новый явный механизм подпрограмм

Структура кода EOF

Splurge: улучшения EVM (продолжение)

Старые контракты будут продолжать существовать и могут создаваться, хотя в будущем их могут постепенно вывести из обращения (или даже принудительно перевести в код EOF). Новые контракты получат выгоду от повышения эффективности, которое приносит EOF — сначала за счёт немного уменьшенного байткода благодаря подпрограммам, затем — за счёт новых функций EOF или снижения стоимости gas.

После внедрения EOF последующие обновления становятся проще. Наиболее проработанным на данный момент является расширение модульной арифметики EVM (EVM-MAX). EVM-MAX создаёт набор новых операций, специально предназначенных для модульных вычислений, и размещает их в новой области памяти, недоступной для других опкодов, что позволяет использовать такие оптимизации, как умножение Монтгомери.

Более новая идея — объединить EVM-MAX с функцией SIMD (Single Instruction Multiple Data). SIMD как концепция для Ethereum существует давно, впервые предложена в EIP-616 Greg Colvin. SIMD может ускорить множество видов криптографии, включая хэш-функции, 32-битные STARKs и криптографию на решётках. Комбинация EVM-MAX и SIMD делает эти два производительных расширения естественной парой.

Примерный дизайн комбинированного EIP будет основываться на EIP-6690, а затем:

• Разрешить (i) любое нечётное число или (ii) любую степень двойки до 2768 в качестве модуля
• Для каждого опкода EVM-MAX (сложение, вычитание, умножение) добавить версию, которая использует не 3 непосредственных значения x, y, z, а 7: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. В Python-коде эти опкоды работают примерно так:

for i in range(count):

mem[z_start + z_skip * count] = op(

mem[x_start + x_skip * count],

mem[y_start + y_skip * count]

)

В реальной реализации это будет обрабатываться параллельно.

• Возможно, будут добавлены XOR, AND, OR, NOT и SHIFT (включая циклические и нециклические), по крайней мере для модулей — степеней двойки. Также добавлен ISZERO (вывод в основной стек EVM), что будет достаточно мощно для реализации эллиптической криптографии, криптографии на малых полях (например, Poseidon, Circle STARKs), традиционных хэш-функций (SHA256, KECCAK, BLAKE) и криптографии на решётках. Другие обновления EVM также возможны, но пока менее приоритетны.

Ссылки на существующие исследования

• EOF: 
• EVM-MAX: 
• SIMD: 

Оставшаяся работа и компромиссы

В настоящее время EOF планируется включить в следующий хардфорк. Хотя всегда есть вероятность его удаления в последний момент — в прошлых хардфорках функции уже временно удалялись, — сделать это будет сложно. Удаление EOF означает, что любые будущие обновления EVM придётся делать без EOF, что возможно, но, вероятно, будет сложнее.

Главный компромисс EVM — это сложность L1 против сложности инфраструктуры. EOF — это большой объём кода, который нужно добавить в реализацию EVM, а статическая проверка кода также относительно сложна. Однако взамен мы можем упростить языки высокого уровня, упростить реализацию EVM и получить другие преимущества. Можно сказать, что дорожная карта, приоритетом которой является постоянное улучшение Ethereum L1, должна включать и строиться на основе EOF.

Важная задача — реализовать функции, подобные EVM-MAX + SIMD, и провести бенчмаркинг потребления gas для различных криптографических операций.

Как это взаимодействует с другими частями дорожной карты?

Корректировка EVM на L1 облегчает аналогичные корректировки на L2. Если они не синхронизированы, это может привести к несовместимости и негативным последствиям. Кроме того, EVM-MAX и SIMD могут снизить стоимость gas для многих доказательных систем, делая L2 более эффективными. Это также облегчает замену большего числа прекомпиляций на эквивалентный код EVM без существенной потери эффективности.

Абстракция аккаунтов

Какую проблему это решает?

В настоящее время транзакции могут быть проверены только одним способом: с помощью подписи ECDSA. Изначально абстракция аккаунтов была задумана для преодоления этого ограничения, позволяя логике проверки аккаунта быть произвольным кодом EVM. Это открывает ряд возможностей:

• Переход на квантово-устойчивую криптографию
• Ротация старых ключей (широко признанная как рекомендуемая практика безопасности)
• Мультиподписи и кошельки с социальным восстановлением
• Использование одного ключа для операций с низкой стоимостью и другого (или набора ключей) для операций с высокой стоимостью

Позволяет протоколам приватности работать без релеев, значительно снижая их сложность и устраняя критическую центральную точку зависимости

С 2015 года, когда была предложена абстракция аккаунтов, её цели расширились и включают множество «удобных» функций, например, возможность для аккаунта, у которого нет ETH, но есть ERC20, оплачивать gas с помощью ERC20. Вот сводная диаграмма этих целей:

MPC (многосторонние вычисления) — это технология, существующая уже 40 лет, позволяющая разделить ключ на несколько частей и хранить их на разных устройствах, используя криптографию для создания подписи без прямого объединения частей ключа.

EIP-7702 — это предложение, планируемое к внедрению в следующем хардфорке. EIP-7702 — результат растущего понимания необходимости предоставить удобство абстракции аккаунтов всем пользователям (включая EOA), чтобы в краткосрочной перспективе улучшить пользовательский опыт и избежать разделения экосистемы.

Работа началась с EIP-3074 и в итоге привела к EIP-7702. EIP-7702 предоставляет «удобные функции» абстракции аккаунтов всем пользователям, включая сегодняшних EOA (внешне управляемые аккаунты, контролируемые подписями ECDSA).

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

Что это такое и как работает?

Суть абстракции аккаунтов проста: разрешить смарт-контрактам инициировать транзакции, а не только EOA. Вся сложность заключается в реализации этого способа, дружественного к децентрализованной сети, и в защите от атак типа отказ в обслуживании (DoS).

Типичная ключевая проблема — множественный сбой:

Если у 1000 аккаунтов функция проверки зависит от одного значения S, и текущее значение S делает все транзакции в мемпуле валидными, то одна транзакция, изменяющая S, может сделать все остальные транзакции в мемпуле невалидными. Это позволяет атакующему с минимальными затратами отправлять в мемпул мусорные транзакции, перегружая ресурсы узлов сети.

После многих лет работы, направленной на расширение функциональности при ограничении риска DoS, был найден способ реализовать «идеальную абстракцию аккаунтов»: ERC-4337.

ERC-4337 работает, разделяя обработку пользовательских операций на два этапа: верификация и исполнение. Сначала обрабатываются все верификации, затем — все исполнения. В мемпуле принимаются только те пользовательские операции, чья верификация затрагивает только собственный аккаунт и не читает переменные окружения. Это предотвращает множественные сбои. Кроме того, на шаг верификации накладываются строгие лимиты по gas.

ERC-4337 был разработан как дополнительный стандарт протокола (ERC), потому что в то время разработчики клиентов Ethereum были сосредоточены на Merge и не имели ресурсов для других функций. Поэтому ERC-4337 использует объекты, называемые пользовательскими операциями, а не обычные транзакции. Однако недавно стало понятно, что хотя бы часть этого нужно записать в сам протокол.

Две ключевые причины:

1. Встроенная неэффективность EntryPoint как контракта: фиксированные накладные расходы около 100 000 gas на каждый бандл и дополнительные тысячи gas на каждую пользовательскую операцию.
2. Необходимость передачи свойств Ethereum: например, гарантии включения, предоставляемые inclusion lists, должны быть доступны пользователям абстракции аккаунтов.

Кроме того, ERC-4337 расширяет два функционала:

• Paymasters: функция, позволяющая одному аккаунту оплачивать комиссии за другой. Это нарушает правило, что на этапе верификации можно обращаться только к аккаунту-отправителю, поэтому введена специальная обработка для обеспечения безопасности механизма paymaster.
• Aggregators: поддержка агрегирования подписей, например, BLS-агрегация или агрегация на основе SNARK. Это необходимо для максимальной эффективности данных на Rollup.

Ссылки на существующие исследования

• Доклад об истории абстракции аккаунтов:
• ERC-4337:
• EIP-7702:
• Код BLSWallet (использует функцию агрегации):
• EIP-7562 (абстракция аккаунтов на уровне протокола):
• EIP-7701 (абстракция аккаунтов на уровне протокола на основе EOF):

Оставшаяся работа и компромиссы

В настоящее время основная задача — полностью внедрить абстракцию аккаунтов в протокол. Недавно популярным стал EIP-7701, реализующий абстракцию аккаунтов поверх EOF. Аккаунт может иметь отдельную часть кода для верификации; если она задана, этот код будет выполняться на этапе верификации транзакций от этого аккаунта.

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

1. Включение EIP-4337 как части протокола
2. Новый тип EOA, где алгоритм подписи — это выполнение кода EVM

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

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

Главный компромисс — «быстро внедрить менее универсальное решение» против «ждать дольше ради более идеального решения». Идеальным может быть гибридный подход: быстрее внедрить часть кейсов и оставить время для изучения остальных. Другой вариант — сначала развернуть более амбициозную версию абстракции аккаунтов на L2. Однако для этого L2-команды должны быть уверены в предложении и в том, что L1 и/или другие L2 смогут в будущем внедрить совместимое решение.

Ещё один важный кейс — аккаунты для хранения ключей, которые хранят состояние на L1 или выделенном L2, но могут использоваться на L1 и любом совместимом L2. Для этого, возможно, потребуется поддержка опкодов вроде L1SLOAD или REMOTESTATICCALL на L2, а также поддержка этих операций в реализации абстракции аккаунтов на L2.

Как это взаимодействует с другими частями дорожной карты?

Inclusion lists должны поддерживать транзакции абстракции аккаунтов. На практике требования inclusion lists и децентрализованного мемпула очень похожи, хотя для inclusion lists гибкости больше. Кроме того, реализация абстракции аккаунтов должна быть максимально согласована между L1 и L2. Если в будущем большинство пользователей будут использовать key storage Rollup, дизайн абстракции аккаунтов должен это учитывать.

Улучшения EIP-1559

Какую проблему это решает?

EIP-1559 был активирован в Ethereum в 2021 году и значительно улучшил среднее время включения блока.

Время ожидания

Однако текущая реализация EIP-1559 несовершенна по нескольким причинам:

1. Формула слегка ошибочна: она нацелена не на 50% заполнения блока, а на 50–53%, в зависимости от дисперсии (это связано с неравенством между средним арифметическим и средним геометрическим).
2. В экстремальных случаях корректировка происходит недостаточно быстро.

Формула для blobs (EIP-4844) была специально разработана для решения первой проблемы и в целом проще. Однако ни EIP-1559, ни EIP-4844 не решают вторую проблему. В результате сейчас используется смешанная система с двумя разными механизмами, и существует мнение, что со временем оба требуют доработки.

Кроме того, есть и другие слабые места ценообразования ресурсов Ethereum, не связанные с EIP-1559, которые можно решить, скорректировав EIP-1559. Одна из главных проблем — разница между средним и худшим случаем: цены на ресурсы в Ethereum должны быть установлены так, чтобы справляться с худшим случаем (полный блок расходует весь ресурс), но фактическое среднее использование намного ниже, что приводит к неэффективности.

Что такое многомерный gas и как он работает?

Решение этих неэффективностей — многомерный gas: разные цены и лимиты для разных ресурсов. Эта концепция технически независима от EIP-1559, но наличие EIP-1559 облегчает её реализацию. Без EIP-1559 оптимальная упаковка блока с несколькими ограничениями по ресурсам — сложная задача многомерного рюкзака. С EIP-1559 большинство блоков не достигают лимита ни по одному ресурсу, поэтому простого алгоритма «принимать любую транзакцию с достаточной оплатой» достаточно.

Сейчас у нас уже есть многомерный gas для исполнения и data blobs; в принципе, это можно расширить на другие измерения: calldata (данные транзакции), чтение/запись состояния и рост размера состояния.

EIP-7706 вводит новое измерение gas, специально для calldata. Он также унифицирует три типа gas в одну (EIP-4844-стильную) схему, упрощая механизм многомерного gas и устраняя математические недостатки EIP-1559. EIP-7623 — более точное решение, строго ограничивающее максимальный calldata без введения нового измерения.

Дальнейшее направление исследований — решить проблему скорости обновления, найти более быструю формулу расчёта базовой комиссии, сохраняя ключевые инварианты механизма EIP-4844 (т.е. в долгосрочной перспективе среднее использование стремится к целевому значению).

Ссылки на существующие исследования

• FAQ по EIP-1559: 
• Эмпирический анализ EIP-1559: 
• Предложения по ускоренной корректировке: 
• Раздел о механизме базовой комиссии в FAQ по EIP-4844: 
• EIP-7706: 
• EIP-7623: 
• Многомерный gas: 

Оставшаяся работа и компромиссы

Два главных компромисса многомерного gas:

1. Усложнение протокола: внедрение многомерного gas делает протокол сложнее.
2. Усложнение оптимального алгоритма заполнения блока: чтобы блок был максимально заполнен, требуется более сложный алгоритм.

Для calldata сложность протокола относительно невелика, но для внутренних измерений gas в EVM (например, чтение и запись в хранилище) сложность возрастает. Проблема в том, что не только пользователи задают лимиты gas, но и контракты при вызове других контрактов. Сейчас они могут задавать лимиты только по одному измерению.

Простое решение — сделать многомерный gas доступным только внутри EOF, поскольку EOF не позволяет контрактам задавать лимиты gas при вызове других контрактов. Не-EOF контракты при выполнении операций со storage должны платить за все типы gas (например, если SLOAD занимает 0,03% лимита gas на доступ к storage в блоке, не-EOF пользователи тоже платят 0,03% лимита на исполнение).

Дальнейшие исследования многомерного gas помогут лучше понять эти компромиссы и найти оптимальный баланс.

Как это взаимодействует с другими частями дорожной карты?

Успешная реализация многомерного gas может значительно снизить использование ресурсов в худших случаях, уменьшив давление на оптимизацию производительности для поддержки, например, бинарных деревьев на основе STARKed-хэшей. Установка чёткой цели по росту размера состояния облегчит планирование и оценку требований для разработчиков клиентов в будущем.

Как уже отмечалось, наличие EOF упрощает внедрение более экстремальных версий многомерного gas благодаря свойству невидимости gas.

Проверяемые функции задержки (VDF)

Какую проблему это решает?

В настоящее время Ethereum использует случайность на основе RANDAO для выбора предложителя блока. Случайность RANDAO работает так: каждый предложитель раскрывает заранее зафиксированный секрет, и каждый раскрытый секрет смешивается в итоговую случайность.

У каждого предложителя есть «1 бит контроля»: он может изменить случайность, просто не появившись (за определённую цену). Такой способ приемлем для выбора предложителя, потому что шанс получить два новых предложения вместо одного крайне мал. Но для on-chain приложений, которым нужна случайность, это не идеально. В идеале нужен более надёжный источник случайности.

Что такое VDF и как она работает?

Проверяемая функция задержки — это функция, которую можно вычислить только последовательно, без ускорения за счёт параллелизма. Простой пример — повторяющийся хэш: for i in range(10**9): x = hash(x). Результат можно использовать как случайное значение, предоставив SNARK-доказательство корректности вычисления.

Идея в том, чтобы выбирать входные данные, доступные к моменту времени T, а результат становится известен только после полного вычисления, то есть после T. Поскольку любой может выполнить вычисление, скрыть результат невозможно, а значит, и манипулировать им нельзя.

Главный риск VDF — неожиданная оптимизация: кто-то находит способ вычислять функцию быстрее, чем ожидалось, и может манипулировать раскрытием информации во времени T.

Неожиданная оптимизация возможна двумя способами:

1. Аппаратное ускорение: кто-то создаёт ASIC, вычисляющий цикл быстрее, чем существующее оборудование.
2. Неожиданный параллелизм: кто-то находит способ ускорить функцию за счёт параллелизма, даже если это требует в 100 раз больше ресурсов.

Задача успешной VDF — избежать обеих проблем и при этом оставаться практически эффективной (например, для хэш-методов проблема — необходимость тяжёлого оборудования для SNARK-доказательств в реальном времени). Аппаратное ускорение обычно решается созданием и распространением почти оптимального ASIC для VDF некоммерческим участником.

Ссылки на существующие исследования

• Сайт исследований VDF: 
• Размышления об атаках на VDF в Ethereum, 2018: 
• Атаки на предлагаемую VDF MinRoot: 

Оставшаяся работа и компромиссы

В настоящее время не существует конструкции VDF, полностью удовлетворяющей всем требованиям исследователей Ethereum. Необходимо провести дополнительные исследования для поиска такой функции. Если она будет найдена, главный компромисс — стоит ли её внедрять: функциональность против сложности протокола и рисков безопасности.

Если мы считаем VDF безопасной, но на деле она окажется небезопасной, то, в зависимости от реализации, безопасность снизится до уровня RANDAO (1 бит контроля на атакующего) или чуть хуже. То есть даже если VDF не сработает, протокол не будет разрушен, но пострадают приложения или новые функции, сильно зависящие от неё.

Как это взаимодействует с другими частями дорожной карты?

VDF — относительно автономная часть протокола Ethereum. Помимо повышения безопасности выбора предложителя, она может использоваться в (i) on-chain приложениях, зависящих от случайности, и (ii) в зашифрованных мемпулах, хотя для последних требуется дополнительное криптографическое открытие, которого пока не произошло.

Важный момент: из-за неопределённости аппаратного обеспечения между генерацией и использованием VDF-выхода будет некоторый «запас» по времени. Это означает, что информация будет доступна за несколько блоков до необходимости. Это приемлемая цена, но её стоит учитывать при проектировании single-slot finality или выбора комитетов.

Обфускация и одноразовые подписи: далёкое будущее криптографии

Какую проблему это решает?

Одна из самых известных статей Nick Szabo — его работа 1997 года о «Божественном протоколе». В ней он отмечает, что многие многопользовательские приложения зависят от «доверенного третьего лица» для управления взаимодействием. По его мнению, задача криптографии — создать симулированное доверенное третье лицо, выполняющее ту же работу, но без необходимости доверять конкретному участнику.

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

Если приватность важна, то до недавнего времени мы могли разрабатывать только отдельные протоколы для конкретных задач: цифровые подписи для базовой аутентификации, кольцевые и связываемые кольцевые подписи для анонимности, криптографию на основе идентификаторов для удобного шифрования при определённых предположениях о доверии, слепые подписи для Chaumian e-cash и т.д. Такой подход требует много работы для каждого нового приложения.

В 2010-х мы впервые увидели другой, более мощный подход — программируемую криптографию. Вместо создания нового протокола для каждого приложения мы можем использовать мощные универсальные протоколы — в частности, ZK-SNARKs — чтобы добавить криптографические гарантии для любой программы.

ZK-SNARKs позволяют пользователю доказывать любые утверждения о своих данных, причём доказательство (i) легко проверяется и (ii) не раскрывает ничего, кроме самого утверждения. Это огромный шаг вперёд для приватности и масштабируемости — я сравниваю это с влиянием трансформеров в искусственном интеллекте. Тысячи человеко-лет работы над специализированными приложениями внезапно заменяются универсальным решением, способным решать неожиданные задачи.

Однако ZK-SNARKs — лишь первая из трёх чрезвычайно мощных универсальных примитивов. Эти протоколы настолько сильны, что напоминают мне набор очень мощных карт из Yu-Gi-Oh! — карточной игры и аниме, в которые я играл в детстве: Египетские божества.

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

Что такое ZK-SNARKs и как они работают?

ZK-SNARKs — один из трёх протоколов, который уже достаточно зрелый. За последние пять лет скорость генерации доказательств и удобство для разработчиков значительно выросли, и ZK-SNARKs стали основой стратегии масштабируемости и приватности Ethereum. Но у ZK-SNARKs есть важное ограничение: чтобы доказать что-то о данных, нужно их знать. В каждом приложении на ZK-SNARKs состояние должно иметь уникального «владельца», который должен присутствовать для разрешения чтения или записи этого состояния.

Второй протокол, лишённый этого ограничения, — полностью гомоморфное шифрование (FHE), позволяющее выполнять любые вычисления над зашифрованными данными, не раскрывая их. Это позволяет выполнять вычисления над пользовательскими данными в их интересах, сохраняя приватность данных и алгоритма.

Это также позволяет расширить такие системы голосования, как MACI, почти до идеальных гарантий безопасности и приватности. Долгое время FHE считалось слишком неэффективным для практического использования, но теперь оно стало достаточно быстрым для реальных приложений.

Cursive — приложение, использующее двухсторонние вычисления и FHE для приватного поиска общих интересов.

Однако у FHE есть ограничение: для любой технологии на FHE кто-то должен владеть ключом расшифровки. Это может быть распределённая схема M-of-N, можно использовать доверенные вычислительные среды (TEE) как второй уровень защиты, но это всё равно ограничение.

Третий протокол — ещё более мощный, чем комбинация первых двух: indistinguishability obfuscation (iO, неразличимая обфускация). Эта технология ещё далека от зрелости, но с 2020 года у нас есть теоретически рабочие протоколы на стандартных предположениях безопасности, и недавно начались попытки реализации.

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

Единственное, чего не может iO-программа — предотвратить своё копирование. Но для этого есть ещё более мощная технология, правда, требующая наличия квантовых компьютеров у всех: квантовые одноразовые подписи (quantum one-shot signatures).

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

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

Сначала предположим, что результаты голосования публикуются в блокчейне. Это даёт нам публичную верифицируемость (любой может проверить правильность результата, включая правила подсчёта и отбора) и устойчивость к цензуре (голосовать нельзя запретить). Но приватности нет.

Добавляем ZK-SNARKs — теперь есть приватность: каждый голос анонимен, при этом гарантируется, что голосовать могут только авторизованные избиратели и только один раз.

Далее внедряем механизм MACI: голоса шифруются на ключ центрального сервера, который проводит подсчёт, удаляет дубликаты и публикует ZK-SNARK-доказательство результата. Это сохраняет предыдущие гарантии (даже если сервер мошенничает!), но если сервер честен, появляется гарантия устойчивости к принуждению: пользователь не может доказать, как он проголосовал, даже если захочет. Потому что хотя пользователь может доказать свой голос, он не может доказать, что не проголосовал противоположным образом. Это предотвращает взяточничество и другие атаки.

Подсчёт голосов проводится с помощью FHE, затем выполняется пороговая расшифровка N/2-of-N. Это повышает устойчивость к принуждению до N/2-of-N вместо 1-of-1.

Обфусцируем программу подсчёта и разрешим ей выводить результат только при наличии авторизации — например, доказательства консенсуса блокчейна, proof-of-work или их комбинации. Это почти идеально защищает от принуждения: для атаки на консенсус блокчейна потребуется сговор 51% валидаторов; для proof-of-work даже полный сговор не позволит эффективно пересчитывать результаты для разных подмножеств избирателей. Можно даже добавить небольшую случайную корректировку итогового результата, чтобы ещё сильнее затруднить извлечение поведения отдельного избирателя.

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

iO также поддерживает другие мощные приложения. Например:

1. DAO, on-chain аукционы и другие приложения с произвольным внутренним приватным состоянием.
2. По-настоящему универсальная trusted setup: кто-то создаёт обфусцированную программу с ключом, запускает любую программу и предоставляет вывод, используя hash(key, program) как вход. Любой может вложить программу 3 в себя, комбинируя ключи, и расширить setup. Это позволяет генерировать trusted setup для любого протокола с 1-of-N схемой.
3. Верификация ZK-SNARKs только одной подписью: реализуется просто — создаётся trusted environment, где обфусцированная программа подписывает сообщение ключом только при наличии валидного ZK-SNARK.
4. Зашифрованный мемпул: зашифрованные транзакции, которые можно расшифровать только после определённого события на блокчейне, например, успешного выполнения VDF.

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

Если эти примитивы станут достаточно эффективными, большинство приложений в мире можно будет реализовать децентрализованно. Основным узким местом останется верификация корректности реализации.

Вот некоторые ссылки на существующие исследования:

• Протокол indistinguishability obfuscation (2021): 
• Как обфускация может помочь Ethereum: 
• Первая известная конструкция одноразовой подписи: 
• Попытка реализации обфускации (1): 
• Попытка реализации обфускации (2): 

Какая работа ещё предстоит и каковы компромиссы?

Работы ещё очень много: indistinguishability obfuscation пока крайне незрелая, кандидаты работают настолько медленно (а иногда и медленнее), что их нельзя использовать на практике. Теоретически iO работает за полиномиальное время, но на практике это может быть дольше жизни Вселенной. Недавние протоколы ускорились, но всё равно слишком медленны для обычного использования: один из реализаторов оценил время работы в год.

Квантовых компьютеров пока не существует: все конструкции, которые вы видите в интернете, либо прототипы, не способные работать с числами больше 4 бит, либо вообще не являются настоящими квантовыми компьютерами, хотя могут содержать квантовые компоненты, но не способны выполнять значимые алгоритмы вроде Shor или Grover. Недавно появились признаки, что «настоящие» квантовые компьютеры не так уж далеки. Однако даже если они появятся скоро, обычным людям придётся ждать десятилетия, прежде чем они смогут использовать квантовые компьютеры на своих ноутбуках или смартфонах, чтобы в один день мощные организации смогли взломать эллиптическую криптографию.

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

Как это взаимодействует с другими частями дорожной карты?

Чрезвычайно мощная криптография может полностью изменить правила игры, например:

1. Если верификация ZK-SNARKs станет такой же простой, как подпись, агрегирующие протоколы могут больше не понадобиться — можно будет проверять их прямо на цепочке.
2. Одноразовые подписи могут сделать протоколы proof-of-stake более безопасными.
3. Многие сложные протоколы приватности можно будет заменить одним приватным EVM.
4. Зашифрованный мемпул станет проще реализовать.

Сначала преимущества появятся на уровне приложений, поскольку L1 Ethereum по своей сути должен оставаться консервативным в плане предположений безопасности. Однако даже только применение на уровне приложений может быть революционным, как это было с появлением ZK-SNARKs.