Шардинг технологій інноваційний шлях: Shardeum та динамічний стан Шардинг
15 вересня 2022 року Ethereum завершив злиття (Merge). Це історичний момент, до якого Ethereum готувався протягом 5 років і відкладав 6 разів. Через тривалу розробку та налагодження, а також через увагу з боку громадськості, багато хто помилково вважає, що злиття природним чином призведе до більшої масштабованості, безпеки та стійкості, але насправді це не так. Перехід від PoW( до PoS) - це лише зміна колії та коліс, він не призведе безпосередньо до більшої швидкості, більшої ємності чи нижчих витрат. Реальні цілі можуть бути досягнуті лише за допомогою цілого комплексу рішень: основна мережа з можливістю Шардинг у поєднанні з рішеннями Layer2, що підвищують масштабованість.
Як зазначив засновник Ethereum Віталік Бутерін, Шардинг є рішенням для масштабованості в умовах трійки труднощів, яке полягає в розподілі вузлів у мережі на менші групи для обробки різних наборів транзакцій та досягнення паралельної обробки. Розподіляючи навантаження з обробки величезної кількості даних, необхідних для узагальнення по всій мережі, це подібно до того, як ми зменшуємо час очікування у черзі та підвищуємо ефективність розрахунків, відкриваючи декілька кас у Walmart під час покупок.
Це логіка Шардингу, пряма і проста, але диявол криється у деталях - принцип і напрямок вірні, але при реалізації завжди виникає безліч проблем. У цій статті я хочу, спростивши напрямок і труднощі на шляху "Шардингу", намалювати карту дослідника Шардингу, яка поєднує в собі погляд на зірки та тверде стояння на землі. Одночасно порівнюючи існуючі рішення Шардингу, знайти деякі спільні проблеми та запропонувати можливий напрямок дослідження: Shardeum та динамічний Шардинг.
Один. Про "Шардинг"
Простими словами, враховуючи обмеження неможливого трикутника, виходячи з ефіріуму як початкової точки координат (, 0,0), за двома підходами "вертикально" та "горизонтально", ми розділимо сучасні методи масштабування блокчейну на дві великі категорії:
Вертикальне масштабування (: досягається шляхом підвищення продуктивності існуючого апаратного забезпечення системи. Створення децентралізованої мережі, в якій кожен вузол має суперкомп'ютерні можливості, тобто кожен вузол повинен мати "краще" обладнання – цей підхід простий і ефективний, може забезпечити попереднє покращення пропускної здатності, особливо підходить для високочастотної торгівлі, ігор та інших сценаріїв, чутливих до затримок. Однак цей спосіб масштабування обмежує рівень децентралізації мережі, оскільки витрати на запуск вузлів верифікації або повних вузлів зростають. Підтримка рівня децентралізації обмежена приблизною швидкістю зростання продуктивності обчислювального апаратного забезпечення ) це так зване "Закон Мура": кількість транзисторів на чіпі подвоюється кожні два роки, а собівартість обчислень зменшується вдвічі (.
Горизонтальне масштабування ) Horizontal Scaling (: Горизонтальне масштабування зазвичай має кілька підходів. Один з них у контексті блокчейну полягає в розподілі обсягу обчислень транзакцій в рамках певної екосистеми на кілька незалежних блокчейнів, кожен з яких має своїх виробників блоків і виконавчі можливості. Цей підхід дозволяє повністю налаштовувати виконавчий рівень кожного блокчейну, наприклад, вимоги до апаратного забезпечення вузлів, функції конфіденційності, витрати на газ, віртуальні машини та налаштування дозволів тощо. Інший варіант горизонтального масштабування - це модульний блокчейн, що розділяє інфраструктуру блокчейну на виконавчий рівень, рівень доступності даних ) DA ( та рівень консенсусу. Найпоширенішим механізмом модульності блокчейнів є rollup. Є ще один спосіб - розділити один блокчейн на багато частин, які виконуються паралельно. Кожен фрагмент можна розглядати як окремий блокчейн, іншими словами, багато блокчейнів можуть виконуватися паралельно. Крім того, зазвичай є один основний блокчейн, єдине завдання якого - підтримувати синхронізацію всіх фрагментів.
Слід зазначити, що наведені вище ідеї щодо масштабування не існують ізольовано, кожне з рішень є точкою компромісу в неможливому трикутнику, у поєднанні з дизайном механізмів стимулювання, створених економічними силами в системі, для досягнення ефективного балансу на макро- та мікрорівнях.
Щоб обговорити "Шардинг", нам потрібно почати з самого початку.
Все ще припустимо таку ситуацію: розрахунок у Walmart. Щоб підвищити ефективність розрахунку та зменшити час очікування клієнтів, ми розширилися з одного касового каналу до 10 касових вікон. Щоб уникнути помилок у бухгалтерії, у цей момент нам потрібно встановити єдині правила:
По-перше, якщо у нас є 10 касирів, як їх розподілити по вікнах?
По-друге, якщо у нас є 1000 клієнтів, які чекають у черзі, як ми можемо вирішити, до якого вікна повинен піти кожен клієнт?
По-третє, як провести підсумок 10 окремих бухгалтерських книг, відповідних 10 вікнам?
По-перше, щоб уникнути ситуацій, коли рахунки не збігаються, як можна запобігти помилкам касира?
Ці кілька питань насправді відповідають кільком ключовим питанням у Шардингу, а саме:
Як визначити, до якого Шардингу належать вузли/верифікатори в усій мережі? Тобто: як здійснити мережевий Шардинг )NetworkSharding(;
Як визначити, до якого шару повинна бути призначена кожна транзакція? Тобто: як здійснити шардінг транзакцій )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 хвилини) довжина епохи( змінювати валідаторів.
Сказати простіше, це означає випадкове групування вузлів, а потім розподіл роботи для незалежної верифікації кожної групи вузлів.
Однак варто зазначити, що випадковість у блокчейні є дуже складною темою. Логічно, що процес генерації цього випадкового числа не повинен залежати від обчислень будь-якого конкретного Шардингу. Для цього обчислення багато існуючих проектних ідей полягають у розробці окремого блокчейну, який підтримує всю мережу. Такий ланцюг називається Beacon-ланцюгом в Ethereum та Near, Relay-ланцюгом в PolkaDot, а в Cosmos – Cosmos Hub.
! [Шардеум: Ще одна можливість шардингу])https://img-cdn.gateio.im/webp-social/moments-69c7de2bfe4ae7b233bec1f706fad9ad.webp(
) 02 Шардинг (Transaction Sharding) транзакцій
Шардинг транзакцій означає встановлення правил щодо "які транзакції мають бути розподілені по яких Шардах", що дозволяє досягти мети паралельної обробки та уникнути проблеми подвійних витрат. Різні моделі бухгалтерських книг у блокчейні можуть вплинути на розробку Шардингу транзакцій.
В даний час у блокчейн-мережах існує два типи механізмів обліку, а саме 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-7aa1677db6b8128b68accfe04fcda738.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, внаслідок чого ефективність обробки транзакцій знижується. Проте, якщо учасники не завантажують і не перевіряють всю історію певного шардингу, вони не можуть бути впевнені, що їхня взаємодія є результатом деякої послідовності дійсних блоків, і що така послідовність блоків справді є нормативним ланцюгом у шардингу.
Отже, порівняно з одною ланцюгом без Шардингу, система Шардингу стикається з новими викликами для користувачів.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
9 лайків
Нагородити
9
6
Поділіться
Прокоментувати
0/400
GateUser-c799715c
· 3год тому
Знову мріють про злиття?
Переглянути оригіналвідповісти на0
GasOptimizer
· 10год тому
газ коли зможе знизитися до 2gwei? Ладно, почекаю ще 5 років для цілого комплексу рішень.
Переглянути оригіналвідповісти на0
GateUser-32ed30ed
· 07-30 20:40
Чи можеш говорити людською мовою?
Переглянути оригіналвідповісти на0
CryptoTarotReader
· 07-30 05:08
Це не означає, що п'ять років були витрачені даремно.
Переглянути оригіналвідповісти на0
pumpamentalist
· 07-30 05:04
Просто знаю, що торгують merge, а результати ніякі.
Переглянути оригіналвідповісти на0
GateUser-00be86fc
· 07-30 04:57
Цей апгрейд не варто робити, краще одразу перейти на L2
Shardeum просуває інновації в технології Шардинг, досліджуючи нові шляхи динамічного стану Шардингу
Шардинг технологій інноваційний шлях: Shardeum та динамічний стан Шардинг
15 вересня 2022 року Ethereum завершив злиття (Merge). Це історичний момент, до якого Ethereum готувався протягом 5 років і відкладав 6 разів. Через тривалу розробку та налагодження, а також через увагу з боку громадськості, багато хто помилково вважає, що злиття природним чином призведе до більшої масштабованості, безпеки та стійкості, але насправді це не так. Перехід від PoW( до PoS) - це лише зміна колії та коліс, він не призведе безпосередньо до більшої швидкості, більшої ємності чи нижчих витрат. Реальні цілі можуть бути досягнуті лише за допомогою цілого комплексу рішень: основна мережа з можливістю Шардинг у поєднанні з рішеннями Layer2, що підвищують масштабованість.
Як зазначив засновник Ethereum Віталік Бутерін, Шардинг є рішенням для масштабованості в умовах трійки труднощів, яке полягає в розподілі вузлів у мережі на менші групи для обробки різних наборів транзакцій та досягнення паралельної обробки. Розподіляючи навантаження з обробки величезної кількості даних, необхідних для узагальнення по всій мережі, це подібно до того, як ми зменшуємо час очікування у черзі та підвищуємо ефективність розрахунків, відкриваючи декілька кас у Walmart під час покупок.
Це логіка Шардингу, пряма і проста, але диявол криється у деталях - принцип і напрямок вірні, але при реалізації завжди виникає безліч проблем. У цій статті я хочу, спростивши напрямок і труднощі на шляху "Шардингу", намалювати карту дослідника Шардингу, яка поєднує в собі погляд на зірки та тверде стояння на землі. Одночасно порівнюючи існуючі рішення Шардингу, знайти деякі спільні проблеми та запропонувати можливий напрямок дослідження: Shardeum та динамічний Шардинг.
Один. Про "Шардинг"
Простими словами, враховуючи обмеження неможливого трикутника, виходячи з ефіріуму як початкової точки координат (, 0,0), за двома підходами "вертикально" та "горизонтально", ми розділимо сучасні методи масштабування блокчейну на дві великі категорії:
Вертикальне масштабування (: досягається шляхом підвищення продуктивності існуючого апаратного забезпечення системи. Створення децентралізованої мережі, в якій кожен вузол має суперкомп'ютерні можливості, тобто кожен вузол повинен мати "краще" обладнання – цей підхід простий і ефективний, може забезпечити попереднє покращення пропускної здатності, особливо підходить для високочастотної торгівлі, ігор та інших сценаріїв, чутливих до затримок. Однак цей спосіб масштабування обмежує рівень децентралізації мережі, оскільки витрати на запуск вузлів верифікації або повних вузлів зростають. Підтримка рівня децентралізації обмежена приблизною швидкістю зростання продуктивності обчислювального апаратного забезпечення ) це так зване "Закон Мура": кількість транзисторів на чіпі подвоюється кожні два роки, а собівартість обчислень зменшується вдвічі (.
Горизонтальне масштабування ) Horizontal Scaling (: Горизонтальне масштабування зазвичай має кілька підходів. Один з них у контексті блокчейну полягає в розподілі обсягу обчислень транзакцій в рамках певної екосистеми на кілька незалежних блокчейнів, кожен з яких має своїх виробників блоків і виконавчі можливості. Цей підхід дозволяє повністю налаштовувати виконавчий рівень кожного блокчейну, наприклад, вимоги до апаратного забезпечення вузлів, функції конфіденційності, витрати на газ, віртуальні машини та налаштування дозволів тощо. Інший варіант горизонтального масштабування - це модульний блокчейн, що розділяє інфраструктуру блокчейну на виконавчий рівень, рівень доступності даних ) DA ( та рівень консенсусу. Найпоширенішим механізмом модульності блокчейнів є rollup. Є ще один спосіб - розділити один блокчейн на багато частин, які виконуються паралельно. Кожен фрагмент можна розглядати як окремий блокчейн, іншими словами, багато блокчейнів можуть виконуватися паралельно. Крім того, зазвичай є один основний блокчейн, єдине завдання якого - підтримувати синхронізацію всіх фрагментів.
Слід зазначити, що наведені вище ідеї щодо масштабування не існують ізольовано, кожне з рішень є точкою компромісу в неможливому трикутнику, у поєднанні з дизайном механізмів стимулювання, створених економічними силами в системі, для досягнення ефективного балансу на макро- та мікрорівнях.
Щоб обговорити "Шардинг", нам потрібно почати з самого початку.
Все ще припустимо таку ситуацію: розрахунок у Walmart. Щоб підвищити ефективність розрахунку та зменшити час очікування клієнтів, ми розширилися з одного касового каналу до 10 касових вікон. Щоб уникнути помилок у бухгалтерії, у цей момент нам потрібно встановити єдині правила:
По-перше, якщо у нас є 10 касирів, як їх розподілити по вікнах?
По-друге, якщо у нас є 1000 клієнтів, які чекають у черзі, як ми можемо вирішити, до якого вікна повинен піти кожен клієнт?
По-третє, як провести підсумок 10 окремих бухгалтерських книг, відповідних 10 вікнам?
По-перше, щоб уникнути ситуацій, коли рахунки не збігаються, як можна запобігти помилкам касира?
Ці кілька питань насправді відповідають кільком ключовим питанням у Шардингу, а саме:
Як визначити, до якого Шардингу належать вузли/верифікатори в усій мережі? Тобто: як здійснити мережевий Шардинг )NetworkSharding(;
Як визначити, до якого шару повинна бути призначена кожна транзакція? Тобто: як здійснити шардінг транзакцій )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 хвилини) довжина епохи( змінювати валідаторів.
Сказати простіше, це означає випадкове групування вузлів, а потім розподіл роботи для незалежної верифікації кожної групи вузлів.
Однак варто зазначити, що випадковість у блокчейні є дуже складною темою. Логічно, що процес генерації цього випадкового числа не повинен залежати від обчислень будь-якого конкретного Шардингу. Для цього обчислення багато існуючих проектних ідей полягають у розробці окремого блокчейну, який підтримує всю мережу. Такий ланцюг називається Beacon-ланцюгом в Ethereum та Near, Relay-ланцюгом в PolkaDot, а в Cosmos – Cosmos Hub.
! [Шардеум: Ще одна можливість шардингу])https://img-cdn.gateio.im/webp-social/moments-69c7de2bfe4ae7b233bec1f706fad9ad.webp(
) 02 Шардинг (Transaction Sharding) транзакцій
Шардинг транзакцій означає встановлення правил щодо "які транзакції мають бути розподілені по яких Шардах", що дозволяє досягти мети паралельної обробки та уникнути проблеми подвійних витрат. Різні моделі бухгалтерських книг у блокчейні можуть вплинути на розробку Шардингу транзакцій.
В даний час у блокчейн-мережах існує два типи механізмів обліку, а саме 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-7aa1677db6b8128b68accfe04fcda738.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, внаслідок чого ефективність обробки транзакцій знижується. Проте, якщо учасники не завантажують і не перевіряють всю історію певного шардингу, вони не можуть бути впевнені, що їхня взаємодія є результатом деякої послідовності дійсних блоків, і що така послідовність блоків справді є нормативним ланцюгом у шардингу.
Отже, порівняно з одною ланцюгом без Шардингу, система Шардингу стикається з новими викликами для користувачів.