На початку історії того, що тоді було відомо як «Ethereum 2.0», існувало сильне бажання створити чистий, простий і естетично привабливий протокол, який намагався б будувати самостійно з якомога меншими витратами і залишав майже всю цю роботу користувачам. В ідеалі протокол — це просто віртуальна машина, а перевірка фрагмента — це просто виклик віртуальної машини.
"Функція переходу стану" (функція, яка обробляє фрагмент) буде лише одним викликом віртуальної машини, а вся інша логіка відбуватиметься через контракт: деякі контракти системного рівня, але в основному контракти, надані користувачем. Дуже хороша особливість цієї моделі полягає в тому, що навіть цілий хардфорк можна описати як одну транзакцію для контракту блокового процесора, який буде схвалений офчейн або ончейн управлінням, а потім виконаний з підвищеними привілеями.
Ці дискусії у 2015 році стосуються, зокрема, двох сфер, які ми розглядали: абстракції облікових записів та масштабування. У випадку масштабування ідея полягає в тому, щоб спробувати створити максимальну абстракційну форму масштабування, яка відчувається як природне продовження наведеної вище діаграми. Контракти можуть викликати дані, які не зберігаються більшістю вузлів Ethereum, і протокол виявить це та вирішить виклик за допомогою якоїсь дуже загальної розширеної обчислювальної функції. З точки зору віртуальної машини, дзвінок потрапляє в якусь окрему підсистему і магічним чином повертає правильну відповідь через деякий час.
Ми коротко досліджували цю лінію мислення, але швидко здалися, тому що були занадто зосереджені на перевірці того, що будь-який тип масштабування блокчейну можливий. Хоча ми побачимо пізніше, поєднання вибірки доступності даних і ZK-EVM означає, що можливе майбутнє масштабування Ethereum насправді дуже близьке до цього бачення! З іншого боку, для абстракції аккаунта ми з самого початку знали, що можлива якась реалізація, тому дослідження відразу почали намагатися максимально наблизити щось до чистої відправної точки «трейдинг – це всього лише дзвінок» в реальність.
Між обробкою транзакції та здійсненням фактичного базового виклику EVM з адреси відправника є багато шаблонного коду, а після цього ще більше шаблонного коду. Як звести цей код якомога ближче до нуля?
Одним з основних кодів тут є validate_transaction(state, tx), який відповідає за перевірку того, що транзакція має правильний nonce і signature. З самого початку практична мета абстракції облікового запису полягала в тому, щоб дозволити користувачам замінити базову неінкрементну перевірку та перевірку ECDSA власною логікою верифікації, щоб користувачам було легше використовувати такі функції, як соціальне відновлення та гаманці з мультипідписом. Таким чином, пошук способу реархітектури застосувати_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, він не вимагає хардфорку і технічно існує «поза протоколом 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 до тих пір, поки вартість узгодження та вартість позапротокольного доступу до сховища не збігатимуться; Коли інші види операцій з редагування сховищ дешевші, немає причин переводити ETH за ціною 9000 газу. Фактично, два EIP, пов'язані з майбутнім перетворенням дерева Веркла, насправді намагаються зробити саме це. Але навіть якщо ми це зробимо, є очевидна причина, чому функціональність інкапсульованого протоколу неминуче буде набагато дешевшою, ніж EVM-код, незалежно від того, наскільки ефективним стане EVM: інкапсульованому коду не потрібно платити газ за попереднє завантаження.
Повнофункціональний гаманець ERC-4337 великий, а реалізація, яка компілює та розміщує його в ланцюжку, займає близько 12 800 байт. Звичайно, ви можете розгорнути цей код один раз і використовувати DELEGATECALL, щоб дозволити кожному окремому гаманцю викликати його, але вам все одно потрібно отримати доступ до коду в кожному блоці, який його використовує. Згідно з деревом Веркла, вартість газу EIP, 12 800 байт становитимуть 413 фрагментів, і доступ до цих фрагментів вимагатиме сплати в 2 рази більше гілки свідка_cost (загалом 3 800 газу) і 413 разів більше шматка свідка_cost (загалом 82 600 газу). І це вже не кажучи вже про саму точку входу ERC-4337, яка у версії 0.6.0 має 23 689 байт у ланцюжку (близько 158 700 газу для завантаження за правилами EIP дерева Веркла).
Звідси випливає проблема: вартість фактичного доступу до цих кодів повинна якимось чином амортизуватися по всій транзакції. Поточний підхід, який використовується ERC-4337, не дуже хороший: перша транзакція в пакеті споживає одноразове сховище/вартість зчитування коду, що робить її набагато дорожчою за інші транзакції. Інкапсуляція в протоколі дозволить цим публічним спільним бібліотекам бути частиною протоколу та вільно доступними для всіх.
Чого ми можемо навчитися з цього прикладу і коли упаковка стане більш поширеною? **
У цьому прикладі ми бачимо деякі різні обґрунтування для інкапсуляції аспекту абстракції облікового запису в протоколі.
Ринкові підходи, які «доводять складність до краю», швидше за все, зазнають невдачі, коли постійні витрати високі. Насправді, дорожня карта абстракції довгострокового облікового запису виглядає так, ніби кожен блок має багато постійних витрат. 244, 100 газ для завантаження стандартизованих кодів гаманців - це одне; Але агрегація може додати сотні тисяч газу до валідації ZK-SNARK, а також вартість перевірки доказу ланцюга в мережі. Немає способу стягувати з користувачів плату за ці витрати, не вносячи багато ринкової неефективності, і переклад деяких із цих функцій у функції протоколу, до яких кожен може отримати безкоштовний доступ, добре вирішує цю проблему.
Реакція всієї спільноти на помилки коду. Якщо деякі фрагменти коду використовуються всіма користувачами або дуже широким колом користувачів, для блокчейн-спільноти зазвичай має сенс взяти на себе відповідальність за хардфорк для виправлення будь-яких помилок, що виникають. ERC-4337 вводить велику кількість глобально поширеного коду, і виправлення помилок у коді за допомогою хардфорку, безсумнівно, є більш розумним у довгостроковій перспективі, ніж змушувати користувачів втрачати багато ETH.
Іноді сильнішої форми можна досягти, безпосередньо використовуючи функціональність протоколу. Ключовим прикладом тут є функція захисту від цензури в протоколі, така як список включень: список включень у протоколі може гарантувати стійкість до цензури краще, ніж метод поза протоколом, і для того, щоб операції на рівні користувача дійсно виграли від списку включення в протоколі, одна операція на рівні користувача повинна бути «читабельною» для протоколу. Іншим менш відомим прикладом є дизайн Ethereum proof-of-stake 2017 року, який абстрагував ключовий рахунок ставки, від якого відмовилися на користь інкапсуляції BLS, оскільки BLS підтримує механізм «агрегації», який повинен бути реалізований на рівні протоколу та мережі, що може зробити обробку великої кількості підписів більш ефективною.
Але важливо пам'ятати, що навіть інкапсуляція абстракції облікового запису в протоколі все ще є величезною «деінкапсуляцією» порівняно з поточною ситуацією. Сьогодні транзакції Ethereum найвищого рівня можна ініціювати лише із зовнішніх облікових записів (EOA), які перевірені за допомогою однієї еліптичної кривої secp 256k1. Абстракція облікового запису усуває це і залишає критерії валідації на розсуд користувача. Отже, у цій історії про абстракцію облікового запису ми також бачимо найбільший аргумент проти інкапсуляції: гнучкість для задоволення потреб різних користувачів.
Давайте конкретизуємо цю історію далі, розглянувши кілька інших прикладів функцій, які нещодавно вважалися інкапсульованими. Особливу увагу ми приділимо: ZK-EVM, поділу ініціатора-будівельника, приватним мемпулам, стейкінгу ліквідності та новій прекомпіляції.
Пакет 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 є statefulness. Якби ZK-EVM не потрібно було передавати дані «свідків», їх ефективність даних була б набагато вищою. Тобто, якщо певний фрагмент даних вже був прочитаний або записаний в якомусь попередньому блоці, ми можемо просто припустити, що виконавець має до них доступ і не зобов'язаний робити його доступним знову. Справа не тільки в тому, щоб не перезавантажувати сховище та код; Виявляється, стиснення зі збереженням стану може зберегти до 3 разів більше даних порівняно зі стисненням без стану, якщо одне зведення стискає дані правильно.
Це означає, що для попередньої компіляції ZK-EVM у нас є два варіанти:
Попередня компіляція вимагає, щоб усі дані були доступні в одному фрагменті. Це означає, що prover може бути без стану, але це також означає, що використання цього попередньо скомпільованого ZK-rollup набагато дорожче, ніж використання rollup з користувацьким кодом.
Попередня компіляція дозволяє покажчику вказувати на раніше виконані, використані або згенеровані дані. Це робить ZK-rollup майже оптимальним, але він складніший і вводить новий стан, який повинен зберігатися proproof.
Чого ми можемо навчитися з цього? Є вагома причина якимось чином інкапсулювати перевірку ZK-EVM: rollup вже створює власну кастомну версію, і Ethereum готовий зважити свої численні реалізації та соціальний консенсус поза мережею щодо L1 для виконання EVM, що здається неправильним, але L2, який виконує ту саму роботу, повинен впроваджувати складні гаджети за участю Ради безпеки. Але з іншого боку, є велика проблема в деталях: існують різні версії ZK-EVM, які відрізняються вартістю та користю. Відмінність між stateful і state less лише дряпає поверхню; Спроба підтримати "майже-EVM", користувацькі коди, які були перевірені іншими системами, може відкрити більше простору для дизайну. Таким чином, інкапсуляція ZK-EVM пов'язана як з перспективами, так і з труднощами.
Розділення оболонки та конструктора (ePBS)
Розвиток MEV перетворив виробництво блоків на великомасштабну економічну діяльність, учасники якої можуть створювати блоки, які приносять більше доходу, ніж алгоритм за замовчуванням, який просто спостерігає за мемпулом транзакцій і містить їх. До сих пір спільнота Ethereum намагалася вирішити цю проблему, використовуючи позапротокольну схему поділу пропозицій-будівельників, таку як MEV-Boost, яка дозволяє звичайним валідаторам («пропонувачам») передавати створення блоків на аутсорсинг спеціалізованим учасникам («будівельникам»).
Однак MEV-Boost робить припущення про довіру до нового класу учасників, які називаються ретрансляторами. За останні два роки з'явилося багато пропозицій щодо створення «інкапсульованої ПБС». Які переваги від цього? У цьому випадку відповідь проста: PBS, побудовані безпосередньо з функціями протоколу, є більш потужними (в сенсі більш слабких припущень про довіру), ніж PBS, побудовані без них. Це схоже на ситуацію з ціновими оракулами в рамках протоколу інкапсуляції, хоча в цьому випадку також існує сильна опозиція.
Інкапсуляція приватного пулу пам'яті
Коли користувач надсилає транзакцію, вона одразу стає загальнодоступною та видимою для всіх, навіть до того, як вона буде включена в ланцюжок. Це робить користувачів багатьох додатків вразливими до економічних атак, таких як превентивні транзакції.
Останнім часом з'явився ряд проектів, присвячених створенню «приватних мемпулів» (або «зашифрованих мемпулів»), які шифрують транзакції користувачів до тих пір, поки вони не будуть безповоротно прийняті в блок.
Проблема, однак, полягає в тому, що такі схеми вимагають особливого виду шифрування: для того, щоб користувачі не переповнили систему і не розшифрували її першим, шифрування має бути автоматично розшифроване після того, як транзакція дійсно була безповоротно прийнята.
Для досягнення цієї форми шифрування існують різні методи компромісу. Джон Шарбонно якось добре висловився:
Шифруйте централізованих операторів, таких як Flashbots Protect.
шифрування timelock, яке може бути розшифроване будь-ким після певного послідовного кроку обчислення і не може бути розпаралелене;
Порогове шифрування, довіра до розшифровки даних чесного комітету більшості. Конкретні рекомендації наведено в розділі Концепція замкнутого маячка.
Надійне обладнання, наприклад SGX.
На жаль, кожне шифрування має різні слабкі місця. Хоча для кожного рішення є підмножина користувачів, які готові йому довіряти, жодне з рішень не є достатньо надійним, щоб воно було фактично прийнято рівнем 1. Таким чином, принаймні до тих пір, поки шифрування затримки не буде вдосконалено або якийсь інший технологічний прорив, інкапсуляція антипросунутих торгових функцій на рівні 1 здається складною пропозицією, навіть якщо це досить цінна функція, яка з'явилася в багатьох прикладних рішеннях.
Стейкінг інкапсульованої ліквідності
Загальною потребою для користувачів Ethereum DeFi є можливість використовувати свої ETH одночасно для стейкінгу та як заставу в інших програмах. Ще одна поширена потреба полягає просто в зручності: користувачі хочуть мати можливість здійснювати стейкінг (і захищати ключі онлайн-стейкінгу) без складнощів із запуском вузла та постійним збереженням його в мережі.
Поки що найпростішим «інтерфейсом» стейкінгу, який задовольняє обидві ці потреби, є лише токен ERC 20: конвертуйте свої ETH у «стейкінг ETH», утримуйте їх і конвертуйте назад. Фактично, провайдери стейкінгу ліквідності, такі як Lido та Rocket Pool, вже почали це робити. Однак стейкінг ліквідності має деякі природні механізми централізації: люди, природно, переходять у найбільшу версію стейкінгу ETH, оскільки вона є найбільш звичною та ліквідною.
Кожна версія стейкінгу ETH вимагає певного механізму для визначення того, хто може бути оператором базового вузла. Він не може бути необмеженим, оскільки тоді зловмисники приєднаються та посилять атаку коштами користувача. Наразі двома лідерами є Lido, який має оператора білого списку вузлів DAO, і Rocket Pool, який дозволяє будь-кому запускати вузол із внесеними 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 R1, дещо іншої еліптичної кривої, ніж secp 256 K1 для базових облікових записів Ethereum, оскільки вона добре підтримується надійними апаратними модулями, тому її широке використання може підвищити безпеку гаманця. Останніми роками спільнота також наполягала на додаванні попередніх компіляцій для BLS-12-377, BW 6-761, узагальненого сполучення та інших функцій.
Контраргументом на ці запити на отримання більшої кількості попередньо скомпільованих файлів є те, що багато з попередніх компіляцій, доданих раніше (наприклад, RIPEMD і BLAKE), в кінцевому підсумку використовують набагато менше, ніж очікувалося, і ми повинні вчитися на них. Замість того, щоб додавати більше попередньої компіляції для конкретних операцій, можливо, нам слід зосередитися на більш м'якому підході, заснованому на таких ідеях, як EVM-MAX і сплячих, але завжди відновлюваних пропозиціях SIMD, які дозволять реалізаціям EVM виконувати широкий спектр класів коду з меншими витратами. Можливо, навіть існуючу рідко використовувану попередню компіляцію можна було б видалити і замінити (неминуче менш ефективною) реалізацією EVM-коду тієї ж функції. Тим не менш, все ще можливо, що існують певні криптографічні операції, які є досить цінними, щоб прискорити, тому має сенс додавати їх як попередньо скомпільовані.
Чого ми навчилися з усього цього?
Прагнення охопити якомога менше – це зрозуміло і добре; Він походить від філософської традиції Unix створення мінімалістичного програмного забезпечення, яке можна легко адаптувати до різних потреб користувачів і уникнути прокляття роздуття програмного забезпечення. Однак блокчейн – це не персональна обчислювальна операційна система, а соціальна система. Це означає, що є сенс інкапсулювати певний функціонал у протоколі.
У багатьох випадках ці інші приклади схожі на те, що ми бачимо в абстракції розповіді. Але ми також засвоїли кілька нових уроків:
Інкапсуляція може допомогти уникнути ризику централізації в інших місцях стека:
Часто мінімізація та простота базового протоколу виводить складність за межі деяких протоколів екосистеми. З філософської точки зору Unix це добре. Однак іноді існує ризик того, що позапротокольні екосистеми будуть централізовані, як правило (але не тільки) через високі постійні витрати. Інкапсуляція іноді може зменшити фактичну централізацію.
Інкапсуляція занадто великого обсягу контенту може надмірно збільшити навантаження на довіру та управління протоколом:
Це тема попередньої статті на тему «Не перевантажуйте консенсус Ethereum»: якщо інкапсуляція певної функції послаблює модель довіри і робить Ethereum в цілому більш «суб'єктивним», це послаблює довірчий нейтралітет Ethereum. У цих випадках краще представити конкретну функцію як механізм поверх Ethereum, ніж намагатися впровадити її в сам Ethereum. Тут найкращим прикладом є зашифровані пули пам'яті, і їх може бути дещо складно інкапсулювати, принаймні до тих пір, поки шифрування затримки не покращиться.
Занадто велика інкапсуляція може надмірно ускладнити протокол:
Складність протоколу – це системний ризик, який можна збільшити, додавши до протоколу занадто багато функцій. Прекомпіляція – найкращий приклад.
У довгостроковій перспективі інкапсуляція функціональності може мати негативні наслідки, оскільки потреби користувачів непередбачувані:
Функція, яку багато хто вважає важливою і буде використовуватися багатьма користувачами, швидше за все, не використовується регулярно на практиці.
Крім того, стейкінг ліквідності, ZK-EVM та попередньо скомпільовані кейси показують можливість серединного шляху: мінімального життєздатного закріплення. Протоколи не обов'язково повинні інкапсулювати всю функцію, але можуть містити конкретні частини, які вирішують ключові проблеми, що робить функцію легкою для реалізації, не будучи занадто параноїдальною або занадто вузькою. Прикладами цього є:
Замість того, щоб інкапсулювати повну систему застави ліквідності, краще змінити правила штрафів за стейкінг, щоб зробити заставу ліквідності без довіри більш здійсненною;
Замість того, щоб інкапсулювати більше прекомпіляторів, інкапсулюйте EVM-MAX та/або SIMD, щоб полегшити ефективну реалізацію для ширшого спектру операційних категорій;
Верифікацію EVM можна просто інкапсулювати, а не інкапсулювати всю концепцію зведення.
Ми можемо розгорнути попередню діаграму наступним чином:
Іноді є сенс щось обернути, і прикладом є видалення рідко використовуваної попередньої компіляції. Абстракція рахунку в цілому, як згадувалося раніше, також є важливою формою деінкапсуляції. Якщо ми хочемо підтримати зворотну сумісність для існуючих користувачів, механізм насправді може бути разюче схожим на той, який деінкапсулює попередньо скомпільований: однією з пропозицій є EIP-5003, який дозволить EOA конвертувати свої облікові записи в контракти з тією ж (або кращою) функціональністю.
Які функції слід впровадити в протокол, а які залишити іншим рівням екосистеми, є складним компромісом. Очікується, що з часом цей компроміс продовжуватиме вдосконалюватися, оскільки наше розуміння потреб користувачів і доступних ідей і технологічних пакетів продовжує вдосконалюватися.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Віталік Бутерін: Чи повинен Ethereum включати більше функцій?
Рання філософія протокольного мінімалізму
На початку історії того, що тоді було відомо як «Ethereum 2.0», існувало сильне бажання створити чистий, простий і естетично привабливий протокол, який намагався б будувати самостійно з якомога меншими витратами і залишав майже всю цю роботу користувачам. В ідеалі протокол — це просто віртуальна машина, а перевірка фрагмента — це просто виклик віртуальної машини.
"Функція переходу стану" (функція, яка обробляє фрагмент) буде лише одним викликом віртуальної машини, а вся інша логіка відбуватиметься через контракт: деякі контракти системного рівня, але в основному контракти, надані користувачем. Дуже хороша особливість цієї моделі полягає в тому, що навіть цілий хардфорк можна описати як одну транзакцію для контракту блокового процесора, який буде схвалений офчейн або ончейн управлінням, а потім виконаний з підвищеними привілеями.
Ці дискусії у 2015 році стосуються, зокрема, двох сфер, які ми розглядали: абстракції облікових записів та масштабування. У випадку масштабування ідея полягає в тому, щоб спробувати створити максимальну абстракційну форму масштабування, яка відчувається як природне продовження наведеної вище діаграми. Контракти можуть викликати дані, які не зберігаються більшістю вузлів Ethereum, і протокол виявить це та вирішить виклик за допомогою якоїсь дуже загальної розширеної обчислювальної функції. З точки зору віртуальної машини, дзвінок потрапляє в якусь окрему підсистему і магічним чином повертає правильну відповідь через деякий час.
Ми коротко досліджували цю лінію мислення, але швидко здалися, тому що були занадто зосереджені на перевірці того, що будь-який тип масштабування блокчейну можливий. Хоча ми побачимо пізніше, поєднання вибірки доступності даних і ZK-EVM означає, що можливе майбутнє масштабування Ethereum насправді дуже близьке до цього бачення! З іншого боку, для абстракції аккаунта ми з самого початку знали, що можлива якась реалізація, тому дослідження відразу почали намагатися максимально наблизити щось до чистої відправної точки «трейдинг – це всього лише дзвінок» в реальність.
Між обробкою транзакції та здійсненням фактичного базового виклику EVM з адреси відправника є багато шаблонного коду, а після цього ще більше шаблонного коду. Як звести цей код якомога ближче до нуля?
Одним з основних кодів тут є validate_transaction(state, tx), який відповідає за перевірку того, що транзакція має правильний nonce і signature. З самого початку практична мета абстракції облікового запису полягала в тому, щоб дозволити користувачам замінити базову неінкрементну перевірку та перевірку ECDSA власною логікою верифікації, щоб користувачам було легше використовувати такі функції, як соціальне відновлення та гаманці з мультипідписом. Таким чином, пошук способу реархітектури застосувати_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, він не вимагає хардфорку і технічно існує «поза протоколом 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 до тих пір, поки вартість узгодження та вартість позапротокольного доступу до сховища не збігатимуться; Коли інші види операцій з редагування сховищ дешевші, немає причин переводити ETH за ціною 9000 газу. Фактично, два EIP, пов'язані з майбутнім перетворенням дерева Веркла, насправді намагаються зробити саме це. Але навіть якщо ми це зробимо, є очевидна причина, чому функціональність інкапсульованого протоколу неминуче буде набагато дешевшою, ніж EVM-код, незалежно від того, наскільки ефективним стане EVM: інкапсульованому коду не потрібно платити газ за попереднє завантаження.
Повнофункціональний гаманець ERC-4337 великий, а реалізація, яка компілює та розміщує його в ланцюжку, займає близько 12 800 байт. Звичайно, ви можете розгорнути цей код один раз і використовувати DELEGATECALL, щоб дозволити кожному окремому гаманцю викликати його, але вам все одно потрібно отримати доступ до коду в кожному блоці, який його використовує. Згідно з деревом Веркла, вартість газу EIP, 12 800 байт становитимуть 413 фрагментів, і доступ до цих фрагментів вимагатиме сплати в 2 рази більше гілки свідка_cost (загалом 3 800 газу) і 413 разів більше шматка свідка_cost (загалом 82 600 газу). І це вже не кажучи вже про саму точку входу ERC-4337, яка у версії 0.6.0 має 23 689 байт у ланцюжку (близько 158 700 газу для завантаження за правилами EIP дерева Веркла).
Звідси випливає проблема: вартість фактичного доступу до цих кодів повинна якимось чином амортизуватися по всій транзакції. Поточний підхід, який використовується ERC-4337, не дуже хороший: перша транзакція в пакеті споживає одноразове сховище/вартість зчитування коду, що робить її набагато дорожчою за інші транзакції. Інкапсуляція в протоколі дозволить цим публічним спільним бібліотекам бути частиною протоколу та вільно доступними для всіх.
Чого ми можемо навчитися з цього прикладу і коли упаковка стане більш поширеною? **
У цьому прикладі ми бачимо деякі різні обґрунтування для інкапсуляції аспекту абстракції облікового запису в протоколі.
Ринкові підходи, які «доводять складність до краю», швидше за все, зазнають невдачі, коли постійні витрати високі. Насправді, дорожня карта абстракції довгострокового облікового запису виглядає так, ніби кожен блок має багато постійних витрат. 244, 100 газ для завантаження стандартизованих кодів гаманців - це одне; Але агрегація може додати сотні тисяч газу до валідації ZK-SNARK, а також вартість перевірки доказу ланцюга в мережі. Немає способу стягувати з користувачів плату за ці витрати, не вносячи багато ринкової неефективності, і переклад деяких із цих функцій у функції протоколу, до яких кожен може отримати безкоштовний доступ, добре вирішує цю проблему.
Реакція всієї спільноти на помилки коду. Якщо деякі фрагменти коду використовуються всіма користувачами або дуже широким колом користувачів, для блокчейн-спільноти зазвичай має сенс взяти на себе відповідальність за хардфорк для виправлення будь-яких помилок, що виникають. ERC-4337 вводить велику кількість глобально поширеного коду, і виправлення помилок у коді за допомогою хардфорку, безсумнівно, є більш розумним у довгостроковій перспективі, ніж змушувати користувачів втрачати багато ETH.
Іноді сильнішої форми можна досягти, безпосередньо використовуючи функціональність протоколу. Ключовим прикладом тут є функція захисту від цензури в протоколі, така як список включень: список включень у протоколі може гарантувати стійкість до цензури краще, ніж метод поза протоколом, і для того, щоб операції на рівні користувача дійсно виграли від списку включення в протоколі, одна операція на рівні користувача повинна бути «читабельною» для протоколу. Іншим менш відомим прикладом є дизайн Ethereum proof-of-stake 2017 року, який абстрагував ключовий рахунок ставки, від якого відмовилися на користь інкапсуляції BLS, оскільки BLS підтримує механізм «агрегації», який повинен бути реалізований на рівні протоколу та мережі, що може зробити обробку великої кількості підписів більш ефективною.
Але важливо пам'ятати, що навіть інкапсуляція абстракції облікового запису в протоколі все ще є величезною «деінкапсуляцією» порівняно з поточною ситуацією. Сьогодні транзакції Ethereum найвищого рівня можна ініціювати лише із зовнішніх облікових записів (EOA), які перевірені за допомогою однієї еліптичної кривої secp 256k1. Абстракція облікового запису усуває це і залишає критерії валідації на розсуд користувача. Отже, у цій історії про абстракцію облікового запису ми також бачимо найбільший аргумент проти інкапсуляції: гнучкість для задоволення потреб різних користувачів.
Давайте конкретизуємо цю історію далі, розглянувши кілька інших прикладів функцій, які нещодавно вважалися інкапсульованими. Особливу увагу ми приділимо: ZK-EVM, поділу ініціатора-будівельника, приватним мемпулам, стейкінгу ліквідності та новій прекомпіляції.
Пакет 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 є statefulness. Якби ZK-EVM не потрібно було передавати дані «свідків», їх ефективність даних була б набагато вищою. Тобто, якщо певний фрагмент даних вже був прочитаний або записаний в якомусь попередньому блоці, ми можемо просто припустити, що виконавець має до них доступ і не зобов'язаний робити його доступним знову. Справа не тільки в тому, щоб не перезавантажувати сховище та код; Виявляється, стиснення зі збереженням стану може зберегти до 3 разів більше даних порівняно зі стисненням без стану, якщо одне зведення стискає дані правильно.
Це означає, що для попередньої компіляції ZK-EVM у нас є два варіанти:
Попередня компіляція вимагає, щоб усі дані були доступні в одному фрагменті. Це означає, що prover може бути без стану, але це також означає, що використання цього попередньо скомпільованого ZK-rollup набагато дорожче, ніж використання rollup з користувацьким кодом.
Попередня компіляція дозволяє покажчику вказувати на раніше виконані, використані або згенеровані дані. Це робить ZK-rollup майже оптимальним, але він складніший і вводить новий стан, який повинен зберігатися proproof.
Чого ми можемо навчитися з цього? Є вагома причина якимось чином інкапсулювати перевірку ZK-EVM: rollup вже створює власну кастомну версію, і Ethereum готовий зважити свої численні реалізації та соціальний консенсус поза мережею щодо L1 для виконання EVM, що здається неправильним, але L2, який виконує ту саму роботу, повинен впроваджувати складні гаджети за участю Ради безпеки. Але з іншого боку, є велика проблема в деталях: існують різні версії ZK-EVM, які відрізняються вартістю та користю. Відмінність між stateful і state less лише дряпає поверхню; Спроба підтримати "майже-EVM", користувацькі коди, які були перевірені іншими системами, може відкрити більше простору для дизайну. Таким чином, інкапсуляція ZK-EVM пов'язана як з перспективами, так і з труднощами.
Розділення оболонки та конструктора (ePBS)
Розвиток MEV перетворив виробництво блоків на великомасштабну економічну діяльність, учасники якої можуть створювати блоки, які приносять більше доходу, ніж алгоритм за замовчуванням, який просто спостерігає за мемпулом транзакцій і містить їх. До сих пір спільнота Ethereum намагалася вирішити цю проблему, використовуючи позапротокольну схему поділу пропозицій-будівельників, таку як MEV-Boost, яка дозволяє звичайним валідаторам («пропонувачам») передавати створення блоків на аутсорсинг спеціалізованим учасникам («будівельникам»).
Однак MEV-Boost робить припущення про довіру до нового класу учасників, які називаються ретрансляторами. За останні два роки з'явилося багато пропозицій щодо створення «інкапсульованої ПБС». Які переваги від цього? У цьому випадку відповідь проста: PBS, побудовані безпосередньо з функціями протоколу, є більш потужними (в сенсі більш слабких припущень про довіру), ніж PBS, побудовані без них. Це схоже на ситуацію з ціновими оракулами в рамках протоколу інкапсуляції, хоча в цьому випадку також існує сильна опозиція.
Інкапсуляція приватного пулу пам'яті
Коли користувач надсилає транзакцію, вона одразу стає загальнодоступною та видимою для всіх, навіть до того, як вона буде включена в ланцюжок. Це робить користувачів багатьох додатків вразливими до економічних атак, таких як превентивні транзакції.
Останнім часом з'явився ряд проектів, присвячених створенню «приватних мемпулів» (або «зашифрованих мемпулів»), які шифрують транзакції користувачів до тих пір, поки вони не будуть безповоротно прийняті в блок.
Проблема, однак, полягає в тому, що такі схеми вимагають особливого виду шифрування: для того, щоб користувачі не переповнили систему і не розшифрували її першим, шифрування має бути автоматично розшифроване після того, як транзакція дійсно була безповоротно прийнята.
Для досягнення цієї форми шифрування існують різні методи компромісу. Джон Шарбонно якось добре висловився:
Шифруйте централізованих операторів, таких як Flashbots Protect.
шифрування timelock, яке може бути розшифроване будь-ким після певного послідовного кроку обчислення і не може бути розпаралелене;
Порогове шифрування, довіра до розшифровки даних чесного комітету більшості. Конкретні рекомендації наведено в розділі Концепція замкнутого маячка.
Надійне обладнання, наприклад SGX.
На жаль, кожне шифрування має різні слабкі місця. Хоча для кожного рішення є підмножина користувачів, які готові йому довіряти, жодне з рішень не є достатньо надійним, щоб воно було фактично прийнято рівнем 1. Таким чином, принаймні до тих пір, поки шифрування затримки не буде вдосконалено або якийсь інший технологічний прорив, інкапсуляція антипросунутих торгових функцій на рівні 1 здається складною пропозицією, навіть якщо це досить цінна функція, яка з'явилася в багатьох прикладних рішеннях.
Стейкінг інкапсульованої ліквідності
Загальною потребою для користувачів Ethereum DeFi є можливість використовувати свої ETH одночасно для стейкінгу та як заставу в інших програмах. Ще одна поширена потреба полягає просто в зручності: користувачі хочуть мати можливість здійснювати стейкінг (і захищати ключі онлайн-стейкінгу) без складнощів із запуском вузла та постійним збереженням його в мережі.
Поки що найпростішим «інтерфейсом» стейкінгу, який задовольняє обидві ці потреби, є лише токен ERC 20: конвертуйте свої ETH у «стейкінг ETH», утримуйте їх і конвертуйте назад. Фактично, провайдери стейкінгу ліквідності, такі як Lido та Rocket Pool, вже почали це робити. Однак стейкінг ліквідності має деякі природні механізми централізації: люди, природно, переходять у найбільшу версію стейкінгу ETH, оскільки вона є найбільш звичною та ліквідною.
Кожна версія стейкінгу ETH вимагає певного механізму для визначення того, хто може бути оператором базового вузла. Він не може бути необмеженим, оскільки тоді зловмисники приєднаються та посилять атаку коштами користувача. Наразі двома лідерами є Lido, який має оператора білого списку вузлів DAO, і Rocket Pool, який дозволяє будь-кому запускати вузол із внесеними 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 R1, дещо іншої еліптичної кривої, ніж secp 256 K1 для базових облікових записів Ethereum, оскільки вона добре підтримується надійними апаратними модулями, тому її широке використання може підвищити безпеку гаманця. Останніми роками спільнота також наполягала на додаванні попередніх компіляцій для BLS-12-377, BW 6-761, узагальненого сполучення та інших функцій.
Контраргументом на ці запити на отримання більшої кількості попередньо скомпільованих файлів є те, що багато з попередніх компіляцій, доданих раніше (наприклад, RIPEMD і BLAKE), в кінцевому підсумку використовують набагато менше, ніж очікувалося, і ми повинні вчитися на них. Замість того, щоб додавати більше попередньої компіляції для конкретних операцій, можливо, нам слід зосередитися на більш м'якому підході, заснованому на таких ідеях, як EVM-MAX і сплячих, але завжди відновлюваних пропозиціях SIMD, які дозволять реалізаціям EVM виконувати широкий спектр класів коду з меншими витратами. Можливо, навіть існуючу рідко використовувану попередню компіляцію можна було б видалити і замінити (неминуче менш ефективною) реалізацією EVM-коду тієї ж функції. Тим не менш, все ще можливо, що існують певні криптографічні операції, які є досить цінними, щоб прискорити, тому має сенс додавати їх як попередньо скомпільовані.
Чого ми навчилися з усього цього?
Прагнення охопити якомога менше – це зрозуміло і добре; Він походить від філософської традиції Unix створення мінімалістичного програмного забезпечення, яке можна легко адаптувати до різних потреб користувачів і уникнути прокляття роздуття програмного забезпечення. Однак блокчейн – це не персональна обчислювальна операційна система, а соціальна система. Це означає, що є сенс інкапсулювати певний функціонал у протоколі.
У багатьох випадках ці інші приклади схожі на те, що ми бачимо в абстракції розповіді. Але ми також засвоїли кілька нових уроків:
Інкапсуляція може допомогти уникнути ризику централізації в інших місцях стека:
Часто мінімізація та простота базового протоколу виводить складність за межі деяких протоколів екосистеми. З філософської точки зору Unix це добре. Однак іноді існує ризик того, що позапротокольні екосистеми будуть централізовані, як правило (але не тільки) через високі постійні витрати. Інкапсуляція іноді може зменшити фактичну централізацію.
Інкапсуляція занадто великого обсягу контенту може надмірно збільшити навантаження на довіру та управління протоколом:
Це тема попередньої статті на тему «Не перевантажуйте консенсус Ethereum»: якщо інкапсуляція певної функції послаблює модель довіри і робить Ethereum в цілому більш «суб'єктивним», це послаблює довірчий нейтралітет Ethereum. У цих випадках краще представити конкретну функцію як механізм поверх Ethereum, ніж намагатися впровадити її в сам Ethereum. Тут найкращим прикладом є зашифровані пули пам'яті, і їх може бути дещо складно інкапсулювати, принаймні до тих пір, поки шифрування затримки не покращиться.
Занадто велика інкапсуляція може надмірно ускладнити протокол:
Складність протоколу – це системний ризик, який можна збільшити, додавши до протоколу занадто багато функцій. Прекомпіляція – найкращий приклад.
У довгостроковій перспективі інкапсуляція функціональності може мати негативні наслідки, оскільки потреби користувачів непередбачувані:
Функція, яку багато хто вважає важливою і буде використовуватися багатьма користувачами, швидше за все, не використовується регулярно на практиці.
Крім того, стейкінг ліквідності, ZK-EVM та попередньо скомпільовані кейси показують можливість серединного шляху: мінімального життєздатного закріплення. Протоколи не обов'язково повинні інкапсулювати всю функцію, але можуть містити конкретні частини, які вирішують ключові проблеми, що робить функцію легкою для реалізації, не будучи занадто параноїдальною або занадто вузькою. Прикладами цього є:
Замість того, щоб інкапсулювати повну систему застави ліквідності, краще змінити правила штрафів за стейкінг, щоб зробити заставу ліквідності без довіри більш здійсненною;
Замість того, щоб інкапсулювати більше прекомпіляторів, інкапсулюйте EVM-MAX та/або SIMD, щоб полегшити ефективну реалізацію для ширшого спектру операційних категорій;
Верифікацію EVM можна просто інкапсулювати, а не інкапсулювати всю концепцію зведення.
Ми можемо розгорнути попередню діаграму наступним чином:
Іноді є сенс щось обернути, і прикладом є видалення рідко використовуваної попередньої компіляції. Абстракція рахунку в цілому, як згадувалося раніше, також є важливою формою деінкапсуляції. Якщо ми хочемо підтримати зворотну сумісність для існуючих користувачів, механізм насправді може бути разюче схожим на той, який деінкапсулює попередньо скомпільований: однією з пропозицій є EIP-5003, який дозволить EOA конвертувати свої облікові записи в контракти з тією ж (або кращою) функціональністю.
Які функції слід впровадити в протокол, а які залишити іншим рівням екосистеми, є складним компромісом. Очікується, що з часом цей компроміс продовжуватиме вдосконалюватися, оскільки наше розуміння потреб користувачів і доступних ідей і технологічних пакетів продовжує вдосконалюватися.