Eclipse Mainnet — це універсальний рівень 2, який поєднує найкращі частини модульної архітектури:
Рівень розрахунків: Ethereum - Eclipse розраховуватиметься з Ethereum (тобто міст перевірки буде на Ethereum) і використовуватиме ETH як свій маркер газу.
Рівень виконання: віртуальна машина Solana (SVM) – Eclipse запускатиме високопродуктивну SVM як середовище виконання.
Доступність даних: Celestia - Eclipse публікуватиме свої дані в Celestia для масштабованої доступності даних (DA).
Доказ: RISC Zero - Eclipse використовуватиме RISC Zero для доказів шахрайства з нульовим знанням (без необхідності серіалізації проміжного стану!)
Більшість основних моментів Eclipse стосувалися розгортання зведених програм для різних проектів, але зараз як ніколи зрозуміло, що Ethereum потребує універсального рівня 2, який може досягти справжнього масштабу. Більшість додатків не отримають переваги від налаштування ланцюжків для окремих додатків, і результуюча ізоляція та складність можуть фактично призвести до погіршення взаємодії з користувачем і розробником.
Часто існує хибна дихотомія між баченням модульних зведень і можливістю мати єдиний ланцюжок із масовим масштабуванням, паралельним виконанням і спільним станом. «Модульний» часто плутають із «спеціальним додатком», що змушує думати, що зведення означає світ багатьох фрагментованих і низькопропускних ланцюжків.
Рівень виконання: швидкість і масштаб Solana
Eclipse Mainnet використовуватиме найкраще в своєму класі середовище виконання, схоже на Solana. Це дає величезні переваги:
Оптимізоване паралельне виконання
SVM і його середовище виконання Sealevel відомі своєю підтримкою паралельного виконання транзакцій. Транзакції, які не торкаються перекриваються станів, можуть виконуватися паралельно, а не послідовно.
Це дозволяє SVM масштабуватися безпосередньо за допомогою апаратного забезпечення, оскільки процесор продовжує додавати більше ядер за нижчих витрат. Однопотокові середовища виконання (наприклад, сьогоднішня EVM) за своєю суттю не отримують переваг від нижчої вартості ядра. Протягом останнього десятиліття або близько того однопотокові покращення продуктивності постійно зменшувалися. Майже всі покращення все ще походять від збільшення кількості ядер, тому дуже важливо скористатися цією тенденцією для розпаралелювання робочого навантаження:
Хоча було кілька дуже ранніх спроб розпаралелити EVM, його додавання при збереженні сумісності пов’язане з фундаментальними компромісами, включаючи неоптимальну продуктивність без усунення інших вузьких місць (таких як зростання стану). Контракти, які заздалегідь оголошують залежності стану (як у SVM), досягають оптимального розпаралелювання.
Рідний платний ринок
Більшість ринків комісії сьогодні є глобальними, тобто одна популярна програма збільшить комісії для всіх користувачів мережі. Одне карбування NFT не повинно зробити весь ланцюжок марним для всього іншого. Дивовижна робота Солани над власним ринком комісій вирішує цю проблему конкуренції щодо стану між програмами. У своїй поточній реалізації планувальник надає пріоритет транзакціям без конфліктів, дозволяючи безконфліктним транзакціям виконуватися за нижчу плату. У довгостроковій перспективі власні ринки зборів будуть реалізовані на рівні протоколу. Це гарантує, що стрибки комісії за одну заявку не вплинуть на інші ланки ланцюга.
Рідний ринок плати отримує переваги від унікального паралелізованого середовища виконання Solana. Спроба запровадити власний ринок плати для державних гарячих точок у EVM за допомогою евристики (тобто не оголошувати державний доступ завчасно) призведе до неефективності та можливих векторів атак.
Також проводяться ранні дослідження, щоб додатки могли легко інтерналізувати значення, властиві самій програмі, що сьогодні часто вимагає більшої креативності в дизайні на рівні програми.
Управління зростанням держави
Ще до того, як послідовне виконання EVM стане вузьким місцем, зростання стану є його більш актуальним вузьким місцем.
Оскільки штати не мають дерев Merkle, Solana не вводить накладні витрати на оновлення дерева Merkle для кожного оновлення штату. Натомість після кожної епохи (2,5 дня) весь стан архівується. Це дешевше, ніж живе архівування (як у EVM).
Що ще важливіше, EVM має динамічний доступ до облікового запису (тобто транзакції можуть торкатися будь-якого стану на вимогу). Цей динамічний пошук стану означає, що стан не можна завантажити в пам'ять перед виконанням. У SVM кожна транзакція визначає всі стани, необхідні для виконання.
Тому розмір стану не впливає на виконання SVM. Якщо припустити, що валідатори оновлюють свої диски зберігання кожні два роки, мережа може безпечно подвоїти розмір знімка кожні два роки, не стикаючись з серйозними проблемами.
Крім того, такі команди, як Helius, активно покращують доступність історичних даних і зменшують розмір стану за допомогою стиснення.
Сумісність з EVM
Neon EVM — це смарт-контракт віртуальної машини Ethereum, який можна розгорнути в будь-якому ланцюжку SVM. Це забезпечує повну сумісність EVM (включно з підтримкою байт-коду EVM і Ethereum JSON-RPC) у Eclipse Mainnet із більшою пропускною здатністю, ніж однопотокова EVM. Оскільки кожен екземпляр Neon EVM має свій власний ринок комісій, додатки можуть просто розгортати власні контракти, щоб скористатися перевагами ланцюжка додатків, не порушуючи UX, безпеку чи ліквідність.
Крім того, компілятор Solang може компілювати код смарт-контракту Solidity у байт-код SVM.
Знімки MetaMask
Історично спонукання користувачів EVM використовувати ланцюжки, що не належать до EVM, було значною перешкодою, але нещодавно анонсовані MetaMask Snaps подолають цей бар’єр. Користувачі EVM можуть продовжувати використовувати MetaMask, не змінюючи гаманці. Завдяки внеску Drift з відкритим кодом у створення чудової реалізації MetaMask Snaps, досвід подібний до взаємодії з будь-яким ланцюжком EVM. Користувачі Eclipse Mainnet зможуть взаємодіяти з програмами безпосередньо в MetaMask або використовувати рідні гаманці Solana, такі як Salmon.
Firedancer
Firedancer — довгоочікуваний клієнт Solana, який розробляє Jump і призначений для значного підвищення пропускної здатності, відмовостійкості та ефективності мережі. Під час запуску ми будемо якомога ближче до основного клієнта Solana, але ми плануємо прийняти Firedancer, коли код стане активним і стабільним.
безпека
Solana працює зі значно зменшеною поверхнею атаки, запобігаючи атакам повторного входу, які ми бачили занадто багато разів. Зокрема, середовище виконання Solana дозволяє лише саморекурсію програм і не дозволяє довільні повторні міжпрограмні виклики. Крім того, розділення стану та коду призводить до коду без стану, який, як правило, легше ефективно перевірити.
Простіший доказ
SVM базується на реєстрі, а набір інструкцій набагато менший, ніж у EVM, що полегшує перевірку виконання SVM у ZK. Для оптимістичних зведень дизайн на основі реєстру дозволяє спростити контрольні точки.
Розрахунковий рівень: безпека та ліквідність на Ethereum
Як і сьогоднішнє велике зведення, Eclipse Mainnet буде розраховуватися за допомогою Ethereum. Зокрема, це означає, що наш міст перевірки на Ethereum буде інтегровано безпосередньо в Eclipse. Вузол Eclipse розглядатиме цей міст, щоб визначити «канонічний ланцюг». Цей міст забезпечує правильне впорядкування для Eclipse.
Це дозволяє нашим користувачам отримувати певні властивості безпеки від Ethereum. Міст перевірятиме всі транзакції Eclipse і запобігатиме введенню недійсних станів. Крім того, це забезпечить остаточну живучість і стійкість до цензури в деяких випадках збою. Навіть якщо замовник L2 припинить роботу або почне цензуру, користувачі зможуть примусово включити свої транзакції через міст.
Завдяки цим властивостям безпеки дієві й оптимальні бібліотеки часто називають «Ethereum L2». L2BEAT визначає L2 як «ланцюжок, який повністю або частково отримує безпеку від Ethereum Layer 1, тому користувачам не потрібно покладатися на чесність валідаторів L2, щоб зберегти кошти».
Розрахунок Ethereum відображає важливість власних активів Ethereum в економіці DeFi та NFT Eclipse Mainnet. ETH є найкращою децентралізованою валютою для більшості користувачів, тому ми також будемо використовувати ETH як наш маркер газу. У довгостроковій перспективі абстракція комісії дозволить користувачам платити будь-яким токеном на свій вибір (наприклад, USDC). Наразі Eclipse Mainnet не планує випускати власні токени.
Доступність даних: пропускна здатність Celestia та можливість перевірки
Eclipse Mainnet використовуватиме Celestia для доступності даних (також відомого як публікація даних або публікація даних). Celestia є довгостроковим екосистемним партнером Eclipse.
Цільова пропускна здатність Eclipse Mainnet і комісії, на жаль, не підтримуються поточними обмеженнями пропускної здатності Ethereum. Це справедливо навіть після EIP-4844 (він же «Proto-danksharding»), який надає ~0,375 МБ простору blob-областей на блок (з обмеженням на блок ~0,75 МБ).
Для передачі ERC-20 із базовим стисненням (~154 байти на транзакцію) це дорівнює ~213 TPS для всіх зведених пакетів.
Для стислих обмінів (~400 байт на транзакцію) це дорівнює ~82 TPS у сукупності.
Для порівняння, Celestia випустить блоки розміром 2 МБ до кінця цього року. Очікується, що коли достатня кількість легких вузлів вибірки доступності даних (DAS) стане онлайн і мережа стане стабільною, очікується, що незабаром після запуску простір blob збільшиться до 8 МБ. Світловий вузол DAS виконує дві ключові функції:
Дозволяє користувачам самостійно перевіряти, чи доступні блокові дані Eclipse;
Допомагає безпечно масштабувати всю мережу, оскільки, оскільки більше вузлів DAS підключаються до мережі, рівень DA може безпечно збільшити свою пропускну здатність.
Очікується, що Celestia стане першим рівнем DA, який увімкне DAS у виробництві. Це відрізняється від традиційних комітетів доступності даних (DAC), які знову вводять припущення про чесність комітету без перевірки користувача (подібно до існуючих монолітних блокчейнів).
Існують невід’ємні припущення щодо безпеки для користувачів, які передають кошти з основної мережі Ethereum до будь-якого ланцюга за допомогою DA поза ланцюгом. Зокрема, валідатори Celestia можуть технічно відхиляти дані транзакцій, але стверджувати, що дані доступні на мосту Ethereum. Фактично, консенсус Celestia щодо підтвердження частки означає, що приховування даних самою Celestia карається, що змушує нас вважати цей ризик нереальним.
Загалом, підтримка легких вузлів DAS Celestia, властивості криптоекономічної безпеки та високомасштабована пропускна здатність DA з першого дня роблять це очевидним вибором для Eclipse Mainnet сьогодні.
Ми також маємо намір стежити за прогресом Ethereum у масштабуванні DA після EIP-4844. З’являються захоплюючі нові дослідження, які можуть забезпечити високу пропускну здатність DA раніше, ніж вважалося раніше (останнє використовує більш просунуті розподілені хеш-таблиці). Якщо Ethereum забезпечить більший масштаб для наших користувачів, ми оцінимо можливість переходу на Ethereum DA.
Доказ: захист від шахрайства RISC Zero ZK (серіалізація проміжного стану не потрібна!)
Наш доказ буде схожий на SIMD, розроблений Анатолієм для захисту від шахрайства SVM, який сам по собі схожий на думку Джона Адлера про те, що серіалізація стану дорога і що її можна уникнути.
Зокрема, ми хочемо уникнути повторного впровадження дерев Merkle у SVM. Ми намагалися вставити розріджене дерево Merkle після кожної транзакції в SVM, але оновлення дерева Merkle призвело до значної втрати продуктивності. Відмова від використання дерев Merkle виключає існуючі фреймворки зведення загального призначення (такі як стек OP) як основу для зведення SVM, а також вимагає більш креативних архітектур, стійких до збоїв.
Коротше кажучи, доказ відмови вимагає:
Зобов'язання щодо введення транзакцій,
сама транзакція, і
Доведіть, що повторне виконання транзакції призводить до іншого результату, ніж той, що вказаний у ланцюжку.
Вхідні зобов’язання зазвичай виконуються шляхом надання кореня Merkle дерева стану зведення. Наш виконавець опублікує список вхідних і вихідних даних (включно з хешами облікового запису та пов’язаним глобальним станом) для кожної транзакції, а також індекс транзакції, яка створила кожен вхід. Транзакції публікуються на Celestia, тому будь-який повний вузол може самостійно витягти обліковий запис у власному стані, обчислити вихідний обліковий запис і підтвердити правильність зобов’язань щодо Ethereum.
Можливі два основних типи несправностей:
Помилка виводу – у цьому випадку верифікатор надає в ланцюжку нульовий доказ правильності результату виконання SVM. Ми використовуємо RISC Zero для створення доказу виконання SVM із нульовим знанням, яке є продовженням нашого попереднього доказу виконання байт-коду BPF. Це дозволяє нашому розрахунковому контракту забезпечувати коректність без необхідності запускати ці транзакції в самому ланцюжку.
Неправильний вхід – у цьому випадку валідатор публікує посилання на історичні дані в ланцюжку, показуючи, що стан введення не відповідає тому, що було заявлено. Використовуючи Quantum Gravity Bridge від Celestia, наша угода про врегулювання гарантує, що ці історичні дані дійсно доведуть шахрайство.
Ми стоїмо на плечах велетнів. Сьогоднішнє зведення покращило стан досліджень у нашій галузі та надає користувачам Ethereum нижчу комісію, ніж L1.
Однак вони не в повній мірі використовують новітні технології, які вимагають великого масштабу. Неймовірні нещодавні досягнення усунули необхідність робити ці компроміси, які робили попередні зведені пакети, фактично поставивши їх у невигідне становище:
Високопродуктивна паралельна віртуальна машина (така як SVM);
Розширення DA з підтримкою світлового вузла DAS (наприклад, Celestia);
Досягнення в інфраструктурі доказів, що робить її практичною всюди (наприклад, RISC Zero);
Покращена переносимість серед екосистем коду (наприклад, Neon і Solang) і користувачів (наприклад, MetaMask Snaps)
Ми можемо вивчити обмеження, з якими стикаються інші мережі, і вибрати найкращі частини для довгострокового розширення.
Ми часто чуємо розмови про мільйон зведених програм у майбутньому.
Налаштування на рівні консенсусу може бути дуже цінним для певних програм (наприклад, dYdX v4), і ми раді допомогти команді запустити зведення для окремих програм.
Однак такі ситуації трапляються рідко. Ось чому більшість нових зведених пакетів все ще є звичайними форками EVM. Проблеми розробників не будуть вирішені шляхом фрагментації UX між більшою кількістю ланцюжків. Основним варіантом використання мільйонів мереж сьогодні часто здається просто запуск нових монет. Для переважної більшості випадків використання потреби в повному налаштуванні стеку технологій сьогодні не існує.
Навіть якщо реальний попит існує, інфраструктура, необхідна для підтримки багатьох ланцюжків додатків із конкурентоспроможним UX, не буде на місці протягом багатьох років (якщо взагалі). Superchain Optimism (стек OP), Hyperchains zkSync (стек ZK), ланцюг Orbit Arbitrum тощо мають бачення багатьох ланцюгів зі спільною інфраструктурою. Це призначено для забезпечення більш плавного UX для операцій між ланцюжками в одній екосистемі (наприклад, між двома ланцюжками в межах Superchain), а не для повністю ізольованих ланцюжків (наприклад, між Ethereum і Solana).
Проте нинішні плани (якщо вони існують) далекі від обіцянок конкурувати з єдиною спільною державою. Крім того, вони не вирішують проблеми сумісності між екосистемами (наприклад, від суперланцюга до гіперланцюга). Модульність будівництва не повинна означати будівництво силосів.
Користувачам складніше вести облікові записи в багатьох мережах. Постійне перетинання ланцюжків і хвилювання про необхідні токени газу є гіршим для користувача. Покладатися на постачальників інфраструктури для роботи та підтримки такої кількості мереж також складніше та дорожче.
Ми завжди захоплювалися простотою бачення Солани. Високооптимізований спільний кінцевий автомат із масштабом для підтримки найцінніших випадків використання. Це часто вважають несумісним із дорожніми картами, орієнтованими на зведення, але насправді це не так. Ми хотіли поєднати найкраще з обох світів.
Це непорозуміння пов’язане з тим, що сьогоднішні зведені пакети здебільшого запускають оригінальну однопотокову EVM, яка майже не змінилася, щоб скористатися перевагами ранніх мережевих ефектів. Тому ми часто бачимо «приватний простір блоку» як причину розгортання зведених програм для окремих програм. Ціни на інші програми у вашій мережі не повинні підвищуватися через божевільне карбування NFT, але відповідь полягає не в тому, щоб створити власну мережу. Ви йдете на болісні та непотрібні компроміси (складність, вартість, погіршення взаємодії з користувачем, фрагментована ліквідність тощо). Найкраще рішення зрозуміло — просто використовуйте паралельну віртуальну машину з власним платним ринком для державних хот-спотів. Це саме те, що приносить SVM.
Ethereum є інтелектуальним, соціальним та економічним центром криптовалюти. Її ахіллесовою п’ятою завжди була експансія. Розширення доступності даних ще триває, і існуючі середовища виконання L2 не можуть конкурувати з новими інноваціями, такими як SVM. Ми стурбовані тим, що якщо сьогоднішній статус-кво збережеться, екосистема Ethereum буде застигнута зненацька у разі різкого зростання активності. Однопотокові EVM і обмежена доступність даних можуть швидко призвести до відродження високих витрат, тільки цього разу через зведення.
Ми вважаємо, що Eclipse Mainnet є очевидним рішенням: поєднання продуктивності Solana з безпекою, можливістю перевірки та мережевими ефектами дорожньої карти, орієнтованої на зведення.
Висновок
Краса Ethereum полягає в тому, що він постійно вдосконалюється. Дорожні карти, орієнтовані на зведення, є прикладом цього, делегуючи виконання та інновації вільному ринку. L2 має дивовижну здатність використовувати мережеві ефекти Ethereum і гарантії розрахунків, експериментуючи з найкращими новими середовищами виконання. Eclipse Mainnet є природною реалізацією цього бачення.
Якби колись з’явився більш продуктивний рівень виконання, ми були б дуже раді побачити його розгортання як конкурентоспроможний Ethereum L2. До того часу SVM залишається стандартом.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Eclipse Mainnet: модульна Layer 2 із захищеністю Ethereum і швидкістю Solana, яка спирається на сильні сторони інших
Автор: Eclipse
Упорядник: Deep Wave TechFlow
Eclipse Mainnet — це універсальний рівень 2, який поєднує найкращі частини модульної архітектури:
Більшість основних моментів Eclipse стосувалися розгортання зведених програм для різних проектів, але зараз як ніколи зрозуміло, що Ethereum потребує універсального рівня 2, який може досягти справжнього масштабу. Більшість додатків не отримають переваги від налаштування ланцюжків для окремих додатків, і результуюча ізоляція та складність можуть фактично призвести до погіршення взаємодії з користувачем і розробником.
Часто існує хибна дихотомія між баченням модульних зведень і можливістю мати єдиний ланцюжок із масовим масштабуванням, паралельним виконанням і спільним станом. «Модульний» часто плутають із «спеціальним додатком», що змушує думати, що зведення означає світ багатьох фрагментованих і низькопропускних ланцюжків.
Рівень виконання: швидкість і масштаб Solana
Eclipse Mainnet використовуватиме найкраще в своєму класі середовище виконання, схоже на Solana. Це дає величезні переваги:
Оптимізоване паралельне виконання
SVM і його середовище виконання Sealevel відомі своєю підтримкою паралельного виконання транзакцій. Транзакції, які не торкаються перекриваються станів, можуть виконуватися паралельно, а не послідовно.
Це дозволяє SVM масштабуватися безпосередньо за допомогою апаратного забезпечення, оскільки процесор продовжує додавати більше ядер за нижчих витрат. Однопотокові середовища виконання (наприклад, сьогоднішня EVM) за своєю суттю не отримують переваг від нижчої вартості ядра. Протягом останнього десятиліття або близько того однопотокові покращення продуктивності постійно зменшувалися. Майже всі покращення все ще походять від збільшення кількості ядер, тому дуже важливо скористатися цією тенденцією для розпаралелювання робочого навантаження:
Хоча було кілька дуже ранніх спроб розпаралелити EVM, його додавання при збереженні сумісності пов’язане з фундаментальними компромісами, включаючи неоптимальну продуктивність без усунення інших вузьких місць (таких як зростання стану). Контракти, які заздалегідь оголошують залежності стану (як у SVM), досягають оптимального розпаралелювання.
Рідний платний ринок
Більшість ринків комісії сьогодні є глобальними, тобто одна популярна програма збільшить комісії для всіх користувачів мережі. Одне карбування NFT не повинно зробити весь ланцюжок марним для всього іншого. Дивовижна робота Солани над власним ринком комісій вирішує цю проблему конкуренції щодо стану між програмами. У своїй поточній реалізації планувальник надає пріоритет транзакціям без конфліктів, дозволяючи безконфліктним транзакціям виконуватися за нижчу плату. У довгостроковій перспективі власні ринки зборів будуть реалізовані на рівні протоколу. Це гарантує, що стрибки комісії за одну заявку не вплинуть на інші ланки ланцюга.
Рідний ринок плати отримує переваги від унікального паралелізованого середовища виконання Solana. Спроба запровадити власний ринок плати для державних гарячих точок у EVM за допомогою евристики (тобто не оголошувати державний доступ завчасно) призведе до неефективності та можливих векторів атак.
Також проводяться ранні дослідження, щоб додатки могли легко інтерналізувати значення, властиві самій програмі, що сьогодні часто вимагає більшої креативності в дизайні на рівні програми.
Управління зростанням держави
Ще до того, як послідовне виконання EVM стане вузьким місцем, зростання стану є його більш актуальним вузьким місцем.
Оскільки штати не мають дерев Merkle, Solana не вводить накладні витрати на оновлення дерева Merkle для кожного оновлення штату. Натомість після кожної епохи (2,5 дня) весь стан архівується. Це дешевше, ніж живе архівування (як у EVM).
Що ще важливіше, EVM має динамічний доступ до облікового запису (тобто транзакції можуть торкатися будь-якого стану на вимогу). Цей динамічний пошук стану означає, що стан не можна завантажити в пам'ять перед виконанням. У SVM кожна транзакція визначає всі стани, необхідні для виконання.
Тому розмір стану не впливає на виконання SVM. Якщо припустити, що валідатори оновлюють свої диски зберігання кожні два роки, мережа може безпечно подвоїти розмір знімка кожні два роки, не стикаючись з серйозними проблемами.
Крім того, такі команди, як Helius, активно покращують доступність історичних даних і зменшують розмір стану за допомогою стиснення.
Сумісність з EVM
Neon EVM — це смарт-контракт віртуальної машини Ethereum, який можна розгорнути в будь-якому ланцюжку SVM. Це забезпечує повну сумісність EVM (включно з підтримкою байт-коду EVM і Ethereum JSON-RPC) у Eclipse Mainnet із більшою пропускною здатністю, ніж однопотокова EVM. Оскільки кожен екземпляр Neon EVM має свій власний ринок комісій, додатки можуть просто розгортати власні контракти, щоб скористатися перевагами ланцюжка додатків, не порушуючи UX, безпеку чи ліквідність.
Крім того, компілятор Solang може компілювати код смарт-контракту Solidity у байт-код SVM.
Знімки MetaMask
Історично спонукання користувачів EVM використовувати ланцюжки, що не належать до EVM, було значною перешкодою, але нещодавно анонсовані MetaMask Snaps подолають цей бар’єр. Користувачі EVM можуть продовжувати використовувати MetaMask, не змінюючи гаманці. Завдяки внеску Drift з відкритим кодом у створення чудової реалізації MetaMask Snaps, досвід подібний до взаємодії з будь-яким ланцюжком EVM. Користувачі Eclipse Mainnet зможуть взаємодіяти з програмами безпосередньо в MetaMask або використовувати рідні гаманці Solana, такі як Salmon.
Firedancer
Firedancer — довгоочікуваний клієнт Solana, який розробляє Jump і призначений для значного підвищення пропускної здатності, відмовостійкості та ефективності мережі. Під час запуску ми будемо якомога ближче до основного клієнта Solana, але ми плануємо прийняти Firedancer, коли код стане активним і стабільним.
безпека
Solana працює зі значно зменшеною поверхнею атаки, запобігаючи атакам повторного входу, які ми бачили занадто багато разів. Зокрема, середовище виконання Solana дозволяє лише саморекурсію програм і не дозволяє довільні повторні міжпрограмні виклики. Крім того, розділення стану та коду призводить до коду без стану, який, як правило, легше ефективно перевірити.
Простіший доказ
SVM базується на реєстрі, а набір інструкцій набагато менший, ніж у EVM, що полегшує перевірку виконання SVM у ZK. Для оптимістичних зведень дизайн на основі реєстру дозволяє спростити контрольні точки.
Розрахунковий рівень: безпека та ліквідність на Ethereum
Як і сьогоднішнє велике зведення, Eclipse Mainnet буде розраховуватися за допомогою Ethereum. Зокрема, це означає, що наш міст перевірки на Ethereum буде інтегровано безпосередньо в Eclipse. Вузол Eclipse розглядатиме цей міст, щоб визначити «канонічний ланцюг». Цей міст забезпечує правильне впорядкування для Eclipse.
Це дозволяє нашим користувачам отримувати певні властивості безпеки від Ethereum. Міст перевірятиме всі транзакції Eclipse і запобігатиме введенню недійсних станів. Крім того, це забезпечить остаточну живучість і стійкість до цензури в деяких випадках збою. Навіть якщо замовник L2 припинить роботу або почне цензуру, користувачі зможуть примусово включити свої транзакції через міст.
Завдяки цим властивостям безпеки дієві й оптимальні бібліотеки часто називають «Ethereum L2». L2BEAT визначає L2 як «ланцюжок, який повністю або частково отримує безпеку від Ethereum Layer 1, тому користувачам не потрібно покладатися на чесність валідаторів L2, щоб зберегти кошти».
Розрахунок Ethereum відображає важливість власних активів Ethereum в економіці DeFi та NFT Eclipse Mainnet. ETH є найкращою децентралізованою валютою для більшості користувачів, тому ми також будемо використовувати ETH як наш маркер газу. У довгостроковій перспективі абстракція комісії дозволить користувачам платити будь-яким токеном на свій вибір (наприклад, USDC). Наразі Eclipse Mainnet не планує випускати власні токени.
Доступність даних: пропускна здатність Celestia та можливість перевірки
Eclipse Mainnet використовуватиме Celestia для доступності даних (також відомого як публікація даних або публікація даних). Celestia є довгостроковим екосистемним партнером Eclipse.
Цільова пропускна здатність Eclipse Mainnet і комісії, на жаль, не підтримуються поточними обмеженнями пропускної здатності Ethereum. Це справедливо навіть після EIP-4844 (він же «Proto-danksharding»), який надає ~0,375 МБ простору blob-областей на блок (з обмеженням на блок ~0,75 МБ).
Для порівняння, Celestia випустить блоки розміром 2 МБ до кінця цього року. Очікується, що коли достатня кількість легких вузлів вибірки доступності даних (DAS) стане онлайн і мережа стане стабільною, очікується, що незабаром після запуску простір blob збільшиться до 8 МБ. Світловий вузол DAS виконує дві ключові функції:
Очікується, що Celestia стане першим рівнем DA, який увімкне DAS у виробництві. Це відрізняється від традиційних комітетів доступності даних (DAC), які знову вводять припущення про чесність комітету без перевірки користувача (подібно до існуючих монолітних блокчейнів).
Існують невід’ємні припущення щодо безпеки для користувачів, які передають кошти з основної мережі Ethereum до будь-якого ланцюга за допомогою DA поза ланцюгом. Зокрема, валідатори Celestia можуть технічно відхиляти дані транзакцій, але стверджувати, що дані доступні на мосту Ethereum. Фактично, консенсус Celestia щодо підтвердження частки означає, що приховування даних самою Celestia карається, що змушує нас вважати цей ризик нереальним.
Загалом, підтримка легких вузлів DAS Celestia, властивості криптоекономічної безпеки та високомасштабована пропускна здатність DA з першого дня роблять це очевидним вибором для Eclipse Mainnet сьогодні.
Ми також маємо намір стежити за прогресом Ethereum у масштабуванні DA після EIP-4844. З’являються захоплюючі нові дослідження, які можуть забезпечити високу пропускну здатність DA раніше, ніж вважалося раніше (останнє використовує більш просунуті розподілені хеш-таблиці). Якщо Ethereum забезпечить більший масштаб для наших користувачів, ми оцінимо можливість переходу на Ethereum DA.
Доказ: захист від шахрайства RISC Zero ZK (серіалізація проміжного стану не потрібна!)
Наш доказ буде схожий на SIMD, розроблений Анатолієм для захисту від шахрайства SVM, який сам по собі схожий на думку Джона Адлера про те, що серіалізація стану дорога і що її можна уникнути.
Зокрема, ми хочемо уникнути повторного впровадження дерев Merkle у SVM. Ми намагалися вставити розріджене дерево Merkle після кожної транзакції в SVM, але оновлення дерева Merkle призвело до значної втрати продуктивності. Відмова від використання дерев Merkle виключає існуючі фреймворки зведення загального призначення (такі як стек OP) як основу для зведення SVM, а також вимагає більш креативних архітектур, стійких до збоїв.
Коротше кажучи, доказ відмови вимагає:
Вхідні зобов’язання зазвичай виконуються шляхом надання кореня Merkle дерева стану зведення. Наш виконавець опублікує список вхідних і вихідних даних (включно з хешами облікового запису та пов’язаним глобальним станом) для кожної транзакції, а також індекс транзакції, яка створила кожен вхід. Транзакції публікуються на Celestia, тому будь-який повний вузол може самостійно витягти обліковий запис у власному стані, обчислити вихідний обліковий запис і підтвердити правильність зобов’язань щодо Ethereum.
Можливі два основних типи несправностей:
Ми стоїмо на плечах велетнів. Сьогоднішнє зведення покращило стан досліджень у нашій галузі та надає користувачам Ethereum нижчу комісію, ніж L1.
Однак вони не в повній мірі використовують новітні технології, які вимагають великого масштабу. Неймовірні нещодавні досягнення усунули необхідність робити ці компроміси, які робили попередні зведені пакети, фактично поставивши їх у невигідне становище:
Ми можемо вивчити обмеження, з якими стикаються інші мережі, і вибрати найкращі частини для довгострокового розширення.
Ми часто чуємо розмови про мільйон зведених програм у майбутньому.
Налаштування на рівні консенсусу може бути дуже цінним для певних програм (наприклад, dYdX v4), і ми раді допомогти команді запустити зведення для окремих програм.
Однак такі ситуації трапляються рідко. Ось чому більшість нових зведених пакетів все ще є звичайними форками EVM. Проблеми розробників не будуть вирішені шляхом фрагментації UX між більшою кількістю ланцюжків. Основним варіантом використання мільйонів мереж сьогодні часто здається просто запуск нових монет. Для переважної більшості випадків використання потреби в повному налаштуванні стеку технологій сьогодні не існує.
Навіть якщо реальний попит існує, інфраструктура, необхідна для підтримки багатьох ланцюжків додатків із конкурентоспроможним UX, не буде на місці протягом багатьох років (якщо взагалі). Superchain Optimism (стек OP), Hyperchains zkSync (стек ZK), ланцюг Orbit Arbitrum тощо мають бачення багатьох ланцюгів зі спільною інфраструктурою. Це призначено для забезпечення більш плавного UX для операцій між ланцюжками в одній екосистемі (наприклад, між двома ланцюжками в межах Superchain), а не для повністю ізольованих ланцюжків (наприклад, між Ethereum і Solana).
Проте нинішні плани (якщо вони існують) далекі від обіцянок конкурувати з єдиною спільною державою. Крім того, вони не вирішують проблеми сумісності між екосистемами (наприклад, від суперланцюга до гіперланцюга). Модульність будівництва не повинна означати будівництво силосів.
Користувачам складніше вести облікові записи в багатьох мережах. Постійне перетинання ланцюжків і хвилювання про необхідні токени газу є гіршим для користувача. Покладатися на постачальників інфраструктури для роботи та підтримки такої кількості мереж також складніше та дорожче.
Ми завжди захоплювалися простотою бачення Солани. Високооптимізований спільний кінцевий автомат із масштабом для підтримки найцінніших випадків використання. Це часто вважають несумісним із дорожніми картами, орієнтованими на зведення, але насправді це не так. Ми хотіли поєднати найкраще з обох світів.
Це непорозуміння пов’язане з тим, що сьогоднішні зведені пакети здебільшого запускають оригінальну однопотокову EVM, яка майже не змінилася, щоб скористатися перевагами ранніх мережевих ефектів. Тому ми часто бачимо «приватний простір блоку» як причину розгортання зведених програм для окремих програм. Ціни на інші програми у вашій мережі не повинні підвищуватися через божевільне карбування NFT, але відповідь полягає не в тому, щоб створити власну мережу. Ви йдете на болісні та непотрібні компроміси (складність, вартість, погіршення взаємодії з користувачем, фрагментована ліквідність тощо). Найкраще рішення зрозуміло — просто використовуйте паралельну віртуальну машину з власним платним ринком для державних хот-спотів. Це саме те, що приносить SVM.
Ethereum є інтелектуальним, соціальним та економічним центром криптовалюти. Її ахіллесовою п’ятою завжди була експансія. Розширення доступності даних ще триває, і існуючі середовища виконання L2 не можуть конкурувати з новими інноваціями, такими як SVM. Ми стурбовані тим, що якщо сьогоднішній статус-кво збережеться, екосистема Ethereum буде застигнута зненацька у разі різкого зростання активності. Однопотокові EVM і обмежена доступність даних можуть швидко призвести до відродження високих витрат, тільки цього разу через зведення.
Ми вважаємо, що Eclipse Mainnet є очевидним рішенням: поєднання продуктивності Solana з безпекою, можливістю перевірки та мережевими ефектами дорожньої карти, орієнтованої на зведення.
Висновок
Краса Ethereum полягає в тому, що він постійно вдосконалюється. Дорожні карти, орієнтовані на зведення, є прикладом цього, делегуючи виконання та інновації вільному ринку. L2 має дивовижну здатність використовувати мережеві ефекти Ethereum і гарантії розрахунків, експериментуючи з найкращими новими середовищами виконання. Eclipse Mainnet є природною реалізацією цього бачення.
Якби колись з’явився більш продуктивний рівень виконання, ми були б дуже раді побачити його розгортання як конкурентоспроможний Ethereum L2. До того часу SVM залишається стандартом.