Sumber asli: akun Web3 Mario X
Penulis: @Web3 Mario
Pendahuluan: Dengan peluncuran Notcoin, game terbesar di ekosistem TON, di Binance dan dampak kekayaan besar yang disebabkan oleh model ekonomi token yang beredar sepenuhnya, TON telah menarik banyak perhatian dalam waktu singkat. Setelah mengobrol dengan seorang teman, saya mengetahui bahwa ambang batas teknis TON relatif tinggi, dan paradigma pengembangan DApp sangat berbeda dari protokol rantai publik arus utama, jadi saya meluangkan waktu untuk melakukan penelitian mendalam tentang topik terkait dan berbagi beberapa wawasan dengan Anda. Singkatnya, konsep desain inti TON adalah merekonstruksi protokol blockchain tradisional dengan cara "bottom-up", dan mencapai konkurensi tinggi dan skalabilitas tinggi dengan mengorbankan interoperabilitas.
Ide desain inti TON adalah konkurensi tinggi dan skalabilitas tinggi
Dapat dikatakan bahwa tujuan dari semua pemilihan teknologi kompleks di TON berasal dari upaya mencapai 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 banyak komponen. TON awalnya dikembangkan oleh pendiri Telegram Nikolai Durov dan timnya, dan kini didukung dan dikelola oleh komunitas global kontributor independen. Kelahirannya dimulai pada tahun 2017, ketika tim Telegram mulai mengeksplorasi sendiri solusi blockchain. Karena tidak ada blockchain L1 yang ada pada saat itu yang dapat mendukung basis pengguna Telegram yang berjumlah sembilan digit, mereka memutuskan untuk merancang blockchain mereka sendiri, yang kemudian disebut Telegram Open Network. Waktunya tiba pada tahun 2018. Untuk mendapatkan sumber daya yang dibutuhkan untuk mengimplementasikan TON, Telegram meluncurkan penjualan token Gram (yang kemudian berganti nama menjadi Toncoin) pada kuartal pertama tahun 2018. Pada tahun 2020, tim Telegram menarik diri dari proyek TON karena masalah regulasi. Selanjutnya, sekelompok kecil pengembang sumber terbuka dan pemenang kompetisi Telegram mengambil alih basis kode TON, mengganti nama proyek tersebut menjadi The Open Network, dan terus secara aktif mengembangkan blockchain hingga hari ini, dengan mengikuti prinsip-prinsip yang diuraikan dalam kertas putih asli TON.
Jadi karena dirancang sebagai lingkungan eksekusi terdesentralisasi untuk Telegram, tentu saja harus menghadapi dua masalah, permintaan bersamaan yang tinggi dan data yang sangat besar. Kita tahu bahwa dengan perkembangan teknologi hingga saat ini, Solana yang dikenal sebagai TPS tertinggi. memiliki TPS terukur tertinggi yaitu 65.000, yang jelas tidak cukup untuk mendukung ekosistem Telegram yang membutuhkan jutaan TPS. Pada saat yang sama, dengan penerapan Telegram berskala besar, jumlah data yang dihasilkannya telah melampaui batas. Sebagai sistem terdistribusi yang sangat berlebihan, blockchain mengharuskan setiap node di jaringan untuk menyimpan salinan lengkap datanya juga tidak realistis.
Oleh karena itu, untuk mengatasi dua masalah di atas, TON telah melakukan dua optimasi pada protokol blockchain utama:
Dengan menggunakan "Paradigma Sharding Tak Terbatas" untuk merancang sistem, kami memecahkan masalah redundansi data sehingga dapat membawa data besar dan mengurangi masalah kemacetan kinerja;
Dengan memperkenalkan lingkungan eksekusi paralel sepenuhnya berdasarkan model Aktor, TPS jaringan ditingkatkan secara signifikan;
Buat rantai blockchain - melalui kemampuan sharding tanpa batas, setiap akun memiliki rantai akun eksklusif
Kita sekarang tahu bahwa sharding telah menjadi solusi utama bagi sebagian besar protokol blockchain untuk meningkatkan kinerja dan mengurangi biaya, dan TON telah mengambil tindakan ekstrem dan mengusulkan paradigma sharding tak terbatas, yang disebut paradigma sharding tak terbatas Mengacu pada mengizinkan blockchain untuk secara dinamis menambah atau mengurangi jumlah pecahan berdasarkan beban jaringan. Paradigma ini memungkinkan TON untuk menangani transaksi skala besar dan operasi kontrak pintar sambil mempertahankan kinerja tinggi. Secara teori, TON dapat membangun rantai akun eksklusif untuk setiap akun dan memastikan interoperabilitas antar rantai melalui konsistensi tertentu.
Untuk memahaminya secara abstrak, ada empat tingkatan struktur rantai di TON:
Rantai Akun: Rantai lapisan ini mewakili rantai yang terdiri dari serangkaian transaksi yang terkait dengan suatu akun. Alasan mengapa transaksi dapat membentuk struktur rantai adalah karena untuk mesin negara, selama aturan eksekusinya konsisten, mesin negara akan melakukannya. hasil yang diperoleh setelah menerima instruksi dalam urutan yang sama adalah konsisten, sehingga pengurutan transaksi berantai diperlukan di semua sistem terdistribusi blockchain, dan TON tidak terkecuali. Rantai akun adalah unit komponen paling dasar dalam jaringan TON. Biasanya rantai akun merupakan konsep virtual, dan kecil kemungkinannya bahwa rantai akun independen benar-benar ada.
Shard Chain: Dalam sebagian besar konteks, shard chain adalah unit komponen sebenarnya di TON. Yang disebut shard chain adalah kumpulan rantai akun.
WorkChain: Ini juga bisa disebut serangkaian rantai sharding dengan aturan khusus, seperti membuat rantai kerja berbasis EVM dan menjalankan kontrak pintar Solidity di dalamnya. Secara teori, setiap orang di komunitas dapat menciptakan rantai kerjanya sendiri. Faktanya, membangunnya adalah tugas yang agak rumit, didahului dengan membayar biaya (mahal) untuk membuatnya dan mendapatkan 2/3 suara validator untuk menyetujui pembuatan rantai kerja Anda.
MasterChain: Terakhir, ada rantai khusus di TON yang disebut rantai master, yang bertanggung jawab untuk menghadirkan finalitas ke semua rantai shard. Setelah hash dari blok rantai shard digabungkan ke dalam blok rantai utama, blok rantai shard tersebut dan semua blok induknya dianggap final, artinya blok tersebut dapat dianggap tetap dan tidak dapat dipecahkan. Konten yang diubah direferensikan oleh blok berikutnya dari semua shard rantai.
Dengan mengadopsi paradigma seperti itu, jaringan TON memiliki tiga karakteristik sebagai berikut:
Sharding dinamis: TON dapat secara otomatis membagi dan menggabungkan rantai shard untuk beradaptasi dengan perubahan beban. Artinya, blok baru selalu dihasilkan dengan cepat dan transaksi tidak memerlukan waktu tunggu yang lama.
Sangat terukur: Melalui paradigma sharding tak terbatas, TON dapat mendukung jumlah shard yang hampir tidak terbatas, dan secara teoritis dapat mencapai kekuatan rantai kerja 2 hingga 60.
Kemampuan beradaptasi: Ketika beban meningkat pada suatu bagian jaringan, bagian tersebut dapat dibagi lagi menjadi lebih banyak pecahan untuk menangani peningkatan volume transaksi. Sebaliknya, ketika beban berkurang, pecahan dapat digabungkan untuk meningkatkan efisiensi.
Maka hal pertama yang perlu dihadapi oleh sistem multi-rantai adalah masalah komunikasi lintas rantai, terutama karena kemampuan sharding yang tidak terbatas. Ketika jumlah pecahan dalam jaringan mencapai tingkat tertentu, informasi dirutekan antar rantai akan menjadi Suatu hal yang sulit untuk dilakukan. Bayangkan ada 4 node dalam jaringan, dan setiap node bertanggung jawab untuk memelihara rantai kerja yang independen. Hubungan link menunjukkan bahwa selain bertanggung jawab untuk menyortir transaksi dalam rantai kerjanya sendiri, node juga perlu memantau dan memproses status. perubahan dalam rantai target, yang secara khusus diterapkan di TON dengan memantau pesan dalam antrian keluaran.
Misalkan akun A di rantai kerja 1 ingin mengirim pesan ke akun C di rantai kerja 3. Maka Anda perlu merancang masalah perutean pesan. Dalam contoh ini, ada dua jalur perutean, rantai kerja 1 -> rantai kerja 2-> rantai kerja 3, dan rantai kerja 1 -> rantai kerja 4 -> rantai kerja 3.
Saat menghadapi situasi yang lebih kompleks, algoritma perutean yang efisien dan berbiaya rendah diperlukan untuk menyelesaikan komunikasi pesan dengan cepat. TON memilih apa yang disebut "algoritma perutean hypercube" untuk mewujudkan penemuan rute komunikasi pesan lintas rantai. Apa yang disebut struktur hypercube mengacu pada topologi jaringan khusus. Hypercube berdimensi n terdiri dari 2^n simpul, dan setiap simpul dapat diidentifikasi secara unik dengan bilangan biner n-bit. Dalam struktur ini, dua simpul mana pun bertetangga jika keduanya berbeda hanya satu bit dalam representasi biner. Misalnya pada hypercube 3 dimensi, simpul 000 dan simpul 001 bertetangga karena hanya berbeda pada bit terakhir. Contoh di atas adalah hypercube 2 dimensi.
Dalam protokol perutean hypercube, proses perutean pesan dari rantai kerja sumber ke rantai kerja target dilakukan dengan membandingkan representasi biner dari rantai kerja sumber dan alamat rantai kerja target. Algoritme perutean menemukan jarak minimum (yaitu jumlah bit berbeda dalam representasi biner) antara dua alamat ini dan secara progresif meneruskan informasi melalui rantai kerja yang berdekatan hingga rantai kerja target tercapai. Metode ini memastikan bahwa paket data dikirimkan sepanjang jalur terpendek, sehingga meningkatkan efisiensi komunikasi jaringan.
Tentu saja, untuk menyederhanakan proses ini, TON juga telah mengusulkan solusi teknis yang optimis. Ketika pengguna dapat memberikan bukti valid dari jalur perutean tertentu, yang biasanya merupakan akar merkle trie, node dapat langsung mengenali kredibilitas jalur tersebut. pesan yang dikirimkan oleh pengguna, ini juga dikenal sebagai perutean hypercube instan.
Oleh karena itu, kita dapat melihat bahwa terdapat perbedaan yang jelas antara alamat di TON dan protokol blockchain lainnya. Sebagian besar protokol blockchain utama lainnya menggunakan hash yang sesuai dengan kunci publik di kunci publik dan pribadi yang dihasilkan oleh algoritma enkripsi elips sebagai alamatnya, karena alamat hanya digunakan sebagai alamat unik. Tidak perlu membawa fungsi pengalamatan perutean, dan alamat di TON terdiri dari dua bagian, (workchain_id, account_id), di mana workchain_id dikodekan sesuai dengan alamat algoritma perutean hypercube, yang mana tidak akan diuraikan di sini.
Ada hal lain yang mudah menimbulkan keraguan. Anda mungkin telah memperhatikan bahwa rantai utama memiliki hubungan tautan dengan setiap rantai yang berfungsi, jadi bukankah cukup jika semua informasi lintas rantai disampaikan melalui rantai utama, cukup saja. seperti Kosmos. Dalam konsep desain TON, rantai utama hanya digunakan untuk menangani tugas-tugas yang paling kritis, yaitu menjaga finalitas banyak rantai kerja. Bukan tidak mungkin untuk merutekan pesan melalui rantai utama, namun biaya penanganan yang diakibatkannya akan sangat mahal .
Terakhir, mari kita sebutkan secara singkat algoritma konsensusnya. TON mengadopsi metode BFT+PoS, yaitu, setiap pemangku kepentingan memiliki kesempatan untuk berpartisipasi dalam kontrak tata kelola pemilu TON akan secara acak memilih pemverifikasi pengemasan dari semua Staker secara berkala cluster, node yang dipilih sebagai validator akan mengemas dan menghasilkan blok melalui algoritma BFT. Jika mereka mengemas informasi yang salah atau melakukan kejahatan, token taruhan mereka akan hangus, dan jika tidak, mereka akan menerima hadiah blok. Ini pada dasarnya adalah pilihan umum, jadi saya tidak akan memperkenalkannya di sini.
Kontrak cerdas dan lingkungan eksekusi paralel sepenuhnya berdasarkan model Aktor
Perbedaan lain antara TON dan protokol blockchain arus utama adalah lingkungan eksekusi kontrak cerdasnya. Untuk menerobos keterbatasan TPS protokol blockchain arus utama, TON mengadopsi ide desain bottom-up dan menggunakan model Aktor untuk merekonstruksi kontrak pintar dan metode pelaksanaannya, sehingga memiliki kemampuan untuk diparalelkan sepenuhnya.
Kita tahu bahwa sebagian besar protokol blockchain arus utama menggunakan lingkungan eksekusi serial berulir tunggal. Mengambil Ethereum sebagai contoh, lingkungan eksekusinya EVM adalah mesin negara dengan transaksi sebagai input. Ketika node penghasil blok menyelesaikan transaksi dengan mengemas blok Setelah diurutkan , transaksi akan dieksekusi melalui EVM dalam urutan ini. Seluruh proses sepenuhnya serial dan single-threaded, yaitu hanya satu transaksi yang dapat dieksekusi pada waktu tertentu dikonfirmasi, hasil eksekusi akan Ada konsistensi dalam berbagai cluster terdistribusi. Pada saat yang sama, karena hanya satu transaksi yang dieksekusi secara serial pada waktu yang sama, artinya selama proses eksekusi, transaksi lain tidak mungkin dilakukan. memodifikasi data keadaan tertentu yang akan diakses, sehingga Interoperabilitas antar kontrak pintar tercapai. Misalnya, kami menggunakan USDT untuk membeli ETH melalui Uniswap. Saat transaksi dijalankan, distribusi LP pada pasangan perdagangan adalah nilai tertentu tidak demikian, ketika melakukan perhitungan kurva ikatan tertentu, jika LP lain menambah likuiditas baru, maka hasil perhitungannya akan menjadi hasil yang ketinggalan jaman, yang jelas tidak dapat diterima.
Namun arsitektur ini juga memiliki batasan yang jelas, yaitu hambatan TPS, dan hambatan ini tampak sangat lama di bawah prosesor multi-core saat ini. Sama seperti jika Anda menggunakan PC terbaru untuk memainkan beberapa game komputer lama, seperti Red Alert, When the jumlah unit tempur mencapai tingkat tertentu, Anda masih akan menemukan bahwa itu macet. Ini adalah masalah dengan arsitektur perangkat lunak.
Anda mungkin mendengar bahwa beberapa protokol telah memperhatikan masalah ini dan telah mengusulkan solusi paralelnya sendiri. Misalnya saja Solana, yang saat ini mengklaim memiliki TPS tertinggi, ia juga memiliki kemampuan untuk mengeksekusi secara paralel. Namun, ide desainnya berbeda dengan TON. Di Solana, ide intinya adalah membagi semua transaksi menjadi beberapa grup sesuai dengan ketergantungan eksekusi, dan tidak ada data status yang dibagikan ke grup yang berbeda. Artinya, tidak ada ketergantungan yang identik, sehingga transaksi dalam kelompok yang berbeda dapat dieksekusi secara paralel tanpa khawatir akan konflik, sedangkan transaksi dalam kelompok yang sama tetap dieksekusi secara serial tradisional.
Di TON, ia sepenuhnya meninggalkan arsitektur eksekusi serial dan sebagai gantinya mengadopsi paradigma pengembangan yang dirancang khusus untuk paralelisme, model Aktor, untuk merekonstruksi lingkungan eksekusi. Model Aktor disebut pertama kali diusulkan oleh Carl Hewitt pada tahun 1973 untuk memecahkan kompleksitas keadaan bersama dalam program konkuren tradisional melalui penyampaian pesan. Setiap Aktor mempunyai keadaan dan perilaku pribadinya sendiri, dan tidak ada informasi keadaan yang dibagikan kepada Aktor lain. Model Aktor adalah model komputasi komputasi konkuren yang mengimplementasikan komputasi paralel melalui penyampaian pesan. Dalam model ini, seorang "Aktor" adalah unit kerja dasar, yang mampu memproses pesan yang diterima, membuat Aktor baru, mengirimkan lebih banyak pesan, dan memutuskan bagaimana menanggapi pesan berikutnya. Model Aktor harus memiliki karakteristik berikut:
Enkapsulasi dan independensi: Setiap aktor sepenuhnya independen saat memproses pesan dan dapat memproses pesan secara paralel tanpa saling mengganggu.
Penyampaian pesan: Aktor berinteraksi satu sama lain hanya dengan mengirim dan menerima pesan, dan penyampaian pesan tidak sinkron.
Struktur dinamis: Aktor dapat membuat lebih banyak Aktor pada waktu proses. Sifat dinamis ini memungkinkan model Aktor untuk menskalakan sistem sesuai kebutuhan.
TON mengadopsi arsitektur ini untuk merancang model kontrak pintar, yang berarti bahwa di TON, setiap kontrak pintar adalah model Aktor dengan ruang penyimpanan yang sepenuhnya independen. Karena tidak bergantung pada data eksternal apa pun. Selain itu, panggilan ke kontrak pintar yang sama tetap dijalankan sesuai urutan pesan dalam antrian penerimaan, sehingga transaksi di TON dapat dieksekusi secara efisien secara paralel tanpa khawatir akan konflik.
Namun skema desain seperti itu juga membawa beberapa dampak baru. Bagi pengembang DApp, paradigma pengembangan yang biasa mereka gunakan akan dipatahkan, sebagai berikut:
1. Panggilan asinkron antar kontrak pintar: Tidak mungkin memanggil kontrak eksternal secara atom atau mengakses data kontrak eksternal dalam kontrak pintar TON. Kita tahu bahwa dalam Soliditas, fungsi 1 kontrak A memanggil fungsi 2 kontrak B. Atau mengakses data negara tertentu melalui fungsi read-only n3 kontrak C. Seluruh proses bersifat atomik dan dieksekusi dalam sebuah transaksi. Ini adalah hal yang sangat mudah, namun, di TON, ini tidak akan mungkin dilakukan. Semua interaksi dengan kontrak pintar eksternal akan dieksekusi secara asinkron dengan mengemas transaksi baru. Transaksi semacam itu yang diprakarsai oleh kontrak pintar juga disebut pesan internal. Dan itu tidak dapat diblokir selama eksekusi untuk mendapatkan hasil eksekusi.
Misalnya, jika kita mengembangkan DEX, jika kita mengadopsi paradigma umum dalam EVM, biasanya akan ada kontrak router terpadu yang digunakan untuk mengelola perutean transaksi, dan setiap Pool secara independen mengelola data LP yang terkait dengan pasangan perdagangan tertentu saat ini ada dua Pool USDT-DAI dan DAI-ETH. Ketika pengguna ingin membeli ETH secara langsung melalui USDT, dia dapat meminta dua kumpulan ini secara berurutan dalam satu transaksi melalui kontrak router untuk menyelesaikan transaksi atom. Namun penerapannya di TON tidaklah mudah. Perlu dipikirkan paradigma pembangunan yang baru. Jika paradigma ini tetap digunakan kembali, arus informasi mungkin akan seperti ini. Permintaan ini akan disertai dengan pesan eksternal yang diprakarsai oleh pengguna dan tiga pesan internal selesai (perhatikan bahwa ini digunakan untuk menggambarkan perbedaannya. Dalam perkembangan nyata, bahkan paradigma ERC 20 harus didesain ulang).
2. Penting untuk mempertimbangkan secara hati-hati proses pemrosesan kesalahan eksekusi saat melakukan panggilan antar kontrak, dan merancang fungsi pentalan yang sesuai untuk setiap panggilan antar kontrak. Kita tahu bahwa dalam EVM arus utama, ketika terjadi masalah selama eksekusi transaksi, seluruh transaksi akan dibatalkan, yaitu disetel ulang ke kondisi awal eksekusi. Hal ini mudah dipahami dalam model serial single-threaded. Namun, di TON, karena panggilan antar kontrak dieksekusi secara asinkron, bahkan jika terjadi kesalahan pada tautan berikutnya, karena transaksi yang berhasil dieksekusi sebelumnya telah dieksekusi dan dikonfirmasi, hal ini dapat menimbulkan masalah. Oleh karena itu, jenis pesan khusus diatur di TON, yang disebut pesan pentalan. Artinya, ketika terjadi kesalahan dalam proses eksekusi selanjutnya yang dipicu oleh pesan internal, kontrak yang dipicu dapat memicu peristiwa tertentu dalam kontrak dengan memicu pentalan. fungsi yang dicadangkan oleh kontrak.
3. Dalam beberapa situasi kompleks, transaksi yang diterima pertama kali mungkin tidak dieksekusi terlebih dahulu, sehingga hubungan waktu ini tidak dapat ditentukan sebelumnya. Dalam sistem panggilan kontrak pintar asinkron dan paralel, menentukan urutan pemrosesan operasi bisa jadi sulit. Inilah sebabnya mengapa setiap pesan di TON memiliki waktu logisnya waktu Lamport (selanjutnya disebut lt). Ini digunakan untuk memahami peristiwa mana yang memicu peristiwa lain dan apa yang perlu ditangani validator terlebih dahulu. Untuk model sederhana, transaksi yang diterima terlebih dahulu harus dieksekusi terlebih dahulu.
Dalam model ini, A dan B masing-masing mewakili dua kontrak pintar, dan terdapat hubungan waktu jika pesan 1 _lt < pesan 2 _lt, maka tx 1 _lt < tx 2 _lt.
Namun, dalam situasi yang lebih kompleks, aturan ini dilanggar. Ada contohnya di dokumentasi resmi, dengan asumsi kita memiliki tiga kontrak A, B, dan C. Dalam suatu transaksi, A mengirimkan dua pesan internal pesan 1 dan pesan 2: satu ke B dan yang lainnya ke C. Meskipun dibuat dalam urutan yang tepat (pesan pertama 1 , lalu pesan 2 ), kami tidak dapat memastikan bahwa pesan 1 akan diproses sebelum pesan 2 . Hal ini karena rute dari A ke B dan dari A ke C mungkin berbeda panjang dan set validatornya. Jika kontrak ini berada pada rantai pecahan yang berbeda, salah satu pesan mungkin memerlukan beberapa blok untuk mencapai kontrak target. Artinya, kita memiliki dua kemungkinan jalur perdagangan, seperti yang ditunjukkan pada gambar.
4. Di TON, penyimpanan persisten kontrak pintarnya menggunakan grafik asiklik terarah dengan Sel sebagai unit sebagai struktur datanya. Data akan dikompres secara kompak ke dalam Sel sesuai dengan aturan pengkodean, dan pada saat yang sama sesuai dengan aturan pengkodean grafik asiklik terarah. Caranya meluas ke bawah, yang berbeda dari organisasi struktural data status berbasis hashmap di EVM. Karena algoritme permintaan data yang berbeda, TON menetapkan harga Gas yang berbeda untuk kedalaman pemrosesan data yang berbeda , semakin banyak Gas yang dibutuhkan. Semakin tinggi, sehingga ada paradigma serangan DOS di TON, yaitu, beberapa pengguna jahat menempati semua sel dangkal dalam kontrak pintar tertentu dengan mengirimkan pesan spam dalam jumlah besar, yang berarti bahwa semakin banyak Gas yang dibutuhkan. biaya penyimpanan pengguna yang jujur akan menjadi semakin tinggi. Di EVM, karena kompleksitas kueri hashmap adalah o(1), ia memiliki Gas yang sama dan tidak akan ada masalah serupa. Oleh karena itu, pengembang TON Dapp harus mencoba menghindari tipe data tidak terbatas dalam kontrak pintar. Ketika tipe data tak terbatas muncul, tipe data tersebut harus dipecah melalui sharding.
5. Ada juga beberapa fitur yang kurang istimewa, seperti kontrak pintar yang perlu membayar sewa untuk penyimpanan, kontrak pintar di TON secara alami dapat ditingkatkan, dan fungsi akun abstrak asli, yaitu semua alamat dompet di TON adalah kontrak pintar. hanya saja tidak diinisialisasi, dll. Hal ini mengharuskan pengembang untuk memberikan perhatian yang cermat.
Di atas adalah beberapa pengalaman saya dalam mempelajari teknologi terkait TON selama periode ini. Saya ingin membaginya dengan Anda. Saya harap Anda dapat mengoreksi saya jika saya membuat kesalahan , ekosistem TON pasti akan berfungsi sebagai platform untuk Web3. Membawa beberapa aplikasi baru, teman-teman yang tertarik dengan pengembangan TON DApp juga dapat menghubungi saya dan berdiskusi dengan kami.
