Сеть, хранилище TON, сервисы TON

Сравнение с другими Блокчейн-проектами
Серверы Facebook на их дисках будут храниться на дисках всех валидаторов
для соответствующей цепочки сегментов (т.е. не менее чем в двадцати копиях).
Поскольку валидаторы по сути те же сервера (или, возможно, кластеры серверов, но это совсем не ест обоснованность этого аргумента), как и те,
в настоящее время используют Facebook, мы видим, что общие расходы, связанные с оборудованием работающем Facebook в блокчейн, как минимум, в двадцать раз выше
чем если бы оно было реализовано обычным способом.
На самом деле, затраты были бы еще намного выше, потому
что виртуальная машина блокчейна работает медленнее, чем простой процессор, на котором работает оптимизированный скомпилированный
код, а ее хранилище не оптимизировано для проблем, специфичных для Facebook. Можно было
бы частично смягчить эту проблему, создав специальную рабочую цепочку с
некоторыми специальными транзакциями, адаптированными для Facebook; это подход
BitShares и EOS к достижению высокой производительности, доступный в ТОННЕ
И блокчейн тоже. Однако общий дизайн блокчейна все равно сам по себе накладывал бы некоторые дополнительные ограничения, такие как необходимость регистрации
все операции как транзакции в блоке, чтобы организовать эти транзакции в
Дерево Меркла, для вычисления и проверки их хэшей Меркла, для дальнейшего распространения этого
блока и так далее.
Таким образом, по самым скромным оценкам,
для проверки блокчейн-проекта, в котором размещается социальная сеть такого масштаба, потребуется в 100 раз больше серверов той же производительности, что и те, которые сейчас используются Facebook
. Кому-то придется заплатить за эти серверы, либо компании, владеющей распределенным приложением (представьте, что вместо этого вы видите 700 объявлений на каждой странице Facebook
из 7) или его пользователей. В любом случае, это не представляется экономически целесообразным.
Мы считаем, что это неправда, что все должно быть загружено в
блокчейн. Например, нет необходимости хранить фотографии пользователей в
блокчейне; было бы лучше зарегистрировать хэши этих фотографий в блокчейне и
хранить фотографии в распределенном хранилище o -chain (таком как хранилище FileCoin
или TON). Именно по этой причине TON - это не
просто блокчейн-проект, а набор из нескольких компонентов (TON P2P
Сеть, хранилище TON, сервисы TON) сосредоточены вокруг блокчейна TON,
как описано в главах 1 и 4.
79
3.1. Абстрактный Сетевой уровень дейтаграмм
3-ТОННАЯ сеть
Любой блокчейн-проект требует не только определения формата блока и правил
проверки блокчейна, но и сетевого протокола, используемого для распространения
новых блоков, отправки и сбора кандидатов на транзакции и так далее. Другими
словами, в каждом блокчейн-проекте должна быть создана специализированная одноранговая сеть
. Эта сеть должна быть одноранговой, потому что блокчейн-проекты
обычно ожидается децентрализация, поэтому нельзя полагаться на централизованную
группу серверов и использовать обычную архитектуру клиент-сервер, как, например, в классических приложениях онлайн-банкинга. Даже легкие клиенты (например,
приложения для смартфонов с криптовалютным кошельком light), которые должны подключаться к полным
узлам по принципу клиент-сервер, на самом деле могут свободно подключаться к другому
полному узлу, если их предыдущий одноранговый узел выходит из строя, при условии, что протокол, используемый для
подключения к полным узлам, достаточно стандартизирован.
В то время как требования к сетевой инфраструктуре из одного блокчейн-проектов, таких как Bitcoin или Эфириума, может быть довольно легко (одним, по сути, должен построить
случайный одноранговых оверлейных сетей, и распространяют все новые блоки и
кандидаты сделки протокола сплетни), мульти-блокчейн проектов, таких
как тонна блокчейн, гораздо более жесткими (например, человек должен быть способен
подписаться на обновления лишь некоторые shardchains, не обязательно все из них).
Поэтому сетевая часть блокчейна TON и проект TON
в целом заслуживают хотя бы краткого обсуждения.
С другой стороны, как только будут созданы более сложные сетевые протоколы, необходимые
для поддержки блокчейна TON, выяснится, что их можно легко
использовать для целей, не обязательно связанных с непосредственными потребностями блокчейна
TON, тем самым предоставляя больше возможностей и гибкости для создания
новых услуг в экосистеме TON.
3.1 Абстрактный Сетевой уровень дейтаграмм
Краеугольным камнем в построении сетевых протоколов TON является (TON)
Абстрактный (дейтаграмм) Сетевой уровень. Это позволяет всем узлам предполагать определенные
сетевые идентификаторы, представленные 256-битными абстрактными сетевыми адресами, и
обмениваются данными (отправляют друг другу дейтаграммы в качестве первого шага), используя только эти
256-разрядные сетевые адреса для идентификации отправителя и получателя. В частности, не нужно беспокоиться об адресах IPv4 или IPv6,
номерах портов UDP и тому подобном; они скрыты Абстрактным сетевым уровнем.
80
3.1. Абстрактный Сетевой уровень дейтаграмм
3.1.1. Абстрактные сетевые адреса. Абстрактный сетевой адрес, или
абстрактный адрес, или просто адрес для краткости, представляет собой 256-битное целое число, по сути
равен 256-битному открытому ключу ECC. Этот открытый ключ может быть сгенерирован произвольно, создавая таким образом столько различных сетевых идентификаторов, сколько пожелает узел.
Однако необходимо знать соответствующий закрытый ключ, чтобы получать
(и расшифровывать) сообщения, предназначенные для такого адреса.
Фактически, адрес не является самим открытым ключом; вместо этого это 256-битный
хэш (хэш = sha256) сериализованного TL-объекта (см. 2.2.5), который может описывать
несколько типов открытых ключей и адресов в зависимости от его конструктора (первые
четыре байта). В простейшем случае этот сериализованный TL-объект состоит только из
4-байтовое магическое число и 256-битный открытый ключ криптографии с эллиптической кривой (ECC)
; в этом случае адрес будет равен хэшу этой 36-байтовой структуры.
Однако вместо этого можно использовать 2048-битные ключи RSA или любую другую схему криптографии с открытым ключом.
Когда узел узнает абстрактный адрес другого узла, он также должен получить
его прообраз (т.Е. сериализованный TL-объект, хэш которого равен этому
абстрактному адресу), иначе он не сможет зашифровать и отправить дейтаграммы
на этот адрес.
3.1.2. Сети более низкого уровня. Реализация UDP. С точки зрения почти всех сетевых компонентов TON, единственное, что
существует, - это сеть (сетевой уровень абстрактных дейтаграмм), способная (ненадежно) отправлять дейтаграммы с одного абстрактного адреса на другой. В принципе, сетевой
уровень абстрактных дейтаграмм (ADNL) может быть реализован с использованием
различных существующих сетевых технологий. Тем не менее, мы собираемся реализовать
его через UDP в сетях IPv4 / IPv6 (таких как Интернет или интрасети) с
дополнительным резервным вариантом TCP, если UDP недоступен.
3.1.3. Простейший случай ADNL над UDP. Простейший случай отправки
дейтаграммы с абстрактного адреса отправителя на любой другой абстрактный адрес
(с известным прообразом) может быть реализован следующим образом.
Предположим, что отправитель каким-то образом знает IP-адрес и UDP-
порт получателя, которому принадлежит абстрактный адрес назначения, и что
как получатель, так и отправитель используют абстрактные адреса, полученные из 256-разрядного
Открытые ключи ECC.