Scroll Ліанчан: складна задача "курка або яйце" у розвитку екосистеми Ethereum

Автор: Ye Zhang Джерело: X, @yezhang1998 Переклад: Шан Ер, Золоті фінанси

Для Ethereum повільний розвиток є не хворобою, а особливістю. Швидкий розвиток для розрахункового рівня, який забезпечує безпеку трільйонів доларів активів, є небезпечним.

Різноманітність клієнтів дуже важлива, але я згоден, насправді нам може знадобитися менше команд клієнтів. Крім того, я не вважаю координацію команд клієнтів основним обмеженням у розробці нового функціоналу; є багато інших факторів, які потрібно враховувати, особливо в аспекті сумісності з попередніми версіями.

Я хочу висунути ще три ключові пункти тут:

1.Інфраструктурі потрібно швидше адаптуватися до змін у Layer 2, інакше існує ризик загальної непривабливості для екосистеми Ethereum.

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

Вартість угод Scroll (або будь-якого іншого рівня 2) включає в себе витрати на доступність даних (DA) та витрати на виконання, але за замовчуванням MetaMask підтримує лише витрати на виконання, що призвело до неправильних розрахунків витрат протягом кількох місяців.

Це створює складне питання, що було спочатку - курка чи яйце:

Якщо Layer 1 не зміниться, постачальникам інфраструктури не буде мотивації оновлюватися. Без оновленої інфраструктури розвиток рішень Layer 2 буде уповільнений, що придушує інновації. Це становить особливий виклик для Ethereum, оскільки у більшості інших ланцюгів є власний вбудований гаманець, пов'язаний з оновленням ланцюга. Натомість стандарт EVM відповідає Ethereum, що ускладнює адаптацію.

2. Нормативи надзвичайно важливі, але наразі всі рішення другого рівня не мають належних нормативів

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

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

Визначення високорівневих стандартів.
Переконайтеся, що будь-яка команда може реалізувати цю функцію, прочитавши специфікацію, без посилання на інші реалізації клієнта.

Іншими словами, єдиним справжнім джерелом реалізації багатоклієнтського додатка має бути сам стандарт. Але наразі більшість реалізацій ґрунтуються на існуючих реалізаціях як на джерелі, що суперечить справжньому потенціалу багатоклієнтської архітектури.

3. Так само важливо звернути увагу на різницю між Ethereum та Bitcoin

Біткойн залежить від однієї реалізації як свого джерела істини, ядро кодової бази є єдиним правдою, воно не може помилятися.

А справжнє джерело Ethereum - це сам стандарт, а не конкретна реалізація, така як Geth.

Цей підхід надає практичне значення стандарту Ethereum. Якщо сталася помилка, її слід виправити шляхом суспільної згоди відповідно до стандарту, а не залежати від конкретної реалізації.