Будущее Эфириума

Виталик Бутерин в своем блоге опубликовал шесть постов, посвященных идеям по улучшению Эфириума. Каждая его статья — это часть дорожной карты Эфириума, которая была опубликована Виталиком в 2023 году. Цель этого исследования – рассказать про основные идеи описанные Виталиком и вместе с вами посмотреть на них глазами простого пользователя сети Эфириум или ходлера ETH.

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

Merge – Ускорение L1

В статье The Merge, которая описывает идеи о том, как ещё можно технически улучшить Proof-of-Stake, Виталик начинает с проблемы долгой финализации блока. Перед тем, как в нее погрузиться, давайте кратко рассмотрим, как сейчас выглядит процесс подтверждения блока в Эфириум, а затем посмотрим, как планируется его улучшить. 

Финализация за один слот

Сейчас процесс добавления новых блоков можно разделить на три этапа:

1. Создание блока. Каждый слот (условная единица времени в Эфириум составляющая 12 секунд) в сети выбирается валидатор, который формирует транзакции из мемпула в блок.

2. Аттестация и обоснование. Собирается комитет валидаторов, которые проверяют правильность блока. Для прохождения аттестации блок должен собрать ⅔ подписей валидаторов. Блок проходит обоснование в течение минимум двух эпох (эпоха - 32 слота, ~6.4 минуты). 

3. Финализация. Только после получения результатов обоснования, блок считается финализированным и становится неизменяемым.

Среднее время финализации блока составляет 15 минут и требуется 32 ETH для того, чтобы стать валидатором в сети. Виталик объясняет такую архитектуру, стремлением найти компромисс между размером стейкинга, временем финализации и нагрузкой на узлы сети. Если начать решать два первых вопроса, то мы столкнемся с тем, что они противоречат цели минимизации нагрузки на сеть. Здесь нам на помощь приходит концепт Single-slot finality. 

Вот три варианта того, как Single-slot finality может решить задачу долгой финализации, не создавая большой нагрузки на сеть: 

1. Brute force. Использование криптографического протокола ZK-SNARKs для быстрой обработки подписей в течение эпохи.

2. Orbit committees. Система с улучшенным механизмом формирования комитета валидаторов. 

3. Two-tiered staking. Создание двух классов стейкеров: с разными требованиями к депозиту и обязанностями в сети.

Какой из подходов лучше? По словам Виталика Brute force – технически сложный подход, Orbit committees значительно уменьшают стоимость атаки на сеть, а Two-tiered staking увеличит риски централизации сети. Пока не понятно какой именно подход к созданию Single-slot finality будет реализован в Эфириуме. 

Случайный выбор валидатора

Знаете, кто будет создавать следующий блок в сети? Для нас с вами эта информация не так важна, однако валидаторам, конкурирующим в сети необходимо знать правила игры. Сейчас в Эфириум алгоритм RANDAO случайным образом определяет валидаторов следующих блоков за две эпохи. То есть если бы вас выбрали, то вы узнали бы об этом за 12 минут до того, как вам нужно было создавать блок.

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

Чтобы избежать вероятности таких DoS-атак Виталик предлагает добавить в Эфириум криптографический протокол Single secret leader election (SSLE). Это позволит скрыть информацию о следующем валидаторе, до момента создания блока.

Суть протокола заключается в том, что: 

• Создается «слепой» идентификатор для каждого валидатора («blinded» validator ID).

• Валидаторы могут повторно перемешивать и менять эти ID.

• Никто другой не знает, какому валидатору соответствует выбранный ID.

• В каждом слоте выбирается один ID для создания блока.

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

Быстрое подтверждение транзакций 

Как мы уже говорили, время создания одного блока — это один слот (12 секунд). Уменьшение времени подтверждения транзакции позволило бы:

• Улучшить пользовательский опыт в L1 и L2
• Сделать DeFi более эффективным
• Увеличить децентрализацию и безопасность L2

Есть два подхода к тому, как ускорить подтверждение транзакций:

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

2. Предварительные подтверждения внутри слота (pre-confirmations). В таком случае валидатор может заранее завершить создание блока. 

Основная проблема увеличения TPS – это повышение требований к сетевой задержке у валидаторов. Если уменьшить время подтверждения до 4 секунд, то задержка должна быть примерно в 2 секунды. Такие изменения приведут к централизации из-за того, что многие валидаторы не смогут обеспечить такой уровень соединения.

Квантовая устойчивость

В конце статьи Виталик кратко говорит о том, что каждый протокол и алгоритм появляющийся в Эфириуме будет в первую очередь проверяться на квантовую устойчивость. Рынок предсказывает, что квантовые компьютеры начнут взламывать криптографию в 2030 году, поэтому многим существующим системам пора искать  квантово-устойчивую замену (не применять криптографию на основе эллиптических кривых). 

Surge — Масштабируемость

Во второй статье Виталик пишет о проблеме масштабирования Эфириума через L2 сети и увеличение пропускной способности L1. Виталик говорит о том, что дилемма масштабируемости (трилемма блокчейна) это не доказанная математическая модель. Развитие zk-SNARKs и архитектуры Plasma (поговорим об этом далее) позволяют выйти за её рамки. 

Сжатие и доступность данных 

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

Чтобы рассмотреть их подробнее, давай вспомним, как сейчас в L1 хранятся транзакции из роллапов. В марте 2024 прошло обновление Dencun, после которого в Эфириуме появились Блобсы. Блоб (Binary Large Object) — это новая структура хранения данных, которая значительно уменьшила стоимость транзакций в L2.

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

Виталик предлагает улучшить работу блобов, добавив в основную сеть подход по организации проверки доступности данных PeerDAS, который позволит увеличить TPS L2 до 58,000 (сейчас это значение меньше тысячи). Запуск PeerDAS позволит ускорить процесс обработки транзакций из L2 узлами Эфириума.

Вот как это планируется реализовать:

• Каждый блоб будет разбиваться на фрагменты (shares). 

• Для восстановления всего блоба, достаточно будет половины фрагментов. 

• Узлы сети будут обрабатывать отдельные фрагменты «собирая» из них блоб. 

PeerDAS уже готов к развертыванию в Эфириум и после этого планируется постепенно увеличивать количество блобов, что тем самым, увеличит TPS роллапов.  

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

Но не всё потеряно, и развитие ERC-4337 (Account abstraction) позволит приблизиться к этому обновлению. Абстракция аккаунта позволяет создать кошелек, который является смарт-контрактом и пользователь может оплатить газ в любых токенах. ERC-4337 позволил также обрабатывать транзакции пакетами. Специальный узел сети (bundler) собирает много операций в одну. В такой транзакции операции группируются, повторяющиеся адреса указываются один раз и объединяются подписи. В итоге пакетная обработка может стать основным методом, уменьшения веса транзакций в роллапах. Недавно в Ethereum, Arbitrum и Optimism был запущен Shared Mempool – это делает пакетную обработку эффективнее и децентрализованные.

Что произойдет, если L2 сети достигнут масштабируемости, а L1 будет обрабатывать только небольшой объем транзакций? Это приведёт к тому, что ETH потеряет свою ценность и меньше проектов захотят развернуть свой L2. Есть несколько вариантов для решения этой проблемы — увеличить лимит газа или создать несколько копий основной сети. А для предотвращения такого сценария нужно определить, что какие задачи должен выполнять L1, а что перейдет в L2 сети. Важен баланс между масштабируемостью и децентрализацией.

Как работает Plasma?

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

Сначала важно уточнить, что Plasma – это другой вид L2 сети отличающийся от роллапа. Основное отличие состоит в том, что данные о транзакциях хранятся вне основной цепочки. Не будем останавливаться на технических деталях и рассмотрим простой сценарий обработки транзакций в Plasma: оператор не публикует данные о транзакциях в блоке,а отправляют только криптографическое доказательство выполненных операций. Каждый пользователь, чья транзакция попала в блок, также получает криптографическое доказательство того, что блок справедлив. Также в сети есть специальный механизм, проверяющий полученное доказательство.

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

Три ступени безопасности L2

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

Для того, чтобы разобраться, а как роллапам поднять уровень безопасности, Виталик вводит три ступени безопасности роллапов:

• Ступень 0 — валидация блоков в цепочке осуществляется централизовано; 

• Ступень 1 — в сети есть система доказательств, гарантирующая, что принимаются только валидные транзакции. Совет может повлиять на систему, но для этого нужно набрать ¾ голосов от членов совета. Также больше  четверти участников совета должно быть из главной команды проекта, так система принятия решений станет справедливее. Виталик отмечает, что стадии 2 удалось достигнуть сетям Optimism и Arbitrum, но многие роллапы далеки от неё. 

• Ступень 2 – система доказательств становится полностью автономной, а совет безопасности может вмешаться только при явных ошибках. Основная идея ступени 2 состоит в том, чтобы совет не диктовал свое решение, а, в случае спора, принималось одно из предложенных системой доказательств. 

Как достичь ступени 2? Для того, чтобы сделать систему доказательств автономной мы должны убедиться, что она действительно надежна. Сделать это можно используя математические методы доказательства или создать несколько уровней проверки, которые будут дополнять друг друга. Оба этих решения находятся в разработке.

Создание единой экосистемы

Чтобы перевести ETH из одной L2 сети в другую, мы должны будем воспользоваться централизованным мостом и подключаться к RPC централизованных провайдеров. Виталик, как и все мы, хотел бы чтобы Эфириум и L2 стали единой экосистемой в которой отправка кроссчейн транзакций станет такой же простой как обычный перевод.

Как мы можем улучшить взаимодействие EVM сетей? Вот основные варианты:

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

2. Открытый протокол для кроссчейн операций. Сейчас каждый мост использует свою систему обмена, однако необходим единый протокол обмена сообщениями между L2. Виталик даже рассматривает идею создания отдельного роллапа, который будет выполнять только эту задачу. 

3. Легкие клиенты. Чтобы не доверять RPC от Infura мы можем получать состояния сети Эфириум не запуская полную ноду, а установив Helios (проект от компании a16z crypto). Но для L2 таких решений пока не создано и их только предстоит реализовать.

4. Хранение ключей (Keystore wallets). Если вы захотите поменять ключи, которые управляют вашим мультисиг кошельком Gnosis Safe, то вам потребуется сделать это во всех L2 сетях. Это дорого и долго, но систему можно упростить если научить L2 считывать данные из основной сети и обновлять их.

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

Scourge — Новый шаг к децентрализации

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

Разделение прав между валидаторами

Когда валидатор получает право на создание блока, он, как правило, передает его другим участникам сети — строителям, из-за того, что эта задача требует затрат ресурсов. Такое делегирование приводит к рискам того, что строители могут задерживать транзакции и проводить сендвич-атаки.

Решить эту проблему можно, если ограничить задачи строителей и передать их часть валидаторам. Как это планируется реализовать: 

1. Валидатор составляет список транзакций, которые войдут в блок (сейчас это делает строитель). 

2. Строитель создает блок, в котором он может изменить порядок транзакций, но удалить или добавить транзакцию не может.  

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

Обновление системы стейкинга 

Сейчас около 30% всего ETH находится в стейкинге, а что будет если этот показатель увеличится? Это круто — можем сказать мы — инвесторы больше верят в ETH и обращение уменьшилось. Однако если посмотреть на это с точки зрения безопасности, мы обнаружим такие риски:

1. Большинство ETH будут делегированы централизованным операторам.

2. Один протокол ликвидного стейкинга может захватить большую часть рынка LST и забрать «сетевой эффект» Эфира себе). 

3. Примерно 1M ETH будет выпускаться в год на награды для стейкеров. 

4. Штрафы недобросовестным стейкерам станут не эффективны. 

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

Виталик также предлагает и более простой подход, который позволит решить и проблему с эмиссией ETH — уменьшение наград за стейкинг. Чем больше ETH будет заблокировано, тем меньше будет общий доход, а это будет снижать стимулы стейкать ещё больше.

Что касается проблемы доминирования LST токенов, то здесь предлагается поощрять создание единого децентрализованного токена, уменьшить стимулы для массового участия в LST протоколах. 

Прикладной уровень децентрализации

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

1. Групповой стейкинг. Решение от компании Obol позволяет нескольким людям запустить свой узел в сети.

2. Эйрдропы. Starknet раздал награды индивидуальным стейкерам. 

3. Специальное оборудование. Устройства от компании Dappnode позволяют запустить свой узел также просто, как подключить домашний интернет. 

Verge — Верификация блокчейна через смартфон

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

Альтернатива деревьям Меркла

Сейчас для верификации блоков в Эфириуме используется Дерево Меркла-Патриции (Merkle Patricia Trie). Если вы не знакомы с принципом работы деревьев Меркла, важно знать, что это алгоритм объединяющий хэши данных о транзакциях в один корневой хэш блока.  

Представьте, что у вас есть шкаф в котором 10 полок и на каждой полке 10 маленьких ящиков. Чтобы доказать, что в ящике на 10 полке лежит именно то, что вы ищете, вам нужно проверить все ящики начиная снизу. Такой объем задач нагружает узел сети. Поэтому Виталик предлагает нам выбрать один из двух новых подходов к проверке блоков:

1. Деревья Verkle. Представьте тот же шкаф, только теперь вы знаете, что вам нужно проверять только первый ящик на каждой полке. Таким образом доказательство происходит быстрее и занимает меньше места. 

2. Деревья STARKed. Вы остановились перед шкафом вспоминаете, на какую полку вы убрали, то что ищете. Размышления занимают у вас больше времени, чем проверка первого ящика на каждой полке, однако итоговая работа, выполненная вами, меньше, ведь вы сразу открываете нужный ящик. 

Деревья Verkle создают сжатые доказательства на каждом уровне, а STARKed создают одно доказательство о всей системе. Деревья Verkle основаны на криптографии эллиптических кривых из-за чего уязвимы перед квантовым компьютером, хотя их логика работы больше готова к запуску. STARKed более устойчивы к квантовым вычислениям, но долго формируют доказательство, а это может быть неэффективно, когда пользователи отправляют много простых запросов в блокчейн. Пока непонятно какая идея будет реализована. На доработку и внедрение этих технологий уйдет нескольких лет. 

Проверка EVM на уровне консенсуса

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

 Если упростить алгоритм работы EVM то мы получим три основные стадии:

1. Начальное состояние. 

2. Получение блока с данными. 

3. Обновление состояния.

Легкие клиенты должны получать только хэши, проверяющие новое состояние. И такая система уже используется, например в zkSync. Но реализовать её в L1 гораздо сложнее. В разработке доказательств консенсуса тоже скрыто много проблем, одна из них это объем данных о состоянии валидаторов, который требует миллиона хэшей в эпоху. Решением этой задачи станет внедрение single slot finality, о котором мы говорили в начале статьи. 

Purge — Как очистить Эфириум?

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

Создание торрент-сети

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

В Эфириуме уже сегодня данные не хранятся на узлах консенсуса вечно (consensus client), после шести месяцев они начинают храниться на архивных узлах (archive node). Однако для лучшего решения проблемы загруженности узлов Виталик предлагает использовать модель работы торрент-сетей, в которой каждый узел будет отвечать за хранение определенной части информации. Такой подход не повлияет на надежность хранения информации, ведь если упростить создание торрент-узлов, то их количество может превысить 100 тысяч. Если каждый узел будет хранить 10% истории и при этом каждый фрагмент данных будет воссоздан 10,000 раз - то это будет сопоставимо с сетью из 10,000 узлов, где каждый узел хранит всё.

Для реализации этой идеи можно внедрить в Эфириум уже существующую библиотеку торрентов или запустить решение Portal. Вместе с этим планируется запуск EIP-4444, который уменьшит время хранения данных на узлах сети. Без реализации этой идеи не получится приблизиться к тому, чтобы пользователи легко проводить верификацию сети, о чем мы говорили в прошлом разделе.

Проблема роста состояния

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

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

1. Оно не должно требовать дополнительных вычислений. 

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

3. Не должно усложнять разработку и нарушать работу существующих решений. 

Есть три решения, которые согласуются с этими целями. Самое простое — это создание системы, в которой будет отсутствовать состояние (statelessness). Точнее, его будут хранить только специальные узлы, а все остальные узлы смогут работать без данных о состоянии. Однако реализовав это можно столкнуться с централизацией, а также будет важен вопрос доверия к узлам, хранящим состояние. Но ключевой недостаток этого предложения в том, что объем состояния в сети будет продолжать расти.

Следующее решение – это частичное чтение состояний. Рассмотрим его работу через аналогию. Представьте, что вы владелец небольшого отеля. Когда вам звонят для бронирования, вы знаете какие комнаты у вас свободны, а какие заняты. Также вы помните в какие номера недавно въезжали, а из каких выезжали. Однако, чтобы узнать, кто живет в определенном номере, вам нужно будет посмотреть в журнал, где вы записываете каждого посетителя. В случае с блокчейном, узлы будут хранить поверхностные данные о состоянии, «помнить о недавних событиях». Для данных, к которым давно не обращались будет устанавливаться «заглушка» позволяющая их воскресить. Если вернуться в ваш отель, то представьте, что вы не храните информацию о всех посетителях за прошлый год, чтобы журнал не был слишком большим, а ведете общую таблицу, где указываете сколько посетителей было за год. Однако, если к вам придёт гость, предоставит прошлогодний чек (доказательство) и попросит скидку, вы будете готовы её предоставить. 

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

• Через определенный период  (например один год) создается новая система состояний (новый журнал) и любое считывание состояния записывается в него. 

• Узлы будут хранить данные о состояниях за два периода (за два года), а более старая информация будет заморожена.

• Для «возрождения» замороженных данных необходимо будет предоставить доказательство, чтобы переписать их. 

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

Лучше — проще

Доступность и безопасность сети можно сохранить только оставляя блокчейн простым. Простой код уменьшает количество ошибок и упрощает жизнь разработчикам. В этой части статьи Виталик описывает те функции, которые можно было бы удалить из блокчейна и те механизмы, которые стоит сделать проще. Не станем подробно их разбирать. Здесь важно отметить, что каждое такое решение будет обсуждаться с сообществом и Виталик замечает, что это будет не быстрый процесс. 

Splurge — Другие важные изменения

До этого каждая часть дорожной карты была посвящена определенной проблеме и описывала варианты её решения. Последняя статья посвящена тем задачам, которые сложно отнести к какой-то категории, но их решение не менее важно.

Первая такая задача – это улучшение EVM за счёт проведения хард-форка, который добавит новую версию кода в EVM. Это предложение называется EOF (EVM Object Format) и нацелено на то, чтобы упростить разработку и снизить затраты на газ.

Следующая задача связана с Абстракцией Аккаунта. ERC-4337 был изначально разработан как внепротокольный стандарт и из-за этого требуется много газа на выполнение пакетов транзакций. Предполагается перенести часть задач по валидации и исполнению транзакций на уровень EVM, что откроет возможности абстракции и для EOA аккаунтов.

Обновить нужно и систему расчёта комиссий, которая работает с 2021, но показывает себя неэффективно (блоки заполняются неравномерно, система не реагирует при резких изменениях количества транзакций). С внедрением EIP-7706 и EIP-7623 предлагается ввести отдельные механизмы изменения газа для разных видов операций. Это позволит сделать систему более гибкой, а цены на газ станут справедливее.

Далекое будущее криптографии

И всё-таки одной из частей статьи мы должны уделить особое внимание, потому что изменения в области криптографии будет определять направления развития Эфириума. Если всё описанное выше, это перспектива двух-трёх лет, то в этой части Виталик готовит нас к будущему через 10-15 лет. Давайте заглянем в него.

Но сначала о прошлом. В 1997 году Nick Szabo написал эссе «The God Protocols», в котором размышлял о том, как создать идеальный протокол, в котором третья сторона способна решить любые споры при этом не получая конфиденциальную информацию о спорщиках. В качестве такой третьей стороны выступает виртуальный компьютер, совмещающий прозрачность, конфиденциальность и доверие.

До недавнего времени мы не умели создавать протоколы способные совместить эти свойства, однако с появлением Programmable Cryptography, которая позволила перенести вычисления на уровень протокола, мы вступили в новую эпоху, которую можно сравнить с переходом от специального оборудования к программируемым компьютерам. В этой новой эпохе у нас есть три технологии, которые позволят приблизиться к созданию идеальной третьей стороны:

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

2. FHE — позволяет выполнять любые вычисления над зашифрованными данными без просмотра самих данных. Если ZK-SNARKs сильно развились за последние пять, то решения на базе FHE только начинают появляться, например Cursive.

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

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

Эфириум к 2030 году 

План развития Эфириума – это не только видение Виталика, но и стремления всех исследователей и разработчиков из Ethereum Foundation. Обновление Beam Chain, представленное Джастином Дрейком на Devcon, – это комплексная концепцией обновления Beacon Chain, включающей идеи, ранее озвученные Виталиком.

«Речь идет о том, чтобы определить конкретную часть этой дорожной карты и ускорить ее выполнение» (Джастин Дрейк о Beam Chain)

Подведем итог. Вот основные технические улучшения, которые ожидают Ethereum в будущем:

• Ускорение финализации и подтверждения транзакций. 

• Квантовая устойчивость. 

• Создание экосистемы, в которой где кроссчейн-транзакции не будут отличаться от обычных переводов;

• Изменение системы стекинга и расчёта газа. 

• Децентрализация за счёт создания торрент-сети, упрощение верификации блокчейна на легких клиентах и решение проблемы роста данных в сети. 

Конечно появление этих технических решения приведет к развитию новых трендов в разработке и создании приложений. Вот несколько, о которых говорят сегодня:

• Будет появляться всё больше L2 решений создаваемых бизнесами и сообществами. Например ENS анонсировали создание своего L2, для запуска мультичейн доменов.  

• Язык программирования Vyper получит больше распространения для создания контрактов в EVM. Об этом говорил Виталик во время выступления на Devcon. 

• Развитие методов шифрования (ZK, FHE, MPC) приведет к созданию новых проектов решающих проблемы приватности и безопасности на разных уровнях. Вот некоторые из них, которые уже есть на рынке: Aztec, Brevis, Ingonyama, Fairblock, Semaphore. 

• Улучшение пользовательского опыта: Account abstraction, Light clients, новые кросс-чейн решения.  

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