Shardeum и динамическое состояние Шардинга: другой возможный путь исследования Шардинга
15 сентября 2022 года Ethereum завершил долгожданное слияние (Merge). Этот исторический момент ознаменовал переход Ethereum от Proof of Work (PoW) к Proof of Stake (PoS), на что команда Ethereum подготовилась в течение 5 лет и шесть раз откладывала. Однако многие ошибочно полагают, что слияние автоматически приведет к более высокой масштабируемости, безопасности и устойчивости, но это не так. Слияние всего лишь заменило "рельсы и колеса", и не приведет к более быстрой скорости, большей емкости или более низким расходам. Реальные достижения этих целей возможны только с помощью полного набора решений: основной сети с возможностями шардирования в сочетании с улучшенными масштабируемыми решениями второго уровня.
Как указал основатель Ethereum Виталик Бутерин, Шардинг является одним из решений для масштабирования в рамках тройственной проблемы масштабируемости. Он разделяет узлы в сети на меньшие группы, обрабатывающие разные наборы транзакций и осуществляющие параллельную обработку. Разделяя нагрузку по обработке огромного объема данных, необходимого для сводки по всей сети, это похоже на то, как мы оплачиваем покупки в супермаркете: открытие нескольких кассовых линий может наглядно сократить время ожидания и повысить эффективность расчетов.
Это основная логика Шардинга, простая и прямая. Однако дьявол кроется в деталях - принцип и направление верны, но при реализации всегда возникают множество проблем. Эта статья направлена на то, чтобы прояснить направление и трудности на пути "Шардинга", нарисовать карту исследователей Шардинга. Одновременно, сравнивая существующие решения Шардинга, найти некоторые общие проблемы и предложить жизнеспособное направление исследования: Shardeum и динамический Шардинг.
Простыми словами, учитывая ограничения невозможного треугольника, начиная с Эфириума как исходной точки координат (, 0), в соответствии с двумя подходами "по вертикали" и "по горизонтали", мы разделим методы масштабируемости текущей блокчейн-технологии на две большие категории:
Вертикальное масштабирование(Vertical Scaling): достигается путем повышения производительности существующего оборудования системы. Создание децентрализованной сети, в которой каждый узел обладает суперкомпьютерной мощностью, т.е. каждый узел требует "лучшего" оборудования. Этот способ прост и эффективен, позволяет достичь предварительного улучшения пропускной способности, особенно подходит для высокочастотной торговли, игр и других приложений, чувствительных к задержкам. Однако этот способ масштабирования ограничивает уровень децентрализации сети, так как стоимость запуска проверочных узлов или полных узлов возрастает. Поддержание уровня децентрализации ограничено приблизительной скоростью роста производительности вычислительного оборудования( это и есть так называемая "закон Мура": количество транзисторов на чипе удваивается каждые два года, а стоимость вычислений уменьшается вдвое).
Горизонтальное масштабирование(Horizontal Scaling): Горизонтальное масштабирование обычно имеет несколько подходов. Один из них заключается в том, чтобы в контексте блокчейна распределить объем вычислений транзакций в определенной экосистеме на несколько независимых блокчейнов, каждый из которых имеет своих производителей блоков и возможности выполнения. Этот подход позволяет полностью настроить уровень выполнения каждого блокчейна, например, требования к аппаратному обеспечению узлов, функции конфиденциальности, газовые сборы, виртуальные машины и настройки разрешений. Другой подход к горизонтальному масштабированию - это модульный блокчейн, который делит инфраструктуру блокчейна на уровни выполнения, уровня доступности данных(DA) и уровня согласия. Наиболее распространенный модульный механизм блокчейна - это rollup. Есть еще один способ, который заключается в том, чтобы разделить один блокчейн на много частей и выполнять их параллельно. Каждое деление можно рассматривать как отдельный блокчейн, то есть множество блокчейнов могут выполняться параллельно. Кроме того, обычно есть одна основная цепочка, единственная задача которой - поддерживать синхронизацию всех делений.
Необходимо отметить, что вышеупомянутые подходы к масштабированию не существуют изолированно; каждое из решений находит компромисс в рамках невозможного треугольника, сочетая его с механизмами стимулов, созданными экономическими силами в системе, для достижения эффективного баланса на макро- и микроуровнях.
Чтобы обсудить "Шардинг", нам нужно начать с самого начала.
Предположим такую ситуацию: в супермаркете, при расчете покупок, чтобы повысить эффективность расчета и сократить время ожидания клиентов, мы расширяем одно кассовое окно до 10 кассовых окон. Чтобы избежать ошибок в расчетах, в это время нам необходимо разработать единые правила:
Во-первых, если у нас есть 10 кассиров, как распределить их по окнам?
Во-вторых, если у нас есть 1000 клиентов, ожидающих в очереди, как мы можем определить, к какому окну должен подойти каждый клиент?
Третье, как можно суммировать 10 отдельных книг учета, соответствующих этим 10 окнам?
Четвёртое, как предотвратить ошибки кассиров, чтобы избежать несоответствия в учёте?
Эти несколько вопросов на самом деле соответствуют нескольким ключевым вопросам в Шардинге, а именно:
Как определить, к какому Шардингу принадлежат узлы/валидаторы в сети? То есть: как осуществить сетевое шардинг (Network Sharding);
Как определить, какой шардинг назначается каждой транзакции? То есть: как выполнить шардирование транзакции (Transaction Sharding);
Как данные блокчейна хранятся в разных Шардинг? То есть: как осуществляется состояние Шардинг (State Sharding);
Сложность означает риск, на основании всего вышесказанного, как избежать раскола безопасности всей системы?
Если мы простым языком поймем блокчейн как децентрализованную книгу учета, то как механизм консенсуса PoS, так и PoW предназначены для того, чтобы узлы соревновались за право ведения записей по определенным установленным правилам, при этом гарантируя правильность книги учета. А сетевой Шардинг означает, что требуется другой установленный порядок, чтобы разделить блокчейн-сеть на части, при этом стараясь минимизировать взаимное общение, чтобы каждая часть обрабатывала транзакции в сети и боролась за право ведения записей - то есть, правила группировки узлов.
Однако в процессе возникают проблемы: по мере того как внутренние узлы блокчейна разделяются на разные Шардинги, сложность и стоимость для атакующего будут резко снижаться. Мы можем предположить, что правила и результаты этого процесса группировки фиксированы и предсказуемы, тогда атакующему, чтобы контролировать всю сеть блокчейна, нужно лишь целенаправленно контролировать один из Шардингов, подкупив некоторые узлы внутри него.
Основатель Near Александр Скиданов описывает эту проблему следующим образом: если одна цепь с X валидаторами решает жестко форкнуться в шардированную цепь и разделить X валидаторов на 10 шардов, то в каждом шарде теперь только X/10 валидаторов, для разрушения одного шарда достаточно уничтожить 5.1%(51% / 10) от общего числа валидаторов. Это подводит нас ко второму вопросу: кто выбирает валидаторов для каждого шарда? Управление 5.1% валидаторов является вредным только в том случае, если все эти 5.1% валидаторов находятся в одном шарде. Если валидаторы не могут выбирать, в каком шарде они будут валидировать, то вероятность того, что участник, контролирующий 5.1% валидаторов, разместит всех валидаторов в одном шарде, крайне мала, что значительно снижает их способность разрушить систему.
Система шардинга должна разработать механизм доверия к сети, чтобы предотвратить обратное действие этих транзакций из внешних шардов. На сегодняшний день, возможно, лучшим ответом является обеспечение того, чтобы количество валидаторов внутри шардов превышало некий минимальный порог, так как это уменьшает вероятность, что недобросовестные валидаторы смогут подавить отдельный шард. Наиболее распространенный способ - это создание определенного уровня беспристрастной случайности, полагаясь на математические методы, чтобы минимизировать вероятность успеха атакующих. Например, в Эфириуме, решение Эфириума заключается в случайном выборе валидаторов для конкретного шарда из всех валидаторов, и каждые 6.4 минуты ( длина эпохи ) валидаторы меняются.
Проще говоря, это означает случайное группирование узлов, а затем распределение работы для независимой проверки каждой группы узлов.
Однако следует отметить, что случайность в блокчейне является очень сложной темой, и с логической точки зрения процесс генерации этого случайного числа не должен зависеть от вычислений какого-либо конкретного Шардинг. Для таких вычислений многие существующие проектные идеи заключаются в разработке отдельного блокчейна, который поддерживает всю сеть. Такие цепочки называются Beacon цепями в Ethereum и Near, Relay цепями в PolkaDot и Cosmos Hub в Cosmos.
Торговый шардинг относится к установлению правил о том, "какие транзакции должны быть распределены на какие шард", что позволяет достичь целей параллельной обработки и избежать проблемы двойного расходования. Различия в модели реестра блокчейна могут повлиять на разработку шардинга транзакций.
В настоящее время в блокчейн-сетях существуют два типа способов учета: UTXO(Невыбранные транзакционные выходы, модель неиспользуемых транзакционных выходов) и модель счета/баланса, типичными представителями первого являются BTC, а второго — ETH.
Модель UTXO: В BTC-транзакциях каждая транзакция имеет один или несколько выходов, UTXO означает неиспользованные выходы транзакций в блокчейне, которые могут быть использованы в качестве входов для новых транзакций, тогда как использованные выходы транзакций больше не могут быть потрачены, аналогично ситуации с бумажными деньгами, где покупатель передает одну или несколько бумажных купюр продавцу, а продавец затем возвращает одну или несколько бумажных купюр в качестве сдачи. В модели UTXO, для разделения транзакций требуется межшардинговая связь. Одна транзакция может включать несколько входов и несколько выходов, концепции счета нет, и не ведется запись баланса, одним из возможных способов является: обработка одного из значений входа транзакции через хеш-функцию для получения дискретного хеш-значения, чтобы определить, в какой шардинг должны идти данные.
Чтобы обеспечить размещение записей в правильных Шардинг'ах последовательным образом, значения, вводимые в хеш-функцию, должны происходить из одного и того же столбца. Этот столбец называется ключом Шардинга. Затем транзакции, генерирующие значение 1, распределяются по Шардинг 1, а транзакции, генерирующие значение 2, распределяются по Шардинг 2. Недостатком этого подхода является необходимость связи между Шардингами, чтобы избежать атаки двойного расходования. Если ограничить кросс-Шардинг транзакции, это ограничит доступность платформы, а если разрешить кросс-Шардинг транзакции, придется взвесить затраты на кросс-Шардинг связь и выгоды от повышения производительности.
Модель аккаунта/баланса: Система фиксирует баланс каждого аккаунта, и при проведении транзакции система проверяет, достаточно ли средств на счете для оплаты, аналогично банковскому переводу, когда банк фиксирует баланс каждого аккаунта, и только если баланс превышает сумму перевода, транзакция может быть выполнена. В модели аккаунта/баланса, поскольку у транзакции есть только один вход, достаточно осуществить шардинг транзакции по адресу отправителя, чтобы гарантировать, что несколько транзакций одного и того же аккаунта обрабатываются в одном шарде, что эффективно предотвращает двойные траты. Поэтому большинство блокчейнов, использующих технологию шардинга, являются системами учета аккаунтов, подобными Ethereum.
Состояние Шардинг относится к тому, как данные блокчейна распределяются и хранятся в разных шардах.
По-прежнему используя наш пример с очередями в супермаркете, у каждого окна есть свои счета. Как они записываются в их книги учета? Если: клиент встает в какую очередь, тот счет и записывается, например, клиент 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 или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Shardeum: динамическое состояние Шардинг исследует новую сторону расширения Блокчейн
Shardeum и динамическое состояние Шардинга: другой возможный путь исследования Шардинга
15 сентября 2022 года Ethereum завершил долгожданное слияние (Merge). Этот исторический момент ознаменовал переход Ethereum от Proof of Work (PoW) к Proof of Stake (PoS), на что команда Ethereum подготовилась в течение 5 лет и шесть раз откладывала. Однако многие ошибочно полагают, что слияние автоматически приведет к более высокой масштабируемости, безопасности и устойчивости, но это не так. Слияние всего лишь заменило "рельсы и колеса", и не приведет к более быстрой скорости, большей емкости или более низким расходам. Реальные достижения этих целей возможны только с помощью полного набора решений: основной сети с возможностями шардирования в сочетании с улучшенными масштабируемыми решениями второго уровня.
Как указал основатель Ethereum Виталик Бутерин, Шардинг является одним из решений для масштабирования в рамках тройственной проблемы масштабируемости. Он разделяет узлы в сети на меньшие группы, обрабатывающие разные наборы транзакций и осуществляющие параллельную обработку. Разделяя нагрузку по обработке огромного объема данных, необходимого для сводки по всей сети, это похоже на то, как мы оплачиваем покупки в супермаркете: открытие нескольких кассовых линий может наглядно сократить время ожидания и повысить эффективность расчетов.
Это основная логика Шардинга, простая и прямая. Однако дьявол кроется в деталях - принцип и направление верны, но при реализации всегда возникают множество проблем. Эта статья направлена на то, чтобы прояснить направление и трудности на пути "Шардинга", нарисовать карту исследователей Шардинга. Одновременно, сравнивая существующие решения Шардинга, найти некоторые общие проблемы и предложить жизнеспособное направление исследования: Shardeum и динамический Шардинг.
! Шардеум: еще одна возможность шардинга
Один. О "Шардинге"
Простыми словами, учитывая ограничения невозможного треугольника, начиная с Эфириума как исходной точки координат (, 0), в соответствии с двумя подходами "по вертикали" и "по горизонтали", мы разделим методы масштабируемости текущей блокчейн-технологии на две большие категории:
Вертикальное масштабирование(Vertical Scaling): достигается путем повышения производительности существующего оборудования системы. Создание децентрализованной сети, в которой каждый узел обладает суперкомпьютерной мощностью, т.е. каждый узел требует "лучшего" оборудования. Этот способ прост и эффективен, позволяет достичь предварительного улучшения пропускной способности, особенно подходит для высокочастотной торговли, игр и других приложений, чувствительных к задержкам. Однако этот способ масштабирования ограничивает уровень децентрализации сети, так как стоимость запуска проверочных узлов или полных узлов возрастает. Поддержание уровня децентрализации ограничено приблизительной скоростью роста производительности вычислительного оборудования( это и есть так называемая "закон Мура": количество транзисторов на чипе удваивается каждые два года, а стоимость вычислений уменьшается вдвое).
Горизонтальное масштабирование(Horizontal Scaling): Горизонтальное масштабирование обычно имеет несколько подходов. Один из них заключается в том, чтобы в контексте блокчейна распределить объем вычислений транзакций в определенной экосистеме на несколько независимых блокчейнов, каждый из которых имеет своих производителей блоков и возможности выполнения. Этот подход позволяет полностью настроить уровень выполнения каждого блокчейна, например, требования к аппаратному обеспечению узлов, функции конфиденциальности, газовые сборы, виртуальные машины и настройки разрешений. Другой подход к горизонтальному масштабированию - это модульный блокчейн, который делит инфраструктуру блокчейна на уровни выполнения, уровня доступности данных(DA) и уровня согласия. Наиболее распространенный модульный механизм блокчейна - это rollup. Есть еще один способ, который заключается в том, чтобы разделить один блокчейн на много частей и выполнять их параллельно. Каждое деление можно рассматривать как отдельный блокчейн, то есть множество блокчейнов могут выполняться параллельно. Кроме того, обычно есть одна основная цепочка, единственная задача которой - поддерживать синхронизацию всех делений.
Необходимо отметить, что вышеупомянутые подходы к масштабированию не существуют изолированно; каждое из решений находит компромисс в рамках невозможного треугольника, сочетая его с механизмами стимулов, созданными экономическими силами в системе, для достижения эффективного баланса на макро- и микроуровнях.
Чтобы обсудить "Шардинг", нам нужно начать с самого начала.
Предположим такую ситуацию: в супермаркете, при расчете покупок, чтобы повысить эффективность расчета и сократить время ожидания клиентов, мы расширяем одно кассовое окно до 10 кассовых окон. Чтобы избежать ошибок в расчетах, в это время нам необходимо разработать единые правила:
Во-первых, если у нас есть 10 кассиров, как распределить их по окнам?
Во-вторых, если у нас есть 1000 клиентов, ожидающих в очереди, как мы можем определить, к какому окну должен подойти каждый клиент?
Третье, как можно суммировать 10 отдельных книг учета, соответствующих этим 10 окнам?
Четвёртое, как предотвратить ошибки кассиров, чтобы избежать несоответствия в учёте?
Эти несколько вопросов на самом деле соответствуют нескольким ключевым вопросам в Шардинге, а именно:
Как определить, к какому Шардингу принадлежат узлы/валидаторы в сети? То есть: как осуществить сетевое шардинг (Network Sharding);
Как определить, какой шардинг назначается каждой транзакции? То есть: как выполнить шардирование транзакции (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% валидаторов, разместит всех валидаторов в одном шарде, крайне мала, что значительно снижает их способность разрушить систему.
Система шардинга должна разработать механизм доверия к сети, чтобы предотвратить обратное действие этих транзакций из внешних шардов. На сегодняшний день, возможно, лучшим ответом является обеспечение того, чтобы количество валидаторов внутри шардов превышало некий минимальный порог, так как это уменьшает вероятность, что недобросовестные валидаторы смогут подавить отдельный шард. Наиболее распространенный способ - это создание определенного уровня беспристрастной случайности, полагаясь на математические методы, чтобы минимизировать вероятность успеха атакующих. Например, в Эфириуме, решение Эфириума заключается в случайном выборе валидаторов для конкретного шарда из всех валидаторов, и каждые 6.4 минуты ( длина эпохи ) валидаторы меняются.
Проще говоря, это означает случайное группирование узлов, а затем распределение работы для независимой проверки каждой группы узлов.
Однако следует отметить, что случайность в блокчейне является очень сложной темой, и с логической точки зрения процесс генерации этого случайного числа не должен зависеть от вычислений какого-либо конкретного Шардинг. Для таких вычислений многие существующие проектные идеи заключаются в разработке отдельного блокчейна, который поддерживает всю сеть. Такие цепочки называются Beacon цепями в Ethereum и Near, Relay цепями в PolkaDot и Cosmos Hub в Cosmos.
! 10 000 слов подробное объяснение новой публичной сети Shardeum: еще одна возможность шардинга
02 транзакции шардинг (Transaction Sharding)
Торговый шардинг относится к установлению правил о том, "какие транзакции должны быть распределены на какие шард", что позволяет достичь целей параллельной обработки и избежать проблемы двойного расходования. Различия в модели реестра блокчейна могут повлиять на разработку шардинга транзакций.
В настоящее время в блокчейн-сетях существуют два типа способов учета: UTXO(Невыбранные транзакционные выходы, модель неиспользуемых транзакционных выходов) и модель счета/баланса, типичными представителями первого являются BTC, а второго — ETH.
Модель UTXO: В BTC-транзакциях каждая транзакция имеет один или несколько выходов, UTXO означает неиспользованные выходы транзакций в блокчейне, которые могут быть использованы в качестве входов для новых транзакций, тогда как использованные выходы транзакций больше не могут быть потрачены, аналогично ситуации с бумажными деньгами, где покупатель передает одну или несколько бумажных купюр продавцу, а продавец затем возвращает одну или несколько бумажных купюр в качестве сдачи. В модели UTXO, для разделения транзакций требуется межшардинговая связь. Одна транзакция может включать несколько входов и несколько выходов, концепции счета нет, и не ведется запись баланса, одним из возможных способов является: обработка одного из значений входа транзакции через хеш-функцию для получения дискретного хеш-значения, чтобы определить, в какой шардинг должны идти данные.
Чтобы обеспечить размещение записей в правильных Шардинг'ах последовательным образом, значения, вводимые в хеш-функцию, должны происходить из одного и того же столбца. Этот столбец называется ключом Шардинга. Затем транзакции, генерирующие значение 1, распределяются по Шардинг 1, а транзакции, генерирующие значение 2, распределяются по Шардинг 2. Недостатком этого подхода является необходимость связи между Шардингами, чтобы избежать атаки двойного расходования. Если ограничить кросс-Шардинг транзакции, это ограничит доступность платформы, а если разрешить кросс-Шардинг транзакции, придется взвесить затраты на кросс-Шардинг связь и выгоды от повышения производительности.
Модель аккаунта/баланса: Система фиксирует баланс каждого аккаунта, и при проведении транзакции система проверяет, достаточно ли средств на счете для оплаты, аналогично банковскому переводу, когда банк фиксирует баланс каждого аккаунта, и только если баланс превышает сумму перевода, транзакция может быть выполнена. В модели аккаунта/баланса, поскольку у транзакции есть только один вход, достаточно осуществить шардинг транзакции по адресу отправителя, чтобы гарантировать, что несколько транзакций одного и того же аккаунта обрабатываются в одном шарде, что эффективно предотвращает двойные траты. Поэтому большинство блокчейнов, использующих технологию шардинга, являются системами учета аккаунтов, подобными Ethereum.
! Шардеум: еще одна возможность шардинга
03 Состояние Шардинг (State Sharding )
Состояние Шардинг относится к тому, как данные блокчейна распределяются и хранятся в разных шардах.
По-прежнему используя наш пример с очередями в супермаркете, у каждого окна есть свои счета. Как они записываются в их книги учета? Если: клиент встает в какую очередь, тот счет и записывается, например, клиент A пошел к окну A, а на следующий день этот клиент пошел в другое кассовое окно, например, окно B, и в окне B нет информации о предыдущих счетах этого клиента (, например, если это касается способов расчета, таких как предоплаченные карты ), что делать? Запрашивать информацию о счете этого клиента у окна A?
Состояние Шардинг является самой большой проблемой Шардинга, более сложной, чем вышеупомянутое сетевое Шардинг и транзакционное Шардинг. Потому что в механизме Шардинга транзакции обрабатываются в разных Шардах в зависимости от адреса, то есть состояние будет храниться только в Шарде, соответствующем его адресу, и в этом случае возникает проблема, что транзакции не будут происходить только в одном Шарде и часто будут касаться межшардовых (Cross-Sharding).
Рассмотрим ситуацию перевода: аккаунт A переводит 10U на аккаунт B, при этом адрес A распределен на Шардинг 1, запись транзакции также будет храниться на Шардинг 1. Адрес B распределен на Шардинг 2, запись транзакции будет храниться на Шардинг 2.
Если A хочет перевести деньги B, то это приведет к межшардинговой сделке, и Шардинг 2 будет запрашивать прошлые записи транзакций у Шардинга 1, чтобы подтвердить действительность сделки. Если A часто переводит деньги B, Шардинг 2 будет постоянно взаимодействовать с Шардингом 1, что снизит эффективность обработки транзакций. Однако, если не...