Файл: Аннотация Цель данной работы предоставить первое описание блокчейнплатформы ton (The Open Network) и связанных с ней технологий одноранговых сетей, распределенного хранилища и хостинга..pdf
Добавлен: 25.10.2023
Просмотров: 220
Скачиваний: 3
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
4.2.5. Реестр или обмен в воркчейне. Другой вариант - создать отдельный воркчейн внутри блокчейна TON, специализирующийся на создании реестров, рынков и бирж.
Этот способ может быть более эффективным и менее затратным, чем использование смарт-контрактов в основном воркчейне (см. 2.1.11), однако это все равно будет дороже, чем поддержание реестров в сайдчейнах (см. 4.2.4).
78 4.3. Доступ к сервисам TON
4.3. Доступ к сервисам TON
В разделе 4.1 мы обсудили различные подходы, которые можно использовать для создания новых сервисов и приложений в экосистеме TON. Теперь мы обсудим, как можно получить доступ к этим сервисам, а также некоторые из «вспомогательных сервисов», которые будут предоставляться TON, включая TON DNS и TON Storage.
4.3.1. TON DNS: иерархическая служба доменных имен в сети (в основном
ончейн). TON DNS - это предопределенная служба, которая использует набор смарт- контрактов для сохранения карты от понятных человеку доменных имен до (256- битных) адресов сетевых узлов ADNL, учетных записей и смарт-контрактов блокчейна TON.
Хотя в принципе любой может реализовать такой сервис с использованием блокчейна
TON, полезно иметь подобный предопределенный сервис с хорошо известным интерфейсом, который будет использоваться по умолчанию всякий раз, когда приложение или сервис захочет преобразовать понятные человеку идентификаторы в адреса.
4.3.2. Примеры использования TON DNS. Например, пользователь, желающий передать некоторую криптовалюту другому пользователю или продавцу, может предпочесть запомнить доменное имя TON DNS учетной записи этого пользователя или продавца, вместо того, чтобы держать свои 256-битные идентификаторы учетных записей под рукой и копировать и вставлять их в поля информации о получателе, хранящейся в легком кошельке клиента.
Аналогичным образом, TON DNS может использоваться для определения идентификаторов учетных записей смарт-контрактов или точек входа в TON-сервисы и TON-сайты (см. 4.1.5), включая специализированный клиент («TON-браузер») или обычный интернет-браузер в сочетании со специализированным расширением ton- proxy или автономным приложением, чтобы предоставить пользователю возможность просмотра веб-страниц в стиле WWW.
4.3.3. Смарт-контракты TON DNS. TON DNS реализуется с помощью дерева специальных смарт-контрактов (DNS). Каждый смарт-контракт DNS отвечает за регистрацию поддоменов некоторого фиксированного домена. «Корневой» смарт- контракт DNS, в котором будут храниться домены первого уровня системы TON DNS, находится в мастерчейне. Соответствующий идентификатор учетной записи должен быть жестко запрограммирован во всем программном обеспечении, которое будет напрямую обращаться к базе данных TON DNS.
Любой смарт-контракт DNS содержит хэш-карту, отображающую строки UTF-8 переменной длины с завершающим нулем в их «значениях». Эта хэш-карта реализована в виде двоичного дерева Patricia, подобного дереву, описанному в 2.3.7, но также поддерживает битовые строки переменной длины в качестве ключей.
4.3.4. Значения хэш-карты DNS или записей TON DNS. Значения представлены в виде «DNS-записей TON», описываемых TL-схемой (см. 2.2.5). Они состоят из
«магического числа», выбора одной из поддерживаемых опций, а также одного из следующих идентификаторов: идентификатора учетной записи, идентификатора смарт-контракта, абстрактного сетевого адреса (см. 3.1), открытого ключа, используемого для определения местоположения абстрактных адресов сервиса (см.
3.2.12) или описания оверлейной сети и т. д. Важным является использование другого смарт-контракта DNS: в таком случае этот смарт-контракт используется для преобразования поддоменов собственного домена. Таким образом, можно создавать отдельные реестры для разных доменов, контролируемые владельцами этих доменов.
79
Эти записи также могут содержать время истечения срока действия, время кеширования (обычно очень большое, поскольку обновление значений в блокчейне слишком часто обходится дорого) и в большинстве случаев ссылку на владельца рассматриваемого поддомена. Владелец имеет право изменить эту запись (в частности, владелец может передать домен под чей-то контроль) и продлить ее.
4.3.5. Регистрация новых поддоменов существующих доменов. Чтобы зарегистрировать новый поддомен существующего домена, нужно просто отправить сообщение смарт-контракту, который является регистратором этого домена, содержащим поддомен (то есть ключ), который должен быть зарегистрирован, значение в одном из нескольких предопределенных форматов, личность владельца, срок действия и некоторое количество криптовалюты, определяемое владельцем домена.
Поддомены регистрируются по принципу «в порядке очереди».
4.3.6. Получение данных из смарт-контракта DNS. В принципе, любая полная нода мастерчейна или шардчейна, содержащая смарт-контракт DNS, может иметь возможность поиска любого поддомена в базе данных этого смарт-контракта, если известна структура и расположение хэш-карты в постоянном хранилище смарт- контракта.
Однако этот подход будет работать только для определенных смарт-контрактов DNS.
В случае использования нестандартного смарт-контракта DNS такой подход будет неуспешным.
Вместо этого используется подход, основанный на общих интерфейсах смарт- контрактов и методах получения (см. 4.3.11). Любой смарт-контракт DNS должен определять «метод получения» с «известной подписью», который вызывается для поиска ключа. Поскольку этот подход имеет смысл и для других смарт-контрактов, особенно для тех, которые обеспечивают сетевые и смешанные сервисы, он будет более подробно описан в п. 4.3.11.
4.3.7. Перевод домена TON DNS. Если любой полной ноде, действующей самой по себе или от имени какого-либо тонкого клиента, необходимо найти записи в базе данных любого смарт-контракта DNS, произвольные доменные имена TON DNS могут быть рекурсивно преобразованы, начиная с хорошо известного и фиксированного идентификатора корневого смарт-контракта DNS (учетной записи).
Например, если необходимо перевести А. В. C, следует найти ключи .С, .В.С и А.В.C в базе данных корневого домена. Если первый из них не был найден, а второй был найден, и его значение является ссылкой на другой смарт-контракт DNS, тогда A ищется в базе данных этого смарт-контракта, после чего извлекается окончательное значение.
4.3.8. Перевод доменов TON DNS для неполных нод. Таким образом, полная нода мастерчейна, а также всех шардчейнов, участвующих в процессе поиска домена, может преобразовывать любое доменное имя в его текущее значение без внешней помощи. Неполная нода может запросить полную ноду сделать это от своего имени и вернуть значение вместе с доказательством Меркла (см. 2.5.11). Это доказательство
Меркла позволит неполной ноде проверить правильность ответа, поэтому такие ответы TON DNS не могут быть «подделаны» злонамеренным перехватчиком, в отличие от обычного протокола DNS.
Поскольку нельзя ожидать, что нода будет полной нодой по отношению ко всем шардчейнам, фактическая трансляция домена TON DNS будет включать комбинацию этих двух стратегий.
4.3.9. Выделенные «серверы TON DNS». Можно предоставить простой «сервер TON
DNS», который будет получать RPC-запросы «DNS» (например, через протоколы
80 4.3. Доступ к сервисам TON
ADNL или RLDP, описанные в 3.1), запрашивая, чтобы сервер переводил данный домен, обрабатывал эти запросы, при необходимости перенаправляя некоторые подзапросы на другие (полные) ноды, и возвращать ответы на исходные запросы, дополненные доказательствами Меркла, если необходимо.
Такие «DNS-серверы» могут предлагать свои услуги (бесплатно или платно) любым другим узлам и особенно легким клиентам, используя один из методов, описанных в п. 4.2. Обратите внимание, что эти серверы, если их рассматривать как часть службы
TON DNS, эффективно преобразовали бы ее из распределенного сервиса в распределенный смешанный сервис (т. е. «сервис туманных вычислений»).
На этом мы завершаем краткий обзор службы TON DNS, масштабируемого сетевого реестра для понятных человеку доменных имен объектов блокчейна TON и сети TON
Network.
4.3.10. Доступ к данным, хранящимся в смарт-контрактах. Мы уже увидели, что иногда необходимо получить доступ к данным, хранящимся в смарт-контракте, без изменения его состояния.
Если пользователю известны детали реализации смарт-контракта, можно извлечь всю необходимую информацию из постоянного хранилища смарт-контракта, доступного для всех полных нод шардчейна, в котором находится смарт-контракт. Однако это довольно грубый способ, очень сильно зависящий от реализации смарт-контракта.
4.3.11. «Методы получения» смарт-контрактов. Лучшим способом было бы определить некоторые методы получения в смарт-контракте, то есть некоторые типы входящих сообщений, которые не влияют на состояние смарт-контракта при доставке, но генерируют одно или несколько выходных сообщений, содержащих «результат» метода получения. Таким образом, можно получить данные из смарт-контракта, зная только, что он реализует метод получения с известной подписью (т. е. известный формат входящего сообщения, которое должно быть отправлено, и исходящего сообщения, которое должно быть в результате получено).
Этот способ намного более изящный и соответствует объектно-ориентированному программированию (ООП). Однако у него имеется очевидный дефект: нужно фактически зафиксировать транзакцию в блокчейне (отправить сообщение get в смарт-контракт), дождаться, пока она будет зафиксирована и обработана валидаторами, извлечь ответ из нового блока и внести оплату за газ (то есть за выполнение метода получения на оборудовании валидаторов). Это пустая трата ресурсов: методы получения в любом случае не изменяют состояние смарт-контракта, поэтому их не нужно выполнять в блокчейне.
4.3.12. Предварительное выполнение методов получения смарт-контрактов. Мы уже отмечали (см. 2.4.6), что любая полная нода может предварительно выполнить любой метод любого смарт-контракта (то есть доставить любое сообщение в смарт- контракт), начиная с заданного состояния смарт-контракта, без фактического совершения соответствующей сделки. Полная нода может просто загрузить код рассматриваемого смарт-контракта в виртуальную машину TON, инициализировать свое постоянное хранилище из глобального состояния шардчейна (известного всем полным нодам шардчейна) и выполнить код смарт-контракта с входящим сообщением в качестве входного параметра. Созданные выходные сообщения будут иметь результат этого вычисления.
Таким образом, любая полная нода может оценивать произвольные методы получения произвольных смарт-контрактов, если известна их подпись (т. е. формат входящих и исходящих сообщений). Нода может отслеживать ячейки состояния шардчейна, к которым осуществляется доступ во время этой оценки, и создавать доказательство
81 4.3. Доступ к сервисам TON
Меркла валидности выполненных вычислений в пользу неполной ноды, которая отправила бы соответствующий запрос на полную ноду (см. 2.5.11).
4.3.13. Интерфейсы смарт-контрактов в TL-схемах. Напомним, что методы, реализованные в смарт-контракте (то есть принимаемые им входные сообщения), по сути, являются некоторыми TL-сериализированными объектами, которые могут быть описаны TL-схемой (см. 2.2.5). Полученные выходные сообщения также можно описать той же TL-схемой. Таким образом, интерфейс смарт-контракта с другими учетными записями и смарт-контрактами может быть формализован с помощью TL- схемы.
В частности, (подмножество) методов получения, поддерживаемых смарт- контрактом, можно описать с помощью такого формализованного интерфейса смарт- контракта.
4.3.14. Публичные интерфейсы смарт-контракта. Обратите внимание, что формализованный интерфейс смарт-контракта, в форме TL-схемы (представленной как исходный файл TL; см. 2.2.5), либо в сериализированной форме
34
, может быть опубликован, например, в специальной форме, хранящейся в описании учетной записи смарт-контракта, хранящемся в блокчейне или отдельно, если к этому интерфейсу будут часто обращаться. В последнем случае хэш поддерживаемого общедоступного интерфейса может быть включен в описание смарт-контракта вместо самого описания интерфейса.
Примером такого общедоступного интерфейса является смарт-контракт DNS, который должен реализовывать как минимум один стандартный метод получения для поиска поддоменов (см. 4.3.6). Стандартный метод регистрации новых поддоменов также может быть включен в стандартный общедоступный интерфейс смарт- контрактов DNS.
4.3.15.
Пользовательский
интерфейс
смарт-контракта.
Существование публичного интерфейса для смарт-контракта имеет и другие преимущества.
Например, клиентское приложение кошелька может загружать такой интерфейс при изучении смарт-контракта по запросу пользователя и отображать список общедоступных методов (то есть доступных действий), поддерживаемых смарт-контрактом, возможно, с некоторыми удобочитаемыми комментариями, если таковые имеются, в формальном интерфейсе. После того, как пользователь выберет один из этих методов, форма может быть автоматически сгенерирована в соответствии с TL-схемой, где пользователю будет предложено ввести все поля, необходимые для выбранного метода, и желаемое количество криптовалюты (например, монет TON) которые должны быть прикрепленным к этому запросу. Отправка этой формы создаст новую транзакцию блокчейна, содержащую только что составленное сообщение, отправленное из учетной записи блокчейна пользователя.
Таким образом, пользователь сможет взаимодействовать с произвольными смарт- контрактами из клиентского приложения кошелька удобным для пользователя способом, заполняя и отправляя определенные формы, при условии, что эти смарт- контракты опубликовали свои интерфейсы.
4.3.16. Пользовательский интерфейс «TON-сервиса». «TON-сервисы» (т. е. cервисы, находящиеся в сети TON и принимающие запросы через протоколы ADNL и RLDP из 3; см. 4.1.5) также могут получить прибыль от наличия общедоступных
34
TL-схемы сами могут быть TL-сериализированы; см. https://core.telegram.org/mtproto/TL-tl
82 4.3. Доступ к сервисам TON интерфейсов, описываемых TL- схемами (см. 2.2.5). Клиентское приложение, такое как легкий кошелек или «тонкий браузер», может предлагать пользователю выбрать один из методов и заполнить форму с параметрами, определенными интерфейсом, аналогично той схеме, которая только что обсуждалась в 4.3. 15. Единственное отличие состоит в том, что результирующее TL-сериализированное сообщение не отправляется как транзакция в блокчейне; вместо этого оно отправляется как запрос
RPC на абстрактный адрес рассматриваемого «TON-сервиса», и ответ на этот запрос анализируется и отображается в соответствии с формальным интерфейсом (т. е. TL- схемой).
4.3.17. Поиск пользовательских интерфейсов через TON DNS. Запись TON DNS, содержащая абстрактный адрес TON-сервиса или идентификатор учетной записи смарт-контракта, также может содержать необязательное поле, описывающее общедоступный (пользовательский) интерфейс этого объекта или несколько поддерживаемых интерфейсов. Затем клиентское приложение (будь то кошелек,
TON-браузер или TON-прокси) сможет загружать интерфейс и взаимодействовать с рассматриваемым объектом (будь то смарт-контракт или TON-сервис).
4.3.18. Стирание различий между ончейн и оффчейн сервисами. Таким образом, различие между ончейн, оффчейн и смешанными сервисами (см. 4.1.2) стирается для конечного пользователя: он просто вводит доменное имя необходимого сервиса в адресную строку своего TON-браузера или кошелек, а остальное легко обрабатывается клиентским приложением.
4.3.19. «TON-сайты» как TON-сервисы, поддерживающие HTTP-интерфейс.
TON-сайт - это просто TON-сервис, который поддерживает интерфейс HTTP, возможно, вместе с некоторыми другими интерфейсами. Об этой поддержке можно объявить в соответствующей записи TON DNS.
4.3.20. Гиперссылки. Обратите внимание, что HTML-страницы, возвращаемые TON- сайтами, могут содержать TON-гиперссылки (то есть ссылки на другие TON-сайты, смарт-контракты и учетные записи посредством специально созданных схем URI (см.
4.3.21)), содержащие абстрактные сетевые адреса, идентификаторы учетных записей или человекочитаемые домены TON DNS. Затем «TON-браузер» может следовать по такой гиперссылке, когда пользователь выбирает ее, обнаруживать интерфейс, который будет использоваться, и отображать форму пользовательского интерфейса, как описано в 4.3.15 и 4.3.16.
4.3.21. URL-адреса гиперссылок могут указывать некоторые параметры. URL- адреса гиперссылок могут содержать не только DNS-домен (TON) или абстрактный адрес рассматриваемого сервиса, но также имя вызываемого метода и некоторые или все его параметры. Возможная схема URI для этого может выглядеть следующим образом:
Когда пользователь выбирает такую ссылку в TON-браузере, то действие либо выполняется немедленно (особенно если это метод получения смарт-контракта, вызываемый анонимно), либо отображается частично заполненная форма, которая должна быть явно подтверждена и отправлена пользователем (это может потребоваться для форм оплаты).
4.3.22. POST-действия. TON-сайт может встраиваться в HTML-страницы, он возвращает некоторые обычные POST-формы, при этом POST-действия ссылаются на
Этот способ может быть более эффективным и менее затратным, чем использование смарт-контрактов в основном воркчейне (см. 2.1.11), однако это все равно будет дороже, чем поддержание реестров в сайдчейнах (см. 4.2.4).
78 4.3. Доступ к сервисам TON
4.3. Доступ к сервисам TON
В разделе 4.1 мы обсудили различные подходы, которые можно использовать для создания новых сервисов и приложений в экосистеме TON. Теперь мы обсудим, как можно получить доступ к этим сервисам, а также некоторые из «вспомогательных сервисов», которые будут предоставляться TON, включая TON DNS и TON Storage.
4.3.1. TON DNS: иерархическая служба доменных имен в сети (в основном
ончейн). TON DNS - это предопределенная служба, которая использует набор смарт- контрактов для сохранения карты от понятных человеку доменных имен до (256- битных) адресов сетевых узлов ADNL, учетных записей и смарт-контрактов блокчейна TON.
Хотя в принципе любой может реализовать такой сервис с использованием блокчейна
TON, полезно иметь подобный предопределенный сервис с хорошо известным интерфейсом, который будет использоваться по умолчанию всякий раз, когда приложение или сервис захочет преобразовать понятные человеку идентификаторы в адреса.
4.3.2. Примеры использования TON DNS. Например, пользователь, желающий передать некоторую криптовалюту другому пользователю или продавцу, может предпочесть запомнить доменное имя TON DNS учетной записи этого пользователя или продавца, вместо того, чтобы держать свои 256-битные идентификаторы учетных записей под рукой и копировать и вставлять их в поля информации о получателе, хранящейся в легком кошельке клиента.
Аналогичным образом, TON DNS может использоваться для определения идентификаторов учетных записей смарт-контрактов или точек входа в TON-сервисы и TON-сайты (см. 4.1.5), включая специализированный клиент («TON-браузер») или обычный интернет-браузер в сочетании со специализированным расширением ton- proxy или автономным приложением, чтобы предоставить пользователю возможность просмотра веб-страниц в стиле WWW.
4.3.3. Смарт-контракты TON DNS. TON DNS реализуется с помощью дерева специальных смарт-контрактов (DNS). Каждый смарт-контракт DNS отвечает за регистрацию поддоменов некоторого фиксированного домена. «Корневой» смарт- контракт DNS, в котором будут храниться домены первого уровня системы TON DNS, находится в мастерчейне. Соответствующий идентификатор учетной записи должен быть жестко запрограммирован во всем программном обеспечении, которое будет напрямую обращаться к базе данных TON DNS.
Любой смарт-контракт DNS содержит хэш-карту, отображающую строки UTF-8 переменной длины с завершающим нулем в их «значениях». Эта хэш-карта реализована в виде двоичного дерева Patricia, подобного дереву, описанному в 2.3.7, но также поддерживает битовые строки переменной длины в качестве ключей.
4.3.4. Значения хэш-карты DNS или записей TON DNS. Значения представлены в виде «DNS-записей TON», описываемых TL-схемой (см. 2.2.5). Они состоят из
«магического числа», выбора одной из поддерживаемых опций, а также одного из следующих идентификаторов: идентификатора учетной записи, идентификатора смарт-контракта, абстрактного сетевого адреса (см. 3.1), открытого ключа, используемого для определения местоположения абстрактных адресов сервиса (см.
3.2.12) или описания оверлейной сети и т. д. Важным является использование другого смарт-контракта DNS: в таком случае этот смарт-контракт используется для преобразования поддоменов собственного домена. Таким образом, можно создавать отдельные реестры для разных доменов, контролируемые владельцами этих доменов.
79
Эти записи также могут содержать время истечения срока действия, время кеширования (обычно очень большое, поскольку обновление значений в блокчейне слишком часто обходится дорого) и в большинстве случаев ссылку на владельца рассматриваемого поддомена. Владелец имеет право изменить эту запись (в частности, владелец может передать домен под чей-то контроль) и продлить ее.
4.3.5. Регистрация новых поддоменов существующих доменов. Чтобы зарегистрировать новый поддомен существующего домена, нужно просто отправить сообщение смарт-контракту, который является регистратором этого домена, содержащим поддомен (то есть ключ), который должен быть зарегистрирован, значение в одном из нескольких предопределенных форматов, личность владельца, срок действия и некоторое количество криптовалюты, определяемое владельцем домена.
Поддомены регистрируются по принципу «в порядке очереди».
4.3.6. Получение данных из смарт-контракта DNS. В принципе, любая полная нода мастерчейна или шардчейна, содержащая смарт-контракт DNS, может иметь возможность поиска любого поддомена в базе данных этого смарт-контракта, если известна структура и расположение хэш-карты в постоянном хранилище смарт- контракта.
Однако этот подход будет работать только для определенных смарт-контрактов DNS.
В случае использования нестандартного смарт-контракта DNS такой подход будет неуспешным.
Вместо этого используется подход, основанный на общих интерфейсах смарт- контрактов и методах получения (см. 4.3.11). Любой смарт-контракт DNS должен определять «метод получения» с «известной подписью», который вызывается для поиска ключа. Поскольку этот подход имеет смысл и для других смарт-контрактов, особенно для тех, которые обеспечивают сетевые и смешанные сервисы, он будет более подробно описан в п. 4.3.11.
4.3.7. Перевод домена TON DNS. Если любой полной ноде, действующей самой по себе или от имени какого-либо тонкого клиента, необходимо найти записи в базе данных любого смарт-контракта DNS, произвольные доменные имена TON DNS могут быть рекурсивно преобразованы, начиная с хорошо известного и фиксированного идентификатора корневого смарт-контракта DNS (учетной записи).
Например, если необходимо перевести А. В. C, следует найти ключи .С, .В.С и А.В.C в базе данных корневого домена. Если первый из них не был найден, а второй был найден, и его значение является ссылкой на другой смарт-контракт DNS, тогда A ищется в базе данных этого смарт-контракта, после чего извлекается окончательное значение.
4.3.8. Перевод доменов TON DNS для неполных нод. Таким образом, полная нода мастерчейна, а также всех шардчейнов, участвующих в процессе поиска домена, может преобразовывать любое доменное имя в его текущее значение без внешней помощи. Неполная нода может запросить полную ноду сделать это от своего имени и вернуть значение вместе с доказательством Меркла (см. 2.5.11). Это доказательство
Меркла позволит неполной ноде проверить правильность ответа, поэтому такие ответы TON DNS не могут быть «подделаны» злонамеренным перехватчиком, в отличие от обычного протокола DNS.
Поскольку нельзя ожидать, что нода будет полной нодой по отношению ко всем шардчейнам, фактическая трансляция домена TON DNS будет включать комбинацию этих двух стратегий.
4.3.9. Выделенные «серверы TON DNS». Можно предоставить простой «сервер TON
DNS», который будет получать RPC-запросы «DNS» (например, через протоколы
80 4.3. Доступ к сервисам TON
ADNL или RLDP, описанные в 3.1), запрашивая, чтобы сервер переводил данный домен, обрабатывал эти запросы, при необходимости перенаправляя некоторые подзапросы на другие (полные) ноды, и возвращать ответы на исходные запросы, дополненные доказательствами Меркла, если необходимо.
Такие «DNS-серверы» могут предлагать свои услуги (бесплатно или платно) любым другим узлам и особенно легким клиентам, используя один из методов, описанных в п. 4.2. Обратите внимание, что эти серверы, если их рассматривать как часть службы
TON DNS, эффективно преобразовали бы ее из распределенного сервиса в распределенный смешанный сервис (т. е. «сервис туманных вычислений»).
На этом мы завершаем краткий обзор службы TON DNS, масштабируемого сетевого реестра для понятных человеку доменных имен объектов блокчейна TON и сети TON
Network.
4.3.10. Доступ к данным, хранящимся в смарт-контрактах. Мы уже увидели, что иногда необходимо получить доступ к данным, хранящимся в смарт-контракте, без изменения его состояния.
Если пользователю известны детали реализации смарт-контракта, можно извлечь всю необходимую информацию из постоянного хранилища смарт-контракта, доступного для всех полных нод шардчейна, в котором находится смарт-контракт. Однако это довольно грубый способ, очень сильно зависящий от реализации смарт-контракта.
4.3.11. «Методы получения» смарт-контрактов. Лучшим способом было бы определить некоторые методы получения в смарт-контракте, то есть некоторые типы входящих сообщений, которые не влияют на состояние смарт-контракта при доставке, но генерируют одно или несколько выходных сообщений, содержащих «результат» метода получения. Таким образом, можно получить данные из смарт-контракта, зная только, что он реализует метод получения с известной подписью (т. е. известный формат входящего сообщения, которое должно быть отправлено, и исходящего сообщения, которое должно быть в результате получено).
Этот способ намного более изящный и соответствует объектно-ориентированному программированию (ООП). Однако у него имеется очевидный дефект: нужно фактически зафиксировать транзакцию в блокчейне (отправить сообщение get в смарт-контракт), дождаться, пока она будет зафиксирована и обработана валидаторами, извлечь ответ из нового блока и внести оплату за газ (то есть за выполнение метода получения на оборудовании валидаторов). Это пустая трата ресурсов: методы получения в любом случае не изменяют состояние смарт-контракта, поэтому их не нужно выполнять в блокчейне.
4.3.12. Предварительное выполнение методов получения смарт-контрактов. Мы уже отмечали (см. 2.4.6), что любая полная нода может предварительно выполнить любой метод любого смарт-контракта (то есть доставить любое сообщение в смарт- контракт), начиная с заданного состояния смарт-контракта, без фактического совершения соответствующей сделки. Полная нода может просто загрузить код рассматриваемого смарт-контракта в виртуальную машину TON, инициализировать свое постоянное хранилище из глобального состояния шардчейна (известного всем полным нодам шардчейна) и выполнить код смарт-контракта с входящим сообщением в качестве входного параметра. Созданные выходные сообщения будут иметь результат этого вычисления.
Таким образом, любая полная нода может оценивать произвольные методы получения произвольных смарт-контрактов, если известна их подпись (т. е. формат входящих и исходящих сообщений). Нода может отслеживать ячейки состояния шардчейна, к которым осуществляется доступ во время этой оценки, и создавать доказательство
81 4.3. Доступ к сервисам TON
Меркла валидности выполненных вычислений в пользу неполной ноды, которая отправила бы соответствующий запрос на полную ноду (см. 2.5.11).
4.3.13. Интерфейсы смарт-контрактов в TL-схемах. Напомним, что методы, реализованные в смарт-контракте (то есть принимаемые им входные сообщения), по сути, являются некоторыми TL-сериализированными объектами, которые могут быть описаны TL-схемой (см. 2.2.5). Полученные выходные сообщения также можно описать той же TL-схемой. Таким образом, интерфейс смарт-контракта с другими учетными записями и смарт-контрактами может быть формализован с помощью TL- схемы.
В частности, (подмножество) методов получения, поддерживаемых смарт- контрактом, можно описать с помощью такого формализованного интерфейса смарт- контракта.
4.3.14. Публичные интерфейсы смарт-контракта. Обратите внимание, что формализованный интерфейс смарт-контракта, в форме TL-схемы (представленной как исходный файл TL; см. 2.2.5), либо в сериализированной форме
34
, может быть опубликован, например, в специальной форме, хранящейся в описании учетной записи смарт-контракта, хранящемся в блокчейне или отдельно, если к этому интерфейсу будут часто обращаться. В последнем случае хэш поддерживаемого общедоступного интерфейса может быть включен в описание смарт-контракта вместо самого описания интерфейса.
Примером такого общедоступного интерфейса является смарт-контракт DNS, который должен реализовывать как минимум один стандартный метод получения для поиска поддоменов (см. 4.3.6). Стандартный метод регистрации новых поддоменов также может быть включен в стандартный общедоступный интерфейс смарт- контрактов DNS.
4.3.15.
Пользовательский
интерфейс
смарт-контракта.
Существование публичного интерфейса для смарт-контракта имеет и другие преимущества.
Например, клиентское приложение кошелька может загружать такой интерфейс при изучении смарт-контракта по запросу пользователя и отображать список общедоступных методов (то есть доступных действий), поддерживаемых смарт-контрактом, возможно, с некоторыми удобочитаемыми комментариями, если таковые имеются, в формальном интерфейсе. После того, как пользователь выберет один из этих методов, форма может быть автоматически сгенерирована в соответствии с TL-схемой, где пользователю будет предложено ввести все поля, необходимые для выбранного метода, и желаемое количество криптовалюты (например, монет TON) которые должны быть прикрепленным к этому запросу. Отправка этой формы создаст новую транзакцию блокчейна, содержащую только что составленное сообщение, отправленное из учетной записи блокчейна пользователя.
Таким образом, пользователь сможет взаимодействовать с произвольными смарт- контрактами из клиентского приложения кошелька удобным для пользователя способом, заполняя и отправляя определенные формы, при условии, что эти смарт- контракты опубликовали свои интерфейсы.
4.3.16. Пользовательский интерфейс «TON-сервиса». «TON-сервисы» (т. е. cервисы, находящиеся в сети TON и принимающие запросы через протоколы ADNL и RLDP из 3; см. 4.1.5) также могут получить прибыль от наличия общедоступных
34
TL-схемы сами могут быть TL-сериализированы; см. https://core.telegram.org/mtproto/TL-tl
82 4.3. Доступ к сервисам TON интерфейсов, описываемых TL- схемами (см. 2.2.5). Клиентское приложение, такое как легкий кошелек или «тонкий браузер», может предлагать пользователю выбрать один из методов и заполнить форму с параметрами, определенными интерфейсом, аналогично той схеме, которая только что обсуждалась в 4.3. 15. Единственное отличие состоит в том, что результирующее TL-сериализированное сообщение не отправляется как транзакция в блокчейне; вместо этого оно отправляется как запрос
RPC на абстрактный адрес рассматриваемого «TON-сервиса», и ответ на этот запрос анализируется и отображается в соответствии с формальным интерфейсом (т. е. TL- схемой).
4.3.17. Поиск пользовательских интерфейсов через TON DNS. Запись TON DNS, содержащая абстрактный адрес TON-сервиса или идентификатор учетной записи смарт-контракта, также может содержать необязательное поле, описывающее общедоступный (пользовательский) интерфейс этого объекта или несколько поддерживаемых интерфейсов. Затем клиентское приложение (будь то кошелек,
TON-браузер или TON-прокси) сможет загружать интерфейс и взаимодействовать с рассматриваемым объектом (будь то смарт-контракт или TON-сервис).
4.3.18. Стирание различий между ончейн и оффчейн сервисами. Таким образом, различие между ончейн, оффчейн и смешанными сервисами (см. 4.1.2) стирается для конечного пользователя: он просто вводит доменное имя необходимого сервиса в адресную строку своего TON-браузера или кошелек, а остальное легко обрабатывается клиентским приложением.
4.3.19. «TON-сайты» как TON-сервисы, поддерживающие HTTP-интерфейс.
TON-сайт - это просто TON-сервис, который поддерживает интерфейс HTTP, возможно, вместе с некоторыми другими интерфейсами. Об этой поддержке можно объявить в соответствующей записи TON DNS.
4.3.20. Гиперссылки. Обратите внимание, что HTML-страницы, возвращаемые TON- сайтами, могут содержать TON-гиперссылки (то есть ссылки на другие TON-сайты, смарт-контракты и учетные записи посредством специально созданных схем URI (см.
4.3.21)), содержащие абстрактные сетевые адреса, идентификаторы учетных записей или человекочитаемые домены TON DNS. Затем «TON-браузер» может следовать по такой гиперссылке, когда пользователь выбирает ее, обнаруживать интерфейс, который будет использоваться, и отображать форму пользовательского интерфейса, как описано в 4.3.15 и 4.3.16.
4.3.21. URL-адреса гиперссылок могут указывать некоторые параметры. URL- адреса гиперссылок могут содержать не только DNS-домен (TON) или абстрактный адрес рассматриваемого сервиса, но также имя вызываемого метода и некоторые или все его параметры. Возможная схема URI для этого может выглядеть следующим образом:
Когда пользователь выбирает такую ссылку в TON-браузере, то действие либо выполняется немедленно (особенно если это метод получения смарт-контракта, вызываемый анонимно), либо отображается частично заполненная форма, которая должна быть явно подтверждена и отправлена пользователем (это может потребоваться для форм оплаты).
4.3.22. POST-действия. TON-сайт может встраиваться в HTML-страницы, он возвращает некоторые обычные POST-формы, при этом POST-действия ссылаются на