Упорядник: 0xxz, Golden Finance

EthCC7 нещодавно відбувся в Брюсселі, і організатори запросили Віталіка, засновника Ethereum, виступити з основною промовою.

Варто зазначити, що у 2024 році виповнюється 10 років ICO Ethereum. Після виступу Віталіка троє колишніх засновників Ethereum, Віталік Бутерін, Джозеф Лубін і Гевін Вуд, знову зробили групове фото на згадку про цю подію.

Ця стаття є основною доповіддю Віталіка, засновника Ethereum, нещодавно на EthCC7.

тема виступу

Посилення L1: оптимізація Ethereum, щоб стати високонадійним, надійним і бездозволовим базовим рівнем рівня 2

Ethereum Vision Spectrum

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

На лівій стороні спектру він в основному намагається бути дуже мінімалістичним базовим рівнем, який в основному діє лише як верифікатор доказів для всіх L2. Можливо, також забезпечити можливість передачі ETH між різними L2. Але крім цього, це в основному все.

На правій стороні спектру в основному відбувається переорієнтація на dApps, які працюють переважно на L1, а L2 використовується лише для деяких дуже специфічних і високопродуктивних транзакцій.

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

Я маю на увазі, що дуже екстремальні варіанти розташовані зліва, а праворуч це може бути базовий рівень, але також спробуйте надати L2 більше функціональності. Однією з ідей у ​​цьому напрямку є подальше скорочення часу обміну Ethereum, який зараз становить 12 секунд, можливо, до 2-4 секунд. Мета цього полягає в тому, щоб фактично зробити базові зведення життєздатними як основний спосіб роботи L2. Тож тепер, якщо ви хочете, щоб L2 мав першокласний користувацький досвід, вам потрібно мати власне попереднє підтвердження, що означає або централізований сортувальник, або ваш власний децентралізований сортувальник. Якщо їх консенсус прискориться, L2 більше не потрібно буде цього робити. Якщо ви дійсно хочете підвищити масштабованість L1, то потреба в L2 також буде зменшена.

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

Перевага стійкості Ethereum

Великою перевагою Ethereum є те, що він має велику та відносно децентралізовану екосистему ставок.

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

Розподіл обчислювальної потужності біткойнів зараз не дуже хороший. Два майнінгові пули складають більше 50% обчислювальної потужності, а чотири майнінгові пули складають більше 75%.

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

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

Переваги надійності Ethereum також включають:

Він має багатоклієнтську екосистему: є клієнти виконання Geth і клієнти виконання, які не належать до Geth, навіть перевищує частку клієнтів виконання Geth. Подібна ситуація виникає в консенсусних клієнтських системах;

Міжнародна спільнота: люди в різних країнах, включаючи проекти, L2, команди тощо;

Багатоцентрова екосистема знань: є Ethereum Foundation, є команда клієнтів, і навіть команда Paradigm Reth останнім часом збільшує своє лідерство у відкритому коді;

Культури, які цінують ці атрибути

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

Де Ethereum L1 не відповідає високим стандартам і як його можна покращити?

Ось опитування, яке я провів на Farcaster приблизно півроку тому: якщо ви не робите ставки Solo, що заважає вам робити ставки Solo?

Я можу повторити запитання на цьому місці, хто робить соло-стейкинг? Без ставки Solo, хто з вас вважає, що поріг у 32 ETH є найбільшою перешкодою, хто вважає, що запустити вузол занадто складно, є найбільшою перешкодою, а хто вважає, що найбільшою перешкодою є те, що ви не можете інвестувати свій ETH у DeFi. протокол одночасно? Хто вважає, що найбільшою перешкодою є страх перед тим, що доведеться розмістити приватні ключі на працюючому вузлі, де їх легше вкрасти?

Можна побачити, що дві головні перешкоди, з якими одностайно погодилися: мінімальна вимога в 32 ETH і складність роботи вузла. Це завжди важливо усвідомлювати.

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

Почніть із запуску вузла перевірки, іншими словами, починаючи з порогу 32 ETH. Насправді ці два питання пов’язані, оскільки вони обидва є функціями кількості валідаторів у доказі частки Ethereum.

Сьогодні ми маємо близько 1 мільйона валідаторів, кожна з яких має депозит у розмірі 32 ETH, тож якби мінімальну вимогу було змінено на 4 ETH, ми б мали 8 мільйонів або, можливо, більше 8 мільйонів, можливо, 9 мільйонів або 10 мільйонів валідаторів. Якщо ми хочемо скоротити його до 100 000 валідаторів, то мінімальна вимога, можливо, повинна піднятися приблизно до 300 ETH.

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

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

Отже, є дві техніки, які можуть покращити обидва ці аспекти.

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

Наразі, я думаю, у нас більш ніж достатньо економічної безпеки. Вартість проведення 51% атаки, розрахована на суму скороченого ETH, становить одну третину від 32 мільйонів ETH, тобто приблизно 11 мільйонів ETH. Хто б витратив 11 мільйонів ETH, щоб знищити блокчейн Ethereum. Ніхто, навіть уряд США, цього не хоче.

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

Друга методика — це краща агрегація підписів. Ви можете зробити щось просунуте, наприклад Starks, і замість підтримки 30 000 підписів на слот, можливо, ми зможемо підтримувати більше підписів з часом. Це перша частина.

Друга частина полегшує запуск вузлів.

Першим кроком є ​​закінчення терміну дії історії. Насправді, EIP-4444, у цій сфері було досягнуто значного прогресу.

Другий крок — клієнт без громадянства. Verkle існує вже давно, іншим можливим варіантом є створення бінарного хеш-дерева, схожого на Poseidon, зручну для Stark хеш-функцію. Після цього для перевірки блоків Ethereum вам більше не потрібен жорсткий диск. Потім ви можете додати тип 1 ZKVM, який може Stark перевірити весь блок Ethereum, тож ви можете перевірити як завгодно великі блоки Ethereum, завантажуючи дані або навіть дані вибірки доступності даних, а потім вам потрібно буде перевірити лише одне підтвердження.

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

Ви можете просто запустити новий автономний клієнт, закрити старий, перемістити ключі та запустити новий. Ви втрачаєте лише одну епоху.

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

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

Proof of Stake має й інші труднощі, наприклад ризики, пов’язані зі ставкою ліквідності, і ризики, пов’язані з MEV. Це також важливі питання, які слід продовжувати розглядати. Над цим думають наші дослідники.

Відновлення після 51% атаки

Я справді почав серйозно і серйозно думати. Дивно, скільки людей взагалі не замислюються над цією темою і просто ставляться до неї як до чорної скриньки.

Що станеться, якщо ми дійсно зіткнемося з атакою 51%?

Ethereum може зазнати атаки 51%, Bitcoin може зазнати атаки 51%, і уряд також може зазнати атаки 51%, наприклад, купити 51% політиків.

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

Поширеною помилкою є те, що люди вважають, що атаки 51% стосуються скасування остаточності. Люди звертають на це увагу, тому що саме це підкреслив Сатоші Накамото в білому документі. Ви можете подвоїти витрати, після того як я купив свій приватний літак, я здійснив атаку на 51%, отримав свої біткойни назад і зміг залишити свій приватний літак і літати.

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

Але розворот – це ще не найстрашніше. Найбільший ризик, про який ми повинні хвилюватися, це насправді цензура. 51% вузлів перестали приймати блоки від інших 49% вузлів або будь-якого вузла, який намагався стримати певний тип транзакції.

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

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

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

Тож я кажу, що насправді цензура – ​​це більший ризик.

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

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

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

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

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

Звичайно, знову існує математична неможливість результату, принаймні будь-хто, хто був офлайн у той час, не зможе сказати, хто був правий, а хто ні.

Є багато обмежень, але чим ближче ви наближаєтеся до цієї мети, тим менше роботи потрібно виконувати соціальному консенсусу.

Якщо уявити, яка насправді буває атака 51%. Це не буде так, як нижче, раптом у якийсь момент Lido, Coinbase і Kraken збираються опублікувати допис у блозі о 5:46, по суті кажучи, привіт, хлопці, ми зараз робимо огляд.

Насправді ви побачите війну в соціальних мережах і всілякі інші атаки одночасно. До речі, якщо атака 51% справді відбудеться, я маю на увазі, що ми не повинні вважати, що Lido, Coinbase і Kraken будуть при владі через 10 років. Екосистема Ethereum ставатиме все більш популярною, і їй потрібно буде добре адаптуватися до цього. Ми хочемо, щоб навантаження на соціальний шар було якомога легшим, а це означає, що нам потрібно, щоб технічний рівень принаймні запропонував явного кандидата-переможця, і якщо вони хочуть відійти від ланцюга, який розглядається, вони повинні згуртуватися навколо жменьки м’яких вилок.

Я виступаю за те, щоб ми провели більше досліджень і дали дуже конкретні рекомендації.

Пропозиція: підвищити поріг кворуму до 75% або 80%

Я думаю, що поріг для кворуму (Примітка: механізм кворуму — це алгоритм голосування, який зазвичай використовується в розподілених системах для забезпечення надмірності даних і остаточної узгодженості) можна підвищити з двох третин сьогодні приблизно до 75% або 80%.

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

Є ризики. Подивимося, як це виглядає на практиці? Наскільки я розумію, я вважаю, що у нас лише один раз завершуваність зупинилася приблизно на годину, оскільки більше третини вузлів були офлайн. І потім, чи бувають випадки, коли від 20% до 33% вузлів офлайн? Я думаю, щонайбільше один раз і принаймні нуль разів. Оскільки на практиці дуже мало валідаторів виходять з мережі, я вважаю, що ризик цього досить низький. Переваги в основному полягають у тому, що планка, яку зловмисник повинен досягти, значно збільшується, а діапазон сценаріїв, коли ланцюжок переходить у безпечний режим у разі вразливості на стороні клієнта, значно збільшується, тому люди можуть фактично співпрацювати, щоб з’ясувати, що пішло не так.

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

Інші проблеми цензури

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

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

Їм було б вигідно, якби в протоколі була абстракція облікового запису. Отже, є багато речей, насправді багато з цих речей є цінними в баченні центру L2 і бачення центру L1.

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

Використовуйте легкі клієнти всюди

Багато в чому сумно, як ми взаємодіємо з простором, ми децентралізовані, нам не довіряють, хто в цій кімнаті запускає легкий клієнт на своєму комп’ютері, який перевіряє консенсус? рідкісний. Хто використовує Ethereum, довіряючи гаманцю браузера Infura? Через п’ять років я хотів би, щоб кількість піднятих рук змінилася. Я хотів би бачити гаманці, які ні в чому не довіряють Infura. Нам потрібно інтегрувати легких клієнтів.

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

Що ми можемо зробити, це мати систему, де кінцевий користувач запускає щось на зразок клієнта Helios light. Насправді він повинен запускатися безпосередньо в браузері, безпосередньо підтверджуючи консенсус Ethereum. Якщо він хоче перевірити щось у ланцюжку, наприклад взаємодіяти з ланцюжком, тоді ви просто перевіряєте доказ Merkle безпосередньо.

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

У ланцюжку L1 є заголовки блоків, стани, комітети синхронізації та консенсус. Якщо ви перевірите консенсус, якщо ви знаєте, що таке заголовок блоку, ви можете пройти по гілці Merkle і побачити, який стан. Отже, як ми надаємо легкі гарантії безпеки клієнтів для L2. Корінь стану L2 є. Якщо це базовий Rollup, є смарт-контракт, і цей смарт-контракт зберігає заголовок блоку L2. Або, якщо у вас є попереднє підтвердження, у вас є смарт-контракт, який зберігає, хто є попереднім підтвердженням, тож ви визначаєте, хто є попереднім підтвердженням, а потім прослуховуєте дві третини підмножини їхніх підписів.

Отже, коли у вас є заголовок блоку Ethereum, є досить простий ланцюжок довіри, хеш, гілка Merkle і підпис, який ви можете перевірити, і ви можете отримати легку перевірку клієнта. Те саме стосується будь-якого L2.

Я розповідав про це людям у минулому, і багато разів відповідь була: «Боже, це цікаво, але який у цьому сенс?» Багато L2 є мультипідписами. Чому ми не довіряємо мультипідписам для перевірки мультипідписів?

На щастя, з минулого року це фактично не відповідає дійсності. Optimism і Arbitrum знаходяться на першому етапі Rollup, що означає, що вони фактично мають системи доказів, що працюють у ланцюжку, і комітет із безпеки, який може захистити їх у разі виявлення вразливості, але комітет із безпеки має подолати дуже високий поріг голосування. , наприклад 75% з 8 осіб, розмір Arbitrum збільшиться до 15 осіб. Отже, у випадку Optimism і Arbitrum, вони не просто мультипідписи, вони мають фактичні системи доказів, і ці системи доказів насправді відіграють певну роль, принаймні з точки зору володіння більшістю повноважень у вирішенні того, який ланцюжок правильний чи неправильний .

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

Сьогодні ми вже можемо перевірити гілку Merkle, нам потрібно лише написати код. Завтра ми також зможемо перевірити ZKVM, щоб ви могли повністю перевірити Ethereum і L2 у своєму гаманці браузера.

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

Квантово-стійкі стратегії

Час для квантових обчислень скорочується. Metaculous вважає, що квантові комп’ютери з’являться на початку 2030-х років, а деякі вважають, що раніше.

Тому нам потрібна квантово стійка стратегія. У нас є квантово-стійка стратегія. Є чотири частини Ethereum, які вразливі для квантових обчислень, і кожна має природні альтернативи.

Квантово-стійкою альтернативою Verkle Tree є Starked Poseidon Hash, або, якщо ми хочемо бути більш консервативними, ми можемо використовувати консенсусні підписи Блейка, зараз ми використовуємо сукупні підписи BLS, які можна замінити сукупними підписами Старка. Blob використовує KZG і може бути підтверджено за допомогою окремого кодування Меркла, дерева Старка. Облікові записи користувачів наразі використовують ECDSA SECP256K1, який можна замінити підписами на основі хешування та абстракцією та агрегацією облікових записів, гаманцями смарт-контрактів ERC 4337 тощо.

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

Спрощення протоколу

Якщо вам потрібен надійний базовий рівень, протокол має бути простим. У нього не повинно бути 73 випадкових хуків і деякої зворотної сумісності, яка існує через випадкову дурну ідею, яку придумав якийсь випадковий хлопець на ім’я Віталік у 2014 році.

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

Зараз Ethereum є неймовірною колекцією, є RLP, є SSZ, є API, і в ідеалі ми повинні просто використовувати SSZ, але принаймні позбутися RLP, стану та бінарного дерева Merkle, коли у вас буде двійкове дерево Merkle, тоді весь Ethereum знаходиться на бінарному дереві Merkle.

Fast Finality, Single Slot Finality (SSF) очищає невикористані прекомпілятори, як-от прекомпілятор ModX, який часто спричиняє помилки консенсусу, було б непогано, якби ми могли видалити його та замінити високопродуктивним надійним кодом.

Підведіть підсумки

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

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

Одна з речей, якими я найбільше задоволений в Ethereum і в основному процесі розробки зокрема, полягає в тому, що наша здатність працювати паралельно значно покращилася. Це сильна сторона, ми насправді можемо працювати над багатьма речами паралельно. Тому турбота про ці теми насправді не впливає на здатність покращувати екосистеми L1 і L2. Наприклад, удосконалення L1 EVM, щоб полегшити роботу з криптографією. Наразі перевіряти хеші Poseidon у EVM занадто дорого. 384-бітна криптографія також занадто дорога.

Отже, є деякі ідеї на додаток до EOF, такі як коди операцій SIMD, EVM max тощо. Є можливість підключити цей високопродуктивний співпроцесор до EVM. Це краще для рівня 2, оскільки вони можуть дешевше перевіряти докази, і краще для програм рівня 1, оскільки протоколи конфіденційності, такі як zk SNARK, дешевші.

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

«Велика трійка» Ethereum возз’єднується

2024 рік — це 10-та річниця Ethereum IC0. 2024 EthCC запросила всіх трьох колишніх засновників Ethereum, Віталіка Бутеріна, Джозефа Лубіна та Гевіна Вуда.

Після виступу Віталіка їх запросили на спільне фото:

Велика трійка знову тисне один одному руки