Шардинг технологія: інша можливість розширення Блокчейн

15 вересня 2022 року, Ethereum завершив злиття (Merge). Це історичний момент, до якого Ethereum готувався протягом 5 років, відтермінувавши 6 разів. Через тривале розроблення та широку увагу, багато хто помилково вважає, що злиття природно призведе до вищої масштабованості, безпеки та сталості, але це не так. Перехід від доказу роботи (PoW) до доказу частки (PoS) - це лише зміна "коліс і рейок", і не призведе безпосередньо до швидшої швидкості, більшої ємності або нижчих витрат. Реально досягти цих цілей можна лише за допомогою цілого набору рішень: основна мережа з можливістю шардингу в поєднанні з рішеннями Layer2, що підвищують масштабованість.

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

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

Один. Про "Шардинг"

Простими словами, враховуючи обмеження неможливого трикутника, виходячи з Ethereum як початкової системи координат (0,0), за двома підходами: "вертикальним" та "горизонтальним", ми поділимо сучасні методи розширення Блокчейн на дві великі категорії:

Вертикальне масштабування(Vertical Scaling): досягається шляхом підвищення продуктивності існуючого апаратного забезпечення системи. Створення децентралізованої мережі, в якій кожен вузол має суперкомп'ютерні можливості, тобто кожен вузол потребує "кращого" апаратного забезпечення. Цей підхід є простим і ефективним, він може досягти первинного покращення пропускної здатності, особливо підходить для високочастотної торгівлі, ігор та інших сценаріїв застосування, чутливих до затримок. Проте, цей спосіб масштабування обмежує рівень децентралізації мережі, оскільки витрати на запуск валідаторських вузлів або повних вузлів зростають. Підтримка рівня децентралізації обмежена приблизною швидкістю зростання продуктивності обчислювального апаратного забезпечення( це так зване "закон Мура": кількість транзисторів на чіпі подвоюється кожні два роки, а вартість обчислень зменшується вдвічі).

Горизонтальне масштабування ( Horizontal Scaling ): Горизонтальне масштабування зазвичай має кілька підходів. Один із них у контексті Блокчейн полягає в розподілі обчислювальних операцій з транзакцій в певній екосистемі на кілька незалежних блокчейнів, кожен з яких має своїх виробників блоків та виконавчі можливості. Цей підхід дозволяє повністю налаштувати виконавчий рівень кожного блокчейну, наприклад, вимоги до апаратного забезпечення вузлів, функції конфіденційності, газові витрати, віртуальні машини та налаштування дозволів тощо. Іншим варіантом горизонтального масштабування є модульний блокчейн, що розподіляє інфраструктуру блокчейну на виконавчий рівень, рівень доступності даних ( DA ) та рівень консенсусу. Найпоширеніший модульний механізм блокчейну - це rollup. Ще один підхід полягає в розділі одного блокчейну на багато частин, які виконуються паралельно. Кожен шардинг можна вважати окремим блокчейном, тобто багато блокчейнів можуть виконуватися паралельно. Крім того, зазвичай існує один головний блокчейн, єдине завдання якого - підтримувати синхронізацію всіх шардінгів.

Слід зазначити, що вищезгадані підходи до масштабування не є ізольованими, кожне з рішень знаходить компроміс у трикутнику неможливого, у поєднанні з ін incentives, створеними економічними силами в системі, для досягнення ефективного балансу на макро- та мікрорівнях.

Щоб обговорити "Шардинг", нам потрібно почати з самого початку.

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

По-перше, якщо у нас є 10 касирів, як нам розподілити їх по вікнам?

По-друге, якщо у нас є 1000 клієнтів, які стоять у черзі, як вирішити, до якого вікна повинен піти кожен клієнт для розрахунку?

По-третє, як слід підсумовувати ці 10 окремих книг рахунків, що відповідають 10 вікнам?

Четверте, щоб уникнути ситуації, коли рахунки не збігаються, як запобігти помилкам касира?

Ці кілька питань насправді відповідають кільком ключовим питанням у Шардингу, а саме:

Як визначити, до якого Шардингу належать вузли/валідатори в усій мережі? Тобто: як здійснити мережевий Шардинг (Network Sharding);

Як визначити, якій частині відноситься кожна транзакція? Тобто: як здійснюється шардінг транзакцій (Transaction Sharding);

Як зберігатися дані Блокчейн у різних Шардингах? Тобто: як здійснити стан Шардингу (State Sharding);

Складність означає ризик, на основі всього вищесказаного, як уникнути розколу безпеки всієї системи?

01 Мережевий Шардинг (Network Sharding )

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

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

Засновник Near Олександр Скіданов так описує цю проблему: якщо єдина ланцюг з X валідаторами вирішить жорстко розгалужитися на шардинг-ланцюг і розділити X валідаторів на 10 шардів, кожен шардинг тепер матиме лише X/10 валідаторів, знищити один шардинг потрібно лише знищити 5.1%(51% / 10) від загальної кількості валідаторів. Це підводить до другого питання: хто обирає валідаторів для кожного шардингу? Тільки якщо всі ці 5.1% валідаторів знаходяться в одному шардингу, контроль 5.1% валідаторів буде шкідливим. Якщо валідатори не можуть вибрати, в якому шардингу вони будуть перевіряти, ймовірність того, що учасники, які контролюють 5.1% валідаторів, помістять всіх валідаторів в один шардинг, є вкрай низькою, що значно зменшує їхню можливість знищити систему.

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

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

Однак слід зазначити, що випадковість у Блокчейн є дуже складною темою, логічно кажучи, процес генерації цього випадкового числа не повинен залежати від обчислень будь-якого конкретного Шардингу. Для цього обчислення багато існуючих проектів розробляють окремий Блокчейн для обслуговування всієї мережі. Така ланка у Ethereum та Near називається Beacon-ланцюгом, у PolkaDot — Relay-ланцюгом, а в Cosmos — Cosmos Hub.

! 10 000 слів детальне пояснення нового публічного ланцюга Shardeum: ще одна можливість шардингу

02 Транзакційний Шардинг(

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

В даний час у мережі Блокчейн існує два типи способів обліку: UTXO)Unspent Transaction Outputs, модель невикористаних транзакцій( та модель облікових записів/балансів, типовим представником першої є BTC, а другої - ETH.

Модель UTXO: в BTC-транзакціях кожна транзакція має один або кілька виходів, UTXO означає необроблені виходи транзакцій Блокчейн, які можуть бути використані як входи для нових транзакцій, тоді як вже використані виходи транзакцій не можуть бути повторно використані, подібно до випадку з готівкою, коли споживач передає один або кілька банкнот продавцю, а продавець повертає один або кілька банкнот споживачу. У моделі UTXO транзакційний Шардинг потребує міжшардингового зв'язку. Одна транзакція може включати кілька входів і виходів, концепції рахунків не існує, також не буде запису балансу, один з можливих способів: помістити її в функцію хешування відповідно до значення одного з її входів, щоб отримати дискретне значення хешу для визначення, куди повинні йти дані. Як показано нижче:

Щоб забезпечити правильне розміщення записів у відповідних Шардах, значення, які вводяться в хеш-функцію, повинні походити з одного стовпця. Цей стовпець називається Shard Key. Після цього транзакції, які генерують значення 1, будуть розподілені в Шард 1, а транзакції, які генерують значення 2, будуть розподілені в Шард 2. Недоліком цього підходу є те, що Шарди змушені взаємодіяти один з одним, щоб уникнути атаки подвійної витрати. Якщо обмежити міжшардові транзакції, це обмежить доступність платформи, а якщо дозволити міжшардові транзакції, то потрібно зважити витрати на міжшардову комунікацію та вигоди, які приносить підвищення продуктивності.

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

! [Шардеум: Ще одна можливість шардингу])https://img-cdn.gateio.im/webp-social/moments-4227a2e49f76cd01b23d7b5398e51a3c.webp(

) 03 стан Шардинг###State Sharding(

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

Зберігаючи наш приклад з чергою у Walmart, як кожне вікно веде свій облік? Якщо: клієнт стає в чергу, то записується до того обліку, наприклад, клієнт A підійшов до вікна A, а наступного дня цей клієнт пішов до іншого вікна, наприклад, вікна B, при цьому вікно B не має інформації про минулі облікові дані цього клієнта ), наприклад, якщо мова йде про способи розрахунку, такі як картки поповнення (, що робити? Викликати облікові дані цього клієнта з вікна A?

Стан статусу є найбільшою проблемою Шардингу, що є більш складним, ніж згадані вище мережевий Шардинг та транзакційний Шардинг. Тому що в механізмі Шардингу транзакції розподіляються за адресами для обробки в різних Шардах, тобто статус буде зберігатися тільки в Шарді, до якої належить його адреса, при цьому стикаючись із проблемою, що транзакції не відбуваються лише в одному Шарді, часто залучаючи крос-Шардинг ) Cross-Sharding (.

Розглянемо ситуацію з переказом: рахунок A переказує 10U на рахунок B, причому адреса A розподілена по Шардингу 1, записи транзакцій також зберігатимуться в Шардингу 1. Адреса B розподілена по Шардингу 2, записи транзакцій зберігатимуться в Шардингу 2.

Коли A хоче переказати гроші B, це призведе до створення крос-шардової транзакції, шардинг 2 буде викликати записи минулих транзакцій з шардингу 1, щоб підтвердити дійсність транзакції. Якщо A часто переводить кошти B, то шардинг 2 повинен постійно взаємодіяти з шардингом 1, внаслідок чого ефективність обробки транзакцій знижується. Однак, якщо не завантажити і не перевірити всю історію конкретного шардінгу, учасники не обов'язково...