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

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

Для того, щоб Ethereum зберігав себе в довгостроковій перспективі, нам потрібен сильний контртиск проти обох цих тенденцій, зменшуючи складність і роздуття з часом. Але в той же час нам потрібно зберегти одну з ключових властивостей, яка робить блокчейни чудовими: їх постійність. Ви можете помістити NFT, любовну записку в транзакції calldata або смарт-контракт, що містить мільйон доларів, ончейн, піти в печеру на десять років, вийти і виявити, що він все ще там, чекаючи, поки ви прочитаєте і зможете з ним взаємодіяти. Для того, щоб децентралізовані застосунки почувалися комфортно, вони повинні бути впевнені, що їхні залежності не порушать їх, особливо сам L1.

Прибирання, дорожня карта на 2023 рік.

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

The Purge: ключові цілі

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

У цій главі

• Термін дії історії
• Термін дії стану
• Очищення функцій

Термін дії історії

Яку проблему він вирішує?

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

Що це таке і як це працює?

Ключовою спрощувальною особливістю проблеми зберігання історії є те, що кожний блок вказує на попередній блок за допомогою хеш-посилання (і іншийструктури), мати згоду щодо теперішнього достатньо, щоб мати згоду щодо історії. Якщо мережа має згоду щодо останнього блоку, будь-який історичний блок або транзакція або стан (баланс рахунку, nonce, код, сховище) може бути наданий будь-яким окремим актором разом з доказом Меркле, і доказ дозволяє будь-кому іншому перевірити його правильність. Хоча згода - це модель довіри N/2 з N, історія - це 1-of-N модель довіри.

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

Сьогодні Ethereum вже почало відходити від моделі, коли всі вузли зберігають всю історію назавжди. Блоки консенсусу (тобто частини, пов'язані з консенсусом доказу урахування) зберігаються лише протягом приблизно 6 місяців. Блоби зберігаються лише протягом приблизно 18 днів.EIP-4444 має на меті ввести однорічний термін зберігання історичних блоків та квитанцій. Довгострокова мета - мати узгоджений період (який може бути ~18 днів), протягом якого кожен вузол відповідає за зберігання всього, а потім мати мережу з вузлів Ethereum, які зберігають старі дані розподіленим чином.

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

Які існують посилання на наявні дослідження?

• EIP-4444: https://eips.ethereum.org/EIPS/eip-4444
• Torrents та EIP-4444:https://ethresear.ch/t/torrents-and-eip-4444/19788
• Мережа Portal: https://ethereum.org/uk/developers/docs/networking-layer/portal-network/
• Мережа Portal та EIP-4444:https://github.com/ethereum/portal-network-specs/issues/308
• Розподіле зберігання та вилучення об'єктів SSZ в Порталі: https://ethresear.ch/t/distributed-storage-and-cryptographically-secured-retrieval-of-ssz-objects-for-portal-network/19575
• Як збільшити ліміт газу (Парадигма): https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2

Що залишилося робити, і які компроміси?

Основна залишена робота полягає в побудові та інтеграції конкретного розподіленого рішення для зберігання історії - принаймні історії виконання, але в кінцевому підсумку також згоди та блоків. Найпростіші рішення для цього - (i) просто ввести існуючу бібліотеку торрентів, та (ii) рішення, що нативно для Ethereum, викликало мережа Portal. Як тільки буде введено будь-яку з цих функцій, ми зможемо увімкнути EIP-4444. Сам EIP-4444 не вимагає жорсткого відгалуження, хоча він потребує нової версії мережевого протоколу. З цієї причини є цінність у ввімкненні його для всіх клієнтів одночасно, оскільки в іншому випадку є ризики неправильної роботи клієнтів при підключенні до інших вузлів, які очікують завантаження повної історії, але фактично не отримують її.

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

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

Максимально параноїдальний підхід до (1) передбачав би доказ власності: фактично потрібно, щоб кожен валідатор доказу утримання зберігав певний відсоток історії та регулярно криптографічно перевіряв, чи він це робить. Більш помірний підхід полягає в тому, щоб встановити добровільний стандарт для того, який відсоток історії зберігає кожен клієнт.

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

Як воно взаємодіє з іншими частинами дорожньої карти?

Зменшення вимог до зберігання історії, можливо, навіть важливіше, ніж відсутність стану, якщо ми хочемо зробити запуск або розгортання вузла надзвичайно простим: з 1,1 ТБ, які повинен мати вузол, ~300 ГБ є станом, а решта ~800 ГБ є історією. Концепція вузла Ethereum, що працює на смарт-годиннику та потребує лише кількох хвилин для налаштування, досяжна лише за умови реалізації як безгромадянства, так і EIP-4444.

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

Термін дії стану

Яку проблему воно вирішує?

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

Стан набагато важче "закінчити", ніж історію, оскільки EVM фундаментально розроблений на основі припущення, що як тільки об'єкт стану створено, він завжди буде там і може бути прочитаний будь-якою транзакцією в будь-який час. Якщо ми введемо безстандартність, є аргумент, що, можливо, ця проблема не така погана: лише спеціалізований клас будівельників блоків дійсно потребуватиме зберігати стан, і всі інші вузли (навіть список включенняпродукція!) може працювати без збереження стану. Однак існує аргумент, що ми не хочемо надто розраховувати на безстатевість, і в кінцевому підсумку ми можемо бажати видаляти стан, щоб зберегти Ethereum децентралізованим.

Що це таке і як це працює?

Сьогодні, коли ви створюєте новий об'єкт стану (що може статися одним із трьох способів: (i) надсилання ETH на новий рахунок, (ii) створення нового рахунку з кодом, (iii) встановлення раніше непорушеного слоту сховища), цей об'єкт стану залишається в стані назавжди. Те, що ми хочемо замість цього, - це автоматичний закінчення терміну дії об'єктів з плином часу. Ключове викликання полягає в тому, як це зробити таким чином, щоб досягти трьох цілей:

1. Ефективність: не потребує великих обсягів додаткових обчислень для запуску процесу закінчення
2. Зручність для користувача: якщо хтось зайде у печеру на п'ять років і повернеться, він не повинен втратити доступ до своїх ETH, ERC20, NFT, позицій CDP ...
3. Зручність для розробника: розробники не повинні переходити до повністю незнайомої психологічної моделі. Крім того, додатки, які сьогодні застигають і не оновлюються, повинні продовжувати працювати досить добре.

Легко вирішити проблему, не задовольняючи цих цілей. Наприклад, ви можете зробити так, щоб кожен об'єкт стану також зберігав лічильник для свого терміну дії (який можна було б подовжити, записавши ETH, що може статися автоматично кожного разу, коли він читається або записується), і мати процес, який циклічно проходить через стан, щоб видалити прострочені об'єкти стану. Однак це вводить додаткові обчислення (і навіть вимоги до зберігання), і це, безумовно, не задовольняє вимогу зручності для користувача. Розробникам також було б важко міркувати про крайні випадки, пов'язані зі значеннями сховища, які іноді скидаються до нуля. Якщо ви зробите таймер закінчення терміну дії на весь контракт, це технічно полегшить життя розробникам, але ускладнить економіку: розробникам доведеться думати про те, як «перекласти» поточні витрати на зберігання даних на своїх користувачів.

Це проблеми, з якими спільнота розробників ядра Ethereum боролася протягом багатьох років, включаючи такі пропозиції, як «блокчейн оренда“ і “регенезаВ кінцевому рахунку ми поєднали найкращі частини пропозицій і сконцентрувались на двох категоріях «найменш поганих відомих рішень»:

• Часткові рішення щодо закінчення строку дії стану
• Пропозиції щодо закінчення терміну дії стану на основі адреси-періоду.

Часткова дата закінчення стану

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

Основні відмінності між цими пропозиціями полягають в наступному: (i) як ми визначаємо "недавно", і (ii) як ми визначаємо "частину"? Одна конкретна пропозиція полягає в тому, що EIP-7736, який базується на дизайні «стебло і листок»введений для дерев Веркле (хоча сумісний з будь-якою формою безгромадянства, наприклад, бінарними деревами). У такій конструкції заголовок, код і слоти зберігання, які примикають один до одного, зберігаються під одним «стеблом». Обсяг даних, що зберігаються під стеблом, може становити не більше 256 * 31 = 7,936 байт. У багатьох випадках увесь заголовок і код, а також багато слотів для зберігання ключів облікового запису зберігатимуться в одній основі. Якщо дані під даним стеблом не читаються і не записуються протягом 6 місяців, дані більше не зберігаються, а замість цього зберігається лише 32-байтове зобов'язання («заглушка») до даних. Майбутні транзакції, які отримають доступ до цих даних, повинні будуть «воскресити» дані з доказом, який буде звірятися з заглушкою.

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

Це складніше через стимули: зловмисник може змусити клієнтів постійно зберігати дуже велику кількість стану, поміщаючи дуже велику кількість даних в одне піддерево і відправляючи одну транзакцію щороку для «оновлення дерева». Якщо ви зробите вартість поновлення пропорційною (або тривалість поновлення обернено пропорційною) розміру дерева, то хтось може засмутити іншого користувача, помістивши дуже велику кількість даних у те саме піддерево, що й він. Можна спробувати обмежити обидві проблеми, зробивши деталізацію динамічною на основі розміру піддерева: наприклад, кожен наступний 216 = 65536 об'єктів стану може розглядатися як «група». Однак ці ідеї більш складні; Підхід, заснований на STEM, простий, і він узгоджує стимули, оскільки, як правило, всі дані в STEM пов'язані з одним і тим же додатком або користувачем.

Пропозиції щодо закінчення строку дії за адресою-періодом

Що, якщо ми хочемо уникнути будь-якого постійного зростання стану, навіть 32-байтові підсили? Це складна проблема через@vbuterin/state_size_management#Resurrection-conflicts">resurrection конфлікти: що, якщо об'єкт стану видаляється, пізніше виконання EVM розміщує інший об'єкт стану в точно тій самій позиції, але після цього хтось, кому цікавий початковий об'єкт стану, повертається і намагається його відновити? З частковим строком придатності об'єкта стану «заглушка» запобігає створенню нових даних. З повним строком придатності об'єкта стану нам не вистачає навіть заглушки.

Дизайн, заснований на адресному періоді, є найвідомішою ідеєю для вирішення цієї проблеми. Замість того, щоб мати одне дерево стану, що зберігає весь стан, ми маємо постійно зростаючий список дерев станів, і будь-який стан, який читається або записується, зберігається в останньому дереві станів. Нове порожнє дерево стану додається один раз на період (подумайте: 1 рік). Старі державні дерева вимерзли твердими. Очікується, що повні ноди зберігатимуть лише останні два дерева. Якщо об'єкт стану не чіпався протягом двох періодів і, таким чином, потрапляє в прострочене дерево, його все одно можна прочитати або записати, але транзакція повинна буде довести доказ Меркла для нього - і як тільки це станеться, копія знову буде збережена в останньому дереві.

Ключовою ідеєю для того, щоб зробити все це зручним для користувачів і розробників, є концепція адресних періодів. Період адреси – це число, яке є частиною адреси. Ключове правило полягає в тому, що адреса з періодом адреси N може бути прочитана або записана тільки під час або після періоду N (тобто, коли список дерева станів досягає довжини N). Якщо ви зберігаєте новий об'єкт стану (наприклад, новий контракт або новий баланс ERC20), якщо ви обов'язково помістили об'єкт стану в контракт з періодом адреси N або N-1, ви можете зберегти його негайно, без необхідності надавати докази того, що там нічого не було раніше. З іншого боку, будь-які доповнення або правки, внесені в старі періоди адреси, вимагають доказів.

Цей дизайн зберігає більшість поточних властивостей Ethereum, дуже легкий для додаткового обчислення, дозволяє писати додатки майже так само, як сьогодні (ERC20-и повинні переписати, щоб забезпечити, що баланси адрес з адресним періодом N зберігаються в дочірньому договорі, який сам має адресний період N), і вирішує проблему «користувач йде в печеру на п'ять років». Однак у нього є одна велика проблема: адреси потрібно розширити понад 20 байт, щоб вмістити адресні періоди.

Розширення адресного простору

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

0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF

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

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

Зменшення адресного простору

Ще один підхід йде у протилежному напрямку: ми одразу ж забороняємо деякий піддіапазон розміром 2128 адрес (наприклад, всі адреси, що починаються з 0xffffffff), а потім використовуємо цей діапазон для введення адрес з періодами адрес і хешів розміром 14 байт.

0xfffffff000169125d5dFcb7B8C2659029395bdF

Ключова жертва, яку приносить цей підхід, полягає в тому, що він представляє ризики безпеки для контрфактних адрес: адреси, які утримують активи або дозволи, але код яких ще не був опублікований на ланцюжку. Ризик полягає в тому, що хтось створює адресу, яка претендує на наявність одного шматка (ще не опублікованого) коду, але також має інший дійсний шматок коду, який має однаковий хеш з адресою. Обчислення такого зіткнення вимагає 2⁸⁰ хеші сьогодні; Скорочення адресного простору зменшило б це число до дуже доступного 2⁵⁶хеши.

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

Які є посилання на існуючі дослідження?

• Ранні пропозиції
  • Оренда блокчейну: https://github.com/ethereum/EIPs/issues/35
  • Регенезис:https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state/7582
• Теорія управління розміром стану Ethereum: @vbuterin/state_size_management" >https://hackmd.io/@vbuterin/state_size_management
• Кілька можливих шляхів до безгромадянства та закінчення терміну дії держави: @vbuterin/state_expiry_paths"">https://hackmd.io/@vbuterin/state_expiry_paths
• Пропозиції щодо часткового закінчення стану
  • EIP-7736: https://eips.ethereum.org/EIPS/eip-7736
• Документи щодо розширення адресного простору
  • Оригінальна пропозиція: https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485
  • Огляд Ipsilon:@ipsilon/address-space-extension-exploration"">https://notes.ethereum.org/@ipsilon/address-space-extension-exploration
  • Огляд блог-пости: @chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6"">https://medium.com/@chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6
• Що станеться, якщо ми втратимо стійкість до зіткнень: https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356

Що залишилося зробити, і які компроміси?

Я бачу чотири життєздатних шляхи для майбутнього:

• Ми працюємо з відсутністю статусу і ніколи не вводимо термін дії статусу. Стан постійно зростає (хоча й повільно: ми можемо не побачити, як він перевищить 8 ТБ протягом десятиліть), але його потрібно зберігати лише відносно спеціалізованим класом користувачів: навіть валідатори PoS не потребують стану.
  \
  Одна з функцій, яка потребує доступу до частини стану, - це виробництво списку включення, але ми можемо досягти цього децентралізованим шляхом: кожен користувач відповідає за підтримку частини дерева стану, що містить їх власні облікові записи. Коли вони транслюють транзакцію, вони транслюють її разом з доказом про доступ до об'єктів стану під час кроку перевірки (це працює як для EOAs, так і для облікових записів ERC-4337). Безстанні перевіряючі можуть потім об'єднати ці докази в доказ для всього списку включення.
• Ми робимо часткове закінчення терміну дії держави і приймаємо набагато нижчі, але все ще ненульові темпи зростання перманентного розміру держави. Цей результат, можливо, схожий на те, як пропозиції щодо закінчення терміну дії історії, що включають однорангові мережі, приймають набагато нижчі, але все ще ненульові темпи зростання постійного сховища історії через те, що кожному клієнту доводиться зберігати низький, але фіксований відсоток історичних даних.
• Ми робимо закінчення терміну дії стану, з розширенням адресного простору. Це вимагатиме багаторічного процесу забезпечення того, щоб підхід перетворення формату адреси працював і був безпечним, у тому числі для існуючих програм.
• Ми заявляємо про закінчення терміну дії з обмеженням адресного простору. Це вимагатиме багаторічного процесу забезпечення того, що всі ризики безпеки, пов'язані з колізіями адрес, включаючи ситуації міжланцюжкового взаємодії, будуть вирішені.

Один важливий момент полягає в тому, що складні питання розширення та стиснення адресного простору в кінцевому рахунку мають бути вирішені незалежно від того, чи будуть впроваджені схеми закінчення терміну дії держави, які залежать від змін формату адреси. Сьогодні це займає приблизно 2⁸⁰гешує для генерації колізії адрес, обчислювальне навантаження, яке вже є можливим для надзвичайно ресурсних акторів: відеокарта може виконувати приблизно 2²⁷хеші, тому протягом року він може обчислити 2⁵², отже все ~2^30 відеокарт в світіможе обчислити зіткнення за ~1/4 року, а FPGA та ASIC можуть ще більше прискорити цей процес. У майбутньому такі атаки стануть доступними для все більшої кількості людей. Тому фактична вартість впровадження повного закінчення терміну дії стану може бути не такою високою, як здається, оскільки нам все одно потрібно вирішити цю дуже складну проблему адреси.

Як воно взаємодіє з іншими частинами дорожньої карти?

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

Очищення функцій

Які проблеми вирішує?

Однією з ключових передумов безпеки, доступності та достовірна нейтральність це простота. Якщо протокол красивий і простий, це зменшує ймовірність того, що в ньому виникнуть помилки. Це збільшує шанс на те, що нові розробники зможуть прийти і попрацювати з будь-якою його частиною. Швидше за все, це буде справедливо і легше захищатися від особливих інтересів. На жаль, протоколи, як і будь-яка соціальна система, за замовчуванням з часом ускладнюються. Якщо ми не хочемо, щоб Ethereum потрапив у чорну діру постійно зростаючої складності, нам потрібно зробити одну з двох речей: (i) припинити вносити зміни та закостеніти протокол, (ii) мати можливість фактично видаляти функції та зменшувати складність. Також можливий проміжний шлях, який полягає у внесенні меншої кількості змін до протоколу, а також усуненні хоча б невеликої складності з часом. У цьому розділі ми розповімо про те, як ми можемо зменшити або усунути складність.

Що це таке і як це працює?

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

Один приклад, який вже в основному закінчений і може слугувати зразком для того, як вирішувати інші, є@vbuterin/selfdestruct">видалення коду операції SELFDESTRUCT. Код операції SELFDESTRUCT був єдиним кодом операції, який міг змінювати необмежену кількість слотів зберігання в межах одного блоку, вимагаючи від клієнтів реалізації значно більшої складності, щоб уникнути DoS-атак. Початкова мета операційного коду полягала в тому, щоб уможливити добровільне очищення штату, дозволяючи розміру штату з часом зменшуватися. На практиці мало хто в кінцевому підсумку скористався нею. Об'єкт опкод був зменшений дозволяти лише саморуйнівні облікові записи, створені під час однієї транзакції в хардфорку Dencun. Це вирішує проблему DoS і дозволяє значно спростити код клієнта. У майбутньому, ймовірно, має сенс з часом повністю видалити код операції.

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

• Перехід RLP → SSZ: спочатку об'єкти Ethereum серіалізувалися за допомогою кодування під назвою RLP. RLP є нетипізованим і зайво складним. Сьогодні ланцюг маяка використовує SSZ, який значно краще в багатьох відношеннях, включаючи підтримку не тільки серіалізації, але і хешування. З часом ми хочемо повністю позбутися RLP і перенести всі типи даних на структури SSZ, що зробить оновлення набагато простіше. Поточні EIP для цього включають [1] [2] [3].
• Видалення старих типів транзакцій: сьогодні є занадто багато типів транзакцій, багато з них потенційно можна видалити. Більш помірний альтернативний варіант повного видалення - це можливість абстракції облікових записів, за допомогою якої розумні облікові записи можуть включати код для обробки та перевірки транзакцій старого стилю, якщо вони так вирішать.
• Реформа LOG: журнали створюють фільтри блума та іншу логіку, яка додає складність до протоколу, але фактично не використовується клієнтами через те, що вона занадто повільна. Ми можемовидалити ці функції, і замість цього докладайте зусиль в альтернативи, такі як додатково-протокольні децентралізовані засоби читання журналів, які використовують сучасну технологію, таку як SNARKs.
• Поступове вилучення механізму синхронізації ланцюга маяка: механізм синхронізації комітетубуло спочатку впроваджено для можливості легкого перевірки клієнта Ethereum. Однак воно додає значну складність до протоколу. У кінцевому підсумку ми зможемоперевірте консенсусний рівень Ethereum безпосередньо за допомогою SNARKs, що дозволить уникнути необхідності в спеціалізованому протоколі перевірки клієнта-світлого. Потенційно зміни в консенсусі можуть дозволити нам видалити комітети синхронізації ще раніше, створивши більш «природній» протокол клієнта-світлого, який передбачає перевірку підписів випадкового підмножини валідаторів консенсусу Ethereum.
• Гармонізація формату даних: сьогодні, стан виконання зберігається в дереві Меркле-Патріці, стан згоди зберігається в дерево SSZ, і блоки фіксуються з @vbuterin/proto_danksharding_faq#У якому форматі зберігаються дані у блоках та як вони фіксуються">Об'єднані формати для даних блоків та стану мають сенс у майбутньому. Ці формати охоплювали б всі важливі потреби: (i) прості докази для клієнтів без стану, (ii) серіалізацію та кодування для даних, (iii) стандартизовані структури даних.
• Видалення комітетів ланцюга маяка: цей механізм спочатку був введений для підтримки конкретна версія виконавчого шарингу. Замість цього ми вирішили провести шардуваннячерез L2s та блоби. Тому комітети зайві, і тому є одне в процесі руху до їх видалення.
• Видалення змішаної порядку байтів: EVM є big-endian, а рівень консенсусу - little-endian. Можливо, має сенс знову узгодити все одне з одним (імовірно, big-endian, оскільки EVM важче змінити)

Зараз деякі приклади, які знаходяться всередині EVM:

• Спрощення механіки газу: поточні правила газу не дуже оптимізовані для надання чітких обмежень кількості ресурсів, необхідних для перевірки блоку. Ключові приклади цього включають (i) витрати на читання/запис зберігання, які призначені для обмеження числа читань/записів у блоку, але наразі досить безладні, та (ii) правила заповнення пам'яті, де наразі важко оцінити максимальне споживання пам'яті EVM. Пропоновані виправлення включають зміни вартості газу бездержавності, які гармонізують всі пов'язані зі зберіганням витрати за допомогою простої формули, та ця пропозиція щодо ціноутворення пам'яті.
• Видалення прекомпілювання: багато з прекомпілювань, які сьогодні є в Ethereum, є зайво складними та відносно не використовуються, і становлять значну частку невдач у згоді, не бувши дійсно використаними жодними додатками. Два способи вирішення цього: (i) просто видалення прекомпілювання, і (ii) заміна його на (неодмінно більш дорогий) шматок коду EVM, який реалізує ту саму логіку.Цей проект EIP пропонуєзробити це для попередньої компіляції ідентифікатора як перший крок; пізніше RIPEMD160, MODEXP і BLAKE можуть бути кандидатами на видалення.
• Видалення спостереження за газом: зробити виконання EVM нездатним бачити, скільки газу залишилося. Це зіпсувало б кілька додатків (особливо, спонсоровані транзакції), але забезпечило б набагато простіше оновлення у майбутньому (наприклад, для більш розширених версій gate).багатовимірний газ. The Специфікація EOFвже робить газ неспостережним, хоча для корисного застосування в спрощенні протоколу EOF потрібно зробити обов'язковим.
• Удосконалення статичного аналізу: сьогодні код EVM важко статично аналізувати, особливо тому, що стрибки можуть бути динамічними. Це також ускладнює створення оптимізованих реалізацій EVM, які попередньо компілюють код EVM на якусь іншу мову. Потенційно ми можемо виправити це за допомогою видалення динамічних стрибків(або зробляючи їх набагато дорожчими, наприклад, вартість газу лінійно залежить від загальної кількості JUMPDEST у контракті). EOF це робить, хоча для отримання вигод від спрощення протоколу це потребуватиме зробити EOF обов'язковим.

Якісь посилання на існуючі дослідження?

• Наступні кроки в очищенні: https://notes.ethereum.org/I_AIhySJTTCYau_adoy2TA
• SELFDESTRUCT: @vbuterin/selfdestruct"">https://hackmd.io/@vbuterin/selfdestruct
• Пристосування до SSZ EIPS:[1][2] [3]
• Зміни вартості газу безстанність: https://eips.ethereum.org/EIPS/eip-4762
• Лінійна ціноутворення пам'яті: https://notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw
• Видалення попередньої компіляції: https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg
• Видалення фільтру Блума: https://eips.ethereum.org/EIPS/eip-7668
• Спосіб здійснення безпечного вилучення журналу поза ланцюжком за допомогою інкрементально перевірної обчислювальної (читайте: рекурсивні STARKs):https://notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw

Що залишилося зробити, і які компроміси?

Основним компромісом при спрощенні такого роду можливостей є (i) наскільки ми спрощуємо та наскільки швидко проти (ii) зворотної сумісності. Вартість Ethereum як ланцюга полягає в тому, що ви можете розгорнути додаток і бути впевненими, що він працюватиме ще багато років. В той же час, можливо підійти до цієї ідеї занадто далеко і, перефразувати Вільяма Дженнінгса Браяна, «розіп'яти Ethereum на хресті зворотної сумісності». Якщо в Ethereum існують лише дві програми, які використовують певну функцію, і одна з них не має жодного користувача протягом років, а інша майже повністю не використовується і захищає загальну суму в $57, то ми просто повинні видалити цю функцію, і якщо потрібно, відшкодувати постраждалим $57 з власного карману.

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

• Крок 1: почніть говорити про видалення функції X
• Крок 2: провести аналіз, щоб визначити, наскільки видалення X руйнує додатки, залежно від результатів, або (i) відмовитися від ідеї, (ii) продовжити згідно з планом, або (iii) визначити змінений «найменш руйнівний» спосіб видалення X та продовжити з ним
• Крок 3: створіть офіційний EIP, щоб скасувати X. Переконайтеся, що популярна інфраструктура вищого рівня (наприклад, мови програмування, гаманці) поважає цю функцію, і припиніть використовувати цю функцію.
• Крок 4: нарешті, насправді видалити X

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

EOF

Головний набір змін, який був запропонований для EVM, цеФормат об'єкта EVM (EOF). EOF вводить велику кількість змін, таких як заборона газової спостережуваності, спостережуваність коду (тобто відсутність CODECOPY), що дозволяє лише статичні стрибки. Мета полягає в тому, щоб дозволити EVM більше оновлюватися, таким чином, щоб він мав сильніші властивості, зберігаючи при цьому зворотну сумісність (оскільки EVM до EOF все ще існуватиме).

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

Як воно взаємодіє з іншими частинами дорожньої карти?

Багато з пропозицій «вдосконалення» в іншій частині дорожньої карти також є можливостями для спрощення старих функцій. Щоб повторити деякі приклади зверху:

• Перехід на фіналізацію з одним слотом дає нам можливість прибрати комітети, переробити економіку та зробити інші спрощення, пов'язані з proof-of-stake.
• Повна реалізація абстракції облікового запису дозволяє нам видалити багато існуючої логіки обробки транзакцій, перемістивши її в частину «коду EVM за замовчуванням облікового запису», на який можуть бути замінені всі ЕОА.
• Якщо ми переведемо стан Ethereum до бінарних хеш-дерев, це може бути узгоджено з новою версією SSZ, так що всі структури даних Ethereum можуть бути хешовані однаковим чином.

Більш радикальний підхід: перетворити значну частину протоколу на код контракту

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

Найекстремальніша версія цього полягає в тому, щоб Ethereum L1 фактично був лише ланцюжком маяка та ввести мінімальну ВМ (наприклад, RISC-V, Каїрабо ще більш мінімальний, спеціалізований для систем доведення) , що дозволяє будь-кому створювати власний rollup. EVM стане першим з цих rollup. Це іронічно виявляється тим самим результатом, що й в Пропозиції щодо середовища виконання на 2019-20 роки, хоча SNARKs роблять його значно більш життєздатним для фактичної реалізації.

Більш помірний підхід полягає в тому, щоб залишити відношення між ланцюжком-маяком та поточним середовищем виконання Ethereum без змін, але зробити заміну EVM на місці. Ми можемо вибрати RISC-V, Cairo або іншу віртуальну машину (VM) в якості нового «офіційного Ethereum VM», а потім примусово конвертувати всі контракти EVM у новий код VM, який інтерпретує логіку початкового коду (шляхом компіляції або інтерпретації). Теоретично, це навіть можна зробити з «цільовою VM», яка є версією EOF.

Увага:

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