Виталик Бутерин, основатель Ethereum, недавно опубликовал новую статью «Следует ли включить больше функций в базовый протокол Ethereum?» 》, в статье обсуждается необходимость включения многих используемых в настоящее время технологий в базовый протокол Ethereum, а также приводятся стандарты для технических суждений.
(Эта статья представляет собой перевод и ключевую компиляцию Lian News. Если у вас есть какие-либо вопросы, обратитесь к исходному тексту.)
Следует ли включить больше функций в базовый протокол Ethereum?
С самого начала проекта Ethereum существовала сильная философия, заключающаяся в том, чтобы попытаться сделать ядро Ethereum как можно более простым и сделать как можно больше, создавая на его основе протоколы.
В сфере блокчейна дебаты «делать это непосредственно на L1» и «сосредоточиться на L2» часто рассматриваются как прежде всего вопросы масштабирования, но на самом деле существуют схожие проблемы с удовлетворением потребностей множества пользователей Ethereum. Проблемы: цифровые. обмен активами, конфиденциальность, имена пользователей, расширенная криптография, безопасность учетных записей, устойчивость к цензуре, оперативная защита и многое другое. Однако в последнее время высказываются опасения по поводу готовности включить больше этих функций в основной протокол Ethereum.
В этой статье будут рассмотрены некоторые философские рассуждения, лежащие в основе оригинальной философии минимальной инклюзивности, а также некоторые новейшие способы размышления об этих идеях. Цель состоит в том, чтобы начать создавать структуру для лучшего определения возможных целей, где включение определенных возможностей в соглашение может быть достойным рассмотрения.
Включено в ERC-4337.
Обсуждается несколько основных причин, почему ERC-4337 следует интегрировать в Ethereum, а именно:
Эффективность газа: все, что выполняется внутри EVM, требует некоторой платы за виртуальную машину, в настоящее время эти неэффективные функции добавляют как минимум ~ 20 000 газа, и интеграция этого компонента в протокол — самый простой способ решить эту проблему.
Риск уязвимости программного кода: если во входном контракте ERC-4337 есть серьезные ошибки, то все кошельки, совместимые с ERC-4337, будут иметь кражу активов. Если контракт будет заменен встроенной функцией протокола, ответственность будет передана. Ethereum, поэтому проблемы риска капитала пользователей могут быть решены посредством хард-форков.
Поддержка кодов операций EVM: как и tx.origin, собственная абстракция учетной записи может указывать tx.origin на реальную учетную запись и отправлять транзакции, благодаря чему она работает как EOA.
Устойчивость к цензуре: ERC-4337 дополнительного протокола инкапсулирует действия пользователя в одну транзакцию, что делает действия пользователя непрозрачными для протокола Ethereum. Таким образом, список включения, предоставленный протоколом Ethereum, не обеспечит устойчивость к цензуре для пользовательских операций ERC-4337. Эта проблема будет решена за счет внедрения ERC-4337 и рассмотрения пользовательских операций как «подходящих» типов транзакций.
Среди этих причин Виталик особое внимание уделяет эффективности затрат на газ. В своем нынешнем виде ERC-4337 значительно дороже «базовых» транзакций Ethereum: базовая транзакция стоит 21 000 Gas, а ERC-4337 — около 42 000 Gas.
Регистрация ZK-EVM
Поскольку L2 ZK-EVM по сути использует тот же EVM, что и Ethereum, можно ли каким-то образом превратить «проверку выполнения EVM в ZK» в функцию протокола? А в особых случаях, таких как ошибки и обновления, можно ли их устранить, просто применив социальный консенсус Ethereum?
Виталик предлагает некоторые нюансы:
Ethereum хочет позволить разным клиентам использовать разные системы доказательств. То есть для любой операции EVM, которая подтверждается с использованием системы ZK-SNARK, Ethereum хочет иметь механизмы, гарантирующие доступность базовых данных, чтобы можно было генерировать доказательства для других систем ZK-SNARK.
Хотя технология еще не развита, проверяемость все еще может потребоваться. Как и выше, если какая-либо операция доказана, Ethereum хочет, чтобы базовые данные были доступны, чтобы пользователи и разработчики могли проверить их в случае возникновения каких-либо проблем.
Необходимо сократить время проверки, чтобы в случае создания одного типа доказательств другие типы доказательств могли быть созданы достаточно быстро, чтобы другие клиенты могли их проверить. Одним из решений является создание прекомпилятора, который реагирует асинхронно через некоторый период времени, превышающий один слот, но это добавляет сложности.
Ethereum надеется поддерживать не только реплики EVM, но и «почти EVM»-системы. Было бы неплохо, если бы L2 мог по-прежнему использовать ZK-EVM в собственном протоколе для обработки тех же частей, что и EVM, и просто полагаться на свой собственный код для обработки разных частей. Это достигается путем разработки предварительной компиляции ZK-EVM, позволяющей вызывающей стороне указать битовое поле, список кодов операций или список адресов, которые будут обрабатываться внешней таблицей, а не самим EVM. Это также позволяет в определенной степени регулировать расходы на газ.
Таким образом, Виталик считает, что аргумент в пользу внедрения ZK-EVM вполне убедителен: Rollup уже создает свою собственную адаптированную версию. Кажется правильным, что L2 должен реализовать сложную структуру, включающую комитет по безопасности, чтобы выполнить ту же работу.
Включено в частный временный пул (Mempool)
Чтобы избежать сэндвич-атак из-за прозрачного характера транзакций блокчейна, частные промежуточные пулы будут предназначены для хранения транзакций пользователей в зашифрованном виде до тех пор, пока они не будут необратимо приняты в блок. Для достижения этой формы шифрования используются разные технологии и разные компромиссы, но все они требуют помощи централизованного оператора.
В связи с этим Виталик считает, что решения этих централизованных организаций имеют разные недостатки: централизованные операторы не могут быть приняты как часть протокола, а традиционный метод шифрования с блокировкой по времени также слишком дорог для запуска в общедоступном временном пуле. обрабатывать тысячи транзакций.
Включите ставку ликвидности
Чтобы удовлетворить потребности пользователей в ставках на Ethereum, протоколы LSD, такие как Lido и Rocketpool, предоставляют простые интерфейсы, которые позволяют пользователям делать ставки одним щелчком мыши. Однако Виталик отметил, что стейкинг ликвидности имеет естественный централизованный механизм: люди склонны использовать крупнейший протокол ставок, потому что он самый известный и обладает лучшей мобильностью. Но Виталик указал на проблемы, с которыми столкнулись Lido и Rocketpool соответственно.
Поскольку пользователям Rocketpool для запуска узла требуется всего 8ETH, это позволяет злоумышленникам провести атаку 51% на сеть. Что касается узла, ответственного за аудит Lido DAO, то если на долю одного залогового кредита приходится большая часть, это приведет к единственному, потенциально уязвимому для атаки управленческому риску. Хотя Lido реализовал соответствующие механизмы защиты, одного уровня защиты может быть недостаточно.
В краткосрочной перспективе, считает Виталик, сообщество можно побудить к использованию различных типов протоколов ЛСД, чтобы снизить риск централизации, но это не стабильный подход. Итак, имеет ли смысл включить в протокол какую-то функциональность, чтобы сделать ставку ликвидности менее централизованной?
В этой связи Виталик сказал, что ключевой вопрос – какие функции следует включить? Он считает, что RocketPool уже обеспечивает жизнеспособный способ работы: каждый оператор узла предоставляет часть ETH, а участники ликвидности предоставляют оставшуюся часть ETH. Просто настройте некоторые параметры, такие как корректировка Slashing Penalty до 2ETH, и существующий rETH Rocket Pool станет безрисковым.
Включите больше прекомпиляций
Предварительная компиляция — это компромисс, принятый на заре разработки Ethereum: поскольку накладные расходы виртуальной машины слишком велики для некоторого очень сложного и узкоспециализированного кода, некоторые из них можно реализовать в собственном коде, который очень ценен для ключа приложения. операции по увеличению скорости.
Однако Виталик считает, что многие из добавленных ранее прекомпиляторов (таких как RIPEMD и BLAKE) в конечном итоге использовались гораздо меньше, чем ожидалось. Теперь нам не следует продолжать концентрироваться на добавлении большего количества прекомпиляторов для конкретных операций, а следует сосредоточиться на более скромных методах. например, это предложение EVM-MAX и SIMD. Можно даже удалить редко используемую сейчас прекомпиляцию и заменить ее кодом EVM, обеспечивающим ту же функциональность.
Что Виталик хочет нам сказать?
В этой статье подчеркивается баланс между минимализмом, вдохновленным философией Unix, и включением функций в протоколы блокчейна. В отличие от операционных систем персональных компьютеров, блокчейны являются социальными системами и поэтому требуют учета различных факторов. Основные моменты из статьи включают в себя:
Закрепление функций. Включение функций может предотвратить риски централизации. Однако если зайти слишком далеко, это может увеличить нагрузку на управление, усложнить протокол и может оказаться несовместимым с долгосрочными потребностями пользователей.
Средний путь: Одним из возможных решений является «минимальное жизнеспособное включение». Вместо того, чтобы интегрировать всю функцию, протокол может использовать только ключевые компоненты, которые упрощают реализацию этой функции. Например, изменение правил штрафов за ликвидные ставки, включение EVM-MAX для расширения объема операций или просто включение проверки EVM вместо всей концепции объединения.
Деэншрин: Удаление определенных функций может быть полезным, особенно если они используются редко. Например: некоторые прекомпиляции.
В конечном счете, решение о том, какие функции следует интегрировать в протокол, а какие оставить другим уровням экосистемы, является сложной проблемой. Этот баланс может со временем измениться по мере развития потребностей пользователей и доступных технологий.
Эта статья Блокчейн — это социальная система, а не персональный компьютер! Виталик рассуждает: следует ли включить больше функций в базовый уровень Ethereum? Впервые появилось в новостях сети ABMedia.
