Важливим і постійно недооціненим аспектом «недовіри», «проходження тесту на відмову» та «самосуверенітету» є простота протоколу. Навіть якщо протокол надзвичайно децентралізований із сотнями тисяч вузлів, має 49% стійкість до відмов, а вузли повністю перевіряють усе за допомогою квантово-безпечних peerd і stark, якщо протокол — це громіздкий хаос із сотень тисяч рядків коду та п'яти форм криптографії рівня PhD, цей протокол врешті-решт не проходить усі три тести: * Це не бездовіра, бо доводиться довіряти невеликому класу верховних жерців, які кажуть, які властивості має протокол * Це не проходить тест на вихід, бо якщо існуючі клієнтські команди зникають, новим командам надзвичайно важко досягти такого ж рівня якості * Це не самосуверенність, бо якщо навіть найтехнічніші люди не можуть оглянути і зрозуміти цю річ, вона не повністю ваша Це також менш безпечно, оскільки кожна частина протоколу, особливо якщо вона може взаємодіяти з іншими складними способами, несе ризик порушення протоколу. Один із моїх страхів щодо розробки протоколу Ethereum полягає в тому, що ми можемо надто прагнути додавати нові функції для задоволення дуже специфічних потреб, навіть якщо ці функції роздувають протокол або додають цілі нові типи взаємодіючих компонентів чи складну криптографію як критичні залежності. Це може бути корисно для короткострокового зростання функціональності, але дуже руйнівно для збереження довгострокової самосуверенітетності та створення столітньої децентралізованої гіперструктури, яка виходить за межі злетів і падіння імперій та ідеологій. Основна проблема полягає в тому, що якщо оцінювати зміни протоколу з точки зору «наскільки вони великі як зміни існуючого протоколу», то прагнення зберегти зворотну сумісність означає, що додавання відбувається набагато частіше, ніж віднімання, і протокол неминуче роздувається з часом. Щоб протидіяти цьому, процес розробки Ethereum потребує явної функції «спрощення» / «збору сміття». «Спрощення» має три метрики: * Мінімізація загальної кількості рядків коду в протоколі. Ідеальний протокол поміщається на одній сторінці — або принаймні на кілька сторінок * Уникнення зайвих залежностей від фундаментально складних технічних компонентів. Наприклад, протокол, безпека якого повністю залежить від хешів (ще краще: від рівно однієї хеш-функції), кращий за той, що залежить від хешів і решіток. Додавання ізогеній — найгірше, бо (вибачте справді геніальним працьовитим ботанікам, які це зрозуміли) ніхто не розуміє ізогеній. * Додавання більшої кількості _invariants_: основних властивостей, на які може покладатися протокол, наприклад, EIP-6780 (самознищенне видалення) додало властивість, що не більше ніж N слотів зберігання можна змінювати на слот, що значно спрощує розробку клієнтів, а EIP-7825 (газовий ліміт на перемикання) додав максимум вартості обробки однієї транзакції, що значно допомагає ZK-EVM і паралельному виконанню. Збір сміття може бути фрагментарним або масштабним. Підхід по частинах намагається взяти існуючі функції та оптимізувати їх так, щоб вони були простішими та зрозумілішими. Прикладом є реформи вартості газу в Гламстердамі, які роблять багато витрат на газ, раніше довільними, натомість залежать від невеликої кількості параметрів, які чітко пов'язані зі споживанням ресурсів. Одним із масштабних зборів сміття було заміна PoW на PoS. Інша, ймовірно, станеться в рамках консенсусу Lean, відкриваючи простір для виправлення великої кількості помилок одночасно ( ). Інший підхід — «зворотна сумісність у стилі Розетти», коли складні, але маловикористовувані функції залишаються придатними для використання, але «понижені» з обов'язкового протоколу і натомість стають кодом смарт-контрактів, щоб нові клієнтські розробники не потребували їх користуватися. Приклади: * Після переходу до повної абстракції нативних акаунтів усі старі типи tx можна вивести з експлуатації, а EOA конвертувати у смарт-контрактні гаманці, код яких може обробляти всі ці типи транзакцій * Ми можемо замінити існуючі попередні компіляції (окрім тих, які _дійсно_ потрібні) на EVM або пізніший RISC-V код * Згодом ми можемо змінити віртуальну машину з EVM на RISC-V (або іншу простішу віртуальну машину); EVM можна перетворити на смарт-контракт у новій віртуальній машині. Нарешті, ми хочемо відійти від того, щоб клієнтські розробники відчували потребу працювати з усіма старими версіями протоколу Ethereum. Це можна залишити для старіших версій клієнтів, які працюють у docker-контейнерах. У довгостроковій перспективі я сподіваюся, що темпи зміни на Ethereum будуть повільнішими. Я думаю, з різних причин це зрештою _мусить_ статися. Ці перші п'ятнадцять років частково слід розглядати як підлітковий період, коли ми досліджували багато ідей і бачили, що працює, що корисно, а що ні. Ми повинні прагнути уникати того, щоб ті частини, які не є корисними, постійно перешкоджали протоколу Ethereum. В основному, ми хочемо покращити Ethereum так, щоб виглядати так: