Шардинг технологія: передовий досвід розширення Блокчейн
15 вересня 2022 року Ethereum завершив злиття (Merge). Це історичний момент, до якого Ethereum готувався 5 років, відтермінувавши 6 разів. Через численні налагодження та тривалу розробку, а також ефект широкої уваги, багато людей помилково вважають, що злиття природним чином принесе вищу масштабованість, безпеку та сталий розвиток, але це не так. Перехід від PoW( до PoS) - це лише зміна "колії та коліс", яка не призведе безпосередньо до швидшої роботи, більшої ємності або нижчих витрат. Реально досягти цих цілей можна лише за допомогою цілого комплексу рішень: основної мережі з можливістю Шардингу, доповненої рішеннями Layer2 для покращення масштабованості.
Як зазначив засновник Ethereum Віталік Бутерін, Шардинг є рішенням для розширення в умовах трилеми масштабованості. Це досягається шляхом розподілу вузлів у мережі на менші групи, які обробляють різні набори транзакцій і реалізують паралельну обробку. Це схоже на процес розрахунку в супермаркеті, де відкриття кількох кас може зменшити час очікування в черзі та підвищити ефективність розрахунків.
Це логіка Шардингу, проста і зрозуміла. Однак диявол у деталях - принцип і напрямок вірні, але під час реалізації завжди виникає безліч проблем. Ця стаття має на меті проаналізувати напрямок і труднощі на шляху "Шардингу", намалювати карту дослідника Шардингу, який дивиться на зірки та стоїть на землі. Одночасно порівнюючи існуючі рішення для Шардингу, знайти деякі спільні проблеми та запропонувати можливий напрямок дослідження: Shardeum та динамічний Шардинг.
Простими словами, враховуючи обмеження неможливого трикутника, виходячи з Ethereum як початкової точки координат (0,0), відповідно до "вертикального" та "горизонтального" підходів, ми розділимо методи масштабування поточного Блокчейн на дві великі категорії:
Вертикальне масштабування(Vertical Scaling): здійснюється шляхом підвищення продуктивності існуючого обладнання системи. Створення децентралізованої мережі, в якій кожен вузол має суперкомп'ютерні можливості, тобто кожен вузол потребує "кращого" обладнання. Цей спосіб є простим і ефективним, може забезпечити початкове покращення пропускної здатності, особливо підходить для високочастотної торгівлі, ігор та інших застосунків, чутливих до затримок. Однак такий спосіб масштабування обмежить рівень децентралізації мережі, оскільки витрати на запуск верифікаційних вузлів або повних вузлів зростають. Підтримка рівня децентралізації обмежена приблизним темпом зростання продуктивності обчислювального обладнання( це і є так званий "закон Мура": кількість транзисторів на чіпі подвоюється кожні два роки, а вартість обчислень зменшується вдвічі).
Горизонтальне масштабування(Horizontal Scaling): Горизонтальне масштабування зазвичай має кілька підходів. Один з них полягає в тому, щоб в контексті Блокчейн розподілити обсяг обчислень транзакцій в певній екосистемі на кілька незалежних Блокчейн, кожен з яких має своїх виробників блоків та виконавчі можливості. Цей підхід дозволяє повністю налаштувати виконавчий рівень кожного ланцюга, наприклад, вимоги до апаратного забезпечення вузлів, функції конфіденційності, витрати на газ, віртуальні машини та налаштування доступу тощо. Інший варіант горизонтального масштабування - це модульний Блокчейн, який розділяє інфраструктуру Блокчейн на виконавчий рівень, рівень доступності даних(DA) та рівень консенсусу. Найпоширеніший модульний механізм Блокчейн - це rollup. Ще один варіант полягає в тому, щоб розділити один Блокчейн на багато частин, які виконуються паралельно. Кожен фрагмент можна розглядати як окремий Блокчейн, тобто багато Блокчейн можуть виконуватись паралельно. Крім того, зазвичай існує один головний ланцюг, єдине завдання якого - підтримувати синхронізацію всіх фрагментів.
Слід зазначити, що вищезгадані підходи до масштабування не існують ізольовано, кожне із рішень знаходить компроміс у рамках неможливого трикутника, поєднуючи його з дизайном механізмів стимулювання, створених економічними силами в системі, для досягнення ефективного балансу на макро- та мікрорівнях.
Щоб обговорити "Шардинг", нам потрібно почати з самого початку.
Все ще припустимо таку ситуацію: каса в супермаркеті. Щоб підвищити ефективність обслуговування, зменшити час очікування клієнтів, ми розширюємо одну касу до 10 касових вікон. Щоб уникнути помилок у підрахунках, нам потрібно встановити єдині правила:
По-перше, якщо у нас є 10 касирів, як ми можемо розподілити їх на які вікна працювати?
По-друге, якщо у нас є 1000 клієнтів, які чекають у черзі, як вирішити, до якого вікна піде кожен клієнт для розрахунку?
По-третє, як можна підсумувати 10 окремих бухгалтерських книг, відповідних цим 10 вікнам?
По-перше, щоб уникнути ситуацій з невідповідністю обліку, як можна запобігти помилкам касирів?
Ці кілька запитань насправді відповідають кільком ключовим проблемам у Шардингу, а саме:
Як визначити, до якого Шардингу належать вузли/вірifiers у всій мережі? Тобто: як здійснити мережевий Шардинг (Network Sharding);
Як визначити, якій частині відповідає кожна транзакція? Тобто: як здійснити транзакційне шардінг (Transaction Sharding);
Як зберігаються дані Блокчейн у різних Шардингах? Тобто: як здійснюється стан Шардингу (State Sharding);
Складність означає ризик, на основі всього вищезазначеного, як уникнути розколу безпеки всієї системи?
( 01 Мережевий Шардинг)
Якщо ми спростимо розуміння Блокчейн як децентралізовану книгу обліку, то незалежно від того, чи це механізм консенсусу PoS чи PoW, метою є те, щоб різні вузли змагалися за право ведення обліку відповідно до певних установлених правил, при цьому гарантується правильність книги обліку. А мережевий Шардинг означає, що потрібні інші встановлені правила, щоб розділити мережу Блокчейн на частини, при цьому намагаючись зменшити взаємне спілкування, щоб кожен Шардинг обробляв транзакції в ланцюзі, змагаючись за право ведення обліку - тобто, правила групування вузлів.
А в цьому процесі виникає проблема: зі зростанням кількості внутрішніх вузлів Блокчейн, розділених на різні Шардинги, складність і витрати для нападника знижуються в геометричній прогресії. Ми можемо зробити висновок, що, якщо правила та результати цього процесу групування є фіксованими та передбачуваними, тоді нападнику потрібно контролювати всю Блокчейн-мережу, лише орієнтуючись на контроль одного з Шардингів, купуючи частину вузлів у цьому Шардингу.
Система Шардингу повинна розробити механізм, щоб довіряти мережі, що не буде скасування цих транзакцій з зовнішніх Шардів. До сьогодні, можливо, найкраща відповідь полягає в тому, щоб забезпечити кількість валідаторів всередині Шарду вище певного мінімального порогу, так що ймовірність нечесних валідаторів переважити окремий Шард буде дуже низькою. Найбільш поширений спосіб - побудувати певну міру непереборної випадковості, покладаючись на математичні методи, щоб звести ймовірність успіху атаки до мінімуму. Наприклад, в Ефіріумі, рішення Ефіріуму полягає в тому, щоб випадковим чином обирати валідаторів для певного Шарду серед усіх валідаторів, і кожні 6.4 хвилин ### довжина епохи ( змінювати валідаторів.
Сказати простіше, це означає випадкове групування вузлів, а потім розподіл роботи для незалежної валідації кожної групи вузлів.
Однак слід зазначити, що випадковість у Блокчейн є дуже складною темою, за логікою, процес генерації цього випадкового числа не повинен залежати від обчислень жодного конкретного Шардингу. Для цього обчислення багато існуючих концепцій дизайну спрямовані на розробку окремого Блоку, що підтримує всю мережу. Такий блок у Ethereum та Near називається Beacon-ланцюгом, у PolkaDot - Relay-ланцюгом, а в Cosmos - Cosmos Hub.
! [10 000 слів детальне пояснення нового публічного ланцюга Shardeum: ще одна можливість шардингу])https://img-cdn.gateio.im/webp-social/moments-6e8d3331d7d68cb512eb2eb47bd9064d.webp(
) 02 Торговельний Шардинг (Transaction Sharding )
Торговий Шардинг означає встановлення правил щодо того, "які угоди повинні бути розподілені між якими Шардингами", що дозволяє досягти мети паралельної обробки та уникнути проблеми подвійного витрачання. Відмінності в моделях бухгалтерії Блокчейн впливають на розробку торгового Шардингу.
Наразі в мережах Блокчейн існує два типи способів ведення обліку, а саме UTXO###Невитрачені транзакційні виходи, модель невикористаних транзакційних виходів ( та модель рахунків/балансів, типичним представником яких є BTC, а другим є ETH.
Модель UTXO: У BTC-транзакціях кожна транзакція має один або декілька виходів. UTXO позначає невитрачені виходи транзакцій Блокчейну, які можуть використовуватися як входи для нових транзакцій, тоді як витрачені виходи транзакцій більше не можуть бути використані. Це схоже на ситуацію з готівкою, коли покупець передає одну або кілька банкнот продавцеві, а продавець повертає покупцеві одну або кілька банкнот як здачу. У моделі UTXO транзакційний Шардинг потребує міжшарового зв'язку. Одна транзакція може включати кілька входів та кілька виходів, а концепція рахунків відсутня, також не ведеться облік залишків. Один з можливих способів: обробити значення одного з входів транзакції через хеш-функцію, щоб визначити, куди має йти дані у відповідний шар.
Щоб забезпечити, щоб записи були розміщені у правильних Шардах послідовно, значення, що вводяться в хеш-функцію, повинні походити з одного стовпця. Цей стовпець називається Шардинг Ключем. Після цього, транзакції, що генерують значення 1, розподіляються у Шард 1, а транзакції, що генерують значення 2, розподіляються у Шард 2. Однак недолік цього підходу полягає в тому, що Шарди повинні взаємодіяти, щоб уникнути атаки подвоєння витрат. Якщо обмежити міжшардові транзакції, це обмежить доступність платформи, а якщо дозволити міжшардові транзакції, доведеться зважити витрати на міжшардове спілкування та вигоди, що випливають з підвищення продуктивності.
Модель рахунків/балансів: Система записує баланс кожного рахунку, під час проведення транзакцій система перевіряє, чи є на рахунку достатньо коштів для оплати, подібно до того, як банк записує баланс кожного рахунку під час банківського переказу, лише коли баланс рахунку перевищує необхідну суму переказу, транзакція може бути виконана. У моделі рахунків/балансів, оскільки у одній транзакції є лише один вхід, достатньо розподілити транзакцію за адресою відправника, щоб забезпечити обробку кількох транзакцій одного рахунку в одному шарді, ефективно запобігаючи подвійному витраті. Тому більшість блокчейнів, які використовують технологію шардінгу, є системами бухгалтерських записів рахунків, подібними до Ethereum.
! [Шардеум: Ще одна можливість шардингу])https://img-cdn.gateio.im/webp-social/moments-4227a2e49f76cd01b23d7b5398e51a3c.webp(
) 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, що призведе до зниження ефективності обробки транзакцій. Однак, якщо не завантажити та не перевірити всю історію конкретного Шардингу, учасники можуть не бути впевненими, що їхня взаємодія є результатом певних дійсних блокових послідовностей, і що така блокова послідовність дійсно є нормативним ланцюгом у Шардингу.
Отже, в порівнянні з одною ланцюгом без шардингу, системи шардингу стикаються з новими викликами, оскільки користувачі не можуть безпосередньо і повністю перевірити дійсність та доступність будь-якого даного ланцюга, оскільки даних занадто багато. Користувачам необхідно надати максимально можливі недовірливі та практичні непрямі методи для перевірки, який ланцюг повністю доступний і дійсний, щоб вони могли визначити, який ланцюг є нормативним. На практиці, розробники Блокчейн можуть використовувати такі технології для вирішення деяких проблем верифікації: такі як комітет, SNARKs/STARKs, механізм рибалки, а також докази шахрайства та доступності даних.
Є два підходи для вирішення цієї проблеми, один з яких полягає у синхронізації між Шардингом.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
13 лайків
Нагородити
13
7
Поділіться
Прокоментувати
0/400
ExpectationFarmer
· 08-03 11:53
Шардинг? А то не можна їсти
Переглянути оригіналвідповісти на0
BuyHighSellLow
· 08-03 05:41
Шахрайство 5 років нарешті вирішено
Переглянути оригіналвідповісти на0
ShitcoinConnoisseur
· 08-03 05:40
Віталік Бутерін каже, що все правильно~
Переглянути оригіналвідповісти на0
SellTheBounce
· 08-03 05:35
Знову бачимо чергову хвилю невдах, які обдурюють людей, як лохів.
Переглянути оригіналвідповісти на0
BrokenYield
· 08-03 05:25
зітхає... ще одне розрекламоване злиття, яке нічого не вирішило. класичне крипто, якщо чесно
Переглянути оригіналвідповісти на0
SchroedingerGas
· 08-03 05:20
Знову обдурювати людей, як лохів?
Переглянути оригіналвідповісти на0
Blockblind
· 08-03 05:14
Працювали 5 років, щоб змінити лише оболонку? Нам потрібно, щоб газ був низьким!
Шардинг технології дослідження: аналіз принципів та викликів масштабування Блокчейн
Шардинг технологія: передовий досвід розширення Блокчейн
15 вересня 2022 року Ethereum завершив злиття (Merge). Це історичний момент, до якого Ethereum готувався 5 років, відтермінувавши 6 разів. Через численні налагодження та тривалу розробку, а також ефект широкої уваги, багато людей помилково вважають, що злиття природним чином принесе вищу масштабованість, безпеку та сталий розвиток, але це не так. Перехід від PoW( до PoS) - це лише зміна "колії та коліс", яка не призведе безпосередньо до швидшої роботи, більшої ємності або нижчих витрат. Реально досягти цих цілей можна лише за допомогою цілого комплексу рішень: основної мережі з можливістю Шардингу, доповненої рішеннями Layer2 для покращення масштабованості.
Як зазначив засновник Ethereum Віталік Бутерін, Шардинг є рішенням для розширення в умовах трилеми масштабованості. Це досягається шляхом розподілу вузлів у мережі на менші групи, які обробляють різні набори транзакцій і реалізують паралельну обробку. Це схоже на процес розрахунку в супермаркеті, де відкриття кількох кас може зменшити час очікування в черзі та підвищити ефективність розрахунків.
Це логіка Шардингу, проста і зрозуміла. Однак диявол у деталях - принцип і напрямок вірні, але під час реалізації завжди виникає безліч проблем. Ця стаття має на меті проаналізувати напрямок і труднощі на шляху "Шардингу", намалювати карту дослідника Шардингу, який дивиться на зірки та стоїть на землі. Одночасно порівнюючи існуючі рішення для Шардингу, знайти деякі спільні проблеми та запропонувати можливий напрямок дослідження: Shardeum та динамічний Шардинг.
! Шардеум: Ще одна можливість шардингу
Один, про "Шардинг"
Простими словами, враховуючи обмеження неможливого трикутника, виходячи з Ethereum як початкової точки координат (0,0), відповідно до "вертикального" та "горизонтального" підходів, ми розділимо методи масштабування поточного Блокчейн на дві великі категорії:
Вертикальне масштабування(Vertical Scaling): здійснюється шляхом підвищення продуктивності існуючого обладнання системи. Створення децентралізованої мережі, в якій кожен вузол має суперкомп'ютерні можливості, тобто кожен вузол потребує "кращого" обладнання. Цей спосіб є простим і ефективним, може забезпечити початкове покращення пропускної здатності, особливо підходить для високочастотної торгівлі, ігор та інших застосунків, чутливих до затримок. Однак такий спосіб масштабування обмежить рівень децентралізації мережі, оскільки витрати на запуск верифікаційних вузлів або повних вузлів зростають. Підтримка рівня децентралізації обмежена приблизним темпом зростання продуктивності обчислювального обладнання( це і є так званий "закон Мура": кількість транзисторів на чіпі подвоюється кожні два роки, а вартість обчислень зменшується вдвічі).
Горизонтальне масштабування(Horizontal Scaling): Горизонтальне масштабування зазвичай має кілька підходів. Один з них полягає в тому, щоб в контексті Блокчейн розподілити обсяг обчислень транзакцій в певній екосистемі на кілька незалежних Блокчейн, кожен з яких має своїх виробників блоків та виконавчі можливості. Цей підхід дозволяє повністю налаштувати виконавчий рівень кожного ланцюга, наприклад, вимоги до апаратного забезпечення вузлів, функції конфіденційності, витрати на газ, віртуальні машини та налаштування доступу тощо. Інший варіант горизонтального масштабування - це модульний Блокчейн, який розділяє інфраструктуру Блокчейн на виконавчий рівень, рівень доступності даних(DA) та рівень консенсусу. Найпоширеніший модульний механізм Блокчейн - це rollup. Ще один варіант полягає в тому, щоб розділити один Блокчейн на багато частин, які виконуються паралельно. Кожен фрагмент можна розглядати як окремий Блокчейн, тобто багато Блокчейн можуть виконуватись паралельно. Крім того, зазвичай існує один головний ланцюг, єдине завдання якого - підтримувати синхронізацію всіх фрагментів.
! Шардеум: Ще одна можливість шардингу
Слід зазначити, що вищезгадані підходи до масштабування не існують ізольовано, кожне із рішень знаходить компроміс у рамках неможливого трикутника, поєднуючи його з дизайном механізмів стимулювання, створених економічними силами в системі, для досягнення ефективного балансу на макро- та мікрорівнях.
Щоб обговорити "Шардинг", нам потрібно почати з самого початку.
Все ще припустимо таку ситуацію: каса в супермаркеті. Щоб підвищити ефективність обслуговування, зменшити час очікування клієнтів, ми розширюємо одну касу до 10 касових вікон. Щоб уникнути помилок у підрахунках, нам потрібно встановити єдині правила:
По-перше, якщо у нас є 10 касирів, як ми можемо розподілити їх на які вікна працювати?
По-друге, якщо у нас є 1000 клієнтів, які чекають у черзі, як вирішити, до якого вікна піде кожен клієнт для розрахунку?
По-третє, як можна підсумувати 10 окремих бухгалтерських книг, відповідних цим 10 вікнам?
По-перше, щоб уникнути ситуацій з невідповідністю обліку, як можна запобігти помилкам касирів?
Ці кілька запитань насправді відповідають кільком ключовим проблемам у Шардингу, а саме:
Як визначити, до якого Шардингу належать вузли/вірifiers у всій мережі? Тобто: як здійснити мережевий Шардинг (Network Sharding);
Як визначити, якій частині відповідає кожна транзакція? Тобто: як здійснити транзакційне шардінг (Transaction Sharding);
Як зберігаються дані Блокчейн у різних Шардингах? Тобто: як здійснюється стан Шардингу (State Sharding);
Складність означає ризик, на основі всього вищезазначеного, як уникнути розколу безпеки всієї системи?
( 01 Мережевий Шардинг)
Якщо ми спростимо розуміння Блокчейн як децентралізовану книгу обліку, то незалежно від того, чи це механізм консенсусу PoS чи PoW, метою є те, щоб різні вузли змагалися за право ведення обліку відповідно до певних установлених правил, при цьому гарантується правильність книги обліку. А мережевий Шардинг означає, що потрібні інші встановлені правила, щоб розділити мережу Блокчейн на частини, при цьому намагаючись зменшити взаємне спілкування, щоб кожен Шардинг обробляв транзакції в ланцюзі, змагаючись за право ведення обліку - тобто, правила групування вузлів.
А в цьому процесі виникає проблема: зі зростанням кількості внутрішніх вузлів Блокчейн, розділених на різні Шардинги, складність і витрати для нападника знижуються в геометричній прогресії. Ми можемо зробити висновок, що, якщо правила та результати цього процесу групування є фіксованими та передбачуваними, тоді нападнику потрібно контролювати всю Блокчейн-мережу, лише орієнтуючись на контроль одного з Шардингів, купуючи частину вузлів у цьому Шардингу.
Система Шардингу повинна розробити механізм, щоб довіряти мережі, що не буде скасування цих транзакцій з зовнішніх Шардів. До сьогодні, можливо, найкраща відповідь полягає в тому, щоб забезпечити кількість валідаторів всередині Шарду вище певного мінімального порогу, так що ймовірність нечесних валідаторів переважити окремий Шард буде дуже низькою. Найбільш поширений спосіб - побудувати певну міру непереборної випадковості, покладаючись на математичні методи, щоб звести ймовірність успіху атаки до мінімуму. Наприклад, в Ефіріумі, рішення Ефіріуму полягає в тому, щоб випадковим чином обирати валідаторів для певного Шарду серед усіх валідаторів, і кожні 6.4 хвилин ### довжина епохи ( змінювати валідаторів.
Сказати простіше, це означає випадкове групування вузлів, а потім розподіл роботи для незалежної валідації кожної групи вузлів.
Однак слід зазначити, що випадковість у Блокчейн є дуже складною темою, за логікою, процес генерації цього випадкового числа не повинен залежати від обчислень жодного конкретного Шардингу. Для цього обчислення багато існуючих концепцій дизайну спрямовані на розробку окремого Блоку, що підтримує всю мережу. Такий блок у Ethereum та Near називається Beacon-ланцюгом, у PolkaDot - Relay-ланцюгом, а в Cosmos - Cosmos Hub.
! [10 000 слів детальне пояснення нового публічного ланцюга Shardeum: ще одна можливість шардингу])https://img-cdn.gateio.im/webp-social/moments-6e8d3331d7d68cb512eb2eb47bd9064d.webp(
) 02 Торговельний Шардинг (Transaction Sharding )
Торговий Шардинг означає встановлення правил щодо того, "які угоди повинні бути розподілені між якими Шардингами", що дозволяє досягти мети паралельної обробки та уникнути проблеми подвійного витрачання. Відмінності в моделях бухгалтерії Блокчейн впливають на розробку торгового Шардингу.
Наразі в мережах Блокчейн існує два типи способів ведення обліку, а саме UTXO###Невитрачені транзакційні виходи, модель невикористаних транзакційних виходів ( та модель рахунків/балансів, типичним представником яких є BTC, а другим є ETH.
Модель UTXO: У BTC-транзакціях кожна транзакція має один або декілька виходів. UTXO позначає невитрачені виходи транзакцій Блокчейну, які можуть використовуватися як входи для нових транзакцій, тоді як витрачені виходи транзакцій більше не можуть бути використані. Це схоже на ситуацію з готівкою, коли покупець передає одну або кілька банкнот продавцеві, а продавець повертає покупцеві одну або кілька банкнот як здачу. У моделі UTXO транзакційний Шардинг потребує міжшарового зв'язку. Одна транзакція може включати кілька входів та кілька виходів, а концепція рахунків відсутня, також не ведеться облік залишків. Один з можливих способів: обробити значення одного з входів транзакції через хеш-функцію, щоб визначити, куди має йти дані у відповідний шар.
Щоб забезпечити, щоб записи були розміщені у правильних Шардах послідовно, значення, що вводяться в хеш-функцію, повинні походити з одного стовпця. Цей стовпець називається Шардинг Ключем. Після цього, транзакції, що генерують значення 1, розподіляються у Шард 1, а транзакції, що генерують значення 2, розподіляються у Шард 2. Однак недолік цього підходу полягає в тому, що Шарди повинні взаємодіяти, щоб уникнути атаки подвоєння витрат. Якщо обмежити міжшардові транзакції, це обмежить доступність платформи, а якщо дозволити міжшардові транзакції, доведеться зважити витрати на міжшардове спілкування та вигоди, що випливають з підвищення продуктивності.
Модель рахунків/балансів: Система записує баланс кожного рахунку, під час проведення транзакцій система перевіряє, чи є на рахунку достатньо коштів для оплати, подібно до того, як банк записує баланс кожного рахунку під час банківського переказу, лише коли баланс рахунку перевищує необхідну суму переказу, транзакція може бути виконана. У моделі рахунків/балансів, оскільки у одній транзакції є лише один вхід, достатньо розподілити транзакцію за адресою відправника, щоб забезпечити обробку кількох транзакцій одного рахунку в одному шарді, ефективно запобігаючи подвійному витраті. Тому більшість блокчейнів, які використовують технологію шардінгу, є системами бухгалтерських записів рахунків, подібними до Ethereum.
! [Шардеум: Ще одна можливість шардингу])https://img-cdn.gateio.im/webp-social/moments-4227a2e49f76cd01b23d7b5398e51a3c.webp(
) 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, що призведе до зниження ефективності обробки транзакцій. Однак, якщо не завантажити та не перевірити всю історію конкретного Шардингу, учасники можуть не бути впевненими, що їхня взаємодія є результатом певних дійсних блокових послідовностей, і що така блокова послідовність дійсно є нормативним ланцюгом у Шардингу.
Отже, в порівнянні з одною ланцюгом без шардингу, системи шардингу стикаються з новими викликами, оскільки користувачі не можуть безпосередньо і повністю перевірити дійсність та доступність будь-якого даного ланцюга, оскільки даних занадто багато. Користувачам необхідно надати максимально можливі недовірливі та практичні непрямі методи для перевірки, який ланцюг повністю доступний і дійсний, щоб вони могли визначити, який ланцюг є нормативним. На практиці, розробники Блокчейн можуть використовувати такі технології для вирішення деяких проблем верифікації: такі як комітет, SNARKs/STARKs, механізм рибалки, а також докази шахрайства та доступності даних.
Є два підходи для вирішення цієї проблеми, один з яких полягає у синхронізації між Шардингом.