Файл: Аннотация Цель данной работы предоставить первое описание блокчейнплатформы ton (The Open Network) и связанных с ней технологий одноранговых сетей, распределенного хранилища и хостинга..pdf

31 2.5. Глобальное состояние шардчейна. Философия «мешка ячеек». заключается в том, что все ячейки хранятся в памяти с адресацией по содержимому с адресом ячейки, равным ее хэш-функции (SHA256). Напомним, что хеш (Меркла) ячейки вычисляется путем замены ссылок на ее дочерние ячейки их (рекурсивно вычисляемыми) хешами и хеширования полученной байтовой строки.
Таким образом, если мы используем хэши ячеек для ссылки на ячейки (например, внутри описаний других ячеек), система несколько упрощается, и хэш ячейки начинает совпадать с хешем представляющей ее байтовой строки.
Теперь мы видим, что любой представляемый TVM объект, включая глобальное состояние шардчейна, может быть представлен как «мешок ячеек» — т. е. набор ячеек вместе с «корневой» ссылкой на одну из них (например, хешем). Обратите внимание, что повторяющиеся ячейки отсутствуют в этом описании («набор ячеек» — это набор ячеек, а не мультимножество ячеек), поэтому представление абстрактного дерева фактически может стать представлением ориентированного ациклического графа
(dag).
Это состояние можно сохранить на диске в дереве B- или B+-, содержащем все рассматриваемые ячейки (возможно, с некоторыми дополнительными данными, такими как высота поддерева или счетчик ссылок) и проиндексированном хэшем ячеек. Однако примитивная реализация этой идеи может привести к тому, что состояние одного смарт-контракта будет разбросано по удаленным частям файла на диске, чего мы предпочли бы избежать
19
Теперь мы собираемся более подробно объяснить, как почти все объекты, используемые блокчейном TON, могут быть представлены в виде «мешков ячеек», демонстрируя тем самым универсальность этого подхода.
2.5.6. Блок шардчейна как «мешок ячеек». Блок шардчейна может быть описан алгебраическим типом и храниться как «мешок ячеек». Тогда простое двоичное представление блока может быть получено простым объединением строк байтов, представляющих каждую из ячеек в «мешке ячеек», в произвольном порядке. Это представление может быть улучшено и оптимизировано, например, путем предоставления списка смещений всех ячеек в начале блока и замены хеш-ссылок на другие ячейки 32-битными индексами в этом списке, когда это возможно.
Однако следует учитывать, что блок — это, по сути, «мешок ячеек», а все остальные технические детали — лишь мелкие компоненты оптимизации и реализации.
2.5.7. Обновление объекта как «мешка ячеек». Представьте, что у нас есть старая версия некоторого объекта, представленного в виде «мешка ячеек», и мы хотим представить новую версию того же объекта, предположительно не слишком отличающуюся от предыдущей. Новое состояние может быть представлено просто как еще один «мешок ячеек» с собственным корнем, из которого будут удалены все ячейки, встречающиеся в старой версии. По сути, оставшийся «мешок ячеек» является обновлением объекта. Каждый пользователь, у которого есть старая версия этого объекта и обновление, может вычислить новую версию, просто объединив два пакета ячеек и удалив старый корень (уменьшив его счетчик ссылок и освободив ячейку, если счетчик ссылок становится равным нулю).
18
Можно показать, что если доказательства Меркла для всех данных, хранящихся в дереве ячеек, требуются одинаково часто, следует использовать ячейки с b+ch ≈ 2(h+r), чтобы минимизировать средний размер доказательства Меркла, где h = 32 — это размер хеша в байтах, а r ≈ 4 — размер ссылки на ячейку в байтах. Другими словами, ячейка должна содержать либо две ссылки и несколько необработанных байтов, либо одну ссылку и около 36 необработанных байтов, либо вообще не иметь ссылок с 72 необработанными байтами.
19
Наилучшей реализацией было бы сохранение состояния смарт-контракта в виде сериализированной строки, если оно маленькое, или в отдельном B-дереве, если оно большое. Тогда структура верхнего уровня, представляющая состояние блокчейна, будет B-деревом, листья которого могут содержать ссылки на другие B-деревья.

32 2.5. Глобальное состояние шардчейна. Философия «мешка ячеек».
2.5.8. Обновления состояния учетной записи. В частности, обновления состояния учетной записи или глобального состояния шардчейна или любой хэш-карты могут быть представлены с использованием идеи, описанной в 2.5.7. Это означает, что когда мы получаем новый блок шардчейна (который представляет собой «мешок ячеек»), мы интерпретируем не только собственно этот «мешок ячеек», но сначала объединяем его с «мешком ячеек», представляющим предыдущее состояние шардчейна. В этом смысле каждый блок может «содержать» все состояние блокчейна.
2.5.9. Обновления в блоке. Напомним, что сам блок представляет собой «мешок ячеек», поэтому, если возникает необходимость отредактировать блок, можно аналогичным образом определить «обновление блока» как «мешок ячеек», интерпретируемый при наличии «мешка ячеек», который является предыдущей версией этого блока. Этот процесс является примерной идеей «вертикальных блоков», описываемых в 2.1.17.
2.5.10. Доказательство Меркла как «мешок ячеек». Обратите внимание, что
(обобщенное) доказательство Меркла - например, утверждение, что x[i] = y, начиная с известного значения HASH(x) = h (см. 2.3.10 и 2.3.15), - также может быть представлено как «мешок ячеек». А именно, нужно просто предоставить подмножество ячеек, соответствующее пути от корня x: Hashmap(n, X) к целевому листу с индексом i: 2
n и значением y: X. Ссылки на дочерние элементы этих ячеек, которые не лежат на этом пути, останутся «нерешенными» в этом доказательстве, представленном хешами ячеек. Можно также обеспечить одновременное доказательство Меркла, скажем, x[i] = y и x[i'] = y', включив в «мешок ячеек» ячейки, лежащие на пути объединения двух путей от корня x в листы, соответствующие индексам i и i'.
2.5.11. Доказательства Меркла в виде ответов на запросы от полных нод. По сути, полная нода с полной копией состояния шардчейна (или цепочки учетных записей) может предоставить доказательство Меркла по запросу неполного узла (например, сетевого узла, на котором запущена облегченная версия клиента блокчейна TON), что позволяет получателю выполнять некоторые простые запросы без внешней помощи, используя только ячейки в этом доказательстве Меркла. Неполная нода может отправлять свои запросы в сериализированном формате на полную ноду и получать правильные ответы с доказательствами Меркла (или просто доказательства Меркла), потому что запрашивающая сторона должна иметь возможность вычислять ответы, используя только ячейки, включенные в доказательство Меркла. Это доказательство
Меркла будет состоять из «мешка ячеек», содержащего только ячейки, принадлежащие к состоянию шардчейна, к которым получила доступ полная нода при выполнении запроса неполной ноды. Такой подход может использоваться, в частности, для выполнения «запросов на получение» смарт-контрактов (см. 4.3.12).
2.5.12. Дополненное обновление или обновление состояния с доказательством
Меркла. Напомним (см. 2.5.7), что мы можем описать изменения в состоянии объекта от старого значения x: X к новому значению x': X с помощью «обновления», которое представляет собой просто «мешок ячеек» с ячейками, которые лежат в поддереве, представляющем новое значение x', но не в поддереве, представляющем старое значение x, поскольку предполагается, что получатель имеет копию старого значения x и всех его ячеек.
Однако если получатель не имеет полной копии x, но знает только ее хэш (Меркла) h
= HASH(X), он не сможет проверить правильность обновления (т. е. все

33 2.5. Глобальное состояние шардчейна. Философия «мешка ячеек».
«подвешенные» ссылки на ячейки в обновлении действительно относятся к ячейкам, присутствующим в дереве x). Хотелось бы иметь «проверяемые» обновления, дополненные доказательствами Меркла для существования всех упомянутых ячеек в старом состоянии. Тогда любой пользователь, который знает только h = HASH(X), сможет проверить правильность обновления и вычислить новый h' = HASH (X') самостоятельно.
Поскольку наши доказательства Меркла сами по себе являются «мешками ячеек» (см.
2.5.10), можно построить такое расширенное обновление, как «мешок ячеек», содержащий старый корень x, некоторые из его потомков вместе с путями из корня x, а также новый корень x' и всех его потомков, которые не являются частью x.
2.5.13. Обновление состояния учетной записи в блоке шардчейна. В частности, обновления состояния учетной записи в блоке шардчейна должны быть дополнены, как обсуждалось в 2.5.12. В противном случае кто-то может зафиксировать блок, содержащий недопустимое обновление состояния, ссылаясь на ячейку, отсутствующую в старом состоянии; доказать невалидность такого блока будет проблематично (как претенденту доказать, что ячейка не является частью предыдущего состояния?).
Если дополняются все обновления состояния, включенные в блок, их достоверность можно легко проверить, а их невалидность также отображается как нарушение рекурсивного определяющего свойства (обобщенных) хэшей Меркла.
2.5.14. Философия «все есть мешок ячеек». Предыдущие соображения показывают, что все данные, которые необходимо хранить или передавать, будь то в блокчейне
TON или в сети, можно представить в виде «мешка ячеек». Это важная часть философии проектного решения блокчейна TON. После объяснения подхода «мешок ячеек» и определения некоторых «низкоуровневых» сериализаций «мешков ячеек» можно просто определить все (формат блока, шардчейн и состояние учетной записи и т. д.) с помощью высокого уровня абстрактных (зависимых) алгебраических типов данных.
Объединяющий эффект философии «все есть мешок ячеек» значительно упрощает реализацию, казалось бы, несвязанных сервисов (в п. 5.1.9 приведен пример с платежными каналами).
2.5.15. «Заголовки» блоков для блокчейнов TON. Обычно блок в блокчейне начинается с небольшого заголовка, содержащего хэш предыдущего блока, время его создания, хэш Меркла дерева всех транзакций, содержащихся в блоке, и так далее.
Затем хеш блока определяется как хеш этого небольшого заголовка блока. Поскольку заголовок блока в конечном итоге зависит от всех данных, включенных в блок, нельзя невозможно изменить блок, не изменив его хэш.
При использовании подхода «мешок ячеек», который используется блокчейнами
TON, назначенный заголовок блока отсутствует. Вместо этого хеш блока определяется как хеш (Меркла) корневой ячейки блока. Следовательно, верхняя
(корневая) ячейка блока может считаться небольшим «заголовком» этого блока.
Однако корневая ячейка может не содержать всех данных, обычно ожидаемых от такого заголовка. По сути, нужно, чтобы заголовок содержал некоторые поля, определенные в типе данных Block. Обычно эти поля содержатся в нескольких ячейках, включая корневую ячейку. Эти ячейки вместе составляют «доказательство
Меркла» для значений рассматриваемых полей. Можно было бы настаивать на том, чтобы эти «ячейки заголовка» содержались в самом начале блока, перед любыми другими ячейками. Тогда нужно будет загрузить только первые несколько байтов сериализации блока, чтобы получить все «ячейки заголовка» и изучить все необходимые поля.

34 2.6. Создание и проверка новых блоков
2.6. Создание и проверка новых блоков
По сути, блокчейн TON состоит из блоков шардчейна и мастерчейна. Чтобы обеспечить бесперебойную и правильную работу системы, эти блоки должны создаваться, проверяться и распространяться по сети всем заинтересованным сторонам.
2.6.1. Валидаторы. Новые блоки создаются и проверяются специальными назначенными узлами, называемыми валидаторами. В сущности, любая желающая нода может стать валидатором, при условии внесения достаточно большого стейка (в монетах TON, см. Приложение A) в мастерчейн. Валидаторы получают "вознаграждения" за хорошую работу, а именно, комиссии за транзакции, хранение и газ со всех транзакций (сообщений), включенных в только что созданные блоки, и некоторое количество только что "отчеканенных" монет, что отражает "благодарность" всего сообщества валидаторам за поддержание работы блокчейна
TON. Этот доход распределяется среди всех участвующих валидаторов пропорционально их стейкам.
Однако быть валидатором - это большая ответственность. Если валидатор подписывает невалидный блок, он может быть наказан потерей части или всего своего стейка, и временным или постоянным исключением из набора валидаторов. Если валидатор не участвует в создании блока, он не получает свою долю награды за этот блок. Если валидатор воздерживается от создания новых блоков длительное время, он может потерять часть стейка и быть временно или навсегда исключен из набора валидаторов.
Всё это значит, что валидатор не получает свои деньги "ни за что". Действительно, валидатор должен следить за состояниями всех или некоторых шардчейнов (каждый валидатор отвечает за валидацию и создание новых блоков в конкретном наборе шардчейнов), выполнять все вычисления для смарт-контрактов в этих шардчейнах, получать обновления о других шардчейнах и так далее. Эта деятельность требует значительного дискового пространства, вычислительной мощности и ширины интернет-канала.
2.6.2. Валидаторы вместо майнеров. Напомним, что блокчейн TON использует подход Proof-of-Stake, вместо подхода Proof-of-Work, используемого Биткоином, текущей версией Эфириума, и большинством других криптовалют. Это значит, что нельзя "майнить" новые блоки, предоставляя некое доказательство проделанной работы (вычисления большого количества в ином случае бесполезных хэшей) и получать в результате новые монеты. Вместо этого, нужно стать валидатором и тратить вычислительные мощности на хранение и обработку реквестов и данных блокчейна TON. Коротко говоря, нужно быть валидатором, чтобы "майнить" новые монеты. В этом смысле, валидаторы являются новыми майнерами.
Тем не менее, есть другие способы заработать монеты помимо становления валидатором.
2.6.3. Номинаторы и «майнинг-пулы». Чтобы стать валидатором, обычно требуется приобретать и устанавливать несколько высокопроизводительных серверов и обеспечивать хорошее интернет-соединение для них. Это не так дорого как оборудование ASIC, на данный момент требуемое для майнинга Биткоинов.
Однако, майнить новые монеты TON определенно не получится на домашнем компьютере, не говоря о смартфоне.
В майнинг-сообществах Биткоина, Эфириума и других Proof-of-Work криптовалютах есть определение «майнинг-пулов» с большим количеством нод, которые сами по себе не имеют достаточно мощности для майнинга новых блоков, но объединяют усилия и впоследствии разделяют награду.

35 2.6. Создание и проверка новых блоков
Соответствующим определением в мире Proof-of-Stake является номинатор. По сути, номинатор - это нода, одалживающая свои деньги, чтобы помочь валидатору увеличить его стейк. Впоследствии валидатор отдает соответствующую часть своей награды (или ранее согласованную её долю, скажем, 50%) номинатору.
В этом смысле номинатор также может принять участие в «майнинге» и получить часть награды пропорционально количеству денег, которую он желает одолжить для этой цели. Он получает только часть доли от награды валидатора, поскольку он предоставляет только «капитал», но не имеет нужды приобретать вычислительную мощность, дисковое пространство и интернет-канал.
Однако если валидатор теряет свой стейк из-за невалидного поведения, номинатор также теряет свою долю стейка. В этом понимании номинатор разделяет риск. Он должен выбирать номинированного валидатора мудро, иначе он может потерять деньги. В этом смысле номинаторы принимают взвешенное решение и «голосуют» за конкретных валидаторов своими деньгами.
С другой стороны, эта система номинирования или одалживания позволяет стать валидатором без изначального инвестирования большого количества денег в монеты
TON. Другими словами, это не позволяет обладателям большого количества монет
TON стать монополистом в среде валидаторов.