Создайте смарт-контракты в блокчейне

Стратегии внедрения услуг TON
Хэш дерева Меркла может быть создан для расширенной последовательности блоков,
и этот хэш дерева Меркла может быть опубликован в смарт-контракте вместо
обычного хэша файла или вместе с ним. Это несколько напоминает
способ хранения файлов в потоке.
Еще более простой формой хранения файлов является полностью о-цепочка: можно, по сути, создать торрент для нового файла и использовать TON DHT в качестве распределенного
торрент-трекера для этого торрента (см. 3.2.10). Это действительно может сработать неплохо
хорошо для популярных файлов. Однако никто не получает никаких гарантий доступности.
Например, гипотетический блокчейн Facebook (см. 2.9.13), который
предпочел бы хранить профессиональные фотографии своих пользователей полностью вне сети в таких
потоках, может рисковать потерять фотографии обычных (не особенно популярных)
пользователи или, по крайней мере, рискуют не иметь возможности представлять эти фотографии в течение длительного
времени. Технология хранения данных TON, которая в основном является o-цепочкой, но использует
смарт-контракт по цепочке для обеспечения доступности хранимых файлов, может
лучше соответствовать этой задаче.
4.1.8. Децентрализованные смешанные услуги, или услуги тумана. До сих пор мы
обсуждали централизованные смешанные сервисы и приложения. В то время как их сетевой
компонент обрабатывается децентрализованным и распределенным способом, будучи
расположенным в блокчейне, их компонент o-chain полагается на некоторые серверы,
управляемые поставщиком услуг обычным централизованным способом. Вместо
использования некоторых выделенных серверов вычислительные мощности могут быть арендованы у службы
облачных вычислений, предлагаемой одной из крупных компаний. Однако это
это не приведет к децентрализации компонента o-chain службы.
Децентрализованный подход к реализации компонента o-chain
услуги заключается в создании рынка, где любой, кто обладает необходимым
оборудованием и готов арендовать свои вычислительные мощности или дисковое пространство, будет
предлагать свои услуги тем, кто в них нуждается.
Например, может существовать реестр (который также может называться
рынком или биржей), в котором все узлы, заинтересованные в хранении файлов других
пользователей, публикуют свои контактные данные вместе с доступным хранилищем
вместимость, политика доступности и цены. Те, кто нуждается в этих услугах, могут
посмотрите их там и, если другая сторона согласна, создайте смарт-контракты в
блокчейне и загрузите файлы для хранения o-chain. Таким образом, такая служба,
как TON Storage, становится по-настоящему децентрализованной, поскольку ей не нужно
полагаться на какой-либо централизованный кластер серверов для хранения файлов.
4.1.9. Пример: вычислительные платформы fog как децентрализованные смешанные
сервисы. Возникает еще один пример такого децентрализованного смешанного приложения
101
4.2. Подключение Пользователей и Поставщиков Услуг
когда кто-то хочет выполнить некоторые специальные вычисления (например, 3D-рендеринг или
обучение нейронных сетей), часто требуется специальное и дорогостоящее оборудование.
Затем те, у кого есть такое оборудование, могли бы предлагать свои услуги через аналогичную
биржу, а те, кто нуждается в таких услугах, арендовали бы их с обязательствами сторон, зарегистрированными с помощью смарт-контрактов. Это похоже на то
, что делают вычислительные платформы fog, такие как Golem (https://golem.network /)
или СОНМ (https://sonm.io /), обещают доставить.
4.1.10. Пример: Прокси-сервер TON - это услуга fog. Прокси-сервер TON предоставляет еще
еще один пример службы тумана, где узлы, желающие предложить свои услуги
(с компенсацией или без нее) в качестве туннелей для сети ADNL может быть
зарегистрирован трафик, и те, кому они нужны, могут выбрать один из этих узлов в зависимости
от цены, задержки и пропускной способности. Впоследствии можно было бы использовать
платежные каналы, предоставляемые TON Payments, для обработки микроплатежей
за услуги этих прокси-серверов, при этом платежи собирались, например, за
каждые переданные 128 КБ.
4.1.11. Пример: Платежи тоннами - это услуга тумана. Тонна Платежей
платформа (см. 5) также является примером такого децентрализованного смешанного приложения.
4.2 Подключение Пользователей и Поставщиков услуг
Мы видели в 4.1.8, что сервисы fog (т. Е. Смешанные децентрализованные сервисы)
обычно потребуются некоторые рынки, биржи или реестры, где те, кому нужны
конкретные услуги, могут встретиться с теми, кто их предоставляет.
Такие рынки, скорее всего, будут реализованы в виде самих сетевых, о-цепных или смешанных
услуг, централизованных или распределенных.
4.2.1. Пример: подключение к платежам TON. Например, если кто-
то хочет использовать платежи ТОННАМИ (см. 5), первым шагом было бы найти по крайней мере
некоторые существующие транзитные узлы сети lightning (см. 5.2) и установите
с ними платежные каналы, если они того пожелают. Некоторые узлы можно найти
с помощью охватывающей оверлейной сети, которая, как предполагается,
содержит все транзитные узлы сети lightning (см. 3.3.17). Однако
неясно, будут ли эти узлы готовы создавать новые платежные каналы.
Поэтому необходим реестр, в котором узлы, готовые создавать новые ссылки, могут
публиковать свою контактную информацию (например, свои абстрактные адреса).
4.2.2. Пример: загрузка файла в хранилище TON. Аналогично, если один
хочет загрузить файл в хранилище TON, она должна найти несколько узлов
102
4.3. Доступ к сервисам TON
, желающим подписать смарт-контракт, обязывающий их хранить копию этого файла (или
любого файла, размер которого не превышает определенного предела, если на то пошло). Поэтому необходим реестр
узлов, предлагающих свои услуги по хранению файлов.
4.2.3. Реестры по цепочке, смешанные и о-цепные реестры. Такой реестр поставщиков
услуг может быть реализован полностью по цепочке с помощью
смарт-контракта, который сохранит реестр в его постоянном хранилище.
Однако это было бы довольно медленно и дорого. Смешанный подход
более эффективен, когда относительно небольшой и редко изменяемый сетевой реестр
используется только для указания некоторых узлов (по их абстрактным адресам или по
их открытым ключам, которые можно использовать для определения фактических абстрактных адресов, как
описано в 3.2.12), которые предоставляют услуги o-chain (централизованного) реестра.
Наконец, децентрализованный, чисто o-цепной подход может состоять из
общедоступной оверлейной сети (см. 3.3), где те, кто готов предложить свои услуги,
или те, кто хочет купить чьи-то услуги, просто передают свои
предложения, подписанные их закрытыми ключами. Если предоставляемая услуга очень проста,
может не потребоваться даже трансляция предложений: приблизительное членство в
самой оверлейной сети может использоваться в качестве реестра тех, кто готов
предоставить конкретную услугу. Затем клиент, которому требуется эта услуга, может найти (см. 3.3.7) и запросить некоторые узлы этой оверлейной сети, а затем запросить
их соседей, если уже известные узлы не готовы удовлетворить его потребности.
4.2.4. Регистрация или обмен в боковой цепочке. Другой подход к реализации смешанных децентрализованных реестров состоит в создании независимой специализированной блокчейн ( боковой цепи ), поддерживается собственный набор самопровозглашенных валидаторы, которые публикуют их личности в цепи смарт-контракта и обеспечение сетевого доступа для всех заинтересованных сторон настоящего специализированных
блокчейн, собирая кандидатов транзакции и вещание обновления блока
через специальную наложенных сетей (МФ. 3.3). Тогда любой полный узел для этого
боковая цепочка может поддерживать свою собственную копию общего реестра (по существу, равную
глобальному состоянию этой боковой цепочки) и обрабатывать произвольные запросы, связанные
с этим реестром.
4.2.5. Регистрация или обмен в рабочей цепочке. Другой вариант -
создать специальную рабочую цепочку внутри блокчейна TON, специализированную для
создания реестров, рынков и бирж.