Shardeum та динамічний стан Шардингу: інша можливість Шардингу

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

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

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

! Шардеум: Ще одна можливість шардингу

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

![Детальний аналіз нової публічної блокчейн-мережі Shardeum: Шардинг як інша можливість])https://img-cdn.gateio.im/webp-social/moments-7aa1677db6b8128b68accfe04fcda738.webp(

) 01 Мережевий Шардинг ###

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

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

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

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

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

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

( 02 Шардинг )Transaction Sharding### транзакцій

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

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

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

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

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

! Шардеум: Ще одна можливість шардингу

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

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

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

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

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

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