*Особая благодарность Джастину Дрейку, Тине Чжэнь и Йоаву Вайсу за их отзывы и обзор. *
С самого начала проекта Ethereum существовала сильная философия, заключающаяся в том, чтобы попытаться сделать ядро Ethereum как можно более простым и добиться этого, насколько это возможно, путем создания протоколов поверх него. В пространстве блокчейнов дебаты «построить на L1» или «фокусироваться на L2» часто рассматриваются как прежде всего вопросы масштабирования, но на самом деле существуют схожие проблемы с удовлетворением потребностей нескольких пользователей Ethereum: обмен цифровыми активами, конфиденциальность. , имена пользователей, расширенное шифрование, безопасность учетной записи, устойчивость к цензуре, предварительная защита и многое другое. Однако в последнее время предпринимались осторожные попытки внедрить больше этих функций в основной протокол Ethereum.
В этой статье мы углубимся в некоторые философские рассуждения, лежащие в основе оригинальной философии минимальной инкапсуляции, а также в некоторые недавние способы размышления об этих идеях. Цель будет заключаться в том, чтобы начать создавать структуру для лучшего определения возможных целей, в которых, возможно, стоит рассмотреть возможность инкапсуляции определенной функциональности.
Ранняя философия минимализма протоколов
В ранней истории того, что тогда было известно как «Эфириум 2.0», существовало сильное желание создать чистый, простой и красивый протокол, который как можно меньше пытался бы основываться на самом себе и оставлял почти всю подобную работу пользователям. В идеале протокол — это просто виртуальная машина, а проверка блока — это просто вызов виртуальной машины.
Это приблизительная реконструкция диаграммы на доске, которую мы с Гэвином Вудом нарисовали в начале 2015 года, когда я говорил о том, как будет выглядеть 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-4337. Он полностью полагается на вызовы EVM!
Поскольку это 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 фрагментов. Доступ к этим фрагментам потребует удвоенной стоимости ветки-свидетеля (всего 3800 газа) и 413-кратной стоимости фрагмента-свидетеля (всего 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 256k 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 преобразовывать свои учетные записи в такие же (или лучше) функциональный контракт.
Какие функции следует внести в протокол, а какие оставить другим уровням экосистемы, — это сложный компромисс. Ожидается, что этот компромисс со временем будет улучшаться по мере того, как наше понимание потребностей пользователей и доступный набор идей и технологий продолжают улучшаться.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Последняя длинная статья Бутерина: Должен ли протокол Ethereum инкапсулировать больше функций?
Автор: Виталик Бутерин Составитель: Odaily Planet Daily Nian Yinsitang
*Особая благодарность Джастину Дрейку, Тине Чжэнь и Йоаву Вайсу за их отзывы и обзор. *
С самого начала проекта Ethereum существовала сильная философия, заключающаяся в том, чтобы попытаться сделать ядро Ethereum как можно более простым и добиться этого, насколько это возможно, путем создания протоколов поверх него. В пространстве блокчейнов дебаты «построить на L1» или «фокусироваться на L2» часто рассматриваются как прежде всего вопросы масштабирования, но на самом деле существуют схожие проблемы с удовлетворением потребностей нескольких пользователей Ethereum: обмен цифровыми активами, конфиденциальность. , имена пользователей, расширенное шифрование, безопасность учетной записи, устойчивость к цензуре, предварительная защита и многое другое. Однако в последнее время предпринимались осторожные попытки внедрить больше этих функций в основной протокол Ethereum.
В этой статье мы углубимся в некоторые философские рассуждения, лежащие в основе оригинальной философии минимальной инкапсуляции, а также в некоторые недавние способы размышления об этих идеях. Цель будет заключаться в том, чтобы начать создавать структуру для лучшего определения возможных целей, в которых, возможно, стоит рассмотреть возможность инкапсуляции определенной функциональности.
Ранняя философия минимализма протоколов
В ранней истории того, что тогда было известно как «Эфириум 2.0», существовало сильное желание создать чистый, простой и красивый протокол, который как можно меньше пытался бы основываться на самом себе и оставлял почти всю подобную работу пользователям. В идеале протокол — это просто виртуальная машина, а проверка блока — это просто вызов виртуальной машины.
Это приблизительная реконструкция диаграммы на доске, которую мы с Гэвином Вудом нарисовали в начале 2015 года, когда я говорил о том, как будет выглядеть 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 совсем не минималистский. Его содержимое включает в себя:
В попытке добиться абстракции учетных записей без участия разработчиков ядра Ethereum (которые были сосредоточены на оптимизации клиентов Ethereum и реализации слияний), EIP-2938 в конечном итоге был перепроектирован как ERC-4337, который был полностью вне протокола.
ERC-4337. Он полностью полагается на вызовы EVM!
Поскольку это ERC, он не требует хард-форка и технически существует «вне протокола Ethereum». Итак... проблема решена? Оказывается, это не так. Текущая среднесрочная дорожная карта ERC-4337 фактически предполагает в конечном итоге переход больших частей ERC-4337 в ряд функций протокола, что является полезным примером руководства относительно того, почему следует рассматривать этот путь.
Пакет 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 фрагментов. Доступ к этим фрагментам потребует удвоенной стоимости ветки-свидетеля (всего 3800 газа) и 413-кратной стоимости фрагмента-свидетеля (всего 82 600). газ). Это даже не говоря уже о самой точке входа ERC-4337, которая в версии 0.6.0 имеет 23 689 байт в цепочке (приблизительно 158 700 газа для загрузки согласно правилам EIP дерева Веркле).
Это приводит к проблеме: стоимость газа для фактического доступа к этим кодам должна каким-то образом амортизироваться между транзакциями. Текущий подход, используемый ERC-4337, не очень хорош: первая транзакция в пакете требует единовременных затрат на хранение/чтение кода, что делает ее намного дороже, чем другие транзакции. Внутрипротокольная инкапсуляция позволит этим публичным общим библиотекам стать частью протокола и свободно доступными для всех.
Чему мы можем научиться из этого примера и когда следует практиковать инкапсуляцию в целом?
В этом примере мы видим несколько различных обоснований инкапсуляции абстракций учетных записей в протоколах.
Но важно помнить, что даже абстракция учетной записи в протоколе инкапсуляции по-прежнему представляет собой огромную «деинкапсуляцию» по сравнению со статус-кво. Сегодня транзакции Ethereum верхнего уровня могут быть инициированы только с внешних учетных записей (EOA), которые проверяются с использованием одной подписи эллиптической кривой secp 256k 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, построенная без их использования. Это похоже на инкапсуляцию ценовых оракулов в протокол – хотя в этом случае есть серьезные возражения.
Инкапсулировать частный пул памяти
Когда пользователь отправляет транзакцию, она сразу же становится общедоступной и видимой для всех, даже до того, как она будет включена в цепочку. Это делает пользователей многих приложений уязвимыми для экономических атак, таких как опережающий запуск.
В последнее время появился ряд проектов, посвященных созданию «частных мемпулов» (или «крипто мемпулов»), которые шифруют транзакции пользователей до тех пор, пока они не будут необратимо приняты в блок.
Проблема, однако, в том, что такая схема требует особого типа шифрования: чтобы пользователи не могли загружать систему и сначала ее расшифровывать, шифрование должно автоматически расшифровываться после того, как транзакция фактически была необратимо принята.
Существуют различные методы с разными компромиссами для реализации этой формы шифрования. Джон Шарбонно однажды хорошо описал это:
К сожалению, каждый метод шифрования имеет свои слабые стороны. Хотя для каждого решения существует сегмент пользователей, готовых ему доверять, ни одно решение не пользуется достаточным доверием, чтобы его фактически принял уровень 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 и предварительно скомпилированные примеры показывают возможность среднего пути: минимальное жизнеспособное закрепление. Протокол не обязательно должен инкапсулировать всю функциональность, но может содержать определенные части, которые решают ключевые проблемы, что упрощает реализацию функциональности, не будучи слишком параноидальным или слишком узким. Примеры включают в себя:
Мы можем расширить предыдущую диаграмму следующим образом:
Иногда имеет смысл что-то инкапсулировать, и одним из примеров является удаление редко используемых прекомпиляторов. Абстракция учетной записи в целом, как упоминалось ранее, также является важной формой деинкапсуляции. Если мы хотим поддерживать обратную совместимость для существующих пользователей, механизм на самом деле может быть удивительно похож на тот, который распаковал предварительную компиляцию: одно из предложений — EIP-5003, который позволит EOA преобразовывать свои учетные записи в такие же (или лучше) функциональный контракт.
Какие функции следует внести в протокол, а какие оставить другим уровням экосистемы, — это сложный компромисс. Ожидается, что этот компромисс со временем будет улучшаться по мере того, как наше понимание потребностей пользователей и доступный набор идей и технологий продолжают улучшаться.