Файл: Аннотация Цель данной работы предоставить первое описание блокчейнплатформы ton (The Open Network) и связанных с ней технологий одноранговых сетей, распределенного хранилища и хостинга..pdf

ВУЗ: Не указан

Категория: Реферат

Дисциплина: Не указана

Добавлен: 25.10.2023

Просмотров: 261

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Одним из вариантов может быть включение абстрактного сетевого адреса в смарт- контракт, создающий платежный канал. Более гибкий вариант — включить открытый ключ в смарт-контракт, а затем использовать DHT, как описано в 3.2.12.

68 3.2. TON DHT: Распределенная хеш-таблица, подобная Kademlia
Наиболее естественным способом было бы использовать тот же закрытый ключ, который управляет учетной записью в блокчейне TON, для подписания и публикации обновлений в TON DHT об абстрактных адресах, связанных с этой учетной записью.
Этот процесс практически совпадает с п. 3.2.12; однако для используемого ключа DHT потребуется специальное описание ключа, содержащее только идентификатор account_id, равный SHA256 «описания учетной записи», который содержит открытый ключ учетной записи. Подпись, включенная в значение этого ключа DHT, также будет содержать описание учетной записи.
Таким образом, становится доступным механизм определения абстрактных сетевых адресов некоторых владельцев учетных записей блокчейна TON.
3.2.14. Поиск абстрактных адресов. Обратите внимание, что хотя таблица TON DHT и реализуется поверх TON ADNL, TON DHT сама используется TON ADNL для нескольких целей.
Самая важная задача - найти узел или его контактные данные, начиная с 256-битного абстрактного адреса. Это необходимо, потому что TON ADNL должен иметь возможность отправлять датаграммы на произвольные 256-битные абстрактные адреса, даже если не предоставляется никакой дополнительной информации.
Для этого 256-битный абстрактный адрес просто просматривается как ключ в DHT.
При этом либо находится узел с этим адресом (т. е. с использованием этого адреса в качестве общедоступного полупостоянного адреса DHT), и в этом случае можно узнать его IP-адрес и порт; либо может быть получено описание входного туннеля как значение рассматриваемого ключа, подписанное правильным закрытым ключом, и в этом случае это описание туннеля будет использоваться для отправки датаграмм
ADNL предполагаемому получателю.
Обратите внимание: для того, чтобы сделать абстрактный адрес «общедоступным»
(доступным с любых узлов в сети), его владелец должен либо использовать его как полупостоянный адрес DHT, либо опубликовать (в ключе DHT, равном рассматриваемому абстрактному адресу ) описание входного туннеля с другим его общедоступным абстрактным адресом (например, полупостоянным адресом) в качестве точки входа в туннель. Другой вариант - просто опубликовать IP-адрес и порт UDP.
3.3. Оверлейные сети и многоадресные сообщения
В мультичейн-системе, такой как блокчейн TON, даже полные ноды обычно заинтересованы в получении обновлений (т. е. новых блоков) только для некоторых шардчейнов. С этой целью внутри сети TON для каждого шардчейна должна быть построена специальная оверлейная (под) сеть поверх протокола ADNL, описанного в п. 3.1.
Следовательно, возникает необходимость в создании произвольных оверлейных подсетей, открытых для любых узлов, желающих в них участвовать. В этих оверлейных сетях будут работать специальные протоколы сплетен, основанные на
ADNL. В частности, эти протоколы сплетен могут использоваться для распространения (передачи) произвольных данных внутри такой подсети.
3.3.1. Оверлейные сети. Оверлейная (под) сеть - это просто (виртуальная) сеть, реализованная внутри более крупной сети. Обычно только некоторые узлы более крупной сети участвуют в оверлейной подсети, и только некоторые «связи» между этими узлами, физическими или виртуальными, являются частью оверлейной подсети.
Таким образом, если представить сеть в виде графа (возможно, полного графа в случае сети датаграмм, такой как ADNL, где любой узел может легко связываться с любым другим), оверлейная подсеть является подграфом этого графа.


69 3.3. Оверлейные сети и многоадресные сообщения
В большинстве случаев оверлейная сеть реализуется с использованием какого-либо протокола, построенного на сетевом протоколе более крупной сети. Она может использовать те же адреса, что и более крупная сеть, либо использовать собственные адреса.
3.3.2. Оверлейные сети в TON. Оверлейные сети в TON построены на протоколе
ADNL, описанном в п. 3.1; в них также используются 256-битные абстрактные адреса
ADNL в качестве адресов. Каждый узел обычно выбирает один из своих абстрактных адресов, который удваивается в оверлейной сети.
В отличие от ADNL, оверлейные сети TON обычно не поддерживают отправку датаграмм на другие произвольные узлы. Вместо этого между некоторыми узлами
(называемыми «соседями» по отношению к рассматриваемой оверлейной сети) устанавливается «полупостоянная связь», и сообщения обычно пересылаются по этой связи (т. е. от узла к одному из его соседей). Таким образом, оверлейная сеть TON представляет собой (обычно не полный) подграф внутри (полного) графа сети ADNL.
Связи с соседями в оверлейных сетях TON могут быть реализованы с использованием выделенных одноранговых каналов ADNL (см. 3.1.5).
Каждый узел оверлейной сети поддерживает список соседей (по отношению к оверлейной сети), содержащий их абстрактные адреса (которые они используют для собственной идентификации в оверлейной сети) и некоторые данные связи (например, канал ADNL, используемый для связи).
3.3.3. Частные и общедоступные оверлейные сети. Некоторые оверлейные сети являются общедоступными, что означает, что любой узел может присоединиться к ним по своему желанию. Другие являются частными – в них могут быть допущены только определенные узлы (например, узлы, которые могут подтвердить, что они являются валидаторами). Некоторые частные оверлейные сети могут быть даже неизвестны «широкой публике». Информация о таких оверлейных сетях доступна только определенным доверенным узлам; например, она может быть зашифрована открытым ключом, и расшифровать эту информацию смогут только узлы, имеющие копию соответствующего закрытого ключа.
3.3.4. Централизованно управляемые оверлейные сети. Некоторые оверлейные сети управляются централизованно одним или несколькими узлами или владельцем широко известного открытого ключа. Другие являются децентрализованными – это означает, что за них не отвечают какие-либо конкретные узлы.
3.3.5. Присоединение к оверлейной сети. Когда узел хочет присоединиться к оверлейной сети, он сначала должен узнать свой 256-битный сетевой идентификатор, обычно равный SHA256 описания оверлейной сети - TL-сериализированный объект
(см. 2.2.5), который может содержать, например, центр оверлейной сети (то есть его открытый ключ и, возможно, его абстрактный адрес
33
), строка с именем оверлейной сети, идентификатор сегмента блокчейна TON, если это оверлейная сеть, связанная с этим шардом, и т. д.
Иногда возможно восстановить описание оверлейной сети, начиная с идентификатора сети, просто просмотрев его в TON DHT. В других случаях (например, для частных оверлейных сетей) необходимо получить описание сети вместе с идентификатором сети.
3.3.6. Поиск одного члена оверлейной сети. После того, как узел узнает идентификатор сети и описание оверлейной сети, к которой он хочет присоединиться, он должен найти хотя бы один узел, принадлежащий этой сети.


70 3.3. Оверлейные сети и многоадресные сообщения
Это также необходимо для узлов, которые не хотят присоединяться к оверлейной сети, а хотят просто связаться с ее участниками. Например, может существовать оверлейная сеть, предназначенная для сбора и распространения транзакций-кандидатов для определенного шардчейна, и клиент может захотеть подключиться к любому узлу этой сети, чтобы предложить транзакцию.
Метод, используемый для обнаружения элементов оверлейной сети, определяется в описании этой сети. Иногда (особенно для частных сетей) нужно уже знать принадлежащий этой сети узел, чтобы иметь возможность присоединиться. В других случаях в описании сети содержатся абстрактные адреса некоторых узлов. Более гибкий подход состоит в том, чтобы указать в описании сети только центральный узел, ответственный за сеть, и тогда абстрактные адреса будут доступны через значения определенных ключей DHT, подписанных этим центральным узлом.
Наконец, действительно децентрализованные общедоступные оверлейные сети могут использовать механизм «распределенного трекера», описанный в 3.2.10, также реализованный с помощью TON DHT.
3.3.7. Поиск дополнительных участников оверлейной сети. Создание ссылок. Как только один узел оверлейной сети будет найден, этому узлу может быть отправлен специальный запрос, запрашивающий список других членов, например, соседей запрашиваемого узла, или список случайных узлов.
Это позволяет присоединяющемуся узлу заполнить «список своих соседей» по отношению к оверлейной сети, выбрав некоторые недавно изученные сетевые узлы и установив с ними связи (т. е. выделенные двухточечные каналы ADNL, как описано в общих чертах в п. 3.3.2). После этого всем соседям отправляются специальные сообщения, указывающие, что новый участник готов работать в оверлейной сети.
Соседи включают свои ссылки на нового участника в свои списки соседей.
3.3.8. Ведение списка соседей. Узел оверлейной сети должен время от времени обновлять свой список соседей. Некоторые соседи или хотя бы ссылки (каналы) на них могут перестать отвечать; в этом случае эти ссылки должны быть помечены как
«приостановленные», должны быть предприняты некоторые попытки повторного подключения к таким соседям, и, если эти попытки не удались, ссылки должны быть уничтожены.
С другой стороны, каждый узел иногда запрашивает у случайно выбранного соседа свой список соседей (или некоторый случайный выбор из них) и использует его для частичного обновления своего собственного списка соседей, добавляя к нему несколько недавно обнаруженных узлов и удаляя некоторые старые узлы (случайным образом или в зависимости от времени отклика и статистики потери датаграмм).
3.3.9. Оверлейная сеть как случайный подграф. Таким образом, оверлейная сеть становится случайным подграфом внутри сети ADNL. Если степень каждой вершины не менее 3 (т. е. если каждый узел связан, по крайней мере, с тремя соседями), этот случайный граф связан с вероятностью, почти равной единице.
Точнее, вероятность того, что случайный граф с n вершинами будет отключен, экспоненциально мала, и этой вероятностью можно полностью пренебречь, если, скажем, n

20. (Конечно, это не применимо в случае разделения глобальной сети, когда узлы на разных сторонах раздела не имеют возможности узнать друг о друге.)
С другой стороны, если n меньше 20, достаточно потребовать, чтобы каждая вершина имела, скажем, как минимум десять соседей.
3.3.10. Оптимизация оверлейных сетей TON для уменьшения задержки.
33
Как вариант, абстрактный адрес может храниться в DHT, как описано в 3.2.12.


71 3.3. Оверлейные сети и многоадресные сообщения
Оверлейные сети TON оптимизируют «случайный» сетевой граф, сгенерированный предыдущим методом, следующим образом. Каждый узел пытается сохранить как минимум трех соседей с минимальным периодом кругового обращения, причем этот список «быстрых соседей» очень редко меняется. В то же время у каждого узла есть как минимум три других «медленных соседа», которые выбираются совершенно случайным образом, поэтому граф оверлейной сети всегда будет содержать случайный подграф. Это необходимо для поддержания связи и предотвращения разделения оверлейной сети на несколько несвязанных местных подсетей. Также выбираются и сохраняются как минимум три «промежуточных соседа», которые имеют промежуточный период кругового обращения, ограниченный определенной константой (фактически, функцией периода кругового обращения для быстрых и медленных соседей).
Таким образом, в графе оверлейной сети сохраняется достаточный уровень произвольности подключения, однако он оптимизирован для более низкой задержки и более высокой пропускной способности.
3.3.11. Протоколы сплетен в оверлейной сети. Оверлейные сети часто используются для запуска одного из так называемых протоколов сплетен, которые достигают какой-то глобальной цели, позволяя каждому узлу взаимодействовать только со своими соседями. Например, существуют протоколы сплетен для построения приблизительного списка всех членов (не слишком большой) оверлейной сети или для вычисления оценки числа членов (произвольно большой) оверлейной сети, используя только ограниченное количество памяти на каждом узле (более подробная информация приведена в [15, 4.4.3] или [1]).
3.3.12. Оверлейная сеть как домен широковещательной рассылки. Самый важный протокол сплетен, работающий в оверлейной сети, - это протокол широковещательной передачи, предназначенный для распространения широковещательных сообщений, генерируемых любым узлом сети или одним из назначенных узлов-отправителей, всем другим узлам.
На самом деле существует несколько протоколов широковещательной передачи, оптимизированных для разных случаев применения. Самый простой из них принимает новые широковещательные сообщения и ретранслирует их всем соседям, которые сами еще не отправили копию этого сообщения.
3.3.13. Более сложные протоколы широковещательной передачи. Для некоторых приложений могут потребоваться более сложные протоколы широковещательной передачи. Например, при широковещательной рассылке сообщений большого размера имеет смысл отправлять соседям не само вновь полученное сообщение, а его хэш (или набор хэшей новых сообщений). Соседний узел может запросить само сообщение после изучения ранее невидимого хэша передаваемого сообщения, скажем, с использованием надежного протокола больших датаграмм (RLDP), описанного в п. 3.1.9. Таким образом, новое сообщение будет загружено только от одного соседнего узла.
3.3.14. Проверка возможности подключения оверлейной сети. Связность оверлейной сети можно проверить с использованием известного узла (например,
«владельца» или «создателя» оверлейной сети), который должен находиться в этой оверлейной сети. Затем рассматриваемый узел просто время от времени передает короткие сообщения, содержащие текущее время, порядковый номер и подпись.
Любой другой узел может быть уверен, что он все еще подключен к оверлейной сети, если он недавно получил такое широковещательное сообщение. Этот протокол может быть расширен на нескольких хорошо известных узлов; например, все они будут


72 3.3. Оверлейные сети и многоадресные сообщения отправлять такие широковещательные рассылки, а все остальные узлы будут ожидать широковещательные рассылки от более чем половины хорошо известных узлов.
В случае оверлейной сети, используемой для распространения новых блоков (или только новых заголовков блоков) определенного шардчейна, хороший способ для узла проверить возможность подключения - это отслеживать самый последний полученный блок. Поскольку блок обычно генерируется каждые пять секунд, если новый блок не принимается в течение, скажем, тридцати секунд, то узел, вероятно, был отключен от оверлейной сети.
3.3.15. Протокол потоковой трансляции. Существует протокол потоковой трансляции для оверлейных сетей TON, который используется, например, для распространения блоков-кандидатов среди валидаторов некоторого шардчейна
(«группа задач шардчейна»), которые, конечно же, создают для этой цели частную оверлейную сеть. Тот же протокол можно использовать для распространения новых блоков шардчейна на все полные ноды этого шардчейна.
Этот протокол уже был описан в 2.6.10: новое (большое) широковещательное сообщение разбивается, скажем, на N блоков по одному килобайту; последовательность этих фрагментов увеличивается до M

N фрагментов с помощью стирающего кода, такого как код Рида-Соломона или исходный код
(например, код RaptorQ [9] [14]), и эти M фрагментов передаются всем соседям в порядке возрастания номеров блоков. Участвующие узлы собирают эти фрагменты до тех пор, пока они не смогут восстановить исходное большое сообщение (для этого необходимо успешно получить не менее N фрагментов), а затем проинструктировать своих соседей прекратить отправку новых фрагментов потока, потому что теперь эти узлы могут генерировать последующие блоки самостоятельно, имея копию исходного сообщения. Такие узлы продолжают генерировать последующие фрагменты потока и отправлять их своим соседям, если соседи, в свою очередь, не укажут, что в этом больше нет необходимости.
Таким образом, узлу не нужно полностью загружать большое сообщение перед его дальнейшим распространением. Это позволяет минимизировать задержку потоковой трансляции, особенно в сочетании с оптимизацией, описанной в 3.3.10.
1   ...   9   10   11   12   13   14   15   16   17