В ранней истории того, что тогда было известно как «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 до тех пор, пока стоимость по договору и стоимость доступа к хранилищу вне протокола не совпадут; Когда другие виды операций редактирования хранилища дешевле, нет смысла переводить ETH за 9000 газа. На самом деле, два EIP, связанных с предстоящим преобразованием дерева Verkle, на самом деле пытаются сделать именно это. Но даже если мы это сделаем, есть очевидная причина, по которой инкапсулированная функциональность протокола неизбежно будет намного дешевле, чем код EVM, независимо от того, насколько эффективным станет EVM: инкапсулированному коду не нужно платить газ за предварительную загрузку.
Полнофункциональный кошелек ERC-4337 имеет большой размер, а реализация, которая компилирует и помещает его в блокчейн, занимает около 12 800 байт. Конечно, вы можете развернуть этот код один раз и использовать DELEGATECALL, чтобы позволить каждому отдельному кошельку вызывать его, но вам все равно нужно получить доступ к коду в каждом блоке, который его использует. В соответствии с затратами на газ дерева Веркла EIP, 12 800 байт составят 413 блоков, и доступ к этим блокам потребует оплаты в 2 раза больше следящей ветки_cost (всего 3 800 газа) и в 413 раз больше следящего блока_cost (всего 82 600 газа). И это не говоря уже о самой точке входа ERC-4337, которая в версии 0.6.0 имеет 23 689 байт в цепочке (около 158 700 газа для загрузки по правилам дерева Verkle EIP).
Это приводит к проблеме: затраты на газ для фактического доступа к этим кодам должны каким-то образом амортизироваться по всей транзакции. Текущий подход, используемый ERC-4337, не очень хорош: первая транзакция в пакете потребляет единовременные затраты на хранение/чтение кода, что делает ее намного дороже, чем другие транзакции. Инкапсуляция в протоколе позволит этим публичным разделяемым библиотекам быть частью протокола и быть свободно доступными для всех.
Чему мы можем научиться из этого примера, и когда упаковка станет более распространенной? **
В этом примере мы видим несколько различных обоснований для инкапсуляции аспекта абстракции учетной записи в протоколе.
Рыночные подходы, которые «доводят сложность до предела», скорее всего, потерпят неудачу при высоких фиксированных затратах. На самом деле, долгосрочная дорожная карта абстракции аккаунта выглядит так, как будто каждый блок имеет много фиксированных затрат. 244, 100 газ для загрузки стандартизированных кодов кошельков - это одно; Но агрегация может добавить сотни тысяч газа к валидации ZK-SNARK, а также затраты на проверку Proof-of-Chain в цепочке. Нет никакого способа взимать с пользователей плату за эти расходы, не внося при этом много неэффективности рынка, и перевод некоторых из этих функций в функции протокола, к которым каждый может получить доступ бесплатно, хорошо решает эту проблему.
Реакция всего сообщества на ошибки в коде. Если какие-то фрагменты кода используются всеми пользователями или очень широким кругом пользователей, обычно блокчейн-сообществу имеет смысл взять на себя ответственность за хардфорк, чтобы исправить любые возникающие ошибки. ERC-4337 вводит большое количество глобально разделяемого кода, и исправление ошибок в коде с помощью хардфорка, несомненно, более разумно в долгосрочной перспективе, чем заставлять пользователей терять много ETH.
Иногда более сильная форма может быть достигнута за счет прямого использования функциональности протокола. Ключевым примером здесь является встроенная функция защиты от цензуры, такая как список включения: список включения в протоколе может гарантировать устойчивость к цензуре лучше, чем метод вне протокола, и для того, чтобы операции на уровне пользователя действительно могли извлечь выгоду из списка включения в протоколе, одна операция на уровне пользователя должна быть «читаемой» для протокола. Другим менее известным примером является дизайн Ethereum Proof-of-Stake 2017 года, в котором абстрагировался ключевой счет стейка, от которого отказались в пользу инкапсуляции BLS, поскольку BLS поддерживает механизм «агрегации», который должен быть реализован на уровне протокола и сети, что может сделать обработку большого количества подписей более эффективной.
Но важно помнить, что даже инкапсуляция внутрипротокольной абстракции учетной записи по-прежнему является огромной «деинкапсуляцией» по сравнению с текущей ситуацией. Сегодня транзакции Ethereum высшего уровня могут быть инициированы только с внешних учетных записей (EOA), которые проверены с помощью одной подписи эллиптической кривой secp 256k1. Абстракция учетной записи устраняет это и оставляет критерии проверки на усмотрение пользователя. Таким образом, в этой истории об абстракции учетной записи мы также видим самый большой аргумент против инкапсуляции: гибкость для удовлетворения потребностей разных пользователей.
Давайте конкретизируем эту историю, рассмотрев несколько других примеров функций, которые недавно считались инкапсулированными. Особое внимание мы уделим: ZK-EVM, разделению proposer и builder, приватным мемпулам, стейкингу ликвидности и новой прекомпиляции.
Пакет ZK-EVM
Давайте обратим внимание на еще одну потенциальную цель инкапсуляции протокола Ethereum: ZK-EVM. В настоящее время у нас есть большое количество ZK-роллапов, каждый из которых должен писать довольно похожий код для проверки выполнения аналогичных блоков Ethereum в ZK-SNARK. Существует достаточно разнообразная экосистема независимых реализаций: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth и многие другие.
Недавний спор в пространстве EVM ZK-rollup связан с тем, как обрабатывать возможные ошибки в коде ZK. В настоящее время все эти работающие системы имеют тот или иной механизм «Совета Безопасности», который контролирует систему аттестации в случае ошибок. В прошлом году я попытался создать стандартизированную структуру, чтобы стимулировать проекты к уточнению уровня доверия к системе сертификации, а также к Совету Безопасности, и постепенно снижать свои полномочия над организацией с течением времени.
В среднесрочной перспективе «роллапы» могут опираться на несколько систем аттестации, и Совет Безопасности будет иметь полномочия только в крайних случаях, когда две различные системы аттестации расходятся.
Однако есть ощущение, что часть работы кажется избыточной. У нас уже есть базовый уровень Ethereum, у него есть EVM, и у нас уже есть работающий механизм обработки багов в реализации: если есть баг, клиент обновится, чтобы его исправить, и тогда цепочка продолжит функционировать. С точки зрения глючного клиента, кажется, что блоки, которые были завершены, больше не будут подтверждаться, но, по крайней мере, мы не увидим, как пользователи теряют деньги. Точно так же, если роллапы просто хотят сохранить свою роль, эквивалентную EVM, то им необходимо внедрить собственное управление, чтобы постоянно изменять свои внутренние правила ZK-EVM, чтобы соответствовать обновлениям базового уровня Ethereum, что кажется неправильным, потому что в конечном итоге они построены поверх самого базового уровня Ethereum, который знает, когда обновляться и в соответствии с какими новыми правилами.
Поскольку эти L2 ZK-EVM в основном используют точно такие же EVM, как и Ethereum, можем ли мы каким-то образом включить «проверку выполнения EVM в ZK» в функцию протокола и обрабатывать исключения, такие как ошибки и обновления, применяя социальный консенсус Ethereum, как мы уже делаем с самой реализацией EVM базового уровня?
Это важная и сложная тема.
Одной из возможных тем дебатов о доступности данных в нативном ZK-EVM является состояние состояния. Если бы ЗК-ЭВМ не нужно было передавать «свидетельские» данные, их эффективность была бы намного выше. То есть, если определенный фрагмент данных уже был прочитан или записан в каком-то предыдущем блоке, мы можем просто предположить, что прувер имеет к нему доступ и не должен делать его снова доступным. Речь идет не только о том, чтобы не перезагружать хранилище и код; Оказывается, что сжатие с отслеживанием состояния может сэкономить до 3 раз данных по сравнению со сжатием без отслеживания состояния, если один свертка сжимает данные правильно.
Это означает, что для прекомпиляции ZK-EVM у нас есть два варианта:
Предварительная компиляция требует, чтобы все данные были доступны в одном блоке. Это означает, что прувер может быть без сохранения состояния, но это также означает, что использование этого предварительно скомпилированного ZK-роллапа намного дороже, чем использование роллапа с пользовательским кодом.
Предварительная компиляция позволяет указателю указывать на ранее выполненные, использованные или сгенерированные данные. Это делает ZK-rollup почти оптимальным, но он более сложен и вводит новое состояние, которое должно быть сохранено prover.
Какие уроки мы можем извлечь из этого? Есть веская причина, чтобы каким-то образом инкапсулировать верификацию ZK-EVM: роллап уже создает свою собственную пользовательскую версию, а Ethereum готов взвесить свои многочисленные реализации и социальный консенсус вне блокчейна на L1 для выполнения EVM, что кажется неправильным, но L2, выполняя точно такую же работу, должен внедрять сложные гаджеты с участием Совета Безопасности. Но с другой стороны, есть большая проблема в деталях: существуют разные версии ЗК-ЭВМ, которые отличаются по стоимости и пользе. Различие между состоянием и состоянием без него лишь поверхностно; Попытка поддержки «почти-EVM», пользовательских кодов, которые были проверены другими системами, может открыть больше пространства для дизайна. Таким образом, инкапсуляция ZK-EVM представляет собой как перспективы, так и проблемы.
Разделение оболочки и сборщика (ePBS)
Рост популярности MEV превратил производство блоков в крупномасштабную экономическую деятельность, в которой сложные участники могут производить блоки, которые приносят больше дохода, чем алгоритм по умолчанию, который просто наблюдает за мемпулом транзакций и содержит их. До сих пор сообщество Ethereum пыталось решить эту проблему, используя внепротокольную схему разделения proposer-builder, такую как MEV-Boost, которая позволяет обычным валидаторам («proposers») передавать строительство блоков на аутсорсинг специализированным участникам («строителям»).
Тем не менее, MEV-Boost делает предположения о доверии к новому классу участников, называемому эстафетами. За последние два года поступило много предложений о создании «инкапсулированной PBS». Какие преимущества это дает? В этом случае ответ прост: PBS, построенная непосредственно с использованием функций протокола, является более мощной (в том смысле, что имеет более слабые предположения о доверии), чем PBS, построенная без них. Это похоже на случай с ценовыми оракулами в протоколе инкапсуляции, хотя в этом случае также есть сильное противодействие.
Инкапсуляция частного пула памяти
Когда пользователь отправляет транзакцию, она сразу становится публичной и видимой для всех, даже до того, как она будет включена в цепочку. Это делает пользователей многих приложений уязвимыми для экономических атак, таких как вытесняющие транзакции.
В последнее время появилось несколько проектов, посвященных созданию «приватных мемпулов» (или «зашифрованных мемпулов»), которые шифруют транзакции пользователей до тех пор, пока они не будут необратимо приняты в блок.
Проблема, однако, заключается в том, что такие схемы требуют особого вида шифрования: для того, чтобы пользователи не наводнили систему и не расшифровали ее первыми, шифрование должно быть автоматически расшифровано после того, как транзакция действительно была необратимо принята.
Для достижения этой формы шифрования существуют различные методы компромисса. Джон Шарбонно однажды хорошо выразился:
Шифрование централизованных операторов, таких как Flashbots Protect.
шифрование timelock, которое может быть расшифровано кем угодно после определенного последовательного шага вычислений и не может быть распараллелено;
Пороговое шифрование, доверив расшифровку данных комитету честного большинства. Конкретные рекомендации см. в разделе Концепция замкнутой маячковой цепи.
Надежное оборудование, такое как SGX.
К сожалению, у каждого шифрования есть свои слабые места. Несмотря на то, что для каждого решения существует подмножество пользователей, готовых доверять ему, ни одно из решений не является достаточно надежным, чтобы оно действительно было принято уровнем 1. Таким образом, по крайней мере, до тех пор, пока не будет усовершенствовано шифрование задержек или не будет достигнут какой-либо другой технологический прорыв, инкапсуляция функциональности защиты от продвинутой торговли на уровне 1 кажется сложной задачей, даже если это достаточно ценная функция, чтобы появилось множество прикладных решений.
Инкапсулированный стейкинг ликвидности
Распространенной потребностью пользователей Ethereum DeFi является возможность использовать свои ETH одновременно для стейкинга и в качестве залога в других приложениях. Еще одна распространенная потребность заключается в простом удобстве: пользователи хотят иметь возможность делать ставки (и защищать ключи онлайн-стейкинга) без сложностей, связанных с запуском узла и его постоянным подключением к сети.
До сих пор самым простым «интерфейсом» для стейкинга, который удовлетворяет обе эти потребности, является просто токен ERC 20: конвертируйте свои ETH в «стейкинг ETH», удерживайте их и конвертируйте обратно. На самом деле, поставщики ликвидности, такие как Lido и Rocket Pool, уже начали это делать. Тем не менее, стейкинг ликвидности имеет некоторые естественные механизмы централизации: люди, естественно, переходят в самую крупную версию стейкинга ETH, потому что она наиболее привычна и ликвидна.
Каждая версия стейкинга ETH требует определенного механизма для определения того, кто может быть базовым оператором узла. Он не может быть неограниченным, так как тогда злоумышленники присоединятся и усилят атаку за счет средств пользователя. В настоящее время двумя лидерами являются Lido, у которого есть оператор белого списка узлов DAO, и Rocket Pool, который позволяет любому запустить ноду с 8 ETH на депозите. Эти два метода имеют разные риски: подход Rocket Pool позволяет злоумышленникам проводить атаки 51% на сеть и вынуждает пользователей оплачивать большую часть стоимости; Что касается подхода DAO, то если определенный токен стейкинга доминирует, это приводит к тому, что один, потенциально атакуемый гаджет управления контролирует значительную часть всех валидаторов Ethereum. Конечно, такие протоколы, как Lido, уже имеют меры предосторожности, но уровня защиты может быть недостаточно.
В краткосрочной перспективе одним из вариантов является поощрение участников экосистемы к использованию широкого спектра поставщиков стейкинга ликвидности, чтобы снизить вероятность системного риска со стороны одной компании. В долгосрочной перспективе, однако, это шаткое равновесие, и опасно слишком полагаться на моральное давление для решения проблем. Возникает закономерный вопрос: есть ли смысл инкапсулировать в протокол какой-то функционал, чтобы сделать стейкинг ликвидности менее централизованным?
Ключевой вопрос здесь заключается в следующем: что это за функциональность в протоколе? Проблема с простым созданием взаимозаменяемого токена 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 R1, немного отличающейся эллиптической кривой, чем secp 256 K1 для базовых учетных записей Ethereum, поскольку она хорошо поддерживается доверенными аппаратными модулями, поэтому ее широкое использование может повысить безопасность кошельков. В последние годы сообщество также настаивало на добавлении предкомпиляций для BLS-12-377, BW 6-761, обобщенных пар и других функций.
Контраргумент против этих запросов на большее количество предварительно скомпилированных файлов заключается в том, что многие из предыдущих компиляций, добавленных ранее (например, RIPEMD и BLAKE), в конечном итоге используют гораздо меньше, чем ожидалось, и мы должны извлечь из них уроки. Вместо того, чтобы добавлять больше предварительной компиляции для конкретных операций, возможно, нам следует сосредоточиться на более щадящем подходе, основанном на таких идеях, как EVM-MAX и спящих, но всегда восстанавливаемых предложениях SIMD, которые позволят реализациям EVM выполнять широкий спектр классов кода с меньшими затратами. Возможно, даже существующая редко используемая предкомпиляция может быть удалена и заменена (неизбежно менее эффективной) реализацией кода EVM той же функции. Тем не менее, все еще возможно, что существуют определенные криптографические операции, которые достаточно ценны для ускорения, поэтому имеет смысл добавлять их в предварительно скомпилированном виде.
Какие уроки мы извлекли из всего этого?
Желание инкапсулировать как можно меньше понятно и хорошо; Он восходит к философской традиции Unix по созданию минималистичного программного обеспечения, которое может быть легко адаптировано к различным потребностям пользователей и избежать проклятия раздувания программного обеспечения. Однако блокчейн — это не персональная вычислительная операционная система, а социальная система. Это означает, что имеет смысл инкапсулировать определенный функционал в протокол.
Во многих случаях эти другие примеры похожи на то, что мы видим в абстракции аккаунта. Но мы также извлекли несколько новых уроков:
Инкапсуляция может помочь избежать риска централизации в других частях стека:
Зачастую, сохранение базового протокола минимальным и простым приводит к тому, что сложность выходит за рамки некоторых протоколов экосистемы. С философской точки зрения Unix это хорошо. Тем не менее, иногда существует риск того, что экосистемы вне протокола будут централизованы, обычно (но не только) из-за высоких фиксированных затрат. Инкапсуляция иногда может снизить фактическую централизацию.
Инкапсуляция слишком большого количества содержимого может чрезмерно увеличить нагрузку на доверие и управление протоколом:
Это тема предыдущей статьи «Не перегружайте консенсус Ethereum»: если инкапсуляция той или иной функции ослабляет модель доверия и делает Ethereum в целом более «субъективным», это ослабляет доверенный нейтралитет Ethereum. В этих случаях лучше представить конкретную функцию в виде механизма поверх Ethereum, чем пытаться внедрить ее в сам Ethereum. Здесь пулы зашифрованной памяти являются лучшим примером, и их может быть немного сложно инкапсулировать, по крайней мере, до тех пор, пока шифрование задержки не улучшится.
Инкапсуляция слишком большого количества может чрезмерно усложнить протокол:
Сложность протокола — это системный риск, который может быть увеличен за счет добавления в протокол слишком большого количества функций. Прекомпиляция — лучший тому пример.
В долгосрочной перспективе инкапсуляция функциональности может иметь неприятные последствия, поскольку потребности пользователей непредсказуемы:
Функция, которую многие считают важной и будет использоваться многими пользователями, скорее всего, не используется регулярно на практике.
Кроме того, стейкинг ликвидности, ZK-EVM и прекомпилированные кейсы показывают возможность срединного пути: минимально жизнеспособного закрепления. Протоколы не обязательно инкапсулируют всю функцию, но могут содержать конкретные части, которые решают ключевые проблемы, что делает функцию простой в реализации, не будучи слишком параноидальной или слишком узкой. Примеры:
Вместо того, чтобы инкапсулировать полную систему залога ликвидности, лучше изменить правила штрафа за стейкинг, чтобы сделать залог ликвидности без доверия более осуществимым;
Вместо того, чтобы инкапсулировать больше прекомпиляторов, инкапсулируйте EVM-MAX и/или SIMD, чтобы упростить эффективную реализацию для более широкого спектра рабочих категорий;
Верификация EVM может быть просто инкапсулирована вместо того, чтобы инкапсулировать всю концепцию свертки.
Мы можем развернуть предыдущую диаграмму следующим образом:
Иногда имеет смысл что-то обернуть, и удаление редко используемой прекомпиляции является тому примером. Абстракция аккаунта в целом, как упоминалось ранее, также является важной формой деинкапсуляции. Если мы хотим поддерживать обратную совместимость для существующих пользователей, механизм может быть поразительно похож на тот, который деинкапсулирует предварительно скомпилированную информацию: одним из предложений является EIP-5003, который позволит EOA конвертировать свои учетные записи в контракты с такой же (или лучшей) функциональностью.
Вопрос о том, какие функции должны быть введены в протокол, а какие должны быть оставлены на откуп другим слоям экосистемы, является сложным компромиссом. Ожидается, что этот компромисс будет продолжать улучшаться с течением времени, поскольку наше понимание потребностей пользователей, доступных идей и наборов технологий продолжает улучшаться.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Виталик Бутерин: Должен ли 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 до тех пор, пока стоимость по договору и стоимость доступа к хранилищу вне протокола не совпадут; Когда другие виды операций редактирования хранилища дешевле, нет смысла переводить ETH за 9000 газа. На самом деле, два EIP, связанных с предстоящим преобразованием дерева Verkle, на самом деле пытаются сделать именно это. Но даже если мы это сделаем, есть очевидная причина, по которой инкапсулированная функциональность протокола неизбежно будет намного дешевле, чем код EVM, независимо от того, насколько эффективным станет EVM: инкапсулированному коду не нужно платить газ за предварительную загрузку.
Полнофункциональный кошелек ERC-4337 имеет большой размер, а реализация, которая компилирует и помещает его в блокчейн, занимает около 12 800 байт. Конечно, вы можете развернуть этот код один раз и использовать DELEGATECALL, чтобы позволить каждому отдельному кошельку вызывать его, но вам все равно нужно получить доступ к коду в каждом блоке, который его использует. В соответствии с затратами на газ дерева Веркла EIP, 12 800 байт составят 413 блоков, и доступ к этим блокам потребует оплаты в 2 раза больше следящей ветки_cost (всего 3 800 газа) и в 413 раз больше следящего блока_cost (всего 82 600 газа). И это не говоря уже о самой точке входа ERC-4337, которая в версии 0.6.0 имеет 23 689 байт в цепочке (около 158 700 газа для загрузки по правилам дерева Verkle EIP).
Это приводит к проблеме: затраты на газ для фактического доступа к этим кодам должны каким-то образом амортизироваться по всей транзакции. Текущий подход, используемый ERC-4337, не очень хорош: первая транзакция в пакете потребляет единовременные затраты на хранение/чтение кода, что делает ее намного дороже, чем другие транзакции. Инкапсуляция в протоколе позволит этим публичным разделяемым библиотекам быть частью протокола и быть свободно доступными для всех.
Чему мы можем научиться из этого примера, и когда упаковка станет более распространенной? **
В этом примере мы видим несколько различных обоснований для инкапсуляции аспекта абстракции учетной записи в протоколе.
Рыночные подходы, которые «доводят сложность до предела», скорее всего, потерпят неудачу при высоких фиксированных затратах. На самом деле, долгосрочная дорожная карта абстракции аккаунта выглядит так, как будто каждый блок имеет много фиксированных затрат. 244, 100 газ для загрузки стандартизированных кодов кошельков - это одно; Но агрегация может добавить сотни тысяч газа к валидации ZK-SNARK, а также затраты на проверку Proof-of-Chain в цепочке. Нет никакого способа взимать с пользователей плату за эти расходы, не внося при этом много неэффективности рынка, и перевод некоторых из этих функций в функции протокола, к которым каждый может получить доступ бесплатно, хорошо решает эту проблему.
Реакция всего сообщества на ошибки в коде. Если какие-то фрагменты кода используются всеми пользователями или очень широким кругом пользователей, обычно блокчейн-сообществу имеет смысл взять на себя ответственность за хардфорк, чтобы исправить любые возникающие ошибки. ERC-4337 вводит большое количество глобально разделяемого кода, и исправление ошибок в коде с помощью хардфорка, несомненно, более разумно в долгосрочной перспективе, чем заставлять пользователей терять много ETH.
Иногда более сильная форма может быть достигнута за счет прямого использования функциональности протокола. Ключевым примером здесь является встроенная функция защиты от цензуры, такая как список включения: список включения в протоколе может гарантировать устойчивость к цензуре лучше, чем метод вне протокола, и для того, чтобы операции на уровне пользователя действительно могли извлечь выгоду из списка включения в протоколе, одна операция на уровне пользователя должна быть «читаемой» для протокола. Другим менее известным примером является дизайн Ethereum Proof-of-Stake 2017 года, в котором абстрагировался ключевой счет стейка, от которого отказались в пользу инкапсуляции BLS, поскольку BLS поддерживает механизм «агрегации», который должен быть реализован на уровне протокола и сети, что может сделать обработку большого количества подписей более эффективной.
Но важно помнить, что даже инкапсуляция внутрипротокольной абстракции учетной записи по-прежнему является огромной «деинкапсуляцией» по сравнению с текущей ситуацией. Сегодня транзакции Ethereum высшего уровня могут быть инициированы только с внешних учетных записей (EOA), которые проверены с помощью одной подписи эллиптической кривой secp 256k1. Абстракция учетной записи устраняет это и оставляет критерии проверки на усмотрение пользователя. Таким образом, в этой истории об абстракции учетной записи мы также видим самый большой аргумент против инкапсуляции: гибкость для удовлетворения потребностей разных пользователей.
Давайте конкретизируем эту историю, рассмотрев несколько других примеров функций, которые недавно считались инкапсулированными. Особое внимание мы уделим: ZK-EVM, разделению proposer и builder, приватным мемпулам, стейкингу ликвидности и новой прекомпиляции.
Пакет ZK-EVM
Давайте обратим внимание на еще одну потенциальную цель инкапсуляции протокола Ethereum: ZK-EVM. В настоящее время у нас есть большое количество ZK-роллапов, каждый из которых должен писать довольно похожий код для проверки выполнения аналогичных блоков Ethereum в ZK-SNARK. Существует достаточно разнообразная экосистема независимых реализаций: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth и многие другие.
Недавний спор в пространстве EVM ZK-rollup связан с тем, как обрабатывать возможные ошибки в коде ZK. В настоящее время все эти работающие системы имеют тот или иной механизм «Совета Безопасности», который контролирует систему аттестации в случае ошибок. В прошлом году я попытался создать стандартизированную структуру, чтобы стимулировать проекты к уточнению уровня доверия к системе сертификации, а также к Совету Безопасности, и постепенно снижать свои полномочия над организацией с течением времени.
В среднесрочной перспективе «роллапы» могут опираться на несколько систем аттестации, и Совет Безопасности будет иметь полномочия только в крайних случаях, когда две различные системы аттестации расходятся.
Однако есть ощущение, что часть работы кажется избыточной. У нас уже есть базовый уровень Ethereum, у него есть EVM, и у нас уже есть работающий механизм обработки багов в реализации: если есть баг, клиент обновится, чтобы его исправить, и тогда цепочка продолжит функционировать. С точки зрения глючного клиента, кажется, что блоки, которые были завершены, больше не будут подтверждаться, но, по крайней мере, мы не увидим, как пользователи теряют деньги. Точно так же, если роллапы просто хотят сохранить свою роль, эквивалентную EVM, то им необходимо внедрить собственное управление, чтобы постоянно изменять свои внутренние правила ZK-EVM, чтобы соответствовать обновлениям базового уровня Ethereum, что кажется неправильным, потому что в конечном итоге они построены поверх самого базового уровня Ethereum, который знает, когда обновляться и в соответствии с какими новыми правилами.
Поскольку эти L2 ZK-EVM в основном используют точно такие же EVM, как и Ethereum, можем ли мы каким-то образом включить «проверку выполнения EVM в ZK» в функцию протокола и обрабатывать исключения, такие как ошибки и обновления, применяя социальный консенсус Ethereum, как мы уже делаем с самой реализацией EVM базового уровня?
Это важная и сложная тема.
Одной из возможных тем дебатов о доступности данных в нативном ZK-EVM является состояние состояния. Если бы ЗК-ЭВМ не нужно было передавать «свидетельские» данные, их эффективность была бы намного выше. То есть, если определенный фрагмент данных уже был прочитан или записан в каком-то предыдущем блоке, мы можем просто предположить, что прувер имеет к нему доступ и не должен делать его снова доступным. Речь идет не только о том, чтобы не перезагружать хранилище и код; Оказывается, что сжатие с отслеживанием состояния может сэкономить до 3 раз данных по сравнению со сжатием без отслеживания состояния, если один свертка сжимает данные правильно.
Это означает, что для прекомпиляции ZK-EVM у нас есть два варианта:
Предварительная компиляция требует, чтобы все данные были доступны в одном блоке. Это означает, что прувер может быть без сохранения состояния, но это также означает, что использование этого предварительно скомпилированного ZK-роллапа намного дороже, чем использование роллапа с пользовательским кодом.
Предварительная компиляция позволяет указателю указывать на ранее выполненные, использованные или сгенерированные данные. Это делает ZK-rollup почти оптимальным, но он более сложен и вводит новое состояние, которое должно быть сохранено prover.
Какие уроки мы можем извлечь из этого? Есть веская причина, чтобы каким-то образом инкапсулировать верификацию ZK-EVM: роллап уже создает свою собственную пользовательскую версию, а Ethereum готов взвесить свои многочисленные реализации и социальный консенсус вне блокчейна на L1 для выполнения EVM, что кажется неправильным, но L2, выполняя точно такую же работу, должен внедрять сложные гаджеты с участием Совета Безопасности. Но с другой стороны, есть большая проблема в деталях: существуют разные версии ЗК-ЭВМ, которые отличаются по стоимости и пользе. Различие между состоянием и состоянием без него лишь поверхностно; Попытка поддержки «почти-EVM», пользовательских кодов, которые были проверены другими системами, может открыть больше пространства для дизайна. Таким образом, инкапсуляция ZK-EVM представляет собой как перспективы, так и проблемы.
Разделение оболочки и сборщика (ePBS)
Рост популярности MEV превратил производство блоков в крупномасштабную экономическую деятельность, в которой сложные участники могут производить блоки, которые приносят больше дохода, чем алгоритм по умолчанию, который просто наблюдает за мемпулом транзакций и содержит их. До сих пор сообщество Ethereum пыталось решить эту проблему, используя внепротокольную схему разделения proposer-builder, такую как MEV-Boost, которая позволяет обычным валидаторам («proposers») передавать строительство блоков на аутсорсинг специализированным участникам («строителям»).
Тем не менее, MEV-Boost делает предположения о доверии к новому классу участников, называемому эстафетами. За последние два года поступило много предложений о создании «инкапсулированной PBS». Какие преимущества это дает? В этом случае ответ прост: PBS, построенная непосредственно с использованием функций протокола, является более мощной (в том смысле, что имеет более слабые предположения о доверии), чем PBS, построенная без них. Это похоже на случай с ценовыми оракулами в протоколе инкапсуляции, хотя в этом случае также есть сильное противодействие.
Инкапсуляция частного пула памяти
Когда пользователь отправляет транзакцию, она сразу становится публичной и видимой для всех, даже до того, как она будет включена в цепочку. Это делает пользователей многих приложений уязвимыми для экономических атак, таких как вытесняющие транзакции.
В последнее время появилось несколько проектов, посвященных созданию «приватных мемпулов» (или «зашифрованных мемпулов»), которые шифруют транзакции пользователей до тех пор, пока они не будут необратимо приняты в блок.
Проблема, однако, заключается в том, что такие схемы требуют особого вида шифрования: для того, чтобы пользователи не наводнили систему и не расшифровали ее первыми, шифрование должно быть автоматически расшифровано после того, как транзакция действительно была необратимо принята.
Для достижения этой формы шифрования существуют различные методы компромисса. Джон Шарбонно однажды хорошо выразился:
Шифрование централизованных операторов, таких как Flashbots Protect.
шифрование timelock, которое может быть расшифровано кем угодно после определенного последовательного шага вычислений и не может быть распараллелено;
Пороговое шифрование, доверив расшифровку данных комитету честного большинства. Конкретные рекомендации см. в разделе Концепция замкнутой маячковой цепи.
Надежное оборудование, такое как SGX.
К сожалению, у каждого шифрования есть свои слабые места. Несмотря на то, что для каждого решения существует подмножество пользователей, готовых доверять ему, ни одно из решений не является достаточно надежным, чтобы оно действительно было принято уровнем 1. Таким образом, по крайней мере, до тех пор, пока не будет усовершенствовано шифрование задержек или не будет достигнут какой-либо другой технологический прорыв, инкапсуляция функциональности защиты от продвинутой торговли на уровне 1 кажется сложной задачей, даже если это достаточно ценная функция, чтобы появилось множество прикладных решений.
Инкапсулированный стейкинг ликвидности
Распространенной потребностью пользователей Ethereum DeFi является возможность использовать свои ETH одновременно для стейкинга и в качестве залога в других приложениях. Еще одна распространенная потребность заключается в простом удобстве: пользователи хотят иметь возможность делать ставки (и защищать ключи онлайн-стейкинга) без сложностей, связанных с запуском узла и его постоянным подключением к сети.
До сих пор самым простым «интерфейсом» для стейкинга, который удовлетворяет обе эти потребности, является просто токен ERC 20: конвертируйте свои ETH в «стейкинг ETH», удерживайте их и конвертируйте обратно. На самом деле, поставщики ликвидности, такие как Lido и Rocket Pool, уже начали это делать. Тем не менее, стейкинг ликвидности имеет некоторые естественные механизмы централизации: люди, естественно, переходят в самую крупную версию стейкинга ETH, потому что она наиболее привычна и ликвидна.
Каждая версия стейкинга ETH требует определенного механизма для определения того, кто может быть базовым оператором узла. Он не может быть неограниченным, так как тогда злоумышленники присоединятся и усилят атаку за счет средств пользователя. В настоящее время двумя лидерами являются Lido, у которого есть оператор белого списка узлов DAO, и Rocket Pool, который позволяет любому запустить ноду с 8 ETH на депозите. Эти два метода имеют разные риски: подход Rocket Pool позволяет злоумышленникам проводить атаки 51% на сеть и вынуждает пользователей оплачивать большую часть стоимости; Что касается подхода DAO, то если определенный токен стейкинга доминирует, это приводит к тому, что один, потенциально атакуемый гаджет управления контролирует значительную часть всех валидаторов Ethereum. Конечно, такие протоколы, как Lido, уже имеют меры предосторожности, но уровня защиты может быть недостаточно.
В краткосрочной перспективе одним из вариантов является поощрение участников экосистемы к использованию широкого спектра поставщиков стейкинга ликвидности, чтобы снизить вероятность системного риска со стороны одной компании. В долгосрочной перспективе, однако, это шаткое равновесие, и опасно слишком полагаться на моральное давление для решения проблем. Возникает закономерный вопрос: есть ли смысл инкапсулировать в протокол какой-то функционал, чтобы сделать стейкинг ликвидности менее централизованным?
Ключевой вопрос здесь заключается в следующем: что это за функциональность в протоколе? Проблема с простым созданием взаимозаменяемого токена 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 R1, немного отличающейся эллиптической кривой, чем secp 256 K1 для базовых учетных записей Ethereum, поскольку она хорошо поддерживается доверенными аппаратными модулями, поэтому ее широкое использование может повысить безопасность кошельков. В последние годы сообщество также настаивало на добавлении предкомпиляций для BLS-12-377, BW 6-761, обобщенных пар и других функций.
Контраргумент против этих запросов на большее количество предварительно скомпилированных файлов заключается в том, что многие из предыдущих компиляций, добавленных ранее (например, RIPEMD и BLAKE), в конечном итоге используют гораздо меньше, чем ожидалось, и мы должны извлечь из них уроки. Вместо того, чтобы добавлять больше предварительной компиляции для конкретных операций, возможно, нам следует сосредоточиться на более щадящем подходе, основанном на таких идеях, как EVM-MAX и спящих, но всегда восстанавливаемых предложениях SIMD, которые позволят реализациям EVM выполнять широкий спектр классов кода с меньшими затратами. Возможно, даже существующая редко используемая предкомпиляция может быть удалена и заменена (неизбежно менее эффективной) реализацией кода EVM той же функции. Тем не менее, все еще возможно, что существуют определенные криптографические операции, которые достаточно ценны для ускорения, поэтому имеет смысл добавлять их в предварительно скомпилированном виде.
Какие уроки мы извлекли из всего этого?
Желание инкапсулировать как можно меньше понятно и хорошо; Он восходит к философской традиции Unix по созданию минималистичного программного обеспечения, которое может быть легко адаптировано к различным потребностям пользователей и избежать проклятия раздувания программного обеспечения. Однако блокчейн — это не персональная вычислительная операционная система, а социальная система. Это означает, что имеет смысл инкапсулировать определенный функционал в протокол.
Во многих случаях эти другие примеры похожи на то, что мы видим в абстракции аккаунта. Но мы также извлекли несколько новых уроков:
Инкапсуляция может помочь избежать риска централизации в других частях стека:
Зачастую, сохранение базового протокола минимальным и простым приводит к тому, что сложность выходит за рамки некоторых протоколов экосистемы. С философской точки зрения Unix это хорошо. Тем не менее, иногда существует риск того, что экосистемы вне протокола будут централизованы, обычно (но не только) из-за высоких фиксированных затрат. Инкапсуляция иногда может снизить фактическую централизацию.
Инкапсуляция слишком большого количества содержимого может чрезмерно увеличить нагрузку на доверие и управление протоколом:
Это тема предыдущей статьи «Не перегружайте консенсус Ethereum»: если инкапсуляция той или иной функции ослабляет модель доверия и делает Ethereum в целом более «субъективным», это ослабляет доверенный нейтралитет Ethereum. В этих случаях лучше представить конкретную функцию в виде механизма поверх Ethereum, чем пытаться внедрить ее в сам Ethereum. Здесь пулы зашифрованной памяти являются лучшим примером, и их может быть немного сложно инкапсулировать, по крайней мере, до тех пор, пока шифрование задержки не улучшится.
Инкапсуляция слишком большого количества может чрезмерно усложнить протокол:
Сложность протокола — это системный риск, который может быть увеличен за счет добавления в протокол слишком большого количества функций. Прекомпиляция — лучший тому пример.
В долгосрочной перспективе инкапсуляция функциональности может иметь неприятные последствия, поскольку потребности пользователей непредсказуемы:
Функция, которую многие считают важной и будет использоваться многими пользователями, скорее всего, не используется регулярно на практике.
Кроме того, стейкинг ликвидности, ZK-EVM и прекомпилированные кейсы показывают возможность срединного пути: минимально жизнеспособного закрепления. Протоколы не обязательно инкапсулируют всю функцию, но могут содержать конкретные части, которые решают ключевые проблемы, что делает функцию простой в реализации, не будучи слишком параноидальной или слишком узкой. Примеры:
Вместо того, чтобы инкапсулировать полную систему залога ликвидности, лучше изменить правила штрафа за стейкинг, чтобы сделать залог ликвидности без доверия более осуществимым;
Вместо того, чтобы инкапсулировать больше прекомпиляторов, инкапсулируйте EVM-MAX и/или SIMD, чтобы упростить эффективную реализацию для более широкого спектра рабочих категорий;
Верификация EVM может быть просто инкапсулирована вместо того, чтобы инкапсулировать всю концепцию свертки.
Мы можем развернуть предыдущую диаграмму следующим образом:
Иногда имеет смысл что-то обернуть, и удаление редко используемой прекомпиляции является тому примером. Абстракция аккаунта в целом, как упоминалось ранее, также является важной формой деинкапсуляции. Если мы хотим поддерживать обратную совместимость для существующих пользователей, механизм может быть поразительно похож на тот, который деинкапсулирует предварительно скомпилированную информацию: одним из предложений является EIP-5003, который позволит EOA конвертировать свои учетные записи в контракты с такой же (или лучшей) функциональностью.
Вопрос о том, какие функции должны быть введены в протокол, а какие должны быть оставлены на откуп другим слоям экосистемы, является сложным компромиссом. Ожидается, что этот компромисс будет продолжать улучшаться с течением времени, поскольку наше понимание потребностей пользователей, доступных идей и наборов технологий продолжает улучшаться.