Обзор структуры шардинга QuarkChain
Учитывая существующие модели блокчейнов, проект QuarkChain улучшает их, внедряя существенные технические инновации:
(Распределение/State to partition): QuarkChain разделяет смарт-контракты, т. е. помещает смарт-контракты в разные шарды (сегменты), при условии РеШардинга (reshard). Смарт-контракт содержит код и хранилище, где размер данных может быть намного больше, чем учетная запись пользователя (рассмотрим ERC20 с большим количеством сопоставлений адреса и баланса).
(Распределение/State to partition): мы не разделяем учетные записи пользователей, и пользователь может легко переместить состояние своей учетной записи (в основном баланс) на другой шард (сегмент) с помощью кросс-шардинговой транзакции. Это позволяет пользователю с закрытым ключом получить доступ ко всем ресурсам (смарт-контрактам) во всех шардах (сегментах).
(Атомарность/Atomicity): каждый смарт-контракт имеет шард-ключ (fullShardId в нашей кодовой базе), и любые пакетные операции на всех смарт-контрактах с тем же ключом сегмента являются атомарными. Кроме того, смарт-контрактам запрещено получать доступ к другим смарт-контрактам с различными шард-ключами.
(Сбалансированная нагрузка/Размер Balanced load/size): предполагая, что шард-ключи смарт-контрактов распределены равномерно, аналогично им, смарт-контракты должны равномерно распределены в разных шардах.
(РеШардинг/Reshard): чтобы добавить больше шард с низкой стоимостью миграции, мы разделили шарды на двое в соответствии с шард-ключем в смарт-контрактах. Это исключает миграцию данных из других шардов, предшествующих reshard, и тем самым упрощает reshard.
(РеШардинг/Reshard): поведение смарт-контрактов будет таким же –как до, так и после - reshard, т. е., чтение результата смарт-контракта в том же значении и запись результата смарт-контракта в тех же изменениях состояния системы до - и после - reshard.
Состояние системы и разделов QuarkChain
Чтобы поддерживать атомарность серии операций CRUD в QuarkChain, QuarkChain переопределяет адрес учетной записи пользователя и смарт-контракта, добавляя к каждому адресу 32-битный ключ шарда (шард-ключ):
Address := RIPEMD160(Public key) + Shard key,
где + - декартово оператор продукта (Cartesian product operator), адрес QuarkChain - это 192-битные данные, и мы ссылаемся на первый 160-бит адреса как получателя адреса в QuarkChain.
Количество шард (размер шард) в сети QuarkChain равно 2, и операция reshard удвоит количество шард в сети. Учитывая размер шарда, сегменты индексируются по формуле:
Shard Id: = Shard key % Shard size.
Состояние в шарде является сопоставлением ключ - значение, где ключ является получателем адресов и значение содержит:
- Баланс;
- Одноразовый номер;
- Код;
- Хранилище;
- Шард-Ключ.
где Шард-Ключ (ShardKey) устанавливается при создании пары ключ-значение и является неизменяемым после этого.
С помощью дополнительного шард-ключа в адресе, пользователь (или получатель) может управлять всеми адресами во всех шардах с помощью одного закрытого ключа.
Транзакции в QuarkChain
Операции переноса баланса
Проводка переноса баланса зависит от адресов источника и назначения:
(Транзакция внутри шарда/In-shard transaction): если оба адреса имеют одинаковый идентификатор шарда (даже ключи сегмента различны), передача является транзакцией в шарде, и такая транзакция будет обновлять только баланс получателей в том же шарде.
(Транзакция между шардами/Cross-shard transaction): если оба адреса имеют разные идентификаторы шардов, передача является транзакцией между шардами, и атомарность транзакции нуждается в дальнейшей координации. К счастью, такая транзакция намного проще, чем традиционная транзакция по кросс-сети (имеется ввиду операции между разными блокчейнами), так как оба шарда работают с одной и той же криптовалютой (QKC). Детали кросс-шардовой сделки будут рассмотрены в другой статье.
Транзакции Смарт-Контракта
Транзакция смарт-контракта должна быть выполнена в том же шарде, т. е. идентификатор шарда исходной учетной записи Пользователя и целевой смарт-контракт должны быть одинаковыми. Смарт-контракт может вызывать другой смарт-контракт (предоставляя получателю другого смарт-контракта, т. е. адрес в EVM, в коде для поддержания обратной совместимости EVM) с тем же ключом шарда. Однако такой вызов контракта завершится ошибкой, если смарт-контракты находятся в разных шардах, где такой вызов эквивалентен вызову смарт-контракта со следующим кодом сборки:
PUSH 0x0
DUP1
REVERTПоскольку смарт-контракты с одним и тем же шард-ключом всегда будут распределены в один и тот же шард, поведение смарт-контракта (чтение/запись) гарантированно будет одинаковым независимо от того, как распределено состояние системы (подробнее см. раздел Reshard в QuarkChain).
РеШардинг/Reshard в QuarkChain
Операция reShard разделит каждый шард на два отдельных, в результате чего Размер шарда будет удвоен. После удвоения размера шарда назначение учетной записи пользователя/смарт-контрактов определяется дополнительным значащим битом в новом идентификаторе шарда. Предполагая, что шард-ключи учетных записей пользователей/смарт-контрактов распределены равномерно, половина учетных записей пользователей/смарт-контрактов должна быть разделена на новый шард, а остальные на другой шард. Кроме того, разделенный шард может по-прежнему содержать смарт-контракты другого разделенного шарда путем замены кода кодом REVERT и обнуления хранилища. Эти фиктивные смарт-контракты гарантируют, что смарт-контракты в новом шарде по-прежнему не смогут вызывать смарт-контракты, которые находились в том же шарде, но с другими шард-ключами.
Если текущий узел, который обрабатывает оба разделенных шарда, не в состоянии вместить их, то может быть добавлен в сеть новый узел для обработки нового шарда путем миграции его состояния, и, таким образом, емкость системы может быть увеличена по мере увеличения числа шард/узлов. Это достигается с помощью кластера, который будет обсуждаться в будущих статьях.
Выбор шард-ключа в QuarkChain
Ключевым моментом в балансировке нагрузки в сети QuarkChain является обеспечение распространения всех смарт-контрактов по всем шардам. Поскольку шард-ключ является неизменяемым после создания смарт-контракта, важно выбрать ключ во время создания.
Во-первых, если создаваемый смарт-контракт зависит от других смарт-контрактов, шард-ключ должен совпадать с ключом зависимых смарт-контрактов.
Во-вторых, если смарт-контракт не зависит от каких-либо других смарт-контрактов, пользователь (или кошелек) может выбрать любой шард-ключ, или система может наложить некоторые правила:
- Случайно сгенерированный шард-ключ;
- или Любой 32-разрядный адрес получателя исходного адреса;
- или IP-адрес кошелька.
Первые два варианта могут привести к равномерному распределению шард-ключей. Однако предположим, что существуют сотни или тысячи шардов. Пользователю, желающему получить доступ к любому смарт-контракту в сети, могут потребоваться частые транзакции между шардами или поддержание нескольких балансов, что снижает эффективность шардинга или ухудшает взаимодействие с пользователем.
Использование IP-адреса может облегчить проблему, сгруппировав смарт-контракты с географической информацией. Если взаимодействие пользователя со смарт-контрактом географически связано (например, взаимодействие с локальными товарами/услугами), пользователь может просто поддерживать свои балансы в шардах, связанных с местоположениями, в которых пользователь проживает или путешествует, потенциально экономя много ненужных транзакций между шардами и упрощая управление учетными записями пользователей.
Сравнение QuarkChain и BigTable от Google
Многое из проекта QuarkChain вдохновлено BigTable от Google, и они имеют много общего, поскольку оба они по существу являются хранилищем ключей и ценностей. Следующая Таблица сравнивает их.
Помимо сходства, QuarkChain также имеет несколько существенных отличий от BigTable:
- QuarkChain изначально поддерживает транзакции между шардами, которые переносят баланс с одного счета в одном сегменте на другой счет в другом сегменте, в то время как BigTable не поддерживает межстрочные транзакции.
- BigTable позволяет объединить две смежные таблетки (шарда) в одну таблетку, если две таблицы малы из-за удаления. В отличие от этого, операции удаления (например, selfdestruct) редко используются в blockchain, и, таким образом, операция слияния не требуется. Это значительно упрощает модель системы и модель угроз QuarkChain (например, replay attack).
Резюме
Вдохновленные существующими масштабируемыми системами, мы предложили новую модель блокчейн-системы и описали нашу схему шардинга. Кроме того, мы представили сравнение предлагаемой нами модели с BigTable от Google. В следующей статье мы обсудим, как построить консенсус для поддержки шардинга и соответствующей модели угроз QuarkChain.
О QuarkChain
Проект QuarkChain направлен на решение проблемы масштабируемости блокчейна с помощью технологий горизонтальной масштабируемости. Миссия QuarkChain - позволить всем в мире использовать технологии блокчейн в любое время и в любом месте. Если вы заинтересованы в QuarkChain, пожалуйста, для получения дополнительной информации воспользуйтесь ссылками ниже:
Сайт: https://www.quarkchain.io
Telegram (Eng): https://t.me/quarkchainio
Telegram (Rus): https://t.me/QuarkChain_Russia
Twitter (Eng): https://twitter.com/Quark_Chain
Twitter (Rus): https://twitter.com/quarkchainru
Steemit: https://steemit.com/@quarkchain
Medium: https://medium.com/@quarkchainio
Reddit: https://www.reddit.com/r/quarkchainio/
Weibo: https://weibo.com/QuarkChain