Вступ

Цей короткий допис опише конкретні компроміси:

• L1s проти L2s
• Зведення проти інтегрованого
• Спеціальна програма проти загального призначення

Нам потрібно краще розуміти, які архітектури будувати і коли. Інакше ми продовжуватимемо отримувати мішанину заплутаної інфраструктури, яку жоден користувач не зможе зрозуміти або взаємодіяти з нею. Це найпоширеніша помилка, яку я бачу:

Як зазначено у вступній публікації Eclipse перед майбутнім запуском основної мережі:

Часто існує хибна дихотомія між модульним баченням згортання та можливістю мати єдиний ланцюг із великим масштабом, розпаралеленим виконанням і спільним станом. «Модульний» часто плутають із «специфічним для програми», що змусить вас повірити, що зведені означають світ багатьох фрагментованих і низькопродуктивних ланцюжків. Ми оскаржуємо цю ідею.

Зведення та L2 – непоганий UX. Фрагментовані зведення та L2 є поганим UX. Правильно розроблені зведення та L2 мають покращити UX.

Зведені версії проти інтегрованих

Усі ланцюги можуть зрештою прийняти найкращу технологію (наприклад, DAS + ZK), якщо вона виявиться корисною. Як обговорювалося в моїй останній доповіді Чи зведені пакети успадковують безпеку? різниця, яку ми залишимо, приблизно така:

• «Зведення» aka «Модульний» — створюйте логічно окремі ланцюжки, які надсилають дані до свого ланцюжка хостів (рівень DA). Вони повторно використовують консенсус хост-ланцюга.
• «Інтегрований» aka «Монолітний» — інтегруйте все в один протокол із власним консенсусом. Не надсилайте дані в окремий ланцюжок хостів. (Навіть якщо рівень DA і рівень виконання є в певному сенсі логічно окремими частинами спільного протоколу).

Solana та Eclipse представляють паралельні шляхи, як показано в Syncracy's Solana Thesis:

Як я обговорював у моєму нещодавньому епізоді Uncommon Core з Hasu, обидва підходи матимуть довгострокову цінність.

Солана використовує підхід, що об’єднує все в один консенсус. Він прагне до мінімальної затримки (зараз середній час слотів становить ~400-500 мс із надією досягти 200 мс у майбутньому), зберігаючи при цьому великий набір валідаторів (~2000). Це неймовірне досягнення вимагало кількох технічних проривів.

Однак ці дві цілі (максимальна децентралізація + мінімальна затримка) за своєю суттю є суперечливими. Це неймовірно складно підтримувати стабільність цього консенсусного набору під час роботи на максимальній швидкості та пропускній здатності. У TowerBFT немає офіційного аналізу безпеки чи живучості, і незрозуміло, чи є підтвердження історії наразі корисним і стійким у змагальній моделі чи його можна просто видалити. Економіка системи з низькою затримкою також, звичайно, збільшує стимул до централізації.

Eclipse використовує підхід консенсусу відокремлення. Зведені пакети можуть мати менший підібраний вручну набір секвенсорів (потенційно навіть керований одним оператором) для роботи в контрольованому середовищі. Це може ще більше підвищити надійність і зменшити затримку, пропонуючи продукт Web2 з перевагами крипторейків. Платіжний додаток Code, який розгорнуто як щось на кшталт L2 на Solana з використанням довговічних одноразових кодів, схожий у своєму прагненні до миттєвих і надійних платежів. Окрім чудового UX майже миттєвої затримки, ще більше просування нижньої межі також необхідне для високоцінних фінансових програм із низькою затримкою.

Потім зведені дані можуть публікувати в іншому децентралізованому консенсусному наборі для більш надійної перевірки за повільніший часовий масштаб. Наприклад, Celestia має 15-секундний час блокування з однослотовою остаточністю, що насправді навіть не так сильно відрізняється від Solana! Solana має підтвердження ~400 мс, потім остаточність досягається через 32 слоти (~12,8 с).

Тут немає безкоштовного обіду. Існує потенційний компроміс між властивостями набору валідаторів у реальному часі (наприклад, Solana має набагато більше валідаторів, ніж зведені секвенсори) порівняно з наданими гарантіями (наприклад, контрольоване стійке середовище, ще менша затримка тощо). Належний рівень зобов’язань (і в якому часовому масштабі) є спектром. Залишаються відкриті інженерні питання, і найкращий варіант, ймовірно, буде відрізнятися залежно від випадку використання. Само собою зрозуміло, що вартість тут також важлива, тому знадобляться масштабовані рівні DA, такі як Celestia (який використовує Eclipse).

Eclipse, очевидно, не замінить Солану. Кожен робить різні компроміси та переслідує інший ринок. Solana залишається серцем і душею розробки SVM, і в результаті, ймовірно, там буде розгорнуто багато нових програм. Однак зрозуміло, що в довгостроковій перспективі буде більше одного ланцюжка SVM (Pyth вже є). Майбутнє не за одноланцюжком, а SVM — це просто дивовижна технологія. Eclipse започатковує цю тенденцію експорту в L2, але я очікую, що інші усвідомлять цінність тут і наслідуватимуть їхній приклад.

L1 проти L2

Я використовую тут L1 і L2 у більш популярному сенсі, щоб включити зведення, валідіуми тощо. Як описано в Віталікові різні типи шару 2:

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

Що відрізняє L1 від L2, так це те, як він працює з вилками. Валідіум буде повертатися, якщо його L1 повертає блок, і він буде хард-форк, якщо його базовий рівень хард-форк. Щоб оновити L2, певна форма управління L2 повинна існувати на L1 як перехідний контракт, який буде зрозумілий для L1.

Тепер, навіщо нам використовувати таку річ? Чи є сенс для ланцюга делегувати свій вибір форк-вибору базовому L1 і розташовуватися навколо свого мосту там?

Незважаючи на поширену думку про те, що війни L1 закінчилися, Ethereum переміг, і всі конкуренти Ethereum хочуть зараз стати L2 – Ethereum L2 не є найкращим рішенням для всіх мереж.

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

Аргумент про те, що всі ланцюжки повинні розгортатися як Ethereum L2 для власної безпеки, найчастіше є невірним. Швидше, основною перевагою L2 була можливість використовувати мережеві ефекти Ethereum (користувачі, ліквідність, розробники, інструменти тощо). Це стратегія виходу на ринок.

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

Однак увага, отримана від L2, слабшає. Список поточних і майбутніх Ethereum L2 зараз надто довгий, щоб будь-хто міг його стежити. Ланцюги, що повертаються до L2, не привертають увагу, ніж перші рушії (наприклад, Optimism і Arbitrum). Навіть потік довгоочікуваних zkEVM намагається залучити користувачів, програми та цінність.

Отже, бути лише L2 більше не гарантує увагу всіх. Однак він все ще може запропонувати перевагу продукту порівняно з окремими мережами, якщо ви можете привернути увагу іншим способом. Наприклад, перетворення пірамідної схеми на квадратну може залучити ~700 мм доларів у мультисиг без L2. Крім того, ви можете створити першу SVM L2 Ethereum.

Припускаючи, що у вас є продукт, який привертає увагу, давайте тепер розглянемо, як бути L2 може допомогти ланцюжку отримати доступ до бази користувачів Ethereum і запропонувати кращий досвід роботи з продуктом. Це буде досягнуто в першу чергу шляхом використання рідних активів Ethereum (наприклад, ETH) у сприятливий спосіб (наприклад, мости з привабливою безпекою та/або UX).

Цінність цього в основному залежить від двох основних припущень:

1. Те, що існуючі активи Ethereum є важливими для даного випадку використання (наприклад, DeFi залежить від ETH)

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

Дивлячись вперед на галузевому рівні, головне питання тут полягає в тому, яким буде нове та цінне державне створення криптовалюти в майбутньому?

• Якщо цей майбутній стан все більше відмежовується від поточного рідного стану Ethereum (наприклад, унікальний новий стан, RWA тощо), тоді привабливість L2 може бути зменшена.
• Якщо цей майбутній стан значною мірою залежить від поточного рідного стану Ethereum (наприклад, торгівля ETH), тоді L2 можуть відігравати помітну роль.

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

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

Наприклад, часто згадувані «гарантії розрахунків» Ethereum мало що значать для активів реального світу (RWA), таких як стейблкойни (наприклад, USDC) або токенізовані казначейські векселі. Вони «розраховані», коли емітент (наприклад, Circle) вважає їх такими.

У цьому сценарії перевага Ethereum L2 може зменшитися як частка програм. Нова платіжна програма на основі USDC за своєю суттю не має значення, Ethereum L2 чи ні. Вони просто хочуть найдешевшу, найшвидшу та найнадійнішу інфраструктуру, яка дозволить їм пропонувати користувачам найкращий досвід роботи з продуктами.

Створення нової держави історично було перешкодою для Солани, хоча ми чітко бачимо, як вітер тут змінюється. Багато відомих проектів DeFi та інфраструктурних проектів на Solana зараз запускають токени, і їх буде більше. Це запускає маховик Солани.

2. Що кращі мости Ethereum ←→ L2 перед мостами Ethereum ←→ L1 (наприклад, через міркування безпеки та/або UX)

Припустімо, що перше припущення справді виконано для даного випадку використання (тобто нативний Ethereum є досить цінним для вашої програми). Тоді нам потрібно запитати, чи може L2 виставити ці активи більш сприятливо, ніж окремий L1. Припустимо, у користувача є трохи ETH і він хоче обміняти його на USDC. Куди вони йдуть?

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

Це можна порівняти з класичним мостом консенсусу-верифікатора (наприклад, IBC). На практиці в таких сценаріях не було серйозних збоїв кворуму валідатора. Збої мостів, як правило, відбуваються через зломи та/або скомпрометовані мультипідписи мосту (до яких L2 однаково чутливі).

Хоча покращення безпеки тут для мене менш переконливі, на мою думку, зручний доступ до користувачів і активів Ethereum є основною перевагою мосту L2 сьогодні. Зведені програми, такі як Base, Optimism і Arbitrum, більше нагадують розширення Ethereum. Користувачі зберігають однакові гаманці та адреси, рідний токен газу є єдиною канонічною версією ETH, ETH домінує в DeFi, наприклад, у всіх торгових парах, соціальні програми оцінюють NFT в ETH і платять творцям в ETH (наприклад, friend.tech), відкладення в L2 відбуваються миттєво (оскільки вони будуть реорганізовуватися разом) тощо.

Від користувачів не можна очікувати, що вони будуть міркувати, через який міст використовувати, аналізувати різні припущення щодо безпеки, отримувати один із кількох доступних загорнутих токенів, отримувати власний токен ланцюга для газу тощо. Вони просто хочуть поєднати свій ETH, отримати ETH з іншого боку та продовжувати використовувати L2, як вони б використовували Ethereum або будь-який інший L2. Ось чому Eclipse просто використовуватиме ETH як рідний токен для газу. Примусове введення нового токена газу шкодить UX.

Отже, чому Solana не може просто надати ті ж переваги, що й Ethereum L2? Насправді це стає більше інженерним питанням, ніж чимось фундаментальним, і з часом це стане легше. Це вірно для токенів газу, а також інших викликів UX, пов’язаних із простою невикористанням EVM (що не властиво L1 проти L2):

• Газовий токен – платежі за газ можна відволікати від користувачів, дозволяючи користувачам платити будь-яким газовим жетоном, який вони виберуть.
• Перехідний зв’язок. Перехідний зв’язок, ймовірно, з часом посилиться та стандартизується, що призведе до меншої плутанини з боку користувачів і фрагментації ліквідності.
• Гаманці – нещодавно оприлюднені Snaps від MetaMask розширюють підтримку MetaMask до ланцюжків, які не належать до EVM, за допомогою сторонніх інтеграцій, створених поверх, наприклад, через Drift або MetaMask Snaps від Solflare.
• Досвід розробника - мовні бар'єри будуть зруйновані. Такі проекти, як Solang і Neon, можуть допомогти розробникам Solidity будувати на Solana, а такі проекти, як Stylus, можуть допомогти розробникам Rust будувати на Arbitrum.

У майбутньому навіть стане можливим, щоб ETH відігравав певну роль у Solana DeFi, якби користувачі висловили сильні переваги ETH через швидкість і масштаб Solana. На практиці набагато більш імовірно, що ці користувачі з рідними активами Ethereum продовжуватимуть використовувати їх в екосистемі Ethereum L2 з причин, які ми обговорювали, припускаючи, що вони мають доступ до порівняно масштабованих L2.

Спеціальна програма проти загального призначення

Незалежно від того, чи є ланцюг L1 чи L2, існує очевидна потреба збільшити пропускну здатність одного ланцюга шляхом масштабування виконання. Зведення не повинно означати фрагментацію. Об’єднання багатьох однорідних ланцюжків під одним спільним секвенсором із збереженням стану просто виглядає як один паралелізований ланцюжок з точки зору масштабування з більш складним UX.

Ми часто бачимо , що «виділений блоковий простір» вказується як причина розгортання зведеного пакета для конкретної програми. Однак це помилкове уявлення здебільшого виникло через непотрібні обмеження однопотокової EVM на глобальних ринках комісій. Паралельний SVM із місцевими ринками зборів значно зменшує потребу в ланцюжках програм. Розміщення більшої кількості програм на спільній інфраструктурі суттєво зменшує складність для розробників і користувачів. Перехресний UX і складність розробника в багатоланцюжному світі є недооціненим екзистенційним ризиком.

Це не означає, що в кінці дня буде буквально один ланцюжок. Я бачу чотири аргументи для розгортання власного ланцюга:

1. Масштабованість і виділений блоковий простір - як згадувалося вище, це зазвичай непереконливо. Один монетний двір NFT не повинен фактично закрити решту ланцюга, але відповідь, як правило, полягає не в створенні іншого ланцюга. Це полегшується паралельною віртуальною машиною з місцевими ринками зборів. Оскільки пропускна здатність усієї мережі насичена, місцеві ринки плати не допоможуть (тобто плата за спільний ланцюг зростатиме у всьому світі). Тоді вам знадобиться інший ланцюжок.
2. Суверенітет. Управління в криптовалюті все ще досить погане, і наявність власного ланцюга для розгалуження може бути корисним механізмом координації. Моя інтуїція свідчить, що це дуже рідкісна обставина, але важко сказати з упевненістю. Це відповідає зацікавленості MakerDAO у ланцюжку програм.
3. Настроюваність – налаштування на рівні консенсусу можуть бути цінними для певних додатків (наприклад, dYdX v4), але на сьогоднішній день таких випадків емпірично небагато і вони поодинокі. Навіть dYdX, яскравий приклад ланцюга додатків, «ймовірно, буде більше рухатися до узагальненого виконання в ланцюжку dYdX», як сказав Антоніо в його останньому епізоді Bell Curve. Потреба в настроюваності повного стека, яку неможливо вирішити на спільному ланцюжку, зазвичай відсутня для більшості криптовалют. Майже всі нові зведені пакети продовжують залишатися просто форками EVM із новими токенами.
4. Value Capture – можливо, це підмножина настроюваності, але вона дуже важлива, тому ми її розділимо. Це може бути складніше засвоїти цінність спільної інфраструктури, яка створена не лише для вашої програми. Ланцюжки програм можуть спростити розподіл цінності для відповідальних програм. Однак це більше, ніж фундаментальна інженерна робота, і в Solana тривають дослідження щодо того, як це зробити. Крім того, зауважте, що розгортання власного ланцюга потребує серйозних накладних витрат порівняно з витратами на амортизацію спільної інфраструктури.

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

Запуск власної мережі сьогодні приносить болючі та непотрібні компроміси (складність, вартість, гірший UX, фрагментована ліквідність тощо), які більшість програм не можуть виправдати для додаткових переваг. Інфраструктура, необхідна для конкурентоспроможності UX, здається далекою. Це не означає, що немає жодних причин для існування ланцюжків додатків (безумовно, є). Швидше, ми просто сильно переіндексували в цьому напрямку наратив як індустрію, тому нинішня тенденція до повторного об’єднання явно вигідна, враховуючи поточний стан.

Висновок

Останніми місяцями Солана по праву набрав значних обертів. Ця різка корекція значною мірою була визнанням поточного стану багатоланцюжкового UX - він фрагментований і болючий. UX використання програм Solana просто неймовірний. Плавно і швидко.

Зведення та L2 отримали погану репутацію для UX, але справжня проблема полягає у фрагментації. Ми асоціюємо зведення та L2 з фрагментованим горизонтальним масштабуванням, оскільки на практиці більшість із них розгалужують EVM як є та використовують обмежену пропускну здатність DA. Вони виявляються дорогими та незручними у використанні.

Однак це не принципово. Вертикальне масштабування за допомогою потужної віртуальної машини на масштабованому рівні DA вирішує ці проблеми UX і витрати. Ймовірно, відбудеться певний рівень повторного об’єднання стека для L1 і L2. L2 та зведені пакети мають покращити UX, якщо їх правильно використовувати. Це має бути їхня справжня перевага.

Обидва підходи мають свої переваги. Нам просто потрібно краще попрацювати, спершу запитавши себе «на який ринок спрямований цей продукт?» і «як ця архітектура може вирішити те, що мені потрібно?» перш ніж ми почнемо будувати наступні L1, L2, L3…

Відмова від відповідальності:

1. Цю статтю передруковано з [dba]. Усі авторські права належать оригінальному автору [Jon Charbonneau]. Якщо є заперечення щодо цього передруку, будь ласка, зв’яжіться з командою Gate Learn , і вони негайно розглянуть це.
2. Відмова від відповідальності: погляди та думки, висловлені в цій статті, належать виключно автору та не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено вище, копіювання, розповсюдження або плагіат перекладених статей заборонено.