Майбутнє оновлення Ethereum, після злиття [Частина 2]

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

In Частина I У нашій розмові з дослідником Ethereum Foundation (EF) Денні Раяном, який допомагав координувати процес оновлення, ми обговорили, що злиття має принести з точки зору безпеки та стабільності.

У частині II Райан розповідає про оновлення, на які користувачі можуть розраховувати в майбутньому, включаючи danksharding, Ethereum без збереження стану та оновлення безпеки, які борються зі зростанням видобутої майнером вартості (MEV). Він також пояснює, як ці багаторічні зусилля привели до нових методів дослідження та тестування майбутніх оновлень.

---

Координація в децентралізованій мережі

МАЙБУТНЄ: Ви натякали на можливість того, що майнери форкнуться і продовжуватимуть спроби використовувати старий ланцюг. Але здебільшого цей процес залучив усіх. Яка ваша роль у цьому як дослідника Ethereum Foundation? Як скоординувати такий масштабний рух?

ДЕННІ РАЙАН: Я почав займатися proof-of-stake десь у 2017 році, і навіть тоді це здавалося наперед вирішеним. Це було п'ять років тому. І спільнота Ethereum була дуже готова не зупинятися на місці та робити це правильно, а також побудувати протокол, який працює не лише сьогодні, але, сподіваємося, працюватиме протягом 100 років або більше. 

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

Є більш чутливі питання. Є менше наперед зроблених висновків, коли EF, дослідницька група та клієнти, які не входять до EF, усі намагаються знайти рішення проблем і підтримувати рух. Іноді рішення знаходяться в дещо більш сірій зоні — чи це правильне рішення? Ми зробимо це зараз? Ми зробимо це пізніше? Це зрештою виявляється складним, і EF намагається допомогти координувати ці методи, допомогти провести деякі дослідження та розробки, щоб допомогти перевірити рішення, допомогти полегшити розмови для визначення часових рамок, пріоритетів і замовлень. 

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

За останні п’ять років до спільноти додалося набагато більше голосів, і після злиття теоретично вона стане більш децентралізованою. Що ви думаєте про майбутній процес оновлення? Чи можливо, що ми будемо шукати якийсь DAO першого рівня для координації оновлень?

Наскільки я розумію, спільнота Ethereum не зацікавлена ​​в голосуванні в ланцюжку — або будь-якому плутократичному голосуванні та оновленнях — і що користувачі вирішують використовувати протокол. Загалом існує широкий консенсус. Іноді виникають розбіжності — наприклад, Ethereum проти Ethereum classic. Але врешті-решт це ваше право, право спільноти та права користувачів вирішувати, яке програмне забезпечення вони хочуть використовувати. Загалом ми погоджуємося, тому що люди намагаються зробити Ethereum кращим, і в деяких ключових речах немає багато конфліктів. 

Тому формального технічного механізму я не очікую. Я очікую, що процес продовжуватиме рости, змінюватися й розвиватися в такому нестрогому управлінні, де є дослідники, є розробники, є члени спільноти, є прикладні програми тощо. 

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

Віталік називає це «функціональна швидкість втечі.” Давайте переведемо Ethereum у місце, де він матиме достатній масштаб і функціональність, щоб його можна було розширювати та використовувати нескінченною кількістю способів на наступному рівні стеку. Нехай EVM має мінімальну достатню функціональність, має бути достатньо доступних даних для обробки величезних обсягів масштабу, а потім програми можуть розширювати його в розумних контрактах. Другий рівень може експериментувати з новими віртуальними машинами всередині своїх конструкцій другого рівня; ви можете масштабувати Ethereum і так далі і так далі.

Я думаю, що буде все важче і важче досягати результатів. І я думаю, що це добре.

Тіньові вилки

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

Ми повинні були робити тіньові розгалуження протягом останніх чотирьох років. Вони чудові; вони дійсно круті. По суті, я беру кілька вузлів, якими ми керуємо — називаємо це 10, 20, 30 — і вони думають, що настане розгалуження, тому вони знаходяться в основній мережі або одній із цих тестових мереж, а потім у певному стані розгалуження, наприклад висоті блоку, вони усі кажуть: «Добре, ми в новій мережі». І вони розгалужуються, а потім бовтаються у власній реальності, але вони мають стан розміру основної мережі.

І деякий час ви можете передавати транзакції з основної мережі в цю розгалужену реальність, щоб отримати розумну кількість того, що виглядає як звичайна активність користувачів, і це дійсно добре. Це дозволяє нам перевірити те, що в кінцевому підсумку виявилося дуже органічними процесами, які важко змоделювати. І це було чудово. Pari [Джаянті] та інші, хто працює в команді DevOps в EF, організовували це, і ми багато чого від них навчилися. Я думаю, якщо запитати будь-кого, він відповість: «Ну, так, було б чудово, якби ми робили це три роки тому, чотири роки тому під час кожного оновлення».

Але я скажу інше. Я говорю це [починаючи з] рік тому, і тепер ми перебуваємо в довгому хвості в безпеці та тестуванні: це справді збиває цю штуку, переконавшись, що всі крайні випадки правильні, переконавшись, що коли це станеться, це станеться — ми робимо один удар, і це працює. І виявилося, що програмне забезпечення створено за допомогою клієнтів рівня консенсусного виконання, тому потрібно багато чого побудувати з точки зору тестування. Shadow forks – одна з них. Використання інших середовищ моделювання, які можуть перевірити ці дві речі разом, наприклад Куртоз, АнтитезаІ інші. 

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

Що після підтвердження частки?

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

По-перше, ймовірно, є низка причин, чому зміна proof-of-stake була пріоритетною. Одне полягало в тому, щоб перестати переплачувати за безпеку з підтвердженням роботи. А інше полягало в тому, що накип почав проникати через ці два шари конструкцій. Тож, можливо, якщо ви отримаєте 10-100-кратний масштаб, виходячи з цього, ви можете зосередитися на цьому іншому, завершити роботу та об’єднати ці дві різнорідні системи: ланцюжок маяків і поточну основну мережу. 

Є деякі інші речі, які вплинули на те, як ми думаємо про часові рамки та пріоритети. Раніше я згадував, що весь світ MEV кинув гайковий ключ у деякі речі. Є централізація та інші проблеми безпеки, які виникають, коли ви починаєте думати про те, куди може піти MEV. І протягом останніх 12 з гаком місяців було проведено багато досліджень щодо того, як пом’якшити деякі з цих проблем за допомогою модифікацій першого рівня. Залежно від аналізу загроз, що надходять зі світу MEV, це може надати пріоритет певним функціям безпеки та доповненням безпеки до рівня L1 над чимось іншим, що, можливо, буде пріоритетним. 

Я вважаю, що щось цікаве – це дорожня карта шардингу та поточна очікувана конструкція, яка називається danksharding, ім. Данкрад [Фейст], наш дослідник з EF. Вся конструкція насправді спрощується, якщо ви припустите, що ці дуже стимулювані актори MEV існують. Деякі з цих зовнішніх гравців не тільки змінили наше уявлення про безпеку, але й те, як ми можемо думати про побудову цих протоколів. Якщо ви припустите, що MEV існує, якщо ви припустите, що ці дуже мотивовані актори готові робити певні речі через MEV, тоді раптом у вас з’явиться сторонній учасник консенсусу, якому, можливо, ви можете перевантажити щось, що багато в чому можна спростити. Отже, з’являються не тільки погані речі, але й відкриваються нові типи дизайну.

Ми дійсно розширили інструменти в нашій панелі інструментів, щоб мати можливість тестувати оновлення таким чином, що наступне оновлення буде більше стосуватися написання тестів, а не думати про те, як їх навіть перевірити.

Чи Ethereum без стану ще активно обговорюється та досліджується? 

Так. Стан — усі рахунки, контракти, баланси та таке інше — ось стан Ethereum. З огляду на те, де ви знаходитесь у блокчейні, є реальний стан. Ця річ росте з часом, росте лінійно. А якщо збільшити ліміт газу, він росте ще швидше. Тож це викликає занепокоєння. Якщо він зростає швидше, ніж пам’ять і простір на жорсткому диску споживчих машин, то у вас є проблеми з фактичним запуском вузлів на домашніх комп’ютерах і споживчому апаратному забезпеченні, що має проблеми з безпекою та централізацією. Крім того, якщо ви поговорите з деякими з ОТРИМАЙТЕ Члени команди [клієнта] той факт, що штат продовжує зростати, означає, що вони повинні продовжувати оптимізувати речі. Так що важко.

Ethereum без стану та речі в цьому напрямку досліджень є потенційним шляхом вирішення цієї проблеми, де для виконання блоку мені насправді не потрібен увесь стан; є такий собі прихований вхід для виконання функції блоку. Мені потрібен попередній стан, мені потрібен блок, а потім я отримую пост-стан, щоб дізнатися, чи блок дійсний. У той час як у Ethereum без стану реквізити стану — облікові записи та інші речі, необхідні для виконання цього конкретного блоку — вбудовані в блок і є доказом того, що це правильний стан. Тепер виконання блоку та перевірка валідності Ethereum стає просто [обов’язковим] мати блок, що дуже добре. Тепер ми можемо мати повні вузли, які не обов’язково мають повний стан. Це відкриває цілий спектр способів побудови вузлів. Тож у мене може бути вузол, який повністю перевіряє та не має стану, у мене може бути вузол, який просто зберігає стан, релевантний мені, або я можу мати дуже повні вузли, які мають увесь стан і таке інше.

Над цим активно працюють. Насправді, я вважаю, зараз існує тестова мережа з усіма іншими цікавими речами, які повинні статися, щоб це сталося. Моя поточна оцінка полягає в тому, що попит на шардинг і масштаб L1 вище, ніж безпосередня загроза зростання штату. Таким чином, дуже ймовірно, що, оскільки один буде пріоритетним над іншим, масштаб буде пріоритетним. 

Тим не менш, важко сказати. є "прото-данкшардінг”, що є схожим на поетапний спосіб отримати трохи більше масштабу. Можливо, це станеться, а потім станеться відсутність стану, а потім повне шардування, залежно від потреб і оцінки того, що відбувається, і відповідних загроз. Я думаю, що загальна думка щодо зростання штату полягає в тому, що ми повинні мати шлях і ми повинні його виправити, але [що] неминучі пожежі погашено, і що це не те, що скалічить Ethereum наступні пару років. Але це річ, яку треба виправити.

Розкажіть мені про оновлення, які ми do знати після злиття. Чи буде оновлення очищення? Це окремо від оновлення в Шанхаї? А коли буде представлено шардинг?

Шанхай, ймовірно, буде назвою будь-якого форка після злиття. Фактично вивести свої кошти, які ви вкладали вже майже два роки — [це] не ввімкнено під час злиття. Спочатку очікувалося, що вони будуть виконані, але, враховуючи складність злиття, з часом було вирішено повністю згорнути його й просто завершити злиття, а не додавати додаткову функцію зняття коштів. Я дуже, дуже, дуже сподіваюся, що в Шанхаї буде ввімкнено зняття коштів — отже, перше оновлення після злиття. Це було обіцяно багатьом, багатьом людям, які мають великий капітал на лінії, і я не очікую жодних проблем із цим. Вони, як правило, визначені, є написані тести і таке інше. 

Існує низка інших покращень EVM [віртуальної машини Ethereum], які, я думаю, увійдуть у цю систему — різні математичні операції, деякі інші можливості розширення, трохи кращі версії в EVM та інші функції. Це щось на кшталт клапана скидання тиску для покращень EVM, які були відкладені вже кілька років, щоб зробити злиття та інші оновлення. І люди справді хочуть побачити тут якесь незначне покращення масштабованості. Тож це може бути або прото-danksharding, який закладає певну основу для повного шардингу та отримує трохи більше масштабу, або потенційне зниження ціни на газ calldata, що дуже легко, але насправді не є стійким рішенням. Сподіваємось, це те, чого ми очікуємо в Шанхаї: вилучення коштів і трохи масштабу.

Тоді постає питання: що буде після цього? І це важко сказати. Якщо ми все-таки досягнемо певного масштабу, і це буде гарно доповнювати L2, і все буде досить добре, тоді, можливо, на цьому етапі виникне потреба зробити без збереження стану. Або якщо L2 мають ненаситну потребу в більшому масштабі, то, можливо, це створює основу для повного danksharding.

Це інтерв’ю було відредаговано та скорочено. 

Опубліковано 27 липня 2022 р