Мы подробно обсудили технологии блокчейна TON и TON Networking. Далее будут описаны некоторые способы, при помощи которых эти технологии могут быть объединены для создания широкого спектра услуг и приложений, а также некоторые из сервисов.
Стратегии внедрения сервисов TON
Мы начнем с обсуждения того, как различные приложения и сервисы, связанные с блокчейном и сетью, могут быть реализованы внутри экосистемы TON. Прежде всего, следует привести простую классификацию:
Приложения и сервисы
Мы будем использовать слова «приложение» и «сервисы» в качестве синонимов. Однако есть небольшое и несколько расплывчатое различие: приложение обычно предоставляет некоторые услуги напрямую пользователям-людям, в то время как сервис обычно используется другими приложениями и сервисами. Например, TON Storage — это сервис, потому что она предназначена для хранения информации от имени других приложений и сервисов, даже если пользователь-человек также может использовать ее напрямую. Гипотетический «Facebook в блокчейне», если он будет доступен через сеть TON (т. е. реализован как «сервис TON»), скорее будет приложением, даже если некоторые «боты» могут получить к нему доступ автоматически без вмешательства человека.
Расположение приложения: ончейн, оффчейн или смешанный тип
Сервис или приложение, разработанное для экосистемы TON, должно где-то хранить свои данные и обрабатывать их. В результате получается следующая классификация приложений (и сервисов):
• Сетевые приложения: все данные и обработка находятся в блокчейне TON.
• Оффчейн-приложения: все данные и обработка находятся за пределами блокчейна TON, на серверах, доступных через сеть TON.
• Смешанные приложения: некоторые (но не все) данные и обработка находятся в блокчейне TON; остальные находятся на оффчейн-серверах, доступных через сеть TON.
Централизация: централизованные и децентрализованные или распределенные приложения
Другой критерий классификации заключается в том, полагается ли приложение (или сервис) на централизованный кластер серверов или оно действительно является «распределенным». Все сетевые приложения автоматически являются децентрализованными и распределенными. Оффчейн и смешанные приложения могут иметь разную степень централизации.
Теперь рассмотрим вышеупомянутые возможности более подробно.
Чистые «ончейн» приложения: распределенные приложения или «децентрализованные приложения», находящиеся в блокчейне
Одним из возможных подходов, является развертывание «распределенного приложения» (сокращенно «dapp») полностью в блокчейне TON в виде одного смарт-контракта или набора смарт-контрактов. Все данные будут храниться как часть постоянного состояния этих смарт-контрактов, а все взаимодействие с проектом будет осуществляться с помощью сообщений (блокчейна TON), отправленных на эти смарт-контракты или полученных от них.
Мы уже обсуждали, что этот подход имеет свои недостатки и ограничения. У него также есть свои преимущества: такому распределенному приложению не нужны серверы для работы или хранения данных (оно работает «в блокчейне», то есть на оборудовании валидаторов), и обладает чрезвычайно высокой (основанной на протоколе византийского соглашения) надежностью и доступностью блокчейна. Разработчику такого распределенного приложения не нужно покупать или арендовать какое-либо оборудование. Все, что необходимо сделать, это разработать какое-то программное обеспечение (например, код для смарт-контрактов). После этого разработчик фактически арендует вычислительную мощность у валидаторов и платит за нее TON монетами сам, либо переложив это бремя на плечи своих пользователей.
Чисто сетевые услуги: «TON-сайты» и «TON-сервисы»
Другой крайний вариант — развернуть службу на некоторых серверах и сделать ее доступной для пользователей через протокол ADNL, и, возможно, какой-либо протокол более высокого уровня (например протокол RLDP), который можно использовать для отправки запросов RPC на сервис в любом настраиваемом формате и получить ответы на эти запросы. Таким образом, сервис будет полностью отключен от сети и будет находиться в сети TON почти без использования блокчейна TON.
Блокчейн TON может использоваться только для определения местоположения абстрактного адреса или адресов службы, например, с помощью службы вроде TON DNS, для облегчения перевода понятных человеку доменных имен в абстрактные адреса.
В той степени, в которой сеть ADNL (то есть сеть TON) похожа на проект Invisible Internet Project (I2P), такие (почти) чисто сетевые услуги аналогичны так называемым «eep-сервисам» (т. е. сервисам, которые имеют 2P-адрес в качестве точки входа и доступен клиентам через сеть 12P). Можно сказать, что такие чисто сетевые сервисы, реализуемые в сети TON, являются «TON-сервисами».
«Eep-сервис» может реализовать HTTP в качестве своего клиент-серверного протокола. В контексте сети TON «TON-сервис» может просто использовать датаграммы RLDP для передачи HTTP-запросов и ответов на них. Если он использует TON DNS, чтобы разрешить поиск своего абстрактного адреса по удобочитаемому доменному имени, можно провести почту точную аналогию с веб-сайтом. Можно даже написать специализированный браузер или специальный прокси-сервер («ton-proxy»), который запускается локально на машине пользователя и принимает произвольные HTTP-запросы от обычного веб-браузера, который использует пользователь (как только локальный IP-адрес и TCP-порт прокси-сервера вводятся в конфигурацию браузера), и пересылает эти запросы через сеть TON на абстрактный адрес службы. Тогда пользователь сможет просматривать страницы аналогично работе во всемирной паутине (WWW).
В экосистеме 12P такие «eep-сервисы» называются «eep-сайтами». В экосистеме TON можно легко создавать «TON-сайты». Этому отчасти способствует существование таких служб, как TON DNS, которые используют блокчейн TON и TON DHT для преобразования доменных имен (TON) в абстрактные адреса.
Смешанные сервисы: частично оффчейн, частично ончейн сервисы
Некоторые сервисы могут использовать смешанный подход: выполнять большую часть обработки вне сети, но также иметь некоторую часть в блокчейне (например, для регистрации своих обязательств перед пользователями и наоборот). Таким образом, часть состояния по-прежнему будет храниться в блокчейне TON (то есть в неизменяемом публичном реестре), а любое неправильное поведение сервиса или его пользователей может быть наказано при помощи смарт-контрактов.
хранение файлов вне сети; TON Storage
Примером такого сервиса является TON Storage. В своей простейшей форме он позволяет пользователям хранить информацию вне сети, сохраняя в блокчейне только хэш информации, которая будет храниться, и, возможно, смарт-контракт, в котором некоторые другие стороны соглашаются хранить данную информацию в течение определенного периода времени за заранее оговоренную плату. Фактически, он может быть разделен на фрагменты небольшого размера (например, 1 килобайт), дополнен стирающим кодом (например, кодом Рида-Соломона или исходным кодом), после чего может быть построен хэш дерева Меркла для расширенной последовательности фрагментов, который может быть опубликован в смарт-контракте вместо обычного хеша файла или вместе с ним. Это чем-то напоминает способ хранения файлов в виде торрент-файлов.
Еще более простая форма хранения файлов — полностью вне сети: можно по существу создать «торрент» для нового файла и использовать TON DHT в качестве «распределенного торрент-трекера» для этого торрента. Такая модель может действительно хорошо сработать для популярных файлов. Однако не дается никаких гарантий доступности. Например, для гипотетического сервиса «Facebook в блокчейне», который будет хранить фотографии своих пользователей полностью вне сети в таких «торрентах», существует риск потери фотографий обычных (не особенно популярных) пользователей, либо риск отсутствия возможности предоставлять эти фотографии в течение длительного времени. Технология TON Storage, которая в основном является автономной, но использует ончейн смарт-контракт для обеспечения доступности хранимых данных, может быть наилучшим решением для этой задачи.
Децентрализованные смешанные услуги или «сервисы туманных вычислений»
До сих пор мы обсуждали централизованные смешанные сервисы и приложения. В то время как их сетевой компонент в блокчейне обрабатывается децентрализованным и распределенным образом, соответствующий автономный компонент полагается на некоторые серверы, контролируемые поставщиком услуг обычным централизованным образом. Вместо использования некоторых выделенных серверов вычислительные мощности могут быть арендованы у службы облачных вычислений, предлагаемой одной из крупных компаний. Однако это не приведет к децентрализации автономного компонента сервиса.
Децентрализованный подход к реализации оффчейн компонента сервиса заключается в создании рынка, на котором пользователи с необходимым оборудованием, которые готовы сдать в аренду свои вычислительные мощности или дисковое пространство, будут предлагать свои услуги тем, кто в них нуждается.
Например, может существовать реестр (который также может называться «рынком» или «биржей»), в котором все узлы, заинтересованные в сохранении информации о других пользователях, будут публиковать свои контактные данные, а также информацию о доступной емкости хранилища, политике доступности и ценах. Пользователи, которым нужны эти услуги, могут найти поставщиков в этом реестре, и если другая сторона согласится, создать смарт-контракты в блокчейне и загрузить файлы для хранения вне сети. Таким образом, такой сервис, как TON Storage, становится действительно децентрализованным, поскольку ему не нужно полагаться на какой-либо централизованный кластер серверов для хранения информации.
платформы «туманных вычислений» как децентрализованные смешанные сервисы
Еще один пример такого децентрализованного смешанного приложения возникает, когда кто-то хочет выполнить некоторые конкретные вычисления (например, 3D-рендеринг или обучение нейронных сетей), что зачастую требует специального и дорогостоящего оборудования. Пользователи, у которых имеется такое оборудование, могут предлагать свои услуги через аналогичный «обмен», а те, кто нуждается в таких услугах, будут их арендовать, причем обязательства сторон будут регистрироваться с помощью смарт-контрактов. Эта модель похожа на то, что обещают предоставить платформы «туманных вычислений», такие как Golem (https://golem.network/) или SONM (https://sonm.io/).
TON Proxy как сервис «туманных вычислений»
Сервис TON Proxy является еще одним примером сервиса «туманных вычислений». В нем могут регистрироваться нем узлы, предлагающие свои услуги (с компенсацией или без нее) в качестве туннелей для сетевого трафика ADNL, а пользователи, которые нуждаются в таких услугах, могут выбрать один из этих узлов в зависимости от цены, задержки сигнала и предлагаемой ширины канала. После этого можно использовать платежные каналы, предоставляемые TON Payments, для обработки микроплатежей за услуги этих прокси-серверов, при этом платежи собираются, например, за каждые 128 KiB переведенных данных.
TON Payments как сервис «туманных вычислений»
Платформа TON Payments (см. 5) также является примером такого децентрализованного смешанного приложения.
Подключение пользователей и поставщиков услуг
Мы увидели, что «сервисы туманных вычислений» (т. е. смешанные децентрализованные сервисы) обычно нуждаются в рынках, биржах или реестрах, где происходит взаимодействие пользователей, которым необходимы определенные услуги, с пользователями, которые эти услуги предоставляют.
Вероятно, такие рынки будут реализованы как внутрисетевые, автономные или смешанные сервисы, централизованные или распределенные.
подключение к TON Payments
Например, если кто-то хочет использовать сервис TON Payments (см. 5), первым шагом будет поиск по как минимум нескольких существующих транзитных узлов «сети мгновенных платежей» и установление с ними каналов оплаты в случае готовности этих узлов. Некоторые узлы могут быть найдены с помощью «охватывающей» оверлейной сети, которая должна содержать все узлы транзитной сети мгновенных платежей. Однако неясно, будут ли эти узлы готовы создавать новые платежные каналы.
Следовательно, необходим реестр, в котором узлы, готовые к созданию новых ссылок, могут публиковать свою контактную информацию (например, свои абстрактные адреса).
загрузка файла в TON Storage
Точно так же, если кто-то хочет загрузить файл в хранилище TON, он должен найти несколько узлов, желающих подписать смарт-контракт, обязывающий их хранить копию этого файла (или любого другого файла ниже определенного предела размера). Следовательно, необходим реестр узлов, предлагающих свои услуги по хранению информации.
Сетевые, смешанные и автономные реестры
Такой реестр поставщиков услуг может быть реализован полностью ончейн с помощью смарт-контракта, который будет хранить реестр в постоянном хранилище. Однако это довольно медленно и дорого. Смешанный подход более эффективен, когда относительно небольшой и редко изменяемый ончейн реестр используется только для указания некоторых узлов (по их абстрактным адресам или по их открытым ключам, которые могут использоваться для определения фактических абстрактных адресов), которые предоставляют услуги реестра вне сети (централизованные).
Наконец, при децентрализованном, чисто автономном подходе может использоваться общедоступная оверлейная сеть, в которой пользователи, которые хотят предложить свои услуги, или пользователи, которые хотят купить чьи-то услуги, просто транслируют свои предложения, подписанные закрытыми ключами. Если предоставляемая услуга очень проста, даже широковещательная передача предложений может не потребоваться: примерное членство в самой оверлейной сети может использоваться в качестве «реестра» тех, кто желает предоставить конкретную услугу. Клиент, которому требуется эта услуга, может найти и запросить некоторые узлы этой оверлейной сети, а затем запросить их соседей, если уже известные узлы не готовы предоставить необходимую услугу.
Регистрация или обмен в сайдчейне
Другой подход к реализации децентрализованных смешанных реестров заключается в создании независимого специализированного блокчейна («сайдчейна»), поддерживаемого собственным набором самопровозглашенных валидаторов, которые публикуют свои идентификаторы в ончейн смарт-контракте и предоставляют всем заинтересованным сторонам доступ в этот специализированный блокчейн, собирая транзакции-кандидаты и транслируя обновления блоков через выделенные оверлейные сети. Затем любая полная нода для этого сайдчейна может поддерживать свою собственную копию общего реестра (по существу, равную глобальному состоянию этого сайдчейна) и обрабатывать произвольные запросы, связанные с этим реестром.
Реестр или обмен в воркчейне
Другой вариант — создать отдельный воркчейн внутри блокчейна TON, специализирующийся на создании реестров, рынков и бирж. Этот способ может быть более эффективным и менее затратным, чем использование смарт-контрактов в основном воркчейне, однако это все равно будет дороже, чем поддержание реестров в сайдчейнах.
Доступ к сервисам TON
В разделе мы обсудили различные подходы, которые можно использовать для создания новых сервисов и приложений в экосистеме TON. Теперь мы обсудим, как можно получить доступ к этим сервисам, а также некоторые из «вспомогательных сервисов», которые будут предоставляться TON, включая TON DNS и TON Storage.
TON DNS: иерархическая служба доменных имен в сети (в основном ончейн)
TON DNS — это предопределенная служба, которая использует набор смарт-контрактов для сохранения карты от понятных человеку доменных имен до (256-битных) адресов сетевых узлов ADNL, учетных записей и смарт-контрактов блокчейна TON.
Хотя в принципе любой может реализовать такой сервис с использованием блокчейна TON, полезно иметь подобный предопределенный сервис с хорошо известным интерфейсом, который будет использоваться по умолчанию всякий раз, когда приложение или сервис захочет преобразовать понятные человеку идентификаторы в адреса.
Примеры использования TON DNS
Например, пользователь, желающий передать некоторую криптовалюту другому пользователю или продавцу, может предпочесть запомнить доменное имя TON DNS учетной записи этого пользователя или продавца, вместо того, чтобы держать свои 256-битные идентификаторы учетных записей под рукой и копировать и вставлять их в поля информации о получателе, хранящейся в легком кошельке клиента.
Аналогичным образом, TON DNS может использоваться для определения идентификаторов учетных записей смарт-контрактов или точек входа в TON-сервисы и TON-сайты, включая специализированный клиент («TON-браузер») или обычный интернет-браузер в сочетании со специализированным расширением ton-proxy или автономным приложением, чтобы предоставить пользователю возможность просмотра веб-страниц в стиле WWW.
Смарт-контракты TON DNS
TON DNS реализуется с помощью дерева специальных смарт-контрактов (DNS). Каждый смарт-контракт DNS отвечает за регистрацию поддоменов некоторого фиксированного домена. «Корневой» смарт-контракт DNS, в котором будут храниться домены первого уровня системы TON DNS, находится в мастерчейне. Соответствующий идентификатор учетной записи должен быть жестко запрограммирован во всем программном обеспечении, которое будет напрямую обращаться к базе данных TON DNS.
Любой смарт-контракт DNS содержит хэш-карту, отображающую строки UTF-8 переменной длины с завершающим нулем в их «значениях». Эта хэш-карта реализована в виде двоичного дерева Patricia, подобного дереву, но также поддерживает битовые строки переменной длины в качестве ключей.
Значения хэш-карты DNS или записей TON DNS
Значения представлены в виде «DNS-записей TON», описываемых TL-схемой. Они состоят из «магического числа», выбора одной из поддерживаемых опций, а также одного из следующих идентификаторов: идентификатора учетной записи, идентификатора смарт-контракта, абстрактного сетевого адреса, открытого ключа, используемого для определения местоположения абстрактных адресов сервиса или описания оверлейной сети и т. д. Важным является использование другого смарт-контракта DNS: в таком случае этот смарт-контракт используется для преобразования поддоменов собственного домена. Таким образом, можно создавать отдельные реестры для разных доменов, контролируемые владельцами этих доменов.
Эти записи также могут содержать время истечения срока действия, время кеширования (обычно очень большое, поскольку обновление значений в блокчейне слишком часто обходится дорого) и в большинстве случаев ссылку на владельца рассматриваемого поддомена. Владелец имеет право изменить эту запись (в частности, владелец может передать домен под чей-то контроль) и продлить ее.
Регистрация новых поддоменов существующих доменов
Чтобы зарегистрировать новый поддомен существующего домена, нужно просто отправить сообщение смарт-контракту, который является регистратором этого домена, содержащим поддомен (то есть ключ), который должен быть зарегистрирован, значение в одном из нескольких предопределенных форматов, личность владельца, срок действия и некоторое количество криптовалюты, определяемое владельцем домена.
Поддомены регистрируются по принципу «в порядке очереди».
Получение данных из смарт-контракта DNS
В принципе, любая полная нода мастерчейна или шардчейна, содержащая смарт-контракт DNS, может иметь возможность поиска любого поддомена в базе данных этого смарт-контракта, если известна структура и расположение хэш-карты в постоянном хранилище смарт-контракта.
Однако этот подход будет работать только для определенных смарт-контрактов DNS. В случае использования нестандартного смарт-контракта DNS такой подход будет неуспешным.
Вместо этого используется подход, основанный на общих интерфейсах смарт-контрактов и методах получения. Любой смарт-контракт DNS должен определять «метод получения» с «известной подписью», который вызывается для поиска ключа. Поскольку этот подход имеет смысл и для других смарт-контрактов, особенно для тех, которые обеспечивают сетевые и смешанные сервисы.
Перевод домена TON DNS
Если любой полной ноде, действующей самой по себе или от имени какого-либо тонкого клиента, необходимо найти записи в базе данных любого смарт-контракта DNS, произвольные доменные имена TON DNS могут быть рекурсивно преобразованы, начиная с хорошо известного и фиксированного идентификатора корневого смарт-контракта DNS (учетной записи).
Например, если необходимо перевести А. В. C, следует найти ключи .С, .В.С и А.В.C в базе данных корневого домена. Если первый из них не был найден, а второй был найден, и его значение является ссылкой на другой смарт-контракт DNS, тогда A ищется в базе данных этого смарт-контракта, после чего извлекается окончательное значение.
Перевод доменов TON DNS для неполных нод
Таким образом, полная нода мастерчейна, а также всех шардчейнов, участвующих в процессе поиска домена, может преобразовывать любое доменное имя в его текущее значение без внешней помощи. Неполная нода может запросить полную ноду сделать это от своего имени и вернуть значение вместе с доказательством Меркла. Это доказательство Меркла позволит неполной ноде проверить правильность ответа, поэтому такие ответы TON DNS не могут быть «подделаны» злонамеренным перехватчиком, в отличие от обычного протокола DNS.
Поскольку нельзя ожидать, что нода будет полной нодой по отношению ко всем шардчейнам, фактическая трансляция домена TON DNS будет включать комбинацию этих двух стратегий.
Выделенные «серверы TON DNS»
Можно предоставить простой «сервер TON DNS», который будет получать RPC-запросы «DNS» (например, через протоколы ADNL или RLDP), запрашивая, чтобы сервер переводил данный домен, обрабатывал эти запросы, при необходимости перенаправляя некоторые подзапросы на другие (полные) ноды, и возвращать ответы на исходные запросы, дополненные доказательствами Меркла, если необходимо.
Такие «DNS-серверы» могут предлагать свои услуги (бесплатно или платно) любым другим узлам и особенно легким клиентам, используя один из методов. Обратите внимание, что эти серверы, если их рассматривать как часть службы TON DNS, эффективно преобразовали бы ее из распределенного сервиса в распределенный смешанный сервис (т. е. «сервис туманных вычислений»).
На этом мы завершаем краткий обзор службы TON DNS, масштабируемого сетевого реестра для понятных человеку доменных имен объектов блокчейна TON и сети TON Network.
Доступ к данным, хранящимся в смарт-контрактах
Мы уже увидели, что иногда необходимо получить доступ к данным, хранящимся в смарт-контракте, без изменения его состояния.
Если пользователю известны детали реализации смарт-контракта, можно извлечь всю необходимую информацию из постоянного хранилища смарт-контракта, доступного для всех полных нод шардчейна, в котором находится смарт-контракт. Однако это довольно грубый способ, очень сильно зависящий от реализации смарт-контракта.
«Методы получения» смарт-контрактов
Лучшим способом было бы определить некоторые методы получения в смарт-контракте, то есть некоторые типы входящих сообщений, которые не влияют на состояние смарт-контракта при доставке, но генерируют одно или несколько выходных сообщений, содержащих «результат» метода получения. Таким образом, можно получить данные из смарт-контракта, зная только, что он реализует метод получения с известной подписью (т. е. известный формат входящего сообщения, которое должно быть отправлено, и исходящего сообщения, которое должно быть в результате получено).
Этот способ намного более изящный и соответствует объектно-ориентированному программированию (ООП). Однако у него имеется очевидный дефект: нужно фактически зафиксировать транзакцию в блокчейне (отправить сообщение get в смарт-контракт), дождаться, пока она будет зафиксирована и обработана валидаторами, извлечь ответ из нового блока и внести оплату за газ (то есть за выполнение метода получения на оборудовании валидаторов). Это пустая трата ресурсов: методы получения в любом случае не изменяют состояние смарт-контракта, поэтому их не нужно выполнять в блокчейне.
Предварительное выполнение методов получения смарт-контрактов
Уже отмечали, что любая полная нода может предварительно выполнить любой метод любого смарт-контракта (то есть доставить любое сообщение в смарт-контракт), начиная с заданного состояния смарт-контракта, без фактического совершения соответствующей сделки. Полная нода может просто загрузить код рассматриваемого смарт-контракта в виртуальную машину TON, инициализировать свое постоянное хранилище из глобального состояния шардчейна (известного всем полным нодам шардчейна) и выполнить код смарт-контракта с входящим сообщением в качестве входного параметра. Созданные выходные сообщения будут иметь результат этого вычисления.
Таким образом, любая полная нода может оценивать произвольные методы получения произвольных смарт-контрактов, если известна их подпись (т. е. формат входящих и исходящих сообщений). Нода может отслеживать ячейки состояния шардчейна, к которым осуществляется доступ во время этой оценки, и создавать доказательство Меркла валидности выполненных вычислений в пользу неполной ноды, которая отправила бы соответствующий запрос на полную ноду.
Интерфейсы смарт-контрактов в TL-схемах
Напомним, что методы, реализованные в смарт-контракте (то есть принимаемые им входные сообщения), по сути, являются некоторыми TL-сериализированными объектами, которые могут быть описаны TL-схемой. Полученные выходные сообщения также можно описать той же TL-схемой. Таким образом, интерфейс смарт-контракта с другими учетными записями и смарт-контрактами может быть формализован с помощью TL-схемы.
В частности, (подмножество) методов получения, поддерживаемых смарт-контрактом, можно описать с помощью такого формализованного интерфейса смарт-контракта.
Публичные интерфейсы смарт-контракта
Обратите внимание, что формализованный интерфейс смарт-контракта, в форме TL-схемы (представленной как исходный файл TL), либо в сериализированной форме, может быть опубликован, например, в специальной форме, хранящейся в описании учетной записи смарт-контракта, хранящемся в блокчейне или отдельно, если к этому интерфейсу будут часто обращаться. В последнем случае хэш поддерживаемого общедоступного интерфейса может быть включен в описание смарт-контракта вместо самого описания интерфейса.
Примером такого общедоступного интерфейса является смарт-контракт DNS, который должен реализовывать как минимум один стандартный метод получения для поиска поддоменов. Стандартный метод регистрации новых поддоменов также может быть включен в стандартный общедоступный интерфейс смарт-контрактов DNS.
Пользовательский интерфейс смарт-контракта
Существование публичного интерфейса для смарт-контракта имеет и другие преимущества. Например, клиентское приложение кошелька может загружать такой интерфейс при изучении смарт-контракта по запросу пользователя и отображать список общедоступных методов (то есть доступных действий), поддерживаемых смарт-контрактом, возможно, с некоторыми удобочитаемыми комментариями, если таковые имеются, в формальном интерфейсе. После того, как пользователь выберет один из этих методов, форма может быть автоматически сгенерирована в соответствии с TL-схемой, где пользователю будет предложено ввести все поля, необходимые для выбранного метода, и желаемое количество криптовалюты (например, монет TON) которые должны быть прикрепленным к этому запросу. Отправка этой формы создаст новую транзакцию блокчейна, содержащую только что составленное сообщение, отправленное из учетной записи блокчейна пользователя.
Таким образом, пользователь сможет взаимодействовать с произвольными смарт-контрактами из клиентского приложения кошелька удобным для пользователя способом, заполняя и отправляя определенные формы, при условии, что эти смарт-контракты опубликовали свои интерфейсы.
Пользовательский интерфейс «TON-сервиса»
«TON-сервисы» (т. е. cервисы, находящиеся в сети TON и принимающие запросы через протоколы ADNL и RLDP из 3; см. 4.1.5) также могут получить прибыль от наличия общедоступных 34 TL-схемы сами могут быть TL-сериализированы; см. https://core.telegram.org/mtproto/TL-tl
Клиентское приложение, такое как легкий кошелек или «тонкий браузер», может предлагать пользователю выбрать один из методов и заполнить форму с параметрами, определенными интерфейсом, аналогично той схеме. Единственное отличие состоит в том, что результирующее TL-сериализированное сообщение не отправляется как транзакция в блокчейне; вместо этого оно отправляется как запрос RPC на абстрактный адрес рассматриваемого «TON-сервиса», и ответ на этот запрос анализируется и отображается в соответствии с формальным интерфейсом (т. е. TL-схемой).
Поиск пользовательских интерфейсов через TON DNS
Запись TON DNS, содержащая абстрактный адрес TON-сервиса или идентификатор учетной записи смарт-контракта, также может содержать необязательное поле, описывающее общедоступный (пользовательский) интерфейс этого объекта или несколько поддерживаемых интерфейсов. Затем клиентское приложение (будь то кошелек, TON-браузер или TON-прокси) сможет загружать интерфейс и взаимодействовать с рассматриваемым объектом (будь то смарт-контракт или TON-сервис).
Стирание различий между ончейн и оффчейн сервисами
Таким образом, различие между ончейн, оффчейн и смешанными сервисами стирается для конечного пользователя: он просто вводит доменное имя необходимого сервиса в адресную строку своего TON-браузера или кошелек, а остальное легко обрабатывается клиентским приложением.
«TON-сайты» как TON-сервисы, поддерживающие HTTP-интерфейс
TON-сайт — это просто TON-сервис, который поддерживает интерфейс HTTP, возможно, вместе с некоторыми другими интерфейсами. Об этой поддержке можно объявить в соответствующей записи TON DNS.
Гиперссылки
Обратите внимание, что HTML-страницы, возвращаемые TON-сайтами, могут содержать TON-гиперссылки (то есть ссылки на другие TON-сайты, смарт-контракты и учетные записи посредством специально созданных схем URI), содержащие абстрактные сетевые адреса, идентификаторы учетных записей или человекочитаемые домены TON DNS. Затем «TON-браузер» может следовать по такой гиперссылке, когда пользователь выбирает ее, обнаруживать интерфейс, который будет использоваться, и отображать форму пользовательского интерфейса.
URL-адреса гиперссылок могут указывать некоторые параметры
URL-адреса гиперссылок могут содержать не только DNS-домен (TON) или абстрактный адрес рассматриваемого сервиса, но также имя вызываемого метода и некоторые или все его параметры. Возможная схема URI для этого может выглядеть следующим образом:
Когда пользователь выбирает такую ссылку в TON-браузере, то действие либо выполняется немедленно (особенно если это метод получения смарт-контракта, вызываемый анонимно), либо отображается частично заполненная форма, которая должна быть явно подтверждена и отправлена пользователем (это может потребоваться для форм оплаты).
POST-действия
TON-сайт может встраиваться в HTML-страницы, он возвращает некоторые обычные POST-формы, при этом POST-действия ссылаются на TON-сайты, TON-сервисы или смарт-контракты с помощью подходящих (TON) URL-адресов. В этом случае, как только пользователь заполняет и отправляет эту настраиваемую форму, соответствующее действие предпринимается либо сразу, либо после явного подтверждения.
Сеть TON WWW
Все вышеперечисленное приведет к созданию целой сети объектов с перекрестными ссылками, находящихся в сети TON, которые будут доступны конечному пользователю через тонкий браузер, предоставляя пользователю возможность просмотра веб-страниц в стиле WWW. Для конечных пользователей это, наконец, сделает приложения блокчейна принципиально похожими на веб-сайты, к которым они уже привыкли.
Преимущества TON WWW
Этот «TON WWW» сетевых и автономных сервисов имеет некоторые преимущества перед своим традиционным аналогом. Например, платежи по своей сути интегрированы в систему. Идентификационные данные пользователя всегда могут быть предоставлены сервисам (посредством автоматически сгенерированных подписей на транзакциях и сгенерированных запросов RPC) или скрыты по желанию. Сервисам не нужно будет перепроверять учетные данные пользователя; эти учетные данные могут быть опубликованы в блокчейне раз и навсегда. Анонимность пользователей в сети может быть легко сохранена с помощью TON Proxy, а все сервисы будут всегда доступными. Также будут доступными микроплатежи, потому что TON-браузеры могут быть интегрированы с системой TON Payments.
