Открытая сеть. Открытая сеть по материалам работы дра Николая Дурова 26 июля 2021
 Скачать 0.79 Mb.
|
|
(особенно функциональных) языках. По сути, TVM использует помеченные типы данных, мало чем отличающиеся от тех, которые используются в реализациях Prolog или Erlang. Сначала можно представить, что состояние смарт-контракта TVM не просто хэш - карта 2 256 → 2 256 или Hashmap (256, 2 256 ) , но (в качестве первого шага) Hashmap(256, X), где X-тип с несколькими конструкторами, позволяющий хранить, помимо 256-битных целых чисел, другие структуры данных, включая другие hashmaps Hashmap(256, X) в частности. Это будет означать, что ячейка TVM (постоянного или временного) хранилища, переменная или элемент массива в коде смарт-контракта TVM может содержать не только целое число, но и совершенно новую хэш-карту. Конечно, это будет означать, что ячейка содержит не только 256 бит, но и, скажем, 8-битный тег, описывающий, как эти 256 бит должны быть интерпретированы. На самом деле значения не обязательно должны быть точно 256-битными. Формат значений , используемый TVM, состоит из последовательности необработанных байтов и ссылок на другие структуры, смешанных в произвольном порядке, с некоторыми байтами дескриптора, вставленными в подходящие места, чтобы иметь возможность отличать указатели от необработанных данных (например, строк или целых чисел); см. 2.3.14. Этот формат необработанных значений может использоваться для реализации произвольных алгебраических типов сумма-произведение. В этом случае значение сначала будет содержать необработанный байт, описывающий используемый конструктор (с точки зрения высокоуровневого 24 2.3. Состояние блокчейна, учетные записи и хэш-карты language), а затем другие поля или аргументы конструктора, состоящие из необработанных байтов и ссылок на другие структуры в зависимости от выбранного конструктора (см. 2.2.5). Однако TVM ничего не знает о соответствии между конструкторами и их аргументами; смесь байтов и ссылок явно описывается определенными байтами дескриптора. 8 Хеширование дерева Меркла распространяется на произвольные такие структуры: для вычисления хэша такой структуры все ссылки рекурсивно заменяются хэшами объектов, на которые ссылаются, а затем вычисляется хэш результирующей байтовой строки (включая байты дескриптора). Таким образом, хеширование дерева Меркла для хэш-карт, описанное в 2.3.8, является всего лишь частным случаем хеширования для произвольных (зависимых) алгебраических типов данных, применяемых к типу Hashmap(n, X) с двумя конструкторами. 9 2.3.13. Постоянное хранение смарт-контрактов TON. Постоянное хранение смарт-контракта TON по существу состоит из его глобальных переменных , сохраняемых между вызовами смарт - контракта. Таким образом, это просто продукт, кортеж или тип записи, состоящий из полей правильных типов, соответствующих одной глобальной переменной. Если глобальных переменных слишком много, они не могут поместиться в одну ячейку TON из-за глобального ограничения на размер ячейки TON. В таком случае они разбиваются на несколько записей и организуются в дерево, по существу становясь продуктом продуктов или продуктом продуктов типа продуктов, а не просто типом продукта. 2.3.14. ТВМ-ячейки. В конечном счете, виртуальная машина TON хранит все данные в коллекции ячеек (TVM). Каждая ячейка содержит сначала два байта дескриптора, указывающих , сколько байтов необработанных данных присутствует в этой ячейке (до 128) и сколько ссылок на другие ячейки (до четырех). Затем следуют эти необработанные байты данных и ссылки. На каждую ячейку ссылаются ровно один раз, поэтому мы могли бы включить в каждую ячейку ссылку на ее родителя (единственную ячейку, ссылающуюся на эту ). Однако эта ссылка не обязательно должна быть явной. Таким образом, постоянные ячейки хранения данных смарт - контракта TON организованы в дерево, 10 со ссылкой на корень этого дерева, хранящийся в 8 Эти два байта дескриптора, присутствующие в любой ячейке TVM, описывают только общее количество ссылок и общее количество необработанных байтов; ссылки хранятся вместе либо до , либо после всех необработанных байтов. 9 На самом деле Leaf и Node являются конструкторами вспомогательного типа HashmapAux(n, X). Тип Hashmap(n, X) имеет конструкторы Root и EmptyRoot, причем Root содержит значение типа HashmapAux (n, X). 10 Логически; представление мешка ячеек, описанное в 2.5.5, идентифицирует все дубликаты 25 2.3. Состояние блокчейна, учетные записи и хэш-карты описание смарт-контракта. При необходимости рекурсивно вычисляется хэш дерева Меркла всего этого постоянного хранилища, начиная с листьев, а затем просто заменяя все ссылки в ячейке рекурсивно вычисленными хэшами ссылочных ячеек и впоследствии вычисляя хэш полученной таким образом байтовой строки. 2.3.15. Обобщенные доказательства Меркля для значений произвольных алгебраических типов. Поскольку виртуальная машина TON представляет значение произвольного алгебраического типа с помощью дерева, состоящего из ячеек (TVM), и каждая ячейка имеет хорошо определенный (рекурсивно вычисленный) хэш Меркла, фактически зависящий от всего поддерева , коренящегося в этой ячейке, мы можем предоставить обобщенные доказательства Меркла для (частейof) значения произвольных алгебраических типов, предназначенные для доказательства того, что определенное поддерево дерева с известным хешем Меркля принимает определенное значение c или значение с определенным хешем c. Это обобщает подход 2.3.10, где рассмотрены только доказательства Меркля для x [i]= y. 2.3.16. Поддержка сегментирования в структурах данных виртуальных машин TON. Мы только что описали, как виртуальная машина TON, не будучи чрезмерно сложной, поддерживает произвольные (зависимые) алгебраические типы данных в высокоуровневых языках смарт-контрактов . Однако шардинг крупных (или глобальных) смарт-контрактов требует специальной поддержки на уровне TON VM. С этой целью в систему была добавлена специальная версия типа hashmap, составляющая карточный счет X Эта карта может показаться эквивалентной Hashmap (m, X), где Счет = 2 m Однако, когда осколок разделяется на две части или два осколка объединяются, такие хэш-карты автоматически разделяются на две части или объединяются обратно, чтобы сохранить только те ключи, которые принадлежат соответствующему осколку. 2.3.17. Оплата за постоянное хранение. Примечательной особенностью блокчейна TON является плата, взимаемая со смарт-контрактов за хранение их постоянных данных (т. Е. За увеличение общего состояния блокчейна). Он работает следующим образом: Каждый блок объявляет две ставки, номинированные в основной валюте блокчейна (обычно монета TON): цена за хранение одной ячейки в постоянном хранилище и цена за хранение одного необработанного байта в некоторой ячейке постоянного хранилища. Статистика по общему количеству ячеек и байтов, используемых каждой учетной записью, хранится как часть ее состояния, поэтому, умножив эти числа на две ставки, объявленные в заголовке блока, мы можем вычислить платеж ячейки, преобразующие это дерево в ориентированный ациклический граф (dag) при сериализации. 26 2.3. Состояние блокчейна, учетные записи и хэш-карты списывается с баланса счета за сохранение его данных между предыдущим блоком и текущим. Однако плата за постоянное использование хранилища не взимается для каждой учетной записи и смарт-контракта в каждом блоке; вместо этого порядковый номер блока, в котором этот платеж был запрошен в последний раз,сохраняется в данных учетной записи, и когда с учетной записью выполняется какое-либо действие (например, передача значения или сообщение),полученный и обработанный смарт-контрактом), плата за использование хранилища для всех блоков, начиная с предыдущего такого платежа, вычитается из баланса счета перед выполнением каких-либо дальнейших действий. Если после этого баланс счета станет отрицательным, счет будет уничтожен. Workchain может объявить некоторое количество необработанных байтов данных на учетную запись бесплатными (т. Е. Не участвующими в постоянных платежах за хранение), чтобы освободить простые учетные записи, которые хранят только свой баланс в одной или двух криптовалютах, от этих постоянных платежей. Обратите внимание, что если никто не отправляет никаких сообщений на учетную запись, ее постоянные платежи за хранение не собираются, и она может существовать независимо. Однако любой может отправить, например, пустое сообщение, чтобы уничтожить такую учетную запись. Отправителю такого сообщения может быть выдан небольшой стимул, собранный с части первоначального баланса уничтожаемого счета Однако мы ожидаем, что валидаторы будут уничтожать такие неплатежеспособные учетные записи бесплатно, просто чтобы уменьшить размер глобального состояния блокчейна и избежать хранения больших объемов данных без компенсации. Платежи, собранные за хранение постоянных данных, распределяются между валидаторами shardchain или masterchain (пропорционально их долям в последнем случае). 2.3.18. Локальные и глобальные смарт-контракты; экземпляры смарт-контрактов. Смарт-контракт обычно находится только в одном осколке, выбранном в соответствии с account_id смарт-контракта , аналогично обычной учетной записи. Обычно этого достаточно для большинства применений. Однако некоторые высоконагруженные смарт- контракты могут захотеть иметь экземпляр в каждой цепочке осколков некоторой рабочей цепочки. Чтобы достичь этого, они должны распространить свою транзакцию создания на все цепочки шардов, например, зафиксировав эту транзакцию в корневой цепочке шардов (w,∅). 11 из workchain w и платить большую комиссию. 12 11 Более дорогой альтернативой является публикация такого глобального смарт - контракта в mas- терчейн. 12 Это своего рода функция трансляции для всех осколков, и как таковая, она должна быть довольно дорого. 27 2.3. Состояние блокчейна, учетные записи и хэш-карты Это действие эффективно создает экземпляры смарт - контракта в каждом осколке с отдельными балансами. Первоначально баланс, переданный в транзакции создания, распределяется просто путем передачи экземпляра в shard (w, s) 2 - −s| часть общего баланса. Когда осколок разбивается на два дочерних осколка, балансы всех экземпляров глобальных смарт-контрактов делятся пополам; когда два осколка сливаются, балансы суммируются. В некоторых случаях разделение / слияние экземпляров глобальных смарт-контрактов может включать (отложенное) выполнение специальных методов этих смарт-контрактов. По умолчанию балансы разделяются и объединяются, как описано выше, и некоторые специальные индексированные счетом хэш-карты также автоматически разделяются и объединяются (см. 2.3.16). 2.3.19. Ограничение разделения смарт - контрактов. Глобальный смарт-контракт может ограничить глубину расщепления d при его создании, чтобы сделать постоянные расходы на хранение более предсказуемыми. Это означает, что если shardchain (w, s) с |s| ≥ d разделяется на две части, только одна из двух новых цепочек шардов наследует экземпляр смарт-контракта. Этот shardchain выбран детерминированно: каждый глобальный смарт-контракт имеет некоторый account_id , который по сути является хэшем его создание транзакции, и ее экземпляры имеют один и тот же account_id с первыми битами ≤ d, замененными подходящими значениями, необходимыми для попадания в правильный шард. Этот account_id выбирает, какой осколок унаследует экземпляр смарт-контракта после разделения. 2.3.20. Состояние счета / смарт-контракта. Суммируя все вышесказанное, можно сделать вывод, что состояние учетной записи или смарт-контракта состоит из : ˆ Баланс в основной валюте блокчейна ˆ Баланс в других валютах блокчейна ˆ Код смарт-контракта (или его хэш) ˆ Постоянные данные смарт-контракта (или его хэш Merkle) ˆ Статистика по количеству постоянных ячеек памяти и используемых необработанных байтов ˆ Последний раз (собственно, номер блока masterchain), когда была собрана плата за постоянное хранение смарт-контракта 28 2.4. Сообщения между шардчейнами ˆ Открытый ключ, необходимый для перевода валюты и отправки сообщений с этой учетной записи (необязательно; по умолчанию равен самому account_id). В некоторых случаях здесь может быть расположен более сложный код проверки подписи,аналогичный тому, что делается для вывода биткойн-транзакций; тогда account_id будет равен хэшу этого кода. Нам также нужно где-то хранить, либо в состоянии учетной записи, либо в какой-то другой индексированной учетной записью хэш-карте, следующие данные: ˆ Очередь выходных сообщений учетной записи (см. 2.4.17) ˆ Коллекция (хэшей) недавно доставленных сообщений (см. 2.4.23) Не все из них действительно необходимы для каждой учетной записи; например, код smartcontract необходим только для смарт-контрактов, но не для простых учетных записей. Кроме того, в то время как любой счет должен иметь ненулевой баланс в основной валюте (например, монеты TON для masterchain и shardchain базовой рабочей цепочки), он может иметь нулевой баланс в других валютах. Чтобы избежать хранения неиспользуемых данных, определяется тип sum-product (в зависимости от рабочей цепочки) (во время создания рабочей цепочки), который использует разные байты тегов (например, конструкторы TL; ср. 2.2.5) различать используемые различные конструкторы. В конечном счете, состояние учетной записи само по себе сохраняется как набор ячеек постоянного хранилища TVM. 2.4 Сообщения между цепочками осколков Важным компонентом блокчейна TON является система обмена сообщениями между блокчейнами. Эти блокчейны могут быть шардчейнами одной и той же рабочей цепочки или разных рабочих цепочек. 2.4.1. Сообщения, счета и транзакции: обзор системы с высоты птичьего полета. Сообщения отправляются из одной учетной записи в другую. Каждая транзакция состоит из получения учетной записью одного сообщения, изменения ее состояния в соответствии с определенными правилами и генерации нескольких (возможно, одного или нуля) новых сообщений другим учетным записям. Каждое сообщение генерируется и принимается (доставляется) ровно один раз. Это означает, что сообщения играют фундаментальную роль в системе, сравнимую с ролью счетов (смарт-контрактов). С точки зрения парадигмы конечного шардинга (см. 2.1.2), каждая учетная запись находится в отдельной цепочке учетных записей , и единственный способ повлиять на состояние какой-либо другой учетной записи-это отправить сообщение. 29 2.4. Сообщения между шардчейнами 2.4.2. Учетные записи как процессы или акторы; Модель актора. Можно думать об учетных записях (и смарт-контрактах) как о процессах или актерах , которые способны обрабатывать входящие сообщения , изменять их внутреннее состояние и в результате генерировать некоторые исходящие сообщения. Это тесно связано с так называемой моделью актора, используемой в таких языках, как Erlang (однако актеры в Erlang обычно называются процессами). Поскольку новые акторы (т. Е. Смарт - контракты) также могут быть созданы существующими акторами в результате обработки входящего сообщения, соответствие с моделью актора по существу завершено. 2.4.3. Получатель сообщения. Любое сообщение имеет своего получателя, характеризуемого идентификатором целевой рабочей цепочки w (по умолчанию предполагается, что он совпадает с идентификатором исходной цепочки осколков) и идентификатором учетной записи получателя account_id . Точный формат (т. е. количество битов) account_id зависит от w; однако осколок всегда определяется его первыми (наиболее значимыми) 64 битами. 2.4.4. Отправитель сообщения. В большинстве случаев сообщение имеет отправителя, который снова характеризуется парой (w, account_id). Если он присутствует, он находится после получателя сообщения и значения сообщения. Иногда отправитель неважен или это кто-то вне блокчейна (т. е. Не смарт-контракт), и в этом случае это поле отсутствует. Обратите внимание, что модель актера не требует, чтобы сообщения имели неявного отправителя. Вместо этого сообщения могут содержать ссылку на Субъекта , которому должен быть отправлен ответ на запрос; обычно она совпадает с отправителем. Тем не менее, полезно иметь явное поле отправителя в сообщении в криптовалютной (византийской) среде. 2.4.5. Значение сообщения. Еще одной важной характеристикой сообщения является его прикрепленное значение в одной или нескольких криптовалютах, поддерживаемых как источником, так и целевой рабочей цепочкой. Значение сообщения указывается в самом его начале сразу после получателя сообщения; по сути , это список пар (currency_id, value). Обратите внимание, что простые передачи значений между простыми учетными записями-это просто пустые сообщения (no-op) с прикрепленным к ним значением. С другой стороны, несколько более сложное тело сообщения может содержать простой текст или двоичный комментарий (например, о цели платежа). 2.4.6. Внешние сообщения или сообщения из ниоткуда . Некоторые сообщения поступают в систему из ниоткуда, то есть они не генерируются учетной записью (смарт-контрактом или нет), находящейся в блокчейне. Самые 30 2.4. Сообщения между шардчейнами типичный пример возникает, когда пользователь хочет перевести часть средств с контролируемого им счета на какой-то другой счет. В этом случае пользователь отправляет сообщение из ниоткуда в свою учетную запись, прося ее сгенерировать сообщение для принимающей учетной записи, несущей указанное значение. Если это сообщение подписано правильно, ее учетная запись получает его и генерирует необходимые исходящие сообщения. На самом деле, можно рассматривать простую учетную запись как частный случай смарт -контракта с предопределенным кодом. Этот смарт - контракт получает только один тип сообщения. Такое входящее сообщение должно содержать список исходящих сообщений , которые будут сформированы в результате доставки (обработки) входящего сообщения, а также подпись. Смарт-контракт проверяет подпись и, если она верна, генерирует необходимые сообщения. Конечно, есть разница между сообщениями из ниоткуда и обычными сообщениями, потому что сообщения из ниоткуда не могут иметь ценности, поэтому они не могут сами платить за свой газ (то есть за свою обработку). Вместо этого они предварительно выполняются с небольшим пределом газа,прежде чем даже быть предложенным для включения в новый блок shardchain; если выполнение не удается ( подпись неверна), сообщение из ниоткуда считается неправильным и отбрасывается. Если выполнение не завершается неудачно в пределах малого предела газа, то message может быть включен в новый блок shardchain и полностью обработан, при этом плата за потребленный газ (перерабатывающие мощности) взимается со счета получателя. Сообщения из ниоткуда также могут содержать некоторую комиссию за транзакцию, которая вычитается со счета получателя поверх платы за газ для перераспределения валидаторам. |