Открытая сеть. Открытая сеть по материалам работы дра Николая Дурова 26 июля 2021
 Скачать 0.79 Mb.
|
|
256-битные сетевые адреса для идентификации отправителя и получателя. В частности, не нужно беспокоиться об адресах IPv4 или IPv6, номерах портов UDP и тому подобном; они скрыты Абстрактным сетевым уровнем. 80 3.1. Абстрактный сетевой уровень дейтаграмм 3.1.1. Абстрактные сетевые адреса. Абстрактный сетевой адрес, или абстрактный адрес, или просто адрес для краткости, представляет собой 256-битное целое число, по существу равное 256-битному открытому ключу ECC. Этот открытый ключ может быть сгенерирован произвольно, создавая таким образом столько различных сетевых идентификаторов, сколько захочет узел. Однако для получения (и расшифровки) сообщений, предназначенных для такого адреса, необходимо знать соответствующий закрытый ключ. Фактически, адрес не является самим открытым ключом; вместо этого он представляет собой 256-битный хэш (Hash = sha256) сериализованного TL-объекта (см. 2.2.5), который может описывать несколько типов открытых ключей и адресов в зависимости от его конструктора (первые четыре байта). В простейшем случае этот сериализованный TL-объект состоит только из 4-байтового магического числа и 256-битного открытого ключа криптографии эллиптической кривой (ECC) ; в этом случае адрес будет равен хэшу этой 36-байтовой структуры. Однако можно использовать 2048-битный RSAключи или любая другая схема криптографии publickey вместо этого. Когда узел узнает абстрактный адрес другого узла, он также должен получить свой прообраз (т. Е. сериализованный TL-объект, хэш которого равен этому абстрактному адресу), иначе он не сможет шифровать и отправлять дейтаграммы на этот адрес. 3.1.2. Сети нижнего уровня. Реализация UDP. С точки зрения почти всех сетевых компонентов TON, единственное, что существует, - это сеть (абстрактный сетевой уровень дейтаграмм), способная (ненадежно) отправлять дейтаграммы с одного абстрактного адреса на другой. В принципе, абстрактный сетевой уровень дейтаграмм (ADNL) может быть реализован поверх различных существующих сетевых технологий. Тем не менее, мы собираемся реализовать его через UDP в сетях IPv4/IPv6 (таких как Интернет или интрасети), с дополнительным резервом TCP, если UDP недоступен. 3.1.3. Простейший случай ADNL по UDP. Простейший случай отправки дейтаграммы с абстрактного адреса отправителя на любой другой абстрактный адрес (с известным прообразом) может быть реализован следующим образом. Предположим, что отправитель каким-то образом знает IP-адрес и UDP -порт получателя, которому принадлежит абстрактный адрес назначения, и что и получатель, и отправитель используют абстрактные адреса, полученные из 256-битных открытых ключей ECC. В этом случае отправитель просто дополняет отправляемую дейтаграмму своей подписью ECC (сделанной с помощью закрытого ключа) и адресом источника (или прообразом адреса источника, если получатель, как известно, этого не знает 81 3.1. Абстрактный сетевой уровень дейтаграмм прообраза пока нет). Результат шифруется открытым ключом получателя, встраивается в UDP - дейтаграмму и отправляется на известный IP и порт получателя. Поскольку первые 256 бит UDP-дейтаграммы содержат абстрактный адрес получателя, получатель может определить, какой закрытый ключ следует использовать для расшифровки оставшейся части дейтаграммы. Только после этого раскрывается личность отправителя. 3.1.4. Менее безопасный способ, с адресом отправителя в открытом виде. Иногда бывает достаточно менее безопасной схемы, когда адреса получателя и отправителя хранятся в виде открытого текста в UDP-дейтаграмме; закрытый ключ отправителя и открытый ключ получателя объединяются вместе с помощью ECDH (Elliptic Curve Di e Hellman) для генерации 256-битного общего секрета, которыйиспользуется впоследствии вместе со случайным 256-битным nonce, также включенным в незашифрованную часть, для получения ключей AES, используемых для шифрования. Целостность может быть обеспечивается, например, путем объединения хэша исходных данных открытого текста с открытым текстом перед шифрованием. Этот подход имеет то преимущество, что если ожидается обмен более чем одной дейтаграммой между двумя адресами, общий секрет может быть вычислен только один раз и затем кэширован; тогда более медленные операции эллиптической кривой больше не потребуются для шифрования или дешифрования следующих дейтаграмм. 3.1.5. Каналы и идентификаторы каналов. В простейшем случае первые 256 бит UDP-дейтаграммы, несущей встроенную TON ADNL-дейтаграмму , будут равны адресу получателя. Однако в целом они представляют собой идентификатор канала. Существуют различные типы каналов. Некоторые из них являются двухточечными; они создаются двумя сторонами, которые хотят обмениваться большим количеством данных в будущем и генерировать общий секрет, обмениваясь несколькими пакетами, зашифрованными, как описано в 3.1.3 или 3.1.4, путем запуска классических или эллиптическая кривая Di e Hellman (если требуется дополнительная безопасность) или просто одна сторона генерирует случайный общий секрет и отправляет его другой стороне. После этого идентификатор канала получается из общего секрета в сочетании с некоторыми дополнительными данными (такими как адреса отправителя и получателя), например,путем хеширования, и этот идентификатор используется в качестве первых 256 бит UDP-дейтаграмм, несущих данные, зашифрованные с помощью этого общего секрета. 3.1.6. Канал как идентификатор туннеля. В общем случае канал или идентификатор канала просто выбирает способ обработки входящей UDP-дейтаграммы, известный получателю. Если канал является абстрактным адресом получателя, обработка выполняется в соответствии с п. 3.1.3 или 3.1.4; если канал является установленным адресом получателя, то обработка выполняется в соответствии с п. 3.1.3 или 3.1.4.- 82 3.1. Абстрактный сетевой уровень дейтаграмм lished point-to-point channel обсуждается в 3.1.5, обработка заключается в расшифровке дейтаграммы с помощью общего секрета, как описано в loc. cit., и так далее. В частности, идентификатор канала может фактически выбрать туннель, когда непосредственный получатель просто пересылает полученное сообщение кому -то другому фактическому получателю или другому прокси-серверу. Некоторые шаги шифрования или дешифрования (напоминающие маршрутизацию лука [6] или даже маршрутизацию чеснока 31 ) может быть сделано по пути, и другой идентификатор канала может быть использован для повторно зашифрованных пересылаемых пакетов (например, одноранговый канал может быть использован для пересылки пакета следующему получателю на пути). Таким образом, некоторая поддержка туннелирования и проксирования несколько упрощается- ilar к тому, что предоставлено TOR или I 2 P проекты могут быть добавлены на уровне сетевого уровня абстрактных дейтаграмм TON, не влияя на функциональность всех сетевых протоколов TON более высокого уровня, что было бы агностиком такого добавления. Эта возможность используется прокси - сервисом TON (см. 4.1.10). 3.1.7. Нулевой канал и проблема начальной загрузки. Обычно узел TON ADNL будет иметь некоторую соседнюю таблицу, содержащую информацию о других известных узлах , таких как их абстрактные адреса и их прообразы (т. Е. Открытые ключи), а также их IP-адреса и UDP-порты. Затем он будет постепенно расширять эту таблицу, используя информацию, полученную от этих известных узлов, в качестве ответов на специальные запросы, а иногда и удалять устаревшие записи. Однако, когда узел TON ADNL только запускается, может случиться так, что он не знает никакого другого узла и может узнать только IP-адрес и UDP -порт узла, но не его абстрактный адрес. Это происходит, например, если клиент light не может получить доступ к любому из ранее кэшированных узлов и любых узлов, жестко закодированных в программное обеспечение, и должен попросить пользователя ввести IP -адрес или DNS-домен узла, который будет разрешен через DNS. В этом случае узел будет посылать пакеты в специальный нулевой канал рассматриваемого узла. Это не требует знания открытого ключа получателя (но сообщение все равно должно содержать личность и подпись отправителя), поэтому сообщение передается без шифрования. Обычно он должен использоваться только для получения личности (возможно, одноразовой личности, созданной специально для этой цели) получателя, а затем для начала общения более безопасным способом. Как только известен хотя бы один узел, легко заполнить соседнюю таблицу и таблицу маршрутизации большим количеством записей, изучая их из ответов на 31 https://geti2p.net/en/docs/how/garlic-routing 83 3.2. TON DHT: Kademlia-подобная распределенная хэш-таблица специальные запросы отправляются на уже известные узлы. Не все узлы должны обрабатывать дейтаграммы,отправленные в нулевой канал, но те, которые используются для начальной загрузки легких клиентов, должны поддерживать эту функцию. 3.1.8. TCP-подобный потоковый протокол через ADNL. ADNL, являясь ненадежным (малогабаритным) протоколом дейтаграмм, основанным на 256-битных абстрактных адресах, может использоваться в качестве основы для более сложных сетевых протоколов. Можно построить, например, TCP-подобный потоковый протокол, используя ADNL в качестве абстрактной замены IP. Однако большинству компонентов проекта TON такой потоковый протокол не нужен. 3.1.9. RLDP, или надежный протокол больших дейтаграмм через ADNL. Вместо TCP-подобного протокола используется надежный протокол дейтаграмм произвольного размера, построенный на ADNL, называемый RLDP . Этот надежный протокол дейтаграмм может использоваться, например, для отправки RPC - запросов удаленным хостам и получения от них ответов (см. 4.1.5). 3.2 TON DHT: Kademlia-подобная распределенная хэш-таблица Распределенная хэш - таблица TON (DHT) играет решающую роль в сетевой части проекта TON, используется для поиска других узлов в сети. Например, клиент, желающий зафиксировать транзакцию в цепочке сегментов, может захотеть найти валидатор или сортировщик этой цепочки сегментов или, по крайней мере, какой-то узел, который может передать транзакцию клиента в collator. Это можно сделать, посмотрев специальный ключ в TON DHT. Еще одно важное применение DHT TON заключается в том, что его можно использовать для быстрого заполнения таблицы соседей нового узла (см. 3.1.7), просто посмотрев случайный ключ или адрес нового узла. Если узел использует проксирование и туннелирование для входящих дейтаграмм, он публикует идентификатор туннеля и его точку входа (например, IP-адрес и UDP-порт) в DHT TON; тогда все узлы, желающие отправить дейтаграммы этому узлу, сначала получат эту контактную информацию из DHT TON DHT является членом семейства распределенных хэш-таблиц, подобных Kademlia [10]. 3.2.1. Ключи ТОННЫ DHT. Ключи TON DHT-это просто 256-битные целые числа. В большинстве случаев они вычисляются как sha256 TL- сериализованного объекта (см. 2.2.5), называемого прообразом ключа или описанием ключа. В некоторых случаях абстрактные адреса узлов сети TON (см. 3.1.1) также могут 84 3.2. TON DHT: Kademlia-подобная распределенная хэш-таблица можно использовать в качестве ключей TON DHT, потому что они также 256-битные, и они также являются хэшами TL-сериализованных объектов. Например, если узел не боится публиковать свой IP-адрес, его может найти любой, кто знает его абстрактный адрес, просто посмотрев этот адрес как ключ в DHT. 3.2.2. Значения ДГТ. Значения, присвоенные этим 256-битным ключам , по существу являются произвольными байтовыми строками ограниченной длины. Интерпретация таких байтовых строк определяется прообразом соответствующего ключа; он обычно известен как узлу, который ищет ключ, так и узлу , который хранит ключ. 3.2.3. Узлы DHT. Полупостоянные сетевые идентификаторы. Отображение ключ-значение DHT TON хранится на узлах DHT по существу, всех членов сети TON. С этой целью любой узел Сети TON (возможно, за исключением некоторых очень легких узлов), помимо любого количества эфемерных и постоянных абстрактных адресов, описанных в 3.1.1, имеет по крайней мере один полупостоянный адрес, который идентифицирует его как член DHT TON. Этот полупостоянный или DHT-адрес не следует менять слишком часто, иначе другие узлы не смогут найти ключи, которые они ищут. Если узел не хочет раскрывать свою истинную идентичность, он генерирует отдельный абстрактный адрес, который будет использоваться только для участия в DHT. Однако этот абстрактный адрес должен быть общедоступным, поскольку он будет связан с IP-адресом и портом узла. 3.2.4. Расстояние Кадемлия. Теперь у нас есть как 256-битные ключи, так и 256-битные (полупостоянные) адреса узлов. Мы вводим так называемое расстояние XOR или расстояние Kademlia d K на множестве 256-битных последовательностей, заданных d K (x, y) := (x ⊕ y) интерпретируется как 256-битное целое число без знака (25) Здесь x ⊕ y обозначает побитовое исключение ИЛИ (XOR) двух битовых последовательностей одинаковой длины. Расстояние Кадемлия вводит метрику на множестве 2 256 из всех 256-битных последовательности. В частности, мы имеем d K (x, y) = 0 тогда и только тогда, когда x = y, d K (x, y) = d K (y, x) , и d K (x, z)≤ d K (x, y)+ d K (y, z) . Еще одним важным свойством является что существует только одна точка на любом заданном расстоянии от x: d K (x, y)= d K (x, y) подразумевает y = y . 3.2.5. Кадемлийские ДХТ и ТОНСКИЕ ДХТ. Мы говорим, что распределенная хэш-таблица (DHT) с 256-битными ключами и 256-битными адресами узлов является 85 3.2. TON DHT: Kademlia-подобная распределенная хэш-таблица Kademlia-как DHT, если ожидается, что значение ключа K на s Kademlianearest узлах будет равно K (т. Е. s узлов с наименьшим расстоянием Kademlia от их адресов до K.) Здесь s-небольшой параметр, скажем, s = 7, необходимый для повышения надежности DHT (если бы мы держали ключ только на одном узле, ближайшем к K, значение этого ключа было бы потеряно, если бы этот единственный узел вышел из строя). Согласно этому определению, ТОН ДГТ является кадемлиеподобным ДГТ. Он реализован по протоколу ADNL, описанному в 3.1. 3.2.6. Таблица маршрутизации Kademlia. Любой узел, участвующий в DHT, подобном Kademli, обычно поддерживает таблицу маршрутизации Kademlia. В случае ТОННЫ DHT он состоит из n = 256 ведер, пронумерованных от 0 до n - 1. I-й блок будет содержать информацию о некоторых известных узлах (фиксированное число t лучших узлов и, возможно, некоторые дополнительные кандидаты), которые лежат на расстоянии Кадемлии от 2 i до 2 i + 1 - 1 с адреса узла a. 32 Эта информация включает их (полупостоянные) адреса, IP-адреса и порты UDP, а также некоторую информацию о доступности, такую как время и задержка последнего пинга. Когда узел Kademlia узнает о любом другом узле Kademlia в результате некоторого запроса, он включает его в подходящее ведро своей таблицы маршрутизации, сначала в качестве кандидата. Затем, если некоторые из лучших узлов в этом ведре терпят неудачу (например, не отвечают на запросы ping в течение длительного времени), они могут быть заменены некоторыми кандидатами. Таким образом, таблица маршрутизации Kademlia остается заполненной. Новые узлы из таблицы маршрутизации Kademlia также включаются в таблицу соседей ADNL, описанную в 3.1.7. Если часто используется лучший узел из ведра таблицы маршрутизации Kademlia , для облегчения шифрования дейтаграмм может быть установлен канал в смысле, описанном в 3.1.5. Особенностью TON DHT является то, что он пытается выбрать узлы с наименьшими задержками в оба конца в качестве лучших узлов для ведер таблицы маршрутизации Kademlia. 3.2.7. (Сетевые запросы Kademlia.) Узел Kademlia обычно поддерживает следующие сетевые запросы: ˆ Ping проверяет доступность узла. 32 Если в ведре достаточно много узлов, оно может быть далее разделено, скажем, на восемь суб-ведер в зависимости от верхних четырех битов расстояния Кадемлия. Это ускорит поиск DHT. 86 3.2. TON DHT: Kademlia-подобная распределенная хэш-таблица ˆ Store (key, value) Запрашивает у узла сохранение значения в качестве значения для ключа key . Для TON DHT запросы магазина немного сложнее (ср. 3.2.9). ˆ Find_Node (key, l) Запрашивает у узла возврат l Kademlia-ближайших известных узлов (из таблицы маршрутизации Kademlia) в key. ˆ Find_Value(key, l) То же самое, что и выше, но если узел знает значение, соответствующее ключу key, он просто возвращает это значение. Когда любой узел хочет найти значение ключа K, он сначала создает набор S узлов s (для некоторого небольшого значения s, скажем, s = 5), ближайших к K по отношению к расстоянию Кадемлии среди всех известных узлов (т. Е. Они берутся из Кадемлиитаблица маршрутизации). Затем каждому из них отправляется запрос Find_Value , и узлы, упомянутые в их ответах, включаются в S. Затем s-узлам из S, ближайшим к K, также отправляется запрос Find_Value, если это не было сделано ранее, и процесс продолжается до тех пор, пока значение не будет найдено или набор S не остановитсярастет. Это своего рода лучевой поиск ближайшего к K узла по отношению к расстоянию Кадемлия. Если необходимо установить значение некоторого ключа K, то та же процедура выполняется для s ≥ s , с запросами Find_Node вместо Find_Value, чтобы найти s ближайший узлы К. После этого всем им отправляются запросы к хранилищу. Есть некоторые менее важные детали в реализации Kademlialike DHT (например, любой узел должен искать s ближайших узлов к себе, скажем, раз в час, и повторно публиковать все сохраненные ключи к ним с помощью запросов хранилища). Мы будем игнорировать их до поры до времени. 3.2.8. Загрузка узла Kademlia. Когда узел Kademlia выходит в интернет, он сначала заполняет свою таблицу маршрутизации Kademlia, ища свой собственный адрес. Во время этого процесса он идентифицирует ближайшие к себе узлы. Он может загрузить из них все известные им пары (ключ, значение), чтобы заполнить свою часть DHT. 3.2.9. Хранение значений в тоннах DHT. Хранение значений в TON DHT немного отличается от общего DHT, подобного Kademlia. Если кто-то хочет сохранить значение, он должен предоставить в запрос хранилища не только сам ключ K |