Снова масштабировать L2s

Перепостите оригинальный заголовок: Sharded L2? "=nil;" Как предложить новое решение для фрагментации состояния L2?

Переход Ethereum к центрированной на rollup дорожной карте вызвал взрывной рост модульных дизайнов масштабирования. Этот рост изначально был успешным, устраняя комиссии за газ в размере $100+ и открывая совершенно новые дизайны приложений. Но всего лишь через несколько лет Ethereum и его rollups столкнулись с новой, критической проблемой: фрагментацией состояния.

В основе фрагментации состояния лежит проблема масштабирования. Недавно сообщество модульности предложило промежуточные решения, объединяющие существующие роллапы в единую систему, (по-видимому) достигая священной грааля масштабируемости блокчейна - горизонтальной масштабируемости. Однако эти решения сопряжены с существенными компромиссами. Новое поколение решений L2 для Ethereum переосмысливает масштабируемость с первых принципов, применяя вертикальные и горизонтальные техники для достижения конечной производительности.

Два направления масштабирования блокчейнаСуществует две рамки для масштабирования блокчейна:

• Вертикальное масштабированиеувеличивает ресурсы, доступные для одного узла. Это философия масштабирования Solana, направленная на максимизацию использования аппаратного обеспечения, а также параллельное движение виртуальной машины (VM).- Горизонтальное масштабированиераспределяет нагрузку между несколькими серверами. Это философия масштабирования осколочных блокчейнов L1, таких как Near и Ethereum (Danksharding).

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

Вызов впередиФрагментация состояния по всему L2 превратилась в серьезную проблему для Ethereum. Фрагментация определяется тремя новыми проблемами.

• Компрометированные сетевые эффекты глобального состояния, включая ликвидность и распределение пользователей, имеют корни в десятках (если не сотнях) Ethereum смежных L2s, которые нацелены на инфраструктуру, специфичную для приложений.- Усложнение сложности стандартов взаимодействия и социальной координации, которое стало катализатором свыше $2.8 миллиарда хакерских атак.- Объективно ухудшился опыт разработчиков и пользователей. Разработчики должны работать с запутанными сетевыми абстракциями, чтобы обеспечить бесперебойный пользовательский опыт, илипользователи вынуждены управлять сложностью взаимодействия между цепями, включая мосты активов, управление сетью кошельков и несколько токенов газа.И эти проблемы усугубляются с каждым днем. Ограниченные существующей инфраструктурой, приложения, чувствительные к цене, вынуждены изолироваться, чтобы сохранить надежно низкие комиссии за транзакции. По мере приближения следующего цикла, должен произойти зловещий снежный комок; по мере увеличения сбоев L2, все больше разработчиков вынуждены выбирать инфраструктуру, специфичную для приложения, усугубляя (уже) всеобщие проблемы, связанные с фрагментацией состояния. Через несколько лет не удивлюсь, если неспособность L2 решить проблему фрагментации состояния приведет к краху доминирования приложений в экосистеме Ethereum.

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

• Объедините существующие роллапы в единую систему, тем самым достигнув «горизонтальной масштабируемости».- Начните с чистого листа и разработайте масштабируемый уровень L2.## Работа назадПервый подход довольно популярен среди существующих L2. Объединение роллапов достигается с использованием промежуточного программного обеспечения для установления представления о единой системе. Фактически, эти решения облегчают коммуникацию между роллапами через общие гарантии консенсуса. Такие решения включают общие последователи, общие доказатели и различные архитектуры L3.

Хотя команды и проекты, работающие над этими решениями, являются сильными, подход, сосредоточенный на промежуточном ПО, к решению масштабируемости L2 сопряжен с существенными компромиссами, включая:

• Уязвимости самой слабой цепи: безопасность и свойства сети наследуются от самого плохого элемента стека.- Фрагментированная среда разработки: различные среды, связанные средствами промежуточного программного обеспечения, все равно приводят к фрагментированному опыту разработки.- Глобальная социальная координация стандартов межслоенной совместимости: для слияния существующих слоев необходимо, чтобы сотни (потенциально тысячи) заинтересованных сторон согласились на лучшие практики.Более критично, это отвлекает команды L2 от решения открытых проблем тарифирования наложения и цензуры одного актёра, для которых требуются значительные инженерные и исследовательские усилия.

Новый стартL2 сети Ethereum могут быть масштабированы вертикально путем изменения среды выполнения узла rollup для увеличения использования аппаратных средств; такие проекты включают Eclipse и Movement Labs, которые строят rollups, используя SVM и MoveVM, соответственно. Этот подход обещает значительное улучшение масштабируемости в ближайшей перспективе; однако для этого требуется, чтобы разработчики Ethereum приняли новый технологический стек.

В качестве альтернативы L2 могут горизонтально масштабироваться путем (пере)введения исполнения шардинга, что позволит сети масштабироваться путем добавления новых узлов. Этот подход способствует децентрализации, имеет более высокие теоретические пределы масштабирования и позволяет проводить вертикальные оптимизации масштабирования при необходимости. Учитывая эти преимущества, =nil; Foundation разработала шардированный L2 под названием =nil;.

=nil; оптимизирует сохранение основных ценностей Эфириума: децентрализации, устойчивости к цензуре и отсутствию разрешений. =nil; является первой проверяемой архитектурой шардинга на основе новаторского дизайна, zkShardingОн позволяет масштабировать свойства вышеприведенных фреймворков горизонтального масштабирования после факта с дополнительным преимуществом единой интегрированной среды разработки. Это дает разработчикам доступ к масштабу тысяч rollups из одной сети. Что более важно, =nil; обеспечивает пользователям надежно низкие комиссии за транзакции даже во время пиковой загрузки транзакций.

Более того, =nil; решает проблемы перегрузки путем динамического разделения и объединения состояния между фрагментами на основе спроса на доступ к состоянию. Такое динамичное поведение позволяет =nil; сохранять надежно низкие комиссии за транзакции (- Эта статья воспроизведена из [ foresightnews] , авторские права принадлежат оригинальному автору [Avi Zurlo,=nil; Фонд], если у вас есть возражения против перепечатки, пожалуйста, свяжитесь [Команда Gate Learn](https://www.Gate.com/questionnaire/3967, команда обработает это как можно скорее в соответствии с соответствующими процедурами.

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

• Другие языковые версии статьи переведены командой Gate Learn и не упоминаются в [](http://Gate.comGate.com , переведенная статья не может быть воспроизведена, распространена или использована в качестве плагиата.