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

59 2.9. Сравнение с другими блокчейн-проектами
Однако это не похоже на способ достигнуть истинной масштабируемости общего назначения.
2.9.11. Специализированные блокчейн-проекты. Существуют также некоторые специализированные блокчейн-проекты, такие как FileCoin (система, которая стимулирует пользователей предлагать свое дисковое пространство для хранения файлов других пользователей, которые готовы за это платить), Golem (платформа на основе блокчейна для аренды и предоставления вычислительной мощности для специализированных приложений, таких как 3D-рендеринг) или SONM (еще один аналогичный проект по предоставлению вычислительной мощности). Такие проекты не привносят ничего концептуально нового на уровне организации блокчейна; скорее, это конкретные приложения блокчейна, которые могут быть реализованы с помощью смарт-контрактов, работающих в блокчейне общего назначения, при условии, что он может обеспечить требуемую производительность.
Таким образом, проекты такого типа, вероятно, будут использовать в качестве своей основы один из существующих или планируемых блокчейн-проектов, например EOS,
PolkaDot или TON. Если проекту нужна «настоящая» масштабируемость (на основе шардинга), лучше использовать TON; если проекту подходит функционирование в контексте «конфедерации» посредством определения семейства собственных воркчейнов, явно оптимизированных для его целей, он может выбрать EOS или
PolkaDot.
2.9.12. Блокчейн TON. Блокчейн TON (The Open Network) (планируется в 2018 г.) - это проект, который мы описываем в данном документе. Он разработан как первый блокчейн-проект пятого поколения, то есть BFT PoS-мультичейн, смешанный гомогенный/гетерогенный, с поддержкой (шардируемых) настраиваемых воркчейнов, с нативной поддержкой шардинга и тесно-связанный блокчейн-проект (в частности, способный пересылать сообщения между шардами почти мгновенно, сохраняя при этом непротиворечивое состояние всех шардчейнов). Таким образом, это действительно масштабируемый блокчейн-проект общего назначения, способный вместить практически любые приложения, которые вообще могут быть реализованы в блокчейне. При добавлении других компонентов проекта TON его возможности расширяются еще больше.
2.9.13. Возможно ли «загрузить Facebook в блокчейн»? Иногда люди утверждают, что можно будет реализовать социальную сеть в масштабе Facebook как распределенное приложение, размещенное в блокчейне. Обычно в качестве возможного «хоста» для такого приложения указывается любимый блокчейн-проект.
Нельзя сказать, что это технически невозможно. Конечно, нужен тесно-связанный блокчейн-проект с настоящим шардингом (например, TON), чтобы такое большое приложение не работало слишком медленно (например, доставляло сообщения и обновления от пользователей, находящихся в одном шардчейне, их друзьям, находящимся в другом, с приемлемой задержкой). Однако мы думаем, что нет необходимости это делать и что это никогда не будет сделано, потому что цена будет непомерно высокой.
Давайте рассмотрим «загрузку Facebook в блокчейн» как мысленный эксперимент; примером может служить любой другой проект подобного масштаба. После загрузки
Facebook в блокчейн все операции, выполняемые в настоящее время серверами
Facebook, будут сериализированы как транзакции в определенных блокчейнах
(например, в шардчейнах TON) и будут выполняться всеми валидаторами этих блокчейнов. Каждую операцию нужно будет выполнить, скажем, не менее двадцати раз, если мы ожидаем, что каждый блок соберет не менее двадцати подписей валидатора (мгновенно или со временем, как в системах DPOS). Точно так же все

60 2.9. Сравнение с другими блокчейн-проектами данные, которые серверы Facebook хранят на своих дисках, будут храниться на дисках всех валидаторов для соответствующего шардчейна (то есть как минимум в двадцати копиях).
Поскольку валидаторы по сути являются теми же серверами (или, скорее, кластерами серверов, но это не влияет на достоверность этого аргумента), что и те, которые в настоящее время используются Facebook, мы видим, что общие затраты на оборудование, связанные с запуском Facebook в блокчейне, как минимум в двадцать раз больше, чем если бы это было реализовано обычным способом.
Фактически, расходы будут еще намного более высокими, потому что виртуальная машина блокчейна работает медленнее, чем "голый процессор", на котором работает оптимизированный скомпилированный код, а ее хранилище не оптимизировано для конкретных проблем Facebook. Можно частично смягчить эту проблему, создав специфический воркчейн с некими специальными транзакциями, адаптированными для Facebook; это подход BitShares и EOS к достижению высокой производительности, также доступный в блокчейне TON. Однако общий дизайн блокчейна сам по себе налагает некоторые дополнительные ограничения, такие как необходимость регистрировать все операции как транзакции в блоке, организовывать эти транзакции в дереве Меркла, вычислять и проверять их хэши Меркла, распространять этот блок дальше и так далее.
Таким образом, по самым скромным подсчетам, потребуется в 100 раз больше серверов с той же производительностью, что и те, которые сейчас используются
Facebook, чтобы валидировать блокчейн-проект, на котором размещена социальная сеть такого масштаба. Кто-то должен будет заплатить за эти серверы, будь то компания, владеющая распределенным приложением (представьте, что вы видите 700 рекламных объявлений на каждой странице Facebook вместо 7), или ее пользователи.
В любом случае это не выглядит экономически жизнеспособным.
Мы считаем неверным, что всё должно быть загружено в блокчейн. Например, нет необходимости хранить фотографии пользователей в блокчейне; регистрация хэшей этих фотографий в блокчейне и хранение фотографий в распределенном офф-чейн хранилище (таком как FileCoin или TON Storage) было бы лучшей идеей. Это причина, по которой TON - это не просто блокчейн-проект, а совокупность нескольких компонентов (TON P2P Network, TON Storage, TON Services), сосредоточенных вокруг блокчейна TON, как описано в главах 1 и 4.
3
Система TON Networking
Для любого блокчейн-проекта необходимы не только спецификации формата блока и правил проверки блокчейна, но и сетевого протокола, используемого для распространения новых блоков, отправки и сбора транзакций-кандидатов и т. д.
Другими словами, в каждом проекте блокчейн должна быть создана специализированная одноранговая сеть. Эта сеть должна быть одноранговой, поскольку обычно предполагается, что блокчейн-проекты будут децентрализованными, поэтому нельзя полагаться на централизованную группу серверов и использовать традиционную архитектуру «клиент-сервер», как, например, в классических приложениях для онлайн-банкинга. Даже тонкие клиенты (например, приложения для смартфонов с кошельком для криптовалюты), которые должны подключаться к полным нодам по типу «клиент-сервер», на самом деле могут свободно подключаться к другой полной ноде, если соответствующая предыдущая одноранговая нода выходит из строя, при условии, что протокол, используемый для подключения для полных нод в достаточной степени стандартизирован.
В то время как сетевые потребности синглчейн-проектов, таких как Биткоин или
Эфириум, могут быть удовлетворены довольно легко (по сути, необходимо построить
«случайную» одноранговую оверлейную сеть и распространять все новые блоки и транзакции-кандидаты с помощью протокола сплетен), мультичейн-проекты с

61 3.1. Сетевой уровень абстрактной датаграммы несколькими блокчейнами, такие как TON Blockchain, гораздо более требовательны
(например, нужно иметь возможность подписаться на обновления только некоторых шардчейнов, не обязательно всех из них). Поэтому сетевая часть блокчейна TON и проекта TON в целом заслуживает хотя бы краткого обсуждения.
С другой стороны, как только будут созданы более сложные сетевые протоколы, необходимые для поддержки блокчейна TON, их можно будет легко использовать для целей, не обязательно связанных с непосредственными потребностями блокчейна
TON, что позволит обеспечить больше возможностей и гибкость для создания новых сервисов в экосистеме TON.
3.1. Сетевой уровень абстрактной датаграммы
Краеугольным камнем в построении сетевых протоколов TON является абстрактный сетевой уровень (датаграммы) (TON). Он позволяет всем узлам принимать определенные
«сетевые идентификаторы», представленные
256-битными
«абстрактными сетевыми адресами», и обмениваться данными (отправлять датаграммы друг другу в качестве первого шага), используя только эти 256-битные сетевые адреса для идентификации отправителя и получателя. В частности, не нужно беспокоиться об адресах IPv4 или IPv6, номерах портов UDP и т.п. - они скрыты в абстрактном сетевым уровне.
3.1.1. Абстрактные сетевые адреса. Абстрактный сетевой адрес, или просто адрес для краткости, является 256-битным целым числом равным 256-битному публичному ключу ECC. Этот публичный ключ может быть сгенерирован произвольно, таким образом создавая столько сетевых идентификаторов, сколько нравится узлу. Однако для получения (и расшифровки) сообщений, предназначенных для такого адреса, необходимо знать соответствующий закрытый ключ.
Фактически, адрес не является открытым ключом; вместо этого это 256-битный хэш
(Hash = sha256) сериализированного TL-объекта, который может описывать несколько типов открытых ключей и адресов в зависимости от его конструктора
(первые четыре байта). В простейшем случае этот сериализированный TL-объект состоит из 4-байтового магического числа и 256-битного открытого ключа криптографии с эллиптической кривой (ECC); в этом случае адрес будет равен хешу этой 36-байтовой структуры. Однако можно вместо этого использовать 2048-битные ключи RSA или любую другую схему криптографии с открытыми ключами. Когда узел узнает абстрактный адрес другого узла, он также должен получить свой «образ»
(т.е. сериализированный TL-объект, хэш которого равен этому абстрактному адресу), иначе он не сможет шифровать и отправлять датаграммы на этот адрес.

62 3.1. Сетевой уровень абстрактной датаграммы
В этом случае отправитель просто добавляет датаграмм для отправки своей подписью
ECC (выполненной с помощью своего закрытого ключа) и адресом своего источника.
Результат шифруется открытым ключом получателя, встраивается в датаграмму UDP и отправляется на известный IP-адрес и порт получателя. Поскольку первые 256 бит датаграммы UDP содержат абстрактный адрес получателя, получатель может определить, какой закрытый ключ следует использовать для расшифровки оставшейся части датаграммы. Только после этого раскрывается личность отправителя.
3.1.4. Менее безопасный способ, с адресом отправителя в тексте. Иногда недостаточно безопасной схемы, когда адреса получателя и отправителя хранятся в незашифрованном виде в дейтаграмме UDP; закрытый ключ отправителя и открытый ключ получателя объединяются вместе с помощью ECDH (эллиптическая кривая
Диффи-Хеллмана) для генерации 256-битного общего секрета, который используется впоследствии, наряду со случайным 256-битным одноразовым номером, также включенным в незашифрованную часть, получить ключи AES, используемые для шифрования. Целостность может быть обеспечена, например, путем объединения хеша исходных данных открытого текста в открытый текст перед шифрованием.
Преимущество этого подхода состоит в том, что если ожидается обмен более чем двумя дейтаграммами между двумя адресами, общий секрет может быть вычислен только один раз, а затем кэширован, тогда более медленные операции эллиптической кривой больше не будут требоваться для шифрования или дешифрования следующих датаграмм.
3.1.5. Каналы и идентификаторы каналов. В простейшем случае первые 256 бит датаграммы UDP, несущей встроенную дейтаграмму TON ADNL, будут равны адресу получателя. Однако в целом они составляют идентификатор канала. Существуют разные типы каналов. Некоторые из них являются двухточечными; они создаются двумя сторонами, которые желают обмениваться большим количеством данных в будущем и генерировать общий секрет путем обмена несколькими пакетами, зашифрованными в соответствии с 3.1.3 или 3.1.4 , путем запуска классической или эллиптической кривой Диффи-Хеллмана (если необходима дополнительная безопасность), или просто одна сторона генерирует случайный общий секрет и отправляет его другой стороне.
После этого идентификатор канала извлекается из общего секрета в сочетании с некоторыми дополнительными данными (такими как адреса отправителя и получателя), например, путем хеширования, и этот идентификатор используется в качестве первых 256 битов датаграмм UDP, переносящих данные, зашифрованные с помощью помощь этого общего секрета.
3.1.6. Канал как идентификатор туннеля. В общем, «канал» или «идентификатор канала» просто выбирает способ обработки входящей датаграммы UDP, известный получателю.
Если канал является абстрактным адресом получателя, обработка выполняется, как описано в п. 3.1.3 или 3.1.4; если канал является установленным двухточечным каналом, описанным в п. 3.1.5, обработка состоит в расшифровке датаграммы с помощью общего секрета, как описано в /цитата/ и т. д.
В частности, идентификатор канала может фактически выбрать «туннель», когда непосредственный получатель просто пересылает полученное сообщение кому-то другому - фактическому получателю или другому прокси. Некоторые этапы шифрования или дешифрования (напоминающие «луковую маршрутизацию» [6] или даже «чесночную маршрутизацию») могут выполняться по пути, и другой идентификатор канала может быть использован для перешифрованных

63 3.1. Сетевой уровень абстрактной датаграммы переадресованных пакетов (например, одноранговая маршрутизация). Равноправный канал может использоваться для пересылки пакета следующему получателю на пути.
Таким образом, некоторая поддержка «туннелирования» и «прокси» - что-то вроде того, что обеспечивается проектами TOR или I2P - может быть добавлена на уровне сетевого уровня абстрактных дейтаграмм TON, не затрагивая функциональность всех высших сетевые протоколы уровня TON, которые были бы независимы от такого дополнения. Эта возможность используется службой TON Proxy (см. 4.1.10).
3.1.7. Нулевой канал и проблема начальной загрузки. Обычно TON ADNL будет иметь некоторую «таблицу соседних узлов», содержащую информацию о других известных узлах, таких как их абстрактные адреса и их прообразы (то есть открытые ключи), а также их IP-адреса и порты UDP. Затем он будет постепенно расширять эту таблицу, используя информацию, полученную из этих известных узлов, в качестве ответов на специальные запросы, а иногда и удалять устаревшие записи.
Однако когда узел TON ADNL только запускается, может случиться так, что он не знает ни одного другого узла и может узнать только IP-адрес и UDP-порт узла, но не его абстрактный адрес. Это происходит, например, если легкий клиент не может получить доступ ни к одному из ранее кэшированных узлов и к любым узлам, жестко закодированным в программное обеспечение, и должен попросить пользователя ввести IP-адрес или DNS-домен узла, который необходимо разрешить через DNS.
В этом случае узел будет отправлять пакеты на специальный «нулевой канал» рассматриваемого узла. Это не требует знания открытого ключа получателя (но сообщение все равно должно содержать личность и подпись отправителя), поэтому сообщение передается без шифрования. Обычно его следует использовать только для получения идентификатора
(возможно, единовременного идентификатора, созданного специально для этой цели) получателя и затем для начала более безопасной связи.
Как только становится известен хотя бы один узел, можно легко заполнить «таблицу соседних узлов» и «таблицу маршрутизации» большим количеством записей, изучая их на основе ответов на специальные запросы, отправленные на уже известные узлы.
Не все узлы требуются для обработки дейтаграмм, отправленных на нулевой канал, но те, которые используются для начальной загрузки легких клиентов, должны поддерживать эту функцию.
3.1.8. TCP-подобный стриминговый протокол поверх ADNL. ADNL, являющийся малым протоколом датаграмм на основе 256-битных абстрактных адресов может использоваться в качестве основы для более сложных сетевых протоколов. Можно создать, например, TCP-подобный потоковый протокол, используя ADNL в качестве абстрактной замены IP. Однако большинству компонентов проекта TON такой потоковый протокол не нужен.
3.1.9. RLDP или надежный протокол больших датаграмм поверх ADNL.
Надежный протокол датаграмм произвольного размера, построенный на ADNL, называемый RLDP, используется вместо протокола, подобного TCP. Этот надежный протокол датаграмм может использоваться, например, для отправки запросов RPC удаленным хостам и получения от них ответов (см. 4.1.5).
3.2. TON DHT: Распределенная хеш-таблица, подобная Kademlia
Распределенная хеш-таблица TON (DHT) играет решающую роль в сетевой части проекта TON и используется для определения местоположения других узлов в сети.
31
https://geti2p.net/en/docs/how/garlic-routing