Telegram Open Network: teori dan praktik dari validator jaringan

Dalam beberapa bulan terakhir, semua perhatian komunitas blockchain dunia telah terpaku pada peluncuran salah satu proyek cryptocurrency terbesar - Telegram Open Network (TON).
Seperti apakah TON blockchain itu? Apakah jaringan TON benar-benar terdesentralisasi? Apa skalabilitas sebenarnya? Bagaimana cara menjadi validator jaringan?

Jawaban atas pertanyaan-pertanyaan ini dan lainnya dicoba untuk ditemukan oleh tim proyek Mercuryo , yang telah menjadi peserta aktif dalam jaringan uji sejak awal September 2019.

Pada 15 November 2019, layanan Telegram pindah ke testnet 2 dan pengujian tahap ketiga dimulai. Tim kami terus berpartisipasi dalam pengujian, menjadi validator pertama di jaringan setelah TON.

Untuk berpartisipasi dalam proses validasi, pengguna diminta tidak hanya memiliki jumlah koin yang cukup (token GRAM), tetapi juga node jaringan penuh yang terus berjalan (TON Blockchain Full Node).

Secara teoritis, setiap pengguna dapat menjadi validator dengan syarat bahwa ia memiliki bagian minimum yang diperlukan dari aset (dalam koin Gram) dalam rantai utama, tetapi dalam praktiknya sejumlah pertanyaan muncul bahwa tim kami akan menjawab dalam artikel ini.

Selain itu, kami ingin berbagi pengalaman tentang penggunaan tonlib-cli , sebagai saat ini praktis tidak ada informasi yang terdokumentasi, tidak seperti versi dasar yang dijelaskan secara rinci di HowTo.

TON Blockchain

Komponen utama Telegram Open Network adalah sistem blockchain yang fleksibel, yang selanjutnya disebut TON Blockchain, yang, menurut para pengembang sendiri, mampu memproses jutaan transaksi per detik, mendukung Turing Complete Smart Contracts, memperbarui spesifikasi blockchain resmi, transfer multi mata uang, serta saluran pembayaran mikro untuk jaringan pembayaran off-chain (Off-Chain).

“Arsitektur TON Blockchain unik karena memiliki fitur spesifik seperti mekanisme blockchain vertikal“ penyembuhan sendiri ”dan Routing Hypercube Instan, yang memungkinkan blockchain menjadi cepat, andal scalable dan berkelanjutan. "

Seperti disebutkan di atas, TON Blockchain adalah nama konvensional untuk jaringan terdesentralisasi (satu set rantai blok) atau blockchain 2D yang terdiri dari tiga jenis utama blockchain.

Master blockchain atau Masterchain adalah rantai blok unik yang berisi informasi umum tentang protokol dan nilai saat ini dari parameternya, seperangkat validator dan bagiannya, seperangkat alat kerja yang saat ini aktif dan "pecahan" mereka, serta seperangkat hash dari blok terakhir masterchains dan shardchaynov.

Working blockchains atau Workchains - satu set (hingga 232) blockchain yang merupakan “workhorses” yang berisi transaksi transfer aset dan kontrak pintar. Pada saat yang sama, masing-masing workwear dapat memiliki "aturan" sendiri, format alamat akun, format transaksi, berbagai mesin virtual (VM) untuk kontrak pintar, token dasar berbeda atau mata uang digital, dll Tetapi semuanya harus memenuhi beberapa kriteria dasar interoperabilitas untuk memastikan interaksi yang relatif sederhana di antara mereka sendiri. Dengan demikian, TON Blockchain pada dasarnya heterogen, seperti EOS dan Polkadot blockchains.

Shard blockchains atau Shardchains - subset dari blockchains (hingga 260) dalam satu set workwear, memastikan pengoperasian sistem sharding dan memiliki aturan dan format blok yang sama dengan workwear tersebut. Shardchains hanya berisi sebagian dari akun, tergantung pada beberapa bit pertama (paling signifikan) dari alamat setiap akun tertentu. Karena semua shardchains memiliki format dan aturan umum untuk blok bangunan, maka blockchain TON dalam hal ini adalah homogen dan memenuhi persyaratan yang dijelaskan dalam salah satu proposal penskalaan Ethereum.



Setiap blok shardchain (dan juga masterchain) sebenarnya bukan hanya sebuah blok, tetapi sebuah blockchain kecil. Sebagai aturan, "block blockchain" atau "blockchain vertikal" ini terdiri dari tepat satu blok, sehingga dapat dianggap hanya sebuah blok dari blockchain "biasa" yang sesuai (atau "rantai blok horizontal"). Namun, jika menjadi perlu untuk memperbaiki blok yang salah, blok baru dimasukkan ke dalam "rantai vertikal blok", yang mengandung baik penggantian blok "horizontal" yang ada, atau "perbedaan blok", yang hanya berisi deskripsi bagian-bagian dari versi sebelumnya dari blok yang perlu diganti. Mekanisme khusus TON ini untuk mengganti blok yang tidak valid yang terdeteksi tanpa perlu garpu keras disebut blockchain 2D , atau hanya 2-blockchain.

Algoritma Konsensus dan Mekanisme Perlindungan Jaringan

TON menawarkan blockchain berdasarkan Paradigma Infinite Sharding (Proof of Stake atau PoS). Menurut dokumentasi pengembang:

“Hampir semua implementasi blockchain menggunakan sharding didasarkan pada model top-down: pertama kita bayangkan satu blockchain, dan kemudian kita memutuskan bagaimana membaginya menjadi beberapa bagian yang saling berinteraksi (shardchains) untuk meningkatkan efisiensi dan meningkatkan skalabilitas.

Pendekatan TON untuk sharding didasarkan pada prinsip bottom-up, yang berarti bahwa blockchain asli sangat scalable, dan masing-masing individu shardchain hanya mengandung satu akun atau kontrak pintar. Pada tingkat berikutnya, kami memiliki sejumlah besar "rantai akun", masing-masing menggambarkan transisi antara keadaan hanya satu akun dan saling mengirim pesan yang berisi informasi tentang transaksi. Pada saat yang sama, tidak layak untuk memiliki ratusan juta blockchain, pembaruan (yaitu blok baru) di mana masing-masing tampak agak jarang, oleh karena itu, untuk penerapannya yang lebih efektif, kami mengelompokkan "rantai akun" ini menjadi "rantai gantungan", yang masing-masing blok dasarnya adalah adalah kumpulan blok rantai akun yang telah dikaitkan dengan pecahan khusus ini. Dengan demikian, "rantai akun" sebenarnya hanya blok virtual atau logis dalam "shardchains" yang benar-benar ada. Mekanisme ini menyoroti banyak keputusan desain blockchain TON dan kami menyebutnya "Paradigma Penembakan Tak Terbatas".

Jaringan konsensus TON terdiri dari berbagai jenis node: validator, nominator, phisher, dan collator.



Validator adalah simpul PoS dan produsen blok. Nelayan memantau jaringan konsensus untuk menemukan kesalahan atau mengidentifikasi node konsensus yang dianggap berbahaya, dan jika phisher secara tidak ambigu mengkonfirmasi bahwa node tersebut demikian, ia menerima hadiah dalam bentuk penyitaan bagian dari bagian validator ini.

Tugas kolektor adalah menyiapkan blok rantai shard dan menyediakannya untuk divalidasi ke simpul PoS, di mana mereka menerima bagian dari hadiah untuk membuat blok tersebut. Pada saat yang sama, kolektor pada dasarnya adalah peserta tambahan dalam konsensus, karena validator hampir selalu menghasilkan blok sendiri.

Nominator meminjamkan asetnya (token Gram ) ke validator untuk mendapat untung. Faktanya, nominasi tidak termasuk dalam infrastruktur validator, tetapi hanya berbagi bagian awal yang besar dari aset di antara mereka dengan imbalan persentase proporsional dari total remunerasi. Dengan demikian, skema dan jumlah remunerasi yang diterima para nominator bergantung sepenuhnya pada hasil kerja validator, sementara nominasi “memilih” untuk validator, meminjamkan mereka token Gram. Para nominator dapat berupa pemegang tanda individu atau kelompok yang mengelola dana masing-masing pengguna TON dan pada saat yang sama bertindak sebagai validator, bertindak sebagai delegasi melalui kontrak pintar TON. Dalam hal ini, total remunerasi dari kumpulan tersebut didistribusikan antara partisipan secara proporsional dengan kontribusi mereka.

Proses menghasilkan blok baru berlangsung sebagai berikut: sejumlah validator memilih blok masterchain (pecahan) yang sesuai untuk validasi menggunakan algoritma khusus, kemudian subset validator yang lebih kecil dipilih untuk setiap beling tersebut dalam urutan yang ditentukan dalam cara pseudo-acak dengan interval sekitar setiap 1024 blok.

Dengan demikian, untuk setiap blok, ada satu set validator yang dipilih secara acak semu untuk menentukan kandidat blok mana yang memiliki prioritas tertinggi. Validator dan node lain memverifikasi validitas kandidat blok yang diusulkan. Jika validator secara otomatis (tidak sengaja) menandatangani kandidat yang tidak sah untuk blok, maka ia dihukum dengan kehilangan sebagian atau seluruh remunerasi, atau dengan penangguhan dari partisipasi dalam pemilihan validator untuk beberapa waktu.

Selanjutnya, validator perlu mencapai konsensus berdasarkan algoritma BFT (Byzantine Resiliency Protocol), mirip dengan protokol BFT pBFT atau Honey Badger . Kemudian, setelah konsensus tercapai, blok baru dibuat, sementara biaya transaksi didistribusikan di antara validator.

Perlu dicatat bahwa setiap validator dapat dipilih untuk berpartisipasi dalam beberapa himpunan validator, oleh karena itu, diasumsikan bahwa semua algoritma validasi dan konsensus dijalankan secara paralel.

Setelah semua blok pecahan rantai yang baru dihasilkan atau batas waktu berakhir, sebuah pesan muncul bahwa blok baru rantai master telah dibuat, yang mencakup hash blok terakhir dari semua pecahan berdasarkan konsensus pBFT dari semua validator.

TON Testnet: pengalaman langsung di Telegram Open Network

Tim proyek Mercuryo telah menjadi peserta aktif dalam jaringan pengujian sejak September 2019, dan selama periode pengujian kami telah memperoleh beberapa pengalaman yang ingin kami bagikan dengan Anda.

Metode Akses Jaringan

Interaksi dengan jaringan TON, dengan satu atau lain cara, bermuara pada penggunaan spesifikasi TL yang menjelaskan cara berinteraksi dengan API. File spesifikasi tersedia di sini .

Ada tiga jenis API:

ton_api - untuk berinteraksi dengan Full Node validator-engine-console
lite_api - untuk bekerja dengan lite-client
tonlib - segala sesuatu tentang dompet dikumpulkan di sini dan ini adalah satu-satunya tonlib-cli API yang tersedia untuk umum

Pembuatan Dompet

Cara termudah untuk membuat dompet adalah dengan menggunakan Test Gram Wallet, yang tersedia di situs web resmi untuk sistem operasi Windows, macOS dan Linux.




Ada juga beberapa cara untuk berinteraksi melalui antarmuka baris perintah: dasar dan menggunakan tonlib-cli . Sayangnya, saat ini tidak ada kompatibilitas di antara mereka.

Di sini kami hanya akan mempertimbangkan alat-alat yang ditawarkan pengembang TON sendiri. Jika versi dasar didokumentasikan secara rinci dalam HowTo , maka informasi tentang penggunaan tonlib-cli praktis tidak ada.

Seperti disebutkan di atas, dalam TON ada 3 API untuk tugas yang berbeda. Fungsi yang terkait dengan pengoperasian dompet bertanggung jawab untuk tonlib .

Untuk mulai bekerja dengan tonlib-cli , di samping antarmuka baris perintah itu sendiri, Anda harus memiliki file konfigurasi untuk menghubungkan ke liteserver jaringan TON publik, yang tersedia di sini .

Koneksi dilakukan oleh tim

tonlib-cli -c ton-lite-client-test1.config.json -v 0

di mana -v 0 adalah parameter yang bertanggung jawab untuk output informasi debugging.

Daftar perintah:

Untuk membuat alamat dompet, gunakan perintah genkey dan daftar frasa mnemonik yang mungkin diperlukan untuk memulihkan akses ke alamat jika kehilangan kunci privat.

Daftar Kunci

Perintah tombol menampilkan daftar kunci. Untuk operasi lebih lanjut ketika menjalankan perintah lain, perlu untuk menggunakan nomor seri mereka, yaitu untuk kunci pertama akan ada id 0 .

Inisialisasi alamat

Setelah membuat alamat, itu harus didaftarkan di jaringan. Untuk melakukan ini, Anda harus mengisinya terlebih dahulu. Awalnya, kontrak pintar khusus digunakan untuk ini - pemberi ujian , tetapi sekarang lebih mudah dan lebih nyaman untuk menggunakan bot khusus di telegram @test_ton_bot .

Segera setelah pengisian, status akun didefinisikan sebagai uninited_accountState dan hanya akan berubah setelah Anda mengirim token uji GRM dari alamat ini.

Jika Anda sudah memiliki token pada saldo Anda dan Anda perlu mengaktifkan dompet lain, maka Anda dapat menggunakan perintah transferf dan kemudian, bersama dengan pengisian dompet, itu akan diinisialisasi.



Anda dapat mengetahui status dompet menggunakan perintah getstate 0.



Dapatkan riwayat transaksi menggunakan perintah

gethistory <num_of_key>

di mana <num_of_key> adalah nomor urut kunci

Dasar jaringan

Seperti sebagian besar blockchains yang ada, TON didasarkan pada server yang menyimpan sejarah lengkap semua blockchains yang pernah dibuat di jaringan.

Untuk menjalankan node penuh dalam jaringan uji TON, 8 core produktif, cukup 4-8 GB RAM, pada saat penulisan, data menempati sekitar 50GB hard disk, tetapi lebih baik memiliki margin setidaknya 100GB. Perlu dicatat bahwa lebih baik menggunakan drive SSD, seperti Sejumlah besar IOPS diperlukan untuk merekam, jika tidak sinkronisasi dengan jaringan akan sangat lambat.

Sebagai OS yang berfungsi, yang terbaik adalah menggunakan Ubuntu 18.04, sebagai sebagian besar tes komunitas dilakukan di sana.

Panduan Instalasi

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

Sistem validator

Diketahui bahwa TON blockchain terdiri dari blok shardchain dan masterchain, yang dibuat dan diverifikasi oleh node yang ditunjuk khusus yang disebut validator. Validator menerima sejumlah hadiah untuk "pekerjaan" mereka: menjaga kesehatan blockchain TON, sementara pendapatan didistribusikan secara proporsional dalam komunitas validator.

Sekilas, semuanya jelas, tetapi dalam praktiknya, sejumlah pertanyaan muncul sehubungan dengan ini:

• Apakah ada batasan jaringan pada steak validator maksimum?

Batas pada ukuran saham untuk satu validator selalu dapat diperiksa dengan perintah getconfig 17 , yang akan menunjukkan ukuran sebenarnya dari steak yang diijinkan:



Tangkapan layar menunjukkan bahwa saat ini ukuran berbagi minimum adalah 10.000 GRAM. Namun, jika validator tidak mendapatkan lebih dari 100.000 GRAM untuk satu putaran pemungutan suara, ia tidak berhak untuk berpartisipasi dalam pemilihan. Pada saat yang sama, jumlah maksimum token per validator tidak boleh melebihi 10.000.000 GRAM dan agar pemungutan suara berlangsung, ukuran minimum total steak harus melebihi 1.000.000 GRAM.

• Bagaimana cara validator dipilih?

Untuk mengajukan partisipasi dalam proses validasi, Anda harus memiliki minimum 10.000 GRAM. Algoritme proses pemilihan dijelaskan secara rinci dalam smart contract elector-code.fc
Kemungkinan besar, kontrak akan berbeda di jaringan utama, sehingga versi saat ini hanya berlaku untuk jaringan uji.

Bagian 10.000 GRAM tidak berarti bahwa Anda dapat menjadi validator menerima token uji dapat dengan mudah diotomatisasi oleh permintaan kepada pemberi tes .

Saat ini, hampir semua validator, ketika berpartisipasi dalam pemungutan suara, menetapkan maksimum faktor dalam jumlah 2,7 dan steak dalam jumlah 120.000 GRAM, karena ada sebagian besar taruhan tersebut, karena beratnya steak minimum naik menjadi 120.000 / 2,7 = 45.000 GRAM (tidak seperti 100.000 menurut dokumentasi resmi). Tetapi bahkan dengan steak seminimal itu, peluang Anda hampir nol, karena tiga validator teratas memiliki faktor-max 2, yang menaikkan bagian minimum menjadi 60.000 GRAM, yang memungkinkan Anda untuk menjadi validator di testnet.

Jika semua validator saat ini meningkatkan faktor maks atau mengurangi ukuran steak, maka dimungkinkan untuk menjadi validator dengan steak minimum, mengingat jumlah validator maksimum (1000 node) tidak akan terlampaui.

• Jika sistem validator terpusat, maka seluruh blockchain juga?

Tidak ada cek, mis. tidak ada yang secara terpusat mengontrol validator; nominator sendiri yang menentukan risiko ketika memilih validator.

• Jenis denda apa yang disediakan untuk validator?

Tidak ada informasi saat ini, kemungkinan besar akan ada mekanisme konsensus dalam dokumen, karena bahkan node yang tidak sinkron menerima penghargaan di testnet.

• Kontrak yang cerdas

Untuk membuat kontrak pintar TON, dua bahasa pemrograman khusus digunakan: Fift dan FunC . Jika Fift memiliki setidaknya dokumentasi umum, maka menemukan informasi tentang FunC hampir tidak mungkin (bahkan dalam kondisi kontes pengembangan , diindikasikan bahwa itu hanya dapat diperoleh dengan menganalisis kode sumbernya).

Selama pengujian, adalah mungkin untuk mengetahui bahwa basis kode FunC tidak begitu banyak (dibandingkan dengan Fift ) dan memungkinkan Anda untuk mempelajarinya lebih cepat, sehingga bekerja dengan FunC jauh lebih mudah daripada dengan Fift .

• Pertanyaan aktual / mendesak / terbuka

Sinkronisasi lambat
https://github.com/ton-blockchain/ton/issues/100

Izin untuk mesin validasi
+0 = permintaan lite-client biasa
+1 = kueri statistik simpul penuh
+2 = kueri modifikasi konfigurasi kode lengkap
+4 = kueri yang berpotensi berbahaya (seperti ekspor kunci pribadi atau menandatangani string sewenang-wenang)
+8 = dicadangkan untuk ekstensi di masa mendatang (tidak melakukan apa-apa saat ini)

• Bagaimana membuat PIPE berfungsi dengan lite-client?

Secara default, output lite-client dikirim ke stderr, jadi untuk memprosesnya, Anda harus mengarahkan ulang output dari stderr ke stdout:

$ lite-client 2 >> (grep ...)

• Apa saja opsi untuk akses jaringan terprogram?

https://github.com/ton-blockchain/ton/issues/76

• Konfigurasi server apa yang diperlukan untuk validator?

Penggunaan server prosesor ganda direkomendasikan secara resmi (setidaknya 8 core per prosesor). Perangkat lunak ini tidak terlalu menuntut RAM, jadi 16 GB sudah cukup. Anda harus menggunakan SSD sebagai drive utama, ukuran minimum yang disarankan adalah 512 GB. 8TB HDD cukup untuk menyimpan data yang diarsipkan.

Sangat penting bahwa Anda memiliki koneksi Internet berkecepatan tinggi: dengan perkiraan beban rata-rata 100 Mbit / detik, Anda harus dapat menangani beban puncak hingga 1Gbit / detik.

Dianjurkan untuk menggunakan XFS sebagai sistem file, karena informasi tentang setiap blok disimpan dalam file terpisah. Diketahui bahwa, misalnya, ext4 tidak bekerja dengan baik dengan sejumlah besar file kecil dan dapat menyebabkan situasi di mana Anda tidak memiliki inode gratis dengan ruang disk yang cukup.

• Bagaimana saya tahu bahwa suatu simpul disinkronkan?

Log akan menyelesaikan pesan sinkronisasi, atau menggunakan unixtime validator-engine-console -c "getstats" dan masterchainblocktime harus hampir sama.

• Berapa banyak validator yang bisa online?

Getconfig 16
max_validators: 1000 max_main_validators: 100 min_validators: 5

• Bagaimana cara mengetahui validator aktif saat ini?

Getconfig 34

Kumpulan validator getconfig 32 sebelumnya

• Waktu untuk validator mana yang dipilih?

Papan tulis menunjukkan bahwa validator dipilih selama satu bulan, tetapi dalam testnet kali ini jauh lebih pendek dan Anda dapat menemukannya dari konfigurasi getconfig 15.

Setelah memulai kembali testnet, interval waktu untuk validator telah berubah:

ConfigParam (15) = (validators_elected_for: 65536 pemilu_start_before: 8192 stake_held_for: 32768)

Dari situlah sekelompok validator dipilih selama 65536 detik.

• Bagaimana validator dipilih untuk babak selanjutnya?

Proses aplikasi dijelaskan secara rinci dalam Validator-HOWTO . Validator dipilih menggunakan kontrak pintar, alamat saat ini yang selalu dapat ditemukan menggunakan perintah getconfig 1 . Maka Anda perlu melacak awal pemilihan.



Jika jawabannya adalah: [0], maka pemungutan suara tidak aktif, tetapi jika responsnya mengandung stempel waktu, maka Anda dapat mengajukan permohonan untuk berpartisipasi. Bahkan jika Anda tidak akan berpartisipasi, aplikasi dari peserta seleksi lain selalu dapat dilihat:

> runmethod -1: A4C2C7C05B093D470DE2316DBA089FA0DD775FD9B1EBFC9DC9D04B498D3A2DDA participant_list

• Apakah mungkin untuk memblokir TON?

Meskipun desain kompleks tumpukan jaringan berdasarkan jaringan overlay, UDP dan TCP masih digunakan sebagai protokol transportasi TON. Diketahui bahwa saat ini kunci Telegram cukup berhasil, karena Dimungkinkan untuk mengubah alamat IP, menggunakan proksi dan memperbarui pengaturan melalui push. Namun, TON tidak akan memiliki peluang seperti itu: tidak mungkin untuk memindahkan node dengan cepat, sementara validator tidak ingin mengambil risiko saham mereka. Oleh karena itu, kemungkinan besar, dalam waktu dekat, pengembang Telegram akan memperkenalkan solusi baru untuk memotong kunci, misalnya, menggunakan Proxy ADNL.

Di bawah ini adalah lalu lintas satu simpul penuh setelah memproses 10 juta paket. Daftar 159 alamat IP yang menjalankan node testnet lengkap adalah sebagai berikut:

126 DIGITAL OCEAN (mungkin server TON)
13 AMAZON
4 GOOGLE
3 HETZNER
3 CLOUD ALIBAB 2
OVH
2 SELECTEL
2 ONLINE.NET
1 LINODE
1 hosteurope.de
1 contabo.de
dan 1 orang mungkin hosting di rumah di telecomitalia.it Italia.

Oleh karena itu, tidak sulit bagi regulator untuk mendapatkan daftar alamat IP dari basis jaringan. Namun, ini bukan hanya masalah TON, tetapi juga layanan Internet lainnya.

Bahkan, Telegram Open Network adalah upaya untuk mengimplementasikan Internet terdesentralisasi independen berdasarkan konsep WEB 3.0 dalam jaringan global yang ada, interaksi dengan yang dilakukan melalui infrastruktur informasi yang sudah dibuat dari utusan Telegram.

Dari sudut pandang teknis, TON adalah proyek unik, tumpukan teknologi yang dibuat dari awal, tanpa menggunakan solusi siap pakai yang ada. Hari ini sudah dimungkinkan untuk mengatakan bahwa:

• Kode sumber proyek ini ditulis oleh pengembang yang sangat profesional yang sangat memahami semua seluk beluk teknologi blockchain;
• menciptakan bahasa tingkat rendah mereka sendiri untuk menulis kontrak pintar (Fift dan FunC), yang memungkinkan untuk secara efektif menggunakan semua kemampuan mesin virtual dan menggunakan debugging;
• , ;
• telegram-, TON;

TON

Paradigma Infinite Sharding terdengar mengesankan, tetapi perlu diuji secara hati-hati dalam praktiknya dengan meningkatnya jumlah pecahan, jumlah rantai silang tumbuh, yang kemungkinan akan menyebabkan penurunan kecepatan pemrosesan transaksi, sehingga, pada kenyataannya, ada batas atas efektif pada throughput. TON berencana untuk menggunakan apa yang oleh pembuatnya disebut “routing instan di hypercube” untuk merutekan cross-chain dan blok antar char-chain. Namun, meskipun jalur perutean dapat ditemukan secara efisien, ini bukan solusi akhir untuk masalah mendasar penskalaan blockchain TON dan peningkatan throughput.

Walaupun mustahil untuk secara tegas mengatakan bahwa pendekatan sharding TON tidak berhasil, namun perlu dicatat bahwa “Paradigma Pengabaian Tak Terbatas” agak menyesatkan, dan jumlah shardchains kemungkinan besar akan tetap berada dalam batas yang wajar.

Desentralisasi dan konsensus

Bahkan, agar memenuhi syarat untuk berpartisipasi dalam pembangunan konsensus, simpul TON harus memiliki bagian tertentu dari aset (Gram token) pada setoran. Kerugian dari model ini adalah bahwa hal itu dapat mengarah pada fakta bahwa orang kaya akan menjadi lebih kaya, karena bagian dari aset adalah satu-satunya faktor penentu dan, oleh karena itu, TON memberi orang kaya cara untuk membiayai pengelolaan simpul PoS, yang berarti bahwa hanya organisasi besar dengan pendanaan yang cukup yang akan menjadi lebih kaya. menerima hadiah dari sebagian besar situs tanpa upaya dan pengetahuan teknis.

Node PoS konsensus bertanggung jawab untuk memproduksi blok untuk setiap rantai shard di jaringan. Sebagai hasilnya, jumlah mini-blockchains seperti itu akan tumbuh secara dinamis tergantung pada beban transaksi, sementara node PoS pseudo-acak yang ditugaskan untuk mengendalikan sektor tertentu dari shardchains, tetapi jumlah node konsensus sendiri tidak tumbuh secara proporsional. Pada awalnya, hanya akan ada sekitar seratus PoS node yang bertanggung jawab untuk membuat, mendistribusikan, dan menyinkronkan semua blok dan rantai. Dengan demikian, ini menciptakan beban besar pada node PoS baik dalam hal bandwidth yang dibutuhkan dan kekuatan pemrosesan.

Gram Dompet - Aplikasi Penyimpanan Token Gram

Mengingat serangkaian peraturan yang baru-baru ini diterbitkan tentang penggunaan layanan blockchain untuk menyimpan token TON Grams Wallet asli , yang akan diintegrasikan langsung ke messenger Telegram, banyak anggota komunitas blockchain memiliki kekhawatiran bahwa manajemen Telegram FZ-LLC bermaksud untuk memblokir akun yang mencurigakan dan mengeksekusi tanpa syarat. instruksi dari regulator di semua yurisdiksi (bahkan negara otoriter).

Namun, dengan studi dokumen yang lebih rinci, menjadi jelas bahwa Perjanjian Pengguna ini tidak mengandung tindakan atau batasan seperti itu, tetapi hanya bahwa pengguna harus berusia di atas 18 tahun dan tidak berencana untuk menggunakan aplikasi untuk tujuan yang melanggar norma hukum, kondisi peraturan dan regulasi bertindak dalam yurisdiksi tertentu dan dalam kasus pelanggaran terhadap peraturan dan regulasi ini, Telegram FZ-LLC tidak bertanggung jawab atas tindakan pengguna tersebut.

Dengan demikian, dokumen ini adalah penafian standar yang dapat ditemukan dengan perangkat lunak sumber terbuka lainnya (seperti distribusi Linux). Dalam hal ini, perhatian khusus harus diberikan pada satu bagian yang sangat penting (hal. 4, hal. 4.3), yang merujuk pada fakta bahwa perusahaan tidak mengelola blockchain Telegram Open Network:

"Kami tidak mengontrol TON Blockchain dan tidak dapat membatalkan atau mengubah data transaksi yang sudah selesai."

Sumber terbuka kami

Go-binding library

Seperti yang telah disebutkan, satu-satunya cara untuk berinteraksi dengan jaringan TON adalah dengan menggunakan perpustakaan TONLIB.

Karena proyek Mercuryo berkembang dalam bahasa Go, kami memutuskan untuk berbagi prestasi kami dengan masyarakat dengan menerbitkan perpustakaan pembungkus yang kami gunakan sendiri.
https://github.com/mercuryoio/tonlib-go

Spesifikasi tonlib api masih jauh dari kondisi akhirnya, tetapi sekarang Anda dapat menggunakannya untuk melakukan hampir semua tindakan yang terkait dengan fungsionalitas dompet:

• Operasi utama (buat / hapus / ekspor / impor / ubah kata sandi);
• Mengirim pesan / gram / file bocor dalam suatu transaksi;
• Mendapatkan status dompet dan informasi tentangnya;
• Mendapatkan daftar transaksi dengan dompet;
• Tongo adalah utilitas dompet ringan;

Saat ini, prioritas pengembangan perpustakaan adalah:

• Pemantauan jaringan. Kemampuan untuk menerima informasi tentang setiap transaksi dari semua blok jaringan. Kami benar-benar menantikan dukungan dari tonlib itu sendiri;
• Interaksi dengan kontrak. Pekerjaan sudah berlangsung;
• Memperluas fungsi asisten konsol tongo. Kami mencoba menambahkan sesuatu yang baru pada setiap rilis;
• Pembuatan struktur antarmuka sesuai dengan spesifikasi tl. Ini akan memungkinkan kami untuk menjadi lebih mobile dan merilis pembaruan dengan penundaan minimal;

Kami akan melanjutkan posting tentang pengujian Telegram Open Network, Grams Wallet dan akan dikirimkan pengamatan kami.