Вже два тижні Рунет шумить про Telegram і ситуацію з його безглуздим і нещадним блокуванням Роскомнаглядом. Рікошетом зачепило багатьох, але все це теми для постів на Geektimes. Мене ж здивувало інше — я досі не бачив на Хабрі жодного аналізу запланованої до виходу на базі Telegram мережі TON — Telegram Open Network. Мені захотілося заповнити цю ваду, бо повивчати там є що — навіть незважаючи на відсутність офіційних заяв про неї.
Нагадаю, ходять чутки про те, що Telegram запустив дуже масштабне закрите ICO, вже зібравши в ньому неймовірні суми. Передбачається, що вже цього року буде запущено власну криптовалюту Gram — і у кожного користувача Телеграма автоматично з'явиться гаманець, що створює неабияку перевагу перед іншими криптовалютами.
На жаль, так як офіційних заяв немає, далі я можу відштовхуватися тільки від , Про що я відразу вас попереджаю. Звичайно, він може виявитися дуже вправною підробкою, але не виключено і те, що це — реальний whitepaper майбутньої системи, написаний Миколою Дуровим (і злитий, ймовірно, кимось із інвесторів). Але навіть якщо це фейк, ніхто нам не заборонить його повивчати та обговорити, вірно?
Що ж йдеться у цьому документі? Я спробую переказати його своїми словами, близько до тексту, але російською і трохи людянішою (хай простить мене Микола зі своєю схильністю йти у формальну математику). Майте на увазі, що навіть у разі його справжності, це чорновий опис системи і він, ймовірно, зміниться на момент публічного запуску.
Ми дізнаємося, що, крім криптовалюти, передбачається ще дуже і дуже багато всього. Давайте розберемо по порядку.
- TON Blockchain. Це основа всієї системи. Якщо ви зовсім не знаєте, що таке - Рекомендую дізнатися, тому що тут блокчейнів буде багато. Вкладені одна в одну, віртуально роздроблені і навіть «вертикальні» блокчейни всередині блоків інших блокчейнів. А ще тут буде кілька термінів, що круто звучать Instant Hypercube Routing и Infinite Sharding Paradigmале про це пізніше. І, звичайно, proof-of-stake та смарт-контракти.
- TON P2P Network. Пірингова мережа, на основі якої буде побудовано роботу системи. Про неї в першу чергу йтиметься в цій частині розповіді.
- Сховище TON. Файлове сховище, яке незалежно від блокчейна, буде побудоване на вищезгаданій піринговій мережі. Можна порівняти з торентами.
- TON проксі. Це сервіс, мета якого – підвищити анонімність учасників мережі. Будь-який пакет можна відправити не безпосередньо, а через тунелі-посередники з додатковим шифруванням — подібно до I2P або TOR.
- TON DHT. Розподілена хеш-таблиця для зберігання довільних значень. Вона теж побудована поверх Мережа TON (але при цьому використовується ним же) і допомагає Сховище TON знаходити «роздають» вузли, а TON проксі - Проміжні ретранслятори. Але слід зазначити, що, на відміну від блокчейну, ця хеш-таблиця не є захищеним сховищем — зберігати важливу інформацію в ній не можна.
- Послуги TON. Платформа для довільних послуг. По суті, це новий інтернет поверх всього вищеописаного. Обмін даними через Мережа TON/TON проксі, А логіка - в смарт-контрактах самого TON Blockchain. І інтерфейс із досить звичними URL.
- TON DNS. Якщо вже зайшла мова про звичні URL, потрібен і перетворювач з них на 256-бітові адреси — акаунтів, контрактів, сервісів та вузлів.
- TON Платежі. І ось тільки тут торкається фінансового питання. І це буде не лише грам - як з ефіром, будуть можливі будь-які «токени»; грами тут будуть лише валютою «за замовчуванням».
Це перша частина, що описує «приземлений» рівень TON — його мережеву частину, яка будується поверх традиційних протоколів. У наступній частині мова піде про "м'якотку" - блокчейн, який підтримуватиметься описаною далі системою. Таким чином, мій порядок переказу дещо відрізняється від використаного у вищезгаданому документі (який починається відразу з абстрактного рівня).
базові поняття
TL (Type Language). Це абстрактний бінарний формат для довільних структур даних. Він використовується в протоколі Телеграма і активно використовуватиметься в TON. Якщо хочете докладно ознайомитися з ним. .
хеш (мішанина). Функція, що робить незворотне перетворення довільної структури даних в однину фіксованої довжини. У рамках документації повсюдно йдеться про функцію .
Вузол мережі (вузол). Вузол - це програмне забезпечення, яке забезпечуватиме роботу системи. Зокрема, передбачається, що кожен клієнтський додаток Телеграма включатиме вузол TON'а. На низькому рівні вузли мають IPv4/IPv6-адреси і спілкуються за протоколом UDP, на вищому — мають абстрактними адресами та реалізують протокол ADNL (про абстрактні адреси та ADNL — див. нижче). Коли йдеться про те, що якісь частини системи щось роблять або зберігають якісь дані, мається на увазі, що це роблять вузли мережі.
Абстрактна адреса (або просто адреса, адреса). Адреса вузла визначається його громадським ключем. Суворіше - це 256-бітний хеш (SHA256) від структури даних, що містить публічний ключ (конкретний криптографічний алгоритм при цьому не уточнюється - як приклад наводяться еліптичні криві і RSA-2048). Щоб один вузол міг взаємодіяти з іншим, йому потрібно знати як адресу того, а й цю структуру даних. Теоретично один фізичний вузол може створити будь-яку кількість адрес (відповідних до різних ключів).
Далі часто використовується саме така зв'язка: "прообраз" у вигляді TL-структури (що містить практично будь-які дані), і 256-бітний хеш від неї, що використовується для адресації.
Блокчейн (blockchain). Блокчейн - це структура даних, елементи (блоки) якої впорядковано в «ланцюг», і кожен наступний блок ланцюга містить у собі хеш попереднього. Таким чином досягається цілісність – зміни можуть вноситися лише додаванням нових блоків.
Сервіс (обслуговування). Сервіси в рамках TON можуть бути різних типів – залежно від того, використовують вони блокчейн чи ні. Наприклад, один (або безліч) з вузлів мережі може обробляти деякі RPC-запити за описаним далі протоколом ADNL, не створюючи жодних записів у блокчейні - на зразок традиційних веб-серверів. У тому числі розглядається можливість реалізації HTTP поверх ADNL, а також перехід месенджера на цей протокол. За аналогією з TOR або I2P це зробить його більш стійким до різних блокувань.
У той же час, ряд сервісів передбачає і взаємодію з блокчейном, і обробку запитів поза ним. Наприклад, для TON Storage – файлового сховища – не дуже розумно зберігати самі файли у блокчейні. У ньому будуть міститися лише хеші файлів (разом з якоюсь метаінформацією про них), а як «файлові сервери» будуть виступати спеціалізовані вузли мережі, готові віддавати їх іншим вузлам по ADNL.
Туманний сервіс (fog service). Йдеться про деякі сервіси, які мають на увазі децентралізацію та відкриту участь у них. Наприклад, TON Proxy — це сервіс, який може підтримувати будь-який учасник, який бажає надати свій вузол як посередник (проксі), який пересилає пакети між іншими вузлами. За бажання він може стягувати за це встановлену плату — використовуючи систему TON Payments для мікроплатежів (яка, у свою чергу, теж є туманним сервісом).
ADNL: Abstract Datagram Network Layer
На найнижчому рівні взаємодія між вузлами буде здійснюватись за протоколом UDP (хоча допустимі й інші варіанти).
Як згадано вище, щоб один вузол міг послати пакет іншому, він повинен знати один із його публічних ключів (і, отже, адресу, яка їм визначається). Він зашифровує пакет цим ключем і додає на початок пакета 256-бітну адресу одержувача - оскільки один вузол може мати кілька таких адрес, це дозволить йому визначити, який ключ використовувати для розшифровки.
Крім того, замість адреси одержувача на початку пакета даних може бути т.зв. ідентифікатор каналу. У такому разі обробка пакета вже залежить від конкретних домовленостей між вузлами — наприклад, надіслані в якийсь канал дані можуть призначатися іншому вузлу і повинні бути переадресовані (це і є сервіс TON проксі). Іншим окремим випадком може бути взаємодія безпосередньо між вузлами, але з шифруванням по індивідуальній парі ключів для цього каналу (попередньо сформованих за протоколом Діффі-Хеллмана).
Нарешті, спеціальним випадком є «нульовий» канал — якщо вузол ще знає публічних ключів своїх «сусідів», може посилати їм пакети без шифрування зовсім. Це призначено тільки для ініціалізації — як тільки вузли надішлють інформацію про свої ключі, їх варто використовувати для подальшої взаємодії.
Описаний вище протокол (256 біт ідентифікатора каналу + вміст пакета) називається ADNL. Документація згадує можливість реалізації аналога TCP поверх нього чи власної надбудови - RLDP (Reliable Large Datagram Protocol), але не вдається у подробиці їх реалізації.
TON DHT: Розподілена хеш-таблиця
Як у випадку з іншими розподіленими системами, TON передбачає реалізацію DHT. . Більш конкретно - таблиця є . Якщо ви не знайомі з таким різновидом хеш-таблиць - не турбуйтеся, далі я приблизно опишу, як вони влаштовані.
В абстрактному сенсі, DHT ставить у відповідність 256-бітовим ключам деякі бінарні значення довільної довжини. При цьому ключі в таблиці - це хеші від певної TL-структури (самі структури також зберігаються разом із DHT). Це дуже схоже на формування адрес вузлів — і вони дійсно можуть бути присутніми в DHT (наприклад, за таким ключем може бути IP-адреса вузла відповідного заданому абстрактною адресою, якщо не приховує його). Але загалом, «прообрази ключів» (їх опису, key descriptions) — це метадані, які вказують на «власника» запису в хеш-таблиці (тобто публічний ключ якогось вузла), тип значення, що зберігається, і правила, за якими цей запис може згодом змінюватися. Наприклад, правило може дозволяти змінювати значення лише власнику або забороняти зміну значення в меншу сторону (щоб захиститися від replay-атак).
Крім 256-бітових ключів вводиться поняття DHT-адрес. Різниця із звичайними адресами вузлів у тому, що DHT-адреса обов'язково прив'язана до IP-адреси. Якщо вузол не приховує свого IP, він може використовувати звичайну адресу DHT. Але частіше для потреб DHT буде заводитися окрема, «напівпостійна» адреса.
Над ключами та DHT-адресами вводиться поняття відстані – у цьому все збігається з таблицями - Відстань між ключами дорівнює XOR (побитовому виключає АБО) від них. Як і в таблицях Kademlia, значення, яке відповідає якомусь ключу, повинно зберігатися на s вузлах, що мають найменшу відстань до цього ключа (s тут - відносно невелика кількість).
Для того, щоб вузол DHT міг взаємодіяти з іншими вузлами, він тримає в пам'яті таблицю маршрутизації DHT — DHT- та IP-адреси вузлів, з якими він взаємодіяв до цього, згруповані на відстані до них. Таких груп 256 (вони відповідають старшому виставленому біту у значенні відстані — тобто вузли з відривом від 0 до 255 потраплять у одну групу, від 256 до 65535 — у наступну, тощо.). Усередині кожної групи зберігається обмежена кількість «найкращих» вузлів (у плані пінгу до них).
Кожен вузол має підтримувати кілька операцій: збереження значення для ключа, пошук вузлів и пошук значень. Пошук вузлів має на увазі видачу за заданим ключем найближчих до нього вузлів із таблиці маршрутизації; пошук значень - те саме, за винятком ситуації, коли вузлу відомо значення для ключа (тоді він просто повертає його). Відповідно, якщо вузол хоче знайти в DHT значення за ключом, він надсилає запити невеликій кількості найближчих до цього ключа вузлів зі своєї таблиці маршрутизації. Якщо серед їхніх відповідей немає значення, але є інші адреси вузлів, то запит повторюється вже до них.
TON DHT може використовуватися для різних цілей, наприклад, для реалізації торрент-подібного сховища файлів (див. Сховище TON); визначення адрес вузлів, реалізують певні послуги; для зберігання інформації про власників облікових записів у блокчейні. Але найважливіше застосування — виявлення вузлів за їхніми абстрактними адресами. Для цього адреса використовується як ключ, значення якого потрібно знайти. В результаті запиту або знайдеться сам вузол (якщо шукана адреса була його напівпостійною DHT-адресою), або значенням виявиться IP-адреса і порт для підключення - або інша адреса, який слід використовувати в якості тунелю-посередника.
Оверлейні мережі в TON
Описаний вище протокол ADNL має на увазі можливість будь-яким вузлам обмінюватися інформацією один з одним - щоправда, не обов'язково оптимальними шляхами. Можна сказати, що завдяки ADNL усі вузли утворюють глобальний граф TON (в ідеалі – зв'язковий). Але додатково передбачена можливість створювати оверлейні мережі - підграфи всередині цього графа.
Усередині такої мережі взаємодія здійснюється лише безпосередньо — за попередньо сформованими зв'язками між вузлами-учасниками мережі (по каналам ADNL, описаним вище). Формування таких зв'язків між сусідами, пошук самих сусідів — автоматичний процес, який прагне зберегти зв'язність оверлейної мережі та мінімізувати затримки під час обміну даними в ній.
Крім того, передбачено спосіб швидко розповсюджувати великі широкомовні оновлення всередині мережі — вони розбиваються на частини, доповнюються кодом корекції помилок, і всі ці шматки пересилаються від одного учасника до іншого. Таким чином, учаснику не обов'язково повністю отримати всі частини, перш ніж пересилати їх далі по мережі.
Оверлейні мережі можуть бути публічними та приватними. Стати учасником публічної мережі нескладно - потрібно знайти TL-структуру, що її описує (вона може бути публічною - або доступна за певним ключем в DHT). У випадку приватної мережі ця структура повинна бути відома вузлу заздалегідь.
Далі буде
Я вирішив поділити огляд TON на кілька статей. На цьому ця частина закінчується, а я переходжу до розгляду структури блокчейна (точніше блокчейнів), з яких складатиметься TON.
Джерело: habr.com