TonBit, yang merupakan anak perusahaan BitsLab, menemukan kerentanan inti TON VM: menjelaskan secara detail penyebab kerentanan inti dan langkah-langkah mitigasinya
Laporan ini secara rinci menganalisis detail teknis kerentanan DoS inti yang ada di TON Virtual Machine, penyebab mendasar, dan kemungkinan metode serangan, sambil menunjukkan solusi efisien yang diajukan oleh tim TonBit.
Baru-baru ini, sistem Virtual Machine dari jaringan TON mengalami peningkatan keamanan signifikan. Tim keamanan TonBit di bawah naungan BitsLab berhasil menemukan dan membantu memperbaiki kerentanan inti yang dapat menyebabkan kehabisan sumber daya TON Virtual Machine. Kerentanan ini mengeksploitasi mekanisme rekursi saat Virtual Machine menangani penanaman Continuation, yang dapat disalahgunakan oleh kontrak jahat, menyebabkan kerusakan sistem dan ketidakstabilan jaringan.
Jika kerentanan ini dieksploitasi dengan jahat, tanpa harus menghabiskan TON, semua Node verifikasi mungkin akan mati dan mengancam ketersediaan jaringan. Dalam insiden ini, TonBit dengan kemampuan teknis yang luar biasa cepat menemukan kerentanan dan berhasil membuat solusi inovatif dengan mengganti rekursi dengan iterasi melalui penyesuaian aliran kontrol internal Virtual Machine, menciptakan lingkungan ekosistem TON yang lebih aman bagi pengguna. Tim resmi TON mengucapkan terima kasih khusus kepada TonBit atas kontribusi luar biasa mereka terhadap keamanan ekosistem.
Dalam laporan keamanan rinci ini, kami akan menganalisis secara mendalam penyebab, rincian teknis, dan solusi dari kerentanan ini. Laporan tersebut secara detail menjelaskan bagaimana kerentanan dieksploitasi dengan membangun rantai rekursif yang memicu serangan exhaustion sumber daya melalui Kedalaman Continuation, dan bagaimana kontrak jahat menghabiskan ruang tumpukan host melalui ekstensi tumpukan. Selain itu, kami juga akan menjelaskan bagaimana tim TonBit secara kolaboratif mengatasi masalah ini dengan menghilangkan cacat desain rantai rekursif, dan mengganti dengan mekanisme iterasi kolaboratif. Pembaruan ini tidak hanya signifikan meningkatkan stabilitas jaringan TON, tetapi juga memberikan referensi penting untuk keamanan dasar industri blockchain.
Studi Kasus: Kerentanan DoS di TON VM dan Langkah Pengurangan Risiko Terkait
Pengantar
Laporan ini menjelaskan kerentanan DoS (Denial of Service) di dalam TON Virtual Machine dan langkah-langkah mitigasi untuk mengatasi masalah ini. Kerentanan ini disebabkan oleh cara Virtual Machine memproses nested Continuation saat menjalankan kontrak. Kerentanan ini memungkinkan kontrak jahat membuat Continuation dan melakukan nesting Kedalaman dengan cara tertentu, yang memicu rekursi yang dalam selama proses evaluasi, menghabiskan ruang stack host dan membuat Virtual Machine berhenti berjalan. Untuk mengatasi masalah ini, Virtual Machine telah melakukan modifikasi pada pemrosesan Continuation dan aliran kontrol. Sekarang, Virtual Machine tidak lagi melakukan panggilan ekor berurutan melalui rantai Continuation, tetapi secara aktif mengiterasi rantai tersebut. Pendekatan ini memastikan penggunaan ruang stack host yang konstan, mencegah terjadinya stack overflow.
Ikhtisar
Menurut dokumen resmi, TON VM adalah Mesin Virtual berbasis tumpukan yang menggunakan Continuation-Passing Style (CPS, gaya penyebaran berkelanjutan) sebagai mekanisme aliran kontrolnya, yang digunakan untuk aliran internal dan Smart Contract. Register aliran kontrol dapat diakses oleh kontrak, sehingga memberikan fleksibilitas.
Dalam TVM, teori Continuation secara teoritis dapat dibagi menjadi tiga kategori:
OrdCont (yaitu, vmc \ _std), yang berisi fragmen TON ASM yang perlu dieksekusi, adalah objek tingkat pertama di TVM. Kontrak dapat secara eksplisit membuatnya saat runtime dan meneruskannya untuk menerapkan alur kontrol arbitrer.
Non-Continuation（lanjutan luar biasa），biasanya mengandung OrdCont sebagai komponen, dibuat melalui primitif iterasi eksplisit dan operasi implisit khusus, digunakan untuk menangani mekanisme aliran kontrol yang sesuai.
ArgContExt tambahan, mengemas Continuation lain untuk menyimpan data kontrol.
Selama proses eksekusi kontrak, Virtual Machine memasuki loop utama, mendekode satu karakter dari segmen kontrak setiap kali, dan menugaskan operasi yang sesuai ke pemroses yang tepat. Pemroses biasa akan segera kembali setelah menjalankan operasi yang sesuai.
Secara relatif, instruksi iterasi akan menggunakan Continuation yang disediakan sebagai komponen untuk membuat Non-Ordinary Continuation, dan melompat ke Non-Ordinary Continuation di konteks yang sesuai. Non-Ordinary Continuation sendiri mengimplementasikan logika saat melompat, dan melompat ke komponen tertentu berdasarkan kondisi. Misalnya, saat menggunakan instruksi WHILE, kita dapat menunjukkan proses ini dalam Gambar 1 (dengan mengabaikan kemungkinan keluar).
Gambar 1: Logika Kontinuasi Non-Umum
alasan sebenarnya
Dalam versi Virtual Machine yang rentan, lompatan ini akan menyebabkan panggilan ekor dinamis yang berkelanjutan, yang mengharuskan tumpukan host memelihara frame tumpukan untuk setiap lompatan (lihat Gambar 2).
Sebagai contoh, bagian lainnya dihilangkan untuk kesederhanaan menggunakan WhileCont.
Gambar 2: Rekursi tiga kali melompat untuk mengebor lebih dalam ke dalam jebakan
Dalam situasi yang ideal, ini tidak akan menjadi masalah karena komponen biasanya direpresentasikan sebagai OrdCont, yang melompat hanya menyimpan konteks saat ini, kemudian menunjukkan potongan yang dimilikinya, dieksekusi sebelum potongan kontrak yang tersisa, dan tidak memperkenalkan lebih banyak rekursi. Namun, Continuation non-standar secara teori dirancang untuk memungkinkan komponennya mengakses regist cc (c0) dalam TVM (yaitu, cabang set_c0 yang disebutkan sebelumnya). Oleh karena itu, kontrak dapat menyalahgunakan fitur ini untuk melakukan rekursi Kedalaman (yang akan dijelaskan nanti). Daripada mengubah implementasi fitur umum ini, menghilangkan rekursi secara langsung dalam proses melompat Continuation non-standar lebih jelas dan mudah dilakukan.
Dengan menggunakan Continuation yang tidak biasa yang telah diperoleh berulang kali untuk membangun Continuation yang tidak biasa di tingkat atas, kita dapat membuat Continuation yang bersarang dalam Kedalaman. Ketika Continuation yang bersarang ini dievaluasi, itu bisa menghabiskan ruang stack yang tersedia di host, menyebabkan sistem operasi mengirimkan sinyal SIGSEGV dan menghentikan proses Virtual Machine.
Gambar 3 menyediakan verifikasi konsep proses bersarang (PoC).
Gambar 3: Proses jebakan
Kami melihat bahwa dalam setiap iterasi, subjek selalu memperluas WhileCont{chkcond=true}. Dengan menjalankan cc yang dihasilkan dan disimpan dalam iterasi sebelumnya, kita akan mendapatkan tumpukan panggilan seperti ini:
Dapat dilihat bahwa ruang tumpukan memiliki ketergantungan linear terhadap tingkat penanaman (yaitu jumlah iterasi), yang menunjukkan kemungkinan kehabisan ruang tumpukan.
Tentang Pemanfaatan dalam Lingkungan Nyata
Dalam Blockchain Blok yang sebenarnya, pembatasan biaya bahan bakar membuat pembangunan kontrak berbahaya menjadi sangat sulit. Karena kompleksitas linear dari proses penanaman (desain TVM secara efektif mencegah konstruksi yang lebih murah melalui referensi diri), mengembangkan kontrak berbahaya yang layak dalam praktik bukanlah tugas yang mudah. Secara khusus, satu tingkat penanaman akan menghasilkan urutan panggilan yang mengonsumsi tiga frame stack utama (320 byte) dalam file biner debug, sementara dalam file biner rilis hanya mengonsumsi dua (256 byte, dua panggilan terakhir dalam satu baris). Untuk Node verifikasi yang berjalan pada sistem operasi POSIX modern, ukuran stack default adalah 8MiB, yang cukup untuk mendukung penanaman dengan lebih dari 30.000 tingkat dalam file biner rilis. Meskipun masih mungkin membangun kontrak yang dapat menghabiskan ruang stack, ini jauh lebih sulit daripada contoh di bagian sebelumnya.
Langkah Pengurangan
Patch ini mengubah perilaku lompatan dalam kasus penanaman Continuation. Kita dapat melihat tanda tangan lompatan Continuation telah berubah.
Mengambil UntilCont sebagai contoh, bagian lainnya dihilangkan untuk kesederhanaan.
Tidak lagi memanggil VmState::jump untuk melompat ke Continuation berikutnya, yang berarti melakukan tiga lompatan rekursif pada setiap Continuation dan menunggu nilai kembali untuk dipropagasikan ke belakang. Sekarang, lompatan Continuation hanya mengurai tingkat berikutnya dari Continuation, kemudian mengembalikan kendali ke Virtual Machine.
Virtual Machine bekerja sama untuk secara iteratif menafsirkan setiap tingkat lanjutan, hingga menemukan NullRef yang menunjukkan penyelesaian interpretasi rantai (seperti yang diimplementasikan dalam OrdCont atau ExuQuitCont). Selama proses iterasi ini, hanya satu lompatan kelanjutan dialokasikan di tumpukan utama, sehingga memastikan penggunaan tumpukan tetap konstan.
Kesimpulan
Untuk layanan yang membutuhkan ketersediaan tinggi, penggunaan rekursif dapat menjadi potensi Vektor Serangan. Ketika melibatkan logika yang ditentukan pengguna, menghentikan rekursi secara paksa dapat menjadi tantangan. Kerentanan DoS ini menunjukkan kasus ekstrem di mana fungsionalitas normal disalahgunakan secara tidak sengaja dalam situasi sumber daya terbatas (atau kondisi pembatasan lainnya). Jika rekursi bergantung pada input pengguna, masalah serupa dapat terjadi, ini sangat umum dalam primitif aliran kontrol Mesin Virtual.
Laporan ini secara rinci menganalisis detail teknis kerentanan DoS inti yang ada dalam TON Virtual Machine, penyebab mendasar, dan kemungkinan cara serangan, sambil menunjukkan solusi efisien yang diusulkan oleh Tim TonBit. Dengan mengubah mekanisme loncatan rekursif Virtual Machine menjadi pemrosesan iteratif, TonBit berhasil menemukan solusi untuk memperbaiki kerentanan, membantu memperbaiki kerentanan inti yang dapat menyebabkan kelumpuhan jaringan, dan memberikan perlindungan keamanan yang lebih kuat untuk ekosistem TON. Kejadian ini tidak hanya mencerminkan akumulasi yang mendalam dari TonBit dalam bidang keamanan teknologi dasar blockchain, tetapi juga memperlihatkan peran pentingnya sebagai Penyedia Jaminan Keamanan (SAP) resmi TON.
Sebagai mitra keamanan yang penting dalam ekosistem TON, TonBit selalu berada di garis depan dalam menjaga stabilitas jaringan Blok dan keamanan aset pengguna. Dari penemuan kerentanan hingga perancangan solusi, TonBit telah membentuk dasar yang kuat bagi perkembangan jangka panjang jaringan TON dengan kemampuan teknis yang kuat dan pemahaman mendalam terhadap perkembangan Blok. Selain itu, tim TonBit juga terus berupaya untuk meningkatkan keamanan arsitektur jaringan, perlindungan data pengguna, dan keamanan aplikasi Blok. Di masa depan, TonBit akan terus mendorong kemajuan teknologi keamanan melalui inovasi, memberikan dukungan dan perlindungan yang berkelanjutan bagi ekosistem TON dan seluruh industri Blok secara keseluruhan. Penemuan kerentanan dan kerja sama dalam perbaikan ini telah mendapatkan pengakuan yang tinggi dari pihak resmi TON, yang lebih mengkonsolidasikan posisi TonBit dalam bidang keamanan Blok dan menunjukkan komitmen yang kuat untuk mendorong perkembangan ekosistem Desentralisasi.
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
TonBit, yang merupakan anak perusahaan BitsLab, menemukan kerentanan inti TON VM: menjelaskan secara detail penyebab kerentanan inti dan langkah-langkah mitigasinya
Laporan ini secara rinci menganalisis detail teknis kerentanan DoS inti yang ada di TON Virtual Machine, penyebab mendasar, dan kemungkinan metode serangan, sambil menunjukkan solusi efisien yang diajukan oleh tim TonBit.
Baru-baru ini, sistem Virtual Machine dari jaringan TON mengalami peningkatan keamanan signifikan. Tim keamanan TonBit di bawah naungan BitsLab berhasil menemukan dan membantu memperbaiki kerentanan inti yang dapat menyebabkan kehabisan sumber daya TON Virtual Machine. Kerentanan ini mengeksploitasi mekanisme rekursi saat Virtual Machine menangani penanaman Continuation, yang dapat disalahgunakan oleh kontrak jahat, menyebabkan kerusakan sistem dan ketidakstabilan jaringan.
Jika kerentanan ini dieksploitasi dengan jahat, tanpa harus menghabiskan TON, semua Node verifikasi mungkin akan mati dan mengancam ketersediaan jaringan. Dalam insiden ini, TonBit dengan kemampuan teknis yang luar biasa cepat menemukan kerentanan dan berhasil membuat solusi inovatif dengan mengganti rekursi dengan iterasi melalui penyesuaian aliran kontrol internal Virtual Machine, menciptakan lingkungan ekosistem TON yang lebih aman bagi pengguna. Tim resmi TON mengucapkan terima kasih khusus kepada TonBit atas kontribusi luar biasa mereka terhadap keamanan ekosistem.
Dalam laporan keamanan rinci ini, kami akan menganalisis secara mendalam penyebab, rincian teknis, dan solusi dari kerentanan ini. Laporan tersebut secara detail menjelaskan bagaimana kerentanan dieksploitasi dengan membangun rantai rekursif yang memicu serangan exhaustion sumber daya melalui Kedalaman Continuation, dan bagaimana kontrak jahat menghabiskan ruang tumpukan host melalui ekstensi tumpukan. Selain itu, kami juga akan menjelaskan bagaimana tim TonBit secara kolaboratif mengatasi masalah ini dengan menghilangkan cacat desain rantai rekursif, dan mengganti dengan mekanisme iterasi kolaboratif. Pembaruan ini tidak hanya signifikan meningkatkan stabilitas jaringan TON, tetapi juga memberikan referensi penting untuk keamanan dasar industri blockchain.
Studi Kasus: Kerentanan DoS di TON VM dan Langkah Pengurangan Risiko Terkait
Pengantar
Laporan ini menjelaskan kerentanan DoS (Denial of Service) di dalam TON Virtual Machine dan langkah-langkah mitigasi untuk mengatasi masalah ini. Kerentanan ini disebabkan oleh cara Virtual Machine memproses nested Continuation saat menjalankan kontrak. Kerentanan ini memungkinkan kontrak jahat membuat Continuation dan melakukan nesting Kedalaman dengan cara tertentu, yang memicu rekursi yang dalam selama proses evaluasi, menghabiskan ruang stack host dan membuat Virtual Machine berhenti berjalan. Untuk mengatasi masalah ini, Virtual Machine telah melakukan modifikasi pada pemrosesan Continuation dan aliran kontrol. Sekarang, Virtual Machine tidak lagi melakukan panggilan ekor berurutan melalui rantai Continuation, tetapi secara aktif mengiterasi rantai tersebut. Pendekatan ini memastikan penggunaan ruang stack host yang konstan, mencegah terjadinya stack overflow.
Ikhtisar
Menurut dokumen resmi, TON VM adalah Mesin Virtual berbasis tumpukan yang menggunakan Continuation-Passing Style (CPS, gaya penyebaran berkelanjutan) sebagai mekanisme aliran kontrolnya, yang digunakan untuk aliran internal dan Smart Contract. Register aliran kontrol dapat diakses oleh kontrak, sehingga memberikan fleksibilitas.
Dalam TVM, teori Continuation secara teoritis dapat dibagi menjadi tiga kategori:
OrdCont (yaitu, vmc \ _std), yang berisi fragmen TON ASM yang perlu dieksekusi, adalah objek tingkat pertama di TVM. Kontrak dapat secara eksplisit membuatnya saat runtime dan meneruskannya untuk menerapkan alur kontrol arbitrer.
Non-Continuation（lanjutan luar biasa），biasanya mengandung OrdCont sebagai komponen, dibuat melalui primitif iterasi eksplisit dan operasi implisit khusus, digunakan untuk menangani mekanisme aliran kontrol yang sesuai.
ArgContExt tambahan, mengemas Continuation lain untuk menyimpan data kontrol.
Selama proses eksekusi kontrak, Virtual Machine memasuki loop utama, mendekode satu karakter dari segmen kontrak setiap kali, dan menugaskan operasi yang sesuai ke pemroses yang tepat. Pemroses biasa akan segera kembali setelah menjalankan operasi yang sesuai.
Secara relatif, instruksi iterasi akan menggunakan Continuation yang disediakan sebagai komponen untuk membuat Non-Ordinary Continuation, dan melompat ke Non-Ordinary Continuation di konteks yang sesuai. Non-Ordinary Continuation sendiri mengimplementasikan logika saat melompat, dan melompat ke komponen tertentu berdasarkan kondisi. Misalnya, saat menggunakan instruksi WHILE, kita dapat menunjukkan proses ini dalam Gambar 1 (dengan mengabaikan kemungkinan keluar).
Gambar 1: Logika Kontinuasi Non-Umum
alasan sebenarnya
Dalam versi Virtual Machine yang rentan, lompatan ini akan menyebabkan panggilan ekor dinamis yang berkelanjutan, yang mengharuskan tumpukan host memelihara frame tumpukan untuk setiap lompatan (lihat Gambar 2).
Sebagai contoh, bagian lainnya dihilangkan untuk kesederhanaan menggunakan WhileCont.
Gambar 2: Rekursi tiga kali melompat untuk mengebor lebih dalam ke dalam jebakan
Dalam situasi yang ideal, ini tidak akan menjadi masalah karena komponen biasanya direpresentasikan sebagai OrdCont, yang melompat hanya menyimpan konteks saat ini, kemudian menunjukkan potongan yang dimilikinya, dieksekusi sebelum potongan kontrak yang tersisa, dan tidak memperkenalkan lebih banyak rekursi. Namun, Continuation non-standar secara teori dirancang untuk memungkinkan komponennya mengakses regist cc (c0) dalam TVM (yaitu, cabang set_c0 yang disebutkan sebelumnya). Oleh karena itu, kontrak dapat menyalahgunakan fitur ini untuk melakukan rekursi Kedalaman (yang akan dijelaskan nanti). Daripada mengubah implementasi fitur umum ini, menghilangkan rekursi secara langsung dalam proses melompat Continuation non-standar lebih jelas dan mudah dilakukan.
Dengan menggunakan Continuation yang tidak biasa yang telah diperoleh berulang kali untuk membangun Continuation yang tidak biasa di tingkat atas, kita dapat membuat Continuation yang bersarang dalam Kedalaman. Ketika Continuation yang bersarang ini dievaluasi, itu bisa menghabiskan ruang stack yang tersedia di host, menyebabkan sistem operasi mengirimkan sinyal SIGSEGV dan menghentikan proses Virtual Machine.
Gambar 3 menyediakan verifikasi konsep proses bersarang (PoC).
Gambar 3: Proses jebakan
Kami melihat bahwa dalam setiap iterasi, subjek selalu memperluas WhileCont{chkcond=true}. Dengan menjalankan cc yang dihasilkan dan disimpan dalam iterasi sebelumnya, kita akan mendapatkan tumpukan panggilan seperti ini:
Dapat dilihat bahwa ruang tumpukan memiliki ketergantungan linear terhadap tingkat penanaman (yaitu jumlah iterasi), yang menunjukkan kemungkinan kehabisan ruang tumpukan.
Tentang Pemanfaatan dalam Lingkungan Nyata
Dalam Blockchain Blok yang sebenarnya, pembatasan biaya bahan bakar membuat pembangunan kontrak berbahaya menjadi sangat sulit. Karena kompleksitas linear dari proses penanaman (desain TVM secara efektif mencegah konstruksi yang lebih murah melalui referensi diri), mengembangkan kontrak berbahaya yang layak dalam praktik bukanlah tugas yang mudah. Secara khusus, satu tingkat penanaman akan menghasilkan urutan panggilan yang mengonsumsi tiga frame stack utama (320 byte) dalam file biner debug, sementara dalam file biner rilis hanya mengonsumsi dua (256 byte, dua panggilan terakhir dalam satu baris). Untuk Node verifikasi yang berjalan pada sistem operasi POSIX modern, ukuran stack default adalah 8MiB, yang cukup untuk mendukung penanaman dengan lebih dari 30.000 tingkat dalam file biner rilis. Meskipun masih mungkin membangun kontrak yang dapat menghabiskan ruang stack, ini jauh lebih sulit daripada contoh di bagian sebelumnya.
Langkah Pengurangan
Patch ini mengubah perilaku lompatan dalam kasus penanaman Continuation. Kita dapat melihat tanda tangan lompatan Continuation telah berubah.
Mengambil UntilCont sebagai contoh, bagian lainnya dihilangkan untuk kesederhanaan.
Tidak lagi memanggil VmState::jump untuk melompat ke Continuation berikutnya, yang berarti melakukan tiga lompatan rekursif pada setiap Continuation dan menunggu nilai kembali untuk dipropagasikan ke belakang. Sekarang, lompatan Continuation hanya mengurai tingkat berikutnya dari Continuation, kemudian mengembalikan kendali ke Virtual Machine.
Virtual Machine bekerja sama untuk secara iteratif menafsirkan setiap tingkat lanjutan, hingga menemukan NullRef yang menunjukkan penyelesaian interpretasi rantai (seperti yang diimplementasikan dalam OrdCont atau ExuQuitCont). Selama proses iterasi ini, hanya satu lompatan kelanjutan dialokasikan di tumpukan utama, sehingga memastikan penggunaan tumpukan tetap konstan.
Kesimpulan
Untuk layanan yang membutuhkan ketersediaan tinggi, penggunaan rekursif dapat menjadi potensi Vektor Serangan. Ketika melibatkan logika yang ditentukan pengguna, menghentikan rekursi secara paksa dapat menjadi tantangan. Kerentanan DoS ini menunjukkan kasus ekstrem di mana fungsionalitas normal disalahgunakan secara tidak sengaja dalam situasi sumber daya terbatas (atau kondisi pembatasan lainnya). Jika rekursi bergantung pada input pengguna, masalah serupa dapat terjadi, ini sangat umum dalam primitif aliran kontrol Mesin Virtual.
Laporan ini secara rinci menganalisis detail teknis kerentanan DoS inti yang ada dalam TON Virtual Machine, penyebab mendasar, dan kemungkinan cara serangan, sambil menunjukkan solusi efisien yang diusulkan oleh Tim TonBit. Dengan mengubah mekanisme loncatan rekursif Virtual Machine menjadi pemrosesan iteratif, TonBit berhasil menemukan solusi untuk memperbaiki kerentanan, membantu memperbaiki kerentanan inti yang dapat menyebabkan kelumpuhan jaringan, dan memberikan perlindungan keamanan yang lebih kuat untuk ekosistem TON. Kejadian ini tidak hanya mencerminkan akumulasi yang mendalam dari TonBit dalam bidang keamanan teknologi dasar blockchain, tetapi juga memperlihatkan peran pentingnya sebagai Penyedia Jaminan Keamanan (SAP) resmi TON.
Sebagai mitra keamanan yang penting dalam ekosistem TON, TonBit selalu berada di garis depan dalam menjaga stabilitas jaringan Blok dan keamanan aset pengguna. Dari penemuan kerentanan hingga perancangan solusi, TonBit telah membentuk dasar yang kuat bagi perkembangan jangka panjang jaringan TON dengan kemampuan teknis yang kuat dan pemahaman mendalam terhadap perkembangan Blok. Selain itu, tim TonBit juga terus berupaya untuk meningkatkan keamanan arsitektur jaringan, perlindungan data pengguna, dan keamanan aplikasi Blok. Di masa depan, TonBit akan terus mendorong kemajuan teknologi keamanan melalui inovasi, memberikan dukungan dan perlindungan yang berkelanjutan bagi ekosistem TON dan seluruh industri Blok secara keseluruhan. Penemuan kerentanan dan kerja sama dalam perbaikan ini telah mendapatkan pengakuan yang tinggi dari pihak resmi TON, yang lebih mengkonsolidasikan posisi TonBit dalam bidang keamanan Blok dan menunjukkan komitmen yang kuat untuk mendorong perkembangan ekosistem Desentralisasi.
Situs web resmi TonBit:
Akun Twitter resmi TonBit:
Telegram：
Linkedin:
Blog: #blogs
Kontak kebutuhan audit Telegram: @starchou