Шардинг технологии инновационный путь: Shardeum и динамическое состояние шардинга
15 сентября 2022 года Эфириум завершил слияние (Merge). Это исторический момент, к которому Эфириум готовился 5 лет и 6 раз откладывал. Из-за длительной разработки и отладки, а также ощутимого эффекта внимания, многие люди ошибочно полагали, что слияние естественным образом приведет к большей масштабируемости, безопасности и устойчивости, но на самом деле это не так. Переход от PoW( к PoS) — это всего лишь замена рельсов и колес, он не приведет к более высокой скорости, большему объему или меньшим расходам. Реализовать эти цели может только целый набор решений: основная сеть с возможностью Шардинг в сочетании с улучшенными масштабируемыми решениями второго уровня.
Как указал соучредитель Ethereum Виталик Бутерин, Шардинг является решением для масштабируемости в условиях тройной сложности, разделяя узлы в сети на меньшие группы, которые обрабатывают различные наборы транзакций и обеспечивают параллельную обработку. Распределяя нагрузку по обработке огромного объема данных, необходимых для агрегирования по всей сети, это похоже на то, как мы можем сократить время ожидания и повысить эффективность расчетов, открыв несколько кассовых каналов в Walmart.
Это логика Шардинга, простая и прямая, однако дьявол кроется в деталях - принципы и направление верны, но на практике всегда возникают множество проблем. В этой статье мы хотим упорядочить направление и ловушки на пути к "Шардингу", чтобы создать карту исследователя Шардинга, смотрящего на звездное небо и стоящего на земле. Также, сравнив существующие решения по Шардингу, мы выявим некоторые общие проблемы и предложим жизнеспособное направление для исследований: Shardeum и динамический Шардинг.
Один. О "Шардинг"
Простыми словами, учитывая ограничения невозможного треугольника, начиная с Ethereum как исходной точки координат (0,0), согласно двум подходам: "вертикальному" и "горизонтальному", мы разделяем текущие методы расширяемости блокчейна на две основные категории:
Вертикальное масштабирование (: достигается за счет повышения производительности существующего оборудования системы. Создание децентрализованной сети, где каждый узел имеет суперкомпьютерные мощности, то есть каждый узел требует "лучшее" оборудование - этот способ прост и эффективен, он может достичь предварительного улучшения пропускной способности, особенно подходит для высокочастотной торговли, игр и других приложений, чувствительных к задержке. Однако этот способ масштабирования ограничивает уровень децентрализации сети, поскольку стоимость запуска узлов проверки или полных узлов возрастает. Поддержание уровня децентрализации ограничено приблизительной скоростью роста производительности вычислительного оборудования ) это то, что называется "законом Мура": количество транзисторов на чипе удваивается каждые два года, а стоимость вычислений уменьшается вдвое (.
Горизонтальное масштабирование)Горизонтальное масштабирование(: Горизонтальное масштабирование обычно имеет несколько подходов. Один из них в контексте блокчейна заключается в распределении объема вычислений транзакций в экосистеме на несколько независимых блокчейнов, каждый из которых имеет своих производителей блоков и возможности исполнения. Этот подход позволяет полностью настроить уровень исполнения каждого блокчейна, например, требования к оборудованию узлов, функции конфиденциальности, комиссии за газ, виртуальные машины и настройки разрешений и т.д. Другой подход к горизонтальному масштабированию – это модульный блокчейн, который разделяет инфраструктуру блокчейна на уровень исполнения, уровень доступности данных)DA( и уровень консенсуса. Самым распространенным модульным механизмом блокчейна является rollup. Еще один подход заключается в разделении одного блокчейна на множество шардов и их параллельном исполнении. Каждый шард можно рассматривать как блокчейн, то есть множество блокчейнов могут исполняться параллельно. Кроме того, обычно существует один основной блокчейн, единственной задачей которого является поддержание синхронизации всех шардов.
Необходимо отметить, что вышеописанные подходы к масштабированию не существуют изолированно, каждая из решений находит компромисс в рамках невозможного треугольника, сочетая с механизмом стимулов, созданным экономическими силами в системе, для достижения эффективного баланса на макро- и микроуровнях.
Чтобы обсудить "Шардинг", нам нужно начать с нуля.
Предположим, что существует такая ситуация: касса в Walmart. Чтобы повысить эффективность расчетов и сократить время ожидания клиентов, мы расширяем число кассовых окон с одного до десяти. Чтобы избежать ошибок в учете, в этот момент нам необходимо установить единые правила:
Во-первых, если у нас есть 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 решение заключается в том, чтобы случайным образом выбирать валидаторов для определенного шарда из всех валидаторов, и каждые 6.4 минуты ) длина эпохи ( валидаторы меняются.
Говоря проще, это означает случайное распределение узлов по группам, а затем распределение работы для независимой проверки узлами в каждой группе.
Однако следует отметить, что случайность в блокчейне является очень сложной темой, и с логической точки зрения процесс генерации этого случайного числа не должен зависеть от вычислений какого-либо конкретного Шардинга. Для этих вычислений многие существующие концепции разрабатывают отдельный блокчейн, который поддерживает всю сеть. Такая цепочка называется Beacon-цепочкой в Ethereum и Near, Relay-цепочкой в PolkaDot, и Cosmos Hub в Cosmos.
! [Шардеум: еще одна возможность шардинга])https://img-cdn.gateio.im/webp-social/moments-69c7de2bfe4ae7b233bec1f706fad9ad.webp(
) 02 транзакции шардинг (Transaction Sharding)
Торговый шардинг относится к правилам, касающимся "какие транзакции должны быть распределены по каким шардом", что позволяет достигать целей параллельной обработки и предотвращать возникновение проблемы двойной траты. Различные модели бухгалтерского учета блокчейна могут повлиять на разработку торгового шардинга.
В настоящее время в блокчейн-сетях существует два типа методов ведения учета: UTXO### Unspent Transaction Outputs, модель неиспользуемых транзакционных выходов ( и модель счета/баланса, типичным представителем которой является BTC, в то время как ETH относится к последней.
Модель UTXO: в BTC-транзакциях каждая транзакция имеет один или несколько выходов. UTXO обозначает необработанные выходы транзакций в блокчейне, которые могут использоваться в качестве входов для новых транзакций, в то время как уже использованные выходы транзакций больше не могут быть использованы. Это похоже на ситуацию с наличными, когда покупатель передает одну или несколько банкнот продавцу, а продавец, в свою очередь, возвращает одну или несколько банкнот покупателю в качестве сдачи. В модели UTXO для расщепления транзакций требуется межфрагментная связь. Одна транзакция может включать несколько входов и несколько выходов, концепции счета не существует, и не ведется учёт баланса. Один из возможных способов: поместить его в хэш-функцию согласно значению какого-либо входа транзакции, чтобы получить дискретное хэш-значение для определения того, в какой фрагмент должны направляться данные. Вот так:
Чтобы гарантировать, что записи помещаются в правильные Шардинги последовательным образом, значения, вводимые в хэш-функцию, должны поступать из одного и того же столбца. Этот столбец называется ключом Шардинга. После этого все транзакции, которые дают значение 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
· 4ч назад
Снова громко говорят о слиянии мечты.
Посмотреть ОригиналОтветить0
GasOptimizer
· 11ч назад
Газ когда сможет упасть до 2гвеи? Ладно, подождем целую ловушку еще 5 лет.
Посмотреть ОригиналОтветить0
GateUser-32ed30ed
· 07-30 20:40
Можешь говорить по-человечески?
Посмотреть ОригиналОтветить0
CryptoTarotReader
· 07-30 05:08
Это не значит, что пять лет были потрачены зря.
Посмотреть ОригиналОтветить0
pumpamentalist
· 07-30 05:04
Знал, что только спекулирую на merge, а в итоге что от этого?
Shardeum продвигает инновации в технологии Шардинг, исследуя новый путь динамического состояния Шардинга
Шардинг технологии инновационный путь: Shardeum и динамическое состояние шардинга
15 сентября 2022 года Эфириум завершил слияние (Merge). Это исторический момент, к которому Эфириум готовился 5 лет и 6 раз откладывал. Из-за длительной разработки и отладки, а также ощутимого эффекта внимания, многие люди ошибочно полагали, что слияние естественным образом приведет к большей масштабируемости, безопасности и устойчивости, но на самом деле это не так. Переход от PoW( к PoS) — это всего лишь замена рельсов и колес, он не приведет к более высокой скорости, большему объему или меньшим расходам. Реализовать эти цели может только целый набор решений: основная сеть с возможностью Шардинг в сочетании с улучшенными масштабируемыми решениями второго уровня.
Как указал соучредитель Ethereum Виталик Бутерин, Шардинг является решением для масштабируемости в условиях тройной сложности, разделяя узлы в сети на меньшие группы, которые обрабатывают различные наборы транзакций и обеспечивают параллельную обработку. Распределяя нагрузку по обработке огромного объема данных, необходимых для агрегирования по всей сети, это похоже на то, как мы можем сократить время ожидания и повысить эффективность расчетов, открыв несколько кассовых каналов в Walmart.
Это логика Шардинга, простая и прямая, однако дьявол кроется в деталях - принципы и направление верны, но на практике всегда возникают множество проблем. В этой статье мы хотим упорядочить направление и ловушки на пути к "Шардингу", чтобы создать карту исследователя Шардинга, смотрящего на звездное небо и стоящего на земле. Также, сравнив существующие решения по Шардингу, мы выявим некоторые общие проблемы и предложим жизнеспособное направление для исследований: Shardeum и динамический Шардинг.
Один. О "Шардинг"
Простыми словами, учитывая ограничения невозможного треугольника, начиная с Ethereum как исходной точки координат (0,0), согласно двум подходам: "вертикальному" и "горизонтальному", мы разделяем текущие методы расширяемости блокчейна на две основные категории:
Вертикальное масштабирование (: достигается за счет повышения производительности существующего оборудования системы. Создание децентрализованной сети, где каждый узел имеет суперкомпьютерные мощности, то есть каждый узел требует "лучшее" оборудование - этот способ прост и эффективен, он может достичь предварительного улучшения пропускной способности, особенно подходит для высокочастотной торговли, игр и других приложений, чувствительных к задержке. Однако этот способ масштабирования ограничивает уровень децентрализации сети, поскольку стоимость запуска узлов проверки или полных узлов возрастает. Поддержание уровня децентрализации ограничено приблизительной скоростью роста производительности вычислительного оборудования ) это то, что называется "законом Мура": количество транзисторов на чипе удваивается каждые два года, а стоимость вычислений уменьшается вдвое (.
Горизонтальное масштабирование)Горизонтальное масштабирование(: Горизонтальное масштабирование обычно имеет несколько подходов. Один из них в контексте блокчейна заключается в распределении объема вычислений транзакций в экосистеме на несколько независимых блокчейнов, каждый из которых имеет своих производителей блоков и возможности исполнения. Этот подход позволяет полностью настроить уровень исполнения каждого блокчейна, например, требования к оборудованию узлов, функции конфиденциальности, комиссии за газ, виртуальные машины и настройки разрешений и т.д. Другой подход к горизонтальному масштабированию – это модульный блокчейн, который разделяет инфраструктуру блокчейна на уровень исполнения, уровень доступности данных)DA( и уровень консенсуса. Самым распространенным модульным механизмом блокчейна является rollup. Еще один подход заключается в разделении одного блокчейна на множество шардов и их параллельном исполнении. Каждый шард можно рассматривать как блокчейн, то есть множество блокчейнов могут исполняться параллельно. Кроме того, обычно существует один основной блокчейн, единственной задачей которого является поддержание синхронизации всех шардов.
Необходимо отметить, что вышеописанные подходы к масштабированию не существуют изолированно, каждая из решений находит компромисс в рамках невозможного треугольника, сочетая с механизмом стимулов, созданным экономическими силами в системе, для достижения эффективного баланса на макро- и микроуровнях.
Чтобы обсудить "Шардинг", нам нужно начать с нуля.
Предположим, что существует такая ситуация: касса в Walmart. Чтобы повысить эффективность расчетов и сократить время ожидания клиентов, мы расширяем число кассовых окон с одного до десяти. Чтобы избежать ошибок в учете, в этот момент нам необходимо установить единые правила:
Во-первых, если у нас есть 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 решение заключается в том, чтобы случайным образом выбирать валидаторов для определенного шарда из всех валидаторов, и каждые 6.4 минуты ) длина эпохи ( валидаторы меняются.
Говоря проще, это означает случайное распределение узлов по группам, а затем распределение работы для независимой проверки узлами в каждой группе.
Однако следует отметить, что случайность в блокчейне является очень сложной темой, и с логической точки зрения процесс генерации этого случайного числа не должен зависеть от вычислений какого-либо конкретного Шардинга. Для этих вычислений многие существующие концепции разрабатывают отдельный блокчейн, который поддерживает всю сеть. Такая цепочка называется Beacon-цепочкой в Ethereum и Near, Relay-цепочкой в PolkaDot, и Cosmos Hub в Cosmos.
! [Шардеум: еще одна возможность шардинга])https://img-cdn.gateio.im/webp-social/moments-69c7de2bfe4ae7b233bec1f706fad9ad.webp(
) 02 транзакции шардинг (Transaction Sharding)
Торговый шардинг относится к правилам, касающимся "какие транзакции должны быть распределены по каким шардом", что позволяет достигать целей параллельной обработки и предотвращать возникновение проблемы двойной траты. Различные модели бухгалтерского учета блокчейна могут повлиять на разработку торгового шардинга.
В настоящее время в блокчейн-сетях существует два типа методов ведения учета: UTXO### Unspent Transaction Outputs, модель неиспользуемых транзакционных выходов ( и модель счета/баланса, типичным представителем которой является BTC, в то время как ETH относится к последней.
Модель UTXO: в BTC-транзакциях каждая транзакция имеет один или несколько выходов. UTXO обозначает необработанные выходы транзакций в блокчейне, которые могут использоваться в качестве входов для новых транзакций, в то время как уже использованные выходы транзакций больше не могут быть использованы. Это похоже на ситуацию с наличными, когда покупатель передает одну или несколько банкнот продавцу, а продавец, в свою очередь, возвращает одну или несколько банкнот покупателю в качестве сдачи. В модели UTXO для расщепления транзакций требуется межфрагментная связь. Одна транзакция может включать несколько входов и несколько выходов, концепции счета не существует, и не ведется учёт баланса. Один из возможных способов: поместить его в хэш-функцию согласно значению какого-либо входа транзакции, чтобы получить дискретное хэш-значение для определения того, в какой фрагмент должны направляться данные. Вот так:
Чтобы гарантировать, что записи помещаются в правильные Шардинги последовательным образом, значения, вводимые в хэш-функцию, должны поступать из одного и того же столбца. Этот столбец называется ключом Шардинга. После этого все транзакции, которые дают значение 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, что снижает эффективность обработки транзакций. Однако, если не загружать и не проверять всю историю конкретного Шардинга, участники не могут быть уверены, что их взаимодействие является результатом некоторой последовательности действительных блоков и что такая последовательность блоков действительно является нормативной цепочкой в Шардинге.
Таким образом, по сравнению с одноцепочечной системой без шардинга, система шардинга сталкивается с новой проблемой: пользователи не