Виталик Бутерин рассказал о классификации L2-решений
- Сооснователь Ethereum опубликовал новую статью.
- В ней он размышляет о классификации L2 и методах их подключения к L1.
Сооснователь Ethereum Виталик Бутерин предложил свое видение классификации решений второго уровня (L2) в новой статье.
«L2-экосистема Ethereum в последний год стремительно расширялась. Экосистема роллапов EVM, в которую традиционно входят Arbitrum, Optimism и Scroll, а в последнее время — Kakarot и Taiko, быстро растет, делая большие успехи в сфере безопасности. […] Мы видели, как команды, разрабатывающие сайдчейны, начинают создавать роллапы (Polygon), L1-решения, что стремятся стать валидиумами (Celo), и совершенно новые продукты (Linea, Zeth)», — подчеркнул Бутерин.
Это решение для масштабирования Ethereum, которое использует доступность данных и вычислений вне цепочки и предназначено для повышения пропускной способности за счет обработки транзакций вне сети.
Подобно zk-Rollups, валидиумы публикуют ZKP-доказательства для проверки офчейн-транзакций. При этом цепочка валидиума управляется смарт-контрактами, развернутыми в мейннете Ethereum.
По мнению Бутерина, текущая тенденция развития сегмента L2-решений привела к определенной «размытости» понятий. Более того, он считает, что в будущем это практика сохранится ввиду определенных факторов:
- некоторые L1-сети позднее могут превратиться в L2-решения поверх Ethereum;
- часть централизованных проектов изучает возможности блокчейна для обеспечения клиентам определенных «гарантий безопасности». Однако они нуждаются только в «промежуточном» уровне децентрализации;
- нефинансовые приложения, игры и социальные сети тяготеют к децентрализации, но им необходим «промежуточный» уровень безопасности.
Однако, со слов Бутерина, тут возникает определенная проблема. Если пользователи Ethereum готовы платить небольшую комиссию за использование роллапов, то все остальные, незнакомые с миром блокчейна, — нет.
На фоне этого возникает вопрос, на какой компромисс готовы пойти подобные централизованные проекты и небольшие приложения?
Роллапы, валидиумы и автономные системы
По мнению Бутерина, один из основных вопросов является гарантия возврата переданного в L2 актива обратно в основную сеть. Он пояснил, что различные системы решают проблему по-разному:
- роллап. Данные хранятся на L1, используются доказательства с нулевой степенью разглашения. В этом случае пользователь всегда может вернуть актив с L2 на L1. Однако этот тип системы сопряжен с высокими расходами;
- валидиум. Данные хранятся на сервере или в отдельной системе. Для доказательства используются только ZK-SNARKS. Активы могут быть потеряны, но не украдены;
- без подключения. Данные хранятся в отдельной сети или на выделенном сервере. Необходимость доверить средства одному человеку или группе. Низкие расходы.
Однако, по словам Бутерина, это упрощенная классификация. Она не включает определенные промежуточные варианты, выбор между которыми обусловлен двумя основными факторами:
- доступность данных Ethereum;
- специфика конкретного приложения.
В качестве примера он приводит такую схему:
Доверительное чтение Ethereum
Тут Бутерин рассматривает еще одну форму соединения — когда сеть способна следить за изменением состояния базового блокчейна. По мнению автора, это крайне ценно по двум основным причинам:
- минимизация рисков, связанных с подключением токенов к этой верхней цепочке;
- кошельки, созданные на базе стандарта абстракции учетных записей, смогут безопасно хранить активы в этой сети.
Может ли цепочка стать валидиумом посредством моста?
Бутерин считает, что это «почти достаточное» решение в случае использования мостовых контрактов с двухсторонней проверкой. Однако в случае появления «исключительного» сбоя единственной гарантией останется социальное обязательство — форк при выходе из строя основной сети.
Выводы
Бутерин выделил два основных аспекта «подключенности» цепочки к сети Ethereum:
- безопасность вывода средств в L1;
- безопасность чтения L1.
По мнению Бутерина, оба этих критерия, а также проекты, которые их придерживаются, имеют собственную ценность. В отдельных случаях приложение может пожертвовать большей безопасностью в угоду масштабируемости. Для других более ценной представляется тесная взаимосвязь с основной сетью.
