Dalam bidang teknologi blockchain yang berkembang pesat, TON (The Open Network) semakin mendapatkan perhatian dari para pengembang sebagai platform blockchain yang efisien dan fleksibel. Arsitektur dan fitur unik TON menyediakan alat yang kuat dan berbagai kemungkinan untuk pengembangan aplikasi terdesentralisasi.

Namun, dengan peningkatan fungsionalitas dan kompleksitas, keamanan kontrak pintar menjadi lebih kritis. FunC, bahasa pemrograman kontrak pintar di TON, dikenal karena fleksibilitas dan efisiensinya, tetapi juga memiliki banyak risiko dan tantangan potensial. Menulis kontrak pintar yang aman dan dapat diandalkan memerlukan pengembang untuk memiliki pemahaman mendalam tentang karakteristik FunC dan risiko potensial yang terlibat.

Artikel ini akan memberikan analisis mendalam tentang fitur terkait smart contract pada blockchain TON, serta kerentanan dalam smart contract TON yang sering terlewatkan.

Analisis Fitur Asynchronous TON dan Mekanisme Akun

Panggilan Asynchronous dalam Kontrak Pintar

Sharding Jaringan dan Komunikasi Asynchronous

Blockchain TON dirancang dengan tiga jenis rantai: Masterchain, Workingchains, dan Shardchains.

Masterchain adalah inti dari seluruh jaringan, bertanggung jawab untuk menyimpan metadata dan mekanisme konsensus seluruh jaringan. Ini mencatat status semua Workingchain dan Shardchain dan memastikan konsistensi dan keamanan jaringan. Workingchain adalah blockchain independen, dengan maksimal 2^32 rantai, bertanggung jawab untuk menangani jenis transaksi dan smart contract tertentu. Setiap Workingchain dapat memiliki aturan dan fitur sendiri untuk memenuhi kebutuhan aplikasi yang berbeda. Shardchain adalah sub-chain dari Workingchain, digunakan untuk membagi beban kerja Workingchain, meningkatkan kapasitas pemrosesan dan skalabilitas. Setiap Workingchain dapat dibagi menjadi hingga 2^60 Shardchain, dengan Shardchain menangani beberapa transaksi secara independen untuk mencapai pemrosesan paralel yang efisien.

Secara teori, setiap akun dapat secara eksklusif menduduki Shardchain, dengan setiap akun secara independen mempertahankan saldo COIN/TOKEN-nya. Transaksi antar akun dapat sepenuhnya diparalelkan. Akun berkomunikasi melalui pesan asinkron, dan jalur untuk pesan melakukan perjalanan antara Shardchains adalah log_16(N) - 1, di mana N adalah jumlah Shardchains.

Sumber gambar: https://frontierlabzh.medium.com/ton-weixin-e1d3ae3b3574Di dunia web3, interaksi dilakukan melalui pengiriman dan penerimaan pesan dalam Ton. Pesan-pesan ini dapat bersifat internal (biasanya dikirim oleh smart contract yang berinteraksi satu sama lain) atau eksternal (dikirim oleh sumber eksternal). Proses pengiriman pesan tidak memerlukan respons segera dari kontrak target, sehingga pengirim dapat melanjutkan mengeksekusi logika yang tersisa. Mekanisme pengiriman pesan asinkronis ini menawarkan fleksibilitas dan skalabilitas yang lebih besar dibandingkan dengan panggilan sinkron Ethereum, mengurangi bottleneck kinerja yang disebabkan oleh menunggu respons, sambil juga memperkenalkan tantangan dalam menangani konkurensi dan kondisi race.

Format dan struktur pesan

Dalam TON, pesan umumnya mencakup informasi seperti pengirim, penerima, jumlah, dan isi pesan. Isi pesan dapat terdiri dari panggilan fungsi, transfer data, atau konten kustom lainnya. Format pesan TON dirancang agar fleksibel dan dapat diperluas, memungkinkan komunikasi yang efisien dari berbagai jenis informasi antara kontrak yang berbeda.

Antrian pesan dan pemrosesan status

Setiap kontrak memelihara antrian pesan untuk menyimpan pesan yang belum diproses. Selama eksekusi, kontrak memproses pesan satu per satu dari antrian. Karena pemrosesan pesan bersifat asinkron, status kontrak tidak akan segera diperbarui setelah menerima pesan.

Keuntungan dari pesan asinkron

• Mekanisme Sharding yang Efisien: Mekanisme asinkron TON sangat kompatibel dengan desain sharding-nya. Setiap pecahan secara independen menangani pesan kontrak dan perubahan status, menghindari penundaan yang disebabkan oleh sinkronisasi lintas-beling. Desain ini meningkatkan throughput dan skalabilitas jaringan secara keseluruhan.

• Konsumsi Sumber Daya yang Lebih Rendah: Pesan asinkron tidak memerlukan tanggapan segera, memungkinkan kontrak TON dieksekusi di beberapa blok dan menghindari konsumsi sumber daya yang berlebihan dalam satu blok. Ini memungkinkan TON untuk mendukung kontrak pintar yang lebih kompleks dan memerlukan sumber daya yang lebih intensif.

• Toleransi Kesalahan dan Keandalan: Mekanisme pengiriman pesan asinkron meningkatkan toleransi kesalahan sistem. Misalnya, jika kontrak tidak dapat merespons pesan secara tepat waktu karena keterbatasan sumber daya atau alasan lainnya, pengirim dapat melanjutkan pemrosesan logika lainnya, mencegah sistem terhenti karena penundaan dalam satu kontrak.

Tantangan desain kontrak asinkron

• Masalah Konsistensi Negara: Karena sifat asinkron dari penyampaian pesan, kontrak dapat menerima pesan yang berbeda pada waktu yang berbeda, yang mengharuskan pengembang untuk memberikan perhatian khusus pada konsistensi negara. Saat merancang kontrak, sangat penting untuk mempertimbangkan bagaimana pesanan pesan yang berbeda dapat memengaruhi perubahan status dan memastikan sistem mempertahankan konsistensi dalam semua kondisi.

• Race Conditions dan Perlindungan: Proses pengolahan pesan asinkron memperkenalkan masalah kondisi perlombaan potensial, di mana beberapa pesan mungkin secara bersamaan mencoba untuk memodifikasi status kontrak. Pengembang perlu mengimplementasikan mekanisme penguncian yang tepat atau menggunakan operasi transaksional untuk mencegah konflik status.

• Pertimbangan Keamanan: Kontrak asinkron rentan terhadap risiko seperti serangan man-in-the-middle atau serangan pengulangan saat menangani komunikasi antar kontrak. Oleh karena itu, saat merancang kontrak asinkron, penting untuk mengatasi risiko keamanan potensial ini dan mengambil tindakan pencegahan, seperti menggunakan timestamp, angka acak, atau pendekatan tanda tangan ganda.

Model ledger

TON (The Open Network) menggunakan abstraksi akun yang unik dan model ledger dalam merancang infrastruktur blockchain-nya. Fleksibilitas model ini tercermin dalam bagaimana ia mengelola status akun, pengiriman pesan, dan eksekusi kontrak.

abstraksi akun

Model akun TON menggunakan abstraksi berbasis kontrak, di mana setiap akun dapat dilihat sebagai kontrak. Ini agak mirip dengan model abstraksi akun Ethereum tetapi lebih fleksibel dan umum. Di TON, akun bukan hanya wadah untuk aset; mereka juga mencakup kode kontrak dan data status. Setiap akun terdiri dari kode, data, dan logika penanganan pesan.

Struktur Akun: Setiap akun TON memiliki alamat unik, yang dihasilkan dari kombinasi nilai hash kode akun, data awal pada penempatan, dan parameter lainnya. Ini berarti bahwa kode yang sama dan data awal yang ditempatkan di lingkungan yang berbeda (misalnya, blockchain atau shard yang berbeda) dapat menghasilkan alamat yang berbeda.

Fleksibilitas: Karena setiap akun dapat menjalankan kode kontraknya sendiri, akun TON dapat mengimplementasikan logika yang sangat kompleks. Akun bukan hanya pemegang saldo sederhana tetapi dapat mengatasi transisi keadaan yang kompleks, komunikasi pesan antar akun, dan bahkan otomatisasi berdasarkan kondisi-kondisi tertentu. Hal ini membuat model akun TON lebih scalable dan fleksibel dibandingkan dengan model akun blockchain tradisional.

Struktur Ledger

Struktur ledger TON dirancang untuk menangani transaksi paralel dalam skala besar dengan efisien, mendukung pengiriman pesan asinkron dan operasi multi-shard. Status setiap akun disimpan dalam struktur pohon Merkle, memberikan kemampuan validasi status yang efisien.

Penyimpanan Status

Informasi status akun disimpan dalam penyimpanan persisten dan diorganisir melalui pohon Merkle untuk memastikan integritas dan keamanan. Desain ini juga mendukung kueri dan verifikasi yang efisien dari status, terutama dalam transaksi lintas shard.

Sebuah akun atau keadaan kontrak pintar umumnya mencakup hal berikut:

1. 1. Saldo mata uang dasar 2. Saldo mata uang lainnya 3. Kode kontrak pintar (atau hash-nya) 4. Data persisten dari kontrak pintar (atau hash Merkle-nya) 5. Statistik tentang jumlah unit penyimpanan persisten dan penggunaan byte mentah 6. Timestamp terbaru pembayaran ke penyimpanan persisten kontrak pintar (pada dasarnya nomor blok rantai utama) 7. Kunci publik yang diperlukan untuk mentransfer mata uang dan mengirim pesan dari akun ini (opsional; secara default, ini sama dengan account_id itu sendiri). Dalam beberapa kasus, kode pemeriksaan tanda tangan yang lebih kompleks mungkin ditemukan di sini, serupa dengan output transaksi Bitcoin; dalam kasus seperti itu, account_id akan menjadi hash kode ini.

Tidak semua informasi diperlukan untuk setiap akun. Misalnya, kode kontrak pintar hanya relevan untuk kontrak pintar, bukan untuk akun "sederhana". Selain itu, sementara setiap akun harus memiliki saldo bukan nol dari mata uang dasar (misalnya, Gram untuk rantai kerja dasar dan rantai pecahan), saldo mata uang lainnya mungkin nol. Untuk menghindari mempertahankan data yang tidak digunakan, jenis jumlah-produk didefinisikan selama pembuatan rantai kerja, menggunakan byte penandaan yang berbeda untuk membedakan berbagai "fungsi konstruktor." Pada akhirnya, status akun disimpan sebagai kumpulan unit dalam penyimpanan persisten TVM.

Pengiriman Pesan dan Pemrosesan

Struktur ledger TON mencakup dukungan bawaan untuk pengiriman pesan asinkron. Setiap akun dapat memproses pesan yang diterima secara independen dan memperbarui statusnya. Mekanisme pengiriman pesan asinkron ini memungkinkan interaksi kompleks antara akun tanpa memengaruhi operasi normal akun lain karena keterlambatan dalam operasi tunggal mana pun.

model Gas

TON (The Open Network) secara signifikan mengoptimalkan efisiensi eksekusi smart contract melalui model biaya gas yang unik. Model biaya gas ini digunakan untuk mengukur dan membatasi sumber daya yang dikonsumsi selama eksekusi smart contract. Dibandingkan dengan blockchain tradisional seperti Ethereum, model TON lebih kompleks dan efisien, memungkinkan pengelolaan konsumsi sumber daya yang lebih tepat selama eksekusi kontrak.

Model gas TON dapat mengukur dengan akurat sumber daya komputasi, operasi penyimpanan, dan biaya pengiriman pesan yang dikonsumsi selama eksekusi kontrak pintar. Dengan menyediakan pengukuran yang rinci untuk sumber daya seperti komputasi, penyimpanan, dan pesan, model gas TON mencegah operasi dengan kompleksitas berlebihan mengkonsumsi terlalu banyak sumber daya. Dengan membatasi konsumsi gas, TON memastikan bahwa setiap node jaringan dapat mengalokasikan sumber daya komputasi secara adil, menghindari penggunaan berlebihan sumber daya jaringan oleh kontrak atau operasi tunggal.

TON mendukung pemrosesan paralel untuk smart contract, memungkinkan banyak kontrak berjalan secara simultan pada shard yang berbeda tanpa saling menghalangi. Dalam desain ini, model gas terintegrasi dengan mekanisme eksekusi paralel dan sharding. Dengan memproses kontrak secara paralel di beberapa shard, TON dapat mendistribusikan komputasi dan pembayaran gas di beberapa node dan rantai, menghindari kemacetan jaringan sambil memaksimalkan penggunaan sumber daya.

Model gas TON mencakup mekanisme penyesuaian dinamis yang memungkinkan biaya gas disesuaikan berdasarkan beban jaringan real-time. Ini berarti bahwa selama periode beban jaringan lebih rendah, pengguna dapat mengeksekusi kontrak dengan biaya gas yang lebih rendah, mendorong operasi selama waktu di luar jam sibuk dan seimbang penggunaan sumber daya jaringan. Mekanisme ini tidak hanya meningkatkan pengalaman pengguna tetapi juga mengontrol penggunaan sumber daya puncak melalui pendekatan pasar.

Kontrak pintar TON mudah diabaikan celah-celah

Di artikel analisis keamanan sebelumnya kamiPada TON, kami telah merinci kerentanan keamanan umum dalam ekosistem TON. Untuk referensi lebih lanjut, silakan lihat tabel di bawah ini:

Artikel ini akan berfokus pada kerentanan dalam kontrak TON yang sering terlewatkan, seperti yang dirangkum oleh tim kami:

(1) Optimisasi Keterbacaan Kode

Dalam kontrak pintar TON, angka sering digunakan untuk menyimpan data yang terkait dengan pengiriman pesan. Sebagai contoh, dalam kode di bawah ini, beberapa contoh angka digunakan untuk mewakili pengidentifikasi dan panjang penyimpanan data yang sesuai, yang secara signifikan mengurangi keterbacaan dan keberlanjutan kode. Pengembang lain mungkin menemukan sulit untuk memahami arti dan tujuan dari angka-angka ini saat membaca kode. Untuk meningkatkan keterbacaan dan keberlanjutan, disarankan untuk mendefinisikan nilai-nilai numerik kunci sebagai konstan bernama. Sebagai contoh, tentukan0x18sebagaiNON_BOUNCEABLE.

1. check_std_addr(address);pesan = begin_cell() store_uint(0x18, 6) ;; nobounce store_slice(alamat) store_coins(jumlah) store_uint(0, 1 + 4 + 4 + 64 + 32 + 1 + 1) end_cell();send_raw_message(pesan, 1);

Selain itu, untuk pesan kesalahan dalam kondisi penilaian kontrak, juga disarankan untuk mendefinisikan variabel-variabel yang sesuai untuk menggantikan kode kesalahan tersebut.

(2) Menggunakan end_parse()untuk Memastikan Integritas Data

Dalam kontrak TON, penguraian data mengikuti urutan tetap, memuat jenis data tertentu selangkah demi selangkah dari data mentah. Metode penguraian ini memastikan konsistensi dan akurasi data, seperti yang diilustrasikan di bawah ini:

Perhatikan bahwa end_parse()digunakan untuk memeriksa apakah irisan data kosong. Jika irisan tidak kosong, fungsi akan melempar pengecualian. Hal ini memastikan bahwa format dan konten data sesuai dengan yang diharapkan. Jika end_parse()fungsi mendeteksi data yang tersisa di dalam slice, hal ini mungkin menunjukkan bahwa parsing data tidak berjalan dengan semestinya atau ada masalah dengan format data. Oleh karena itu, dengan memanggil end_parse(), Anda dapat memverifikasi apakah ada kelalaian atau anomali selama proses penguraian.

(3) Pengecualian yang Disebabkan oleh Penyimpanan Data dan Jenis yang Tidak Cocok

Ini terutama menyangkut pencocokan int dan UINTjenis penyimpanan. Misalnya, dalam kode berikut, store_int()fungsi digunakan untuk menyimpan sebuahint Nilai dari -42, tetapi load_uint()digunakan untuk memuat nilai ini, yang mungkin mengakibatkan pengecualian.

(4) Penggunaan yang Tepat dari inline_refdaninlineModifier

Pertama, penting untuk membedakan antara Inlinedaninline_refmodifikator:

inline: Fungsi-fungsi dengan inline Pengubah memiliki kode mereka dimasukkan langsung di situs panggilan setiap kali mereka dipanggil. Ini berarti bahwa kode aktual fungsi disalin ke lokasi panggilan daripada dieksekusi melalui lompatan fungsi, yang mengurangi overhead panggilan fungsi tetapi dapat menyebabkan duplikasi kode.

inline_ref: Fungsi dengan yang inline_refmodifier menyimpan kode mereka di sel terpisah. Setiap kali fungsi dipanggil, TVM menjalankan kode yang disimpan di sel melalui CALLREFperintah, menghindari duplikasi kode dan meningkatkan efisiensi untuk fungsi yang lebih kompleks atau yang dipanggil beberapa kali.

Singkatnya, gunakan inlineuntuk fungsi sederhana untuk mengurangi overhead panggilan, tetapi perhatikan kemungkinan duplikasi kode. Gunakaninline_refuntuk fungsi yang lebih besar atau sering dipanggil untuk meningkatkan efisiensi dan menghindari pengulangan kode.

(5) Menentukan Rantai Kerja yang Benar

TON memungkinkan pembuatan hingga 2^32 workchain, masing-masing dapat dibagi lagi menjadi hingga 2^60 shard. Awalnya, terdapat dua workchain: masterchain (-1) dan basechain (0). Saat menghitung alamat target dalam kontrak, sangat penting untuk menentukan ID workchain yang benar untuk memastikan bahwa alamat dompet yang dihasilkan berada pada workchain yang benar. Untuk menghindari pembuatan alamat yang salah, disarankan untuk menggunakan force_chain()untuk secara eksplisit menentukan ID rantai.

(6) Menghindari Konflik Kode Kesalahan

Manajemen kode kesalahan yang efektif sangat penting untuk desain kontrak guna memastikan konsistensi dan menghindari kebingungan. Untuk kontrak pintar TON, pastikan setiap kode kesalahan unik dalam kontrak untuk mencegah konflik dan pesan kesalahan yang ambigu. Selain itu, hindari konflik dengan kode kesalahan standar yang didefinisikan oleh platform TON atau sistem yang mendasarinya. Sebagai contoh, kode kesalahan 333 menunjukkan ketidakcocokan ID rantai. Disarankan untuk menggunakan kode kesalahan antara 400 dan 1000 untuk mencegah konflik semacam itu.

(7) Menyimpan Data dan Memanggilreturn()Setelah Penyelesaian Operasi

Dalam kontrak pintar TON, penanganan pesan melibatkan pemilihan logika yang berbeda berdasarkan op-kode. Setelah menyelesaikan logika yang sesuai, dua langkah tambahan diperlukan: Pertama, jika data telah dimodifikasi, panggilsave_data() untuk memastikan bahwa perubahan disimpan; Jika tidak, perubahan tidak akan efektif. Kedua, telepon kembali()untuk menunjukkan bahwa operasi telah selesai; jika tidak, sebuah throw(0xffff)akan memicu pengecualian.

() recv_internal(int my_balance, int msg_value, cell in_msg_full, slice in_msg_body) impure {

int flags = cs~load_uint(4);

jika (flags & 1) {

;; Abaikan semua pesan email tidak terkirim

kembali ();

}

slice sender_address = cs~load_msg_addr();

load_data();

int op = in_msg_body~load_op();

jika ((op == op::op_1())) {

handle_op1();

simpan_data();

kembali ();

}

if ((op == op::op_2())) {

handle_op2();

simpan_data();

kembali ();

}

jika ((op == op::op_3())) {

handle_op3();

save_data();

kembalikan ();

}

melempar (0xffff);

}

Secara singkat, blockchain TON, dengan arsitektur inovatif dan lingkungan pengembangan yang fleksibel, menjadi platform yang ideal bagi pengembang aplikasi terdesentralisasi. Namun, karena kontrak pintar semakin memainkan peran penting dalam ekosistem TON, masalah keamanan tidak boleh diabaikan. Pengembang harus memahami dengan baik karakteristik ekosistem TON, mematuhi praktik terbaik secara ketat, dan meningkatkan proses audit keamanan untuk menjamin ketahanan dan keamanan kontrak. Hanya dengan begitu keuntungan dari platform TON dapat sepenuhnya direalisasikan, membangun aplikasi terdesentralisasi yang lebih aman dan dapat diandalkan serta menjaga perkembangan yang sehat dari seluruh ekosistem.

Ekosistem TON saat ini mengalami pertumbuhan pesat, menarik pendanaan yang signifikan dan pengguna aktif. Namun, masalah keamanan yang menyertainya tidak dapat diabaikan. Untuk memastikan keamanan dan keandalan ekosistem TON, Beosin menyediakan audit keamanan yang komprehensif dan profesional yang disesuaikan dengan karakteristik panggilan dan operasi kontrak pintar TON, mendukung pengembangan ekosistem.

Beosin memiliki banyak kasus sukses dalam ekosistem TON. Sebelumnya, Beosin melakukan audit keamanan yang komprehensif untuk proyek stablecoin terdesentralisasi terkemuka Aqua Protocol dan infrastruktur DeFi ONTON Finance. Audit meliputi beberapa aspek, termasuk keamanan kode kontrak pintar, kebenaran implementasi logika bisnis, optimasi gas kode kontrak, serta deteksi dan perbaikan kerentanan potensial.

Pernyataan:

1. Artikel ini direproduksi dari [Beosin], judul asli "Beosin Hard Core Research | Dari Risiko ke Perlindungan: Risiko Keamanan dan Saran Pengoptimalan Kontrak Cerdas TON》, hak cipta adalah milik penulis asli [Beosin], jika Anda memiliki keberatan terhadap pencetakan ulang ini, silakan hubungi Tim Gate Learn, Tim akan menanganinya sesegera mungkin sesuai dengan prosedur yang relevan.

2. Penafian: Pandangan dan pendapat yang tercantum dalam artikel ini hanya mewakili pandangan pribadi penulis dan tidak merupakan saran investasi apa pun.

3. Versi bahasa lain dari artikel ini diterjemahkan oleh tim Gate Learn dan tidak disebutkan dalam Gate.ioArtikel yang diterjemahkan tidak boleh direproduksi, didistribusikan, atau diplagiat.