Pendahuluan: Setelah Binance meluncurkan Notcoin, game terbesar di ekosistem TON, dan ekonomi tokennya yang beredar penuh menciptakan efek kekayaan yang sangat besar, TON dengan cepat mendapatkan banyak perhatian. Berbicara dengan teman-teman, saya menemukan bahwa TON memiliki hambatan teknis yang tinggi dan model pengembangannya yang DApp sangat berbeda dari protokol blockchain arus utama. Jadi, saya meluangkan waktu untuk meneliti topik ini secara mendalam dan memiliki beberapa wawasan untuk dibagikan kepada Anda. Dalam short, filosofi desain inti TON adalah membangun kembali protokol blockchain tradisional dari bawah ke atas, dengan fokus pada pencapaian konkurensi dan skalabilitas tinggi, bahkan jika itu berarti mengorbankan interoperabilitas.

TON Prinsip Desain Inti - Konkurensi dan Skalabilitas Tinggi

Dapat dikatakan bahwa tujuan dari semua pilihan teknologi yang kompleks dalam TON berasal dari mengejar konkurensi tinggi dan skalabilitas tinggi. Tentu saja, tidak sulit bagi kita untuk memahami hal ini dari latar belakang kelahirannya. TON, atau The Open Network, adalah jaringan komputasi terdesentralisasi yang mencakup blockchain L1 dan beberapa komponen. TON awalnya dikembangkan oleh pendiri Telegram Nikolai Durov dan timnya, dan sekarang didukung dan dikelola oleh komunitas global kontributor independen. Kelahirannya dimulai pada tahun 2017, ketika tim Telegram mulai mengeksplorasi solusi blockchain untuk diri mereka sendiri. Karena tidak ada blockchain L1 yang ada pada saat itu yang dapat dukungan basis pengguna sembilan digit Telegram, mereka memutuskan untuk merancang blockchain mereka sendiri, yang kemudian disebut Telegram Open Network. Waktunya tiba pada tahun 2018. Pada pesanan untuk mendapatkan sumber daya yang dibutuhkan untuk mengimplementasikan TON, Telegram meluncurkan penjualan token Gram (kemudian berganti nama menjadi Toncoin) pada kuartal pertama 2018. Pada tahun 2020, tim Telegram menarik diri dari proyek TON karena masalah peraturan. Selanjutnya, sekelompok kecil pengembang open source dan pemenang kompetisi Telegram mengambil alih basis kode TON, mengganti nama proyek menjadi The Open Network, dan terus aktif mengembangkan blockchain hingga hari ini, mengikuti prinsip-prinsip yang diuraikan dalam kertas putih TON asli.

Karena TON dirancang untuk menjadi lingkungan eksekusi terdesentralisasi Telegram, ia harus mengatasi dua tantangan utama: permintaan bersamaan yang tinggi dan data besar. Bahkan TPS (transaksi per detik) tertinggi yang diuji Solana, yang mengklaim sebagai yang tercepat, hanya 65.000, jauh short dari TPS tingkat juta yang dibutuhkan untuk Telegram. Selain itu, sejumlah besar data yang dihasilkan oleh Telegram tidak dapat dikelola oleh blockchain di mana setiap node menyimpan salinan lengkap data.

Untuk mengatasi tantangan ini, TON mengoptimalkan protokol blockchain arus utama dengan dua cara:

l Ini menggunakan "Paradigma Sharding Tak Terbatas" untuk mengurangi redundansi data, memungkinkannya menangani data dalam jumlah besar dan mengurangi kemacetan kinerja.

l Dengan memperkenalkan lingkungan eksekusi paralel sepenuhnya berdasarkan model Aktor, TPS jaringan sangat ditingkatkan;

Membangun Blockchain Rantai - Menyediakan Setiap Akun dengan Rantai Kustomnya Sendiri Melalui Infinite Sharding

Kita sekarang tahu bahwa sharding telah menjadi solusi utama bagi sebagian besar protokol blockchain untuk meningkatkan kinerja dan mengurangi biaya, dan TON telah membawa ini ke ekstrem dan mengusulkan paradigma sharding tak terbatas, yang disebut paradigma sharding tak terbatas. Mengacu pada memungkinkan blockchain untuk secara dinamis menambah atau mengurangi jumlah pecahan berdasarkan beban jaringan. Paradigma ini memungkinkan TON untuk menangani transaksi skala besar dan operasi kontrak cerdas sambil mempertahankan kinerja tinggi. Secara teori, TON dapat membuat rantai akun eksklusif untuk setiap akun dan memastikan interoperabilitas antara rantai ini melalui aturan tertentu. konsistensi

Intinya, struktur rantai TON terdiri dari empat lapisan

AccountChain: Lapisan ini mewakili serangkaian transaksi yang terkait dengan akun tertentu. Transaksi membentuk rantai karena, dalam mesin negara, aturan eksekusi yang konsisten memastikan bahwa mesin negara menghasilkan hasil yang sama ketika memproses instruksi dalam pesanan yang sama. Oleh karena itu, semua sistem blockchain memerlukan transaksi untuk dihubungkan dalam suatu rantai, dan TON tidak berbeda. AccountChain adalah unit paling mendasar dalam jaringan TON. Biasanya, AccountChain adalah konsep virtual, dan AccountChain independen tidak mungkin ada.

ShardChain: Dalam kebanyakan konteks, ShardChain adalah unit aktual dalam TON. ShardChain pada dasarnya adalah kumpulan AccountChains.

WorkChain: Juga dikenal sebagai sekumpulan chain pecahan dengan aturan kustom, seperti membuat WorkChain berdasarkan EVM untuk menjalankan Solidity smart contract. Secara teori, siapa pun di komunitas dapat membuat WorkChain mereka sendiri. Namun, membangunnya cukup rumit dan membutuhkan pembayaran biaya pembuatan (tinggi) dan mendapatkan persetujuan dari 2/3 validator.

MasterChain: Dalam TON, ada rantai unik yang disebut MasterChain, yang memberikan finalitas untuk semua rantai beling. Ketika nilai hash dari blok shard chain dimasukkan dalam blok MasterChain, blok shard chain dan semua blok induknya dianggap final, yang berarti mereka tetap dan tidak berubah, direferensikan oleh semua blok shard chain berikutnya.

Paradigma ini memberi jaringan TON tiga fitur utama:

Sharding Dinamis: TON dapat secara otomatis membagi dan menggabungkan rantai pecahan untuk beradaptasi dengan perubahan beban, memastikan blok baru dibuat dengan cepat dan transaksi tidak mengalami penundaan long.

Skalabilitas Tinggi: Dengan paradigma sharding yang tak terbatas, TON dapat dukungan jumlah pecahan yang hampir tidak terbatas, secara teoritis hingga 2^60 WorkChains.

Kemampuan beradaptasi: Ketika bagian dari jaringan mengalami peningkatan beban, ia dapat dibagi lagi menjadi lebih banyak pecahan untuk menangani volume transaksi yang lebih tinggi. Sebaliknya, ketika beban berkurang, pecahan dapat bergabung untuk meningkatkan efisiensi.

Dalam sistem multi-rantai seperti ini, tantangan utamanya adalah cross-chain komunikasi. Dengan kemampuan untuk sharding tak terbatas, ketika jumlah shard dalam jaringan tumbuh secara signifikan, merutekan informasi antar rantai menjadi kompleks. Misalnya, bayangkan sebuah jaringan dengan empat node, masing-masing mempertahankan WorkChain independen. Setiap node, selain mengelola penyortiran transaksinya sendiri, juga harus memantau dan memproses perubahan status dalam rantai lain. Dalam TON, ini dilakukan dengan memantau pesan dalam antrian output.

Misalkan Akun A di WorkChain 1 ingin mengirim pesan ke Akun C di WorkChain 3. Ini membutuhkan perancangan solusi perutean pesan. Dalam contoh ini, ada dua jalur perutean: WorkChain 1 -> WorkChain 2 -> WorkChain 3, dan WorkChain 1 -> WorkChain 4 -> WorkChain 3.

Dalam skenario yang lebih kompleks, algoritma routing yang efisien dan murah diperlukan untuk komunikasi pesan yang cepat. TON menggunakan "algoritma perutean hypercube" untuk penemuan perutean pesan cross-chain. Struktur hypercube adalah topologi jaringan khusus di mana hypercube n-dimensi memiliki 2^n simpul, masing-masing diidentifikasi secara unik oleh bilangan biner n-bit. Dalam struktur ini, setiap dua simpul berdekatan jika representasi biner mereka berbeda hanya satu bit. Misalnya, dalam hypercube 3 dimensi, vertex 000 dan vertex 001 berdekatan karena mereka hanya berbeda pada bit terakhir. Contoh di atas adalah hypercube 2 dimensi.

Dalam protokol perutean hypercube, perutean pesan dari WorkChain sumber ke WorkChain target dilakukan dengan membandingkan alamat biner mereka. Algoritma menemukan jarak minimum antara alamat-alamat ini (yaitu, jumlah bit yang berbeda) dan meneruskan pesan melalui WorkChains yang berdekatan hingga mencapai tujuannya. Ini memastikan bahwa paket data mengikuti jalur terpendek, meningkatkan efisiensi komunikasi jaringan. Untuk menyederhanakan proses ini, TON juga menawarkan solusi optimis. Jika pengguna dapat memberikan bukti yang valid dari jalur perutean, biasanya akar trie Merkle, node dapat segera memverifikasi keaslian pesan. Ini dikenal sebagai perutean hypercube instan. Akibatnya, alamat TON berbeda secara signifikan dari yang ada di protokol blockchain lainnya. Sebagian besar protokol blockchain menggunakan hash kunci publik yang dihasilkan oleh algoritma enkripsi eliptik sebagai alamat, dengan fokus pada keunikan tanpa memerlukan fungsi routing. Dalam TON, alamat terdiri dari dua bagian: (workchain_id, akun_id), dengan workchain_id dikodekan sesuai dengan algoritma routing hypercube. Orang mungkin bertanya-tanya mengapa tidak menyampaikan semua informasi cross-chain melalui MasterChain, mirip dengan Cosmos. Dalam desain TON, MasterChain hanya menangani tugas paling penting untuk mempertahankan finalitas WorkChains. Meskipun dimungkinkan untuk merutekan pesan melalui MasterChain, biaya terkait akan sangat tinggi.

Akhirnya, mari kita bahas secara singkat algoritma konsensusnya. TON menggunakan kombinasi BFT (Byzantine Fault Toleransi) dan PoS (Proof of Stake). Ini berarti bahwa setiap staker dapat berpartisipasi dalam pembuatan blok. Kontrak tata kelola pemilu TON secara berkala memilih sekelompok validator secara acak dari semua pemangku kepentingan. Ini dipilih validator kemudian menggunakan algoritma BFT untuk membuat blok. Jika validator membuat blok yang tidak valid atau bertindak jahat, token yang dipertaruhkan akan disita. Sebaliknya, mereka menerima hadiah karena berhasil membuat blok yang valid. Metode ini cukup umum, jadi kami tidak akan membahas lebih lanjut di sini.

Kontrak pintar yang memanfaatkan model Aktor dalam lingkungan eksekusi yang sepenuhnya paralel

Perbedaan utama lainnya dalam TON dibandingkan dengan protokol blockchain arus utama adalah lingkungan eksekusi kontrak cerdasnya. Untuk mengatasi keterbatasan TPS yang dihadapi oleh protokol blockchain arus utama, TON menggunakan pendekatan desain bottom-up dan menggunakan model Aktor untuk merekonstruksi smart contract dan eksekusinya, memungkinkan kemampuan eksekusi paralel sepenuhnya.

Sebagian besar protokol blockchain utama menggunakan lingkungan eksekusi serial single-threaded. Misalnya, lingkungan eksekusi Ethereum, EVM, beroperasi sebagai mesin negara yang memproses transaksi secara berurutan. Setelah blok terbentuk dan transaksi dipesan, mereka dieksekusi satu per satu melalui EVM. Proses yang sepenuhnya serial, single-threaded ini berarti hanya satu transaksi yang diproses pada waktu tertentu. Keuntungannya adalah bahwa setelah pesanan transaksi ditetapkan, hasil eksekusi tetap konsisten di seluruh jaringan terdistribusi. Selain itu, karena hanya satu transaksi yang dijalankan pada satu waktu, tidak ada transaksi lain yang dapat mengubah data negara yang diakses, memastikan interoperabilitas antar smart contract. Misalnya, saat menggunakan Uniswap untuk membeli ETH dengan USDT, distribusi pool likuiditas adalah nilai tetap selama eksekusi. Hal ini memungkinkan model matematika untuk menentukan hasil yang tepat. Sebaliknya, jika penyedia likuiditas lain menambahkan likuiditas selama perhitungan bonding curve, hasilnya akan ketinggalan zaman, yang jelas tidak dapat diterima.

Namun, arsitektur ini juga memiliki keterbatasan yang jelas, terutama hambatan TPS, yang terasa ketinggalan zaman dengan prosesor multi-core modern. Ini mirip dengan memainkan game komputer lama seperti Red Alert di PC baru; Ketika jumlah unit tempur mencapai level tertentu, Anda masih mengalami lag yang signifikan. Ini karena masalah arsitektur perangkat lunak.

Beberapa protokol mengatasi masalah ini dan telah mengusulkan solusi paralel mereka sendiri. Misalnya, Solana, yang mengklaim memiliki TPS tertinggi, juga mendukung eksekusi paralel. Namun, desain Solana berbeda dari TON. Ide inti Solana adalah mengelompokkan semua transaksi berdasarkan dependensi eksekusi mereka, memastikan bahwa kelompok yang berbeda tidak berbagi data negara apa pun. Ini berarti tidak ada dependensi bersama, memungkinkan transaksi dalam kelompok yang berbeda untuk dieksekusi secara paralel tanpa konflik. Transaksi dalam grup yang sama masih dijalankan secara serial.

Sebaliknya, TON sepenuhnya meninggalkan arsitektur eksekusi serial dan mengadopsi paradigma pengembangan yang dirancang khusus untuk paralelisme, menggunakan model Aktor untuk merekonstruksi lingkungan eksekusinya. Model Aktor, pertama kali diusulkan oleh Carl Hewitt pada tahun 1973, bertujuan untuk memecahkan kompleksitas negara bersama dalam program bersamaan tradisional melalui penyampaian pesan. Setiap Aktor memiliki keadaan dan perilaku pribadinya sendiri dan tidak berbagi informasi negara dengan Aktor lain. Model Aktor adalah model komputasi konkurensi yang mencapai pemrosesan paralel melalui penyampaian pesan. Dalam model ini, "Aktor" adalah unit dasar yang dapat menangani pesan yang diterima, membuat Aktor baru, mengirim pesan tambahan, dan memutuskan bagaimana menanggapi pesan berikutnya. Model Aktor harus memiliki karakteristik sebagai berikut:

Enkapsulasi dan Kemandirian: Setiap Aktor beroperasi sepenuhnya secara independen saat memproses pesan, memungkinkan pemrosesan pesan paralel tanpa gangguan.

Message Passing: Aktor berinteraksi hanya melalui pengiriman dan penerimaan pesan, dengan penyampaian pesan yang tidak sinkron.

Struktur Dinamis: Aktor dapat membuat Aktor tambahan saat runtime, memungkinkan model Aktor untuk memperluas sistem secara dinamis sesuai kebutuhan.

TON mengadopsi arsitektur ini untuk model kontrak pintarnya, yang berarti bahwa setiap kontrak pintar di TON didasarkan pada model Aktor dan memiliki penyimpanan yang sepenuhnya independen karena tidak bergantung pada data eksternal apa pun. Selain itu, panggilan ke kontrak pintar yang sama dijalankan di pesanan pesan dalam antrian terima. Hal ini memungkinkan transaksi dalam TON dilakukan secara paralel secara efisien, tanpa kekhawatiran tentang konflik. Namun, desain ini juga memperkenalkan beberapa tantangan baru. Untuk pengembang DApp, paradigma pengembangan mereka yang akrab akan terganggu dengan cara-cara berikut:

1. Panggilan Smart Contract Asinkron: Dalam TON, tidak mungkin untuk memanggil kontrak eksternal secara atom atau mengakses data kontrak eksternal dalam smart contract. Dalam Solidity, misalnya, sangat mudah bagi fungsi Kontrak A1 untuk memanggil fungsi Kontrak B2 atau mengakses data status tertentu melalui fungsi hanya-baca Kontrak C3, semuanya dalam satu transaksi. Namun, dalam TON, ini tidak dapat dicapai. Setiap interaksi dengan smart contract eksternal akan dijalankan secara asinkron dengan membuat transaksi baru, yang disebut sebagai pesan internal yang diprakarsai oleh smart contract. Proses eksekusi tidak dapat diblokir untuk menunggu hasilnya.

Misalnya, jika kita mengembangkan DEX dan mengikuti paradigma EVM umum, kita biasanya memiliki kontrak router terpadu untuk mengelola perutean transaksi, sementara setiap kumpulan secara independen mengelola data LP untuk pasangan perdagangan tertentu. Katakanlah kita memiliki dua kolam: USDT-DAI dan DAI-ETH. Ketika pengguna ingin membeli ETH langsung dengan USDT, mereka dapat menggunakan kontrak router untuk berinteraksi secara berurutan dengan dua kumpulan ini dalam satu transaksi atom. Namun, dalam TON, proses ini tidak semudah dan membutuhkan pendekatan pengembangan yang berbeda. Jika kita mencoba menggunakan kembali paradigma EVM ini, arus informasi akan melibatkan pesan eksternal yang diprakarsai oleh pengguna dan tiga pesan internal untuk menyelesaikan transaksi (perhatikan bahwa contoh ini adalah untuk menyoroti perbedaan; dalam pengembangan aktual, bahkan paradigma ERC20 perlu didesain ulang).

1. Pertimbangan yang cermat diperlukan untuk penanganan kesalahan dalam panggilan lintas kontrak, merancang fungsi pentalan yang sesuai untuk setiap interaksi antar-kontrak. Dalam sistem EVM mainstream, jika terjadi kesalahan selama eksekusi transaksi, seluruh transaksi dikembalikan ke keadaan awal. Ini sangat mudah dalam model single-threaded serial. Namun, dalam TON, karena panggilan antar kontrak dijalankan secara asinkron, jika terjadi kesalahan pada tahap selanjutnya, transaksi yang berhasil dieksekusi sebelumnya telah dikonfirmasi, berpotensi menyebabkan masalah. Oleh karena itu, TON telah memperkenalkan jenis pesan khusus yang disebut pesan pentalan. Jika terjadi kesalahan dalam eksekusi pesan internal berikutnya, kontrak yang dipicu dapat menggunakan fungsi pentalan yang dicadangkan dalam kontrak pemicu untuk mengatur ulang status tertentu dalam kontrak pemicu.

2. Dalam skenario yang kompleks, transaksi yang diterima pertama mungkin tidak diselesaikan terlebih dahulu, sehingga Anda tidak dapat mengasumsikan pesanan eksekusi tertentu. Dalam sistem kontrak pintar asinkron dan paralel, mendefinisikan pesanan pemrosesan dapat menjadi tantangan. Inilah sebabnya mengapa setiap pesan dalam TON memiliki waktu logisnya, yang dikenal sebagai waktu Lamport (lt). Ini membantu menentukan peristiwa mana yang memicu yang lain dan apa yang perlu validator proses terlebih dahulu. Dalam model sederhana, transaksi yang diterima pertama kali dieksekusi terlebih dahulu.

Dalam model ini, A dan B mewakili dua smart contract. Jika msg1_lt < msg2_lt, maka tx1_lt < tx2_lt dalam hal urutan.

Namun, dalam situasi yang lebih kompleks, aturan ini dapat dilanggar. Dokumentasi resmi memberikan contoh: misalkan kita memiliki tiga kontrak, A, B, dan C. Dalam satu transaksi, A mengirim dua pesan internal, msg1 dan msg2, satu ke B dan yang lainnya ke C. Meskipun mereka dibuat dalam pesanan tertentu (msg1 pertama, kemudian msg2), kita tidak dapat memastikan bahwa msg1 akan diproses sebelum msg2. Ketidakpastian ini muncul karena rute dari A ke B dan dari A ke C mungkin berbeda dalam panjang dan set validator. Jika kontrak ini berada dalam rantai pecahan yang berbeda, satu pesan mungkin memerlukan beberapa blok untuk mencapai kontrak target. Oleh karena itu, ada dua jalur transaksi yang mungkin, seperti yang diilustrasikan.

1. Dalam TON, penyimpanan persisten untuk smart contract menggunakan struktur directed acyclic graph (DAG) dengan sel sebagai unit. Data secara kompak dikompresi ke dalam sel sesuai dengan aturan pengkodean tertentu dan meluas ke bawah dengan cara yang DAG. Ini kontras dengan struktur berbasis hashmap yang digunakan dalam EVM untuk data negara. Karena algoritma akses data yang berbeda, TON menetapkan harga gas yang bervariasi untuk memproses data pada kedalaman yang berbeda; Pemrosesan data sel yang lebih dalam membutuhkan lebih banyak gas. Akibatnya, TON menghadapi jenis serangan DOS, di mana pengguna jahat membanjiri kontrak pintar dengan sejumlah besar pesan sampah, mengisi semua sel dangkal. Ini meningkatkan biaya penyimpanan untuk pengguna yang jujur. Sebaliknya, hashmap EVM memiliki kompleksitas kueri O (1), memastikan biaya gas yang konsisten dan menghindari masalah serupa. Oleh karena itu, pengembang Dapp TON harus menghindari penggunaan tipe data tak terbatas dalam smart contract. Ketika tipe data tak terbatas diperlukan, mereka harus dipartisi menggunakan sharding.

1. Beberapa fitur kurang unik, seperti persyaratan bagi smart contract untuk membayar sewa penyimpanan. Dalam TON, smart contract secara inheren dapat ditingkatkan dan dilengkapi dengan fungsi akun abstrak asli, yang berarti bahwa semua alamat dompet di TON smart contract, hanya tidak diinisialisasi. Pengembang perlu memperhatikan aspek-aspek ini.

Penafian:

1. Artikel ini dicetak ulang dari [Theblockbeats]. Semua hak cipta adalah milik penulis asli [Web3Mario]. Jika ada keberatan dengan cetak ulang ini, silakan hubungi tim Gate Learn, dan mereka akan segera menanganinya.
2. Penafian Kewajiban: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata milik penulis dan bukan merupakan saran investasi.
3. Penerjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.