Автор оригинала: Виталик Бутерин Оригинальный перевод: Нянь Инь Си Тан, Odaily

С самого начала проекта Ethereum существовала сильная философия, заключающаяся в том, чтобы попытаться сделать ядро ​​​​Ethereum как можно более простым и добиться этого в максимально возможной степени путем создания протоколов поверх него. В блокчейн-пространстве дебаты «построить на L1» или «фокусироваться на L2» часто связаны в первую очередь с масштабированием, но на самом деле существуют схожие проблемы с удовлетворением потребностей нескольких пользователей Ethereum: обмен цифровыми активами, конфиденциальность. , имена пользователей, расширенное шифрование, безопасность учетной записи, устойчивость к цензуре, предварительная защита и многое другое. Однако в последнее время предпринимались осторожные попытки внедрить больше этих функций в основной протокол Ethereum.

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

Ранняя философия протокольного минимализма

В ранней истории того, что тогда было известно как «Эфириум 2.0», было сильное желание создать чистый, простой и красивый протокол, который как можно меньше старался бы основываться на самом себе и оставлял почти всю подобную работу пользователям. В идеале протокол — это просто виртуальная машина, а проверка блока — это просто вызов виртуальной машины.

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

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

Мы кратко изучили эту идею, но быстро отказались от нее, поскольку были слишком сосредоточены на доказательстве возможности любого масштабирования блокчейна. Хотя, как мы увидим позже, сочетание выборки доступности данных и ZK-EVM означает, что возможное будущее масштабирования Ethereum на самом деле очень близко к этому видению! С другой стороны, что касается абстракции учетной записи, мы с самого начала знали, что какая-то реализация возможна, поэтому немедленно начались исследования, пытаясь сделать что-то как можно ближе к чистой отправной точке «транзакция — это просто звонок». реальность.

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

Одним из основных фрагментов кода здесь является validate_transaction(state, tx), который отвечает за проверку правильности nonce и подписи транзакции. С самого начала фактическая цель абстракции учетной записи заключалась в том, чтобы позволить пользователям заменить базовую неинкрементальную проверку и проверку ECDSA собственной логикой проверки, чтобы пользователям было проще использовать такие функции, как социальное восстановление и кошельки с несколькими подписями. Таким образом, поиск способа реструктуризации apply_transaction в простой вызов EVM был не просто задачей «сделать код чистым ради того, чтобы сделать код чистым», а заключался в перемещении логики в код учетной записи пользователя. Дайте пользователям ту гибкость, которую они могут; нуждаться.

Однако настаивание на том, чтобы apply_transaction содержало как можно меньше фиксированной логики, в конечном итоге создало множество проблем. Мы можем рассмотреть одно из первых предложений по абстракции учетных записей — EIP-86.

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

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

С тех пор абстракция аккаунта развивалась поэтапно. Позднее EIP-86 стал EIP-208, и, наконец, появился практический EIP-2938.

Однако EIP-2938 совсем не минималистский. Его содержимое включает в себя:

· Новые типы транзакций

· Три новые глобальные переменные области транзакций.

· Два новых кода операций, в том числе очень неуклюжий код операции PAYgas для проверки цены на газ и лимита газа, в качестве точек останова выполнения EVM, а также для временного хранения ETH для единовременных платежей.

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

Чтобы добиться абстракции учетных записей без участия разработчиков ядра Ethereum (с упором на оптимизацию клиентов Ethereum и реализацию слияний), EIP-2938 в конечном итоге был перепроектирован как ERC-4337, который полностью не соответствует протоколу.

Поскольку это ERC, он не требует хард-форка и технически существует «вне протокола Ethereum». Итак... проблема решена? Оказывается, это не так. Текущая среднесрочная дорожная карта ERC-4337 фактически предполагает в конечном итоге преобразование больших частей ERC-4337 в ряд функций протокола, что является полезным примером руководства относительно того, почему следует рассматривать этот путь.

Пакет ERC-4337

Обсуждается несколько ключевых причин для возвращения ERC-4337 в протокол:

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

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

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

Сопротивление цензуре. Одна из проблем разделения предлагающего и разработчика заключается в том, что становится легче проверять отдельные транзакции. В мире, где протокол Ethereum может идентифицировать отдельные транзакции, эту проблему можно значительно облегчить с помощью списков включения, которые позволяют предлагающим указать список транзакций, которые должны быть включены в следующие два слота почти во всех случаях. Однако ERC-4337 вне протокола инкапсулирует «пользовательские операции» в одной транзакции, что делает пользовательские операции непрозрачными для протокола Ethereum, поэтому список включения, предоставляемый протоколом Ethereum, не сможет обеспечить устойчивость к цензуре для пользователя ERC-4337; операции. Инкапсуляция ERC-4337 и придание пользовательским операциям «правильного» типа транзакции решит эту проблему.

Стоит отметить, что в своем нынешнем виде ERC-4337 значительно дороже «базовых» транзакций Ethereum: транзакция стоит 21 000 газа, а ERC-4337 — около 42 000 газа.

Теоретически должна быть возможность корректировать систему стоимости газа EVM до тех пор, пока стоимость внутри протокола и стоимость доступа к хранилищу вне протокола не совпадут, и не будет необходимости тратить 9000 газа на передачу ETH при других типах редактирования хранилища; операции дешевле. Фактически, два EIP, связанные с предстоящим преобразованием дерева Веркла, на самом деле пытаются сделать именно это. Но даже если мы сделаем это, есть очевидная причина, по которой независимо от того, насколько эффективной станет EVM, функции инкапсулированного протокола неизбежно будут намного дешевле, чем код EVM: инкапсулированному коду не нужно платить за предварительную загрузку.

Полнофункциональный кошелек ERC-4337 имеет большие размеры: эта реализация, скомпилированная и размещенная в цепочке, занимает около 12 800 байт. Конечно, вы можете развернуть этот код один раз и использовать DELEGATECALL, чтобы позволить каждому отдельному кошельку вызывать его, но вам все равно потребуется доступ к коду в каждом блоке, где он используется. При EIP стоимости газа дерева Веркла 12 800 байт образуют 413 кусков, и для доступа к этим кускам потребуется заплатить двойную сумму свидетеля Branch_cost (всего 3800 газа) и 413-кратную сумму свидетеля chunk_cost (всего 82 600 газа). Это даже не говоря уже о самой точке входа ERC-4337, которая в версии 0.6.0 имеет 23 689 байт в цепочке (приблизительно 158 700 газа для загрузки согласно правилам EIP дерева Веркле).

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

Чему мы можем научиться из этого примера и когда следует практиковать инкапсуляцию в более широком смысле?

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

Рыночные подходы, которые «доводят сложность до предела», скорее всего, потерпят неудачу, когда фиксированные затраты высоки. Фактически, долгосрочная дорожная карта абстракции учетных записей предполагает много фиксированных затрат на блок. 244 100 газа для загрузки стандартизированного кода кошелька — это одно, но агрегация может добавить сотни тысяч газа для проверки ZK-SNARK, а также стоимость проверки доказательства в сети; Невозможно взимать с пользователей плату за эти затраты, не приводя к огромной неэффективности рынка, а превращение некоторых из этих функций в функции протокола, которые свободно доступны каждому, могло бы очень хорошо решить эту проблему.

Реакция всего сообщества на ошибки в коде. Если какой-то фрагмент кода используется всеми пользователями или очень широким кругом пользователей, для сообщества блокчейна часто имеет смысл взять на себя ответственность за хард-форк для исправления любых возникающих ошибок. ERC-4337 вводит большой объем глобального общего кода. В долгосрочной перспективе, несомненно, более разумно исправлять ошибки в коде с помощью хард-форков, чем заставлять пользователей терять большое количество ETH.

Иногда можно реализовать более сильную форму протокола, напрямую используя его функциональность. Ключевым примером здесь являются функции протокола, устойчивые к цензуре, такие как списки включения: списки включения в протоколе могут обеспечить устойчивость к цензуре лучше, чем внепротокольные методы, чтобы операции на уровне пользователя действительно извлекали выгоду из внутрипротокольных операций. включать списки, отдельные пользователи. Операции на уровне требуют, чтобы протокол был «читабельным». Другой менее известный пример заключается в том, что в конструкции доказательства ставки Ethereum 2017 года использовалась абстракция учетных записей ключей ставки, от которой отказались в пользу инкапсулированного BLS, поскольку BLS поддерживал механизм «агрегации», который должен был быть реализован в протоколе и сетевых уровнях, это может сделать обработку большого количества подписей более эффективной.

Но важно помнить, что даже инкапсуляция абстракций учетных записей в протоколах по-прежнему является огромной «деинкапсуляцией» по сравнению со статус-кво. Сегодня транзакции Ethereum верхнего уровня могут быть инициированы только с внешних учетных записей (EOA), которые проверяются с использованием одной подписи эллиптической кривой secp 256 k 1. Абстракция учетной записи устраняет это и оставляет условия проверки на усмотрение пользователя. Поэтому в этой истории об абстракции учетных записей мы также видим самую большую причину против инкапсуляции: гибкость для удовлетворения потребностей разных пользователей.

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

Пакет ЗК-ЭВМ

Давайте обратим внимание на еще одну потенциальную цель инкапсуляции протокола Ethereum: ZK-EVM. В настоящее время у нас есть большое количество объединений ZK, и все они должны писать довольно похожий код для проверки выполнения аналогичных блоков Ethereum в ZK-SNARK. Существует достаточно разнообразная экосистема независимых реализаций: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth и другие.

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

В среднесрочной перспективе объединение может опираться на несколько систем сертификации, а Совет Безопасности будет иметь полномочия только в крайних случаях, когда две разные системы сертификации расходятся.

Однако есть ощущение, что часть этой работы кажется излишней. У нас уже есть базовый уровень Ethereum, в нем есть EVM, и у нас уже есть работающий механизм борьбы с ошибками в реализации: если есть ошибка, клиент будет обновлен для ее исправления, и цепочка продолжит функционировать. . С точки зрения глючного клиента кажется, что финализированные блоки больше не будут подтверждаться, но, по крайней мере, мы не увидим, как пользователи теряют средства. Аналогичным образом, если накопительные пакеты просто хотят оставаться эквивалентными EVM, им необходимо реализовать собственное управление, чтобы постоянно изменять свои внутренние правила ZK-EVM, чтобы соответствовать обновлениям базового уровня Ethereum, что кажется неправильным, поскольку в конечном итоге они построены на основе Сам базовый уровень Ethereum знает, когда обновляться и в соответствии с какими новыми правилами.

Поскольку эти ZK-EVM L2 в основном используют тот же EVM, что и Ethereum, можем ли мы каким-то образом включить «проверку выполнения EVM в ZK» в функциональность протокола и обрабатывать исключения, применяя социальный консенсус Ethereum, например ошибки и обновления, как мы уже делаем для само выполнение EVM базового уровня?

Это важная и сложная тема.

Одной из возможных тем дискуссий относительно доступности данных в собственном ZK-EVM является сохранение состояния. ZK-EVM были бы гораздо более эффективными в отношении данных, если бы им не нужно было переносить «свидетельские» данные. То есть, если конкретный фрагмент данных был прочитан или записан в каком-то предыдущем блоке, мы можем просто предположить, что доказывающая сторона имеет к нему доступ и ему не нужно снова делать его доступным. Дело не только в том, чтобы не перезагружать хранилище и код; оказывается, что если объединение правильно сжимает данные, сжатие с сохранением состояния может сэкономить до 3 раз больше данных по сравнению со сжатием без сохранения состояния.

Это означает, что для предварительной компиляции ZK-EVM у нас есть два варианта:

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

2. Предварительная компиляция позволяет указателям указывать на данные, использованные или сгенерированные предыдущими выполнениями. Это делает ZK-свертывание близким к оптимальному, но оно более сложное и вводит новое состояние, которое должно быть сохранено проверяющим.

Чему мы можем научиться из этого? Есть веская причина каким-то образом инкапсулировать проверку ZK-EVM: накопительный пакет уже создает свою собственную версию, и Ethereum готов взвесить свои многочисленные реализации и социальный консенсус вне цепочки для выполнения EVM на L1, это кажется неправильным, но L2, выполняющий ту же самую работу, должен будет внедрить сложный гаджет с участием Совета Безопасности. Но с другой стороны, есть большая проблема в деталях: существуют разные версии ZK-EVM, с разной стоимостью и преимуществами. Различие между состоянием и отсутствием состояния лишь поверхностное; попытки поддерживать «почти-EVM» собственный код, который был проверен другими системами, могут открыть большее пространство для проектирования. Таким образом, упаковка ZK-EVM приносит как надежду, так и проблемы.

Разделение предложения инкапсуляции и построения (ePBS)

Рост MEV делает производство блоков масштабной экономической деятельностью, где сложные участники могут создавать блоки, которые приносят больший доход, чем алгоритм по умолчанию, который просто наблюдает за мемпулом транзакций и содержит их. До сих пор сообщество Ethereum пыталось решить эту проблему, используя схемы разделения предлагающего и создателя вне протокола, такие как MEV-Boost, который позволяет обычным валидаторам («предлагающим») отправлять блоки на аутсорсинг строительства специализированным участникам («строители»). ").

Однако MEV-Boost делает предположения о доверии в новом классе участников, называемых ретрансляторами. За последние два года многие люди предложили создать «инкапсулированную PBS». Каковы преимущества этого? В этом случае ответ очень прост: PBS, построенная с использованием непосредственно функций протокола, является более мощной (в смысле наличия более слабых предположений о доверии), чем PBS, построенная без их использования. Это похоже на инкапсуляцию ценовых оракулов в протокол – хотя в этом случае есть серьезные возражения.

Инкапсулировать частный пул памяти

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

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

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

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

Шифруйте централизованные операторы, такие как Flashbots Protect.

Шифрование с временной блокировкой. Эта форма шифрования может быть расшифрована кем угодно после определенных последовательных шагов вычислений и не может быть распараллелена;

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

Надежное оборудование, такое как SGX.

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

Инкапсулированная ликвидность

Общей потребностью среди пользователей Ethereum DeFi является возможность одновременно использовать свои ETH для ставок и в качестве залога в других приложениях. Еще один распространенный запрос связан просто с удобством: пользователи хотят иметь возможность делать ставки (и защищать ключи онлайн-стейкинга) без необходимости запуска узла и постоянного поддержания его в сети.

Безусловно, самый простой «интерфейс», отвечающий обеим этим потребностям, — это токен ERC 20: конвертируйте свой ETH в «стейкинг ETH», удерживайте его, а затем конвертируйте обратно. Фактически, такие поставщики ставок ликвидности, как Lido и Rocket Pool, уже делают это. Тем не менее, при размещении ставок на ликвидность действуют некоторые естественные механизмы централизации: люди, естественно, будут делать ставки на самую крупную версию ETH, потому что она является наиболее распространенной и ликвидной.

Каждая версия стейкинга ETH должна иметь какой-то механизм для определения того, кто может стать оператором базового узла. Оно не может быть неограниченным, потому что тогда к нему присоединятся злоумышленники и будут использовать средства пользователей для расширения своих атак. В настоящее время двумя ведущими являются Lido и Rocket Pool: первый имеет операторов узлов, внесенных в белый список DAO, а второй позволяет любому запустить узел с депозитом в 8 ETH. Эти два метода имеют разные риски: метод Rocket Pool позволяет злоумышленнику провести атаку 51% на сеть и заставляет пользователей нести большую часть затрат, что касается метода DAO, если определенный застейканный токен станет доминирующим, он будет лидировать; к одному потенциально скомпрометированному гаджету управления, который контролирует большую часть всех валидаторов Ethereum. Надо отдать должное, такие протоколы, как Лидо, реализуют меры безопасности, но одного уровня защиты может быть недостаточно.

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

Ключевой вопрос здесь: какая внутрипротокольная функциональность? Одна из проблем с простым созданием взаимозаменяемого токена «ставки ETH» в протоколе заключается в том, что он должен либо иметь инкапсулированное управление в масштабе всего Ethereum, чтобы выбирать, кто будет управлять узлами, либо быть открытым, что превратило бы его в инструмент атакующего. Инструменты.

Интересная идея — статья Данкрада Файста о ставках на максимизацию ликвидности. Прежде всего, давайте стиснем зубы. Если Ethereum подвергнется атаке 51%, только 5% атакованного ETH может быть уничтожено. Это разумный компромисс; учитывая, что в настоящее время на кону поставлено более 26 миллионов ETH, стоимость атаки на треть из них (~ 8 миллионов ETH) является чрезмерной, особенно если учесть, сколько «нестандартных» атак можно осуществить за один раз. более низкая стоимость. Фактически, аналогичные компромиссы были рассмотрены в предложении Суперкомитета по внедрению окончательности с одним интервалом.

Если мы признаем, что только 5% атакованных ETH сокращается, то более 90% поставленных ETH не будут затронуты сокращением, поэтому их можно будет использовать в качестве взаимозаменяемых токенов для стейкинга в рамках протокола, а затем использовать другие приложения.

Этот путь интересен. Но остается один вопрос: что именно инкапсулируется? Rocket Pool работает очень похоже: каждый оператор ноды предоставляет часть средств, а остальные предоставляют участники стейкинга ликвидности. Мы можем просто настроить некоторые константы, чтобы ограничить максимальный штраф за сокращение до 2 ETH, и существующий rETH Rocket Pool станет безрисковым.

С помощью простых настроек протокола мы можем делать и другие умные вещи. Например, предположим, что нам нужна система с двумя «уровнями» ставок: операторы узлов (высокие требования к залогу) и вкладчики (нет минимальных требований к залогу, могут присоединиться и выйти в любое время), но мы все равно хотим иметь возможность присоединиться. и уйти в любое время, предоставив случайно выбранному комитету вкладчиков полномочия по предотвращению централизации операторов узлов, например, рекомендовать список транзакций, которые должны быть включены (по причинам сопротивления цензуре), контролировать выбор форков во время утечек бездействия или требовать подписей на блоках . Это может быть достигнуто способом, который по сути выходит за рамки протокола, путем настройки протокола, требующего от каждого валидатора предоставления (i) обычного ключа для ставок и (ii) адреса ETH, который можно использовать в каждом слоте, для вывода вторичный залоговый ключ. Протокол предоставит полномочия обоим ключам, но механизм выбора второго ключа в каждом слоте можно оставить на усмотрение протокола пула ставок. Возможно, все же лучше инкапсулировать некоторые функции напрямую, но стоит отметить, что существует такое пространство дизайна, как «включить некоторые вещи, а другие оставить пользователю».

Инкапсулируйте больше предварительной компиляции

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

В настоящее время ведется работа по добавлению предварительной компиляции для secp 256 r 1 , эллиптической кривой, немного отличающейся от secp 256 k 1, используемой для базовых учетных записей Ethereum, поскольку она хорошо поддерживается надежными аппаратными модулями и поэтому широко используется для повышения безопасности кошелька. В последние годы сообщество также настаивало на добавлении предварительной компиляции для BLS-12-377, BW 6-761, обобщенного сопряжения и других функций.

Контраргументом к этим призывам к большему количеству прекомпиляторов является то, что многие из добавленных ранее прекомпиляторов (таких как RIPEMD и BLAKE) в конечном итоге использовались гораздо реже, чем ожидалось, и нам следует извлечь из этого уроки. Вместо того, чтобы добавлять больше предварительной компиляции для конкретных операций, нам, вероятно, следует сосредоточиться на более скромном подходе, основанном на таких идеях, как EVM-MAX и предложении SIMD Hibernate-But-Always-Resumable, который позволит реализациям EVM работать с меньшими затратами. выполнение широкого спектра классов кода. Возможно, даже существующую малоиспользуемую предварительную компиляцию можно было бы удалить и заменить (неизбежно менее эффективной) реализацией тех же функций в коде EVM. Тем не менее, все же возможно, что существуют определенные криптографические операции, которые достаточно ценны для ускорения, поэтому имеет смысл добавлять их как предварительно скомпилированные.

Чему мы научились из всего этого?

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

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

Инкапсуляция функциональности может помочь избежать рисков централизации в других областях стека:

Часто сохранение минимального и простого базового протокола усложняет некую экосистему за пределами протокола. С точки зрения философии Unix это нормально. Однако иногда существует риск того, что внепротокольная экосистема станет централизованной, обычно (но не только) из-за высоких фиксированных затрат. Инкапсуляция иногда может снизить фактическую централизацию.

Слишком большая инкапсуляция может привести к чрезмерному увеличению доверия и бремени управления протоколом:

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

Слишком большая инкапсуляция может сделать протокол слишком сложным:

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

Инкапсуляция функциональности может оказаться контрпродуктивной в долгосрочной перспективе, поскольку потребности пользователей непредсказуемы:

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

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

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

Вместо инкапсуляции большего количества прекомпиляторов лучше инкапсулировать EVM-MAX и/или SIMD, чтобы упростить эффективную реализацию более широкого класса операций;

Вместо инкапсуляции всей концепции объединения можно просто инкапсулировать проверку EVM.

Мы можем расширить предыдущую диаграмму следующим образом:

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

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