Salus Insights: Beberapa pemeriksaan keamanan yang harus dilihat untuk pengembang proyek sebelum peningkatan Cancun
Long cerita singkat: Upgrade Cancun semakin dekat, dan upgrade ini terutama mencakup perubahan lapisan eksekutif yang diusulkan oleh enam EIP, EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780, dan EIP-7516. EIP-4844 adalah protagonis dari peningkatan ini, yang bertujuan untuk meningkatkan skalabilitas Ethereum, Drop Biaya Transaksi L2, dan meningkatkan kecepatan transaksi. Upgrade Cancun selesai pada 17 Januari, 30 Januari, 7 Februari di Ethereum Goerli, Sepolia, dan Holesky Testnet, dan dijadwalkan akan diaktifkan pada 13 Maret di Ethereum Mainnet. Sebelum upgrade, Salus telah menyusun pertimbangan keamanan penting untuk upgrade ini bagi pengembang untuk memeriksa sendiri.
Peninjauan Proposal EIP
Pertimbangan keamanan yang diungkapkan secara resmi
Smart Contract Risiko Terkait
Baca lebih lajut
Ulasan Proposal EIP
EIP-1153
EIP-1153 memperkenalkan Kode Operasi penyimpanan sementara, yang Kode Operasi digunakan untuk keadaan operasional dan berperilaku hampir identik dengan penyimpanan, tetapi dibuang setelah setiap transaksi selesai. Ini berarti bahwa penyimpanan sementara tidak membatalkan serialisasi nilai dari penyimpanan dan tidak membuat serial nilai ke penyimpanan, sehingga penyimpanan sementara lebih murah karena tidak memerlukan akses disk. Dengan dua Kode Operasi baru, TLOAD dan TSTORE (di mana “T” adalah singkatan dari “sementara”), Smart Contract dapat mengakses penyimpanan sementara. Proposal ini bertujuan untuk memberikan solusi khusus dan efisien untuk komunikasi antara kerangka eksekusi bersarang Long dalam eksekusi transaksi Ethereum.
EIP-4788
EIP-4788 bertujuan untuk mengekspos akar pohon hash dari Blok Rantai Suar ke EVM untuk memungkinkan akses ke akar ini di dalam Smart Contract. Melakukan hal itu memberikan akses tanpa kepercayaan ke status lapisan Konsensus, mendukung kasus penggunaan Long seperti kumpulan staking, struktur penatapan, jembatan Smart Contract, mitigasi MEV, dan banyak lagi. Proposal menyimpan akar ini melalui Smart Contract dan menggunakan buffer cincin untuk membatasi konsumsi penyimpanan, memastikan bahwa setiap Blok eksekusi hanya membutuhkan Short konstan untuk mewakili informasi ini.
EIP-4844
EIP-4844 memperkenalkan format transaksi baru yang disebut “Sharding Blob Transactions” yang dirancang untuk menskalakan ketersediaan data Ethereum dengan cara yang sederhana dan kompatibel ke depan. Proposal ini melakukan ini dengan memperkenalkan “transaksi pembawa gumpalan” yang berisi sejumlah besar data yang tidak dapat diakses oleh eksekusi EVM, tetapi dapat mengakses janji-janjinya. Format ini sepenuhnya kompatibel dengan format yang digunakan oleh Sharding penuh di masa mendatang, memberikan bantuan sementara namun signifikan untuk penskalaan bergulir.
EIP-5656
EIP-5656 memperkenalkan instruksi EVM baru, MCOPY, untuk replikasi wilayah memori yang efisien. Proposal ini bertujuan untuk Drop overhead melakukan operasi penyalinan memori pada EVM dengan secara langsung memungkinkan replikasi data antara memori melalui instruksi MCOPY. MCOPY MEMUNGKINKAN Alamat Alamat SUMBER DAN TARGET TUMPANG TINDIH, DIRANCANG DENGAN MEMPERTIMBANGKAN KOMPATIBILITAS KE BELAKANG, DAN DIRANCANG UNTUK MENINGKATKAN EFISIENSI EKSEKUSI DALAM SKENARIO Long, TERMASUK KONSTRUKSI STRUKTUR DATA, AKSES EFISIEN KE OBJEK DALAM MEMORI, DAN REPLIKASI.
EIP-6780
EIP-6780 memodifikasi fungsionalitas Kode Operasi SELFDESTRUCT. Dalam proposal ini, SELFDESTRUCT hanya akan menghapus akun dan mentransfer semua Ether dalam transaksi yang sama dengan kontrak dibuat, kecuali bahwa ketika SELFDESTRUCT dieksekusi, kontrak tidak akan dihapus, tetapi hanya akan mentransfer semua Ether ke tujuan yang ditentukan. Perubahan ini dimaksudkan untuk mengakomodasi penggunaan pohon Verkle di masa depan, dan dimaksudkan untuk menyederhanakan implementasi EVM dan mengurangi kompleksitas perubahan keadaan, sambil mempertahankan beberapa skenario umum yang digunakan oleh SELFDESTRUCT.
EIP-7516
EIP-7516 memperkenalkan instruksi EVM baru, BLOBBASEFEE, yang mengembalikan nilai biaya dasar blob dalam eksekusi blok saat ini. Direktif ini mirip dengan Kode Operasi BASEFEE di EIP-3198, kecuali bahwa ia mengembalikan biaya dasar blob seperti yang ditentukan oleh EIP-4844. Fitur ini memungkinkan kontrak untuk secara terprogram mempertimbangkan harga gas data blob, misalnya, dengan memungkinkan kontrak rollup untuk menghitung biaya penggunaan data blob tanpa kepercayaan, atau untuk menerapkan futures gas blob berdasarkan ini untuk memperlancar biaya data blob.
Pertimbangan keamanan yang diungkapkan secara resmi
EIP-1153
Smart Contract pengembang harus memahami siklus hidup variabel penyimpanan sementara sebelum menggunakannya. Karena penyimpanan sementara dihapus secara otomatis pada akhir transaksi, pengembang Smart Contract mungkin mencoba menghindari membersihkan slot selama panggilan untuk menghemat gas. Namun, ini dapat mencegah interaksi lebih lanjut dengan kontrak dalam transaksi yang sama (misalnya, dalam kasus kunci reentrant) atau menyebabkan kesalahan lain, sehingga pengembang Smart Contract harus berhati-hati untuk mempertahankan nilai bukan nol hanya ketika slot sementara dicadangkan. Dimaksudkan untuk digunakan oleh panggilan di masa mendatang dalam transaksi yang sama. SSTORE Jika tidak, Kode Operasi ini berperilaku persis sama dengan dan SLOAD, sehingga semua pertimbangan keamanan umum berlaku, terutama ketika menyangkut risiko re-entrency.
Smart Contract pengembang juga dapat mencoba menggunakan penyimpanan sementara sebagai alternatif untuk pemetaan memori. Mereka harus menyadari bahwa penyimpanan sementara tidak dibuang seperti memori ketika panggilan kembali atau dilanjutkan, dan memori harus diprioritaskan dalam kasus penggunaan ini untuk menghindari perilaku tak terduga ketika entrancy ulang dalam transaksi yang sama. Penyimpanan sementara pada memori tentu mahal, yang seharusnya mencegah pola penggunaan ini. Penggunaan pemetaan dalam memori yang besar Long dapat dicapai dengan lebih baik dengan daftar entri yang diurutkan kunci, dan pemetaan dalam memori jarang diperlukan dalam Smart Contract (yaitu penulis tahu bahwa tidak ada kasus penggunaan yang diketahui dalam produksi).
EIP-4844
EIP ini meningkatkan kebutuhan bandwidth sekitar 0.75 MB pada Long maksimum per blok suar. Ini 40% lebih besar dari ukuran Blok maksimum teoritis saat ini (30 M Gas / 16 Gas per byte calldata = 1,875 M byte), sehingga tidak secara signifikan meningkatkan bandwidth kasus terburuk. Setelah merger, waktu Blok adalah statis daripada distribusi Poisson yang tidak dapat diprediksi, memberikan periode waktu yang dijamin untuk propagasi Blok besar.
Bahkan dengan data panggilan terbatas, beban berkelanjutan EIP ini Long lebih rendah daripada alternatif yang dapat Drop biaya data panggilan karena Anda tidak perlu menyimpan blob selama beban eksekusi. Hal ini memungkinkan untuk menerapkan kebijakan bahwa blob ini harus dipertahankan setidaknya untuk jangka waktu tertentu. Nilai spesifik yang dipilih adalah zaman MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, yaitu sekitar 18 hari, dengan latensi Long dibandingkan dengan rotasi satu tahun riwayat muatan eksekusi yang direkomendasikan (tetapi belum diterapkan).
EIP-5656
Klien harus menyadari bahwa implementasi mereka tidak menggunakan buffer menengah (misalnya, fungsi C stdlibmemmove tidak menggunakan buffer perantara), karena ini adalah vektor denial-of-service (DoS) potensial. Long fungsi pustaka bawaan/standar bahasa untuk memindahkan byte memiliki karakteristik kinerja yang benar di sini.
Selain itu, analisis denial-of-service (DoS) dan serangan kelelahan memori sama dengan Kode Operasi lain untuk menyentuh memori, karena ekspansi memori mengikuti aturan harga yang sama.
EIP-6780
APLIKASI SELFDESTRUCT BERIKUT AKAN DIKOMPROMIKAN, DAN APLIKASI YANG MENGGUNAKANNYA DENGAN CARA INI TIDAK LAGI AMAN:
WhereCREATE 2 digunakan untuk memindahkan kontrak di lokasi yang sama sehingga kontrak dapat ditingkatkan. Fitur ini tidak lagi didukung dan ERC-2535 atau jenis kontrak proxy lainnya harus digunakan sebagai gantinya.
Jika kontrak bergantung pada pembakaran Ether dengan mengambil kontrak SELFDESTRUCT sebagai penerima manfaat, kontrak tidak dibuat dalam transaksi yang sama.
Risiko yang terkait dengan Kontrak Cerdas
EIP 1153
Pertimbangkan dua skenario menggunakan Kode Operasi TLOAD dan TSTORE:
- Kontrak yang disebut menggunakan Kode Operasi
- Kode Operasi digunakan untuk memulai kontrak panggilan
Risiko 1 :
Dibandingkan dengan SSTORE dan SLOAD tradisional, penyimpanan sementara baru terutama mengubah periode penyimpanan data, data yang disimpan oleh tstore dibaca melalui tload, dan data akan dirilis setelah pelaksanaan transaksi, alih-alih ditulis ke dalam kontrak karena sstore dicatat secara permanen. Pengembang harus mengenali fitur-fitur Kode Operasi saat menggunakan Kode Operasi, untuk menghindari kerugian yang disebabkan oleh penggunaan data yang salah yang tidak dapat ditulis ke dalam kontrak dengan benar. Selain itu, data tstore adalah variabel pribadi dan hanya dapat diakses oleh kontrak itu sendiri. Jika Anda ingin menggunakan data secara eksternal, Anda hanya dapat meneruskannya sebagai parameter atau mementaskannya dalam variabel stroase publik.
Risiko 2 :
Risiko potensial lainnya adalah jika pengembang Smart Contract tidak mengelola siklus hidup variabel penyimpanan sementara dengan benar, hal itu dapat menyebabkan data dihapus atau disimpan secara tidak benar pada waktu yang tidak semestinya. Jika kontrak mengharapkan untuk menggunakan data yang disimpan dalam penyimpanan sementara dalam panggilan berikutnya ke transaksi, tetapi gagal mengelola siklus hidup data tersebut dengan benar, data mungkin secara keliru dibagikan atau hilang di antara panggilan yang berbeda, yang mengakibatkan kesalahan logis atau pelanggaran keamanan. Mengingat data saldo atau penyisihan proyek Token sejenis tidak disimpan dengan benar, maka akan menyebabkan kesalahan dalam logika kontrak dan menyebabkan kerugian. Atau penggunaan Kode Operasi ini ketika mengatur pemilik Alamat akan menyebabkan Alamat istimewa tidak dicatat dengan benar, sehingga kehilangan modifikasi parameter penting dari kontrak.
Pertimbangkan Smart Contract yang menggunakan penyimpanan sementara untuk mencatat harga transaksi sementara pada platform perdagangan Aset Kripto. Kontrak memperbarui harga saat setiap transaksi selesai dan memungkinkan pengguna untuk menanyakan harga terbaru untuk waktu yang singkat. Namun, jika desain kontrak tidak memperhitungkan fakta bahwa penyimpanan sementara secara otomatis dihapus pada akhir perdagangan, maka pengguna mungkin mendapatkan harga yang salah atau ketinggalan zaman dalam periode antara akhir satu perdagangan dan awal berikutnya. Ini tidak hanya dapat menyebabkan pengguna membuat keputusan berdasarkan informasi yang salah, tetapi juga dapat dieksploitasi dengan jahat, memengaruhi reputasi platform dan keamanan aset pengguna.
EIP-6780
Proposal mengubah perilaku sebelumnya dari Kode Operasi penghancuran diri, tidak menghancurkan kontrak, hanya mentransfer token, dan hanya kontrak yang dibuat dalam transaksi yang sama dengan penghancuran diri yang akan dihancurkan. Dampak dari EIP ini relatif besar.
Pindahkan ulang kontrak pada Alamat yang sama dengan create 2 untuk meningkatkan kontrak. Fitur ini tidak lagi didukung dan ERC-2535 atau jenis kontrak proxy lainnya harus digunakan sebagai gantinya. (Ini dapat memengaruhi keamanan kontrak on-chain yang menggunakan create 2 untuk menerapkan kontrak yang dapat diskalakan)
Operasi SELFDESTRUCT di Smart Contract memungkinkan kontrak dihancurkan dan saldo kontrak dikirim ke Alamat tujuan yang ditentukan. Dalam hal ini, kontrak menggunakan SELFDESTRUCT untuk membakar Ether dan mengirimkan Ether yang terbakar ke kontrak. Namun, kontrak hanya dapat berupa kontrak yang dibuat dalam transaksi yang sama (kontrak yang dibuat oleh kontrak ini atau kontrak lain dalam transaksi yang sama). Jika tidak, hanya Ether yang akan ditransfer tanpa merusak kontrak (misalnya merusak diri sendiri dan penerima manfaat adalah kontrak penghancuran diri, yang tidak akan mengubah apa pun). Ini akan mempengaruhi setiap kontrak yang mengandalkan penghancuran diri untuk penarikan atau operasi lainnya.
Token gas yang mirip dengan CHI 1inch Token berfungsi: simpan offset, selalu jalankan CREATE 2 atau SELFDESTRUCT pada offset itu. Setelah pembaruan ini, jika kontrak dengan offset saat ini belum dihancurkan sendiri dengan benar, CREATE 2 berikutnya tidak akan berhasil menyebarkan kontrak.
Implementasi proposal ini tidak akan mengarah pada serangan langsung terhadap kontrak, tetapi akan merusak logika normal dari kontrak asli yang digunakan yang bergantung pada operasi penghancuran diri (kontrak yang hanya mengandalkan penghancuran diri untuk transfer dana tidak akan terpengaruh, dan jika operasi selanjutnya harus memerlukan kontrak penghancuran diri untuk dihapus, itu akan terpengaruh), mengakibatkan kontrak tidak berfungsi sebagaimana dimaksud, dan hanya untuk kontrak dan pengguna, itu dapat menyebabkan pemogokan kontrak, kehilangan dana, dan bahaya lainnya (seperti penggunaan asli create 2). Terapkan kontrak baru di Alamat asli, dan kontrak yang merusak sendiri kontrak asli untuk peningkatan tidak lagi dapat berhasil digunakan). Dalam jangka panjang, kemampuan untuk memodifikasi Kode Operasi dapat menyebabkan masalah sentralisasi.
Misalnya, ada vault kontrak vault yang sudah ada untuk diperbarui:
- Buat 2 Kontrak Penyimpanan Sementara digunakan untuk mencadangkan dana sementara untuk brankas
- Self-destruct vault contract, transfer dana ke kontrak sementara (hanya dana yang ditransfer, tidak ada kontrak yang dibakar)
- Kontrak vault baru di Alamat asli buat 2 (gagal karena kontrak vault asli tidak dihancurkan)
- Self-destruct kontrak sementara untuk mengembalikan dana ke vault (kehilangan dana, kontrak vault tidak dibuat)
Baca lebih lanjut
Upgrade Cancun akan semakin meningkatkan keunggulan kompetitif Ethereum. Namun, peningkatan ini menimbulkan risiko terhadap perubahan pada lapisan Smart Contract inti, yang akan memengaruhi operasi aman DApps yang ada. Dalam proses perkembangan Smart Contract, perubahan-perubahan tersebut dan risiko-risiko yang mungkin timbul juga perlu diperhatikan. Anda dapat menghubungi Salus untuk pemeriksaan risiko atau dukungan audit, atau Anda dapat membaca lebih lanjut untuk memahami perubahannya.
Spesifikasi Peningkatan Jaringan Cancun
EIP-1153
EIP-4788
EIP-4844
EIP-5656
EIP-6780
EIP-7516
Kontrak Metapod
Kontrak GasToken 2