Примітка редактора: Сьогодні вдень на головному місці проведення заходу Devcon у Бангкоку основний розробник Ethereum Джастін Дрейк оголосив про «найамбітнішу» пропозицію Ethereum щодо зміни рівня консенсусу за останні кілька років – Beam Chain, яка представляє серію технологій ZK для заміни «старого» Ethereum Beacon Chain. На зустрічі Джастін заявив, що розробка нового рівня консенсусу може тривати до 2030 року. Однак ринок, схоже, не купив його, і поки тривала прес-конференція, ціна Ethereum різко впала. Здається, всі думають: а чи є у фонду ще один привід продавати монети?

Ось повний текст промови:

Проект, в який я вклав багато часу цього року, називається "Beam Chain". Beam Chain - це переробка шару консенсусу, яка включає найновіші та найпрогресивніші ідеї з дорожньої карти досліджень. Мета полягає в тому, щоб перейти від поточного Beacon Chain до цього дизайну безпечним і швидким способом, який буде ближче до Ethereum. кінцевої форми.

Джерело зображення: Uncommons Dasong

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

У наступній промові я спробую пояснити здавалося б безглузду ідею у розумну пропозицію - а саме повністю переробити рівень консенсусу.

На початку я хотів би поговорити про велике бачення рамочного Beam Chain. Обсяг Beam Chain фокусується на рівні згоди і не включає блоби на рівні даних та EVM на рівні виконання, оскільки блоби та EVM використовуються безпосередньо застосунками та потребують збереження сумісності вперед, тому можливості змінити ці два рівні відносно обмежені. Рівень згоди не безпосередньо споживається застосунками, що дозволяє нам мати більше можливостей для коригувань у цьому відношенні.

Чому Beam Chain?

Так чому я запропоновую цю масштабну рефакторингову роботу на рівні консенсусу зараз?

Головна причина полягає в тому, що Beacon Chain вже трохи «старий».

"Специфікації" були заморожені п'ять років тому, а за цей час багато змінилося, особливо те, що наше розуміння нових перспектив глибше, ніж було п'ять років тому. Ми були відносно наївними, коли йшлося про PoW п'ять років тому, але з того часу ринок стрімко зріс, і у нас є краще розуміння механізмів, які можуть допомогти зменшити негативні зовнішні витрати MEV.

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

Додатково, з часом ми отримали чітке розуміння помилок, які були допущені на Beacon Chain і накопичена технічна заборгованість. Ці заборгованості дуже стійкі і з часом зростатимуть.

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

Які зміни включає Beam Chain?

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

Джерело: Aaros.183

Перше - це виробництво блоків, яке включає MEV. Наразі існує багато проблем централізації на рівні будівельника блоків та реле. Ми сподіваємося ввести "список включень", щоб значно покращити стійкість до цензури. Як тільки список включень буде стійким до цензури, ми зможемо чітко розділити перевірників від процесу виробництва блоків. Це називається відокремленням пропонента-будівельника (PBS) та включає ідеї, такі як функції виконання.

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

Друга категорія - застава. Дослідники в основному досягли згоди, що поточна крива випуску є недосконалою, і є можливості для внесення коректив для покращення здоров'я та довгострокового розвитку Ethereum. Другий проект у категорії стейкінгу полягає у значному зменшенні ETH, необхідних для стати валідатором, з поточних 32 ETH до всього 1 ETH.

Останнім часом виникло кілька ідей щодо «Orbit». Крім того, ідея щодо одноразової фінальності, яка обговорюється вже кілька років, може значно прискорити процес фінальності Ethereum.

Остання категорія - криптографія, яка містить два важливі проекти. Перший проект - перевірка SNARK всього шару консенсусу в реальному часі, з розумною апаратною підтримкою.

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

Тут я використовую різні кольори, щоб відрізнити, чи можна легко або поступово виконати пункти дорожньої карти, чи вони складні для досягнення. Чотири зелені проекти в верхньому лівому куті - це проекти, які, на мою думку, можна і слід реалізувати поступово на Beacon Chain, і коли ці менші проекти будуть завершені, залишаться деякі великі проекти (червоні частини), які, на мою думку, найкраще реалізувати більш системним підходом.

На прикладі «Сповіщення про зміну», для досягнення миттєвого доказу Beacon Chain на розумному обладнанні, нам потрібно змінити хеш-функцію, метод підпису та методи серіалізації та Мерклізації стану. Це буде велика зміна для Beacon Chain, тому можливо, у нас є можливість внести ці зміни разом з іншими вдосконаленнями.

Аналогічна ситуація стосується "Faster Slots" і "Faster Finality" у двох червоних полях внизу. Коли ми розробляли Beacon Chain п'ять років тому, наша увага була зосереджена на безпеці, а не на продуктивності. Однак тепер ми виявляємо, що існують конструкції, які можуть підтримувати необхідну нам безпеку, а також покращувати продуктивність і використовувати деякі прості для досягнення покращення продуктивності.

Цей PPT показує відображення з дорожньої карти рівня консенсусу, про яку я щойно згадував, на більш широку дорожню карту Віталіка. Деякі з наших проектів перебувають у фазі Merge, деякі - у фазі Scourge, а деякі - у фазах Verge і Scourge.

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

Джерело: Aaros.183

Пошерсті часові інтервали в мапі консенсу новини, оскільки дискусії про пошерсті часові почалися в 2024 році, а карта доріг Віталіка була останні оновлена в 2023 році.

На додаток до того, що ми можемо прискорити ці важливі проекти, ми також можемо погасити частину технічного боргу, згаданого раніше. Якщо ми реалізуємо одноджерельну завершеність, епохи більше не потрібні, і слоти можна використовувати безпосередньо. Крім того, поточний депозитний договір дещо складний і є спадщиною від злиття; інфраструктура, така як комітет синхронізації, більше не буде потрібна після того, як буде досягнуто SNARKing Beacon Chain у реальному часі. Це можливість прибрати одним махом.

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

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

У 2021 році ми додали синхронний комітет, у 2022 році ми зробили злиття, у 2023 році ми додали можливості знімання коштів та природне динамічне шарування, а у 2025 році ми збільшимо максимальний ефективний баланс.

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

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

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

Які технології використовує Beam Chain?

Наступним етапом є частина друга, де я представлю деякі з технік, які будуть використовуватися в ланцюгу Beam. Подумайте про це як про різні епохи механізму консенсусу Ethereum: спочатку епоха доказу роботи (POW), потім перехід до епохи доказу участі (POS), і зараз ми можемо увійти в епоху доказу нульового знання (ZK).

У ері ZK ми широко використовуємо технологію SNARKs. Один із місць, де ми вже використовуємо SNARKs, - це надання перевірки нульового знання для всього ланцюга Beam - всього шару консенсусу - і це саме те місце, де дуже корисними стають zkVM (віртуальні машини з нульовим знанням).

Уявіть, що ми могли б реалізувати ланцюг Beam на різних мовах програмування високого рівня, таких як Rust та Go, а потім компілювати ці мови в байткод, який зможуть розуміти zkVMs, щоб досягти перевірки SNARK без турботи про деталі низького рівня.

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

Протягом останніх кількох років RISC-V став стандартом промисловості для цих zkVMs. RISC-V - це набір інструкцій, які в основному компілюють високорівневий код в інструкції RISC-V. Зараз існує сім компаній, що пропонують RISC-V zkVMs, такі як RISC Zero і SP1, про які можливо, ви чули.

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

Ще одне місце, де SNARKs широко використовуються в ланцюгу Beam, - це агреговані підписи. Ми хотіли б мати квантовостійкі агреговані підписи, і пропозиція тут полягає в використанні хеш-функцій. Хеш-функції є квантовостійкими і можуть бути використані як базовий модуль для побудови криптографії.

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

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

Цей бенчмарк був завершений на процесорі MacBook Pro і тепер може перевіряти 2 мільйони хешів на секунду. Це дивовижна швидкість, що означає, що ця пропозиція на основі хешів має велику продуктивність на Beam Chain. потенціал.

Крім zkVM та SNARKs, я хочу підкреслити, що ми будемо в значній мірі використовувати існуючу інфраструктуру.

Наприклад, мережева бібліотека libp2p, бібліотека серіалізації Simple Serialize та інші можуть бути повторно використані безпосередньо. Те саме стосується Pyspec framework, фреймворку специфікацій Python, який ми використовуємо для написання офіційних специфікацій та модульних тестів.

Крім того, інфраструктура, така як Протокольна Гільдія, також може бути повторно використана. Цього не було на початку Beacon Chain, але зараз вона може бути безкоштовно повторно використана.

Так само зараз існують кілька команд, які підтримують розвиток Beacon Chain. Тоді ми не мали команди клієнта консенсусу. Поточні п'ять команд клієнта консенсусу можуть бути використані безпосередньо без необхідності переорганізації.

Крім того, ми маємо відділи, які відповідають за комбіновані операції, такі як підтримка DevOps, надана командою Panda Ops, дослідницькі групи застосування, такі як команда з безпеки та команда мотивації, ці всі ресурси, які можна використовувати безпосередньо.

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

Джерело зображення: Uncommons Dasong

Моє наступне завдання як дослідника - почати писати виконавчу специфікацію, яку я називаю «виконавчим маршрутним планом». Ідея полягає в поєднанні «пікселів» у маршрутному плані, сотень тисяч слів у різних дослідницьких та академічних статтях та різних ідеях у розумах дослідників, витягнути з них основну суть і сформувати документ з виконавчою специфікацією. В кінцевому рахунку це буде дуже компактний документ, приблизно 1000 рядків коду Python.

Цікаво для мене те, що якщо буде загальна згода щодо нового напрямку Beam Chain, це буде велика можливість впровадити нову кров у клієнт згоди.

Зараз наша команда клієнтів узгодження розподілена між Північною Америкою, Європою та Океанією. Сьогодні я щасливий оголосити, що нова команда була готова розробляти клієнт Beam. Одна з команд базується в Індії, її звуть Zine, і вони пишуть клієнта Beam за допомогою мови Zig. Також є команда Lambda Class, яка базується в Південній Америці, і вони також висловили бажання розробити клієнт Beam.

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

Disclaimer：

1. Цю статтю підтверджено з [BlockBeats], Всі авторські права належать оригінальному автору [ BlockBeats ]. Якщо є зауваження до цього перепублікування, будь ласка, зв'яжіться з Ворота Навчаннякоманда, і вони оперативно це вирішать.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими, хто написав її, і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови здійснює команда Gate Learn. Якщо не зазначено, копіювання, розповсюдження або плагіат перекладених статей заборонено.