Блокчейни - це глобально розподілені реєстри, які приходять до згоди щодо глобального стану. Деякі блокчейни обладнані виконавчим середовищем повного пошуку, що дозволяє програмованість на основі цього глобального стану. Програми, які націлюються на виконавчі середовища блокчейнів, називаються смарт-контрактами, а підтримуючі блокчейни називаються платформами смарт-контрактів. Ethereum, Solana та Avalanche - це деякі з найбільш відомих платформ смарт-контрактів. Ми можемо уявити платформи смарт-контрактів як розподілені комп'ютери, де виконавче середовище (або віртуальна машина) діє як ЦП, а стан виконує роль сховища.
Це уявлення блокчейнів як комп'ютерів буде важливим для того, щоб пояснити, чому копроцесори / обчислення поза ланцюжком є необхідними, особливо в контексті блокчейнів. У традиційному обчислювальному процесі копроцесори виникли в мікроархітектурі для підвищення продуктивності. Так само копроцесори на Ethereum обіцяють доступ до історичних даних та високопродуктивних обчислень поза ланцюжком, щоб розширити можливості та простір дизайну базового протоколу. Подивіться на цю вступну статтю про копроцесори для отримання додаткової інформації.
У цій статті співпроцесори досліджуються з перших принципів, прагнучи з'ясувати їх важливість і мета-властивості. Потім ми порівнюємо їх зі зведеннями, демонструючи, як ці два поняття, хоч і різні, але тісно пов'язані між собою. Ми також наводимо приклади, коли зведення та співпроцесори можна використовувати разом один з одним. Наприклад, навіть для всепотужного rollup або L1 може знадобитися співпроцесор для важких завдань.
Ми підсумовуємо цю статтю, зауважуючи, що блокчейни рухаються в майбутнє, де обчислення централізовані, але перевірка залишається децентралізованою. Rollups, копроцесори та будь-яка інша форма перевірної позачергової обчислюваності - це лише різні втілення цього майбутнього.
У статті «Обмеження масштабованості блокчейну» Віталік зазначив, що для децентралізації блокчейну важливо, щоб звичайні користувачі могли запускати вузол.
Як згадувалося раніше, Ethereum можна концептуалізувати як децентралізований глобальний комп'ютер у багатьох аспектах. Це мережа вузлів, на яких працює програмне забезпечення, яке надає обчислювальні ресурси для виконання смарт-контрактів. Блокчейн Ethereum зберігає інформацію про стан і код, подібно до сховища та пам'яті комп'ютера. А віртуальна машина Ethereum (EVM) працює на кожному вузлі, обробляючи транзакції та виконуючи код, як центральний процесор. Однак Ethereum є інклюзивним і децентралізованим, використовуючи консенсус між ненадійними вузлами. Якщо деякі вузли переходять в автономний режим, мережа продовжує працювати. Щоб забезпечити правильність операцій EVM, валідатори в мережах Proof-of-Stake (PoS), таких як Ethereum, повинні виконати всі переходи станів для їх перевірки. Це обмежує швидкість мережі PoS її найповільнішими вузлами, обмежуючи кількість обчислювальних програм, доступних для них.
На відміну від звичайного комп'ютера, Ethereum обмежує обчислення та зберігання, щоб запобігти зловживанню мережею. За кожну операцію стягуються платежі, що робить фінансово недоцільними безкінечні петлі. Цей підхід дозволяє знижувати бар'єри для вступу, дозволяючи використовувати повсякденне обладнання, таке як Raspberry Pi, для запуску мережевих вузлів. Обмеження дозволяють створити інклюзивну систему, де кожен може допомагати управляти децентралізованою мережею Ethereum.
Через ці обчислювальні обмеження вузлів Ethereum, складні застосунки, такі як моделі машинного навчання, ігри або наукові обчислення, не можуть реалістично виконуватися безпосередньо на Ethereum сьогодні.
Це компроміс, щоб зробити Ethereum широкодоступним, безпечним та стійким як основу для базових додатків. Проте неодмінно існують деякі обмеження у порівнянні з обчислювально необмеженим комп'ютером. У нього є обмеження, порівняно навіть з таким старим процесором, як Pentium 5:
Немає складної плаваючої математики - EVM підтримує лише основні математичні та логічні операції. Розширені числові обчислення, такі як нейронні мережі, не є доцільними. (Цікавий факт полягає в тому, що неможливість обробки плаваючої коми також ускладнює обмін активами, такими як Ampleforth і т.д., в останній час і іноді навіть несумісні з деякими DEXs).
Обмежений обсяг обчислень на блок — оплата газу метро обчислення, тому складне програмне забезпечення, таке як ігри, було б надзвичайно дорогим. Ліміт газу на блок становить 30M газу.
Обмежена пам'ять - Розумні контракти мають невеликі постійні обмеження зберігання, що ускладнює створення великих програм.
Немає постійного зберігання файлів - Немає способу зберігати файли, такі як графіка, аудіо або відео на блокчейні.
Повільна швидкість - Швидкості транзакцій на Ethereum наразі становлять приблизно 15 TPS, що в декілька разів повільніше, ніж у процесора.
У кінцевому підсумку, обмежений обсяг сховища та обчислення обмежують ступені вільності, доступні для додатків (ці обмеження відрізняються від блокчейну до блокчейну, але завжди існують). Люди порівнювали блокчейни з обмеженими обчислювальними середовищами 1970-1980-х років, але ми вважаємо, що існують деякі великі різниці між ними двома:
Зростання обчислень у 1970-1980-х роках було стрімким (з кількістю транзисторів у мікропроцесорах, яка збільшилася з приблизно 1 000 до приблизно 1 000 000 за цей період). Проте це зростання не означало, що люди часто купували або оновлювали свої комп'ютери. Оскільки платформи для розумних контрактів обмежені своїми найповільнішими вузлами, прискорення на межі комп'ютерів не обов'язково призведе до того, що блокчейни побачать пропорційне збільшення обчислювальної швидкості. Прискорення може відбутися лише в тому випадку, якщо базові вимоги для вузлів на блокчейні будуть оновлені.
Також існує чіткий компроміс між постійним оновленням мінімальних апаратних вимог для вузлів та децентралізацією. Одиничні стейкери можуть не бажати оновлювати апаратне забезпечення кожні кілька років (і вони точно не хочуть щодня контролювати продуктивність), що призводить до того, що лише фахівці хочуть запускати інфраструктуру блокчейну.
Все це говорить про те, що з роками процесори вдосконалювалися, і ми отримали більше ядер ЦП на кожному пристрої, що дозволяє нам виконувати все складніші завдання. Якщо ми вважаємо, що блокчейн-комп'ютери не будуть прискорюватися так швидко, як традиційні обчислення (через базові вимоги до вузлів), то має сенс спробувати знайти альтернативні джерела обчислень. Цікава аналогія, яку можна провести, полягає в тому, що центральні процесори в традиційних обчисленнях не справлялися з завданнями графічної обробки, що призвело до появи графічних процесорів майже в кожному комп'ютері. Аналогічним чином, оскільки блокчейни зосереджені на тому, щоб бути безпечними сховищами стану з увімкненими простими обчислювальними батареями, існує чітка можливість для офчейн-обчислень розширити простір дизайну додатків. Сьогодні блокчейни мають сенс лише для додатків з низьким рівнем обчислень, яким потрібні такі властивості, як відкритий доступ, самосуверенітет, стійкість до цензури та компонування. Щоб розмістити більшу різноманітність додатків у мережі, нам потрібно зняти обмеження, які ми накладаємо на розробників додатків. Ми говоримо це з розумінням того, що ці обмеження також були благом для експериментів. Наприклад, CLOB не могли ефективно працювати на Ethereum через обчислювальні обмеження, тому були прийняті AMM, які з тих пір досягли трильйона доларів.
Існують два загальні підходи до забезпечення доступності більшого обчислювального потенціалу для додатків блокчейн:
Дуже часто збільшуйте базові вимоги до вузлів. Це приблизно шлях інтегрованих високопродуктивних блокчейнів, таких як Solana та Sui. Високий базовий рівень для вузлів дає їм змогу будувати дуже швидкий блокчейн і також знімає деякі обмеження з дизайну додатків. Фінікс, DEX з лімітованим ордер-буком на Solana, не міг бути побудований на Ethereum (або будь-якому L2) сьогодні. З іншого боку, збільшення базових вимог призводить до того, що якщо вони постійно зростатимуть, то запуск вузлів може бути прийнятним тільки для професійних постачальників інфраструктури. Історичні вимоги до ОЗП досить добре демонструють, як ріс апаратний забезпечення на Solana:
Web Archive (Примітка: ми використовуємо медіанні вимоги до ОЗП з 2020 року)
Переміщення обчислень поза ланцюжок на сторонні сервери. Це була стратегія, яку прийняла екосистема Ethereum. Ці сторонні сервери можуть бути блокчейнами (у випадку роллапів), пристроями для позачергової перевірки обчислень (тобто співпроцесорами) або довіреними сторонами (як у випадку позачергових обчислень застосунків, таких як orderbook від dydx).
До уніфікації обчислень поза ланцюжком
Нещодавно почали активно обговорювати копроцесори, які забезпечують обчислення за ланцюжком. Копроцесори можуть бути реалізовані різними способами, включаючи, але не обмежуючись, доказами нульового знання або оточеннями довіри виконання (TEEs). Деякі приклади:
ZK копроцесори: Аксіома, Bonsai Risc Zero.
TEEs: Устриця Марлін,
Водночас, коли справа доходить до розвантаження обчислень, дорожня карта Ethereum, орієнтована на зведення, розвантажує обчислення в різні зведення, які осідають на Ethereum. Протягом останніх кількох років постійний потік розробників і користувачів переходив на ролапи завдяки поєднанню дешевших і швидших транзакцій і стимулів, які надають ролапи. В ідеальному світі зведення дозволяють Ethereum масштабувати свої загальні обчислювальні потужності за допомогою офчейн-виконання, не додаючи припущень про довіру. Більше обчислень означає не тільки виконання більшої кількості транзакцій, але й виконання більш виразних обчислень для кожної транзакції. Нові типи транзакцій розширюють простір проектування, доступний для додатків, а більш висока пропускна здатність знижує витрати на виконання цих виразних транзакцій, забезпечуючи доступний доступ до додатків вищого класу.
Перш ніж ми підемо далі, давайте коротко визначимо як роллапи, так і копроцесори, щоб уникнути плутанини:
Rollups: Rollups зберігають постійний, розділений стан, відмінний від базових/хост-ланцюгів, але все ж успадковує захисні властивості свого базового ланцюгу, публікуючи дані/докази про це. Переміщуючи стан з хост-ланцюгу, rollups можуть використовувати додаткові обчислення для виконання переходів стану перед публікацією доказів цих переходів стану на хост-ланцюгу. Rollups найбільш корисні для користувачів, які не хочуть платити високі комісії Ethereum, але хочуть мати доступ до захисних властивостей Ethereum.
Перед тим як заглибитися у копроцесори, давайте подамо ще деяку інформацію про те, як сьогодні обмежений розвиток розумних контрактів на Ethereum. У Ethereum є постійне зберігання стану в його глобальному стані - баланси рахунків, дані контрактів тощо. Ці дані залишаються на блокчейні назавжди. Однак є обмеження:
Максимальний розмір даних контракту обмежений (наприклад, 24 КБ на контракт наразі і було встановлено в EIP 170). Зберігання великих файлів перевищувало б це. (*Не вирішено також копроцесорами)
Читання/запис сховища контракту повільніше, ніж файлова система або база даних. Доступ до 1 КБ даних може коштувати мільйони газу.
Поки глобальний стан існує, окремі вузли зберігають лише останній стан локально в режимі "видалення". Повна історія стану потребує архівного вузла.
Немає жодних природних примітивів файлової системи для роботи з файлами, такими як зображення, аудіо та документи. Смарт-контракти можуть лише читати / записувати базові типи даних у сховище.
Рішення навколо цього є:
Великі файли можуть бути розділені на менші частини, щоб вони вмістилися в обмеження сховища контрактів.
Посилання на файли можуть бути збережені on-chain, з файлами, що зберігаються off-chain в системах, таких як IPFS.
Співпроцесори: Співпроцесори самі не підтримують жодного стану; вони поводяться як лямбда-функції на AWS, де програми можуть надсилати їм обчислювальне завдання, і вони надсилають результат із доказом обчислень. Співпроцесори принципово збільшують кількість обчислень, доступних для будь-якої конкретної транзакції, але оскільки доведення на співпроцесорах також відбувається на основі кожної транзакції, їх використання буде дорожчим, ніж зведення. Враховуючи вартість, співпроцесори, ймовірно, будуть корисними для протоколів або користувачів, які хочуть виконувати складні одноразові завдання у спосіб, який можна перевірити. Ще одна перевага співпроцесорів полягає в тому, що вони дозволяють програмам, що використовують офчейн-обчислення, також отримувати доступ до повного історичного стану Ethereum, не додаючи жодних припущень щодо довіри до самої програми; Сьогодні це неможливо на смарт-контракті Vanilla.
Щоб зрозуміти різницю між роллапами та співпроцесорами, звернемося до смаків ZK обох цих примітивів. ZK-зведення отримують доступ як до перевірюваності, так і до аспекту стиснення доказів із нульовим розголошенням, що дозволяє їм суттєво збільшити пропускну здатність своєї екосистеми. Співпроцесори, з іншого боку, отримують доступ лише до властивості перевірюваності доказів zk, що означає, що загальна пропускна здатність системи залишається незмінною. Крім того, для ZK-ролапів потрібні схеми, які можуть довести будь-яку програму, націлену на віртуальну машину для цього зведення (наприклад, ролапи на Ethereum створили zkEVM для контрактів, націлених на EVM). На відміну від них, співпроцесорам ZK потрібно лише будувати схеми для виконання завдань, для виконання яких вони залучені.
Отже, здається, дві найбільші відмінності між роллапами та копроцесорами це:
Rollups зберігають розділене постійне стан, а копроцесори ні (вони використовують стан головного ланцюжка).
Rollups (як ім'я підказує) пакують кілька транзакцій разом, а копроцесори, як правило, використовуються для складних завдань як частина однієї транзакції (принаймні в поточному парадигмі).
Нещодавно було запропоновано Booster Rollups, які виконують транзакції так, ніби вони працюють безпосередньо на головному ланцюжку, з доступом до повного стану головного ланцюжка. Однак у Booster Rollups також є власне сховище, що дозволяє їм масштабувати обчислення та зберігання як на головному ланцюжку, так і на роллапі. Пропозиція Booster Rollup вказує на те, що в дизайні поза ланцюжком обчислень існує спектр, при цьому традиційні роллапи та співпроцесори знаходяться на кінцях цього спектру. Роллапи, Booster Rollups та Співпроцесори надають доступ до більшого обчислення й відрізняються лише тим, яку кількість стану вони утримують від свого базового L1.
На виступі на Modular Summit, 2023 під назвою «Захищені транзакції - це Rollups», Генрі Де Валенс розповів про цей самий концепт і представив дуже простий образ, щоб визначити Rollup:
Доповідь стверджує, що будь-яке виконання, вивантажене базовим ланцюжком на сторонню сторону, є rollup. Згідно з його визначенням, копроцесори також будуть rollups. Це трохи відрізняється від нашого погляду на об'єднання rollups та копроцесорів під прапорцем off-chain підтверджуваного обчислення, але загальний настрій залишається таким самим!
У своєму баченні «Фіналу» Віталік обговорює майбутнє, в якому виробництво блоків буде централізованим, а перевірка блоків не потребує довіри та дуже децентралізованою. Ми вважаємо, що це приблизно правильна модель для того, щоб думати про те, що відбувається зараз. У zk-rollup виробництво блоків і обчислення переходів станів централізовані. Однак докази дозволяють верифікації бути дешевою та децентралізованою. Аналогічно, zk-співпроцесор не має блокового виробництва; Він отримує доступ лише до історичних даних і обчислює переходи станів над цими даними. Обчислення на zk-співпроцесорі, швидше за все, завжди будуть виконуватися на централізованій машині; Тим не менш, доказ дійсності, повернутий разом із результатом, дозволяє будь-кому перевірити результати перед їх використанням. Можливо, буде правильним перефразувати бачення Віталіка так: «майбутнє, де обчислення будуть централізованими, але верифікація централізованих обчислень не потребує довіри і буде дуже децентралізованою».
Незважаючи на їх загальні схожості, ролапи та копроцесори сьогодні обслуговують дуже різні ринки. Хтось може запитати: «Якщо ми можемо просто використовувати копроцесор на ETH L1 та мати доступ до його ліквідності, чому нам потрібні ролапи?», хоча це справедливе запитання, ми вважаємо, що є кілька причин, чому ролапи все ще мають сенс (і представляють набагато більші можливості на ринку, ніж копроцесори сьогодні):
Як вже зазначалося, копроцесори дозволяють отримати доступ до більшої обчислювальної потужності в тому ж транзакції, ніж L1. Але вони не можуть допомогти збільшити кількість транзакцій, які можуть бути виконані блокчейном, який викликає копроцесор (якщо ви думаєте про пакетне виконання, ось ви вже дійшли до роллапу). Зберігаючи розділене постійне стан, роллапи можуть збільшити кількість транзакцій, доступних для людей, які хочуть отримати доступ до блокпростору з властивостями безпеки Ethereum. Це можливо, оскільки роллапи публікуються лише в Ethereum кожні n блоків і не вимагають, щоб всі валідатори Ethereum перевіряли, що відбулася зміна стану. Зацікавлені сторони можуть просто покладатися на доказ.
Навіть якщо ви використовуєте копроцесори, вам все одно доведеться платити таку саму величину комісій, як і за будь-яку іншу транзакцію на L1. З іншого боку, ролапи через пакування можуть зменшити витрати на кілька порядків величини.
Крім того, оскільки ролапи надають можливість запускати транзакції в цьому окремому стані, вони все ще поводяться як блокчейни (швидші, менш децентралізовані блокчейни, але, тим не менш, блокчейни), тому вони також мають чіткі обмеження на те, скільки обчислень можна отримати з самого зведення. У цьому сценарії співпроцесор може бути корисним для зведення, якщо користувач хоче виконувати як завгодно складні транзакції (а тепер ви робите транзакції, які можна перевірити, у зведенні, тому вам потрібно лише підкорятися законам фізики зведення).
Ще один важливий момент, який слід відзначити тут, полягає в тому, що більшість ліквідності сьогодні знаходиться на ETH L1, тому для багатьох протоколів, які покладаються на ліквідність для поліпшення своїх продуктів, може бути розумно все ще випустити їх на головну мережу Ethereum. Додаток на головній мережі Ethereum може мати доступ до більшої обчислювальної потужності, виконуючи періодичні операції на співпроцесорі. Наприклад, DEX, як Ambient або Uniswap v4, може використовувати гачки разом зі співпроцесорами для складної логіки щодо зміни комісій або навіть зміни форми кривої ліквідності на основі ринкових даних.
Одна цікава аналогія порівнює взаємодію між ролапами та копроцесорами з імперативним та функціональним програмуванням. Імперативне програмування акцентується на змінних станах та побічних ефектах, вказуючи крок за кроком, як виконувати завдання. Функціональне програмування підкреслює незмінні дані та чисті функції, уникуючи змін стану та побічних ефектів. Так само, ролапи схожі на імперативні програми, які змінюють стан, який вони утримують, тоді як копроцесори схожі на функціональні програми, де вони не змінюють стан, але виробляють результат разом із доказами обчислення. Більше того, так само, як імперативне та функціональне програмування, ролапи та копроцесори мають своє місце і повинні використовуватися відповідно.
Якщо ми опинимося в світі, де обчислення централізовані, але перевірка централізованого обчислення надійна й високоградаційна, то що це означатиме для Ethereum? Чи буде світовий комп'ютер зведений до простої бази даних? Чи це погано?
Зрештою, мета Ethereum полягає в тому, щоб надати своїм користувачам доступ до надійних обчислень і сховищ. У минулому єдиним способом отримати доступ до обчислень Ethereum без довіри було виконання обчислень і перевірка всіма вузлами. З розвитком методів доведення (особливо доведень з нульовим розголошенням) ми можемо перемістити більшу частину обчислень, які відбувалися на вузлах валідаторів, до офчейн-обчислень і лише змусити валідаторів перевіряти результати в ланцюжку. Це, по суті, перетворює Ethereum на незмінну дошку оголошень у світі. Докази обчислень дозволяють нам перевірити, що транзакція була виконана правильно, і, опублікувавши їх в Ethereum, ми отримуємо позначку часу та незмінне історичне сховище для цих доказів. Оскільки доведення з нульовим розголошенням стають більш ефективними при довільних обчисленнях, цілком імовірно, що в якийсь момент вартість виконання обчислень у ZK буде значно меншою, ніж вартість виконання цього в блокчейні (можливо, навіть у ланцюжку CometBFT зі 100 валідаторами). У такому світі важко уявити, що докази ZK не стануть домінуючим способом доступу до обчислень без довіри. Схожі думки останнім часом повторює і Девід Вонг:
Майбутнє, в якому можна довести будь-який обчислювальний процес, також дозволяє нам будувати інфраструктуру для типів довірчих додатків, які користувачі вимагають, замість спроби адаптації базового рівня Ethereum, щоб стати домашнім для цих додатків. У ідеальному випадку спеціалізована інфраструктура створить більш безшовні користувацькі враження і також буде масштабуватися разом з додатками, побудованими на його основі. Це, сподіваємося, дозволить веб3-додаткам конкурувати з їх веб2-аналогами та відкрити двері у довірче, доказове майбутнє, про яке завжди мріяли саїферпанки.
В цілому ми вважаємо, що ми рухаємося в напрямку наступної парадигми:
————————————————————Не довіряй, перевіряй————————————————————-
Блокчейни - це глобально розподілені реєстри, які приходять до згоди щодо глобального стану. Деякі блокчейни обладнані виконавчим середовищем повного пошуку, що дозволяє програмованість на основі цього глобального стану. Програми, які націлюються на виконавчі середовища блокчейнів, називаються смарт-контрактами, а підтримуючі блокчейни називаються платформами смарт-контрактів. Ethereum, Solana та Avalanche - це деякі з найбільш відомих платформ смарт-контрактів. Ми можемо уявити платформи смарт-контрактів як розподілені комп'ютери, де виконавче середовище (або віртуальна машина) діє як ЦП, а стан виконує роль сховища.
Це уявлення блокчейнів як комп'ютерів буде важливим для того, щоб пояснити, чому копроцесори / обчислення поза ланцюжком є необхідними, особливо в контексті блокчейнів. У традиційному обчислювальному процесі копроцесори виникли в мікроархітектурі для підвищення продуктивності. Так само копроцесори на Ethereum обіцяють доступ до історичних даних та високопродуктивних обчислень поза ланцюжком, щоб розширити можливості та простір дизайну базового протоколу. Подивіться на цю вступну статтю про копроцесори для отримання додаткової інформації.
У цій статті співпроцесори досліджуються з перших принципів, прагнучи з'ясувати їх важливість і мета-властивості. Потім ми порівнюємо їх зі зведеннями, демонструючи, як ці два поняття, хоч і різні, але тісно пов'язані між собою. Ми також наводимо приклади, коли зведення та співпроцесори можна використовувати разом один з одним. Наприклад, навіть для всепотужного rollup або L1 може знадобитися співпроцесор для важких завдань.
Ми підсумовуємо цю статтю, зауважуючи, що блокчейни рухаються в майбутнє, де обчислення централізовані, але перевірка залишається децентралізованою. Rollups, копроцесори та будь-яка інша форма перевірної позачергової обчислюваності - це лише різні втілення цього майбутнього.
У статті «Обмеження масштабованості блокчейну» Віталік зазначив, що для децентралізації блокчейну важливо, щоб звичайні користувачі могли запускати вузол.
Як згадувалося раніше, Ethereum можна концептуалізувати як децентралізований глобальний комп'ютер у багатьох аспектах. Це мережа вузлів, на яких працює програмне забезпечення, яке надає обчислювальні ресурси для виконання смарт-контрактів. Блокчейн Ethereum зберігає інформацію про стан і код, подібно до сховища та пам'яті комп'ютера. А віртуальна машина Ethereum (EVM) працює на кожному вузлі, обробляючи транзакції та виконуючи код, як центральний процесор. Однак Ethereum є інклюзивним і децентралізованим, використовуючи консенсус між ненадійними вузлами. Якщо деякі вузли переходять в автономний режим, мережа продовжує працювати. Щоб забезпечити правильність операцій EVM, валідатори в мережах Proof-of-Stake (PoS), таких як Ethereum, повинні виконати всі переходи станів для їх перевірки. Це обмежує швидкість мережі PoS її найповільнішими вузлами, обмежуючи кількість обчислювальних програм, доступних для них.
На відміну від звичайного комп'ютера, Ethereum обмежує обчислення та зберігання, щоб запобігти зловживанню мережею. За кожну операцію стягуються платежі, що робить фінансово недоцільними безкінечні петлі. Цей підхід дозволяє знижувати бар'єри для вступу, дозволяючи використовувати повсякденне обладнання, таке як Raspberry Pi, для запуску мережевих вузлів. Обмеження дозволяють створити інклюзивну систему, де кожен може допомагати управляти децентралізованою мережею Ethereum.
Через ці обчислювальні обмеження вузлів Ethereum, складні застосунки, такі як моделі машинного навчання, ігри або наукові обчислення, не можуть реалістично виконуватися безпосередньо на Ethereum сьогодні.
Це компроміс, щоб зробити Ethereum широкодоступним, безпечним та стійким як основу для базових додатків. Проте неодмінно існують деякі обмеження у порівнянні з обчислювально необмеженим комп'ютером. У нього є обмеження, порівняно навіть з таким старим процесором, як Pentium 5:
Немає складної плаваючої математики - EVM підтримує лише основні математичні та логічні операції. Розширені числові обчислення, такі як нейронні мережі, не є доцільними. (Цікавий факт полягає в тому, що неможливість обробки плаваючої коми також ускладнює обмін активами, такими як Ampleforth і т.д., в останній час і іноді навіть несумісні з деякими DEXs).
Обмежений обсяг обчислень на блок — оплата газу метро обчислення, тому складне програмне забезпечення, таке як ігри, було б надзвичайно дорогим. Ліміт газу на блок становить 30M газу.
Обмежена пам'ять - Розумні контракти мають невеликі постійні обмеження зберігання, що ускладнює створення великих програм.
Немає постійного зберігання файлів - Немає способу зберігати файли, такі як графіка, аудіо або відео на блокчейні.
Повільна швидкість - Швидкості транзакцій на Ethereum наразі становлять приблизно 15 TPS, що в декілька разів повільніше, ніж у процесора.
У кінцевому підсумку, обмежений обсяг сховища та обчислення обмежують ступені вільності, доступні для додатків (ці обмеження відрізняються від блокчейну до блокчейну, але завжди існують). Люди порівнювали блокчейни з обмеженими обчислювальними середовищами 1970-1980-х років, але ми вважаємо, що існують деякі великі різниці між ними двома:
Зростання обчислень у 1970-1980-х роках було стрімким (з кількістю транзисторів у мікропроцесорах, яка збільшилася з приблизно 1 000 до приблизно 1 000 000 за цей період). Проте це зростання не означало, що люди часто купували або оновлювали свої комп'ютери. Оскільки платформи для розумних контрактів обмежені своїми найповільнішими вузлами, прискорення на межі комп'ютерів не обов'язково призведе до того, що блокчейни побачать пропорційне збільшення обчислювальної швидкості. Прискорення може відбутися лише в тому випадку, якщо базові вимоги для вузлів на блокчейні будуть оновлені.
Також існує чіткий компроміс між постійним оновленням мінімальних апаратних вимог для вузлів та децентралізацією. Одиничні стейкери можуть не бажати оновлювати апаратне забезпечення кожні кілька років (і вони точно не хочуть щодня контролювати продуктивність), що призводить до того, що лише фахівці хочуть запускати інфраструктуру блокчейну.
Все це говорить про те, що з роками процесори вдосконалювалися, і ми отримали більше ядер ЦП на кожному пристрої, що дозволяє нам виконувати все складніші завдання. Якщо ми вважаємо, що блокчейн-комп'ютери не будуть прискорюватися так швидко, як традиційні обчислення (через базові вимоги до вузлів), то має сенс спробувати знайти альтернативні джерела обчислень. Цікава аналогія, яку можна провести, полягає в тому, що центральні процесори в традиційних обчисленнях не справлялися з завданнями графічної обробки, що призвело до появи графічних процесорів майже в кожному комп'ютері. Аналогічним чином, оскільки блокчейни зосереджені на тому, щоб бути безпечними сховищами стану з увімкненими простими обчислювальними батареями, існує чітка можливість для офчейн-обчислень розширити простір дизайну додатків. Сьогодні блокчейни мають сенс лише для додатків з низьким рівнем обчислень, яким потрібні такі властивості, як відкритий доступ, самосуверенітет, стійкість до цензури та компонування. Щоб розмістити більшу різноманітність додатків у мережі, нам потрібно зняти обмеження, які ми накладаємо на розробників додатків. Ми говоримо це з розумінням того, що ці обмеження також були благом для експериментів. Наприклад, CLOB не могли ефективно працювати на Ethereum через обчислювальні обмеження, тому були прийняті AMM, які з тих пір досягли трильйона доларів.
Існують два загальні підходи до забезпечення доступності більшого обчислювального потенціалу для додатків блокчейн:
Дуже часто збільшуйте базові вимоги до вузлів. Це приблизно шлях інтегрованих високопродуктивних блокчейнів, таких як Solana та Sui. Високий базовий рівень для вузлів дає їм змогу будувати дуже швидкий блокчейн і також знімає деякі обмеження з дизайну додатків. Фінікс, DEX з лімітованим ордер-буком на Solana, не міг бути побудований на Ethereum (або будь-якому L2) сьогодні. З іншого боку, збільшення базових вимог призводить до того, що якщо вони постійно зростатимуть, то запуск вузлів може бути прийнятним тільки для професійних постачальників інфраструктури. Історичні вимоги до ОЗП досить добре демонструють, як ріс апаратний забезпечення на Solana:
Web Archive (Примітка: ми використовуємо медіанні вимоги до ОЗП з 2020 року)
Переміщення обчислень поза ланцюжок на сторонні сервери. Це була стратегія, яку прийняла екосистема Ethereum. Ці сторонні сервери можуть бути блокчейнами (у випадку роллапів), пристроями для позачергової перевірки обчислень (тобто співпроцесорами) або довіреними сторонами (як у випадку позачергових обчислень застосунків, таких як orderbook від dydx).
До уніфікації обчислень поза ланцюжком
Нещодавно почали активно обговорювати копроцесори, які забезпечують обчислення за ланцюжком. Копроцесори можуть бути реалізовані різними способами, включаючи, але не обмежуючись, доказами нульового знання або оточеннями довіри виконання (TEEs). Деякі приклади:
ZK копроцесори: Аксіома, Bonsai Risc Zero.
TEEs: Устриця Марлін,
Водночас, коли справа доходить до розвантаження обчислень, дорожня карта Ethereum, орієнтована на зведення, розвантажує обчислення в різні зведення, які осідають на Ethereum. Протягом останніх кількох років постійний потік розробників і користувачів переходив на ролапи завдяки поєднанню дешевших і швидших транзакцій і стимулів, які надають ролапи. В ідеальному світі зведення дозволяють Ethereum масштабувати свої загальні обчислювальні потужності за допомогою офчейн-виконання, не додаючи припущень про довіру. Більше обчислень означає не тільки виконання більшої кількості транзакцій, але й виконання більш виразних обчислень для кожної транзакції. Нові типи транзакцій розширюють простір проектування, доступний для додатків, а більш висока пропускна здатність знижує витрати на виконання цих виразних транзакцій, забезпечуючи доступний доступ до додатків вищого класу.
Перш ніж ми підемо далі, давайте коротко визначимо як роллапи, так і копроцесори, щоб уникнути плутанини:
Rollups: Rollups зберігають постійний, розділений стан, відмінний від базових/хост-ланцюгів, але все ж успадковує захисні властивості свого базового ланцюгу, публікуючи дані/докази про це. Переміщуючи стан з хост-ланцюгу, rollups можуть використовувати додаткові обчислення для виконання переходів стану перед публікацією доказів цих переходів стану на хост-ланцюгу. Rollups найбільш корисні для користувачів, які не хочуть платити високі комісії Ethereum, але хочуть мати доступ до захисних властивостей Ethereum.
Перед тим як заглибитися у копроцесори, давайте подамо ще деяку інформацію про те, як сьогодні обмежений розвиток розумних контрактів на Ethereum. У Ethereum є постійне зберігання стану в його глобальному стані - баланси рахунків, дані контрактів тощо. Ці дані залишаються на блокчейні назавжди. Однак є обмеження:
Максимальний розмір даних контракту обмежений (наприклад, 24 КБ на контракт наразі і було встановлено в EIP 170). Зберігання великих файлів перевищувало б це. (*Не вирішено також копроцесорами)
Читання/запис сховища контракту повільніше, ніж файлова система або база даних. Доступ до 1 КБ даних може коштувати мільйони газу.
Поки глобальний стан існує, окремі вузли зберігають лише останній стан локально в режимі "видалення". Повна історія стану потребує архівного вузла.
Немає жодних природних примітивів файлової системи для роботи з файлами, такими як зображення, аудіо та документи. Смарт-контракти можуть лише читати / записувати базові типи даних у сховище.
Рішення навколо цього є:
Великі файли можуть бути розділені на менші частини, щоб вони вмістилися в обмеження сховища контрактів.
Посилання на файли можуть бути збережені on-chain, з файлами, що зберігаються off-chain в системах, таких як IPFS.
Співпроцесори: Співпроцесори самі не підтримують жодного стану; вони поводяться як лямбда-функції на AWS, де програми можуть надсилати їм обчислювальне завдання, і вони надсилають результат із доказом обчислень. Співпроцесори принципово збільшують кількість обчислень, доступних для будь-якої конкретної транзакції, але оскільки доведення на співпроцесорах також відбувається на основі кожної транзакції, їх використання буде дорожчим, ніж зведення. Враховуючи вартість, співпроцесори, ймовірно, будуть корисними для протоколів або користувачів, які хочуть виконувати складні одноразові завдання у спосіб, який можна перевірити. Ще одна перевага співпроцесорів полягає в тому, що вони дозволяють програмам, що використовують офчейн-обчислення, також отримувати доступ до повного історичного стану Ethereum, не додаючи жодних припущень щодо довіри до самої програми; Сьогодні це неможливо на смарт-контракті Vanilla.
Щоб зрозуміти різницю між роллапами та співпроцесорами, звернемося до смаків ZK обох цих примітивів. ZK-зведення отримують доступ як до перевірюваності, так і до аспекту стиснення доказів із нульовим розголошенням, що дозволяє їм суттєво збільшити пропускну здатність своєї екосистеми. Співпроцесори, з іншого боку, отримують доступ лише до властивості перевірюваності доказів zk, що означає, що загальна пропускна здатність системи залишається незмінною. Крім того, для ZK-ролапів потрібні схеми, які можуть довести будь-яку програму, націлену на віртуальну машину для цього зведення (наприклад, ролапи на Ethereum створили zkEVM для контрактів, націлених на EVM). На відміну від них, співпроцесорам ZK потрібно лише будувати схеми для виконання завдань, для виконання яких вони залучені.
Отже, здається, дві найбільші відмінності між роллапами та копроцесорами це:
Rollups зберігають розділене постійне стан, а копроцесори ні (вони використовують стан головного ланцюжка).
Rollups (як ім'я підказує) пакують кілька транзакцій разом, а копроцесори, як правило, використовуються для складних завдань як частина однієї транзакції (принаймні в поточному парадигмі).
Нещодавно було запропоновано Booster Rollups, які виконують транзакції так, ніби вони працюють безпосередньо на головному ланцюжку, з доступом до повного стану головного ланцюжка. Однак у Booster Rollups також є власне сховище, що дозволяє їм масштабувати обчислення та зберігання як на головному ланцюжку, так і на роллапі. Пропозиція Booster Rollup вказує на те, що в дизайні поза ланцюжком обчислень існує спектр, при цьому традиційні роллапи та співпроцесори знаходяться на кінцях цього спектру. Роллапи, Booster Rollups та Співпроцесори надають доступ до більшого обчислення й відрізняються лише тим, яку кількість стану вони утримують від свого базового L1.
На виступі на Modular Summit, 2023 під назвою «Захищені транзакції - це Rollups», Генрі Де Валенс розповів про цей самий концепт і представив дуже простий образ, щоб визначити Rollup:
Доповідь стверджує, що будь-яке виконання, вивантажене базовим ланцюжком на сторонню сторону, є rollup. Згідно з його визначенням, копроцесори також будуть rollups. Це трохи відрізняється від нашого погляду на об'єднання rollups та копроцесорів під прапорцем off-chain підтверджуваного обчислення, але загальний настрій залишається таким самим!
У своєму баченні «Фіналу» Віталік обговорює майбутнє, в якому виробництво блоків буде централізованим, а перевірка блоків не потребує довіри та дуже децентралізованою. Ми вважаємо, що це приблизно правильна модель для того, щоб думати про те, що відбувається зараз. У zk-rollup виробництво блоків і обчислення переходів станів централізовані. Однак докази дозволяють верифікації бути дешевою та децентралізованою. Аналогічно, zk-співпроцесор не має блокового виробництва; Він отримує доступ лише до історичних даних і обчислює переходи станів над цими даними. Обчислення на zk-співпроцесорі, швидше за все, завжди будуть виконуватися на централізованій машині; Тим не менш, доказ дійсності, повернутий разом із результатом, дозволяє будь-кому перевірити результати перед їх використанням. Можливо, буде правильним перефразувати бачення Віталіка так: «майбутнє, де обчислення будуть централізованими, але верифікація централізованих обчислень не потребує довіри і буде дуже децентралізованою».
Незважаючи на їх загальні схожості, ролапи та копроцесори сьогодні обслуговують дуже різні ринки. Хтось може запитати: «Якщо ми можемо просто використовувати копроцесор на ETH L1 та мати доступ до його ліквідності, чому нам потрібні ролапи?», хоча це справедливе запитання, ми вважаємо, що є кілька причин, чому ролапи все ще мають сенс (і представляють набагато більші можливості на ринку, ніж копроцесори сьогодні):
Як вже зазначалося, копроцесори дозволяють отримати доступ до більшої обчислювальної потужності в тому ж транзакції, ніж L1. Але вони не можуть допомогти збільшити кількість транзакцій, які можуть бути виконані блокчейном, який викликає копроцесор (якщо ви думаєте про пакетне виконання, ось ви вже дійшли до роллапу). Зберігаючи розділене постійне стан, роллапи можуть збільшити кількість транзакцій, доступних для людей, які хочуть отримати доступ до блокпростору з властивостями безпеки Ethereum. Це можливо, оскільки роллапи публікуються лише в Ethereum кожні n блоків і не вимагають, щоб всі валідатори Ethereum перевіряли, що відбулася зміна стану. Зацікавлені сторони можуть просто покладатися на доказ.
Навіть якщо ви використовуєте копроцесори, вам все одно доведеться платити таку саму величину комісій, як і за будь-яку іншу транзакцію на L1. З іншого боку, ролапи через пакування можуть зменшити витрати на кілька порядків величини.
Крім того, оскільки ролапи надають можливість запускати транзакції в цьому окремому стані, вони все ще поводяться як блокчейни (швидші, менш децентралізовані блокчейни, але, тим не менш, блокчейни), тому вони також мають чіткі обмеження на те, скільки обчислень можна отримати з самого зведення. У цьому сценарії співпроцесор може бути корисним для зведення, якщо користувач хоче виконувати як завгодно складні транзакції (а тепер ви робите транзакції, які можна перевірити, у зведенні, тому вам потрібно лише підкорятися законам фізики зведення).
Ще один важливий момент, який слід відзначити тут, полягає в тому, що більшість ліквідності сьогодні знаходиться на ETH L1, тому для багатьох протоколів, які покладаються на ліквідність для поліпшення своїх продуктів, може бути розумно все ще випустити їх на головну мережу Ethereum. Додаток на головній мережі Ethereum може мати доступ до більшої обчислювальної потужності, виконуючи періодичні операції на співпроцесорі. Наприклад, DEX, як Ambient або Uniswap v4, може використовувати гачки разом зі співпроцесорами для складної логіки щодо зміни комісій або навіть зміни форми кривої ліквідності на основі ринкових даних.
Одна цікава аналогія порівнює взаємодію між ролапами та копроцесорами з імперативним та функціональним програмуванням. Імперативне програмування акцентується на змінних станах та побічних ефектах, вказуючи крок за кроком, як виконувати завдання. Функціональне програмування підкреслює незмінні дані та чисті функції, уникуючи змін стану та побічних ефектів. Так само, ролапи схожі на імперативні програми, які змінюють стан, який вони утримують, тоді як копроцесори схожі на функціональні програми, де вони не змінюють стан, але виробляють результат разом із доказами обчислення. Більше того, так само, як імперативне та функціональне програмування, ролапи та копроцесори мають своє місце і повинні використовуватися відповідно.
Якщо ми опинимося в світі, де обчислення централізовані, але перевірка централізованого обчислення надійна й високоградаційна, то що це означатиме для Ethereum? Чи буде світовий комп'ютер зведений до простої бази даних? Чи це погано?
Зрештою, мета Ethereum полягає в тому, щоб надати своїм користувачам доступ до надійних обчислень і сховищ. У минулому єдиним способом отримати доступ до обчислень Ethereum без довіри було виконання обчислень і перевірка всіма вузлами. З розвитком методів доведення (особливо доведень з нульовим розголошенням) ми можемо перемістити більшу частину обчислень, які відбувалися на вузлах валідаторів, до офчейн-обчислень і лише змусити валідаторів перевіряти результати в ланцюжку. Це, по суті, перетворює Ethereum на незмінну дошку оголошень у світі. Докази обчислень дозволяють нам перевірити, що транзакція була виконана правильно, і, опублікувавши їх в Ethereum, ми отримуємо позначку часу та незмінне історичне сховище для цих доказів. Оскільки доведення з нульовим розголошенням стають більш ефективними при довільних обчисленнях, цілком імовірно, що в якийсь момент вартість виконання обчислень у ZK буде значно меншою, ніж вартість виконання цього в блокчейні (можливо, навіть у ланцюжку CometBFT зі 100 валідаторами). У такому світі важко уявити, що докази ZK не стануть домінуючим способом доступу до обчислень без довіри. Схожі думки останнім часом повторює і Девід Вонг:
Майбутнє, в якому можна довести будь-який обчислювальний процес, також дозволяє нам будувати інфраструктуру для типів довірчих додатків, які користувачі вимагають, замість спроби адаптації базового рівня Ethereum, щоб стати домашнім для цих додатків. У ідеальному випадку спеціалізована інфраструктура створить більш безшовні користувацькі враження і також буде масштабуватися разом з додатками, побудованими на його основі. Це, сподіваємося, дозволить веб3-додаткам конкурувати з їх веб2-аналогами та відкрити двері у довірче, доказове майбутнє, про яке завжди мріяли саїферпанки.
В цілому ми вважаємо, що ми рухаємося в напрямку наступної парадигми:
————————————————————Не довіряй, перевіряй————————————————————-