Файл: Аннотация Цель данной работы предоставить первое описание блокчейнплатформы ton (The Open Network) и связанных с ней технологий одноранговых сетей, распределенного хранилища и хостинга..pdf
Добавлен: 25.10.2023
Просмотров: 279
Скачиваний: 3
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
3.3.16. Построение новых оверлейных сетей на основе существующих сетей.
Иногда строить оверлейную сеть с нуля нет смысла. Вместо этого известна одна или несколько ранее существовавших оверлейных сетей, и ожидается, что членство в новой оверлейной сети будет значительно перекрываться с объединенным членством этих оверлейных сетей.
Важный пример – разделение шардчейна TON на два шардчейна, либо объединение двух родственных шардчейнов в один (см. 2.7). В первом случае оверлейные сети, используемые для распространения новых блоков на полные ноды, должны быть построены для каждого нового шардчейна. Однако можно ожидать, что каждая из этих новых оверлейных сетей будет содержаться в сети распространения блоков исходного шардчейна (и включать примерно половину ее членов). Во втором случае оверлейная сеть для распространения новых блоков объединенного шардчейна будет состоять примерно из объединения членов двух оверлейных сетей, связанных с двумя объединяемыми родственными шардчейнами.
В таких случаях описание новой оверлейной сети может содержать явную или неявную ссылку на список связанных существующих оверлейных сетей. Узел, желающий присоединиться к новой оверлейной сети, может проверить, является ли он уже членом одной из этих существующих сетей, и запросить своих соседей в этих сетях, заинтересованы ли они также в новой сети. В случае положительного ответа для таких соседей могут быть установлены новые двухточечные каналы, и они могут быть включены в список соседей для новой оверлейной сети.
73 3.3. Оверлейные сети и многоадресные сообщения
Этот механизм не заменяет полностью общий механизм, описанный в 3.3.6 и 3.3.7; скорее, оба механизма выполняются параллельно и используются для заполнения списка соседей. Это необходимо для предотвращения случайного разделения новой оверлейной сети на несколько несвязанных подсетей.
3.3.17. Оверлейные сети внутри оверлейных сетей. Другой интересный случай возникает при реализации сервиса TON Payments («сеть моментальных платежей» для мгновенных переводов стоимости вне сети; см. 5.2). В этом случае сначала строится оверлейная сеть, содержащая все транзитные узлы «сети моментальных платежей».
Однако некоторые из этих узлов имеют платежные каналы в блокчейне; они всегда должны быть соседями в этой оверлейной сети, в дополнение к любым «случайным» соседям, выбранным общими алгоритмами оверлейной сети, описанными в 3.3.6, 3.3.7 и 3.3.8, эти «постоянные соединения» с соседями с установленными платежными каналами используются для запуска определенных сетевых протоколов Lightning.
Таким образом, обеспечивается эффективное создание оверлейной подсети (не обязательно подключенной, если что-то пойдет не так) внутри охватывающей (почти всегда подключенной) оверлейной сети.
4
Сервисы и приложения TON
Мы подробно обсудили технологии блокчейна TON и TON Networking. Далее будут описаны некоторые способы, при помощи которых эти технологии могут быть объединены для создания широкого спектра услуг и приложений, а также некоторые из сервисов, которые будут предоставляться самим проектом TON с самого начала, либо позже.
4.1. Стратегии внедрения сервисов TON
Мы начнем с обсуждения того, как различные приложения и сервисы, связанные с блокчейном и сетью, могут быть реализованы внутри экосистемы TON. Прежде всего, следует привести простую классификацию:
4.1.1. Приложения и сервисы. Мы будем использовать слова «приложение» и
«сервисы» в качестве синонимов. Однако есть небольшое и несколько расплывчатое различие: приложение обычно предоставляет некоторые услуги напрямую пользователям-людям, в то время как сервис обычно используется другими приложениями и сервисами. Например, TON Storage - это сервис, потому что она предназначена для хранения информации от имени других приложений и сервисов, даже если пользователь-человек также может использовать ее напрямую.
Гипотетический «Facebook в блокчейне» (см. 2.9.13), если он будет доступен через сеть TON (т. е. реализован как «сервис TON»), скорее будет приложением, даже если некоторые «боты» могут получить к нему доступ автоматически без вмешательства человека.
4.1.2. Расположение приложения: ончейн, оффчейн или смешанный тип. Сервис или приложение, разработанное для экосистемы TON, должно где-то хранить свои данные и обрабатывать их. В результате получается следующая классификация приложений (и сервисов):
• Сетевые приложения (см. 4.1.4): все данные и обработка находятся в блокчейне
TON.
• Оффчейн-приложения (см. 4.1.5): все данные и обработка находятся за пределами блокчейна TON, на серверах, доступных через сеть TON.
74 4.1. Стратегии внедрения сервисов TON
• Смешанные приложения (см. 4.1.6): некоторые (но не все) данные и обработка находятся в блокчейне TON; остальные находятся на оффчейн-серверах, доступных через сеть TON.
4.1.3. Централизация: централизованные и децентрализованные или
распределенные приложения. Другой критерий классификации заключается в том, полагается ли приложение (или сервис) на централизованный кластер серверов или оно действительно является «распределенным» (см. 4.1.8). Все сетевые приложения автоматически являются децентрализованными и распределенными. Оффчейн и смешанные приложения могут иметь разную степень централизации.
Теперь рассмотрим вышеупомянутые возможности более подробно.
4.1.4. Чистые «ончейн» приложения: распределенные приложения или
«децентрализованные приложения», находящиеся в блокчейне. Одним из возможных подходов, упомянутых в 4.1.2, является развертывание «распределенного приложения» (сокращенно «dapp») полностью в блокчейне TON в виде одного смарт- контракта или набора смарт-контрактов. Все данные будут храниться как часть постоянного состояния этих смарт-контрактов, а все взаимодействие с проектом будет осуществляться с помощью сообщений (блокчейна TON), отправленных на эти смарт- контракты или полученных от них.
Мы уже обсуждали в 2.9.13, что этот подход имеет свои недостатки и ограничения. У него также есть свои преимущества: такому распределенному приложению не нужны серверы для работы или хранения данных (оно работает «в блокчейне», то есть на оборудовании валидаторов), и обладает чрезвычайно высокой (основанной на протоколе византийского соглашения) надежностью и доступностью блокчейна.
Разработчику такого распределенного приложения не нужно покупать или арендовать какое-либо оборудование. Все, что необходимо сделать, это разработать какое-то программное обеспечение (например, код для смарт-контрактов). После этого разработчик фактически арендует вычислительную мощность у валидаторов и платит за нее TON монетами сам, либо переложив это бремя на плечи своих пользователей.
4.1.5. Чисто сетевые услуги: «TON-сайты» и «TON-сервисы». Другой крайний вариант - развернуть службу на некоторых серверах и сделать ее доступной для пользователей через протокол ADNL, описанный в п. 3.1, и, возможно, какой-либо протокол более высокого уровня (например, описанный в п. 3.1.9 протокол RLDP), который можно использовать для отправки запросов RPC на сервис в любом настраиваемом формате и получить ответы на эти запросы. Таким образом, сервис будет полностью отключен от сети и будет находиться в сети TON почти без использования блокчейна TON.
Блокчейн TON может использоваться только для определения местоположения абстрактного адреса или адресов службы, как указано в 3.2.12, например, с помощью службы вроде TON DNS (см. 4.3.1), для облегчения перевода понятных человеку доменных имен в абстрактные адреса.
В той степени, в которой сеть ADNL (то есть сеть TON) похожа на проект Invisible
Internet Project (I
2
P), такие (почти) чисто сетевые услуги аналогичны так называемым
«eep-сервисам» (т. е. сервисам, которые имеют 1 2
P-адрес в качестве точки входа и доступен клиентам через сеть 1 2
P). Можно сказать, что такие чисто сетевые сервисы, реализуемые в сети TON, являются «TON-сервисами».
«Eep-сервис» может реализовать HTTP в качестве своего клиент-серверного протокола. В контексте сети TON «TON-сервис» может просто использовать датаграммы RLDP (см. 3.1.9) для передачи HTTP-запросов и ответов на них. Если он использует TON DNS, чтобы разрешить поиск своего абстрактного адреса по удобочитаемому доменному имени, можно провести почту точную аналогию с веб-
75 4.1. Стратегии внедрения сервисов TON сайтом. Можно даже написать специализированный браузер или специальный прокси-сервер («ton-proxy»), который запускается локально на машине пользователя и принимает произвольные HTTP-запросы от обычного веб-браузера, который использует пользователь (как только локальный IP-адрес и TCP-порт прокси-сервера вводятся в конфигурацию браузера), и пересылает эти запросы через сеть TON на абстрактный адрес службы. Тогда пользователь сможет просматривать страницы аналогично работе во всемирной паутине (WWW).
В экосистеме 1 2
P такие «eep-сервисы» называются «eep-сайтами». В экосистеме TON можно легко создавать «TON-сайты». Этому отчасти способствует существование таких служб, как TON DNS, которые используют блокчейн TON и TON DHT для преобразования доменных имен (TON) в абстрактные адреса.’
4.1.6. Смешанные сервисы: частично оффчейн, частично ончейн сервисы.
Некоторые сервисы могут использовать смешанный подход: выполнять большую часть обработки вне сети, но также иметь некоторую часть в блокчейне (например, для регистрации своих обязательств перед пользователями и наоборот). Таким образом, часть состояния по-прежнему будет храниться в блокчейне TON (то есть в неизменяемом публичном реестре), а любое неправильное поведение сервиса или его пользователей может быть наказано при помощи смарт-контрактов.
4.1.7. Пример: хранение файлов вне сети; TON Storage. Примером такого сервиса является TON Storage. В своей простейшей форме он позволяет пользователям хранить информацию вне сети, сохраняя в блокчейне только хэш информации, которая будет храниться, и, возможно, смарт-контракт, в котором некоторые другие стороны соглашаются хранить данную информацию в течение определенного периода времени за заранее оговоренную плату. Фактически, он может быть разделен на фрагменты небольшого размера (например, 1 килобайт), дополнен стирающим кодом
(например, кодом Рида-Соломона или исходным кодом), после чего может быть построен хэш дерева Меркла для расширенной последовательности фрагментов, который может быть опубликован в смарт-контракте вместо обычного хеша файла или вместе с ним. Это чем-то напоминает способ хранения файлов в виде торрент- файлов.
Еще более простая форма хранения файлов - полностью вне сети: можно по существу создать «торрент» для нового файла и использовать TON DHT в качестве
«распределенного торрент-трекера» для этого торрента (см. 3.2.10). Такая модель может действительно хорошо сработать для популярных файлов. Однако не дается никаких гарантий доступности. Например, для гипотетического сервиса «Facebook в блокчейне» (см. 2.9.13), который будет хранить фотографии своих пользователей полностью вне сети в таких «торрентах», существует риск потери фотографий обычных (не особенно популярных) пользователей, либо риск отсутствия возможности предоставлять эти фотографии в течение длительного времени.
Технология TON Storage, которая в основном является автономной, но использует ончейн смарт-контракт для обеспечения доступности хранимых данных, может быть наилучшим решением для этой задачи.
4.1.8. Децентрализованные смешанные услуги или «сервисы туманных
вычислений». До сих пор мы обсуждали централизованные смешанные сервисы и приложения. В то время как их сетевой компонент в блокчейне обрабатывается децентрализованным и распределенным образом, соответствующий автономный компонент полагается на некоторые серверы, контролируемые поставщиком услуг обычным централизованным образом. Вместо использования некоторых выделенных серверов вычислительные мощности могут быть арендованы у службы облачных
76 4.1. Стратегии внедрения сервисов TON вычислений, предлагаемой одной из крупных компаний. Однако это не приведет к децентрализации автономного компонента сервиса.
Децентрализованный подход к реализации оффчейн компонента сервиса заключается в создании рынка, на котором пользователи с необходимым оборудованием, которые готовы сдать в аренду свои вычислительные мощности или дисковое пространство, будут предлагать свои услуги тем, кто в них нуждается.
Например, может существовать реестр (который также может называться «рынком» или «биржей»), в котором все узлы, заинтересованные в сохранении информации о других пользователях, будут публиковать свои контактные данные, а также информацию о доступной емкости хранилища, политике доступности и ценах.
Пользователи, которым нужны эти услуги, могут найти поставщиков в этом реестре, и если другая сторона согласится, создать смарт-контракты в блокчейне и загрузить файлы для хранения вне сети. Таким образом, такой сервис, как TON Storage, становится действительно децентрализованным, поскольку ему не нужно полагаться на какой-либо централизованный кластер серверов для хранения информации.
4.1.9. Пример: платформы «туманных вычислений» как децентрализованные
смешанные сервисы.
Еще один пример такого децентрализованного смешанного приложения возникает, когда кто-то хочет выполнить некоторые конкретные вычисления (например, 3D- рендеринг или обучение нейронных сетей), что зачастую требует специального и дорогостоящего оборудования. Пользователи, у которых имеется такое оборудование, могут предлагать свои услуги через аналогичный «обмен», а те, кто нуждается в таких услугах, будут их арендовать, причем обязательства сторон будут регистрироваться с помощью смарт-контрактов. Эта модель похожа на то, что обещают предоставить платформы «туманных вычислений», такие как Golem (https://golem.network/) или
SONM (
https://sonm.io/
).
4.1.10. Пример: TON Proxy как сервис «туманных вычислений». Сервис TON
Proxy является еще одним примером сервиса «туманных вычислений». В нем могут регистрироваться нем узлы, предлагающие свои услуги (с компенсацией или без нее) в качестве туннелей для сетевого трафика ADNL, а пользователи, которые нуждаются в таких услугах, могут выбрать один из этих узлов в зависимости от цены, задержки сигнала и предлагаемой ширины канала. После этого можно использовать платежные каналы, предоставляемые TON Payments, для обработки микроплатежей за услуги этих прокси-серверов, при этом платежи собираются, например, за каждые 128 KiB переведенных данных.
4.1.11. Пример: TON Payments как сервис «туманных вычислений». Платформа
TON Payments (см. 5) также является примером такого децентрализованного смешанного приложения.
4.2. Подключение пользователей и поставщиков услуг
Мы увидели в 4.1.8, что «сервисы туманных вычислений» (т. е. смешанные децентрализованные сервисы) обычно нуждаются в рынках, биржах или реестрах, где происходит взаимодействие пользователей, которым необходимы определенные услуги, с пользователями, которые эти услуги предоставляют.
Вероятно, такие рынки будут реализованы как внутрисетевые, автономные или смешанные сервисы, централизованные или распределенные.
4.2.1. Пример: подключение к TON Payments. Например, если кто-то хочет использовать сервис TON Payments (см. 5), первым шагом будет поиск по как минимум нескольких существующих транзитных узлов «сети мгновенных платежей»
77 4.2. Подключение пользователей и поставщиков услуг
(см. 5.2) и установление с ними каналов оплаты в случае готовности этих узлов.
Некоторые узлы могут быть найдены с помощью «охватывающей» оверлейной сети, которая должна содержать все узлы транзитной сети мгновенных платежей (см.
3.3.17). Однако неясно, будут ли эти узлы готовы создавать новые платежные каналы.
Следовательно, необходим реестр, в котором узлы, готовые к созданию новых ссылок, могут публиковать свою контактную информацию (например, свои абстрактные адреса).
4.2.2. Пример: загрузка файла в TON Storage. Точно так же, если кто-то хочет загрузить файл в хранилище TON, он должен найти несколько узлов, желающих подписать смарт-контракт, обязывающий их хранить копию этого файла (или любого другого файла ниже определенного предела размера). Следовательно, необходим реестр узлов, предлагающих свои услуги по хранению информации.
4.2.3. Сетевые, смешанные и автономные реестры. Такой реестр поставщиков услуг может быть реализован полностью ончейн с помощью смарт-контракта, который будет хранить реестр в постоянном хранилище. Однако это довольно медленно и дорого. Смешанный подход более эффективен, когда относительно небольшой и редко изменяемый ончейн реестр используется только для указания некоторых узлов (по их абстрактным адресам или по их открытым ключам, которые могут использоваться для определения фактических абстрактных адресов, как описано в 3.2.12), которые предоставляют услуги реестра вне сети
(централизованные).
Наконец, при децентрализованном, чисто автономном подходе может использоваться общедоступная оверлейная сеть (см. 3.3), в которой пользователи, которые хотят предложить свои услуги, или пользователи, которые хотят купить чьи-то услуги, просто транслируют свои предложения, подписанные закрытыми ключами. Если предоставляемая услуга очень проста, даже широковещательная передача предложений может не потребоваться: примерное членство в самой оверлейной сети может использоваться в качестве «реестра» тех, кто желает предоставить конкретную услугу. Клиент, которому требуется эта услуга, может найти (см. 3.3.7) и запросить некоторые узлы этой оверлейной сети, а затем запросить их соседей, если уже известные узлы не готовы предоставить необходимую услугу.
4.2.4. Регистрация или обмен в сайдчейне. Другой подход к реализации децентрализованных смешанных реестров заключается в создании независимого специализированного блокчейна («сайдчейна»), поддерживаемого собственным набором самопровозглашенных валидаторов, которые публикуют свои идентификаторы в ончейн смарт-контракте и предоставляют всем заинтересованным сторонам доступ в этот специализированный блокчейн, собирая транзакции- кандидаты и транслируя обновления блоков через выделенные оверлейные сети (см.
3.3). Затем любая полная нода для этого сайдчейна может поддерживать свою собственную копию общего реестра (по существу, равную глобальному состоянию этого сайдчейна) и обрабатывать произвольные запросы, связанные с этим реестром.
Иногда строить оверлейную сеть с нуля нет смысла. Вместо этого известна одна или несколько ранее существовавших оверлейных сетей, и ожидается, что членство в новой оверлейной сети будет значительно перекрываться с объединенным членством этих оверлейных сетей.
Важный пример – разделение шардчейна TON на два шардчейна, либо объединение двух родственных шардчейнов в один (см. 2.7). В первом случае оверлейные сети, используемые для распространения новых блоков на полные ноды, должны быть построены для каждого нового шардчейна. Однако можно ожидать, что каждая из этих новых оверлейных сетей будет содержаться в сети распространения блоков исходного шардчейна (и включать примерно половину ее членов). Во втором случае оверлейная сеть для распространения новых блоков объединенного шардчейна будет состоять примерно из объединения членов двух оверлейных сетей, связанных с двумя объединяемыми родственными шардчейнами.
В таких случаях описание новой оверлейной сети может содержать явную или неявную ссылку на список связанных существующих оверлейных сетей. Узел, желающий присоединиться к новой оверлейной сети, может проверить, является ли он уже членом одной из этих существующих сетей, и запросить своих соседей в этих сетях, заинтересованы ли они также в новой сети. В случае положительного ответа для таких соседей могут быть установлены новые двухточечные каналы, и они могут быть включены в список соседей для новой оверлейной сети.
73 3.3. Оверлейные сети и многоадресные сообщения
Этот механизм не заменяет полностью общий механизм, описанный в 3.3.6 и 3.3.7; скорее, оба механизма выполняются параллельно и используются для заполнения списка соседей. Это необходимо для предотвращения случайного разделения новой оверлейной сети на несколько несвязанных подсетей.
3.3.17. Оверлейные сети внутри оверлейных сетей. Другой интересный случай возникает при реализации сервиса TON Payments («сеть моментальных платежей» для мгновенных переводов стоимости вне сети; см. 5.2). В этом случае сначала строится оверлейная сеть, содержащая все транзитные узлы «сети моментальных платежей».
Однако некоторые из этих узлов имеют платежные каналы в блокчейне; они всегда должны быть соседями в этой оверлейной сети, в дополнение к любым «случайным» соседям, выбранным общими алгоритмами оверлейной сети, описанными в 3.3.6, 3.3.7 и 3.3.8, эти «постоянные соединения» с соседями с установленными платежными каналами используются для запуска определенных сетевых протоколов Lightning.
Таким образом, обеспечивается эффективное создание оверлейной подсети (не обязательно подключенной, если что-то пойдет не так) внутри охватывающей (почти всегда подключенной) оверлейной сети.
4
Сервисы и приложения TON
Мы подробно обсудили технологии блокчейна TON и TON Networking. Далее будут описаны некоторые способы, при помощи которых эти технологии могут быть объединены для создания широкого спектра услуг и приложений, а также некоторые из сервисов, которые будут предоставляться самим проектом TON с самого начала, либо позже.
4.1. Стратегии внедрения сервисов TON
Мы начнем с обсуждения того, как различные приложения и сервисы, связанные с блокчейном и сетью, могут быть реализованы внутри экосистемы TON. Прежде всего, следует привести простую классификацию:
4.1.1. Приложения и сервисы. Мы будем использовать слова «приложение» и
«сервисы» в качестве синонимов. Однако есть небольшое и несколько расплывчатое различие: приложение обычно предоставляет некоторые услуги напрямую пользователям-людям, в то время как сервис обычно используется другими приложениями и сервисами. Например, TON Storage - это сервис, потому что она предназначена для хранения информации от имени других приложений и сервисов, даже если пользователь-человек также может использовать ее напрямую.
Гипотетический «Facebook в блокчейне» (см. 2.9.13), если он будет доступен через сеть TON (т. е. реализован как «сервис TON»), скорее будет приложением, даже если некоторые «боты» могут получить к нему доступ автоматически без вмешательства человека.
4.1.2. Расположение приложения: ончейн, оффчейн или смешанный тип. Сервис или приложение, разработанное для экосистемы TON, должно где-то хранить свои данные и обрабатывать их. В результате получается следующая классификация приложений (и сервисов):
• Сетевые приложения (см. 4.1.4): все данные и обработка находятся в блокчейне
TON.
• Оффчейн-приложения (см. 4.1.5): все данные и обработка находятся за пределами блокчейна TON, на серверах, доступных через сеть TON.
74 4.1. Стратегии внедрения сервисов TON
• Смешанные приложения (см. 4.1.6): некоторые (но не все) данные и обработка находятся в блокчейне TON; остальные находятся на оффчейн-серверах, доступных через сеть TON.
4.1.3. Централизация: централизованные и децентрализованные или
распределенные приложения. Другой критерий классификации заключается в том, полагается ли приложение (или сервис) на централизованный кластер серверов или оно действительно является «распределенным» (см. 4.1.8). Все сетевые приложения автоматически являются децентрализованными и распределенными. Оффчейн и смешанные приложения могут иметь разную степень централизации.
Теперь рассмотрим вышеупомянутые возможности более подробно.
4.1.4. Чистые «ончейн» приложения: распределенные приложения или
«децентрализованные приложения», находящиеся в блокчейне. Одним из возможных подходов, упомянутых в 4.1.2, является развертывание «распределенного приложения» (сокращенно «dapp») полностью в блокчейне TON в виде одного смарт- контракта или набора смарт-контрактов. Все данные будут храниться как часть постоянного состояния этих смарт-контрактов, а все взаимодействие с проектом будет осуществляться с помощью сообщений (блокчейна TON), отправленных на эти смарт- контракты или полученных от них.
Мы уже обсуждали в 2.9.13, что этот подход имеет свои недостатки и ограничения. У него также есть свои преимущества: такому распределенному приложению не нужны серверы для работы или хранения данных (оно работает «в блокчейне», то есть на оборудовании валидаторов), и обладает чрезвычайно высокой (основанной на протоколе византийского соглашения) надежностью и доступностью блокчейна.
Разработчику такого распределенного приложения не нужно покупать или арендовать какое-либо оборудование. Все, что необходимо сделать, это разработать какое-то программное обеспечение (например, код для смарт-контрактов). После этого разработчик фактически арендует вычислительную мощность у валидаторов и платит за нее TON монетами сам, либо переложив это бремя на плечи своих пользователей.
4.1.5. Чисто сетевые услуги: «TON-сайты» и «TON-сервисы». Другой крайний вариант - развернуть службу на некоторых серверах и сделать ее доступной для пользователей через протокол ADNL, описанный в п. 3.1, и, возможно, какой-либо протокол более высокого уровня (например, описанный в п. 3.1.9 протокол RLDP), который можно использовать для отправки запросов RPC на сервис в любом настраиваемом формате и получить ответы на эти запросы. Таким образом, сервис будет полностью отключен от сети и будет находиться в сети TON почти без использования блокчейна TON.
Блокчейн TON может использоваться только для определения местоположения абстрактного адреса или адресов службы, как указано в 3.2.12, например, с помощью службы вроде TON DNS (см. 4.3.1), для облегчения перевода понятных человеку доменных имен в абстрактные адреса.
В той степени, в которой сеть ADNL (то есть сеть TON) похожа на проект Invisible
Internet Project (I
2
P), такие (почти) чисто сетевые услуги аналогичны так называемым
«eep-сервисам» (т. е. сервисам, которые имеют 1 2
P-адрес в качестве точки входа и доступен клиентам через сеть 1 2
P). Можно сказать, что такие чисто сетевые сервисы, реализуемые в сети TON, являются «TON-сервисами».
«Eep-сервис» может реализовать HTTP в качестве своего клиент-серверного протокола. В контексте сети TON «TON-сервис» может просто использовать датаграммы RLDP (см. 3.1.9) для передачи HTTP-запросов и ответов на них. Если он использует TON DNS, чтобы разрешить поиск своего абстрактного адреса по удобочитаемому доменному имени, можно провести почту точную аналогию с веб-
75 4.1. Стратегии внедрения сервисов TON сайтом. Можно даже написать специализированный браузер или специальный прокси-сервер («ton-proxy»), который запускается локально на машине пользователя и принимает произвольные HTTP-запросы от обычного веб-браузера, который использует пользователь (как только локальный IP-адрес и TCP-порт прокси-сервера вводятся в конфигурацию браузера), и пересылает эти запросы через сеть TON на абстрактный адрес службы. Тогда пользователь сможет просматривать страницы аналогично работе во всемирной паутине (WWW).
В экосистеме 1 2
P такие «eep-сервисы» называются «eep-сайтами». В экосистеме TON можно легко создавать «TON-сайты». Этому отчасти способствует существование таких служб, как TON DNS, которые используют блокчейн TON и TON DHT для преобразования доменных имен (TON) в абстрактные адреса.’
4.1.6. Смешанные сервисы: частично оффчейн, частично ончейн сервисы.
Некоторые сервисы могут использовать смешанный подход: выполнять большую часть обработки вне сети, но также иметь некоторую часть в блокчейне (например, для регистрации своих обязательств перед пользователями и наоборот). Таким образом, часть состояния по-прежнему будет храниться в блокчейне TON (то есть в неизменяемом публичном реестре), а любое неправильное поведение сервиса или его пользователей может быть наказано при помощи смарт-контрактов.
4.1.7. Пример: хранение файлов вне сети; TON Storage. Примером такого сервиса является TON Storage. В своей простейшей форме он позволяет пользователям хранить информацию вне сети, сохраняя в блокчейне только хэш информации, которая будет храниться, и, возможно, смарт-контракт, в котором некоторые другие стороны соглашаются хранить данную информацию в течение определенного периода времени за заранее оговоренную плату. Фактически, он может быть разделен на фрагменты небольшого размера (например, 1 килобайт), дополнен стирающим кодом
(например, кодом Рида-Соломона или исходным кодом), после чего может быть построен хэш дерева Меркла для расширенной последовательности фрагментов, который может быть опубликован в смарт-контракте вместо обычного хеша файла или вместе с ним. Это чем-то напоминает способ хранения файлов в виде торрент- файлов.
Еще более простая форма хранения файлов - полностью вне сети: можно по существу создать «торрент» для нового файла и использовать TON DHT в качестве
«распределенного торрент-трекера» для этого торрента (см. 3.2.10). Такая модель может действительно хорошо сработать для популярных файлов. Однако не дается никаких гарантий доступности. Например, для гипотетического сервиса «Facebook в блокчейне» (см. 2.9.13), который будет хранить фотографии своих пользователей полностью вне сети в таких «торрентах», существует риск потери фотографий обычных (не особенно популярных) пользователей, либо риск отсутствия возможности предоставлять эти фотографии в течение длительного времени.
Технология TON Storage, которая в основном является автономной, но использует ончейн смарт-контракт для обеспечения доступности хранимых данных, может быть наилучшим решением для этой задачи.
4.1.8. Децентрализованные смешанные услуги или «сервисы туманных
вычислений». До сих пор мы обсуждали централизованные смешанные сервисы и приложения. В то время как их сетевой компонент в блокчейне обрабатывается децентрализованным и распределенным образом, соответствующий автономный компонент полагается на некоторые серверы, контролируемые поставщиком услуг обычным централизованным образом. Вместо использования некоторых выделенных серверов вычислительные мощности могут быть арендованы у службы облачных
76 4.1. Стратегии внедрения сервисов TON вычислений, предлагаемой одной из крупных компаний. Однако это не приведет к децентрализации автономного компонента сервиса.
Децентрализованный подход к реализации оффчейн компонента сервиса заключается в создании рынка, на котором пользователи с необходимым оборудованием, которые готовы сдать в аренду свои вычислительные мощности или дисковое пространство, будут предлагать свои услуги тем, кто в них нуждается.
Например, может существовать реестр (который также может называться «рынком» или «биржей»), в котором все узлы, заинтересованные в сохранении информации о других пользователях, будут публиковать свои контактные данные, а также информацию о доступной емкости хранилища, политике доступности и ценах.
Пользователи, которым нужны эти услуги, могут найти поставщиков в этом реестре, и если другая сторона согласится, создать смарт-контракты в блокчейне и загрузить файлы для хранения вне сети. Таким образом, такой сервис, как TON Storage, становится действительно децентрализованным, поскольку ему не нужно полагаться на какой-либо централизованный кластер серверов для хранения информации.
4.1.9. Пример: платформы «туманных вычислений» как децентрализованные
смешанные сервисы.
Еще один пример такого децентрализованного смешанного приложения возникает, когда кто-то хочет выполнить некоторые конкретные вычисления (например, 3D- рендеринг или обучение нейронных сетей), что зачастую требует специального и дорогостоящего оборудования. Пользователи, у которых имеется такое оборудование, могут предлагать свои услуги через аналогичный «обмен», а те, кто нуждается в таких услугах, будут их арендовать, причем обязательства сторон будут регистрироваться с помощью смарт-контрактов. Эта модель похожа на то, что обещают предоставить платформы «туманных вычислений», такие как Golem (https://golem.network/) или
SONM (
https://sonm.io/
).
4.1.10. Пример: TON Proxy как сервис «туманных вычислений». Сервис TON
Proxy является еще одним примером сервиса «туманных вычислений». В нем могут регистрироваться нем узлы, предлагающие свои услуги (с компенсацией или без нее) в качестве туннелей для сетевого трафика ADNL, а пользователи, которые нуждаются в таких услугах, могут выбрать один из этих узлов в зависимости от цены, задержки сигнала и предлагаемой ширины канала. После этого можно использовать платежные каналы, предоставляемые TON Payments, для обработки микроплатежей за услуги этих прокси-серверов, при этом платежи собираются, например, за каждые 128 KiB переведенных данных.
4.1.11. Пример: TON Payments как сервис «туманных вычислений». Платформа
TON Payments (см. 5) также является примером такого децентрализованного смешанного приложения.
4.2. Подключение пользователей и поставщиков услуг
Мы увидели в 4.1.8, что «сервисы туманных вычислений» (т. е. смешанные децентрализованные сервисы) обычно нуждаются в рынках, биржах или реестрах, где происходит взаимодействие пользователей, которым необходимы определенные услуги, с пользователями, которые эти услуги предоставляют.
Вероятно, такие рынки будут реализованы как внутрисетевые, автономные или смешанные сервисы, централизованные или распределенные.
4.2.1. Пример: подключение к TON Payments. Например, если кто-то хочет использовать сервис TON Payments (см. 5), первым шагом будет поиск по как минимум нескольких существующих транзитных узлов «сети мгновенных платежей»
77 4.2. Подключение пользователей и поставщиков услуг
(см. 5.2) и установление с ними каналов оплаты в случае готовности этих узлов.
Некоторые узлы могут быть найдены с помощью «охватывающей» оверлейной сети, которая должна содержать все узлы транзитной сети мгновенных платежей (см.
3.3.17). Однако неясно, будут ли эти узлы готовы создавать новые платежные каналы.
Следовательно, необходим реестр, в котором узлы, готовые к созданию новых ссылок, могут публиковать свою контактную информацию (например, свои абстрактные адреса).
4.2.2. Пример: загрузка файла в TON Storage. Точно так же, если кто-то хочет загрузить файл в хранилище TON, он должен найти несколько узлов, желающих подписать смарт-контракт, обязывающий их хранить копию этого файла (или любого другого файла ниже определенного предела размера). Следовательно, необходим реестр узлов, предлагающих свои услуги по хранению информации.
4.2.3. Сетевые, смешанные и автономные реестры. Такой реестр поставщиков услуг может быть реализован полностью ончейн с помощью смарт-контракта, который будет хранить реестр в постоянном хранилище. Однако это довольно медленно и дорого. Смешанный подход более эффективен, когда относительно небольшой и редко изменяемый ончейн реестр используется только для указания некоторых узлов (по их абстрактным адресам или по их открытым ключам, которые могут использоваться для определения фактических абстрактных адресов, как описано в 3.2.12), которые предоставляют услуги реестра вне сети
(централизованные).
Наконец, при децентрализованном, чисто автономном подходе может использоваться общедоступная оверлейная сеть (см. 3.3), в которой пользователи, которые хотят предложить свои услуги, или пользователи, которые хотят купить чьи-то услуги, просто транслируют свои предложения, подписанные закрытыми ключами. Если предоставляемая услуга очень проста, даже широковещательная передача предложений может не потребоваться: примерное членство в самой оверлейной сети может использоваться в качестве «реестра» тех, кто желает предоставить конкретную услугу. Клиент, которому требуется эта услуга, может найти (см. 3.3.7) и запросить некоторые узлы этой оверлейной сети, а затем запросить их соседей, если уже известные узлы не готовы предоставить необходимую услугу.
4.2.4. Регистрация или обмен в сайдчейне. Другой подход к реализации децентрализованных смешанных реестров заключается в создании независимого специализированного блокчейна («сайдчейна»), поддерживаемого собственным набором самопровозглашенных валидаторов, которые публикуют свои идентификаторы в ончейн смарт-контракте и предоставляют всем заинтересованным сторонам доступ в этот специализированный блокчейн, собирая транзакции- кандидаты и транслируя обновления блоков через выделенные оверлейные сети (см.
3.3). Затем любая полная нода для этого сайдчейна может поддерживать свою собственную копию общего реестра (по существу, равную глобальному состоянию этого сайдчейна) и обрабатывать произвольные запросы, связанные с этим реестром.
1 ... 9 10 11 12 13 14 15 16 17