Открытая сеть. Открытая сеть по материалам работы дра Николая Дурова 26 июля 2021
 Скачать 0.79 Mb.
|
|
Поэтому необходим реестр, в котором узлы, готовые создавать новые ссылки, могут публиковать свою контактную информацию (например, свои абстрактные адреса). 4.2.2. Пример: загрузка файла в хранилище TON. Точно так же, если кто -то хочет загрузить файл в хранилище TON, он должен найти некоторые узлы 102 4.3. Доступ к сервисам TON готовы подписать смарт-контракт, обязывающий их хранить копию этого файла (или любого файла ниже определенного предела размера, если уж на то пошло). Поэтому необходим реестр узлов, предоставляющих свои услуги для хранения файлов. 4.2.3. On-chain, mixed и o - chain реестры. Такой реестр поставщиков услуг может быть реализован полностью по цепочке, с помощью смарт-контракта, который будет хранить реестр в его постоянном хранилище. Однако это было бы довольно медленно и дорого. Смешанный подход более эффективен, когда относительно небольшой и редко изменяемый сетевой реестр используется только для указания некоторых узлов (по их абстрактным адресам или по их открытым ключам, которые могут быть использованы для поиска фактических абстрактных адресов, как описано в 3.2.12), обеспечивающих o-chain (централизованные) службы реестра. Наконец, децентрализованный, чисто цепной подход может состоять из публичной оверлейной сети (см. 3.3), где те,кто хочет предложить свои услуги, или те,кто хочет купить чьи-то услуги, просто транслируют свои предложения, подписанные их закрытыми ключами. Если предоставляемая услуга очень проста, то даже трансляция предложений может оказаться ненужной: приблизительное членство самой оверлейной сети может быть использовано в качестве реестра желающих предоставить ту или иную услугу. Тогда клиент, нуждающийся в этой услуге, может найти (ср. 3.3.7) и запросить некоторые узлы этой оверлейной сети, а затем запросить их соседей, если уже известные узлы не готовы удовлетворить ее потребности. 4.2.4. Реестр или биржа в боковой цепочке. Другой подход к внедрению децентрализованных смешанных реестров заключается в создании независимого специализированного блокчейна (side-chain), поддерживаемого собственным набором самопровозглашенных валидаторов, которые публикуют свои идентификаторы в смарт- контракте on-chain и предоставляют сетевой доступ всем заинтересованным сторонам к этому специализированному блокчейну, собирая кандидатов на транзакции и транслируя обновления блоковчерез выделенные оверлейные сети (см. 3.3). Тогда любой полный узел для этой боковой цепи может поддерживать свою собственную копию общего реестра (по существу равную глобальному состоянию этой боковой цепи) и обрабатывать произвольные запросы, связанные с этим реестром. 4.2.5. Реестр или биржа в рабочей цепочке. Другой вариант- создать специальную рабочую цепочку внутри блокчейна TON, специализирующуюся на создании реестров, рынков и бирж. Это может быть более эффективным и менее дорогостоящим, чем использование смарт-контрактов, находящихся в базовой рабочей цепочке (см. 2.1.11). Однако это все равно будет дороже, чем ведение реестров в боковых цепочках (см. 4.2.4). 103 4.3. Доступ к сервисам TON 4.3 Доступ к услугам TON В разделе 4.1 мы обсудили различные подходы, которые можно использовать для создания новых сервисов и приложений, находящихся в экосистеме TON. Теперь мы обсудим, как можно получить доступ к этим службам, а также некоторые вспомогательные службы, которые будут предоставляться TON, включая TON DNS и TON Storage. 4.3.1. TON DNS: в основном цепная иерархическая служба доменных имен. TON DNS-это услуга prede ned, которая использует набор смарт -контрактов для хранения карты от удобочитаемых доменных имен до (256-битных) адресов узлов сети ADNL и учетных записей TON Blockchain и смарт -контрактов. В то время как любой может в принципе реализовать такой сервис, используя блокчейн TON, полезно иметь такой предопределенный сервис с хорошо известным интерфейсом, который будет использоваться по умолчанию всякий раз, когда приложение или служба хотят перевести читаемые человеком идентификаторы в адреса. 4.3.2. Варианты использования TON DNS. Например, пользователь, желающий перевести некоторую криптовалюту другому пользователю или продавцу, может предпочесть запомнить доменное имя TON DNS учетной записи этого пользователя или продавца, вместо того, чтобы держать свои 256-битные идентификаторы учетной записи под рукой и копировать их в поле получателя в своем легком кошелькеклиент. Аналогично, TON DNS может использоваться для определения идентификаторов учетных записей смарт -контрактов или точек входа ton-сервисов и ton-сайтов (см. 4.1.5), включая специализированный клиент ( ton-браузер) или обычный интернет-браузер в сочетании со специализированным расширением ton-прокси или автономным приложением, чтобы доставить пользователю WWW-подобный опыт просмотра. 4.3.3. Смарт-контракты TON DNS. DNS TON реализуется с помощью дерева специальных (DNS) смарт-контрактов. Каждый смарт-контракт DNS отвечает за регистрацию поддоменов некоторого фиксированного домена. Корневой смарт - контракт DNS, в котором будут храниться домены первого уровня системы TON DNS , находится в masterchain. Его идентификатор учетной записи должен быть жестко закодирован во все программное обеспечение, которое хочет получить прямой доступ к базе данных TON DNS. Любой смарт-контракт DNS содержит хэш-карту, отображающую строки переменной длины с нулевым окончанием UTF-8 в их значения . Эта hashmap реализована как двоичное дерево Patricia, аналогичное описанному в 2.3.7, но поддерживающее битовые строки переменной длины в качестве ключей. 104 4.3. Доступ к сервисам TON 4.3.4. Значения DNS hashmap или TON DNS записей. Что касается значений, то это записи TON DNS , описываемые TL-схемой (см. 2.2.5). Они состоят из магического числа,выбора одного из поддерживаемых вариантов, а затем либо идентификатора учетной записи, либо идентификатора смарт-контракта, либо абстрактного сетевого адреса (см. 2.2.5).3.1), или открытый ключ, используемый для поиска абстрактных адресов службы (см. 3.2.12), или описание оверлейной сети и так далее. Важным случаем является другой смарт-контракт DNS: в таком случае этот смарт-контракт используется для разрешения поддоменов своего домена. Таким образом, можно создать отдельные реестры для разных доменов, контролируемые владельцами этих доменов. Эти записи также могут содержать время истечения срока действия, время кэширования (обычно очень большое, поскольку обновление значений в блокчейне слишком часто обходится дорого) и в большинстве случаев ссылку на владельца рассматриваемого поддомена. Владелец имеет право изменить эту запись (в частности, поле владельца, передав тем самым домен под чужой контроль), а также продлить ее. 4.3.5. Регистрация новых поддоменов существующих доменов. Чтобы зарегистрировать новый поддомен существующего домена, просто посылается сообщение смарт-контракту, который является регистратором этого домена, содержащее поддомен (т. Е. Ключ), подлежащий регистрации, значение в одном из нескольких заданных форматов, личность владельца, адрес электронной почты.срок действия и некоторое количество криптовалюты определяется владельцем домена. Субдомены регистрируются в порядке очереди. 4.3.6. Извлечение данных из смарт-контракта DNS. В принципе, любой полный узел для masterchain или shardchain, содержащий смарт -контракт DNS, может найти любой поддомен в базе данных этого смарт-контракта, если известны структура и расположение хэш-карты в постоянном хранилище смарт-контракта. Однако этот подход будет работать только для определенных смарт-контрактов DNS. Это с треском провалилось бы, если бы использовался нестандартный смарт-контракт DNS. Вместо этого используется подход, основанный на общих интерфейсах смарт- контрактов и методах get (см. 4.3.11). Любой смарт - контракт DNS должен иметь метод get с известной сигнатурой, который вызывается для поиска ключа. Поскольку этот подход имеет смысл и для других смарт-контрактов, особенно для тех, которые предоставляют сетевые и смешанные услуги, мы подробно объясняем это в 4.3.11. 4.3.7. Перевод домена TON DNS. Когда-то любой полный узел, действующий сам по себе или от имени какого-то легкого клиента, может искать записи в базе данных 105 4.3. Доступ к сервисам TON любого смарт-контракта DNS произвольные доменные имена TON DNS могут быть рекурсивно переведены, начиная с хорошо известного и фиксированного корневого идентификатора смарт-контракта DNS (учетной записи). Например, если кто-то хочет перевести A. B. C, он ищет ключи. C,. B. C и A. B. C в базе данных корневого домена. Если первый из них не найден, а второй есть,и его значение является ссылкой на другой смарт-контракт DNS, то A ищется в базе данных этого смарт-контракта и извлекается окончательное значение 4.3.8. Перевод доменов TON DNS для легких узлов. Таким образом, полный узел для мастер-цепи, а также для всех шардчейнов, участвующих в процессе поиска домена, может перевести любое доменное имя в его текущее значение без внешней помощи. Легкий узел может запросить полный узел сделать это от своего имени и вернуть значение вместе с доказательством Merkle (см. 2.5.11). Это доказательство Merkle позволит легкому узлу проверить правильность ответа , поэтому такие ответы TON DNS не могут быть подделаны вредоносным перехватчиком.отличие от обычного протокола DNS. Поскольку нельзя ожидать, что ни один узел не будет полным узлом по отношению ко всем цепочкам осколков, фактическая трансляция домена TON DNS будет включать комбинацию этих двух стратегий. 4.3.9. Выделенные DNS-серверы TON . Можно было бы предоставить простой DNS-сервер TON , который получал бы DNS-запросы RPC (например, через протоколы ADNL или RLDP, описанные в 3.1), запрашивая, чтобы сервер переводил данный домен, обрабатывал эти запросы, пересылая некоторые подзапросы другим (полным) узлам, если это необходимо, и возвращал ответы на исходныйзапросы, дополненные доказательствами Меркля, если требуется. Такие DNS-серверы могут предлагать свои услуги (бесплатно или нет) любым другим узлам и особенно легким клиентам, используя один из методов, описанных в 4.2. Обратите внимание, что эти серверы, если рассматривать их как часть службы TON DNS, эффективно преобразуют ее из распределенной службы on-chain в распределенную службу TON DNS.распределенная смешанная служба (т. е. Служба тумана). На этом мы завершаем наш краткий обзор службы TON DNS, масштабируемого сетевого реестра для удобочитаемых доменных имен объектов TON Blockchain и TON Network. 4.3.10. Доступ к данным, хранящимся в смарт-контрактах. Мы уже видели , что иногда необходимо получить доступ к данным, хранящимся в смарт-контракте , не меняя его состояния. 106 4.3. Доступ к сервисам TON Зная детали реализации смарт-контракта, можно извлечь всю необходимую информацию из постоянного хранилища смарт-контракта, доступного всем полным узлам цепочки шардов, в которой находится смарт-контракт . Однако это довольно неэлегантный способ делать вещи, очень сильно зависящий от реализации смарт-контракта. 4.3.11. Получите методы смарт-контрактов. Лучшим способом было бы определить некоторые методы get в смарт-контракте, то есть некоторые типы входящих сообщений, которые не влияют на состояние смарт-контракта при доставке, но генерируют одно или несколько выходных сообщений, содержащих результат метода get . Таким образом, можно получить данные из смарт-контракта, зная только, что он реализует метод get с известной сигнатурой (т. Е. Известным форматом отправляемого входящего сообщения и получаемых в результате исходящих сообщений). Этот способ гораздо более элегантен и соответствует объектно - ориентированному программированию (ООП). Однако пока у него есть очевидный дефект: нужно фактически зафиксировать транзакцию в блокчейне (отправить сообщение get в смарт-контракт), дождаться, пока она будет зафиксирована и обработана валидаторами, извлечь ответ из нового блока и заплатить за газ (т. Е. За выполнение getметод на аппаратном обеспечении валидаторов). Это пустая трата ресурсов: методы get в любом случае не изменяют состояние смарт - контракта, поэтому их не нужно выполнять в блокчейне. 4.3.12. Предварительное исполнение методов get смарт-контрактов. Мы уже отмечали (см. 2.4.6), что любой полный узел может предварительно выполнить любой метод любого смарт-контракта (т. Е. Доставить Любое сообщение в смарт -контракт), начиная с данного состояния смарт-контракта, без фактического совершения соответствующей транзакции. Полный узел может просто загрузить код рассматриваемого смарт - контракта в виртуальную машину TON, инициализировать его постоянное хранилище из глобального состояния shardchain (известного всем полные узлы shardchain) и выполнить код смарт-контракта с входящим сообщением в качестве входного параметра. Созданные выходные сообщения дадут результат этого вычисления. Таким образом, любой полный узел может оценивать произвольные методы get произвольных смарт-контрактов при условии, что их подпись (т. Е. Формат входящих и исходящих сообщений) известна. Узел может отслеживать ячейки состояния цепочки осколков, к которым был получен доступ во время этой оценки, и создавать доказательство Меркле достоверности выполненного вычисления в интересах легкого узла , который мог бы попросить полный узел сделать это (см. 2.5.11). 107 4.3. Доступ к сервисам TON 4.3.13. Интерфейсы смарт-контрактов в TL-схемах. Напомним, что методы, реализуемые смарт-контрактом (т. е. принимаемые им входные сообщения ), по существу являются некоторыми TL-сериализованными объектами, которые могут быть описаны TL-схемой (ср. 2.2.5). Результирующие выходные сообщения могут быть описаны той же самой TL-схемой. Таким образом, интерфейс, предоставляемый смарт -контрактом другим учетным записям и смарт-контрактам, может быть формализован с помощью TL-схемы. В частности, (подмножество) методов get, поддерживаемых смарт-контрактом , может быть описано таким формализованным интерфейсом смарт-контракта. 4.3.14. Публичные интерфейсы смарт-контракта. Обратите внимание, что формализованный интерфейс смарт-контракта либо в виде TL-схемы (представлен в виде исходного файла TL; см. 2.2.5), либо в сериализованной форме, 34 может публиковаться, например, в специальном поле в описании счета смарт-контракта, хранящемся в блокчейне, или отдельно, если на этот интерфейс будут ссылаться много раз. В последнем случае хэш поддерживаемого публичного интерфейса может быть включен в описание смарт-контракта вместо самого описания интерфейса. Примером такого открытого интерфейса является смарт-контракт DNS, который должен реализовать по крайней мере один стандартный метод get для поиска поддоменов (см. 4.3.6). Стандартный метод регистрации новых поддоменов также может быть включен в стандартный публичный интерфейс смарт -контрактов DNS. 4.3.15. Пользовательский интерфейс смарт-контракта. Наличие открытого интерфейса для смарт - контракта имеет и другие преимущества. Например, клиентское приложение кошелька может загрузить такой интерфейс во время проверки смарт -контракта по запросу пользователя и отобразить список общедоступных методов (т. Е. Доступных действий), поддерживаемых смарт-контрактом,возможно, с некоторыми удобочитаемыми комментариями, если таковые имеются в формальном интерфейсе. После того, как пользователь выберет один из этих методов, форма может быть сгенерирована автоматически согласно TL-схеме, где пользователю будет предложено указать все поля , требуемые выбранным методом, и желаемое количество криптовалюты (например, монеты TON), которое будет прикреплено к этому запросу. Отправка этой формы создаст новую транзакцию blockchain,содержащую только что составленное сообщение, отправленное из учетной записи пользователя blockchain. Таким образом, пользователь сможет взаимодействовать с произвольными смарт - контрактами 34 TL-схемы могут быть TL-сериализованы сами по себе; ср. https://core.telegram.org/ mtproto / TL-tl. 108 4.3. Доступ к сервисам TON из клиентского приложения кошелька удобным для пользователя способом путем заполнения и отправки определенных форм при условии, что эти смарт-контракты опубликовали свои интерфейсы. 4.3.16. Пользовательский интерфейс ton-сервиса . Оказывается, что ton-сервисы (т. е. сервисы, находящиеся в сети TON и принимающие запросы по протоколам ADNL и RLDP 3; ср. 4.1.5) также могут иметь публичные интерфейсы, описываемые TL-схемами (ср. 2.2.5). Клиентское приложение, такое как light wallet или ton-браузер , может предложить пользователю выбрать один из методов и заполнить форму параметрами,определенными интерфейсом, аналогично тому, что только что обсуждалось в 4.3.15. Единственное отличие заключается в том, что результирующее TL-сериализованное сообщение не отправляется как транзакция в блокчейне; вместо этого оно отправляется как RPC-запрос на абстрактный адрес рассматриваемого ton-сервиса, а ответ на этот запрос анализируется и отображается в соответствии с формальным интерфейсом (т. Е., TL-схема). 4.3.17. Поиск пользовательских интерфейсов через TON DNS. DNS-запись TON , содержащая абстрактный адрес ton-сервиса или идентификатора учетной записи смарт-контракта, может также содержать необязательное поле, описывающее общедоступный (пользовательский) интерфейс этой сущности или несколько поддерживаемых интерфейсов. Тогда клиентское приложение (будь то кошелек, ton-браузер или ton-прокси) сможет загрузить интерфейс и взаимодействовать с рассматриваемой сущностью (будь то смарт -контракт или ton-сервис) единым способом. 4.3.18. Стирание различий между сервисами on-chain и o - chain . Таким образом, различие между on-chain, o-chain и смешанными сервисами (см. 4.1.2) размывается для конечного пользователя: он просто вводит доменное имя желаемого сервиса в адресную строку своего ton-браузера или кошелька, а остальное клиент обрабатывает без проблемприменение. 4.3.19. ton-сайты как ton-сервисы, поддерживающие HTTP-интерфейс. Ton-сайт-это просто ton-сервис, который поддерживает HTTP-интерфейс, возможно , наряду с некоторыми другими интерфейсами. Эта поддержка может быть объявлена в соответствующей записи TON DNS. |