«Співвідношення між модульним блокчейном і єдиним блокчейном доповнюють, а не конфронтують».
Оригінальна назва: «Co-exist Future of Smart Contract Platforms»
Автор: FF, дослідницька група LBank Labs
Складач: Sharon, BlockBeats
Примітка редактора:
Модульний блокчейн став однією з тенденцій розвитку 2024 року, визначених членами криптоспільноти, включаючи інвестиційні установи, такі як a16z. У той же час оновлення Ethereum Cancun неминуче, і в спільноті існують різні думки щодо технології модульного блокчейну та монолітного блокчейну. LBank нещодавно опублікував статтю, у якій виклав власну точку зору з цього приводу. Після порівняння та аналізу базової технічної архітектури Ethereum 2.0 з Near і Polkadot LBank вважає, що модульні блокчейни та окремі блокчейни не слід розглядати як антагоністи. , а слід розглядати як взаємодоповнюючі. , модульний ланцюг може служити проміжним шаром мономерного ланцюга, а мономерний ланцюг може служити специфічним шаром модульного ланцюга. Вони вчаться на сильних і слабких сторонах один одного і разом розвиваються. BlockBeats компілює оригінальний текст таким чином:
Ця стаття є продовженням нашого попереднього дослідження під назвою «Можливості в модульних наративах». У цій статті ми глибоко занурилися в модульну хвилю, яку ведуть Ethereum і Celestia, і визначили різні можливості.
Однак важливо зазначити, що модульні наративи не повинні обмежувати нашу перспективу. За останні кілька років технологія блокчейн досягла значного прогресу з появою монолітних і модульних архітектур блокчейнів.
У цій статті ми спочатку проаналізуємо ці два архітектурні підходи та порівняємо Ethereum з іншими конкурентами Ethereum з попереднього циклу. Дивно, але подібності між ними більше, ніж люди думають.
Далі ми вивчимо проблеми та конкретні міркування, пов’язані з цими двома архітектурними підходами, дивлячись на симбіотичне майбутнє для платформ смарт-контрактів. У минулому в екосистемі блокчейнів домінували монолітні блокчейни, причому кожен новий блокчейн L1 працював незалежно, що призводило до жорсткої конкуренції та обмеженої співпраці на ринку; однак зараз ми перебуваємо в ланцюжковому зв’язку та сумісності між етапами є більш розвиненими, ніж будь-коли раніше. Тому ми віддаємо перевагу відкритим платформам, будь вони модульними чи монолітними.
У цьому розділі наведено детальне порівняння відмінностей і схожості між Ethereum та іншими монолітними блокчейнами, підкреслюючи їх відмінності в архітектурному дизайні. У ньому також обговорюються відмінності між модульним дизайном і монолітною архітектурою, а також проблеми, пов’язані з досягненням справжньої масштабованості.
Хоча сам Ethereum має модульну конструкцію, він також використовує шардинг як засіб досягнення масштабованості. Шардинг дозволяє паралельно обробляти транзакції та дані в кількох сегментах, збільшуючи пропускну здатність і ємність.
Однак реалізація сегментування також приносить власний набір проблем, таких як забезпечення доступності даних, остаточність транзакцій і полегшення перехресних транзакцій. Подолання цих проблем вимагає ретельного розгляду та інноваційних рішень для успішної інтеграції шардингу в монолітний блокчейн. Приклади шардингу включають Ethereum, Near і Polkadot.
Порівняння Ethereum 2.0 (ETH2.0) і Near Protocol зосереджується на ключових відмінностях у їхніх підходах. Підхід Ethereum передбачає сегментування, орієнтоване на зведення, де рівні виконання та доступності даних роз’єднані. Це використовує базовий L1 для забезпечення безпеки та зведення для масштабованості.
Near вирішив побудувати сегментовану мережу з самого початку, повністю враховуючи наявність шардингу даних і виконання у своїй вбудованій архітектурі. Це перша ключова відмінність. Дизайн центрального методу Ethereum Rollup є відносно простим, але він все ще вимагає шардингу доступності даних (Danksharding), щоб L2 працював ефективно.
Друга ключова відмінність чітко пояснюється нижче. Порівняно зі звичайним ланцюгом маяків і ланцюгом реле, Near вибрав інше рішення для шардингу. Сам Near розділений на різні шарди, кожен шард відповідає за генерацію і зберігання блоків у складі блоку.
Так званий дизайн «Nightshade» дає змогу досягти безперебійного читання та запису смарт-контрактів між сегментами, хоча це накладає вищий поріг для розробників. Що стосується користувачів, вони навіть не будуть знати про шарди, з якими вони взаємодіють.
У модульній розповіді попередньої статті ми обговорювали вирішення проблем компонування та сумісності. Однак це не є проблемою для Near, оскільки його вбудований шардинг по суті дозволяє здійснювати крос-шардові транзакції, подібні до крос-згорнутих транзакцій у L2.

Дорожня карта Nightshade включає наступні етапи:
З точки зору прогресу, Near зараз знаходиться між Фазою 1 і Фазою 2. Продюсер лише для фрагментів, представлений минулого року, може відстежувати статус лише одного шарда. Проте все ще існують повні валідатори вузлів, які відповідають за підтримку глобального стану.
Незважаючи на те, що Near лідирує в дизайні шардингу, він також багато чого навчився з революції Ethereum. Щоб досягти цілей Фази 2, жоден валідатор не повинен відстежувати всі сегменти. Натомість «рибалка» діє як охоронець, відстежуючи стан і створюючи докази шахрайства в викликах. Основний дизайн дуже схожий на Optimistic Rollup, але його повна реалізація складна.
Ось чому багато протоколів відмовляються від цього рішення. Наприклад, Optimism перейшов на рішення zk, а Arbitrum не дозволяє подавати неліцензійні докази шахрайства. Очевидно, що zkRollups — це майбутнє Ethereum. Ми також бачимо вплив zkRollups у новому дизайні сегментування Near.

Що, якби було краще рішення, щоб усунути виклик, що стоїть за грою? Тут Near представляє перевірку без збереження стану. Перевірка без стану генерує перевірку стану без передачі стану іншим сегментам. З державним свідком немає потреби ні в «рибалці», ні в доказі шахрайства.
У налаштуваннях перевірки без стану існує два типи валідаторів. Попередні повні валідатори вузлів тепер замінено на валідатори без стану, тоді як пропонатори блоків залишаються незмінними. Пропоненти блоків відповідають за створення блоків і свідків стану, які повинні підтримувати стан шарда локально.
З іншого боку, валідатори без стану отримують свідки стану для перевірки переходу стану кожного блоку. Запровадивши ротацію валідатора, практично неможливо домогтися, щоб валідатор пошкодив шард.
Запровадження перевірки без збереження стану приносить багато переваг. Вартість роботи валідаторів без збереження стану значно нижча, ніж раніше, що дозволяє більшій кількості валідаторів приєднатися до консенсусу. Це збільшує децентралізацію всієї мережі. Для тих, хто пропонує блоки, у міру додавання більшої кількості шардів стан кожного шарда зменшуватиметься. Оскільки вузьким місцем блокчейну є в основному читання та запис стану, продуктивність окремого фрагмента може бути значно покращена, якщо стан повністю зберігається в пам’яті.

До появи доказів з нульовим знанням (ZKP) державні свідки традиційно використовувалися в MPT. Однак із зрілістю та останнім розвитком ZKP багато протоколів, у тому числі Near, активно сприйняли цей перехід. ZKP виділяється простотою та функціями конфіденційності, які він пропонує, значно знижуючи вартість перевірки переходу стану. На додаток до стислих даних, ZKP невеликий і його легко перевірити. Використовуючи рекурсивні докази, стан усіх сегментів можна перевірити разом.
Доказ переходу стану для шарда складається з трьох основних елементів: забезпечення правильності хешу блоку, підтвердження точності стану, який використовується під час виконання, і перевірка виконання під час виконання. Наразі залишається одна проблема – незважаючи на значний прогрес за останній рік, створення доказів все ще займає більше часу, ніж очікувалося.
Очікується, що це буде розвиватися далі, оскільки зусилля з демонстрації систем та інженерних можливостей триватимуть. Ось чому Near об’єднався з Polygon для створення zkWASM.
Щоб зберегти поточну швидку надійність, не впливаючи на взаємодію з користувачем, Near вніс модульні налаштування. Starsight відокремив консенсус від виконання, дозволяючи консенсусу працювати незалежно та вирішувати, які транзакції будуть включені в блок. Віддалені виклики процедур (RPC) забезпечують оптимістичну остаточність. Після того, як згенеровано підтвердження певного переходу стану, воно подається в блок, а валідатор згодом перевіряє достовірність підтвердження.
Це підтвердження діє як підтвердження нового кореня стану та нового кореня вихідної квитанції. У цьому випадку докази з нульовим знанням функціонують як свідки стану. Однак ZKP можна підтвердити або відхилити лише консенсусом, усуваючи потребу в ротації валідатора. ZKP гарантує правильність і безпеку за допомогою математики та працює дуже подібно до Rollup, який успадковує функції безпеки Ethereum.
Модульна конструкція може забезпечити додаткові переваги в монолітних ланцюгах. Гнучкість Starsight полягає в тому, що він працює не лише з існуючим середовищем виконання Near WASM, а й із будь-яким середовищем виконання, яке може генерувати докази zk для переходів станів, наприклад EVM і Move.
Між Ethereum 2.0 і Polkadot більше, ніж очікувалося спочатку, підтвердженням чого є спільність реалізацій Гевіна Вуда. Деякі навіть припускають, що Polkadot представляє кінцеву мету ETH 2.0, і хоча це не зовсім точно, аналогія фіксує фундаментальну істину.
З нашої точки зору, Polkadot демонструє вищий рівень інженерної зрілості. До того, як з’явилося підтвердження нульового знання, архітектура Ethereum, орієнтована на зведення, була тісно інтегрована з дизайном Polkadot. Пряме порівняння термінів може виявити разючу подібність у їхніх кінцевих цілях.
Будучи рівнем координації, ланцюжок маяків наголошує на доступності даних у центрі зведення; ланцюжок ретрансляції відповідає за ретрансляцію повідомлень і підтримку даних паралельного ланцюга. Спільна безпека походить від ланцюга ретрансляції, і Ethereum успадковує безпеку секс.
Паралельні ланцюги відповідають за виконання транзакцій, публікацію даних у ланцюжку ретрансляції та налаштування власних переходів між станами; Rollup виконує транзакції поза L1, потім публікує дані на L1 і досягає консенсусу.


Послідовна філософія дизайну очевидна: зберігайте простий базовий рівень, зберігайте доступність даних, координуйте інформацію та використовуйте верхні рівні для повного покращення функціональності та масштабованості.
Незважаючи на однакову філософію дизайну та роботу над досягненням спільних цілей, поточний статус двох блокчейнів різко відрізняється. Згідно зі статистичними даними Etherscan і Subscan, щоденний обсяг транзакцій Ethereum перевищує 1 мільйон, тоді як Polkadot має лише 12 000 за останні дні. Що стосується щоденних активних облікових записів, ми бачимо 395 000 на Ethereum і 8 000 на Polkadot.




Різниця в їх поточному статусі значною мірою зумовлена їхніми відповідними стратегіями. Polkadot переслідує найкращу архітектуру та свідомо відмовляється від функції смарт-контракту. Розробникам потрібно створювати «піддони» або модулі ланцюжка додатків, що для багатьох є важким тягарем. Поєднання агресивних стратегій і високого порогу для аукціонів слотів призводить до екосистеми, якій бракує достатнього динамізму, щоб компенсувати ці виклики.
Навпаки, Ethereum надає пріоритет ринку та прагне задовольнити потреби ринку. Він відповідно коригує свою дорожню карту, використовуючи поетапний підхід.
Хоча ми не будемо заглиблюватися в конкретні причини буму Ethereum і занепаду Polkadot, порівняння ETH 2.0 і Polkadot дає нам цінну інформацію про майбутнє архітектури блокчейнів і потенціал відкритої спільної екосистеми.
Незважаючи на труднощі, з якими зараз стикається, Polkadot має багато передових конструкцій, які варто вивчати та вчитися.
Видатним внеском екосистеми Polkadot є фреймворк підстанів, який забезпечує чудову концепцію абстракції для ланцюжків додатків. Ця структура дозволяє сторонам проекту легко запускати власні мережі. За межами екосистеми Polkadot ми спостерігаємо, як багато активних ланцюжків будуються на Substrate, включаючи такі проекти, як Polygon Avail і Starknet Madara, не кажучи вже про численні незалежні ланцюжки.

Хоча «піддони» можуть становити технічний тягар для розробників смарт-контрактів, вони надають потужні інструменти абстракції для розробників протоколів. Ці «піддони» можна повторно використовувати на всіх ланцюгах Substrate, сприяючи досягненню спільного консенсусу та стандартизації. Ця функція дозволяє спеціалізувати та оптимізувати для конкретних програм.
Сучасні тенденції в Resource as a Service (RaaS), такі як стек OP і Polygon CDK, демонструють певний рівень абстракції. Однак ці ініціативи, такі як репозиторії з відкритим кодом, все ще не є комплексними порівняно з Substrate. У міру розвитку RaaS ми можемо очікувати більших покращень у налаштуванні та доступності модулів ланцюга.


Другою відмінною рисою Polkadot є Cross-Consensus Message Passing (XCMP), протокол обміну повідомленнями, який дозволяє парачейнам обмінюватися довільними повідомленнями без проходження через ланцюжок ретрансляції. Це означає, що смарт-контракти можуть безперешкодно викликати один одного в межах одного парачейну, а також між різними парачейнами.
Навпаки, під час взаємодії з різними зведеними пакетами на Ethereum необхідні перемикання активів і мережеве перемикання. Цей процес створює такі проблеми, як фрагментована ліквідність і порушення сумісності. Щоб вирішити ці проблеми, ми виступаємо за те, щоб Ethereum Foundation відігравала провідну роль у розробці стандартів і активно просувала застосування цих стандартів у різних зведених пакетах. Цей підхід суттєво сприятиме майбутньому розвитку Ethereum та пов’язаних з ним екосистем, які стануть більш бездоганними та сумісними.

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

Наведене вище порівняння показує, що, незважаючи на незначні відмінності, суть платформ смарт-контрактів в основному залишається незмінною. Тому як монолітні, так і модульні блокчейни стикаються з певними проблемами.
У цьому розділі ми вивчимо дві поширені проблеми, з якими стикаються платформи смарт-контрактів у цілому, перш ніж заглибитись у конкретні питання, пов’язані з модульними ланцюжками.
Однією з головних проблем, з якою стикаються платформи смарт-контрактів, є створення конкурентного та інноваційного середовища. Популярність EVM-сумісних L1 рішень стала дещо одноманітною, навіть Віталік Бутерін класифікував їх за сумісністю.
Визнаючи історичне значення новаторських EVM і Solidity, важливо також визнати, що технології з часом розвивалися. Наполягання на правовому та традиційному характері EVM може обмежити прогрес, особливо з огляду на обмеження блоків Ethereum.
Захоплення різними архітектурами, віртуальними машинами (VM) і мовами смарт-контрактів походить від бажання уникнути обмежень EVM. Різноманітність цих аспектів приваблює розробників і користувачів, які вважають за краще використовувати різні мови програмування та функції смарт-контрактів. Наприклад, на первинному ринку Move VM (Aptos, Sui) і Cario VM (Starknet) досягли високих оцінок завдяки очікуванням інновацій і можливостям, які вони приносять.
Роблячи ставки на наступну інноваційну платформу, необхідно визнати домінування EVM на ринку. Але в міру того, як ринок розвивається, він, як правило, потрапляє в дуополію, наприклад, Android і iOS, Windows і Mac.
WASM є сильним конкурентом EVM, а Солана є найбільшим гравцем. Незважаючи на критику, ключові інновації Solana, такі як годинник Proof-of-History (POH), Optimistic Concurrency Control (OCC) і протокол пересилання транзакцій без мемпулу, відрізняють її від інших протоколів і порушують традиційне обмеження дизайну блоків.
Згаданий тут консенсус виходить за межі вузького технічного рівня та охоплює широке поле соціального консенсусу.
З точки зору консенсусу, зрозуміло, що багато L1 і L2 обирають сумісність з EVM. Ця опція надає їм найпростіший спосіб підключитися до екосистеми Ethereum. Однак із збільшенням кількості ланцюжків EVM і зведених пакетів, зменшення граничної корисності, як правило, приваблює тимчасових і нелояльних розробників і користувачів, які можуть швидко піти після того, як отримають airdrops.
На додаток до сумісності з EVM, досягнення консенсусу шляхом переставлення дає ще один переконливий наратив для залучення існуючої спільноти. Будівництво з нуля стає дедалі складнішим, що підкреслює важливість вибору правильного активу для перезастави. Тонкий, але критичний момент полягає в тому, що якщо припустити, що всі модульні рівні використовують L1 Security Derivatives (LSD) для забезпечення безпеки, різниця між монолітним блокчейном і модульним блокчейном зменшується.
Крім того, деякі протоколи поширюють свій вплив на ширшу групу користувачів Web2, особливо в ігровій сфері. Хоча цей підхід є ефективним, він вимагає серйозних зусиль для розвитку бізнесу. Багато традиційних гравців віддають перевагу розширенню своєї бази користувачів як засобу досягнення консенсусу в мінливому середовищі.
У той час як модульні блокчейни ефективно розподіляють робоче навантаження між підключеними ланцюжками або модулями, вирішення конкретних завдань має вирішальне значення для досягнення справжньої масштабованості. Основні проблеми, пов’язані з модульними ланцюжками, включають фрагментацію, нестабільність, перехресне згортання та централізацію.
Фрагментація: Фрагментація є результатом гострої конкуренції між різними верствами. Хоча нинішні конкуренти можуть не співпрацювати відразу, очікується, що розвиток універсальних протоколів і абстракцій облікових записів забезпечить користувачам бездоганний досвід роботи з різними продуктами;
Вразливість: вразливість є результатом різних припущень безпеки між різними рівнями. У модульному блокчейні кожен модуль працює незалежно, представляючи потенційні вразливості. Коли певний рівень стикається з проблемою, вона може вплинути на інші інтегровані рівні — компроміс, властивий переходу до модульності;
Виконання перехресного зведення: у модульному блокчейні виконання перехресного зведення має вирішальне значення для досягнення сумісності модульного блокчейну. Відсутність стандартизованих протоколів перешкоджає бездоганній інтеграції між різними модулями. Крім того, для досягнення справжньої масштабованості модульних блокчейнів необхідно вирішити проблеми асинхронного виконання, властиві шардингу;
Централізація: хоча децентралізація Rollup може бути не такою критичною, як децентралізація L1, вона все одно є важливою проблемою безпеки. Децентралізація необхідна для забезпечення життєздатності, протистояння цензурі та уникнення монополістичних переваг. Протокол активно працює над вирішенням цих проблем за допомогою таких рішень, як упорядники сегментів, абстрактний шаблонний код і надання бізнес-логіки лише розробникам ланцюжків. Прийняття цих рішень може допомогти вирішити проблеми виконання перехресного зведення.
Вивчаючи дві вищезгадані частини, стає зрозуміло, що модульні та монолітні блокчейни представляють продукти різних епох, втілюють компроміси в неможливому трикутнику та відображають різні філософські рішення.
Протягом багатьох років криптопростір застряг у циклі монолітних блокчейнів, з кожним новим L1, що будує закриту систему, що викликає інтенсивну конкуренцію з нульовою сумою. Таке середовище часто призводить до екстремізму, оскільки платформи конкурують за користувачів у своїх екосистемах.
Поява модульного блокчейну запроваджує спільний та інклюзивний підхід, який наголошує на співпраці та взаємозв’язку між різними ланцюгами – позитивний розвиток для всієї галузі. Спільний підхід дозволяє модулям бездоганно працювати разом, підвищуючи загальну функціональність і покращуючи досвід користувача.
Крім того, спільна природа модульного блокчейну полегшує розробку інноваційних та спеціалізованих модулів. Співпраця та спільне використання ресурсів між різними ланцюжками дозволяє розробникам зосередитися на конкретних сферах знань, у результаті створюючи індивідуальні високоякісні модулі, які підходять для конкретних випадків використання. Крім того, відриви від монолітного ланцюга можна від’єднати та послідовно об’єднати в модульні рівні.
Вкрай важливо, щоб модульні блокчейни та монолітні блокчейни не розглядалися як змагальні, а скоріше як взаємодоповнюючі. Вони вчаться на сильних і слабких сторонах один одного і разом розвиваються. Межі між ними можуть бути неочевидними, оскільки модульні ланцюги можуть діяти як проміжне програмне забезпечення для монолітних ланцюгів, тоді як монолітні ланцюги можуть діяти як окремі рівні модульних ланцюгів.
Замість того, щоб зосереджуватися на категоричних відмінностях, слід зосередитися на розвитку відкритої мережі, впровадженні ключових інновацій і досягненні широкого консенсусу.
Додаток:
Вступ до формату повідомлень перехресного консенсусу (XCM) · Polkadot Wiki
Polkadot: основа нового Інтернету | Джек Платтс | Мережа Polkadot | Середній
Субстрат — стек технологій Web3
Пейзаж стеку OP | ON Stack Docs
OpenGov: що таке Polkadot Gov2 | Мережа Moonbeam
NEARCON 2023 | Етап рівня 2 — день 2 — YouTube
Дорожня карта Ethereum | ethereum.org
Архітектура Stateless проти Stateless: Чому Stateless перемогла | Віртасант
NEAR—Операція блокчейном | НЕАР Документація
Постачальники впровадження Polygon CDK
Ландшафт стека OP