Особлива подяка Джастін Дрейку, Тіму Бейко, Метту Гарнетту, Пайпер Мерріам, Маріусу ван дер Вейдену та Томашу Станчаку за зворотний зв’язок та рецензію.

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

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

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

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

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

The Purge: основна мета.

· Зниження вимог клієнта до зберігання за рахунок зменшення або усунення необхідності постійного зберігання всієї історії і навіть кінцевого стану для кожної Нода.

· Шляхом усунення зайвих функцій для Падінняпротокол складності.

Зміст статті:

· Історія закінчення терміну дії

· Стан спливає (Стан закінчується)

· Очищення функцій (Feature cleanup)

Історія закінчення

Що вирішує ця проблема?

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

Що це, і як воно працює?

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

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

Зараз Етерум вже почав відмовлятися від моделі, в якій всі Ноди постійно зберігають усю історію. Блок Консенсусу (тобто частина, пов’язана з Доказом утримання) зберігається лише близько 6 місяців. Blob зберігається лише близько 18 днів. EIP-4444 спрямований на введення зберігання історії Блоку та Квитанцій на один рік. Довгострокова мета - створити єдиний термін (можливо, близько 18 днів), протягом якого кожна Нода відповідає за зберігання всього вмісту, а потім створити мережу peer-to-peer, складену з Нод Етеруму, для зберігання старих даних у розподіленому мережевому способі.

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

Які зв’язки існують з існуючими дослідженнями?

· ІП-4444 ;

· Торренти та EIP-4444 ；

· Мережа порталів;

· Порталові мережі та EIP-4444 ；

· Розподілений зберігання та пошук об’єктів SSZ в Portal 中;

· Як підвищити обмеження газу (Парадигма).

Що ще потрібно зробити, що потрібно врахувати?

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

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

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

2. Яка глибина історичного зберігання в протоколі Глибина?

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

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

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

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

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

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

Що вирішує ця проблема?

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

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

Воно є, як воно працює

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

1. Ефективність: не потрібно великої кількості додаткових обчислень для виконання процесу до настання терміну.

2. Людино-орієнтованість: якщо хтось пробув у печері протягом п’яти років і повернувся, він не повинен втратити доступ до ETH, ERC 20, Невзаємозамінний токен, позиції CDP…

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

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

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

· Часткові рішення для прострочених станів

· Рекомендація щодо закінчення стану на основі циклу Адреса.

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

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

Основна різниця між цими пропозиціями полягає в тому, як ми визначаємо «недавно» та «блоки». Одним з конкретних пропозицій є EIP-7736, яка ґрунтується на введенні дизайну «стебла-листка» для Verkle-дерева (хоча вона сумісна з будь-якою формою безстаних станів, наприклад, бінарне дерево). За цим дизайном заголовки, коди та слоти зберігання, що сусідять один з одним, зберігаються в одній «головній гілці». Дані, що зберігаються в підгілці, можуть складатися з максимум 256 * 31 = 7,936 байтів. У багатьох випадках весь заголовок, код облікового запису та багато ключових слотів зберігаються в одній головній гілці. Якщо дані в певній головній гілці не читаються або не записуються протягом 6 місяців, то ці дані більше не зберігаються, а замість цього зберігається лише 32-байтовий зобов’язання («стъжка») для цих даних. У майбутньому транзакції, які отримують доступ до цих даних, будуть потребувати «відродження» даних та надавати докази, що ґрунтуються на зобов’язанні.

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

Через стимули, це стає ще складнішим: атакувальник може змусити клієнтський бік постійно зберігати велику кількість стану, помістивши великий обсяг даних в одне піддерево та відправляючи одну угоду щорічно для “оновлення дерева”. Якщо ви зробите вартість поновлення пропорційною розміру дерева (або часу тривалості поновлення пропорційно діаметру), хтось може завдати шкоди іншим користувачам, помістивши велику кількість даних в те ж саме піддерево, що й вони. Люди можуть намагатися обмежити обидва цих проблем, роблячи розмір піддерева динамічним залежно від розміру, наприклад, кожні послідовні 2 16 = 65536 об’єктів стану можуть розглядатися як “група”. Однак ці ідеї є більш складними; оснований на стовбурі підхід є простішим і може регулювати стимули, оскільки зазвичай всі дані під стовбуром відносяться до одного і того ж додатку або користувача.

Рекомендації щодо стану терміну дії на основі періоду 01928374656574839201

Якщо ми хочемо повністю уникнути будь-якого постійного стану зростання, навіть 32-байтовий засіб, що робити? Це складне питання через конфлікт відродження: якщо об’єкт стану видаляється, пізніше виконання EVM помістить інший об’єкт стану на точно таке ж саме місце, але якщо людина, яка цікавиться початковим об’єктом стану, повертається і намагається його відновити, що робити? Коли частковий стан закінчується, “засіб” буде перешкоджати створенню нових даних. При повному закінченні стану ми навіть не зможемо зберігати засіб.

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

Одна з ключових ідей, яка сприятливо впливає на користувачів і розробників, - це поняття циклу Адреса. Цикл Адреса - це цифра, що належить до Адреса. Основне правило полягає в тому, що Адреса з циклом N можуть бути прочитані або записані лише під час або після циклу N (тобто, коли список дерев стану досягає довжини N). Якщо ви хочете зберегти новий об’єкт стану (наприклад, новий контракт або новий баланс ERC 20), ви можете зберегти його негайно, без необхідності доводити, що раніше нічого не було, якщо ви переконані, що розмістите об’єкт стану в контракті з циклом Адреса N або N-1. З іншого боку, будь-які додатки або редагування, зроблені під час старого циклу Адреса, потребують доказів.

Цей дизайн зберігає більшість властивостей поточного Ethereum, не потребує додаткового обчислення, дозволяє практично так само, як зараз, писати додатки (ERC 20 потребує переписування, щоб забезпечити зберігання балансів на Адреса підциклу N в підконтракті, самостійно маючи Адреса підцикл N), вирішує проблему “користувач входить у печеру на п’ять років”. Однак він має велику проблему: Адреса потребує розширення до понад 20 байтів, щоб відповідати циклу Адреса.

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

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

0x01 (червоний) 0000 (помаранчевий) 000001 (зелений) 57 вічність408398 вічність7 Е5 f4552091 A69125 d5вічністьcb7вічність8C2659029395bdвічність (синій)。

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

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

Адреса空间收缩

Інший підхід полягає в тому, що ми негайно забороняємо деякі піддіапазони Адреси розміром 2 128 (наприклад, всі Адреси, що починаються з 0x ffffffff), а потім використовуємо цей діапазон для введення Адреси з циклом та хеш-значенням довжиною 14 байтів.

0xffffffff000169125 d5dFcb7B8C2659029395bdF

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

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

Які зв’язки існують з існуючими дослідженнями?

Ранні пропозиції

Блокчейн чистий;

Відновити;

Теорія керування розміром стану Ethereum;

Деякі можливі шляхи безстатевого та простроченого стану;

Деякі пропозиції з закінченням статусу

ЄІП-7736 ;

Адреса空间扩展文档

Початкова пропозиція;

Ipsilon коментар;

Коментарі до статей у блозі;

Якщо ми втрачаємо опір удару, що це руйнує.

Що ще потрібно зробити, що потрібно врахувати?

Я вважаю, що майбутнє має чотири можливі шляхи:

· Ми досягаємо безстанційності і ніколи не вводимо застарілих станів. Стан зростає (хоча й повільно: ми можливо не побачимо його понад 8 ТБ протягом десятків років), але його потрібно мати тільки для відносно спеціальних категорій користувачів: навіть перевірячі PoS не потребують стану.

Один з функціональних компонентів, який вимагає доступу до частини стану, є генерація списків в розсіяному вигляді: кожен користувач відповідає за підтримку частини дерева стану, яка містить його власний обліковий запис. Коли вони розсилають транзакцію, вони розсилають транзакцію з підтвердженням об’єкта стану, до якого вони мали доступ під час перевірки (це стосується облікових записів EOA та ERC-4337). Потім безстатевий перевірник може об’єднати ці підтвердження в підтвердження, що містить список.

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

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

· Ми проводимо старіння стану через зменшення простору Адреса. Це займе кілька років, щоб забезпечити вирішення всіх безпечних ризиків, пов’язаних з конфліктами Адреса (включаючи Крос-ланцюгові взаємодії).

Важливою є те, що в кінцевому підсумку доведеться вирішити проблеми розширення та стискання простору Адреса, незалежно від того, чи буде втілено схему, яка залежить від зміни формату Адреса. Зараз генерація конфліктів Адреса вимагає приблизно 2 80 хеш-значень, і для учасників з вкрай рідкими ресурсами таке обчислювальне навантаження вже є прийнятним: GPU може виконати близько 2 27 хеш-значень, тому за рік може бути обчислено 2 52, отже, всіма GPU в світі (приблизно 230) можна обчислити зіткнення за близько 1/4 року, а FPGA та ASIC можуть ще прискорити цей процес. У майбутньому такі атаки стануть доступними для все більшої кількості людей. Тому втілення повної схеми зі строком дії можливо не коштуватиме так багато, як здається на перший погляд, оскільки ми все одно мусимо вирішити цю дуже складну проблему Адреса.

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

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

Очистка функцій

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

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

Що це, і як воно працює?

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

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

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

· RLP → SSZ конвертація: спочатку об’єкти Ethereum серіалізувалися за допомогою кодування, відомого як RLP. RLP є безтиповим і зайвою складністю. На сьогоднішній день сигнальна мережа використовує SSZ, яке у багатьох відношеннях є значно кращим, оскільки підтримує не тільки серіалізацію, але й хешування. У кінцевому підсумку ми сподіваємося повністю позбутися RLP і перенести всі типи даних до структури SSZ, що зробить оновлення набагато простішими. Поточні EIP включають [1] [2] [3].

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

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

· Кінцеве видалення механізму сигнальної мережі: механізм сигнальної мережі спочатку був введений для забезпечення перевірки легкого клієнта ETH мережі. Однак це значно ускладнює протокол. На кінцевому етапі ми зможемо безпосередньо використовувати верифікацію ETH мережі на рівні консенсусу SNARK, це усуне потребу в спеціалізованому протоколі легкого клієнта. Ці зміни в консенсусі можуть дозволити нам раніше видалити сигнальну мережу шляхом створення більш «інтегрованого» протоколу легкого клієнта, який включає перевірку підпису випадкового підмножини підписувачів консенсусу ETH мережі.

· Уніфікований формат даних: на сьогоднішній день стан виконання зберігається в дереві Меркля-Патріції, стан Консенсус зберігається в дереві SSZ, і блоб подається через обіцянку KZG. У майбутньому має сенс встановити єдиний уніфікований формат для даних блоку і єдиний уніфікований формат для стану. Ці формати задовольнять всі важливі вимоги: (i) просте доведення для клієнтів без стану, (ii) серіалізація та кодування стирання даних, (iii) стандартизована структура даних.

· Видалення комітету сигнальна мережа: Цей механізм спочатку введено для підтримки виконання Шардинг у певних версіях. Замість цього, ми в кінцевому підсумку використовуємо Шардинг через L2 та blob. Таким чином, комітет є зайвим, тому проводиться операція зняття комітету.

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

Зараз декілька прикладів у EVM:

· Спрощена механіка газу: Поточні правила газу ще не були належним чином оптимізовані, тому неможливо чітко обмежити кількість ресурсів, необхідних для верифікації Блок01928374656574839201. Ключові приклади включають (i) вартість зберігання читання/запису, яка спрямована на обмеження кількості читань/записів в блоку, але наразі досить довільна, та (ii) правила заповнення пам’яті, які наразі дуже складно оцінити максимальне споживання пам’яті EVM. Запропоновані заходи щодо виправлення включають зміну вартості газу для безстандартних операцій (об’єднання всіх витрат, пов’язаних зі зберіганням, у просту формулу) та пропозицію щодо ціноутворення пам’яті.

· Видалення попередньої компіляції: У Ethereum зараз є багато попередньо скомпільованого коду, який є непотрібно складним, відносно не використовуваним і у значній мірі спричиняє велику частку невдачі в Консенсусі, оскільки практично жоден додаток не використовує його. Два можливих підходи до вирішення цієї проблеми: (i) просто видалити попередньо скомпільований код; (ii) замінити його на фрагмент EVM-коду, який реалізує ту саму логіку (і, безперечно, буде дорожчим). Ця версія EIP пропонує спочатку видалити попередньо скомпільований код для перевірки прав. На подальшій стадії можливо видалення таких операцій, як RIPEMD 160, MODEXP і BLAKE.

· Видалення газової спостережуваності: забезпечення того, що виконання EVM більше не може бачити, скільки газу залишилося. Це пошкодить деякі додатки (найбільш очевидно - спонсорська транзакція), але в майбутньому оновлення будуть легшими (наприклад, для більш високих версій багатовимірного газу). Специфікація EOF уже зробила газ неспостережним, але для спрощення протоколу EOF потрібно зробити обов’язковим.

· Покращення статичного аналізу: В даний час EVM-код важко піддавати статичному аналізу, особливо через те, що переходи можуть бути динамічними. Це також ускладнює оптимізацію реалізації EVM (попереднє компілювання EVM-коду в інші мови програмування). Ми можемо вирішити цю проблему, видаливши динамічні стрибки (або зробивши їх більш дорогими, наприклад, лінійною вартістю газу для загальної кількості JUMPDEST в контракті). EOF робить це, хоча для отримання вигод від спрощення протоколу потрібно обов’язково виконувати EOF.

Які зв’язки існують з існуючими дослідженнями?

· Последующие шаги по очистке;

· Руйнівна

· SSZ конвертування EIPS: [1] [2] [3];

· Без стану газ зміна вартості;

· Лінійне ціноутворення пам’яті;

· Попередня компіляція видалена;

· видалення фільтра блум;

· Метод, який використовує інкрементне перевірку обчислень для безпечного пошуку журналів за допомогоюпоза блокчейном (читати: рекурсивний STARK);

Що ще потрібно зробити, що потрібно врахувати?

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

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

1. Почнемо обговорювати функцію видалення X;

2. Проведення аналізу для визначення впливу видалення X на додаток залежить від конкретного результату: (i) відмовитися від ідеї, (ii) продовжувати за планом або (iii) визначити спосіб видалення X і продовження, який має «мінімально можливий руйнівний» вплив.

3. Розробити офіційний EIP для відмови від X. Переконайтеся, що популярна інфраструктура вищого рівня (наприклад, мови програмування, Гаманець) поважає це і припиняє використання цієї функції.

4. Нарешті, фактично видалити X;

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

Кінець файлу

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

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

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

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

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

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

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

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

Более радикальна спрощена стратегія ETH Pole є збереження протоколу, але перенесення його основної частини з функцій протоколу до коду контракту.

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

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

Посилання на оригінальний текст