TL;DR

• =nil; це розсіяний zkRollup - нова концепція L2 для динамічного та безпечного масштабування Ethereum через паралельне виконання транзакцій на рівні протоколу по всіх шардах.
• Оснащений zkSharding, =nil; пропонує горизонтальне масштабування без ушкодження переваг одного виконавчого шару, а саме єдиної ліквідності та економічної безпеки.
• =nil; надає додаткам повну композицію з Ethereum через прозорий та перевірений доступ до даних Ethereum.
• =nil; вводить Type-1 zkEVM, скомпільований за допомогою zkLLVM.
• Швидке створення доказів гарантується відкритою конкуренцією на ринку через =nil; Proof Market - ринок створення доказів без дозволу.

Вступ до zkSharding

Сьогодні рішення на другому рівні жертвують масштабованість заради фрагментації стану. Ми представляємо дизайн на другому рівні (L2), =nil;, який дозволяє розширення Ethereum без ущемлення переваг єдиної середовища виконання. Рішення поєднує динамічний механізм шардінгу з перевіреною доступністю до даних Ethereum, захищеною технологіями нульового знання. Основні елементи включають:

• zkRollup з Шардингом: Основою =nil; є доказовий протокол розділення, що дозволяє горизонтальну масштабованість без втрати безпеки або ефективності. Цей підхід вирішує деякі поточні обмеження вертикального масштабування (L3, L4 і т. д.), а саме фрагментацію даних та ліквідності.
• Прямий доступ до даних Ethereum: Можливість виклику оригінальних даних Ethereum з додатків L2 дозволяє нам використовувати вже розгорнуті додатки. Прямий доступ до даних L1 з L2 забезпечує більш єдине та безшовне середовище.

Через zkSharding =nil; отримує переваги як від монолітного, так і від модулярного дизайнів, включаючи:

• Масштабованість

  • Немає обмежень масштабованості, оскільки виконання відбувається паралельно. Пропускна здатність оцінюється на рівні близько 60к переказів ERC-20 за секунду з приблизно 400 вузлами.
  • Конкурентне створення доказів через Proof Market забезпечує найшвидшу L1-фінальність та найнижчі витрати на генерацію доказів.

• Уніфіковане середовище виконання

  • Об'єднане середовище виконання гарантує відсутність фрагментації безпеки / ліквідності, оскільки кожен шар є частиною цілої кластері.
  • Зменшення потреби у міграції ліквідності з Ethereum, оскільки =nil; забезпечує прозорий доступ до своїх даних для програм шляхом змушення кожного валідатора зберігати повний стан Ethereum як частину розгортання, що дозволяє програмам отримувати доступ до даних прямо з zkEVM від =nil;.

• Безпека

  • Переходи між станами, захищені за допомогою zkEVM, скомпільовані через zkLLVM. Він забезпечує перевірену безпеку (наприклад, безпеку обмежень), оскільки код легко перевіряється, оскільки циркути zkEVM компілюються з реалізації EVM, яка використовується в виробництві у високорівневій мові, а не написана вручну.
  • Децентралізований з першого дня завдяки децентралізованому генерації підтвердження, що дозволяє =nil; Proof Market.

• Функціональність

  • Тип-1 zkEVM, повністю еквівалентний байт-код EVM, скомпільований через zkLLVM.
  • Середовище, спеціально розроблене для додатків, які мають високі вимоги, пов'язані з часом, пам'яттю та алгоритмічною складністю, шляхом підвищення консистентності одиночного шарду та впровадження примусового розташування додатків на кожному шарді для зменшення затримки. Приклади включають децентралізовані обмінники, ринки доказів, децентралізовані послідовники/будівничі, спільні додатки зі спільним станом (так звані автономні світи тощо).

Динамічне комбіноване масштабування

На нижньому рівні стан =nil; розбивається на основний шардинг та кілька вторинних шардингів. Основна роль шардингу полягає в синхронізації та консолідації даних з вторинних шардингів. Вона використовує Ethereum як його Шардинг Шардингу як Доступність Даних та як перевірник для доказів переходу стану, подібно до типових операцій zkRollups.

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

Кожен шард контролюється комітетом валідаторів. Існує періодична ротація цих валідаторів по шардах. Крім того, оновлення стану шарду перевіряються на головному шарді за допомогою zkEVM.

Для ілюстрації потоку транзакцій від ініціації користувачем до підтвердження на Ethereum розгляньте наступні кроки:

• Користувач підписує транзакцію (tx) та відправляє її до мережі.
• Валідатори в шарді S, де знаходиться гаманець користувача, поміщають tx в мемпул.
• Ці валідатори потім створюють новий блок B(1/S)
• Хеш B(1/S) записано на головному шарді в межах блоку B(1/M)
• Доказ проходження стану для B(1/S) створюється та перевіряється головною часткою в блоку B(2/M)
• Доказ проходження стану для B(2/M) надсилається в Ethereum для перевірки і сполучається з необхідними даними для забезпечення доступності даних.
• Після завершення цього процесу tx підтверджується Ethereum.

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

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

Щоб гарантувати безпеку кожного вторинного шарда, його валідаторський комітет зобов'язаний довести перехід свого стану на первинний, щоб переконатися, що в меншій групі валідаторів не сталося шахрайства. Кожен комітет валідаторів шардів має додаткові завдання, окрім обслуговування шардів. Валідатори відповідають за відстеження певних типів подій, а саме повідомлень між шардами, у межах «ближніх шардів». Ближні уламки визначаються на основі відстані Хеммінга в ідентифікаторах шардів.

zkEVM через zkLLVM: Тип-1 Безпечний, перевірки та продуктивний zkEVM

=nil;s zkEVM - це тип-1 zkEVM, скомпільований з zkLLVM. Щоб зрозуміти відмінності між традиційнішими zkEVM та zkEVM від =nil;, нам потрібно обговорити обмеження, пов'язані з процесом визначення схем, що лежать в основі zkEVM. Схема zkEVM - це критична частина, відповідальна за доказ переходу стану, щоб його вважали вірним, зазвичай визначена з допомогою деякого спеціалізованого zkDSL або просто бібліотеки. Такий спосіб визначення схеми вносить проблеми, пов'язані з:

• Безпека: Проблемичерез розмір схеми та ручне копіювання логіки EVM.
• Перевірка: Обмеженааудитованість та інспектованістьчерез складність та неявність використовуваних zkDSLs.
• Можливість оновлення: Складність обслуговування та можливості оновлення через вимоги до визначення обмежень за допомогою вручну. У випадку внесення будь-яких змін у EVM - більшість схем zkEVM потрібно буде переробити та повторно пройти аудит з нуля.
• Сумісність: Складність реалізації фактично сумісного з байткодом (так звана Тип-1) кола zkEVM часто веде до обмежень для додатків через різницю у поведінці zkEVM та фактичної поведінки EVM.

=nil; zkEVM ефективно вирішує всі ці виклики, бути:

• Безпека: Схема повинна автоматично генеруватися з того ж коду високого рівня, що використовується в реальних вузлах Ethereum, які працюють на виробництві, щоб гарантувати відсутність різниці в алгоритмах.
• Перевірка: Схема повинна бути представлена мовою програмування високого рівня (такою як C++ або Rust), яка повинна бути написана таким чином, щоб бути легко зрозумілою для середнього розробника.
• Оновлюваний: Схему слід визначати таким чином, щоб будь-яка зміна в межах EVM могла бути легко перекладена / скомпільована в доказуючу / визначальну схему zkEVM, яка точно визначає таку саму поведінку. Жодне повне перекомпілювання або необхідність повторного аудиту не повинні виникати внаслідок такого оновлення.
• Сумісність з байт-кодом (також відомий як Type-1): компіляція схем з мов високого рівня забезпечує повну сумісність байт-коду та поведінки EVM, значно скорочуючи час виходу на ринок додатків EVM та час/зусилля розробки, необхідні для досягнення такої сумісності.

zkEVM, скомпільований через zkLLVM, захищений за конструкцією, використовуючи evmone для забезпечення повної узгодженості з використовуваним виробництвом EVM Ethereum. zkLLVM (C++ або Rust) автоматично компілюється до схеми, що означає, що людська помилка вилучається з процесу визначення схеми.

Крім того, оскільки =nil; zkEVM компілюється через zkLLVM, він природно більш гнучкий (і, отже, майбутнє) ніж вручну визначені схеми, оскільки його легко налаштовувати, а генерація схеми автоматична. Також він більш аудитований, що означає, що його безпека не залежить від включення останніх EIP, доданих до Ethereum.

zkRollup з безпекою та доступністю даних Ethereum

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

• Основний шар використовує Ethereum як свою DA.
• Другорядні шари мають можливість використовувати Ethereum або відмовитися від використання окремого DA.

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

Додатково, ця структура може бути розширена, щоб включати інші типи DA.

Прозорий доступ до даних Ethereum

Однією з наших основних цілей є оптимізація для композиції додатків та запобігання фрагментації ліквідності, тому, зрозуміло, що підхід zkSharding був би неповним без безпечного доступу до стану Ethereum. Це означає =nil; пропонує повну композицію та прозору інтеграцію з Ethereum через модуль Data Provider.

Постачальник даних працює незалежно від зберігання даних розділу, синхронізує свою інформацію зовнішньою базою даних та впроваджує в блок розділу відбиток пальця Ethereum останнього відстеженого стану бази даних (представлений хешем блоку Ethereum). Найбільш недавній стан цієї бази даних отримує підтвердження від модуля підтвердження, який використовує zkBridge з підтвердженням згоди Casper FFG Ethereum.

Що далі:

=nil; та zkSharding є підсумком продуктів, які Фонд =nil; розробив за останні 4 роки. Його мета - бути першим композиційним, масштабованим та універсальним рішенням Ethereum L2 zkRollup. Ми з нетерпінням поділимося більш докладними деталями реалізації протягом наступних кількох місяців. Обов'язково слідкуйте за нашим Twitter, щоб бути в курсі наших досягнень!

Для технічно нахилених ми розробили окремий, всебічний підручникякий досліджує деталі =nil; та zkSharding. Цей підручник є вашим входом у розуміння тонкощів цього підходу, обладнаний усіма технічними деталями та підготовчими заходами, які вам потрібні.

Зануртесь у наш технічний путівник зараз і долучайтеся до розмови проДискордіTelegramДавайте дослідимо нескінченні можливості zkSharding разом!

Disclaimer：

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