Розуміння дебатів “Закріпити чи розширити”

Погляди на філософію закріплення Віталіка

Віталік Бутерін нещодавно опублікував блог під назвою “Чи варто Ethereum вбудовувати в протокол більше речей?”. У цьому блозі він поділився своїми думками щодо функцій протоколу, необхідних для закріплення додатків верхнього рівня в Ethereum, і запропонував структуру для закріплення певних функцій в Ethereum dApps. Ця пропозиція висвітлює критичну проблему, з якою зіткнуться блокчейн-платформи у 2023 році: Чи повинні функції протоколу бути “закріплені” в базовому рівні, або ж зовнішні розробники повинні бути відкритими для “розширення” нових функцій на рівні додатків?

Ethereum — єдиний з новітніх протоколів, який намагається вирішити дилему “закріпити чи розширити”. За останні шість місяців кілька основних протоколів впровадили технічні оновлення з фокусом на те, щоб дозволити зовнішнім розробникам розширювати основну функціональність: Uniswap представив “хуки” для підтримки розширення функції пулів, а гаманець MetaMask представив “прив’язки”, щоб дозволити користувачеві створювати розширення.

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

Виклик для Ethereum: Закріпити проти розширення

Розширення Ethereum стикається з проблемами

Філософія дизайну Ethereum бере свій початок в Unix. Вона спрямована на створення мінімального, універсального простору ядра і дозволяє зовнішнім розробникам реалізовувати потреби користувачів у просторі додатків. Ключовою технологією, що підтримує цей підхід, є віртуальна машина Ethereum (EVM). Ця мова смарт-контрактів з повною мовою Тьюринга дозволяє розробникам налаштовувати свої dApps у просторі додатків.

Хоча ця модель, орієнтована на розробників, має багато переваг, вона стикається з проблемами — зокрема, так звана “повна за Тюрінгом” EVM насправді не є повною. У EVM обмежена кількість опкодів і механізм обробки газових платежів вимагають від зовнішніх програм виконувати завдання за кінцеву кількість кроків. Це обмеження суттєво обмежує здатність Ethereum dApps масштабуватися, працювати гнучко і включати розширену функціональність, таку як користувацький рівень Unix у Web3 додатках. Незважаючи на запропоновані рішення, такі як Rollups і AA гаманці, які можуть працювати на Ethereum без модифікації L1, поки що не відбулося справжнього прориву, який би дозволив досягти цілей ефективності і зручності для користувачів, яких вимагають розробники.

Закріплення здається неминучим

Оскільки “децентралізований Unix” приймає все більше додатків та інновацій, перед Ethereum стоїть виклик, як краще пристосувати універсальні функції. Простого розширення функціональності на рівні EVM недостатньо. Ethereum також потребує закріплення. Деякі розширені функції додатків, які можуть не функціонувати оптимально в EVM, повинні бути закріплені на рівні протоколу.

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

Закріплення не є панацеєю

На момент написання цієї статті Пропозиція щодо вдосконалення Ефіріуму (EIP) є єдиним способом закріпити певні функції в базовому шарі. Однак ця пропозиція створює серйозну перешкоду: всі нові функції повинні бути розглянуті і, в кінцевому рахунку, об’єднані основною командою Ethereum, перш ніж вони стануть доступними для розробників.

Він має кілька обмежень:

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

У дилемі “закріплювати чи розширювати” Ethereum застряг між молотом і ковадлом. Через ці обмеження, практична реальність буде такою, що будь-яка функція, яка не є широко узгодженою необхідністю, швидше за все, ніколи не буде закріплена. У багатьох випадках розробникам, можливо, доведеться створювати власний ланцюжок додатків (AppChain), що пов’язано з високими витратами на розробку та експлуатацію, а також з втратою сумісності смарт-контрактів Ethereum. Як “закріпити” більше функцій поступово, як зазначив Віталік, він і команда Ethereum все ще досліджують, і очевидні рамки для визначення цих функцій — і для досягнення певного консенсусу спільноти щодо пріоритетів розвитку — знаходяться в стадії розробки.

Вчимося у Unix: Нативне розширення

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

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

Наприклад, розглянемо Mac OS X, загальну операційну систему, яка розрізняє простір ядра та простір користувача. Користувацькі програми зазвичай працюють у просторі користувача, використовуючи функції, що надаються програмами у просторі ядра. Спрощене (хоча і не зовсім точне) порівняння полягає в тому, що смарт-контракти поверх EVM еквівалентні додаткам користувацького простору, в той час як рівень протоколу Ethereum еквівалентний простору ядра. Mac OS X дозволяє розробникам додатків розгортати програми в просторі ядра автономно, розширюючи функції ядра без необхідності в тому, щоб основна команда Mac OS X закріплювала ці функції в кожному конкретному випадку. Mac OS X надає основні механізми, відомі як “розширення ядра” та “системні розширення”. Ці розширення дозволяють розробникам створювати розширення ядра у безпечному режимі, використовувати функції вищого рівня та реалізовувати можливості, які не можуть бути реалізовані у користувацьких програмах.

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

На додаток до підтримки смарт-контрактів, ми пропонуємо інший тип програм на рівні протоколу блокчейну, який називається “нативні розширення”, з наступними характеристиками:

1. Більший доступ до API базового протоколу, ніж у смарт-контрактів.
2. На порядок вища ефективність середовища виконання в порівнянні з EVM.
3. Ізоляція безпеки від базового протоколу, що забезпечує стабільність системи.
4. Відсутність потреби в обслуговуванні з боку основної команди розробників; незалежні команди розробників додатків можуть підтримувати та розгортати систему.

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

Давайте подивимося, чи є якісь сліди цієї парадигми “Нативного розширення” в існуючих інфраструктурах Web3.

Гачок, гачок, гачок…

У світі програмного забезпечення великі винаходи найчастіше виникають з великої потреби. Uniswap, як інфраструктура DeFi, знаходиться на критичному етапі становлення “платформи”. У дебатах “закріплювати чи розширювати” Uniswap твердо стоїть на стороні “розширювати” за допомогою хуків. Хуки дозволяють розробникам додавати розширення до пулів Uniswap, не вимагаючи дозволу, досягаючи диверсифікованого досвіду роботи з пулом без необхідності постійного оновлення функцій за допомогою закріплення.

Механізм хука має кілька спільних рис з вищезгаданою парадигмою Native Extension:

1. Хуки можуть інтегрувати логіку в життєвий цикл виконання пулів і отримувати доступ до даних під час виконання, забезпечуючи вищий рівень доступу.
2. Хуки та пули — це два окремі контракти, тобто безпека хуків не впливає на пули.
3. З точки зору управління, хуки можуть розроблятися і розгортатися сторонніми розробниками без дозволу. Хуки не активуються глобально, а прив’язуються до різних пулів, якщо це необхідно для реалізації користувацьких функцій.

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

Проектування розширення нових публічних ланцюгів

Давайте подивимося, що роблять проекти 2-го рівня для розширення функціональності 1-го рівня.

Arbitrum Stylus: Дозвольте розробникам додатків самим закріплювати заздалегідь складені контракти!

На момент написання цієї статті єдиним способом розширення (дуже обмеженого) функціоналу EVM є використання “попередньо скомпільованих контрактів”; ці контракти не виконуються на EVM, а інтегруються у вузли і виконуються далі по стеку. Наприклад, розробник може додати новий обчислювально інтенсивний криптографічний алгоритм як попередньо скомпільований контракт, але він буде працювати лише на вузлі, на якому його реалізовано. Однак, навіть з обмеженою функціональністю, дозволи на додавання попередньо скомпільованих контрактів не є відкритими для більшості розробників додатків і вимагають від основної команди Ethereum їх закріплення.

Arbitrum Stylus представляє парадигму “EVM+”, яка зберігає сумісність з EVM і дозволяє розробникам вийти за рамки обмежень EVM для розгортання високопродуктивних, попередньо скомпільованих контрактів без дозволу. Це досягається шляхом додавання середовища виконання Web Assembly до самого рівня виконання, динамічного завантаження та запуску контрактів WASM. WASM забезпечує на порядок вищу ефективність, ніж EVM, і підтримує декілька мов програмування.

Завдяки Stylus, потреби EVM у розширенні більше не залежать від основної команди — основна команда може зосередитися на підтримці розширеного часу виконання, в той час як розробка, впровадження та управління новими функціями залишаються на рівні додатків для подальшої кастомізації. Arbitrum, що є символом інфраструктури нового покоління, представив дизайн розширюваності, який вирішує поточну проблему “закріплення”, водночас продумано враховуючи довгострокову стійкість і зростання екосистеми.

Рідне розширення: Модульний підхід Артела!

Розуміючи історію успіху Web2 та потреби Web3, ми можемо зробити висновок, що ідеальним механізмом додавання функціональності до системи є збільшення “розширюваності”, що дозволяє розробникам самостійно визначати свої потреби та модульно розширювати можливості системи. Подібно до Unix і Google Chrome, нативне розширення дозволяє розробникам задовольняти свої потреби, використовуючи базовий протокол без шкоди для його стабільності.

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

Artela, новий публічний блокчейн L1, дозволяє здійснювати нативне розширення.

У блокчейні Artela ми впровадили середовище виконання WebAssembly (WASM) разом з віртуальною машиною Ethereum (EVM). WASM може підтримувати роботу програм зі станом, подібних до попередньо скомпільованих контрактів. Artela дозволяє використовувати механізм, подібний до хуків, який може виконуватися на різних етапах життєвого циклу блоків і транзакцій. В цілому, Artela може вийти далеко за рамки закріплення попередньо скомпільованих контрактів (наприклад, Arbitrum Stylus), дозволяючи кастомізувати потоки виконання транзакцій і блоків для набагато ширшого спектру потенційних можливостей і функціональності.

Наприклад, нативне розширення WASM може бути прив’язане до dApp і спрацьовувати під час процесу перевірки транзакції, щоб використовувати новий алгоритм для ідентифікації та перевірки відповідних транзакцій. В Artela ці хуки називаються точками з’єднання, а нативні розширення називаються аспектами (Aspects). Подібно до концепції Аспектно-орієнтованого програмування (AoP), Аспекти дозволяють розробникам включати нові функції та можливості в різні Точки приєднання в системі блокчейн.

Які унікальні випадки використання Aspects? Один із прикладів — захист під час виконання. Основною перешкодою для широкомасштабної міграції активів на Web3 є безпека на рівні ланцюжка. На відміну від існуючих заходів контролю ризиків, які зосереджені на рівні вихідного коду протоколу і вступають в силу до його виконання, захист під час виконання передбачає написання розробниками протоколу правил безпеки і дій для обробки непередбачених результатів під час виконання. Захист протоколу за принципом “чорного ящика” підвищує безпеку, гарантуючи, що кінцеві результати виконання відповідають запланованому дизайну протоколу, і все це без безпосередньої участі у фактичному виконанні коду.

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

Для “Артела” наше бачення полягає в наступному:

1. Надайте можливість проектам прикладного рівня вирішувати проблеми за допомогою нативного розширення, не чекаючи, поки команда розробників базового блокчейну закріпить його.
2. Заохочуйте великі установи зі світу Web2 впевнено ставити активи на блокчейн завдяки посиленому контролю ризиків на рівні виконання на рівні Web2.
3. Надати розробникам екосистему для революційних інновацій, враховуючи, що потенціал EVM може незабаром досягти своїх меж, тоді як EVM+Native Extension пропонує більше можливостей.
4. Забезпечити кращу платформу для проектів, спрямованих на реалізацію більшої кількості логіки та функціональних можливостей на основі ланцюжка, включаючи повністю ланцюжкові ігри та реальні активи.

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

Імпорт Web2

Хоча на рівні коду децентралізований стек Web3 і стек Web2 є абсолютно різними парадигмами, це не заважає нам досліджувати скарби філософії дизайну та історичного розвитку Інтернету. Продовжуйте будувати!

Артела будує модульне майбутнє Web3 вже майже рік, і до кінця року запустить публічну тестову мережу для всіх розробників! Будьте в курсі подій, слідкуйте за Artela у Twitter та приєднуйтесь до нашого Discord.