Я сиджу тут і пишу це в останній день міжоперативного розробника Ethereum в Кенії, де ми зробили великий прогрес у впровадженні та вирішенні технічних деталей важливих майбутніх покращень Ethereum, наибільш помітних PeerDAS, Перехід дерева Веркле та децентралізовані підходи до зберігання історії в контексті EIP 4444З моєї власної перспективи, відчувається, що темп розвитку Ethereum та наша здатність впроваджувати великі та важливі функції, які значно поліпшують досвід для операторів вузлів та користувачів (L1 та L2), зростає.

Команди клієнтів Ethereum спільно працюють над випуском тестової мережі Pectra.

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

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

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

MEV, та залежність будівельника

У минулому блоки Ethereum створювалися майнерами, які використовували досить простий алгоритм для створення блоків. Користувачі надсилають транзакції до публічної мережі p2p, яку часто називають "mempool" (або "txpool"). Майнери слухають mempool і приймають транзакції, які є валідними і оплачують комісію. Вони включають транзакції, які можуть, і якщо місця недостатньо, вони віддають перевагу тим з найвищою комісією.

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

Наприклад, розгляньте децентралізовані біржі, такі як Uniswap. Припустимо, що в час T обмінний курс USD/ETH - на централізованих біржах та на Uniswap - становить $3000. У час T+11 обмінний курс USD/ETH на централізованих біржах підвищується до $3005. Але Ethereum ще не мав свого наступного блоку. У час T+12 він з'являється. Хто створює блок, може зробити свою першу транзакцію серією покупок на Uniswap, купуючи всі доступні ETH на Uniswap за цінами від $3000 до $3004. Це додатковий дохід, і його називають MEV. Додатки, крім DEXes, мають свої аналоги цієї проблеми. Flash Boys 2.0 paper опублікована в 2019 році докладно розглядає це.

Діаграма з документа Flash Boys 2.0, що показує обсяг доходів, які можна здобути за допомогою таких підходів, які були описані вище.

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

З того часу триває дискусія між двома стратегіями, які я назву мінімізацією MEV та карантинуванням MEV. Мінімізація MEV має дві форми: (i) агресивна робота над альтернативами Uniswap без MEV (наприклад, Обмін коров'ячими) та (ii) вбудовувати техніки у протокол, наприклад, зашифровані mempools, що зменшують інформацію, доступну для виробників блоків, тим самим зменшуючи дохід, який вони можуть здобути. Зокрема, зашифровані mempools унеможливлюють стратегії, такі як атаки-сендвіч, які розміщують транзакції безпосереду перед і після угод користувачів, щоб фінансово експлуатувати їх («фронтранінг»).

Карантин MEV працює, приймаючи MEV, але намагаючись обмежити його вплив на централізацію стейкінгу, розділяючи ринок на два типи суб'єктів: валідатори відповідають за атестацію та пропозицію блоків, але завдання вибору вмісту блоку передається на аутсорсинг спеціалізованим розробникам через протокол аукціону. Окремим стейкерам тепер більше не потрібно турбуватися про оптимізацію арбітражу defi; Вони просто приєднуються до протоколу аукціону та приймають найвищу ставку. Це називається розділенням пропонента/будівельника (PBS). Цей підхід має прецеденти в інших галузях: основна причина, чому ресторани можуть залишатися такими децентралізованими, полягає в тому, що вони часто покладаються на досить концентрований набір постачальників для різних операцій, які мають велику економію на масштабі. До сих пір PBS досить успішно забезпечувала справедливі умови для малих валідаторів і великих валідаторів, принаймні в тому, що стосується MEV. Однак це створює іншу проблему: завдання вибору того, які транзакції будуть включені, стає більш концентрованим.

Моя думка з цього приводу завжди полягала в тому, що мінімізація MEV - це добре, і ми повинні прагнути до неї (особисто я регулярно використовую Cowswap!) - хоча зашифровані мемпули мають багато проблем, але мінімізація MEV, швидше за все, буде недостатньою; MEV не опуститься до нуля або навіть майже до нуля. Отже, нам теж потрібен якийсь карантин МЕВ. Це створює цікаве завдання: як зробити «карантинну скриньку MEV» якомога меншою? Як дати будівельникам найменше повноважень, зберігши при цьому можливість взяти на себе роль оптимізації арбітражу та інших форм збору MEV?

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

Ось де входять списки.

Джерело: цей пост ethresear.ch.

Списки включення дозволяють пропонентам блоків (точніше, учасникам) вибирати транзакції, які обов'язково повинні потрапити в блок. Будівельники все ще можуть перепорядковувати транзакції або вставляти свої власні, але вони повинні включити транзакції пропонента. В кінцевому підсумку, списки включення були зміненіобмежувати наступний блок, а не поточний блок. У будь-якому випадку вони позбавляють забудовника можливості виводити транзакції з блока повністю.

Вищезазначене було складною кроликовою норою складного фону. Але MEV - це складне питання; навіть вищезазначений опис упускає багато важливих нюансів. Як кажуть стара приказка, "ви можливо не шукаєте MEV, але MEV шукає вас". Дослідники Ethereum вже досить збігаються на меті "мінімізувати карантинний бокс", як можна більше зменшити шкоду, яку можуть заподіяти будівельники (наприклад, виключити або затримати операції як спосіб нападу на конкретні застосування).

Тим не менш, я думаю, що ми можемо піти ще далі. Історично склалося так, що списки включень часто сприймалися як «побічна особливість»: зазвичай ви не думаєте про них, але на випадок, якщо зловмисники почнуть робити божевільні речі, вони дають вам «другий шлях». Таке ставлення знайшло своє відображення в поточних дизайнерських рішеннях: в поточний EIP, ліміт газу списку включень становить близько 2,1 мільйона. Але ми можемо зробити філософський здвиг у способі мислення про списки включень: подумайте про список включень як про блок, а роль будівничого як про функцію додавання декількох транзакцій для збору MEV. Що, якщо це будівники мають ліміт газу у 2,1 мільйона?

Я вважаю, що ідеї в цьому напрямку - дійсно зменшення карантинної коробки до мінімуму - дуже цікаві, і я підтримую рух в цьому напрямку. Це зміна філософії "ера 2021 року": в філософії "ера 2021 року" ми були більш ентузіазмовані ідеєю того, що, оскільки у нас зараз є будівельники, ми можемо "перевантажувати" їх функціональність і мати їх обслуговувати користувачів більш складними способами, наприклад, підтримуючиERC-4337 ринки комісій. У цій новій філософії частини перевірки транзакцій ERC-4337 мусили б бути уособлені в протокол. На щастя, команда ERC-4337 вже @yoav/AA-roadmap-May-2024#Native-AA---a-modular-roadmap">з кожним днем все більше відчуваю позитивне ставлення до цього напрямку.

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

Рідне ставлення

Сьогодні одиночні стейкери становлять відносно невеликий відсоток всіх стейкінгів Ethereum, і більшість стейкінгу виконується різними провайдерами - деякі централізовані оператори, а інші - DAO, такі як Lido та RocketPool.

Я провів власне дослідження - різні опитування [1] [2], опитування, особисті розмови, запитання «чому саме ви - саме ви - не займаєтеся сольовим стейкінгом сьогодні?» Для мене міцна екосистема сольового стейкінгу - це найбажаніший результат для стейкінгу Ethereum, і одне з найкращих речей у Ethereum полягає в тому, що ми насправді намагаємося підтримувати міцну екосистему сольового стейкінгу, а не лише піддаватися делегуванню. Однак ми далекі від цього результату. У моїх опитуваннях і дослідженнях є кілька постійних тенденцій:

1. Велика більшість людей, які не займаються самостійним стейкінгом, вказують на те, що їхня основна причина - це мінімальна кількість ETH у 32.
2. З тих, хто вказує на інші причини, найвищий рівень технічних викликів з запуску та утримання вузла валідатора.
3. Втрата миттєвої доступності ETH, ризики безпеки «гарячих» приватних ключів та втрата можливості одночасного участі в протоколах децентралізованих фінансів є значущими, але менш важливими проблемами.

Основні причини, чому люди не ведуть сольовий стейкінг, за даними опитувань Farcaster.

Є два ключові питання, які дослідження стейкінгу повинні вирішити:

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

Багато невирішених досліджень та розробок спрямовані саме на вирішення цих проблем:

1. Дерева ВерклеплюсEIP-4444дозволяти стейкінговим вузлам працювати з дуже низькими вимогами до жорсткого диска. Додатково вони дозволяють стейкінговим вузлам майже миттєво синхронізуватися, що значно спрощує процес налаштування, а також операції, такі як перехід з однієї реалізації на іншу. Вони також роблять легкі клієнти Ethereum набагато більш життєздатними, зменшуючи потрібну пропускну здатність даних для надання підтверджень для кожного доступу до стану.
2. Дослідження(наприклад, ці пропозиції)у способи дозволити набагато більший набір валдідаторів (що дозволяє набагато менші мінімальні ставки) одночасно зменшуючи накладні витрати вузлів згоди. Ці ідеї можуть бути реалізовані як частинаодинарна фінальність слоту. Роблячи це, також робить легкі клієнти безпечнішими, оскільки вони зможуть перевірити повний набір підписів замість того, щоб покладатися насинхронні комітети).
3. Постійні оптимізації клієнта Ethereum продовжують знижувати вартість та складність запуску вузла валідатора, незважаючи на зростаючу історію.
4. Дослідження проштрафи з обмеженнямможе потенційно пом'якшити обурення щодо ризику втрати приватного ключа та зробити можливим для стейкерів одночасно ставити свої ETH в протоколах децентралізованих фінансів, якщо це те, що вони хочуть зробити.
5. 0x01 Вивідні облікові данідозволяють стейкерам встановлювати адресу ETH як свою адресу виведення коштів. Це робить децентралізовані пули для стейкінгу більш життєздатними, надаючи їм перевагу перед централізованими пулами для стейкінгу.

Однак ще раз є багато того, що ми могли б зробити. Теоретично можливо дозволити валідаторам виводити гроші набагато швидше: Casper FFG залишається безпечним, навіть якщо набір валідаторів змінюється на кілька відсотків кожного разу, коли він завершується (тобто один раз за епоху). Отже, ми могли б значно скоротити період виведення, якби приклали зусилля до цього. Якби ми хотіли значно зменшити мінімальний розмір депозиту, ми могли б прийняти важке рішення про вибір в інших напрямках, наприклад, якщо ми збільшимо час остаточності в 4 рази, це дозволить@VitalikButerin/параметризація-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735">4x мінімальне зменшення розміру депозиту. Одноразова фінальність пізніше виправить це, вийшовши за межі моделі «кожен стейкер бере участь в кожній епосі» цілком.

Ще одна важлива частина цієї цілої проблеми - економіка стейкінгу. Ключове питання: чи хочемо ми, щоб стейкінг був відносно узагальненою діяльністю, чи хочемо, щоб всі або майже всі стейкують всі свої ETH? Якщо всі стейкують, то яку відповідальність ми хочемо, щоб всі взяли на себе? Якщо люди просто делегують цю відповідальність через лінощі, це може призвести до централізації. Тут стоять важливі і глибокі філософські питання. Неправильні відповіді можуть вести Ethereum шляхом централізації та «перетворення традиційної фінансової системи з додатковими кроками»; правильні відповіді можуть створити яскравий приклад успішної екосистеми з широким та різноманітним набором самостійних стейкерів та високодецентралізованих стейкінг пулів. Ці питання стосуються основної економіки та цінностей Ethereum, тому нам потрібно більше різноманітності участі тут.

Вимоги щодо апаратного забезпечення вузлів

Багато ключових питань у децентралізації Ethereum зазвичай сводяться до питання, яке визначило політику блокчейнуна протязі десяти років: наскільки доступним ми хочемо зробити запуск вузла, і як?

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

Як я писав вище, EIP-4444 та дерева Verkle - це дві ключові технології, які наближають нас до цієї ідеї. Якщо обидві реалізовані, апаратні вимоги до вузла ймовірно в кінцевому підсумку можуть зменшитися до менше, ніж сотня гігабайтів, і можливо навіть до практично нуля, якщо ми повністю усунемо відповідальність зберігання історії (можливо лише для вузлів, які не беруть участь в стейкінгу).Тип 1 ZK-EVMsвидалимо потребу запускати обчислення EVM самостійно, оскільки ви замість цього можете просто перевірити доказ того, що виконання було правильним. У моєму ідеальному світі ми об'єднаємо всі ці технології разом, і навіть розширення браузера Ethereum (наприклад, Metamask, Rabby) матимуть вбудований вузол, який перевіряє ці докази, робить вибіркове забезпечення доступності даних і переконаний, що ланцюг є правильним.

Вищевикладене вище часто називають "The Verge".

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

Одна дуже близька версія цієї стурбованості полягає в тому, що багатьом людям дискомфортно відносно EIP-4444: якщо звичайним вузлам Ethereum більше не потрібно зберігати стару історію, то хто це робить? Загальна відповідь полягає в тому, що точно існують достатньо великі гравці (наприклад, дослідники блоків, обмінники, рівні 2), які мають стимул утримувати ці дані, і порівняно з100 петабайтів, збережених Wayback Machine, ланцюг Ethereum дуже малий. Так що дійсно нерозумно думати, що будь-яка історія буде втрачена.

Однак ці аргументи ґрунтуються на залежності від невеликої кількості великих акторів. У моїй таксономія моделей довіри, це припущення 1 з N, але N досить малий. Це має свої ризики. Одне з того, що ми можемо зробити замість цього, це зберігати стару історію в мережі однорідних учасників, де кожен вузол зберігає лише невеликий відсоток даних. Такий тип мережі все ще забезпечував би достатньо копіювання для забезпечення надійності: кожен шматок даних матиме тисячі копій, і у майбутньому ми могли б використовувати кодування стирання (реалістично, розмістивши історію вEIP-4844-стильові краплі, в яких вже вбудований кодування стирання) для подальшого підвищення надійності.

Блоби мають кодування стирання в межах блобів та між блобами. Найлегший спосіб зробити ультра-надійне сховище для всієї історії Ethereum можливо полягає в тому, щоб просто помістити блоки маяка та виконання в блоби.Джерело зображення: codex.storage

Ця робота довгий час була на задвірках; Порталова мережаіснує, але реалістично вона ще не отримала рівень уваги, який відповідав би її важливості у майбутньому Ethereum. На щастя, зараз існує сильний інтерес до руху у напрямку вкладення набагато більшої кількості ресурсів у мінімізовану версію Portal, яка акцентується на розподіленому зберіганні та доступності історії. Цей рух слід підтримувати, і ми повинні зробити усі зусилля для невідкладної реалізації EIP-4444, у поєднанні з міцною децентралізованою піринговою мережею для зберігання та отримання старої історії.

Для держави та ZK-EVMs цей вид розподіленого підходу складніший. Для побудови ефективного блоку вам просто потрібно мати повний стан. У цьому випадку я особисто вважаю прагматичним підхід: ми визначаємо, і приділяємо увагу, певному рівню апаратних вимог, необхідних для наявності «вузла, що виконує все», який вище, ніж (ідеально спадаюча) вартість простої перевірки ланцюга, але все ще достатньо низька, щоб бути доступною для хобістів. Ми розраховуємо на припущення 1-з-N, де ми забезпечуємо, що N досить велике. Наприклад, це може бути ноутбук високого класу для споживачів.

Доведення ZK-EVM, ймовірно, буде найважчою частиною, а реальні довідники ZK-EVM, найімовірніше, вимагатимуть значно потужнішого обладнання, ніж архівний вузол, навіть зпокращення, такі як Binius, і найгірший випадок обмежується з багатовимірний газ. Ми могли б наполегливо працювати над розподіленою мережею доказів, де кожен вузол бере на себе відповідальність за доведення, напр. один відсоток від виконання блоку, а потім блок-продюсеру потрібно лише зібрати сотню доказів наприкінці. Дерева агрегації доказів можуть допомогти далі. Але якщо це не спрацює, то ще одним компромісом було б дозволити вимогам до апаратного забезпечення доведення підвищитися, але переконатися, що «вузол, який робить все» може перевіряти блоки Ethereum безпосередньо (без доказу), досить швидко, щоб ефективно брати участь у мережі.

Висновки

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

Ми цього не робимо.

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

Але є багато того, що ми могли б зробити, щоб піти далі в цьому напрямку, на всіх трьох вісях, про які я говорив вище, а також на багатьох інших важливих вісцях.Гелійзробило великий прогрес у створенні Ethereum «фактичного легкого клієнта». Тепер нам потрібно включити його за замовчуванням у гаманці Ethereum, зробити постачальників RPC забезпечувати докази разом із їх результатами, щоб їх можна було перевірити, та розширити технологію легкого клієнта на протоколи 2-го рівня. Якщо Ethereum масштабується за дорожньою картографією, орієнтованою на rollup, протоколи 2-го рівня повинні мати ті ж гарантії щодо безпеки та децентралізації, що й на 1-му рівні. У світі, орієнтованому на rollup, є багато інших речей, на яких ми повинні зосередитися більше уваги; децентралізовані та ефективні мости між L2 - один із численних прикладів. Багато dapps отримують свої логи через централізовані протоколи, оскільки сканування журналів Ethereum стало занадто повільним. Ми могли б покращити це за допомогою присвяченого децентралізованого підпротоколу;@vbuterin/parallel_post_state_roots">ось одне з моїх пропозицій, як це може бути зроблено.

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

Disclaimer：

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