Блокчейн блокчейнов
Термины смарт-контракт, аккаунт и актор используются взаимозаменяемо в этом документе для описания сущности блокчейна.
Отдельный актор
Рассмотрим один смарт-контракт.
В TON это сущность с такими свойствами как address
, code
, data
, balance
и другие. Другими словами, это объект, который имеет хранилище и определенное поведение. Это поведение в основном принимает следующий вид:
- происходит событие (наиболее распространенная ситуация — контракт получает сообщение)
- контракт обрабатывает это событие в соответствии со своими свойствами, исполняя
код
в виртуальной машине TON. - контракт изменяет свои свойства (
code
,data
и другие) - контракт опционально генерирует исходящие сообщения
- контракт переходит в режим ожидания, пока не произойдет следующее событие
Комбинация этих шагов называется транзакцией. Важно, чтобы описанные выше события обрабатывались одно за другим, поэтому транзакции в блокчейне строго упорядочены и не могут прерывать друг друга.
Данная модель обработки и называется Актор
.
Самый низкий уровень: AccountChain
Последовательность транзакций Tx1 -> Tx2 -> Tx3 -> ....
можно назвать цепочкой. В рассматриваемом нами случае, так как эта цепочка транзакций относится к одному аккаунту, мы можем использовать термин AccountChain
.
Далее, так как обрабатывающие транзакции узлы время от времени должны координировать состояние смарт-контракта, достигать консенсуса о состоянии, эти транзакции собираются в батчи: [Tx1 -> Tx2] -> [Tx3 -> Tx4 -> Tx5] -> [] -> [Tx6]
.Собранные батчи не вмешивается в последовательность, каждая транзакция по-прежнему имеет только одну предыдущую
и максимум одну последующую
, однако теперь эта общая последовательность будет разбита на отдельные блоки.
Также будет целесообразно включать в блоки и очереди входящих и исходящих сообщений. В этом случае блок будет содержать полный набор информации, которая определяет и описывает, что произошло со смарт-контрактом во время исполнения этого блока.
Множество AccountChains: Шарды
Теперь давайте рассмотрим множество аккаунтов. Мы можем получить несколько AccountChains и хранить их вместе. Подобный набор AccountChains называется Шардчейн.Схожим образом мы можем разбить Шардчейн на Шардблоки, которые будут являться совокупностью отдельных AccountBlocks.
Динамическое разделение и объединение шардчейнов
Важно отметить, что поскольку Шардчейн состоит из явно различимых AccountChains, мы сможем его легко разделять.К примеру, если у нас есть 1 Шардчейн, который описывает происходящие с 1 миллионом аккаунтов события, и в одну секунду происходит слишком много транзакций для обработки и хранения в одном узле, то мы можем просто разделить эту цепочку на два меньших Шардчейна. При этом каждая цепочка будет работать с выделенным полмиллионом аккаунтов, а также она будет обрабатываться на отдельном подмножестве узлов.
Аналогично, если некоторые шарды станут слишком свободными, их можно объединить в один более крупный шард.
Очевидно, что есть два предельных случая – когда шард содержит только один аккаунт (и, следовательно, не может быть разделен дальше) и когда шард содержит все аккаунты.
Аккаунты могут взаимодействовать друг с другом, отправляя сообщения. Существует специальный механизм маршрутизации, который перемещает сообщения из исходящих очередей в соответствующие входящие очереди и гарантирует, что все сообщения будут доставлены, а также, что эти сообщения будут доставлены последовательно (сообщение, отправленное раньше, достигнет получателя раньше).
Чтобы сделать разделение и слияние детерминированными, агрегация AccountChains в шарды основана на битовом представлении адресов аккаунтов. Например, адрес выглядит как (shard prefix, address)
. Таким образом, все аккаунты в шарде будут иметь точно такой же двоичный префикс (например, все адреса будут начинаться с 0b00101
).