цепочки учетных записей на все транзакции

Сообщения между учетными записями в одной цепочке сегментов. В некоторых
случаях сообщение генерируется учетной записью, принадлежащей к некоторой цепочке сегментов,
предназначенной для другой учетной записи в той же цепочке сегментов. Например, это происходит в новой рабочей цепочке, которая еще не разделена на несколько цепочек сегментов,
потому что нагрузка управляема.
Такие сообщения могут накапливаться в очереди вывода цепочки сегментов, а затем обрабатываться как входящие сообщения в последующих блоках (
для этой цели любой сегмент считается соседним сам по себе). Однако в большинстве
случаи, когда эти сообщения можно доставить в пределах самого исходного блока.

Для достижения этой цели на все транзакции,
включенные в блок цепочки сегментов, накладывается частичный порядок, и транзакции (каждая из которых заключается в
доставке сообщения на какую-либо учетную запись) обрабатываются в соответствии с этим частичным
порядком. В частности, транзакции разрешается обрабатывать некоторое выходное сообщение
предыдущей транзакции в отношении этого частичного заказа.
В этом случае текст сообщения не копируется дважды. Вместо этого исходное
и транзакции обработки относятся к общей копии сообщения.
2.5 Состояние глобальной цепочки осколков. Философия мешка с клетками.
Теперь мы готовы описать глобальное состояние блокчейна TON или, по крайней
мере, цепочки фрагментов базовой рабочей цепочки.
Мы начинаем с высокоуровневого или логического описания, которое состоит в
том, что глобальное состояние является значением алгебраического типа ShardchainState.
2.5.1. Состояние цепочки сегментов как совокупность состояний цепочки учетных записей. Согласно парадигме конечного сегментирования (см. 2.1.2), любая цепочка сегментов - это просто
(временная) коллекция виртуальных цепочек учетных записей, содержащих ровно по одной
учетной записи в каждой. Это означает, что, по сути, глобальное состояние
цепочки сегментов должно быть хэш-картой
Состояние цепочки осколков := (Состояние учетной записи 99K) (23)
где все account_id, отображаемые в качестве индексов этой хэш-карты, должны начинаться с
pre x s, если мы обсуждаем состояние осколка (w, s) (см. 2.1..
38
2.5. Состояние глобальной цепочки осколков. Философия мешка с клетками.
На практике мы можем захотеть разделить состояние учетной записи на несколько частей (например,
сохранить очередь выходных сообщений учетной записи отдельно, чтобы упростить ее проверку
соседними цепочками осколков) и имеют несколько хэш-карт (учетная запись 99K
AccountStateParti) внутри ShardchainState. Мы также можем добавить небольшое
количество глобальных или интегральных параметров в состояние цепочки сегментов (например,
общий баланс всех учетных записей, принадлежащих этому сегменту, или общее количество
сообщений во всех очередях вывода).
Однако (23) является хорошим первым приближением того, как выглядит глобальное
состояние цепочки осколков, по крайней мере, с логической (высокоуровневой) точки зрения. Формальное
описание алгебраических типов Accountstate и ShardchainState может быть выполнено
с помощью TL-схемы (см. 2.2.5), которая будет предоставлена в другом месте.
2.5.2. Разделение и объединение состояний цепочки сегментов. Обратите внимание, что в конце
Описание парадигмы сегментирования состояния цепочки сегментов (23) показывает, как это
состояние должно обрабатываться при разделении или объединении сегментов. На самом деле эти преобразования
состояний оказываются очень простыми операциями с хэш-картами.
2.5.3. Состояние цепочки учетных записей. Состояние (виртуальной) цепочки учетных записей -
это просто состояние одной учетной записи, описываемое типом AccountState. Обычно в нем есть все или
некоторые поля, перечисленные в 2.3.20, в зависимости от используемого конкретного конструктора.
2.5.4. Состояние глобальной рабочей цепочки. Аналогично (23), мы можем определить
состояние глобальной рабочей цепочки по той же формуле, но с account_id, которому разрешено принимать
любые значения, а не только те, которые принадлежат одному сегменту. Замечания, аналогичные тем,
которые сделаны в 2.5.1, применимы и в этом случае: мы можем захотеть разделить эту хэш-карту
на несколько хэш-карт, и мы можем захотеть добавить некоторые интегральные параметры,
такие как общий баланс.
По сути, состояние глобальной рабочей цепочки должно быть задано одним и тем же типом
Состояние цепочки осколков как состояние цепочки осколков, потому что это состояние цепочки осколков
мы получили бы, если бы все существующие цепочки фрагментов этой рабочей цепочки внезапно слились
в одну.
2.5.5. Перспектива низкого уровня: мешок клеток. Существует также низкоуровневое описание состояния цепочки учетных записей или цепочки сегментов, дополняющее описание
высокого уровня, приведенное выше. Это описание довольно важно, потому что оно оказывается довольно универсальным, обеспечивая общую основу
для представления, хранения, сериализации и передачи по сети почти всех
данных, используемых блокчейном TON (блоки, состояния цепочки сегментов, смарт-контракт
хранение, доказательства Меркла и т. Д.). В то же время такой универсальный низкоуровневый
39
2.5. Состояние глобальной цепочки осколков. Философия мешка с клетками.
описание, будучи понято и реализовано, позволяет нам сосредоточить наше
внимание только на соображениях высокого уровня.
Напомним, что TVM представляет значения произвольных алгебраических типов (включая, например, состояние цепочки сегментов (23)) с помощью дерева
ячеек TVM или сокращенно ячеек (см. 2.3.14 и 2.2.5).
Любая такая ячейка состоит из двух байтов дескриптора, определяющих определенные символы и
значения 0 ≤ b ≤ 128, количество необработанных байтов, и 0 ≤ c ≤ 4, количество
ссылок на другие ячейки. Затем следуют b необработанных байтов и ссылки на ячейки c.18
Точный формат ссылок на ячейки зависит от реализации и от того
, находится ли ячейка в оперативной памяти, на диске, в сетевом пакете, в блоке
и так далее. Полезная абстрактная модель состоит в том, чтобы представить, что все ячейки
хранятся в адресуемой содержимому памяти с адресом ячейки, равным ее хэшу
(sha256). Напомним, что хэш (Merkle) ячейки вычисляется точно
путем замены ссылок на его дочерние ячейки их (рекурсивно вычисленными)
хэши и хэширование результирующей строки байтов.
Таким образом, если мы используем хэши ячеек для ссылки на ячейки (например, внутри описаний
других ячеек), система несколько упрощается, и хэш ячейки начинает
совпадать с хэшем строки байтов, представляющей ее.
Теперь мы видим, что любой объект, представляемый TVM,
включая глобальное состояние цепочки сегментов, может быть представлен в виде пакета ячеек, т.е. набора ячеек
вместе с корневой ссылкой на одну из них (например, с помощью хэша). Обратите внимание, что
повторяющиеся ячейки удаляются из этого описания (пакет ячеек представляет собой набор
ячеек, а не множественный набор ячеек), поэтому представление абстрактного дерева может
фактически стать представлением направленного ациклического графа (dag).
Можно даже сохранить это состояние на диске в дереве B- или B +, содержащем все рассматриваемые
ячейки (возможно, с некоторыми дополнительными данными, такими как высота поддерева или счетчик
ссылок), индексируемыми хэшем ячейки. Однако наивная реализация
этой идеи приведет к тому, что состояние одного смарт-контракта будет разбросано
среди отдаленных частей файла диска, чего мы предпочли бы избежать.19
18One можно показать, что если Меркле доказательств всех данных, хранящихся в дереве клеток необходимы
одинаково часто, то следует использовать клетки с+ч ≈ 2(ч+р), чтобы минимизировать средний Меркле доказательство
площадь, где h = 32 размер хеша в байтах, и ≈ Р 4-это размер в байтах ссылку на ячейку.
Другими словами, ячейка должна содержать либо две ссылки и несколько необработанных байтов, либо одну
ссылку и около 36 необработанных байтов, либо вообще никаких ссылок с 72 необработанными байтами.
19A Лучшей реализацией было бы сохранить состояние смарт-контракта в виде сериализованной
строки, если она маленькая, или в отдельном B-дереве, если оно большое; тогда структура верхнего уровня,
представляющая состояние блокчейна, была бы B-деревом, листьям которого разрешено
содержать ссылки на другие B-деревья