*Окрема подяка Джастіну Дрейку, Тіні Жень і Йоаву Вайс за їхні відгуки та рецензію. *
З самого початку проекту Ethereum існувала сильна філософія намагання зробити ядро Ethereum максимально простим і досягти цього, наскільки це можливо, створюючи на його основі протоколи. У просторі блокчейну дебати «будувати на L1» проти «фокусу на L2» часто розглядають як насамперед про масштабування, але насправді існують схожі проблеми щодо задоволення потреб багатьох користувачів Ethereum: обмін цифровими активами, конфіденційність , імена користувачів, розширене шифрування, безпека облікового запису, стійкість до цензури, попередній захист тощо. Однак останнім часом було зроблено кілька обережних спроб закріпити більше цих функцій в основному протоколі Ethereum.
У цій статті ми розглянемо деякі філософські міркування, що стоять за оригінальною філософією мінімальної інкапсуляції, а також деякі новітні способи мислення щодо цих ідей. Мета полягатиме в тому, щоб почати будувати структуру для кращого визначення можливих цілей, де інкапсуляція певної функціональності може бути вартою розгляду.
Рання філософія мінімалізму протоколу
На початку історії того, що тоді було відомо як «Ethereum 2.0», було сильне бажання створити чистий, простий і красивий протокол, який намагався якомога менше будувати на собі та залишав майже всю таку роботу користувачам. В ідеалі протокол — це просто віртуальна машина, а перевірка блоку — це лише виклик віртуальної машини.
Це приблизна реконструкція діаграми дошки, яку ми з Гевіном Вудом намалювали на початку 2015 року, коли я говорив про те, як виглядатиме Ethereum 2.0.
«Функція переходу стану» (функція, яка обробляє блок) буде лише одним викликом віртуальної машини, а вся інша логіка відбуватиметься через контракти: деякі контракти системного рівня, але переважно контракти, надані користувачем. Дуже приємною особливістю цієї моделі є те, що навіть весь хардфорк можна описати як одну транзакцію з контрактом на блоковий процесор, який буде схвалено керуванням поза ланцюгом або в ланцюзі, а потім буде оновлено дозвіл на виконання.
Ці обговорення в 2015 році стосуються саме двох областей, які ми розглядаємо: абстрагування облікового запису та масштабування. У випадку масштабування ідея полягає в тому, щоб спробувати створити максимально абстрактну форму масштабування, яка виглядає як природне розширення діаграми вище. Контракти можуть викликати дані, які не зберігаються більшістю вузлів Ethereum, і протокол виявить це та вирішить виклик за допомогою деяких дуже загальних розширених обчислювальних функцій. З точки зору віртуальної машини, виклик перейде в якусь окрему підсистему, а потім чарівним чином поверне правильну відповідь через деякий час.
Ми коротко дослідили цю ідею, але швидко відмовилися від неї, оскільки були надто зосереджені на тому, щоб довести, що будь-яке масштабування блокчейну можливе. Хоча, як ми побачимо пізніше, поєднання вибірки доступності даних і ZK-EVM означає, що можливе майбутнє масштабування Ethereum насправді виглядає дуже близьким до цього бачення! З іншого боку, з абстракцією облікового запису ми з самого початку знали, що певна реалізація можлива, тому дослідження негайно почали намагатися зробити щось якомога ближче до чистої вихідної точки «транзакція — це лише дзвінок».
*Існує багато шаблонного коду між обробкою транзакції та здійсненням фактичного основного виклику EVM з адреси відправника, з додатковим шаблонним кодом. Як зменшити цей код якомога ближче до нуля? *
Одним із основних кодів тут є validate_transaction(state, tx), який відповідає за перевірку правильності nonce та підпису транзакції. Справжньою метою абстракції облікового запису з самого початку було дозволити користувачам замінити базову неінкрементну перевірку та перевірку ECDSA власною логікою перевірки, щоб користувачі могли легше використовувати такі функції, як соціальне відновлення та гаманці з кількома підписами. Отже, пошук способу реструктуризації apply_transaction у простий виклик EVM — це не просто завдання «зробити код чистим заради того, щоб зробити код чистим»; скоріше це стосується перенесення логіки до коду облікового запису користувача, надаючи користувачам гнучкість, яку вони потреба.
Однак наполягання на тому, щоб apply_transaction містило якомога менше фіксованої логіки, призвело до багатьох проблем. Ми можемо розглянути одну з найперших пропозицій абстракції облікового запису, EIP-86.
Якби EIP-86 було включено як є, це зменшило б складність EVM ціною значного збільшення складності інших частин стеку Ethereum, вимагаючи, по суті, того самого коду, який потрібно написати деінде, на додаток до введення цілого новий клас дивовижності.Наприклад, та сама транзакція з тим самим хеш-значенням може з’являтися кілька разів у ланцюжку, не кажучи вже про проблему кількох недійсних.
Численні проблеми з недійсністю в абстракції облікового запису. Одна транзакція, включена в ланцюжок, може зробити недійсними тисячі інших транзакцій у мемпулі, що полегшить мемпул для дешевого заповнення. *
Відтоді абстракція облікового запису розвивалася поетапно. EIP-86 згодом став EIP-208, і згодом з’явився практичний EIP-2938.
Однак EIP-2938 не є мінімалістичним. Його вміст включає:
Новий тип транзакції
Три нові глобальні змінні обсягу транзакцій
Два нових коди операції, включаючи дуже незграбний код операції PAYgas для обробки ціни на газ і перевірки ліміту газу, як контрольні точки виконання EVM і для тимчасового зберігання ETH для одноразової оплати
Складний набір стратегій видобутку та повторної передачі, включаючи список заборонених кодів операцій на етапі перевірки транзакцій
У спробі досягти абстракції облікового запису без залучення розробників ядра Ethereum (які були зосереджені на оптимізації клієнтів Ethereum і здійсненні злиття), EIP-2938 був остаточно перетворений на ERC-4337, який був повністю поза протоколом.
ERC-4337. Він повністю покладається на виклики EVM!
Оскільки це ERC, він не вимагає хардфорка і технічно існує «поза протоколом Ethereum». Отже... проблему вирішено? Виявляється, це не так. Поточна середньострокова дорожня карта для ERC-4337 фактично передбачає зрештою перехід великих частин ERC-4337 у низку функцій протоколу, що є корисним прикладом керівництва щодо того, чому слід розглянути цей шлях.
Пакет ERC-4337
Обговорюється кілька ключових причин можливого повторного включення ERC-4337 у протокол:
Ефективність газу: будь-яка операція, що виконується всередині EVM, спричиняє певний рівень накладних витрат на віртуальну машину, включаючи неефективність під час використання дорогих на газ функцій, таких як слоти для зберігання. Наразі ця додаткова неефективність становить щонайменше 20 000 газу або більше. Введення цих компонентів у протокол є найпростішим способом усунення цих проблем.
Ризик помилки коду: якщо «контракт точки входу» ERC-4337 має достатньо жахливу помилку, усі сумісні з ERC-4337 гаманці можуть побачити, що всі їхні кошти виснажаться. Заміна контрактів внутрішньопротокольними функціями створює неявне зобов’язання виправляти помилки коду за допомогою хардфорків, тим самим усуваючи ризик того, що користувачі залишаться без коштів.
Підтримує коди операцій EVM, наприклад txt.origin. Сам ERC-4337 змушує txt.origin повертати адресу «групувальника», який пакує набір дій користувача в транзакцію. Власна абстракція облікового запису вирішує цю проблему, змушуючи txt.origin вказувати на фактичний обліковий запис, який надсилає транзакцію, завдяки чому він веде себе так само, як EOA.
Стійкість до цензури: однією з проблем із розділенням пропонента й розробника є те, що стає легше переглядати окремі транзакції. У світі, де протокол Ethereum може ідентифікувати окремі транзакції, цю проблему можна значно полегшити за допомогою списків включення, які дозволяють пропонентам вказати список транзакцій, які мають бути включені в наступні два слоти майже в усіх випадках. Однак ERC-4337 за межами протоколу інкапсулює «операції користувача» в одну транзакцію, роблячи операції користувача непрозорими для протоколу Ethereum; тому список включень, наданий протоколом Ethereum, не зможе забезпечити захист від цензури для користувача ERC-4337. операції. Обгортання ERC-4337 і перетворення дії користувача на "належний" тип транзакції вирішило б цю проблему.
Варто зазначити, що в своїй поточній формі ERC-4337 значно дорожчий, ніж «базові» транзакції Ethereum: транзакція коштує 21 000 газу, тоді як ERC-4337 коштує близько 42 000 газу.
Теоретично повинна бути можливість налаштувати систему витрат на газ EVM, доки вартість у протоколі та вартість доступу до сховища поза протоколом не збігаються; немає жодних причин витрачати 9000 газу на передачу ETH при редагуванні інших типів сховища операції дешевші. Насправді два EIP, пов’язані з майбутньою трансформацією дерева Verkle, насправді намагаються зробити саме це. Але навіть якщо ми це зробимо, є очевидна причина, чому незалежно від того, наскільки ефективним стане EVM, функції інкапсульованого протоколу неминуче будуть набагато дешевшими, ніж код EVM: інкапсульованому коду не потрібно платити за попереднє завантаження.
Повнофункціональний гаманець ERC-4337 великий, а реалізація, скомпільована та розміщена в ланцюжку, займає близько 12 800 байт. Звичайно, ви можете розгорнути цей код один раз і використати DELEGATECALL, щоб дозволити кожному окремому гаманцю викликати його, але вам все одно потрібно буде отримати доступ до коду в кожному блоці, де він використовується. Згідно з EIP вартості газу дерева Verkle, 12 800 байтів утворять 413 блоків. Доступ до цих фрагментів вимагатиме сплати 2-кратної вартості гілки_свідка (загалом 3800 газу) і 413-кратної вартості фрагмента_свідка (загалом 82 600 газ). Це навіть не згадує саму точку входу ERC-4337, яка у версії 0.6.0 має 23 689 байтів у ланцюжку (приблизно 158 700 газів для завантаження відповідно до правил EIP дерева Verkle).
Це призводить до проблеми: вартість газу для фактичного доступу до цих кодів має певним чином амортизуватися між транзакціями. Поточний підхід, який використовує ERC-4337, не дуже хороший: перша транзакція в пакеті потребує одноразових витрат на зберігання/читання коду, що робить її набагато дорожчою, ніж інші транзакції. Внутрішньопротокольна інкапсуляція дозволить цим загальнодоступним бібліотекам стати частиною протоколу та вільно доступними для всіх.
Чого ми можемо навчитися з цього прикладу, і коли слід практикувати інкапсуляцію в більш загальному плані?
У цьому прикладі ми бачимо кілька різних обґрунтувань для інкапсуляції абстракцій облікових записів у протоколах.
**Ринкові підходи, які «підштовхують складність до краю», швидше за все, зазнають невдачі, коли постійні витрати високі. **Насправді довгострокова дорожня карта абстракції облікового запису передбачає багато постійних витрат на блок. 244 100 газів для завантаження стандартизованого коду гаманця – це одне; але агрегація може додати сотні тисяч газів для перевірки ZK-SNARK, а також витрати на перевірку доказів у мережі. Немає способу стягувати з користувачів плату за ці витрати, не вводячи масової неефективності ринку, і перетворення деяких із цих функцій на функції протоколу, які є вільно доступними для всіх, вирішило б цю проблему дуже добре.
**Реакція спільноти на помилки коду. **Якщо певний фрагмент коду використовується всіма користувачами або дуже широким колом користувачів, для спільноти блокчейнів часто доцільніше взяти на себе відповідальність за хардфорк для виправлення будь-яких помилок, що виникають. ERC-4337 представляє велику кількість глобально спільного коду. У довгостроковій перспективі, безсумнівно, розумніше виправляти помилки в коді за допомогою хардфорків, ніж змушувати користувачів втрачати велику кількість ETH.
**Іноді сильнішу форму протоколу можна реалізувати шляхом безпосереднього використання його функціональних можливостей. **Ключовим прикладом є стійкі до цензури функції протоколу, такі як списки включення: списки включення в протоколі можуть гарантувати стійкість до цензури краще, ніж методи за межами протоколу. Щоб операції на рівні користувача справді отримували вигоду від внутрішньопротоколного включають списки, операції на рівні користувача повинні бути "розбірливими" для протоколу. Іншим менш відомим прикладом є те, що дизайн доказу частки Ethereum 2017 року мав абстракцію облікових записів ключів частки, від якої відмовилися на користь інкапсульованого BLS, оскільки BLS підтримував механізм «агрегації», який мав бути реалізований у протоколі та рівні мережі, це може зробити обробку великої кількості підписів ефективнішою.
Але важливо пам’ятати, що навіть абстракція облікового запису в протоколі інкапсуляції все ще є величезною «деінкапсуляцією» порівняно зі статус-кво. Сьогодні транзакції верхнього рівня Ethereum можуть бути ініційовані лише з зовнішніх облікових записів (EOA), які перевіряються за допомогою єдиного підпису еліптичної кривої secp 256k 1. Абстракція облікового запису усуває це та залишає користувачеві визначати умови перевірки. Тому в цій історії про абстракцію облікових записів ми також бачимо головну причину проти інкапсуляції: Гнучкість для задоволення потреб різних користувачів.
Давайте конкретизуємо історію далі, переглянувши кілька інших прикладів функцій, які нещодавно розглядалися для інкапсуляції. Зокрема, ми розглянемо: ZK-EVM, розділення пропонента та конструктора, приватні пули пам’яті, ставку ліквідності та нову попередню компіляцію.
Пакет ЗК-ЕВМ
Давайте звернемо увагу на іншу потенційну ціль інкапсуляції для протоколу Ethereum: ZK-EVM. Наразі у нас є велика кількість ZK-зведень, які мають написати досить подібний код, щоб перевірити виконання подібних блоків Ethereum у ZK-SNARK. Існує досить різноманітна екосистема незалежних реалізацій: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth та багато інших.
Нещодавня суперечка в області EVM ZK-rollup стосується того, як боротися з помилками, які можуть з’являтися в коді ZK. Наразі всі ці діючі системи мають певну форму механізму «ради безпеки», який контролює систему атестації у разі помилки. Минулого року я намагався створити стандартизовану структуру, яка заохочувала б проекти уточнювати, наскільки вони довіряють системі атестації та наскільки вони довіряють Раді Безпеки, і поступово зменшувати свої повноваження щодо цієї організації з часом.
*У середньостроковій перспективі зведення, ймовірно, покладатиметься на кілька систем сертифікації, причому Рада безпеки матиме повноваження лише в крайніх випадках, коли дві різні системи сертифікації розходяться. *
Однак є відчуття, що частина цієї роботи здається зайвою. У нас уже є базовий рівень Ethereum, він має EVM, і ми вже маємо робочий механізм для роботи з помилками в реалізації: якщо є помилка, клієнт буде оновлено, щоб її виправити, і ланцюжок продовжить функціонувати . З точки зору клієнта з помилками, схоже, що завершені блоки більше не підтверджуватимуться, але принаймні ми не побачимо, як користувачі втратять кошти. Подібним чином, якщо зведені просто хочуть зберегти еквівалентну роль EVM, тоді їм потрібно запровадити власне управління, щоб постійно змінювати свої внутрішні правила ZK-EVM відповідно до оновлень базового рівня Ethereum, що здається неправильним, оскільки в кінцевому підсумку вони створені поверх. самого базового рівня Ethereum, він знає, коли оновлювати та відповідно до яких нових правил.
Оскільки ці L2 ZK-EVM в основному використовують ту саму EVM, що й Ethereum, чи можемо ми якимось чином включити «перевірку виконання EVM у ZK» у функціональність протоколу та обробляти винятки, застосовуючи соціальний консенсус Ethereum, як-от помилки та оновлення, як ми вже робимо для саме виконання EVM базового рівня?
Це важлива і складна тема.
Одна з можливих тем для дискусії щодо доступності даних у рідному ZK-EVM — це збереження стану. ZK-EVM були б набагато ефективнішими для обробки даних, якби їм не потрібно було передавати дані «очевидців». Тобто, якщо певний фрагмент даних уже був прочитаний або записаний у якомусь попередньому блоці, ми можемо просто припустити, що перевіряльник має до нього доступ і не повинен знову робити його доступним. Йдеться не лише про те, щоб не перезавантажувати сховище та код; виявляється, що якщо зведення стискає дані правильно, стиснення зі збереженням стану може зберегти до 3 разів більше даних порівняно зі стисненням без стану.
Це означає, що для попередньої компіляції ZK-EVM у нас є два варіанти:
**1.**Попередня компіляція вимагає, щоб усі дані були доступні в одному блоці. Це означає, що перевірка може бути без стану, але це також означає, що використання цього попередньо скомпільованого ZK-зведення набагато дорожче, ніж використання спеціального зведення коду.
**2.**Попередня компіляція дозволяє покажчикам вказувати на дані, використані або згенеровані попередніми виконаннями. Це робить ZK-rollup близьким до оптимального, але він більш складний і вводить новий стан, який має зберігатися прувером.
Чого ми можемо навчитися з цього? Існує вагома причина інкапсулювати верифікацію ZK-EVM якимось чином: зведення вже створює власну спеціальну версію, і Ethereum готовий запровадити EVM на L1 з урахуванням його кількох реалізацій і соціального консенсусу поза ланцюгом. неправильно, але L2, виконуючи ту саму роботу, мав би впровадити складний гаджет із залученням Ради безпеки. Але з іншого боку, є велика проблема в деталях: існують різні версії ZK-EVM, і вони мають різні витрати та переваги. Різниця між станом і без стану лише дряпає поверхню; спроби підтримувати «майже-EVM» спеціальний код, який був перевірений іншими системами, можуть відкрити більший простір для проектування. Тому упаковка ZK-EVM несе надію і виклик.
Розділення пропонента інкапсуляції та розробника (ePBS)
Зростання MEV робить виробництво блоків масштабною економічною діяльністю, за допомогою досвідчених акторів, здатних створювати блоки, які генерують більший дохід, ніж алгоритм за замовчуванням, який просто спостерігає за масивом транзакцій і містить їх. Наразі спільнота Ethereum намагалася вирішити цю проблему, використовуючи позапротокольні схеми поділу пропонента та розробника, такі як MEV-Boost, що дозволяє звичайним валідаторам («пропонаторам») надсилати блоки до Створення передається спеціалізованим виконавцям («Builders»). ").
Однак MEV-Boost робить припущення про довіру до нового класу акторів, які називаються ретрансляторами. За останні два роки було багато пропозицій створити «пакетований PBS». Які переваги цього? У цьому випадку відповідь дуже проста: PBS, побудований безпосередньо з використанням функцій протоколу, є потужнішим (у сенсі слабкішої довіри), ніж PBS, створений без їх використання. Це схоже на випадок інкапсуляції цінових оракулів у протоколі – хоча в цьому випадку є серйозні заперечення.
Інкапсулювати приватний пул пам'яті
Коли користувач надсилає транзакцію, вона одразу стає загальнодоступною та видимою для всіх, навіть до того, як її включено в мережу. Це робить користувачів багатьох додатків уразливими до економічних атак, як-от атак.
Нещодавно з’явилася низка проектів, присвячених створенню «приватних пам’ятних фондів» (або «крипто-мемпулів»), які шифрують транзакції користувачів, доки вони незворотно не будуть прийняті в блок.
Проблема, однак, полягає в тому, що така схема вимагає особливого типу шифрування: щоб запобігти переповненню системою користувачами та першим її дешифруванням, шифрування має бути автоматично розшифроване після фактичного незворотного прийняття транзакції.
Існують різні техніки з різними компромісами для реалізації цієї форми шифрування. Джон Шарбоно якось добре описав це:
Шифрування для централізованих операторів, таких як Flashbots Protect**. **
Шифрування блокування часу, ця форма шифрування може бути розшифрована будь-ким після певних послідовних кроків обчислення та не може бути розпаралелена;
Порогове шифрування, довірте розшифровку даних комітету чесної більшості. Конкретні пропозиції див. у концепції закритих ланцюгів маяків.
Надійне обладнання, наприклад SGX.
На жаль, кожен метод шифрування має різні недоліки. У той час як для кожного рішення є сегмент користувачів, які бажають йому довіряти, жодне рішення не є достатньо довіреним, щоб прийняти його Рівнем 1. **Тож, принаймні до удосконалення відкладеного шифрування або до якогось іншого технологічного прориву, інкапсуляція функції запобігання випередженню торгівлі на рівні 1 здається складною пропозицією, навіть якщо це досить цінна функція, яку багато програм вирішують. з'явився план.
Інкапсулюйте ставку ліквідності
Загальною потребою користувачів Ethereum DeFi є можливість одночасно використовувати свій ETH для стекінгу та як заставу в інших програмах. Ще один поширений запит — просто для зручності: користувачі хочуть мати можливість робити ставки (і захищати онлайн-ключі ставки) без складнощів, пов’язаних із запуском вузла та його постійною підтримкою онлайн.
Найпростішим «інтерфейсом» стекінгу, який задовольняє обидві ці потреби, є лише токен ERC 20: конвертуйте свій ETH у «стейк ETH», утримуйте його, а потім конвертуйте назад. Фактично, постачальники ставки ліквідності, такі як Lido та Rocket Pool, уже роблять це. Проте існують деякі природні механізми централізації, які діють у стейкінгу ліквідності: люди, природно, переходитимуть на стейкінг найбільшої версії ETH, оскільки вона є найбільш знайомою та ліквідною.
Кожна версія розставленого ETH повинна мати певний механізм для визначення того, хто може стати базовим оператором вузла. Воно не може бути необмеженим, оскільки тоді зловмисники приєднаються та використовуватимуть кошти користувачів для розширення своїх атак. Наразі двома найкращими є Lido та Rocket Pool, причому перший має операторів вузлів DAO у білому списку, а другий дозволяє будь-кому запускати вузол із депозитом у розмірі 8 ETH. Ці два методи мають різні ризики: метод Rocket Pool дозволяє зловмиснику здійснити 51% атаку на мережу та змушує користувачів оплачувати більшу частину витрат; що стосується методу DAO, якщо певний токен домінує, це призведе до єдиний, потенційно скомпрометований гаджет керування контролює велику частину всіх валідаторів Ethereum. До честі, такі протоколи, як Lido, реалізували гарантії, але одного рівня захисту може бути недостатньо.
У короткостроковій перспективі одним із варіантів є заохочення учасників екосистеми використовувати різноманітний набір постачальників ставки ліквідності, щоб зменшити ймовірність того, що домінуючий гравець створює системний ризик. Однак у довгостроковій перспективі це нестабільний баланс, і надмірне покладання на моральний тиск для вирішення проблем є небезпечним. Виникає природне запитання: **Чи є сенс інкапсулювати деякі функції в протоколі, щоб зробити ставку ліквідності менш централізованою? **
Ключове питання тут: яка функціональність у протоколі? Однією з проблем простого створення взаємозамінного токена «стейкінг ETH» у протоколі є те, що він або матиме інкапсульоване управління для всього Ethereum, щоб вибирати, хто має керувати вузлами, або буде відкритим, але це перетворить його на зловмисника. Інструменти.
Цікавою ідеєю є стаття Данкрада Фейста про максимізацію ставки ліквідності. По-перше, давайте спробуємо: якщо Ethereum зазнає атаки 51%, лише 5% атакованого ETH може бути скорочено. Це розумний компроміс; оскільки зараз на ставку понад 26 мільйонів ETH, вартість атаки на третину цього (~8 мільйонів ETH) є надмірною, особливо враховуючи, скільки атак «поза моделью» можна здійснити за один раз менша вартість. Фактично, подібні компроміси були досліджені в пропозиції Суперкомітету запровадити однослотовий фінал.
Якщо ми приймемо, що лише 5% атаки ETH скорочується, то більше 90% ставок ETH не постраждають від скорочення, тому їх можна буде використовувати як взаємозамінні рідинні токени стекінгу в протоколі, а потім використовувати в інших програмах.
Цей шлях цікавий. Але все одно залишається питання: що саме інкапсульовано? **Rocket Pool працює дуже подібно: кожен оператор вузла надає частину коштів, а учасники ліквідності забезпечують решту. Ми можемо просто налаштувати деякі константи, щоб обмежити максимальний штраф до 2 ETH, і існуючий rETH Rocket Pool стане безризиковим.
За допомогою простих коригувань протоколу ми також можемо робити інші розумні речі. Наприклад, припустімо, що нам потрібна система з двома «рівнями» ставок: оператори вузлів (високі вимоги до застави) і вкладники (без мінімальних вимог до застави, можуть приєднатися та залишити будь-коли), але ми все одно хочемо надати випадкову вибірку повноваження комітету вкладників запобігати централізації операторів вузлів, наприклад, рекомендувати список транзакцій, які повинні бути включені (з міркувань опору цензурі), контролювати вибір форка під час витоку неактивності або вимагати підписи на блоках. Це може бути досягнуто таким чином, що, по суті, виходить за межі протоколу, налаштувавши протокол, щоб вимагати від кожного валідатора надавати (i) звичайний ключ ставки, і (ii) адресу ETH, яка може використовуватися в кожному слоті, викликається для виведення ключ вторинної застави. Протокол надавав би обидва ключі, але механізм вибору другого ключа в кожному слоті можна було б залишити протоколу пулу розміщення. Можливо, все-таки краще інкапсулювати деякі функції безпосередньо, але варто зазначити, що такий простір дизайну «включити деякі речі, а інші залишити користувачеві» існує.
Інкапсулюйте більше попередньої компіляції
Попередньо скомпільовані контракти (або «попередньо скомпільовані контракти») — це контракти Ethereum, які реалізують складні криптографічні операції з логікою, реалізованою в коді клієнта, а не в коді смарт-контракту EVM. Попереднє кодування є компромісом, прийнятим на початку розробки Ethereum: оскільки накладні витрати на віртуальну машину занадто великі для дуже складного та вузькоспеціалізованого коду, ми можемо реалізувати деякі важливі програми у рідному коді. Цінуйте критичні операції, щоб зробити їх швидшими. Сьогодні це в основному включає деякі специфічні хеш-функції та операції з еліптичною кривою.
Наразі існує поштовх для додавання попередньої компіляції для secp 256 r 1, дещо іншої еліптичної кривої, ніж secp 256 k 1, яка використовується для базових облікових записів ethereum, яка широко використовується, оскільки добре підтримується надійними апаратними модулями. Використовуйте її для підвищення безпеки гаманця. В останні роки спільнота також наполягала на додаванні попередньої компіляції для BLS-12-377, BW 6-761, узагальненого парування та інших функцій.
Контраргументом до цих закликів до більшої кількості прекомпіляторів є те, що багато попередніх компіляторів, доданих раніше (таких як RIPEMD і BLAKE), зрештою використовувалися набагато рідше, ніж очікувалося, і ми повинні навчитися з цього. Замість того, щоб додавати більше попередньої компіляції для конкретних операцій, ми, мабуть, повинні зосередитися на більш м’якому підході, заснованому на таких ідеях, як EVM-MAX і пропозиція SIMD із режимом Hibernate-But-Always-Resumable, що дозволить реалізаціям EVM працювати з меншими витратами. Вартість виконання широкий спектр класів коду. Можливо, навіть існуючу маловикористовувану попередню компіляцію можна було б видалити та замінити (неминуче менш ефективною) реалізацією коду EVM тих самих функцій. Тим не менш, все ще можливо, що існують певні криптографічні операції, які є достатньо цінними, щоб їх можна було прискорити, тому має сенс додати їх як попередньо скомпільовані.
Чого ми навчилися з усього цього?
Бажання інкапсулювати якомога менше є зрозумілим і добрим; воно походить від філософської традиції Unix щодо створення мінімалістичного програмного забезпечення, яке може легко адаптуватися до різних потреб користувачів і уникнути прокляття роздуття програмного забезпечення. Однак блокчейн — це не операційна система персонального комп’ютера, а соціальна система. Це означає, що є сенс інкапсулювати певні функції в протоколі.
У багатьох випадках ці інші приклади схожі на те, що ми бачили в абстракції облікового запису. Але ми також отримали деякі нові уроки:
Інкапсульовані функції можуть допомогти уникнути ризиків централізації в інших областях стеку:
Часто мінімальний і простий базовий протокол висуває складність у певну екосистему за межами протоколу. З точки зору філософії Unix, це добре. Однак іноді існує ризик того, що позапротокольна екосистема стане централізованою, зазвичай (але не тільки) через високі постійні витрати. Інкапсуляція іноді може зменшити де-факто централізацію.
Інкапсуляція занадто великої кількості вмісту може призвести до надмірного навантаження на довіру та керування протоколом:
Це тема попередньої статті «Не перевантажуйте Ethereum Consensus»: якщо інкапсуляція певної функції послаблює модель довіри та робить Ethereum у цілому більш «суб’єктивним», це послаблює Ethereum. У цих випадках краще мати певну функціональність як механізм поверх Ethereum, а не намагатися перенести її в сам Ethereum. Найкращим прикладом тут є зашифровані пули пам’яті, які може бути трохи складно інкапсулювати, принаймні до тих пір, поки не покращиться шифрування затримки.
Інкапсуляція занадто великої кількості вмісту може зробити протокол надто складним:
Складність протоколу – це системний ризик, який збільшується через додавання занадто великої кількості функцій до протоколу. Найкращим прикладом є попередня компіляція.
У довгостроковій перспективі функція інкапсуляції може бути контрпродуктивною, оскільки потреби користувачів непередбачувані:
Функція, яку багато людей вважають важливою і яку використовуватимуть багато користувачів, на практиці, ймовірно, не використовується дуже часто.
Крім того, ставка ліквідності, ZK-EVM і попередньо скомпільовані приклади показують можливість середнього шляху: мінімальне життєздатне закріплення. Протокол не потребує інкапсуляції всієї функціональності, але може містити конкретні частини, які вирішують ключові проблеми, що робить функціональність легкою для реалізації, не надто параноїдальною або занадто вузькою. Приклади:
Замість інкапсуляції повної системи стейкінгу ліквідності краще змінити правила штрафних санкцій, щоб зробити ненадійне стейкінг ліквідності більш можливим;
Замість того, щоб інкапсулювати більше попередніх компіляторів, краще інкапсулювати EVM-MAX та/або SIMD, щоб полегшити ефективне впровадження ширшого класу операцій;
Можна просто інкапсулювати перевірку EVM замість інкапсуляції всієї концепції зведення.
Ми можемо розширити попередню діаграму наступним чином:
Іноді має сенс щось інкапсулювати, і видалення рідко використовуваних прекомпіляторів є одним із прикладів. Абстракція облікового запису в цілому, як згадувалося раніше, також є важливою формою деінкапсуляції. Якщо ми хочемо підтримувати зворотну сумісність для існуючих користувачів, механізм насправді може бути напрочуд схожим на той, який дезгортав попередню компіляцію: одна з пропозицій — EIP-5003, що дозволить EOA перетворювати свої облікові записи на те саме ( або краще) функціональний договір.
Які функції слід включити в протокол, а які слід залишити іншим рівням екосистеми, є складним компромісом. Очікується, що цей компроміс з часом покращуватиметься, оскільки наше розуміння потреб користувачів і доступний набір ідей і технологій продовжуватимуть покращуватися.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Остання велика стаття Бутеріна: Чи повинен протокол Ethereum інкапсулювати більше функцій?
Автор: Віталік Бутерін Упорядник: Odaily Planet Daily Nian Yinsitang
*Окрема подяка Джастіну Дрейку, Тіні Жень і Йоаву Вайс за їхні відгуки та рецензію. *
З самого початку проекту Ethereum існувала сильна філософія намагання зробити ядро Ethereum максимально простим і досягти цього, наскільки це можливо, створюючи на його основі протоколи. У просторі блокчейну дебати «будувати на L1» проти «фокусу на L2» часто розглядають як насамперед про масштабування, але насправді існують схожі проблеми щодо задоволення потреб багатьох користувачів Ethereum: обмін цифровими активами, конфіденційність , імена користувачів, розширене шифрування, безпека облікового запису, стійкість до цензури, попередній захист тощо. Однак останнім часом було зроблено кілька обережних спроб закріпити більше цих функцій в основному протоколі Ethereum.
У цій статті ми розглянемо деякі філософські міркування, що стоять за оригінальною філософією мінімальної інкапсуляції, а також деякі новітні способи мислення щодо цих ідей. Мета полягатиме в тому, щоб почати будувати структуру для кращого визначення можливих цілей, де інкапсуляція певної функціональності може бути вартою розгляду.
Рання філософія мінімалізму протоколу
На початку історії того, що тоді було відомо як «Ethereum 2.0», було сильне бажання створити чистий, простий і красивий протокол, який намагався якомога менше будувати на собі та залишав майже всю таку роботу користувачам. В ідеалі протокол — це просто віртуальна машина, а перевірка блоку — це лише виклик віртуальної машини.
Це приблизна реконструкція діаграми дошки, яку ми з Гевіном Вудом намалювали на початку 2015 року, коли я говорив про те, як виглядатиме Ethereum 2.0.
«Функція переходу стану» (функція, яка обробляє блок) буде лише одним викликом віртуальної машини, а вся інша логіка відбуватиметься через контракти: деякі контракти системного рівня, але переважно контракти, надані користувачем. Дуже приємною особливістю цієї моделі є те, що навіть весь хардфорк можна описати як одну транзакцію з контрактом на блоковий процесор, який буде схвалено керуванням поза ланцюгом або в ланцюзі, а потім буде оновлено дозвіл на виконання.
Ці обговорення в 2015 році стосуються саме двох областей, які ми розглядаємо: абстрагування облікового запису та масштабування. У випадку масштабування ідея полягає в тому, щоб спробувати створити максимально абстрактну форму масштабування, яка виглядає як природне розширення діаграми вище. Контракти можуть викликати дані, які не зберігаються більшістю вузлів Ethereum, і протокол виявить це та вирішить виклик за допомогою деяких дуже загальних розширених обчислювальних функцій. З точки зору віртуальної машини, виклик перейде в якусь окрему підсистему, а потім чарівним чином поверне правильну відповідь через деякий час.
Ми коротко дослідили цю ідею, але швидко відмовилися від неї, оскільки були надто зосереджені на тому, щоб довести, що будь-яке масштабування блокчейну можливе. Хоча, як ми побачимо пізніше, поєднання вибірки доступності даних і ZK-EVM означає, що можливе майбутнє масштабування Ethereum насправді виглядає дуже близьким до цього бачення! З іншого боку, з абстракцією облікового запису ми з самого початку знали, що певна реалізація можлива, тому дослідження негайно почали намагатися зробити щось якомога ближче до чистої вихідної точки «транзакція — це лише дзвінок».
*Існує багато шаблонного коду між обробкою транзакції та здійсненням фактичного основного виклику EVM з адреси відправника, з додатковим шаблонним кодом. Як зменшити цей код якомога ближче до нуля? *
Одним із основних кодів тут є validate_transaction(state, tx), який відповідає за перевірку правильності nonce та підпису транзакції. Справжньою метою абстракції облікового запису з самого початку було дозволити користувачам замінити базову неінкрементну перевірку та перевірку ECDSA власною логікою перевірки, щоб користувачі могли легше використовувати такі функції, як соціальне відновлення та гаманці з кількома підписами. Отже, пошук способу реструктуризації apply_transaction у простий виклик EVM — це не просто завдання «зробити код чистим заради того, щоб зробити код чистим»; скоріше це стосується перенесення логіки до коду облікового запису користувача, надаючи користувачам гнучкість, яку вони потреба.
Однак наполягання на тому, щоб apply_transaction містило якомога менше фіксованої логіки, призвело до багатьох проблем. Ми можемо розглянути одну з найперших пропозицій абстракції облікового запису, EIP-86.
Якби EIP-86 було включено як є, це зменшило б складність EVM ціною значного збільшення складності інших частин стеку Ethereum, вимагаючи, по суті, того самого коду, який потрібно написати деінде, на додаток до введення цілого новий клас дивовижності.Наприклад, та сама транзакція з тим самим хеш-значенням може з’являтися кілька разів у ланцюжку, не кажучи вже про проблему кількох недійсних.
Відтоді абстракція облікового запису розвивалася поетапно. EIP-86 згодом став EIP-208, і згодом з’явився практичний EIP-2938.
Однак EIP-2938 не є мінімалістичним. Його вміст включає:
У спробі досягти абстракції облікового запису без залучення розробників ядра Ethereum (які були зосереджені на оптимізації клієнтів Ethereum і здійсненні злиття), EIP-2938 був остаточно перетворений на ERC-4337, який був повністю поза протоколом.
ERC-4337. Він повністю покладається на виклики EVM!
Оскільки це ERC, він не вимагає хардфорка і технічно існує «поза протоколом Ethereum». Отже... проблему вирішено? Виявляється, це не так. Поточна середньострокова дорожня карта для ERC-4337 фактично передбачає зрештою перехід великих частин ERC-4337 у низку функцій протоколу, що є корисним прикладом керівництва щодо того, чому слід розглянути цей шлях.
Пакет ERC-4337
Обговорюється кілька ключових причин можливого повторного включення ERC-4337 у протокол:
Варто зазначити, що в своїй поточній формі ERC-4337 значно дорожчий, ніж «базові» транзакції Ethereum: транзакція коштує 21 000 газу, тоді як ERC-4337 коштує близько 42 000 газу.
Теоретично повинна бути можливість налаштувати систему витрат на газ EVM, доки вартість у протоколі та вартість доступу до сховища поза протоколом не збігаються; немає жодних причин витрачати 9000 газу на передачу ETH при редагуванні інших типів сховища операції дешевші. Насправді два EIP, пов’язані з майбутньою трансформацією дерева Verkle, насправді намагаються зробити саме це. Але навіть якщо ми це зробимо, є очевидна причина, чому незалежно від того, наскільки ефективним стане EVM, функції інкапсульованого протоколу неминуче будуть набагато дешевшими, ніж код EVM: інкапсульованому коду не потрібно платити за попереднє завантаження.
Повнофункціональний гаманець ERC-4337 великий, а реалізація, скомпільована та розміщена в ланцюжку, займає близько 12 800 байт. Звичайно, ви можете розгорнути цей код один раз і використати DELEGATECALL, щоб дозволити кожному окремому гаманцю викликати його, але вам все одно потрібно буде отримати доступ до коду в кожному блоці, де він використовується. Згідно з EIP вартості газу дерева Verkle, 12 800 байтів утворять 413 блоків. Доступ до цих фрагментів вимагатиме сплати 2-кратної вартості гілки_свідка (загалом 3800 газу) і 413-кратної вартості фрагмента_свідка (загалом 82 600 газ). Це навіть не згадує саму точку входу ERC-4337, яка у версії 0.6.0 має 23 689 байтів у ланцюжку (приблизно 158 700 газів для завантаження відповідно до правил EIP дерева Verkle).
Це призводить до проблеми: вартість газу для фактичного доступу до цих кодів має певним чином амортизуватися між транзакціями. Поточний підхід, який використовує ERC-4337, не дуже хороший: перша транзакція в пакеті потребує одноразових витрат на зберігання/читання коду, що робить її набагато дорожчою, ніж інші транзакції. Внутрішньопротокольна інкапсуляція дозволить цим загальнодоступним бібліотекам стати частиною протоколу та вільно доступними для всіх.
Чого ми можемо навчитися з цього прикладу, і коли слід практикувати інкапсуляцію в більш загальному плані?
У цьому прикладі ми бачимо кілька різних обґрунтувань для інкапсуляції абстракцій облікових записів у протоколах.
Але важливо пам’ятати, що навіть абстракція облікового запису в протоколі інкапсуляції все ще є величезною «деінкапсуляцією» порівняно зі статус-кво. Сьогодні транзакції верхнього рівня Ethereum можуть бути ініційовані лише з зовнішніх облікових записів (EOA), які перевіряються за допомогою єдиного підпису еліптичної кривої secp 256k 1. Абстракція облікового запису усуває це та залишає користувачеві визначати умови перевірки. Тому в цій історії про абстракцію облікових записів ми також бачимо головну причину проти інкапсуляції: Гнучкість для задоволення потреб різних користувачів.
Давайте конкретизуємо історію далі, переглянувши кілька інших прикладів функцій, які нещодавно розглядалися для інкапсуляції. Зокрема, ми розглянемо: ZK-EVM, розділення пропонента та конструктора, приватні пули пам’яті, ставку ліквідності та нову попередню компіляцію.
Пакет ЗК-ЕВМ
Давайте звернемо увагу на іншу потенційну ціль інкапсуляції для протоколу Ethereum: ZK-EVM. Наразі у нас є велика кількість ZK-зведень, які мають написати досить подібний код, щоб перевірити виконання подібних блоків Ethereum у ZK-SNARK. Існує досить різноманітна екосистема незалежних реалізацій: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth та багато інших.
Нещодавня суперечка в області EVM ZK-rollup стосується того, як боротися з помилками, які можуть з’являтися в коді ZK. Наразі всі ці діючі системи мають певну форму механізму «ради безпеки», який контролює систему атестації у разі помилки. Минулого року я намагався створити стандартизовану структуру, яка заохочувала б проекти уточнювати, наскільки вони довіряють системі атестації та наскільки вони довіряють Раді Безпеки, і поступово зменшувати свої повноваження щодо цієї організації з часом.
*У середньостроковій перспективі зведення, ймовірно, покладатиметься на кілька систем сертифікації, причому Рада безпеки матиме повноваження лише в крайніх випадках, коли дві різні системи сертифікації розходяться. *
Однак є відчуття, що частина цієї роботи здається зайвою. У нас уже є базовий рівень Ethereum, він має EVM, і ми вже маємо робочий механізм для роботи з помилками в реалізації: якщо є помилка, клієнт буде оновлено, щоб її виправити, і ланцюжок продовжить функціонувати . З точки зору клієнта з помилками, схоже, що завершені блоки більше не підтверджуватимуться, але принаймні ми не побачимо, як користувачі втратять кошти. Подібним чином, якщо зведені просто хочуть зберегти еквівалентну роль EVM, тоді їм потрібно запровадити власне управління, щоб постійно змінювати свої внутрішні правила ZK-EVM відповідно до оновлень базового рівня Ethereum, що здається неправильним, оскільки в кінцевому підсумку вони створені поверх. самого базового рівня Ethereum, він знає, коли оновлювати та відповідно до яких нових правил.
Оскільки ці L2 ZK-EVM в основному використовують ту саму EVM, що й Ethereum, чи можемо ми якимось чином включити «перевірку виконання EVM у ZK» у функціональність протоколу та обробляти винятки, застосовуючи соціальний консенсус Ethereum, як-от помилки та оновлення, як ми вже робимо для саме виконання EVM базового рівня?
Це важлива і складна тема.
Одна з можливих тем для дискусії щодо доступності даних у рідному ZK-EVM — це збереження стану. ZK-EVM були б набагато ефективнішими для обробки даних, якби їм не потрібно було передавати дані «очевидців». Тобто, якщо певний фрагмент даних уже був прочитаний або записаний у якомусь попередньому блоці, ми можемо просто припустити, що перевіряльник має до нього доступ і не повинен знову робити його доступним. Йдеться не лише про те, щоб не перезавантажувати сховище та код; виявляється, що якщо зведення стискає дані правильно, стиснення зі збереженням стану може зберегти до 3 разів більше даних порівняно зі стисненням без стану.
Це означає, що для попередньої компіляції ZK-EVM у нас є два варіанти:
**1.**Попередня компіляція вимагає, щоб усі дані були доступні в одному блоці. Це означає, що перевірка може бути без стану, але це також означає, що використання цього попередньо скомпільованого ZK-зведення набагато дорожче, ніж використання спеціального зведення коду.
**2.**Попередня компіляція дозволяє покажчикам вказувати на дані, використані або згенеровані попередніми виконаннями. Це робить ZK-rollup близьким до оптимального, але він більш складний і вводить новий стан, який має зберігатися прувером.
Чого ми можемо навчитися з цього? Існує вагома причина інкапсулювати верифікацію ZK-EVM якимось чином: зведення вже створює власну спеціальну версію, і Ethereum готовий запровадити EVM на L1 з урахуванням його кількох реалізацій і соціального консенсусу поза ланцюгом. неправильно, але L2, виконуючи ту саму роботу, мав би впровадити складний гаджет із залученням Ради безпеки. Але з іншого боку, є велика проблема в деталях: існують різні версії ZK-EVM, і вони мають різні витрати та переваги. Різниця між станом і без стану лише дряпає поверхню; спроби підтримувати «майже-EVM» спеціальний код, який був перевірений іншими системами, можуть відкрити більший простір для проектування. Тому упаковка ZK-EVM несе надію і виклик.
Розділення пропонента інкапсуляції та розробника (ePBS)
Зростання MEV робить виробництво блоків масштабною економічною діяльністю, за допомогою досвідчених акторів, здатних створювати блоки, які генерують більший дохід, ніж алгоритм за замовчуванням, який просто спостерігає за масивом транзакцій і містить їх. Наразі спільнота Ethereum намагалася вирішити цю проблему, використовуючи позапротокольні схеми поділу пропонента та розробника, такі як MEV-Boost, що дозволяє звичайним валідаторам («пропонаторам») надсилати блоки до Створення передається спеціалізованим виконавцям («Builders»). ").
Однак MEV-Boost робить припущення про довіру до нового класу акторів, які називаються ретрансляторами. За останні два роки було багато пропозицій створити «пакетований PBS». Які переваги цього? У цьому випадку відповідь дуже проста: PBS, побудований безпосередньо з використанням функцій протоколу, є потужнішим (у сенсі слабкішої довіри), ніж PBS, створений без їх використання. Це схоже на випадок інкапсуляції цінових оракулів у протоколі – хоча в цьому випадку є серйозні заперечення.
Інкапсулювати приватний пул пам'яті
Коли користувач надсилає транзакцію, вона одразу стає загальнодоступною та видимою для всіх, навіть до того, як її включено в мережу. Це робить користувачів багатьох додатків уразливими до економічних атак, як-от атак.
Нещодавно з’явилася низка проектів, присвячених створенню «приватних пам’ятних фондів» (або «крипто-мемпулів»), які шифрують транзакції користувачів, доки вони незворотно не будуть прийняті в блок.
Проблема, однак, полягає в тому, що така схема вимагає особливого типу шифрування: щоб запобігти переповненню системою користувачами та першим її дешифруванням, шифрування має бути автоматично розшифроване після фактичного незворотного прийняття транзакції.
Існують різні техніки з різними компромісами для реалізації цієї форми шифрування. Джон Шарбоно якось добре описав це:
На жаль, кожен метод шифрування має різні недоліки. У той час як для кожного рішення є сегмент користувачів, які бажають йому довіряти, жодне рішення не є достатньо довіреним, щоб прийняти його Рівнем 1. **Тож, принаймні до удосконалення відкладеного шифрування або до якогось іншого технологічного прориву, інкапсуляція функції запобігання випередженню торгівлі на рівні 1 здається складною пропозицією, навіть якщо це досить цінна функція, яку багато програм вирішують. з'явився план.
Інкапсулюйте ставку ліквідності
Загальною потребою користувачів Ethereum DeFi є можливість одночасно використовувати свій ETH для стекінгу та як заставу в інших програмах. Ще один поширений запит — просто для зручності: користувачі хочуть мати можливість робити ставки (і захищати онлайн-ключі ставки) без складнощів, пов’язаних із запуском вузла та його постійною підтримкою онлайн.
Найпростішим «інтерфейсом» стекінгу, який задовольняє обидві ці потреби, є лише токен ERC 20: конвертуйте свій ETH у «стейк ETH», утримуйте його, а потім конвертуйте назад. Фактично, постачальники ставки ліквідності, такі як Lido та Rocket Pool, уже роблять це. Проте існують деякі природні механізми централізації, які діють у стейкінгу ліквідності: люди, природно, переходитимуть на стейкінг найбільшої версії ETH, оскільки вона є найбільш знайомою та ліквідною.
Кожна версія розставленого ETH повинна мати певний механізм для визначення того, хто може стати базовим оператором вузла. Воно не може бути необмеженим, оскільки тоді зловмисники приєднаються та використовуватимуть кошти користувачів для розширення своїх атак. Наразі двома найкращими є Lido та Rocket Pool, причому перший має операторів вузлів DAO у білому списку, а другий дозволяє будь-кому запускати вузол із депозитом у розмірі 8 ETH. Ці два методи мають різні ризики: метод Rocket Pool дозволяє зловмиснику здійснити 51% атаку на мережу та змушує користувачів оплачувати більшу частину витрат; що стосується методу DAO, якщо певний токен домінує, це призведе до єдиний, потенційно скомпрометований гаджет керування контролює велику частину всіх валідаторів Ethereum. До честі, такі протоколи, як Lido, реалізували гарантії, але одного рівня захисту може бути недостатньо.
У короткостроковій перспективі одним із варіантів є заохочення учасників екосистеми використовувати різноманітний набір постачальників ставки ліквідності, щоб зменшити ймовірність того, що домінуючий гравець створює системний ризик. Однак у довгостроковій перспективі це нестабільний баланс, і надмірне покладання на моральний тиск для вирішення проблем є небезпечним. Виникає природне запитання: **Чи є сенс інкапсулювати деякі функції в протоколі, щоб зробити ставку ліквідності менш централізованою? **
Ключове питання тут: яка функціональність у протоколі? Однією з проблем простого створення взаємозамінного токена «стейкінг ETH» у протоколі є те, що він або матиме інкапсульоване управління для всього Ethereum, щоб вибирати, хто має керувати вузлами, або буде відкритим, але це перетворить його на зловмисника. Інструменти.
Цікавою ідеєю є стаття Данкрада Фейста про максимізацію ставки ліквідності. По-перше, давайте спробуємо: якщо Ethereum зазнає атаки 51%, лише 5% атакованого ETH може бути скорочено. Це розумний компроміс; оскільки зараз на ставку понад 26 мільйонів ETH, вартість атаки на третину цього (~8 мільйонів ETH) є надмірною, особливо враховуючи, скільки атак «поза моделью» можна здійснити за один раз менша вартість. Фактично, подібні компроміси були досліджені в пропозиції Суперкомітету запровадити однослотовий фінал.
Якщо ми приймемо, що лише 5% атаки ETH скорочується, то більше 90% ставок ETH не постраждають від скорочення, тому їх можна буде використовувати як взаємозамінні рідинні токени стекінгу в протоколі, а потім використовувати в інших програмах.
Цей шлях цікавий. Але все одно залишається питання: що саме інкапсульовано? **Rocket Pool працює дуже подібно: кожен оператор вузла надає частину коштів, а учасники ліквідності забезпечують решту. Ми можемо просто налаштувати деякі константи, щоб обмежити максимальний штраф до 2 ETH, і існуючий rETH Rocket Pool стане безризиковим.
За допомогою простих коригувань протоколу ми також можемо робити інші розумні речі. Наприклад, припустімо, що нам потрібна система з двома «рівнями» ставок: оператори вузлів (високі вимоги до застави) і вкладники (без мінімальних вимог до застави, можуть приєднатися та залишити будь-коли), але ми все одно хочемо надати випадкову вибірку повноваження комітету вкладників запобігати централізації операторів вузлів, наприклад, рекомендувати список транзакцій, які повинні бути включені (з міркувань опору цензурі), контролювати вибір форка під час витоку неактивності або вимагати підписи на блоках. Це може бути досягнуто таким чином, що, по суті, виходить за межі протоколу, налаштувавши протокол, щоб вимагати від кожного валідатора надавати (i) звичайний ключ ставки, і (ii) адресу ETH, яка може використовуватися в кожному слоті, викликається для виведення ключ вторинної застави. Протокол надавав би обидва ключі, але механізм вибору другого ключа в кожному слоті можна було б залишити протоколу пулу розміщення. Можливо, все-таки краще інкапсулювати деякі функції безпосередньо, але варто зазначити, що такий простір дизайну «включити деякі речі, а інші залишити користувачеві» існує.
Інкапсулюйте більше попередньої компіляції
Попередньо скомпільовані контракти (або «попередньо скомпільовані контракти») — це контракти Ethereum, які реалізують складні криптографічні операції з логікою, реалізованою в коді клієнта, а не в коді смарт-контракту EVM. Попереднє кодування є компромісом, прийнятим на початку розробки Ethereum: оскільки накладні витрати на віртуальну машину занадто великі для дуже складного та вузькоспеціалізованого коду, ми можемо реалізувати деякі важливі програми у рідному коді. Цінуйте критичні операції, щоб зробити їх швидшими. Сьогодні це в основному включає деякі специфічні хеш-функції та операції з еліптичною кривою.
Наразі існує поштовх для додавання попередньої компіляції для secp 256 r 1, дещо іншої еліптичної кривої, ніж secp 256 k 1, яка використовується для базових облікових записів ethereum, яка широко використовується, оскільки добре підтримується надійними апаратними модулями. Використовуйте її для підвищення безпеки гаманця. В останні роки спільнота також наполягала на додаванні попередньої компіляції для BLS-12-377, BW 6-761, узагальненого парування та інших функцій.
Контраргументом до цих закликів до більшої кількості прекомпіляторів є те, що багато попередніх компіляторів, доданих раніше (таких як RIPEMD і BLAKE), зрештою використовувалися набагато рідше, ніж очікувалося, і ми повинні навчитися з цього. Замість того, щоб додавати більше попередньої компіляції для конкретних операцій, ми, мабуть, повинні зосередитися на більш м’якому підході, заснованому на таких ідеях, як EVM-MAX і пропозиція SIMD із режимом Hibernate-But-Always-Resumable, що дозволить реалізаціям EVM працювати з меншими витратами. Вартість виконання широкий спектр класів коду. Можливо, навіть існуючу маловикористовувану попередню компіляцію можна було б видалити та замінити (неминуче менш ефективною) реалізацією коду EVM тих самих функцій. Тим не менш, все ще можливо, що існують певні криптографічні операції, які є достатньо цінними, щоб їх можна було прискорити, тому має сенс додати їх як попередньо скомпільовані.
Чого ми навчилися з усього цього?
Бажання інкапсулювати якомога менше є зрозумілим і добрим; воно походить від філософської традиції Unix щодо створення мінімалістичного програмного забезпечення, яке може легко адаптуватися до різних потреб користувачів і уникнути прокляття роздуття програмного забезпечення. Однак блокчейн — це не операційна система персонального комп’ютера, а соціальна система. Це означає, що є сенс інкапсулювати певні функції в протоколі.
У багатьох випадках ці інші приклади схожі на те, що ми бачили в абстракції облікового запису. Але ми також отримали деякі нові уроки:
Часто мінімальний і простий базовий протокол висуває складність у певну екосистему за межами протоколу. З точки зору філософії Unix, це добре. Однак іноді існує ризик того, що позапротокольна екосистема стане централізованою, зазвичай (але не тільки) через високі постійні витрати. Інкапсуляція іноді може зменшити де-факто централізацію.
Це тема попередньої статті «Не перевантажуйте Ethereum Consensus»: якщо інкапсуляція певної функції послаблює модель довіри та робить Ethereum у цілому більш «суб’єктивним», це послаблює Ethereum. У цих випадках краще мати певну функціональність як механізм поверх Ethereum, а не намагатися перенести її в сам Ethereum. Найкращим прикладом тут є зашифровані пули пам’яті, які може бути трохи складно інкапсулювати, принаймні до тих пір, поки не покращиться шифрування затримки.
Складність протоколу – це системний ризик, який збільшується через додавання занадто великої кількості функцій до протоколу. Найкращим прикладом є попередня компіляція.
Функція, яку багато людей вважають важливою і яку використовуватимуть багато користувачів, на практиці, ймовірно, не використовується дуже часто.
Крім того, ставка ліквідності, ZK-EVM і попередньо скомпільовані приклади показують можливість середнього шляху: мінімальне життєздатне закріплення. Протокол не потребує інкапсуляції всієї функціональності, але може містити конкретні частини, які вирішують ключові проблеми, що робить функціональність легкою для реалізації, не надто параноїдальною або занадто вузькою. Приклади:
Ми можемо розширити попередню діаграму наступним чином:
Іноді має сенс щось інкапсулювати, і видалення рідко використовуваних прекомпіляторів є одним із прикладів. Абстракція облікового запису в цілому, як згадувалося раніше, також є важливою формою деінкапсуляції. Якщо ми хочемо підтримувати зворотну сумісність для існуючих користувачів, механізм насправді може бути напрочуд схожим на той, який дезгортав попередню компіляцію: одна з пропозицій — EIP-5003, що дозволить EOA перетворювати свої облікові записи на те саме ( або краще) функціональний договір.
Які функції слід включити в протокол, а які слід залишити іншим рівням екосистеми, є складним компромісом. Очікується, що цей компроміс з часом покращуватиметься, оскільки наше розуміння потреб користувачів і доступний набір ідей і технологій продовжуватимуть покращуватися.