Telegram Open Network: теорія і практика

Telegram Open Network: теорія і практика  👌
В останні кілька місяців вся увага світового блокчейн-спільноти була прикута до запуску одного з наймасштабніших кріптовалютних проектів - Telegram Open Network (TON).
Що насправді представляє з себе блокчейн TON? Чи є мережа TON дійсно децентралізованою? Які її реальні можливості масштабування? Як стати валідатором мережі?
Відповіді на ці та інші питання спробувала знайти команда проекту Mercuryo яка є активним учасником тестової мережі з початку вересня 2019 р.
Для участі в процесі валідації, від користувача вимагається не тільки мати достатню кількість монет (токенів GRAM), але і постійно запущений повний вузол мережі (TON Blockchain Full Node).
Теоретично будь-який користувач може стати валідатором при дотриманні умови, що він володіє мінімально необхідною часткою активу (в монетах Gram) в мастерчейне, але на практиці виникає ряд питань, на які відповість їх команда.
Розповімо трішки про успіхи та  невдачі в роботі тестової мережі ТОН команди Mercuryo ✊

Крім цього, ми хочемо поділитися досвідом по використанню tonlib-cli, тому що в даний момент практично відсутня задокументована інформація на відміну від базового варіанту, детально описаного в HowTo.

TON Blockchain
Основним компонентом Telegram Open Network є гнучка система блокчейнов, далі в тексті буде називатись TON Blockchain, яка, за твердженням самих розробників, здатна обробляти мільйони транзакцій в секунду, підтримувати повні по Тьюрингу смарт-контракти (Turing Complete Smart Contracts), оновлювані офіційні блокчейн-специфікації, мультивалютні переклади, а також канали мікроплатежів для офчейн (Off-Chain) платіжних мереж.
"Архітектура TON Blockchain є унікальною оскільки володіє такими специфічними особливостями, як механізм" самовідновлювання "вертикального ланцюжка блоків (" self-healing "vertical blockchain mechanism) і миттєва маршрутизація в гиперкубі (Instant Hypercube Routing), які дозволяють блокчейну бути одночасно швидким, надійним , маштабованим і стійким. "
Як вже говорилося вище, TON Blockchain - це умовна назва децентралізованої мережі (сукупності ланцюжків блоків) або 2D-блокчейн, що складається з трьох основних типів блокчейнов.
Master blockchain або Masterchain (Мастерчейн) - єдиний в своєму роді ланцюжок блоків, що містить загальну інформацію про протокол і поточні значення його параметрів, набір валідаторів і їх частки, набір активних в даний момент воркчейнів і їх «Шарден», а також набір хеш останніх блоків мастерчейнів і шардчейнів.

  • Working blockchains або Workchains (Воркчейни) - безліч (до 232) блокчейнов, які є «робочими конячками», що містять транзакції по переміщенню активів і смарт-контракти. При цьому окремі воркчейни можуть мати свої власні «правила», формати адрес акаунтів, формати транзакцій, різні віртуальні машини (ВМ) для смарт-контрактів, різні базові маркери або криптовалюта і т.д. Але всі вони повинні задовольняти деяким основним критеріям функціональної сумісності для забезпечення простої взаємодії між собою. Таким чином, TON Blockchain за своєю суттю є гетерогенним, також як блокчейни EOS і Polkadot.

  • Shard blockchains або Shardchains (Шардчейни) - підмножина блокчейнов (до 260) всередині безлічі воркчейнів, що забезпечують роботу системи шардінга і мають ті ж правила і формаи блоків, що і у воркчейнів. Шардчейни містять тільки підмножини акаунтів, в залежності від декількох перших (найбільш значущих) байтів адреси кожного конкретного аккаунта. Оскільки всі шардчейни мають загальний формат і правила побудови блоків, ланцюжок блоків TON в цьому відношенні є гомогенним і відповідає вимогам, описаним в одній з пропозицій по маштабуванні Ethereum.
схема блоків у вертикальному блокчейні

Кожен блок шардчейна (також як і мастерчейна) насправді не просто блок, а невеликий блокчейн. Як правило цей «блоковий блокчейн» або «вертикальний блокчейн» складається рівно з одного блоку, таким чином його можна вважати просто блоком відповідного йому «звичайного» блокчейна (або «горизонтального ланцюжка блоків»). Однак, якщо виникає необхідність у виправленні некоректних блоків, то в «вертикальну ланцюжку блоків» вводиться новий блок, що містить або заміну чинного «горизонтального» блоку, або «різницю блоків», що містить тільки опис частин попередніх версії блоку, які потребують заміни. Цей специфічний для TON механізм заміни виявлених некоректних блоків без необхідності хардфорка отримав назву 2D-блокчейн, або просто 2-блокчейн.

Алгоритми консенсусу і механізм захисту мережі
TON пропонує блокчейн на основі Infinite Sharding Paradigm (парадигма нескінченного шардінга), який використовує традиційний механізм доказів володіння (Proof of Stake або PoS).
 Згідно з документацією розробника:
«Практично всі реалізації блокчейнів, що використовують шардінг, засновані на моделі « зверху вниз »: спочатку ми уявляємо собі один блокчейн, а потім вирішуємо, як розділити його на кілька  котрі взаємодіють один з одним частинами (шардчейнів) для підвищення ефективності та збільшення маштабності.
Підхід TON до шардінгу заснований на принципі «від низу до верху», що полягає в тому, що вихідний блокчейн вже є гранично масштабованим, а кожен окремий шардчейн містить тільки один акаунт чи смарт-контракт. На наступному рівні у нас є величезна кількість «ланцюжків акаунтів», кожен з яких описує переходи між станами тільки одного акаунта і посилає один одному повідомлення, що містять інформацію про транзакції. При цьому недоцільно мати сотні мільйонів блокчейнів, поновлення (тобто нові блоки) в кожному з яких з'являються досить рідко, тому, для їх більш ефективної реалізації, ми згрупували ці «ланцюжки акаунтів» в «шардчейни», кожен блок яких по суті являє собою сукупність блоків - ланцюжків акаунтів, які були прив'язані до даного конкретного Шардчейна. Таким чином, «ланцюжки акаунтів» насправді є всього лише віртуальними або логічними блоками всередині реально існуючих «шардчейнів». Цей механізм проливає світло на багато що  з проектних рішень блокчейна TON і ми називаємо його «Парадигмою нескінченного шардінга» (Infinite Sharding Paradigm) ».
Консенсусна мережу TON складається з різних типів вузлів: валідатори, номінатори, фішери і коллатори.
типи вузлів у мережі TONВалідаторами є вузли PoS і виробники блоків. Фішери стежать за консенсус-мережею з метою знайти помилку або виявити ймовірно зловмисний вузол консенсусу і в разі, якщо Фішер однозначно підтвердить, що вузол є таким, він отримує винагороду у вигляді конфіскації частини частки цього валідатора.
Завдання коллатора - підготовка блоків шардчейна і надання їх на валідацію PoS-Нодам, за що вони отримують свою частину винагороди за створення блоку. При цьому коллатори є по суті додатковими учасниками консенсусу, так як валідатори майже завжди генерують блоки самостійно.
Номінатори надають свої активи (токени Gram) валідатору борг з метою отримання прибутку. Фактично номінатори не входять до інфраструктури валідаторів, а тільки розділяють свою велику початкову частку активу між ними в обмін на пропорційний відсоток від загальної винагороди. Таким чином, схема і розмір винагороди, яку отримують номінатори, повністю залежить від результатів роботи валідаторів, при цьому номінатори «голосують» за валідаторів, надаючи їм у позику токени Gram. У ролі номінаторов можуть виступати як індивідуальні власники токенов, так і пули, які управляють коштами окремих користувачів TON і одночасно виступають в ролі валідаторів, діючи як делегати за  допомогою смарт-контракту TON. При цьому сумарна винагорода такого пулу розподіляється між його учасниками пропорційно їх вкладам.
Сам процес генерації нових блоків відбувається наступним чином: деяку певну кількість валідаторів за спеціальним алгоритмом вибирають придатні для валідації блоки мастерчейна (Шарден), потім для кожного такого Шарда відбирається менша підмножина валідаторів в порядку, визначеному псевдовипадковим способом з інтервалом приблизно кожні 1024 блоки.
Таким чином, для кожного блоку існує псевдовипадково обраний набір валідаторів для визначення того, чий кандидат в блок має найвищий пріоритет. Валідатори і інші вузли перевіряють достовірність запропонованих кандидатів в блоки. У разі, якщо валідатор автоматично (не намірено) підписує недійсного кандидата в блоки, то він карається втратою частини або всієї своєї винагороди, або зовсім відстороненням від участі в відборі валідаторів на деякий час.
Далі валідатору необхідно досягти консенсусу на основі алгоритму BFT (Візантійський протокол відмовостійкості), аналогічного протоколу pBFT або Honey Badger BFT. Потім, після досягнення консенсусу, створюється новий блок, при цьому комісії за транзакції розподіляються між валідаторами.
Необхідно відзначити, що кожен валідатор може бути обраний для участі в декількох подмножинах валідаторів, тому передбачається, що всі алгоритми валідації і консенсусу запущені паралельно.
Після того, як всі нові блоки Шарден ланцюга згенеровані або таймаут закінчено, з'являється повідомлення про те, що створений новий блок мастерчейна, що включає в себе хеші останніх блоків всіх Шарден на основі pBFT-консенсусу всіх валідаторів.

TON Testnet: практичний досвід роботи в Telegram Open Network

 Способи доступу до мережі
Взаємодія з мережею TON, так чи інакше, зводиться до використання TL специфікацій, які описують способи взаємодії з API. Файли специфікацій доступні за посиланням.
Існує три типи API:
  • ton_api - для взаємодії з Full Node validator-engine-console
  • lite_api - для роботи з lite-client
  • tonlib - тут зібрано все, що стосується гаманця і це єдиний доступний публічно API tonlib-cli
Створення гаманця GRAM
Найпростіший спосіб створити гаманець - це скористатись Test Gram Wallet, який доступний на офіційному сайті для операційних систем Windows, macOS і Linux.

Gram WalletGram Wallet
Також існує кілька способів взаємодії через інтерфейс командного рядка: базовий і за допомогою tonlib-cli. На жаль, на даний момент сумісності між ними немає.

Тут ми будемо розглядати тільки ті інструменти, які пропонують самі розробники TON. Якщо базовий варіант детально задокументований в HowTo, то інформація по використанню tonlib-cli практично відсутня.

Як згадувалося вище, в TON існує 3 API для різних завдань. За функції, пов'язані з роботою гаманця, відповідає tonlib.

Для початку роботи з tonlib-cli, крім самого інтерфейсу командного рядка, необхідно мати файл конфігурації для підключення до публічного liteserver мережі TON, який доступний за посиланням.


Підключення здійснюється командою
tonlib-cli -c ton-lite-client-test1.config.json -v 0
де -v 0 - параметр, який відповідає за висновок налагоджувальної інформації.


 Список команд:Help TON

Для створення адреси гаманця використовується команда genkey і список mnemonic-фраз, які можуть бути необхідні для відновлення доступу до адреси у  разі втрати приватного ключа.
Genkey TON

Список ключів
Команда keys виводить список ключів. Для подальших операцій при виконанні інших команд необхідно використовувати їх порядковий номер, тобто для першого ключа буде id 0.
Keys TONІніціалізація адреси
Після створення адреси, її потрібно зареєструвати в мережі. Для цього гаманець необхідно спочатку поповнити. Спочатку для цього використовувався спеціальний смарт-контракт - testgiver, але зараз простіше і зручніше використовувати спеціального бота в телеграмі @test_ton_bot.
Відразу після поповнення, статус аккаунта позначається як uninited_accountState і зміниться тільки після того, як ви відправите з цієї адреси тестові токени GRAM.
Якщо у вас вже є токени на балансі і вам потрібно активувати інший гаманець, то можна скористатися командою transferf і тоді разом з поповненням гаманця відбудеться його ініціалізація.
transferf TON
Дізнатись стан гаманця можна за допомогою команди getstate 0.
getstate TON
Отримати історію транзакцій можна за допомогою команди
gethistory <num_of_key>
де <num_of_key> - порядковий номер ключаgethistory TON
Основа мережі
Також, як і в більшості існуючих блокчейнів, основу TON складають сервери, які зберігають повну історію всіх ланцюжків блоків, які коли-небудь були створені в мережі.
Для запуску повної Ноди в тестовій мережі TON досить 8 продуктивних ядер, 4-8 GB оперативної пам'яті, на момент написання статті дані займали близько 50GB жорсткого диска, але краще мати запас хоча б до 100GB. Необхідно відзначити, що краще використовувати SSD диск, тому що потрібна велика кількість IOPS на запис, інакше синхронізація з мережею буде дуже повільною.
В якості робочої ОС найкраще використовувати Ubuntu 18.04, тому що велика частина тестів спільноти проводиться саме на ній.
  Посилання на гайди по встановленню.

README.txt
FullNode-HOWTO.txt
Validator-HOWTO.txt

Система валідаторів
Відомо, що блокчейн TON складається з блоків шардчейна (shardchain) і мастерчейна (masterchain), які створюються і перевіряються спеціальними призначеними вузлами, котрі називаються валідаторами. Валідатори отримують певну винагороду за свою «роботу»: підтримка працездатності блокчейна TON, при цьому дохід розподіляється всередині спільноти валідаторів пропорційно.

На перший погляд все зрозуміло, але на практиці в зв'язку з цим виникає ряд питань:
  • Чи існує обмеження мережі на максимальний стейк валідатора?
Обмеження на розмір частки для одного валідатора завжди можна перевірити командою getconfig 17, яка покаже актуальні розміри допустимих стейків:
getconfig в TON розмір частки долі в валідаторі
На скріншоті вище видно, що в даний момент мінімальний розмір частки становить 10 000 GRAM. Однак в разі, якщо за раунд голосування у валідатора не набирається більше 100 000 GRAM, то він не має права брати участь у виборах. При цьому максимальна кількість токенів на одного валідатора не може перевищувати 10 000 000 GRAM і для того, щоб голосування відбулося, мінімальний розмір загального стейка повинен перевищувати 1 000 000 GRAM.

  • Як вибираються валідатори?
Для подачі заявки на участь у процесі валідації, необхідно мати мінімум 10000 GRAM. Алгоритм процесу виборів докладно описаний в смарт-контракті elector-code.fc
Швидше за все, в основній мережі контракт буде іншим, тому поточна версія контракту може бути застосована тільки для тестової мережі.
Частка в розмірі 10000 GRAM ще не означає, що ви зможете стати валідатором, тому що отримання тестових токенов можна було легко автоматизувати запитами до testgiver.
На даний момент практично всі валідатори за участю в голосуванні виставляють max-factor в розмірі 2.7 і стейк в розмірі 120000 GRAM, оскільки таких ставок більшість, то через їх вагу мінімальний стейк піднімається до 120000 / 2.7 = 45 000 GRAM (на відміну від 100 000 по офіційній документації). Але і з таким мінімальним стейком ваші шанси практично нульові, так як три топових валідатора мають max-factor рівний 2, що піднімає мінімальну частку до 60000 GRAM, яка дозволяє стати валідатором в тестнеті.
Якби всі поточні валідатори збільшили свій макс-фактор або зменшили розмір стейка, то можна було стати валідатором і з мінімальним стейком, при врахуванні того, що не буде перевищено максимальну кількість валідаторів (1000 вузлів).
  • Якщо система валідаторів централізована, то і весь блокчейн Telegram Open Network теж?
Перевірок немає, тобто ніхто централізовано не контролює валідаторів, номінатори самі визначають ризики при виборі валідатора.
  • Які види штрафів передбачені для валідаторів?
В даний момент немає ніякої інформації, швидше за все буде в документі з описом консенсус механізму, тому що в тестнеті навіть розсінхронізовані ноди отримували нагороди.

  • Смарт-контракти Telegram Open Network
Для створення смарт-контрактів TON, використовується два спеціальних мови програмування: Fift і FunC. Якщо у Fift існує хоча б загальна документація, то знайти інформацію про FunC практично неможливо (навіть в умовах конкурсу на розробку зазначено, що її можна отримати тільки при аналізі його вихідного коду).
Під час тестування вдалося з'ясувати, що кодова база FunC не така об'ємна (в порівнянні з Fift) і дозволяє вивчити її набагато швидше, тому працювати з FunC набагато простіше, ніж з Fift.

  • Актуальні / Нагальні / Відкриті питання
повільна синхронізація
https://github.com/ton-blockchain/ton/issues/100

Права доступу до validation-engine
+0 = usual lite-client queries
+1 = full node statistics queries
+2 = full code configuration modification queries
+4 = potentially dangerous queries (such as private key export or signing arbitrary strings)
+8 = reserved for future extensions (does nothing at the moment)

  • Як змусити PIPE працювати з lite-client?
За замовчуванням висновок lite-client відправляється в stderr, тому для його обробки спочатку необхідно перенаправити висновок з stderr в stdout:
$ Lite-client 2>> (grep ...)

  • Які існують варіанти програмного доступу до мережі?
https://github.com/ton-blockchain/ton/issues/76

  • Яка конфігурація сервера потрібно для валідатора?
Офіційно рекомендується використання двопроцесорного сервера (мінімум 8 ядер на кожен процесор). Програмне забезпечення не дуже вимогливе до оперативної пам'яті, тому цілком достатньо 16 GB. В якості основного диска необхідно використовувати SSD, мінімальний рекомендований обсяг якого становить 512 GB. Для зберігання архівних даних досить 8TB HDD.
Обов'язкова наявність високошвидкісного інтернет-підключення: при прогнозованому середньозваженому навантаженні 100 Mbit/sec, необхідно мати можливість обробляти пікове навантаження до 1Gbit/sec.
В якості файлової системи рекомендується використовувати XFS, оскільки інформація про кожний блок зберігається в окремому файлі. Відомо, що, наприклад, ext4 не дуже ефективно працює з великою кількістю дрібних файлів і може привести до ситуації, коли у вас просто не залишиться вільних inodes при достатньому запасі ємності диска.

  • Як дізнатися, що нода Telegram Open Network синхронізувалася?
В лозі буде completed sync повідомлення або за допомогою validator-engine-console -c «getstats» unixtime і masterchainblocktime повинні бути майже однаковими.

  • Скільки валідаторів може бути в мережі?
Getconfig 16
max_validators 1000 max_main_validators: 100 min_validators: 5
  • Як дізнатися список активних валідаторів?
Getconfig 34
Попередній набір валідаторів getconfig 32
  • Час на який вибираються валідатори?
У whitepaper вказується, що валідатори вибираються на місяць, але в тестнете цей час набагато менше і дізнатися його можна з конфіга getconfig 15.
Після перезапуску testnet, тимчасові інтервали для валідаторів змінилися:
ConfigParam (15) = (validators_elected_for: 65536 elections_start_before: 32768 elections_end_before: 8192 stake_held_for: 32768)
З чого випливає, що група валідаторів вибираються на 65536 секунд.

  • Як відбувається вибір валідаторів для наступного раунду?
Процес подачі заявки докладно описаний в Validator-HOWTO. Валідатори вибираються за допомогою смарт-контракту, актуальний адреса якого завжди можна знайти за допомогою команди getconfig 1. Потім необхідно відстежити початок голосування.
getconfig 1 Validator-HOWTO
Якщо у відповіді result: [0], то значить голосування неактивно, якщо ж у відповіді вказано timestamp, то можна подавати участь на замовлення. Навіть якщо ви не збираєтеся брати участь, заявки інших учасників відбору завжди можна подивитися:
> Runmethod -1: A4C2C7C05B093D470DE2316DBA089FA0DD775FD9B1EBFC9DC9D04B498D3A2DDA participant_list

  • Чи можна заблокувати TON?
Незважаючи на складну конструкцію мережевого стека на основі оверлейних мереж, в якості транспортних протоколів Telegram Open Network як і раніше використовуються UDP і TCP. Відомо, що сьогодні блокування Telegram залишаються досить безуспішними, тому що є можливість змінювати IP адреси, чудова ідея і оновлювати налаштування через пуш. Однак TON не матиме таких можливостей: швидко перемістити Ноди не представляється можливим, при цьому валідатори не захочуть ризикувати своїми частками. Тому, швидше за все, в найближчому майбутньому розробники Telegram представлять нові рішення для обходу блокування, наприклад, за допомогою ADNL Proxy.

Нижче представлений трафік одного повного вузла після обробки 10 млн. Пакетів. Список з 159 IP-адрес, на яких запущені повні yоди тестнета, виглядає наступним чином:
126 DIGITAL OCEAN (імовірно сервери під управлінням TON)
13 AMAZON
4 GOOGLE
3 HETZNER
3 ALIBABA CLOUD
2 OVH
2 SELECTEL
2 ONLINE.NET
1 LINODE
1 hosteurope.de
1 contabo.de
and 1 person possibly hosting it at home in Italy telecomitalia.it

Отже для регулятора не важко отримати список IP-адрес основyj] мережі. Втім, це проблема не тільки TON, але і будь-якого іншого інтернет-сервісу.

По суті, Telegram Open Network представляє собою спробу реалізувати незалежний децентралізований інтернет на основі концепції WEB 3.0 всередині існуючої глобальної мережі, взаємодія з якою здійснюється за допомогою вже створеної інформаційної інфраструктури месенджера Telegram.
З технічної точки зору TON є унікальним проектом, технологічний стек якого створено «з нуля», без використання існуючих готових рішень. На сьогоднішній день вже можна говорити про те, що:
  • вихідний код проекту написаний високопрофесійними розробниками, які глибоко розуміють всі тонкощі технології блокчейн;
  • створені свої власні низькорівневі мови для написання смарт-контрактів (Fift і FunC), що дають можливість ефективно використовувати всі можливості віртуальної машини і використовувати налагодження;
  • запущена тестова мережа, в якій активно працює співтовариство сторонніх розробників;
  • працюють telegram-боти, що полегшують взаємодію з екосистемою TON;
Реальні можливості масштабування блокчейна TON
Парадигма нескінченного шардінга (Infinite Sharding Paradigm) звучить вражаюче, але вона потребує ретельної перевірки на практиці, тому що в міру збільшення кількості шард, виросте і кількість кроссчейнів, що, цілком ймовірно, призведе до зниження швидкості обробки транзакцій, таким чином, насправді існує ефективна верхня межа пропускної здатності. TON планує використовувати те, що самі розробники називають «миттєвою маршрутизацією в гиперкубі» для маршрутизації кроссчейнов і блоків між шарчейнами. Однак, хоча шлях маршрутизації може бути знайдений ефективно, це не є остаточним рішенням основної проблеми масштабування блокчейна TON і збільшення пропускної здатності.
У той час, як не можна однозначно говорити про те, що шардінговий підхід TON не увінчається успіхом, проте необхідно відзначити, що «Парадигма нескінченного шардінга» трохи вводить в оману, і кількість шардчейнів, швидше за все, має залишатися в розумних межах.

Децентралізація і консенсус
Фактично, щоб отримати право на участь в досягненні консенсусу, вузли TON повинні мати на депозиті певну частку активу (токенов Gram). Недоліком такої моделі є те, що вона може привести до того, що багаті стануть ще багатшими, оскільки частка активу є єдиним визначальним фактором і відповідно TON надає багатим людям кошти для фінансування управління вузлами PoS, що означає, що тільки великі організації з достатнім фінансуванням будуть отримувати винагороду від більшості вузлів без зусиль і технічного ноу-хау.
Консенсусні вузли PoS відповідають за виробництво блоків для кожного шардчейна в мережі. Внаслідок цього, кількість таких міні-блокчейнів буде динамічно зростати в залежності від транзакційного навантаження, при цьому вузли PoS псевдовипадково призначаються для управління певним сектором шардчейнів, але кількість самих вузлів консенсусу не росте пропорційно. Спочатку буде тільки близько ста вузлів PoS, які відповідають за створення, поширення і синхронізацію всіх блоків і шардчейнов. Таким чином, це створює велике навантаження на вузли PoS як з точки зору необхідної пропускної спроможності, так і обчислювальної потужності.

Grams Wallet - додаток для зберігання токенов Gram
У світлі нещодавно опублікованого списку правил по використанню блокчейн-сервісу для зберігання нативних токенов TON Grams Wallet, який буде інтегрований безпосередньо в месенджер Telegram, у багатьох учасників блокчейн-спільноти виникли побоювання, що керівництво компанії Telegram FZ-LLC має намір блокувати підозрілі акаунти і беззастережно виконувати будь-які вказівки регуляторів у всіх юрисдикціях (навіть авторитарних країн).
Однак, при більш детальному вивченні документа, стає зрозуміло, що дана угода не містить подібних заходів або обмежень, а лише те, що користувач повинен бути старше 18 років і не планує використовувати додаток з метою, які порушують правові норми, умови регулювання і приписи , що діють в конкретних юрисдикціях і в разі порушення цих норм і правил, компанія Telegram FZ-LLC не несе відповідальність за дії таких користувачів.
Таким чином, цей документ являє собою стандартний відмову від відповідальності, який можна зустріти при використанні будь-якого іншого відкритого ПЗ (напр. Дистрибутива Linux). При цьому, особливу увагу слід звернути на один дуже важливий розділ (р. 4, п. 4.3), в якому мова йде про те, що компанія не управляє блокчейном Telegram Open Network:
«Ми не контролюємо TON Blockchain і не в силах анулювати або змінити дані вже скоєних транзакцій».

Our open source
Go-binding library
Як уже згадувалося, єдиним способом для взаємодії з мережею TON є використання бібліотеки TONLIB.
Бібліотека-обгортка, яку використовувалась.
https://github.com/mercuryoio/tonlib-go
Специфікація tonlib api ще далека від свого фінального стан, але вже зараз з її допомогою можна виконувати практично будь-які дії, пов'язані з функціоналом гаманця:

  • Операції з ключами (створення / видалення / експорт / імпорт / зміна пароля);
  • Відправлення повідомлень / gram / boc-файлів в транзакції;
  • Отримання стану гаманця та інформації про нього;
  • Отримання списку транзакцій по гаманцю;
  • Tongo легковага утиліта для роботи з гаманцем;

На поточний момент пріоритетом у розвитку бібліотеки є:
  • Моніторинг мережі. Можливість отримувати інформацію по кожній транзакції з усіх блоків мережі. Дуже чекаємо підтримки з боку самого tonlib;
  • Взаємодії з контрактами. Робота вже ведеться;
  • Розширення функціоналу консольного помічника tongo. Намагаємося додати що-небудь нове з кожним релізом;


Джерела котрі використані в написанні тексту

Whitepaper.
Github… github.com/ton-blockchain/ton
Тестовые доки
Доки разработчикаdocs.ton.dev
TON — Telegram Open Network
Grams Wallet