Shardeum та динамічна шардинг: інша можливість для дослідження шардингу
15 вересня 2022 року Ethereum завершив довгоочікуване злиття (Merge). Цей історичний момент позначає перехід Ethereum від доказу роботи (PoW) до доказу частки (PoS), на що команда Ethereum готувалася протягом 5 років та відкладала 6 разів. Однак багато хто помилково вважає, що злиття природним чином призведе до підвищення масштабованості, безпеки та сталості, але це не так. Злиття лише змінило "колію та колеса", і не принесе безпосередньо швидшого зростання, більшої ємності чи нижчих витрат. Реально досягти цих цілей можна лише за допомогою цілого набору рішень: основна мережа з можливостями Шардингу у поєднанні з рішеннями Layer2 для підвищення масштабованості.
Як зазначив засновник Ethereum Віталік Бутерін, Шардинг є рішенням для масштабування в умовах трилеми масштабованості. Він розділяє вузли в мережі на менші групи, що обробляють різні набори транзакцій і реалізують паралельну обробку. Розподіляючи навантаження з обробки величезних обсягів даних, необхідних для агрегування по всій мережі, це можна уявити так само, як при покупках у супермаркеті, де відкриття кількох кас може суттєво зменшити час очікування в черзі та підвищити ефективність розрахунків.
Це основна логіка Шардингу, проста і зрозуміла. Але диявол у деталях - принцип і напрямок вірні, але під час реалізації завжди виникає багато проблем. Ця стаття має на меті впорядкувати напрямок і труднощі на шляху "Шардингу", створивши карту для дослідників Шардингу. Одночасно, порівнюючи наявні рішення Шардингу, знайти деякі загальні проблеми і запропонувати здійсненний напрямок дослідження: Shardeum та динамічний Шардинг.
Один. Про "Шардинг"
Простими словами, зважаючи на обмеження неможливого трикутника, від точки координатної системи Ethereum (, 0), виходячи з двох підходів – "вертикального" та "горизонтального", ми класифікуємо методи масштабування сучасного блокчейну на дві великі категорії:
Вертикальне масштабування(Vertical Scaling): досягається шляхом підвищення продуктивності існуючого апаратного забезпечення системи. Створення децентралізованої мережі, в якій кожен вузол має суперкомп'ютерні можливості, тобто кожен вузол потребує "кращого" апаратного забезпечення. Цей спосіб є простим і ефективним, може забезпечити початкове покращення пропускної здатності, особливо підходить для високоінтенсивної торгівлі, ігор та інших сценаріїв застосування, чутливих до затримок. Однак цей спосіб масштабування обмежує рівень децентралізації мережі, оскільки вартість запуску верифікаційних вузлів або повних вузлів зростає. Підтримка децентралізованого рівня обмежена приблизною швидкістю зростання продуктивності обчислювального апаратного забезпечення( це так зване "Закон Мура": кількість транзисторів на чіпі подвоюється кожні два роки, вартість обчислень зменшується вдвічі).
Горизонтальне масштабування(Horizontal Scaling): Горизонтальне масштабування зазвичай має кілька підходів. Один із них у контексті блокчейну полягає в розподілі обсягу обчислень транзакцій в межах певної екосистеми на кілька незалежних блокчейнів, кожен з яких має своїх виробників блоків і виконавчу здатність. Цей спосіб дозволяє повністю налаштувати виконавчий рівень кожного блокчейну, наприклад, вимоги до апаратного забезпечення вузлів, функції конфіденційності, витрати на gas, віртуальні машини та налаштування доступу тощо. Інший підхід до горизонтального масштабування — це модульний блокчейн, який розділяє інфраструктуру блокчейну на виконавчий рівень, рівень доступності даних(DA) та рівень консенсусу. Найпоширеніший механізм модульного блокчейну — це rollup. Ще один варіант — розділити один блокчейн на багато частин і виконувати їх паралельно. Кожен фрагмент можна розглядати як окремий блокчейн, тобто багато блокчейнів можуть працювати паралельно. Крім того, зазвичай є один головний блокчейн, єдиним завданням якого є підтримка синхронізації всіх фрагментів.
Потрібно зазначити, що наведенні вище ідеї розширення не існують ізольовано, кожне з рішень є компромісом у рамках неможливого трикутника, поєднуючи з системою економічні сили, які створюють механізми стимулювання, для досягнення ефективного балансу на макро- та мікрорівнях.
Щоб обговорити "Шардинг", нам потрібно почати з самого початку.
Все ще припустимо таку ситуацію: при покупках у супермаркеті, щоб підвищити ефективність розрахунків і знизити час очікування клієнтів, ми розширюємо від одного касового вікна до 10 касових вікон. Щоб уникнути помилок у бухгалтерії, в цей момент нам потрібно встановити єдині правила:
По-перше, якщо у нас є 10 касирів, як ми повинні розподілити їх по вікнах?
По-друге, якщо ми маємо 1000 клієнтів, які чекають у черзі, як вирішити, до якого вікна повинен піти кожен клієнт для розрахунку?
По-третє, як підсумувати ці 10 окремих бухгалтерських книг, відповідно до цих 10 вікон?
По-перше, щоб уникнути ситуацій, коли рахунки не збігаються, як можна запобігти помилкам касирів?
Ці кілька питань насправді відповідають кільком ключовим питанням у Шардингу, а саме:
Як визначити, до якого Шардингу належать вузли/валідатори в усій мережі? Тобто: як здійснити мережевий Шардинг (Network Sharding);
Як визначити, яка частина транзакції буде призначена кожному Шардингу? Тобто: як здійснити шардінг транзакції (Transaction Sharding);
Як зберігати дані блокчейну в різних Шардинг? Тобто: як здійснити стан Шардинг (State Sharding);
Складність означає ризик, на основі всього вищезазначеного, як уникнути розколу безпеки всієї системи?
01 Мережевий Шардинг (
Якщо ми просто розглянемо блокчейн як децентралізований реєстр, незалежно від того, чи це механізм консенсусу 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 Chain, у PolkaDot - Relay Chain, а в Cosmos - Cosmos Hub.
![Детальний огляд нової публічної блокчейн-мережі Shardeum: Шардинг як альтернатива])https://img-cdn.gateio.im/webp-social/moments-6e8d3331d7d68cb512eb2eb47bd9064d.webp(
) 02 Транзакційний Шардинг ###
Шардинг транзакцій означає розробку правил щодо "які транзакції повинні бути розподілені по яких шардам", що дозволяє досягти мети паралельної обробки та уникнути проблеми подвійних витрат. Відмінності в моделях бухгалтерських книг блокчейну можуть впливати на розробку шардингу транзакцій.
Наразі в мережі блокчейн існує два типи методів обліку, а саме UTXO(Unspent Transaction Outputs, модель невитрачених транзакцій ) та модель рахунку/балансу, типовим представником першого є BTC, а другого - ETH.
Модель UTXO: У BTC-транзакціях кожна транзакція має один або кілька виходів, UTXO означає невитрачені виходи транзакцій в блокчейні, які можуть бути використані як вхід для нових транзакцій, в той час як витрачені виходи транзакцій не можуть бути витрачені знову, подібно до того, як відбувається оплата та здача в паперових грошах: клієнт передає один або кілька паперових купюр продавцеві, а продавець повертає один або кілька паперових купюр клієнту. В умовах моделі UTXO, розподіл транзакцій потребує міжшардингового зв'язку. Одна транзакція може включати кілька входів і кілька виходів, концепції облікового запису тут немає, і не ведеться облік залишків, один з можливих способів: за певним вхідним значенням транзакції обробити його через хеш-функцію, щоб отримати дискретне хеш-значення, яке визначає, куди повинні відправлятися дані в певний шардинг.
Щоб забезпечити розміщення записів у правильних Шардингах послідовним чином, значення, що вводяться в хеш-функцію, повинні походити з одного стовпця. Цей стовпець називається Shard Key. Після цього транзакції, що генерують значення 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, через що ефективність обробки транзакцій знижується. Але якщо не
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
8 лайків
Нагородити
8
4
Репост
Поділіться
Прокоментувати
0/400
ThreeHornBlasts
· 08-09 22:54
Знову почали розповідати байки.
Переглянути оригіналвідповісти на0
CrossChainBreather
· 08-09 22:52
Злиття завершено, і що далі? Все ще не працює?
Переглянути оригіналвідповісти на0
DecentralizeMe
· 08-09 22:39
П'ять років готували що? Все вийшло з-під контролю, гаразд?
Shardeum: Динамічний стан Шардинг досліджує новий напрямок розширення Блокчейн
Shardeum та динамічна шардинг: інша можливість для дослідження шардингу
15 вересня 2022 року Ethereum завершив довгоочікуване злиття (Merge). Цей історичний момент позначає перехід Ethereum від доказу роботи (PoW) до доказу частки (PoS), на що команда Ethereum готувалася протягом 5 років та відкладала 6 разів. Однак багато хто помилково вважає, що злиття природним чином призведе до підвищення масштабованості, безпеки та сталості, але це не так. Злиття лише змінило "колію та колеса", і не принесе безпосередньо швидшого зростання, більшої ємності чи нижчих витрат. Реально досягти цих цілей можна лише за допомогою цілого набору рішень: основна мережа з можливостями Шардингу у поєднанні з рішеннями Layer2 для підвищення масштабованості.
Як зазначив засновник Ethereum Віталік Бутерін, Шардинг є рішенням для масштабування в умовах трилеми масштабованості. Він розділяє вузли в мережі на менші групи, що обробляють різні набори транзакцій і реалізують паралельну обробку. Розподіляючи навантаження з обробки величезних обсягів даних, необхідних для агрегування по всій мережі, це можна уявити так само, як при покупках у супермаркеті, де відкриття кількох кас може суттєво зменшити час очікування в черзі та підвищити ефективність розрахунків.
Це основна логіка Шардингу, проста і зрозуміла. Але диявол у деталях - принцип і напрямок вірні, але під час реалізації завжди виникає багато проблем. Ця стаття має на меті впорядкувати напрямок і труднощі на шляху "Шардингу", створивши карту для дослідників Шардингу. Одночасно, порівнюючи наявні рішення Шардингу, знайти деякі загальні проблеми і запропонувати здійсненний напрямок дослідження: Shardeum та динамічний Шардинг.
Один. Про "Шардинг"
Простими словами, зважаючи на обмеження неможливого трикутника, від точки координатної системи Ethereum (, 0), виходячи з двох підходів – "вертикального" та "горизонтального", ми класифікуємо методи масштабування сучасного блокчейну на дві великі категорії:
Вертикальне масштабування(Vertical Scaling): досягається шляхом підвищення продуктивності існуючого апаратного забезпечення системи. Створення децентралізованої мережі, в якій кожен вузол має суперкомп'ютерні можливості, тобто кожен вузол потребує "кращого" апаратного забезпечення. Цей спосіб є простим і ефективним, може забезпечити початкове покращення пропускної здатності, особливо підходить для високоінтенсивної торгівлі, ігор та інших сценаріїв застосування, чутливих до затримок. Однак цей спосіб масштабування обмежує рівень децентралізації мережі, оскільки вартість запуску верифікаційних вузлів або повних вузлів зростає. Підтримка децентралізованого рівня обмежена приблизною швидкістю зростання продуктивності обчислювального апаратного забезпечення( це так зване "Закон Мура": кількість транзисторів на чіпі подвоюється кожні два роки, вартість обчислень зменшується вдвічі).
Горизонтальне масштабування(Horizontal Scaling): Горизонтальне масштабування зазвичай має кілька підходів. Один із них у контексті блокчейну полягає в розподілі обсягу обчислень транзакцій в межах певної екосистеми на кілька незалежних блокчейнів, кожен з яких має своїх виробників блоків і виконавчу здатність. Цей спосіб дозволяє повністю налаштувати виконавчий рівень кожного блокчейну, наприклад, вимоги до апаратного забезпечення вузлів, функції конфіденційності, витрати на gas, віртуальні машини та налаштування доступу тощо. Інший підхід до горизонтального масштабування — це модульний блокчейн, який розділяє інфраструктуру блокчейну на виконавчий рівень, рівень доступності даних(DA) та рівень консенсусу. Найпоширеніший механізм модульного блокчейну — це rollup. Ще один варіант — розділити один блокчейн на багато частин і виконувати їх паралельно. Кожен фрагмент можна розглядати як окремий блокчейн, тобто багато блокчейнів можуть працювати паралельно. Крім того, зазвичай є один головний блокчейн, єдиним завданням якого є підтримка синхронізації всіх фрагментів.
Потрібно зазначити, що наведенні вище ідеї розширення не існують ізольовано, кожне з рішень є компромісом у рамках неможливого трикутника, поєднуючи з системою економічні сили, які створюють механізми стимулювання, для досягнення ефективного балансу на макро- та мікрорівнях.
Щоб обговорити "Шардинг", нам потрібно почати з самого початку.
Все ще припустимо таку ситуацію: при покупках у супермаркеті, щоб підвищити ефективність розрахунків і знизити час очікування клієнтів, ми розширюємо від одного касового вікна до 10 касових вікон. Щоб уникнути помилок у бухгалтерії, в цей момент нам потрібно встановити єдині правила:
По-перше, якщо у нас є 10 касирів, як ми повинні розподілити їх по вікнах?
По-друге, якщо ми маємо 1000 клієнтів, які чекають у черзі, як вирішити, до якого вікна повинен піти кожен клієнт для розрахунку?
По-третє, як підсумувати ці 10 окремих бухгалтерських книг, відповідно до цих 10 вікон?
По-перше, щоб уникнути ситуацій, коли рахунки не збігаються, як можна запобігти помилкам касирів?
Ці кілька питань насправді відповідають кільком ключовим питанням у Шардингу, а саме:
Як визначити, до якого Шардингу належать вузли/валідатори в усій мережі? Тобто: як здійснити мережевий Шардинг (Network Sharding);
Як визначити, яка частина транзакції буде призначена кожному Шардингу? Тобто: як здійснити шардінг транзакції (Transaction Sharding);
Як зберігати дані блокчейну в різних Шардинг? Тобто: як здійснити стан Шардинг (State Sharding);
Складність означає ризик, на основі всього вищезазначеного, як уникнути розколу безпеки всієї системи?
01 Мережевий Шардинг (
Якщо ми просто розглянемо блокчейн як децентралізований реєстр, незалежно від того, чи це механізм консенсусу 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 Chain, у PolkaDot - Relay Chain, а в Cosmos - Cosmos Hub.
![Детальний огляд нової публічної блокчейн-мережі Shardeum: Шардинг як альтернатива])https://img-cdn.gateio.im/webp-social/moments-6e8d3331d7d68cb512eb2eb47bd9064d.webp(
) 02 Транзакційний Шардинг ###
Шардинг транзакцій означає розробку правил щодо "які транзакції повинні бути розподілені по яких шардам", що дозволяє досягти мети паралельної обробки та уникнути проблеми подвійних витрат. Відмінності в моделях бухгалтерських книг блокчейну можуть впливати на розробку шардингу транзакцій.
Наразі в мережі блокчейн існує два типи методів обліку, а саме UTXO(Unspent Transaction Outputs, модель невитрачених транзакцій ) та модель рахунку/балансу, типовим представником першого є BTC, а другого - ETH.
Модель UTXO: У BTC-транзакціях кожна транзакція має один або кілька виходів, UTXO означає невитрачені виходи транзакцій в блокчейні, які можуть бути використані як вхід для нових транзакцій, в той час як витрачені виходи транзакцій не можуть бути витрачені знову, подібно до того, як відбувається оплата та здача в паперових грошах: клієнт передає один або кілька паперових купюр продавцеві, а продавець повертає один або кілька паперових купюр клієнту. В умовах моделі UTXO, розподіл транзакцій потребує міжшардингового зв'язку. Одна транзакція може включати кілька входів і кілька виходів, концепції облікового запису тут немає, і не ведеться облік залишків, один з можливих способів: за певним вхідним значенням транзакції обробити його через хеш-функцію, щоб отримати дискретне хеш-значення, яке визначає, куди повинні відправлятися дані в певний шардинг.
Щоб забезпечити розміщення записів у правильних Шардингах послідовним чином, значення, що вводяться в хеш-функцію, повинні походити з одного стовпця. Цей стовпець називається Shard Key. Після цього транзакції, що генерують значення 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, через що ефективність обробки транзакцій знижується. Але якщо не