Вступ

У 2024 році навколо Ethereum відбулося багато значних подій. В самому початку року Ethereum представив кульки через оновлення Dencun. Це оновлення драматично знизило вартість транзакцій для існуючих роллапів, створивши основу для швидкого розширення екосистеми роллапів.

(Зменшення комісії в ланцюгах OP після оновлення Dencun | Джерело:Optimism X)

Однак, коли dapps у екосистемі перейшли на високомасштабні ролапи та альтернативні мережі рівня 1 (L1), активність користувачів на самому Ethereum почала зменшуватися. Крім того, коли ролапи перестали подавати високі комісії до Ethereum, у спільноті почалися обурення.

Крім того, 2024 рік був роком, коли масштабовані L1, такі як Solana та Sui, продемонстрували значну силу. Величезна кількість TPS (транзакцій на секунду), згенерована цими мережами, зробила активність на rollups відносно невеликою.

У цьому контексті з'явилися критики, такі як «роадмап Ethereum, спрямований на роллапи, має недоліки» або «розвиток Ethereum занадто повільний, щоб бути успішним». Чи дійсно Ethereum йде правильним шляхом? Яким буде Ethereum у 2025 році або навіть у 2030 році?

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

Що таке пропозиція Beam Chain і чому вона важлива?

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

Основна ідея пропозиції Beam Chain полягає в повній переробці консенсусного рівня Ethereum. Джастін Дрейк виклав наступні три причини, чому поточний рівень консенсусу, Beacon Chain, потрібно переробити:

• Краще розуміння MEV через минулі досвіди
• Швидкі досягнення в технології SNARK (наприклад, розробка zkVM прогресує з дивовижною швидкістю, більше 10 разів швидше)
• Усунення «технічного боргу», присутнього у Сигнальній мережі

На даний момент план шари консенсусного рівня Ethereum включає наступні елементи:

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

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

Ланцюг Beam пропонує досягти цих змін шляхом єдиного хардфорку. Узагалі:

1. Реалізація дорожньої карти для шару згоди Ethereum потребує повного перепроектування шару згоди.
2. До цього часу основні зміни на шляху розвитку будуть включені в жорсткий відгалуження під назвою Ланцюг Beam.
3. Включає чотири елементи: швидкість створення блоків, швидка остаточність, застосування chain snarkification та квантова стійкість.

Далі давайте дослідимо, як кожен з цих елементів реалізований та технічні наслідки, які вони передбачають.

Технічні деталі дизайну Beam Chain

Швидші слоти та швидша остаточність

На даний момент час слотування Ethereum становить 12 секунд, і на блок, пов'язаний зі слотом, підтвердження займає 2-3 епохи (приблизно 15 хвилин). Покращення цих часів позитивно позначиться на користувачах Ethereum, додатках та роллапах, які будуються на Ethereum.

Коротший термін остаточності (Orbit SSF)

Ця тема, відома серед дослідників Ethereum як SSF (однослотова остаточність), має на меті зменшити час досягнення остаточності блоків Ethereum з приблизно 15 хвилин до 12 секунд, надаючи користувачам швидше підтвердження. Щоб зрозуміти однослотову остаточність, нам потрібно розуміти поточний алгоритм консенсусу Ethereum, Gasper.

Ключовим принципом дизайну Gasper є забезпечення того, щоб блок, запропонований в слоті, досягав певного рівня економічної безпеки протягом встановленого часу, мінімізуючи при цьому комунікаційне навантаження на кожного валідатора. Для досягнення цього, Ethereum розподіляє весь набір валідаторів на комітети, розподілені по 32 слотам. Кожен слот може містити до 64 комітетів, і метою є створення кожного комітету з 128 валідаторів (хоча це число може збільшуватися, якщо загальна кількість активних валідаторів перевищує це число).

Валідатори у кожному комітеті незалежно перевіряють блок і голосують за нього, використовуючи BLS підписи. Механізм BLS підписів дозволяє об'єднувати кілька підписів в один, що означає, що визначений вузол у комітеті збирає ці підписи і компілює їх у один компактний пакет даних. Розсилаючи цей об'єднаний підпис, наступний пропонувач блоку може підтвердити з мінімальними даними, що блок було належним чином перевірено.

(Агрегація підпису BLS між валідаторами Ethereum | Джерело: eth2book)

У підсумку, Gasper Ethereum досягає як масштабованості, так і економічної безпеки за допомогою наступних механізмів:

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

Проте виникає проблема, оскільки Gasper працює на основі епох, і «зв'язність» між епохами повинна бути перевірена, перш ніж слот може досягти остаточності. У Gasper має пройти мінімум дві епохи (64 слоти), перш ніж досягти остаточності, що еквівалентна повній економічній безпеці Ethereum.

Це призводить до наступного діаграматичного представлення:

(Економічна остаточність у Гаспер | Джерело:Orbit SSF)

Це створює різноманітні виклики та погіршує користувацький досвід. Наприклад:

• При виведенні коштів з ЦЕХ (централізованої біржі) на Ethereum або навпаки, період підтвердження може становити близько 10 хвилин, що є досить великим.
• Rollups Ethereum та dApps стикаються з ризиком того, що блоки L1, на які вони покладаються, можуть не бути завершеними й стати недійсними. Якщо не будуть вжиті належні протиходії, це може спричинити проблеми.

Наприклад, у березні 2024 року Polygon zkEVM пережив зупинку ланцюга, яка тривала понад два дні через неправильну обробку переорганізації Ethereum.

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

У Tendermint, якщо кількість вузлів дорівнює N, складність його повідомлень дорівнює O(N^3). Це означає, що зі збільшенням кількості вузлів частота комунікації між ними зростає експоненційно, обмежуючи масштабованість. Таким чином, протоколи, такі як Ethereum, з багатьма валідаторами, не можуть безпосередньо приймати Tendermint в такому вигляді.

Необхідно зробити додаткову роботу для вирішення цих проблем, щоб застосувати консенсус у стилі Tendermint до Ethereum.

Огляд пропозиції Orbit SSF

Orbit SSF має на меті змінити механізм комітету Gasper для скорочення часу остаточності слоту при високій економічній безпеці.

Пропозиція полягає в зменшенні розміру епохи з 32 слотів до одного слоту (~12 секунд). Однак, як вже згадувалося раніше, це збільшить використання ресурсів для комунікації валідаторів, негативно впливаючи на децентралізацію Ethereum.

Для вирішення цього Orbit SSF пропонує наступні ідеї:

Збільшення максимальної суми стейкінгу для кожного валідатора Ethereum може забезпечити такий же рівень економічної безпеки з меншою кількістю валідаторів.

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

Наступне оновлення Ethereum, Pectra, включає EIP-7251, яке пропонує підвищити максимальну суму стейкінгу (MaxEB) для валідаторів з 32 ETH до 2048 ETH. Ця пропозиція приваблива для операторів інфраструктури вузлів Ethereum, а також є обов'язковою умовою для Orbit SSF.

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

(Нагорода та ймовірність бути включеним до комітету в Orbit SSF | Джерело:Orbit SSF)

Додатково, Orbit SSF переходить до “комітетної остаточності.” У Gasper комітети могли сприяти остаточності лише після того, як пройшли два або більше епох, але Orbit SSF дозволяє кожному призначеному слоту комітету сприяти остаточності в режимі реального часу. Це спрямовано на зроблення комітетів більш активними учасниками остаточності та досягнення масштабованості швидше.

(Фінальність у Orbit SSF за допомогою Cap-and-slow-rotate | Джерело:Orbit SSF)

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

Наприклад, встановлення n = 3 та значної величини F дозволить Ethereum досягти закінченості приблизно за три слоти, тим самим реалізуючи бачення Джастина Дрейка про 3-слотову FFG.

Однак, підвищення F до рівня повного набору валідаторів Ethereum не є простим завданням. Це може знизити вартість проведення 51% атаки на Ethereum. Таким чином, основним викликом для Orbit SSF в майбутньому є визначення технічного способу збільшення F, щоб забезпечити надійність Ethereum без значних втрат децентралізації.

Коротші інтервали між слотами (слоти тривають 4 секунди) Навіть якщо досягнуто SSF (або фінальність за 3 слоти), користувачі Ethereum все ще зазнають мінімального часу підтвердження транзакції в 12 секунд. Це призводить до двох основних недоліків для користувачів:

1. Довга затримка порівняно з іншими L1, такими як Solana та Sui
2. Вища вразливість до MEV (MEV зменшується зі скороченням часу блоку, що робить користувачів Ethereum більш вразливими до MEV)

Крім того, 12-секундний час блоку особливо несприятливий для ролапів, особливо на основі ролапів. Наприклад, Taiko реалізовує ролап на основі публікації кожного блоку L2 на L1. В результаті, час блоку Taiko може збільшитися до мінімуму 12 секунд і іноді перевищувати 24 секунди.

Для вирішення цього запропоновано два рішення:

a. Зменшити час блоку Ethereum до 4 або 8 секунд

b. Використовуйте попередні підтвердження

Зменшення часу блоку Ethereum

Зменшення часу блоку Ethereum - це тема активної дискусії. Воно було формалізовано як EIP-7782, яке пропонує зменшити час слоту з 12 секунд до 8 секунд, тим самим збільшивши масштабованість Ethereum на 33%. Однак 8-секундний час слоту може бути не оптимальним для користувацького досвіду або основних rollups. Досягнення коротшого часу слоту здається більш бажаним.

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

Статистика часу передачі блоків головної мережі Ethereum надає уявлення про можливість використання блоку з часом 4 секунди. Діаграма нижче показує розподіл часу передачі блоків.

(CDF часу прибуття повідомлень | Джерело:Затримка поширення повідомлень Gossipsub)

Приблизно 98% блоків передаються протягом 4 секунд, тоді як близько 2% займають більше часу. За цими даними, 4-секундний час блокування може виглядати доцільним. Однак, час блокування враховує не тільки комунікацію, а й виконання та голосування. Враховуючи ці фактори, тільки приблизно 2 секунди з 4-секундного часу блокування будуть доступні для комунікації. У таких умовах досягнення 4-секундного часу блокування є викликом.

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

Використання попередніх підтверджень

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

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

Commit-Boost, подібно до MEV-Boost, є необов'язковим допоміжним засобом для валідаторів, що дозволяє їм безпечно генерувати та поширювати "зобов'язання". Залежно від ситуації, такі зобов'язання можуть мати різні форми:

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

Однак, ефективність Commit-Boost залежить від прийняття валідаторами. Якщо його використовують лише кілька валідаторів, вплив на користування буде мінімальним. Зазначено, що Commit-Boost здобув сильну підтримку від спільноти Ethereum та має потенціал стати поширеним проміжним програмним забезпеченням, подібним до MEV-Boost. Він отримав підтримку від відомих операторів валідаторів, таких як Rocket Pool, Renzo, SSV, Luganodes, Nethermind, Puffer, A41 та Figment. Крім того, він отримав гранти від EF, Lido та Eigenlayer і користується сильною підтримкою від будівельника блоків Titan.

Тим не менш, як вже зазначалося раніше, передпідтвердження ймовірніше буде використовуватися як позапротокольний бічний засіб, подібний до MEV-Boost, а не інтегруватися безпосередньо в протокол.

Роль Beam Chain у швидших слотах

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

Сигнальна мережа snarkification та квантова стійкість

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

Ланцюжкова зморшування

На даний момент Сигнальна мережа Ethereum досягає згоди за допомогою валідаторів, які «повторно виконують» кожний блок, щоб перевірити правильність кореня стану, отриманого в результаті. Цей процес повторного виконання вводить неефективності і діє як бар'єр для зниження апаратних вимог до валідаторів.

Beam Chain має на меті замінити цей процес повторного виконання на «верифікацію» за технологією ZK. Це значно знизить вимоги до апаратного забезпечення для валідаторів і дозволить будь-кому запускати вузол Ethereum з будь-якого місця. Щоб досягти цього, Beam Chain та Ethereum використовуватимуть ZK SNARK.

ZK в протоколі Ethereum

ZK SNARKs мають наступні дві властивості:

1. Вони дозволяють перевірити той факт, що певний обчислення було виконано, не потребуючи повторного виконання обчислення
2. Розмір доказу компактний порівняно з оригінальними даними

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

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

Що потрібно зробити?

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

f(S,B)=S’

Тут:

• S: Попередній стан блокчейну
• B: заданий блок
• S': Після-стан блокчейну після виконання блоку
• f: Функція переходу стану

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

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

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

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

У цьому випадку хто генерує доказ ZK? Зазвичай можна припустити, що пропонент блоку також відповідальний за генерацію доказу ZK. Однак важливо зауважити, що не всі валідатори можуть генерувати докази ZK.

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

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

Майбутнє: повна снаркіфікація Ethereum

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

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

Підсумовуючи, ось переваги повної зміни Ethereum для валідаторів.

1. Валідаторам потрібно лише перевіряти докази, а не повторно виконувати обчислення, що знижує обчислювальні вимоги
2. Валідатори обмінюють докази замість повних даних блоку, зменшуючи вимоги до мережевої пропускної здатності

В результаті екосистема Ethereum може змінитися драматично. Наприклад:

• Речі типу «Ethereum Node Apps» можуть дозволити валідаторам працювати на мобільних пристроях.
• Будь-хто, хто відповідає мінімальним вимогам до стейкінгу, може запустити вузол Ethereum, що значно знижує бар'єр для стати валідатором.

Це зробило би участь валідатора набагато більш доступною та децентралізованою.

Сигнатури, стійкі до квантових обчислень

Чи достатньо лише зменшення стану функції для Beam Chain як консенсусного шару?

Які проблеми стануть перед Ethereum у постквантовому світі?

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

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

Підписи BLS, використовані в Сигнальній мережі Ethereum, базуються на еліптичних кривих. Безпека механізмів підпису на основі еліптичних кривих залежить від проблеми дискретного логарифму (DLP), яку суперіорна обчислювальна потужність квантових комп'ютерів може підірвати. Це робить підписи на основі еліптичних кривих вразливими до квантових комп'ютерів.

Квантові обчислення швидко розвиваються, про що свідчать останні досягнення Google у сфері квантових обчислень, такі як чіпи Willow. Google стверджує, що Willow може виконати обчислення за 5 хвилин, на що суперкомп'ютеру зайняло б 10^25 років. Хоча це поки що не загрожує безпеці еліптичних кривих, подальший розвиток на цьому рівні може поставити під загрозу системи блокчейну вже за кілька років.

(Перехід до стандартів криптографії післяквантового періоду | Джерело: NIST IR 8547)

Національний інститут стандартів та технологій США (NIST) вже розпочав зусилля стандартизувати квантово-стійкі алгоритми підпису для вирішення очікуваного зламу існуючих систем через квантові комп'ютери.

Ethereum також серйозно ставиться до цього питання. У Beam Chain метою є досягнення квантово-стійких алгоритмів підпису.

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

Виклики та роль ZK

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

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

(Діаграма агрегації доказу | Джерело: Figment Capital)

1. Валідатори підписують блок за допомогою квантово-стійкого алгоритму.
2. Підписи надсилаються до агрегатораабо комітет зібрання.
3. Агрегатор генерує ZK-доказ, що підтверджує правильність підписів.
4. З використанням технік агрегування доказів агрегатор комбінує нові докази з існуючими по мірі отримання нових підписів.

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

Ролі ZK в Beam Chain

Загалом, ланцюг Beam з ZK принесе наступні переваги:

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

zkVM як основа для ZK в ланцюжку Beam

Система доказів, що лежить в основі ZK в Beam Chain, буде zkVM. Заснований на Risc-V zkVM дозволяє доводити будь-яку програму будь-якою мовою, що дає більшу гнучкість.

(Перехід стану Beam для компіляції в Risc-V та підтвердження в zkVMs | Джерело: Оголошення про Beam Chain від Джастіна Дрейка)

Це добре узгоджується з існуючою клієнтською екосистемою Ethereum, яка розроблена кількома мовами, зберігаючи різноманітність і відмовостійкість Ethereum. У майбутньому ланцюжку Beam різні клієнти напишуть функцію переходу стану на декількох мовах програмування, скомпілюють її в Risc-V і дозволять довести її в будь-яких zkVM на основі Risc-V. З цієї причини zkVM є природним вибором для Beam Chain.

Висновок

Якщо Beam Chain успішно реалізується, Ethereum ймовірно матиме наступні можливості:

1. Користувачі отримають підтвердження транзакцій протягом 4 секунд, з остаточністю, досягнутою протягом 12 секунд.
2. Валідатори перевірятимуть переходи стану в рівні консенсусу за допомогою ZK-доказів. Якщо рівень виконання також є snarkified, валідаторам буде потрібно лише мінімальна кількість даних для участі в консенсусі.
3. Підписи валідаторів будуть квантово-стійкими
4. t, що запобігає квантовим комп'ютерам ускладнювати консенсус Ethereum.

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

Це завершує наше дослідження того, як Ethereum може розвиватися протягом п'яти років через призму Beam Chain. У наступній статті ми розглянемо, як Ethereum може виглядати у 2025 році з двох перспектив: UX та опір цензурі.

Додаток: Питання щодо мережі Beam

(П): Пропозицію Джастіна Дрейка обговорювали приватно. Це не суперечить основній цінності Ethereum бути «відкритим»?

(А): Ні. Пропозиція Beam Chain просто пропонує впровадити певні частини існуючої дорожньої карти Ethereum за один раз. Чи буде він реалізований, чи ні – це те, що все ще потребує обговорення спільнотою. Усі теми, про які йшлося вище, вже мають пов'язані EIP або дописи на Ethresear.ch. Це, більш-менш, свідчить про те, що Beam Chain не є пропозицією, яка пропонує новий, раніше нерозголошений напрямок для Ethereum. Крім того, обговорення дорожньої карти Ethereum проводяться публічно під час двотижневого All Core Devs Call, в якому може взяти участь будь-хто. Якщо хтось не згоден з дорожньою картою або має нові ідеї, він може висловити свою думку під час цих дзвінків або подати нові пропозиції у вигляді EIP чи дописів на Ethresear.ch.

Коротко кажучи, пропозиція Джастіна щодо ланцюжка Beam не стосується зміни дорожньої карти, але скоріше об'єднання частин дорожньої карти під однією назвою або мемом.

(П): Чи не занадто довго реалізувати Beam Chain протягом 5 років?

(А): П'ять років можуть здатися довгим терміном, але необхідно враховувати два фактори:

1. Ethereum побудована на багатоклієнтській архітектурі.
2. Ethereum має найбільшу кількість валідаторів серед усіх блокчейнів.

(Різноманіття клієнтів узгодження | Джерело: Різноманітність клієнтів Ethereum)

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

Як показано на зображенні, консенсусний шар Ethereum наразі працює з щонайменше чотирма клієнтами. Щоб замінити Сигнальну мережу Сигнальною мережею, всі чотири команди клієнтів повинні співпрацювати над розробкою. Беручи до уваги це та великий набір валідаторів Ethereum, процес розробки Сигнальної мережі має пріоритетом стабільність і не може бути прискорений до кількох місяців або 1-2 років.

Попередження:

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