Scroll Лианчуан: сложная проблема «курица и яйцо» развития экосистемы Эфира

Автор: Ye Zhang Источник: X, @yezhang1998 Перевод: Шан Оба, Золотые финансы

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

Я хочу выдвинуть еще три дополнительных момента здесь:

1.Инфраструктура должна быстрее адаптироваться к изменениям Layer 2, иначе у экосистемы Ethereum есть риск потерять привлекательность в целом.

Люди в целом ожидают более быстрого развития решений Layer 2. Однако это представляет собой значительные вызовы, поскольку скорость адаптации многих инфраструктур очень низкая. Даже если Scroll полностью совместим с EVM, у нас все равно возникают проблемы с MetaMask:

Стоимость транзакции на Scroll (или любом другом Layer 2) включает в себя плату за доступность данных (DA) и исполнение, но MetaMask по умолчанию поддерживает только плату за исполнение, что привело к неправильному расчету сборов в течение нескольких месяцев.

Это создает затруднительную ситуацию с вопросом о том, что было раньше - яйцо или курица:

Если Layer 1 не изменится, то поставщики инфраструктуры не будут иметь стимула обновляться. Без обновленной инфраструктуры решения Layer 2 не смогут развиваться быстрее и подавлять инновации. Это представляет особую проблему для Ethereum, поскольку у большинства других блокчейнов есть собственные кошельки, тесно связанные с обновлениями цепи. В отличие от этого, стандарт EVM следует Ethereum, что делает адаптацию сложной.

2. Стандарты крайне важны, и в настоящее время все решения Layer 2 не имеют стандартов

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

Правильный подход должен быть:

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

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

3. Также важно обратить внимание на различия между Ethereum и Bitcoin

Биткойн зависит от единой реализации в качестве своего истинного источника, ядро кода является единственной истиной, не может быть ошибок.

Источником самого Ethereum является спецификация самого себя, а не конкретная реализация, такая как Geth.

Этот метод делает стандарт более практичным для Ethereum. В случае ошибки поправки проблем должны осуществляться через социальное согласие в соответствии со стандартом, а не зависеть от конкретной реализации.