Eclipse Mainnet — це універсальна мережа L2, яка поєднує найкращі частини модульного стеку:

1. Розрахунок: Ethereum – Eclipse розраховуватиметься на Ethereum (тобто закріплений міст перевірки буде на Ethereum) і використовуватиме ETH як свій маркер газу.
2. Виконання: віртуальна машина Solana (SVM) – Eclipse запускатиме високопродуктивну SVM як середовище виконання.
3. Доступність даних: Celestia – Eclipse публікуватиме свої дані в Celestia для масштабованої доступності даних (DA).
4. Доведення: RISC Zero - Eclipse використовуватиме RISC Zero для ZK доказів шахрайства (без серіалізації проміжного стану!)

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

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

Виконання: швидкість і масштаб Солани

Eclipse Mainnet використовуватиме найкраще в своєму класі середовище виконання Solana. Це дає величезні переваги:

Оптимізоване паралельне виконання

SVM і його середовище виконання Sealevel дозволяють паралельно виконувати транзакції. Транзакції, які не торкаються стану перекриття, можуть виконуватися паралельно, а не послідовно.

Це дозволяє SVM напряму масштабувати апаратне забезпечення, оскільки процесори продовжують додавати більше ядер за менших витрат. Однопотокові середовища виконання (наприклад, сьогоднішня EVM) принципово не виграють від зниження вартості ядра. Вже більше десяти років однопотокове прискорення продуктивності постійно зменшується. Майже всі покращення продовжують відбуватися завдяки збільшенню кількості ядер, тому дуже важливо скористатися перевагами цієї тенденції шляхом розпаралелювання робочих навантажень:

Є деякі дуже ранні неперевірені спроби розпаралелити EVM, але додавання цього, зберігаючи сумісність, приносить фундаментальні компроміси, включаючи неоптимальну продуктивність без усунення інших вузьких місць (наприклад, зростання стану). Контракти, що заздалегідь декларують залежності стану (як у SVM), дозволяють оптимально розпаралелювати.

Місцеві ринки зборів

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

Місцеві ринки комісії можливі завдяки унікальному розпаралеленому середовищу виконання Solana. Спроба запровадити місцеві ринки зборів для державних гарячих точок у EVM за допомогою евристики (тобто без попереднього оголошення державного доступу) призведе до неефективності та ймовірних векторів атак.

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

Державне управління зростанням

Перш ніж EVM навіть зіткнеться з послідовним виконанням як вузьким місцем, зростання стану є його набагато більш актуальним вузьким місцем.

Оскільки не існує дерева Merkle для стану, Solana не несе накладних витрат на оновлення дерева Merkle для кожного оновлення стану. Натомість після кожної епохи (~2,5 дня) весь стан мерклізується. Це набагато дешевше, ніж мерклізація в реальному часі (як у EVM).

Що ще важливіше, EVM має динамічний доступ до облікового запису (тобто транзакції можуть торкатися будь-якого стану на вимогу). Цей динамічний пошук стану означає, що цей стан не можна завантажити в пам'ять до виконання. У SVM кожна транзакція визначає всі стани, необхідні для виконання.

Як результат, розмір стану не впливає на виконання SVM. Мережа може безпечно подвоїти розмір знімка кожні 2 роки, не стикаючись із серйозними проблемами, якщо припустити, що валідатори оновлюють свої диски зберігання кожні 2 роки.

Крім того, такі групи, як Helius , активно покращують доступність історичних даних і зменшують розмір стану за допомогою стиснення.

Сумісність з EVM

Neon EVM — це EVM, що працює як смарт-контракт, який можна розгорнути в будь-якому ланцюжку SVM. Це забезпечує повну сумісність EVM з Eclipse Mainnet (включаючи підтримку байт-коду EVM і JSON-RPC Ethereum) з більшою пропускною здатністю, ніж однопотокові EVM. Оскільки кожен екземпляр Neon EVM має власний місцевий ринок комісій, додатки можуть просто розгорнути власний контракт, щоб отримати переваги ланцюжка додатків без фрагментації UX, безпеки чи ліквідності.

Крім того, компілятор Solang дозволяє компілювати код смарт-контрактів Solidity у байт-код SVM.

Знімки MetaMask

Приєднання користувачів EVM до ланцюжків, які не належать до EVM, історично було серйозною перешкодою, але нещодавно представлені Metamask Snaps збираються подолати цей бар’єр. Користувачі EVM можуть продовжувати використовувати MetaMask без необхідності міняти гаманці. UX можна порівняти з взаємодією з будь-яким ланцюжком EVM завдяки внеску Driftу відкритий вихідний код, який створює чудову реалізацію MetaMask Snap. Користувачі Eclipse Mainnet зможуть взаємодіяти з програмами безпосередньо в MetaMask або використовувати рідний гаманець Solana, наприклад Salmon.

Ось короткий огляд UX від Drift:

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, тому користувачам не доводиться покладатися на чесність валідаторів 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 МБ на блок).

1. Для передачі ERC-20 із базовим стисненням (~154 байти на транзакцію) це означає ~213 TPS для всіх сукупних зведень.
2. Для свопів зі стисненням (~400 байт на транзакцію) це означає ~82 TPS для всіх сукупних зведень.

Для порівняння, Celestia буде запущена з блоками розміром 2 МБ пізніше цього року. Очікується, що простір Blob-простір збільшиться до 8 МБ незабаром після запуску, щойно достатньо легких вузлів вибірки доступності даних (DAS) стане доступним і мережа стане стабільною. Світлові вузли DAS виконують дві важливі функції:

1. Дозволити користувачам самостійно перевірити, що дані блоків Eclipse стали доступними
2. Внесіть свій внесок у безпечне масштабування всієї мережі, оскільки рівні DA можуть безпечно збільшити свою пропускну здатність, оскільки більше легких вузлів DAS підключаються до мережі

Очікується, що Celestia стане першим рівнем DA, який буде запущено з DAS у виробництві. Це контрастує з традиційними комітетами доступності даних (DAC), які знову запроваджують припущення про чесність комітетів без перевірки користувача (подібно до існуючих монолітних блокчейнів).

Для користувачів, які переводять свої кошти з основної мережі Ethereum до будь-якого ланцюга, який використовує автономний DA, є природне припущення щодо безпеки . Зокрема, для валідаторів Celestia технічно можливо приховувати дані транзакцій, але заявляти мосту Ethereum, що дані доступні. На практиці консенсус щодо підтвердження участі Celestia означає, що приховування даних про саму Celestia може скорочуватися, що робить цей ризик нереалістичним, на нашу думку.

Загалом, підтримка легкого вузла DAS від Celestia з першого дня, властивості криптоекономічної безпеки та високомасштабована пропускна здатність DA роблять його очевидним вибором для Eclipse Mainnet сьогодні.

Зауважте, що дехто розглядає onchain Ethereum DA як вимогу для справжнього «L2» тут з причин, описаних вище. Ми використовуємо більш поширену термінологію L2, наведену раніше, і хочемо чітко пояснити міркування безпеки.

Ми також маємо намір стежити за прогресом Ethereum у масштабуванні DA після EIP-4844. Продовжують з’являтися нові цікаві дослідження, які потенційно пропонують високопродуктивний DA швидше, ніж попередні ідеї (які використовують більш просунуті розподілені хеш-таблиці). Якщо Ethereum запропонує більший масштаб для Eclipse на користь наших користувачів, ми оцінимо можливість переходу на Ethereum DA.

Підтвердження: RISC Zero ZK докази шахрайства (без серіалізації проміжного стану!)

Наше доведення виглядатиме подібно до доказів шахрайства SIMD Анатолія SVM, яке само по собі схоже на думку Джона Адлера про те, що серіалізація стану є дорогою, і її можна уникнути.

Зокрема, ми хочемо уникнути повторного введення дерева Merkle у SVM. Ми експериментували зі вставленням розрідженого дерева Merkle у SVM на ранньому етапі, але оновлення дерева Merkle після кожної транзакції призводить до значного зниження продуктивності. Доведення без дерева Merkle виключає існуючі загальні структури зведення, як-от стек OP, як основу для зведення SVM, а також вимагає більш креативної архітектури захисту від помилок.

На високому рівні доказ несправності вимагає:

1. Зобов’язання щодо вхідних даних для транзакції,
2. Сама транзакція, і
3. Доказ того, що повторне виконання транзакції призводить до іншого результату, ніж той, який був указаний у мережі.

Зобов’язання щодо введення зазвичай здійснюється шляхом надання кореня Merkle для дерева стану зведення. Натомість наш виконавець опублікує список вхідних і вихідних даних (включно з хешами облікового запису та відповідним глобальним станом) для кожної транзакції разом із індексом транзакції, яка спричинила кожен вхід. Транзакції публікуються в Celestia, тож будь-який повний вузол може слідкувати, щоб отримати вхідні облікові записи зі свого власного стану, обчислити вихідні облікові записи та підтвердити правильність зобов’язань щодо Ethereum.

Існує два можливих типи серйозних несправностей:

1. Неправильні виходи. У цьому випадку верифікатор надає ZK-доказ у ланцюжку правильних виходів. Ми використовуємо RISC Zero для створення ZK-доказів виконання SVM, продовжуючи нашу попередню роботу з підтвердження виконання байт-коду BPF. Це дозволяє нашій розрахунковій угоді забезпечувати правильність без необхідності виконувати самі транзакції в мережі.
2. Неправильні введення – у цьому випадку верифікатор публікує в ланцюжку посилання на історичні дані, які показують, що стан введення не відповідає заявленому. Використовуючи Quantum Gravity Bridge від Celestia, наша угода про врегулювання гарантує, що ці історичні дані справді доводять шахрайство.

Чому Eclipse, чому Ethereum, чому зараз

Ми стоїмо на плечах велетнів. Сьогоднішні зведені пакети покращили стан досліджень для всієї нашої галузі та забезпечили користувачам Ethereum нижчу плату порівняно з L1.

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

1. Високопродуктивні паралелізовані віртуальні машини (наприклад, SVM)
2. Масштабування DA з підтримкою світлового вузла DAS (наприклад, Celestia)
3. Удосконалення інфраструктури перевірки, щоб зробити її практичною будь-де (наприклад, RISC Zero)
4. Покращена переносимість коду (наприклад, Neon і Solang) і користувачів (наприклад, MetaMask Snaps) між екосистемами

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

https://twitter.com/0xMert?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1680271128537726976%7Ctwgr%5E9336eadfb24c400b8686ae67184014bab31080f1%7Ctwcon%5Es1&ref_url=https%3A%2F%2Fmirror.xyz%2Feclipsemainnet.eth%2Fme7bXLWJDS177V6nl8j1uzF1mxpX6nbGOLNeyBAwXgs

https://twitter.com/colludingnode?refsrc=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1680285353662468097%7Ctwgr%5E9336eadfb24c400b8686ae67184014bab31080f1%7Ctwcon%5Es1&ref_url=https%3A%2F%2Fmirror.xyz%2Feclipsemainnet.eth%2Fme7bXLWJDS177V6nl8j1uzF1mxpX6nbGOLNeyBAwXgs

Ми часто чуємо про майбутнє з мільйонами зведених додатків.

Налаштування на рівні консенсусу можуть бути неймовірно цінними для певних програм (наприклад, dYdX v4), і ми раді допомогти командам запустити зведення для конкретних програм.

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

Навіть якби реальний попит існував, інфраструктура, необхідна для підтримки багатьох ланцюжків додатків із конкурентоспроможним UX, залишиться далеко (якщо вона колись досягне рівня). Суперланцюжки Optimism (OP Stack), Hyperchains zkSync (ZK Stack), ланцюги Orbit Arbitrum тощо мають багатоланцюгове бачення зі спільною інфраструктурою. Це має на меті забезпечити більш плавну роботу UX між ланцюжками в одній екосистемі (наприклад, між двома ланцюжками в межах Superchain) порівняно з повністю ізольованими ланцюжками (наприклад, між Ethereum і Solana).

Однак поточні плани (там, де вони існують) ще далекі від того, щоб коли-небудь конкурувати з єдиною спільною державою. Крім того, вони не стосуються взаємодії між екосистемами (наприклад, від суперланцюга до гіперланцюга). Модульна конструкція не повинна означати створення островів.

Користувачам складніше підтримувати облікові записи в багатьох мережах. Гірше для UX – продовжувати перемикати й хвилюватися про те, який токен газу вам потрібен. Більш складно та дорожче покладатися на постачальників інфраструктури для роботи та підтримки такої кількості мереж.

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

Це помилкове уявлення виникає через те, що сьогоднішні зведені пакети здебільшого запускають однопотоковий EVM без змін, щоб використати ранні мережеві ефекти. Як наслідок, ми часто бачимо «виділений блоковий простір» як причину розгортання зведеного пакета для конкретної програми. Ці божевільні монетні двори NFT не повинні підвищувати ціни на всі інші програми у вашій мережі, але відповідь полягає не в тому, щоб піти створювати власну мережу. Це як використовувати кувалду, щоб розбити арахіс. Ви йдете на болісні та непотрібні компроміси (складність, вартість, погіршення UX, фрагментована ліквідність тощо). Оптимальне рішення неймовірно зрозуміле – просто використовуйте паралелізовану віртуальну машину з локальними ринками зборів для державних хот-спотів. Це саме те, що приносить SVM.

Ethereum є інтелектуальним, соціальним та економічним центром криптовалюти. Його ахіллесова п’ята зашкалювала. Масштабування DA все ще знаходиться в стадії розробки, і існуючі середовища виконання L2 не можуть конкурувати з новими інноваціями, такими як SVM. Ми боїмося, що екосистема Ethereum застанеться з ніг на ногах через будь-яке різке зростання активності, яка є сьогодні. Однопотокові EVM і обмежений DA швидко призведуть до відновлення високих комісій, за винятком цього разу згортань.

Ми вважаємо, що Eclipse Mainnet є очевидним рішенням: поєднання продуктивності Solana з безпекою, можливістю перевірки та мережевими ефектами дорожньої карти, орієнтованої на зведення.

Прощальні думки

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

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

Щоб взяти участь, зв’яжіться з нами за адресоюhttp://mailto:team@eclipse.builders/team@eclipse.builders, щоб отримати інструкції щодо тестової мережі.

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

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