публикация открытого ключа в блокчейне TON

Когда какой-либо узел хочет найти значение ключа K, он сначала создает
набор S из s
0 узлов (для некоторого небольшого значения s
0
, скажем, s
0 = 5), ближайший к K по
отношению к расстоянию Кадемлии среди всех известных узлов (т. е. они
взяты из таблицы маршрутизации Кадемлии). Затем каждому
из них отправляется запрос Find_Value, и узлы, упомянутые в их ответах, включаются в S.
Затем s
0 узлов из S, ближайших к K, также отправляются запрос Find_Value
, если это не было сделано ранее, и процесс продолжается до тех пор, пока значение не будет
найдено, или набор S перестанет расти. Это своего рода поиск луча узла,
ближайшего к K по отношению к расстоянию Кадемлии.
Если необходимо установить значение некоторого ключа K, то та же процедура выполняется для s

0 ≥ s, с запросами find_node вместо Find_Value, чтобы найти s ближайших
узлов к K. После этого всем им отправляются запросы на хранение.
Есть некоторые менее важные детали в реализации DHT, подобного Kademli (например, любой узел должен искать ближайшие к себе узлы, скажем,
раз в час, и повторно публиковать все сохраненные ключи к ним с помощью хранилища
запросы). Мы будем игнорировать их до поры до времени.
3.2.8. Загрузка узла Kademlia. Когда узел Kademlia подключается к сети,
он сначала заполняет свою таблицу маршрутизации Kademlia, просматривая свой собственный адрес.
Во время этого процесса он идентифицирует ближайшие к себе узлы. Он может загружать
из них все известные им пары (ключ, значение) для заполнения своей части
DHT.
3.2.9. Хранение значений в тоннах DHT. Хранение значений в тонне DHT
немного отличается от общего DHT, подобного Кадемлии. Когда кто-то хочет
сохранить значение, он должен предоставить в Хранилище не только сам ключ K
запрос, но также и его прообраз, т. е. TL-сериализованная строка (с одним из нескольких
предопределенных TL-конструкторов в начале), содержащая описание
ключа. Это описание ключа позже сохраняется узлом вместе с ключом
и значением.
87
3.2. ТОННА DHT: Распределенная хэш-таблица, подобная Kademlia
Описание ключа описывает тип сохраняемого объекта, его
владельца и правила его обновления в случае будущих обновлений. Владелец
обычно идентифицируется по открытому ключу, включенному в описание ключа. Если это так
включено, обычно принимаются только обновления, подписанные соответствующим закрытым ключом.
Тип хранимого объекта обычно представляет собой просто строку байтов.
Однако в некоторых случаях он может быть более сложным, например,
описание входного туннеля (см. 3.1.6) или набор адресов узлов.
Правила обновления также могут быть различными. В некоторых случаях они просто
позволяют заменить старое значение новым значением при условии, что новое значение
подписано владельцем (подпись должна быть сохранена как часть значения, чтобы позже ее
проверяли любые другие узлы после того, как они получат значение этого ключа).
В других случаях старое значение каким-то образом влияет на новое значение. Например, он
может содержать порядковый номер, и старое значение перезаписывается только в том случае, если
новый порядковый номер больше (для предотвращения повторных атак).
3.2.10. Распространяемые торрент-трекеры и сетевые группы по интересам
в TON DHT. Еще один интересный случай, когда значение содержит
список узлов, возможно, с их IP-адресами и портами или просто с их
абстрактными адресами, и правило обновления состоит в том, чтобы включить запрашивающую
в этот список, при условии, что она может подтвердить свою личность.
Этот механизм может быть использован для создания распределенного торрент-трекера,
где все узлы, заинтересованные в определенном торренте (т. Е. в определенном файле), могут найти
другие узлы, которые заинтересованы в том же торренте или уже имеют копию.
Хранилище TON (см. 4.1.7) использует эту технологию для поиска узлов, у которых есть
копия требуемого файла (например, снимок состояния цепочки сегментов или
старого блока). Однако его более важное применение заключается в создании многоадресных
подсетей с наложением и сетевых групп интересов (см. 3.3). Идея состоит в том, что только
некоторые узлы заинтересованы в обновлениях определенной цепочки сегментов. Если
количество цепочек сегментов становится очень большим, поиск даже одного узла, заинтересованного в одном и
том же сегменте, может усложниться. Этот распределенный торрент-трекер
предоставляет удобный способ найти некоторые из этих узлов. Другим вариантом было
бы запросить их у валидатора, но это не будет масштабируемым
подходом, и валидаторы могут решить не отвечать на такие запросы, поступающие
от произвольных неизвестных узлов.
3.2.11. Резервные ключи. Большинство ключевых типов, описанных до сих пор, имеют
дополнительное 32-разрядное целое поле в их описании TL, обычно равное нулю.
Однако, если ключ, полученный путем хеширования этого описания, не может быть извлечен
или обновлен в TON DHT, значение в этом поле увеличивается, и
88
3.2. ТОННА DHT: Распределенная хэш-таблица, подобная Kademlia, предпринята
новая попытка. Таким образом, невозможно захватить и подвергнуть цензуре
ключ (т. Е. Выполнить атаку на удержание ключа), создав множество абстрактных
адресов, расположенных рядом с атакуемым ключом, и контролируя соответствующие
Узлы DHT.
3.2.12. Службы определения местоположения. Некоторые сервисы, расположенные в сети TON
и доступные через (протоколы более высокого уровня, построенные на) TON ADNL,
описанные в 3.1, могут захотеть опубликовать свои абстрактные адреса где-нибудь,
чтобы их клиенты знали, где их найти.
Однако публикация абстрактного адреса сервиса в блокчейне TON
может быть не лучшим подходом, потому что абстрактный адрес может потребоваться
довольно часто менять, и потому что может иметь смысл предоставить несколько
адресов для целей надежности или балансировки нагрузки.
Альтернативой является публикация открытого ключа в блокчейне TON, и
используйте специальный ключ DHT, указывающий, что этот открытый ключ является его владельцем в
строке описания TL (см. 2.2.5), чтобы опубликовать обновленный список
абстрактных адресов службы. Это один из подходов, используемых службами TON.
3.2.13. Поиск владельцев блокчейн-аккаунтов TON. В большинстве случаев
владельцы блокчейн-аккаунтов TON не хотели бы, чтобы их ассоциировали с
абстрактными сетевыми адресами, и особенно IP-адресами, потому что это может
нарушить их конфиденциальность. Однако в некоторых случаях владелец блокчейн-
аккаунта TON может захотеть опубликовать один или несколько абстрактных адресов, где она
можно было бы связаться.
Типичным случаем является узел в сети TON Payments lightning
(см. 5.2), платформе для мгновенных переводов криптовалют. Публичная ТОННА
Узел платежей может захотеть не только установить платежные каналы с другими
одноранговыми узлами, но и опубликовать абстрактный сетевой адрес, который можно было бы использовать
для связи с ним позже для передачи платежей по уже установленным каналам.
Одним из вариантов было бы включить абстрактный сетевой адрес в смарт-
контракт, создающий канал оплаты. Более гибкий вариант состоит в том, чтобы включить
открытый ключ в смарт-контракте, а затем используйте DHT, как описано в 3.2.12.
Наиболее естественным способом было бы использовать тот же закрытый ключ, который управляет учетной записью в блокчейне TON, для подписания и публикации обновлений в
TON DHT об абстрактных адресах, связанных с этой учетной записью. Это
делается почти так же, как описано в 3.2.12; однако
используемый ключ DHT потребует специального описания ключа, содержащего только