Открытая сеть. Открытая сеть по материалам работы дра Николая Дурова 26 июля 2021
 Скачать 0.79 Mb.
|
|
94 3.3. Оверлейные сети и многоадресные сообщения новых сообщений). Сосед может запросить само сообщение после изучения ранее невидимого хэша сообщения, который будет передан, скажем, с использованием надежного протокола больших дейтаграмм (RLDP), обсуждаемого в 3.1.9. Таким образом, новое сообщение будет загружено только от одного соседа. 3.3.14. Проверка подключения оверлейной сети. Подключение оверлейной сети можно проверить,если есть известный узел (например, владелец или создатель оверлейной сети), который должен находиться в этой оверлейной сети. Тогда рассматриваемый узел просто транслирует время от времени короткие сообщения, содержащие текущее время, порядковый номер и его подпись. Любой другой узел может быть уверен, что он все еще подключен к оверлейной сети, если он получил такую трансляцию не так давно. Это протокол может быть расширен на случай нескольких известных узлов; например, все они будут отправлять такие трансляции, а все остальные узлы будут ожидать приема трансляций от более чем половины известных узлов. В случае оверлейной сети, используемой для распространения новых блоков (или просто новых заголовков блоков) определенной цепочки шардов, хороший способ для узла проверить связь-это отслеживать самый последний блок, полученный до сих пор. Потому что блок обычно генерируется каждые пять секунд, если нет новогоблок принимается более, скажем, тридцати секунд, узел, вероятно, был отключен от оверлейной сети. 3.3.15. Протокол потокового вещания. Наконец, существует протокол потокового вещания для оверлейных сетей TON, используемый, например, для распространения кандидатов в блоки среди валидаторов некоторой shardchain (shardchain task group), которые, конечно же, создают для этой цели частную оверлейную сеть. Один и тот же протокол может использоваться для распространения новых блоков shardchain на все полные узлы для этого shardchain. Этот протокол уже был описан в 2.6.10: новое (большое) широковещательное сообщение разбивается, скажем, на N однокилобайтных блоков; последовательность этих блоков увеличивается до M ≥ N блоков с помощью кода стирания, такого как код Рида Соломона или код фонтана (например, RaptorQcode [9] [14]), и эти M блоков передаются всем соседям в порядке возрастания номера блока . Участвующие узлы собирают эти фрагменты до тех пор, пока они не смогут восстановить исходное большое сообщение (нужно было бы успешно получить не менее N из кусков для этого), а затем поручить своим соседям прекратить отправку новых кусков потока, потому что теперь эти узлы могут генерировать последующие куски самостоятельно, имея копию исходного сообщения. Такие узлы продолжают генерировать последующие фрагменты потока и отправлять их в 95 3.3. Оверлейные сети и многоадресные сообщения их соседи, если только соседи в свою очередь не укажут, что в этом больше нет необходимости. Таким образом, узлу не нужно загружать большое сообщение полностью, прежде чем распространять его дальше. Это минимизирует задержку вещания, особенно в сочетании с оптимизациями, описанными в 3.3.10. 3.3.16. Построение новых оверлейных сетей на основе существующих. Иногда не хочется строить оверлейную сеть с нуля. Вместо этого известна одна или несколько ранее существовавших оверлейных сетей, и ожидается, что членство в новой оверлейной сети будет значительно перекрываться с объединенным членством в этих оверлейных сетях. Важный пример возникает, когда цепочка осколков ТОННЫ разделяется на две части или две родственные цепочки осколков объединяются в одну (см. 2.7). В первом случае сети наложения, используемые для распространения новых блоков на полные узлы, должны быть построены для каждой из новых цепочек шардов; однако можно ожидать, что каждая из этих новых сетей наложения будет содержаться в сети распространения блоков исходной цепочки шардов (и включать примерно половину ее членов). Во втором случае сеть наложения для распространения новых блоков объединенная цепочка шардов будет состоять примерно из объединения членов двух оверлейных сетей, связанных с двумя объединяемыми братскими цепочками шардов. В таких случаях описание новой оверлейной сети может содержать явную или неявную ссылку на список связанных существующих оверлейных сетей. Узел, желающий присоединиться к новой оверлейной сети, может проверить, является ли он уже членом одной из этих существующих сетей, и запросить своих соседей в этих сетях, заинтересованы ли они в новой сети. В случае положительного ответа к таким соседям могут быть установлены новые каналы точка- точка , и они могут быть включены в список соседей для новой оверлейной сети. Этот механизм не полностью вытесняет общий механизм , описанный в 3.3.6 и 3.3.7; скорее, оба они выполняются параллельно и используются для заполнения списка соседей. Это необходимо для предотвращения непреднамеренного разделения новой оверлейной сети на несколько несвязанных подсетей. 3.3.17. Оверлейные сети внутри оверлейных сетей. Еще один интересный случай возникает при реализации платежей TON (lightning network для мгновенных переводов стоимости o - chain; ср. 5.2). В этом случае сначала строится оверлейная сеть, содержащая все транзитные узлы сети Lightning . Однако некоторые из этих узлов установили платежные каналы в блокчейне; они всегда должны быть соседями в этой наложенной сети, в 96 3.3. Оверлейные сети и многоадресные сообщения дополнение к любым случайным соседям, выбранным общими алгоритмами оверлейной сети, описанными в 3.3.6, 3.3.7 и 3.3.8. Эти постоянные ссылки на соседей с установленными платежными каналами используются для запуска специальных протоколов Lightning network, таким образом эффективно создавая оверлейную подсеть (не обязательно связанную, если что-то пойдет не так) внутри охватывающей сети.(почти всегда подключенная) оверлейная сеть. 97 4.1. Стратегии внедрения сервиса TON 4 Услуги и приложения TON Мы подробно обсудили технологии TON Blockchain и TON Networking . Теперь мы объясним некоторые способы, которыми они могут быть объединены для создания широкого спектра сервисов и приложений, и обсудим некоторые услуги, которые будут предоставляться самим проектом TON, либо с самого начала, либо позже. 4.1 Стратегии внедрения сервиса TON Мы начнем с обсуждения того, как различные приложения и сервисы, связанные с блокчейном и сетью, могут быть реализованы в экосистеме TON. Прежде всего, необходимо провести простую классификацию: 4.1.1. Приложения и сервисы. Мы будем использовать слова application и service взаимозаменяемо. Однако существует тонкое и несколько расплывчатое различие: приложение обычно предоставляет некоторые услуги непосредственно пользователям, в то время как услуга обычно используется другими приложениями и службами. Например, TON Storage-это сервис, поскольку он предназначен для хранения файлов от имени других приложений и служб, даже если пользователь может использовать его напрямую. Гипотетический Facebook в блокчейне (см. 2.9.13), если он доступен через сеть TON (т. Е., реализованный как ton-сервис), скорее будет приложением, хотя некоторые боты могут получить к нему доступ автоматически без вмешательства человека. 4.1.2. Место нанесения: цепное, кольцевое или смешанное. Сервис или приложение, предназначенное для экосистемы TON, должно где-то хранить свои данные и обрабатывать их. Это приводит к следующей классификации приложений (и служб):: ˆ Приложения On-chain (см. 4.1.4): все данные и обработка находятся в блокчейне TON. ˆ Приложения O - chain (см. 4.1.5): все данные и обработка находятся вне блокчейна TON, на серверах, доступных через сеть TON. ˆ Смешанные приложения (см. 4.1.6): некоторые, но не все данные и обработка находятся в блокчейне TON; остальные находятся на серверах o - chain, доступных через сеть TON. 98 4.1. Стратегии внедрения сервиса TON 4.1.3. Централизация: централизованные и децентрализованные, или распределенные, приложения. Другим критерием классификации является то, полагается ли приложение (или служба) на централизованный серверный кластер или действительно распределено (см. 4.1.8). Все сетевые приложения автоматически децентрализуются и распространяются. O - chain и смешанные приложения могут демонстрировать различные степени централизации. Теперь рассмотрим вышеперечисленные возможности более подробно. 4.1.4. Чистые приложения on-chain: распределенные приложения или dapps, находящиеся в блокчейне. Одним из возможных подходов, упомянутых в 4.1.2, является развертывание распределенного приложения (обычно сокращенно dapp) полностью в блокчейне TON в виде одного смарт -контракта или набора смарт - контрактов. Все данные будут храниться как часть постоянного состояния этих смарт-контрактов, и все взаимодействие с проектом будет осуществляться с помощью сообщений (TON Blockchain), отправленных или полученных от этих смарт-контрактов. Мы уже обсуждали в 2.9.13, что этот подход имеет свои недостатки и ограничения. У него есть и свои преимущества: такое распределенное приложение не нуждается в серверах для запуска или хранения своих данных (оно работает в блокчейне , то есть на оборудовании валидаторов) и обладает чрезвычайно высокой (византийской) надежностью и доступностью блокчейна. Разработчику такого распределенного приложения не нужно покупать или арендовать какое-либо оборудование; все, что ей нужно сделать, это разработать некоторое программное обеспечение (т. Е. Код для смарт-контрактов). После этого она будет эффективно арендовать вычислительные мощности у валидаторов и будет платить за это тоннами монет, либо сама, либо перекладывая это бремя на плечи своих пользователей. 4.1.5. Чистые сетевые сервисы: ton-сайты и ton-сервисы . Другой крайний вариант-развернуть службу на некоторых серверах и сделать ее доступной для пользователей через протокол ADNL, описанный в 3.1, и, возможно, какой -нибудь протокол более высокого уровня, такой как RLDP, описанный в 3.1.9, который можно использовать для отправки запросов RPC в службу в любом пользовательском формате и получения ответов на эти запросы.запросы. Таким образом, сервис будет полностью o - chain и будет находиться в сети TON, почти не используя блокчейн TON. Блокчейн TON может использоваться только для поиска абстрактного адреса или адресов сервиса, как описано в 3.2.12, возможно, с помощью такой службы, как TON DNS (см. 4.3.1), чтобы облегчить перевод доменоподобных удобочитаемых строк в абстрактные адреса. 99 4.1. Стратегии внедрения сервиса TON В той мере, в какой сеть ADNL (т. Е. Сеть TON) аналогична Невидимый интернет-проект (I 2 P ), такие (почти) чисто сетевые сервисы аналогичны так называемым eep-сервисам (т. е. сервисам, имеющим I 2 P - адрес как их точка входа, и доступны клиентам через I 2 P сеть). Скажем, что такие чисто сетевые сервисы, находящиеся в Сети TON, являются ton-сервисами . Eep-сервис может реализовать HTTP в качестве протокола клиент-сервер; в контексте сети TON ton-сервис может просто использовать дейтаграммы RLDP (см. 3.1.9) для передачи HTTP-запросов и ответов на них. Если он использует DNS TON для поиска своего абстрактного адреса по удобочитаемому доменному имени, аналогия с веб-сайтом становится почти идеальной. Можно даже написать специализированный браузер или специальный прокси ( ton-proxy), который запускается локально на компьютере пользователя и принимает произвольные HTTP-запросы от обычного веб-браузер, который использует пользователь (после ввода локального IP-адреса и TCP- порта прокси-сервера в конфигурацию браузера), и пересылает эти запросы через сеть TON на абстрактный адрес службы. Тогда у пользователя будет опыт просмотра, аналогичный опыту Всемирной паутины (WWW). В I 2 P экосистема, такие eep-сервисы называются eep-сайтами . Можно легко создавать ton-сайты и в экосистеме TON. Этому несколько способствует существование таких сервисов, как TON DNS, которые используют блокчейн TON и TON DHT для перевода (TON) доменных имен в абстрактные адреса. 4.1.6. Смешанные услуги: частично o - chain, частично on-chain. Некоторые сервисы могут использовать смешанный подход: выполнять большую часть обработки o- chain, но также иметь некоторую часть on-chain (например, регистрировать свои обязательства перед пользователями и наоборот). Таким образом, часть государства по-прежнему будет храниться в блокчейне TON (т. Е. неизменяемом публичном реестре), и любое неправильное поведение сервиса или его пользователей может быть наказано смарт -контрактами. 4.1.7. Пример: хранение уплотнительной цепи les; Хранение ТОНН. Пример такой услуги дает TON Storage. В своей простейшей форме он позволяет пользователям хранить файлы o-chain, сохраняя в цепочке только хэш файла, который будет храниться, и, возможно, смарт-контракт, в котором некоторые другие стороны соглашаются хранить рассматриваемый файл в течение определенного периода времени за предварительно оговоренную плату. Фактически, файл может быть разделен на куски небольшого размера (например, 1 килобайт), дополненные кодом стирания, таким как код Рида Соломона или код фонтана. 100 4.1. Стратегии внедрения сервиса TON Хэш Merkle tree может быть сконструирован для дополненной последовательности фрагментов, и этот хэш Merkle tree может быть опубликован в смарт-контракте вместо обычного хэша файла или вместе с ним. Это несколько напоминает способ хранения файлов в торренте. Еще более простая форма хранения файлов полностью o-chain: можно создать торрент для нового файла и использовать TON DHT в качестве распределенного торрент-трекера для этого торрента (см. 3.2.10). Это может действительно хорошо работать для популярных файлов. Однако никто не получает никаких гарантий доступности. Например, гипотетический блокчейн Facebook (см. 2.9.13), который предпочел бы сохранить фотографии своих пользователей полностью o - chain в таких торренты могут рисковать потерять фотографии обычных (не особенно популярных) пользователей или , по крайней мере, рисковать не иметь возможности представить эти фотографии в течение длительного времени. Технология хранения TON, которая в основном является o - chain, но использует смарт-контракт on-chain для обеспечения доступности хранимых файлов, может быть лучше подходит для этой задачи. 4.1.8. Децентрализованные смешанные сервисы, или туманные сервисы . До сих пор мы обсуждали централизованные смешанные сервисы и приложения. В то время как их компонент on-chain обрабатывается децентрализованным и распределенным способом, находясь в блокчейне, их компонент o-chain полагается на некоторые серверы , контролируемые поставщиком услуг обычным централизованным способом. Вместо того, чтобы использовать некоторые выделенные серверы, вычислительная мощность может быть арендована у службы облачных вычислений, предлагаемой одной из крупных компаний. Однако это не приведет к децентрализации компонента o - chain сервиса. Децентрализованный подход к реализации компонента o-chain услуги заключается в создании рынка, где любой, кто обладает необходимым оборудованием и готов арендовать свои вычислительные мощности или дисковое пространство , предложит свои услуги тем, кто в них нуждается. Например, может существовать реестр (который также может называться рынком или биржей), где все узлы, заинтересованные в сохранении файлов других пользователей, публикуют свои контактные данные, а также доступную емкость хранилища, политику доступности и цены. Те, кто нуждается в этих услугах, могут посмотреть их там и, если другая сторона согласится, создать смарт-контракты в блокчейне и загрузить файлы для хранения o-chain. Таким образом, такой сервис , как TON Storage, становится действительно децентрализованным, поскольку ему не нужно полагаться на какой-либо централизованный кластер серверов для хранения файлов. 4.1.9. Пример: платформы туманных вычислений как децентрализованные смешанные сервисы. Возникает еще один пример такого децентрализованного смешанного приложения 101 4.2. Подключение пользователей и поставщиков услуг когда требуется выполнить некоторые специальные вычисления (например, 3D-рендеринг или обучение нейронных сетей), часто требующие специального и дорогостоящего оборудования. Тогда те , у кого есть такое оборудование, могут предложить свои услуги через аналогичную биржу, а те, кто нуждается в таких услугах, арендуют их, причем обязательства сторон регистрируются посредством смарт-контрактов. Это похоже на то, что делают туманные вычислительные платформы, такие как Golem (https://golem.network/) или SONM (https://sonm.io/), обещают доставить. 4.1.10. Пример: TON Proxy - это служба тумана. TON Proxy представляет собой еще один пример службы тумана, где узлы, желающие предложить свои услуги (с компенсацией или без нее) в качестве туннелей для трафика сети ADNL, могут зарегистрироваться, и те, кто нуждается в них, могут выбрать один из этих узлов в зависимости от цены, задержки и пропускной способности. После этого можно было бы использовать платежные каналы, предоставляемые TON Payments, для обработки микроплатежей за услуги этих прокси-серверов, при этом платежи собирались бы, например, за каждые переведенные 128 Кб. 4.1.11. Пример: TON Payments - это услуга fog. Платежная платформа TON (cf. 5) также является примером такого децентрализованного смешанного приложения. 4.2 Подключение пользователей и поставщиков услуг Мы видели в 4.1.8, что услуги тумана (т. е. смешанные децентрализованные услуги) обычно нуждаются в некоторых рынках, биржах или реестрах, где те, кто нуждается в конкретных услугах, могут встретиться с теми, кто их предоставляет. Такие рынки, скорее всего, будут реализованы как цепные, o-цепные или смешанные услуги, централизованные или распределенные. 4.2.1. Пример: подключение к TON Payments. Например, если кто -то хочет использовать TON Payments (см. 5), первым шагом будет найти по крайней мере некоторые существующие транзитные узлы lightning network (см. 5.2) и установить с ними платежные каналы, если они этого захотят. Некоторые узлы могут быть найдены с помощью охватывающей оверлейной сети, которая должна содержать все транзитные узлы Lightning network (см. 3.3.17). Однако неясно, будут ли эти узлы готовы создавать новые платежные каналы. |