*Forward the Original Title: Sebelum Peningkatan Kancun, Beberapa Pemeriksaan Keamanan yang Harus Dilihat oleh Pengembang Proyek

TL;DR: Dengan upgrade Cancun yang akan datang, itu termasuk enam perubahan yang diusulkan oleh EIP, terutama EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780, dan EIP-7516. EIP-4844 berfokus pada meningkatkan skalabilitas Ethereum, mengurangi biaya transaksi, dan mempercepat transaksi untuk solusi Layer 2. Upgrade telah diuji di testnet Ethereum dan dijadwalkan untuk diaktifkan di mainnet pada tanggal 13 Maret. Salus telah menyusun pertimbangan keamanan penting bagi pengembang untuk diperiksa sebelum upgrade.

Review dari Proposal EIP

Pertimbangan Keamanan Resmi

Resiko terkait kontrak pintar

Bacaan lanjutan

Ulasan Proposal EIP

EIP-1153

EIP-1153 memperkenalkan opcode penyimpanan sementara, yang digunakan untuk memanipulasi keadaan dengan cara yang mirip dengan penyimpanan, tetapi dengan penyimpanan sementara dibuang setelah setiap transaksi. Ini berarti bahwa penyimpanan sementara tidak membatalkan serialisasi nilai dari penyimpanan, atau membuat serial nilai ke penyimpanan, sehingga menghasilkan biaya yang lebih rendah karena menghindari akses disk. Dengan diperkenalkannya dua opcode baru, TLOAD dan TSTORE (di mana "T" adalah singkatan dari "sementara"), kontrak pintar dapat mengakses penyimpanan sementara. Proposal ini bertujuan untuk memberikan solusi khusus dan efisien untuk komunikasi antara beberapa frame eksekusi bersarang selama eksekusi transaksi di Ethereum.

EIP-4788

EIP-4788 bertujuan untuk mengekspos akar pohon hash dari blok rantai beacon ke EVM, memungkinkan akar-akar ini diakses dalam kontrak pintar. Ini memungkinkan akses ke status lapis konsensus tanpa kepercayaan, mendukung berbagai kasus penggunaan seperti staking pool, struktur restaking, jembatan kontrak pintar, dan mitigasi MEV. Proposal ini mencapai hal ini dengan menyimpan akar-akar ini dalam kontrak pintar dan menggunakan buffer circular untuk membatasi konsumsi penyimpanan, memastikan bahwa setiap blok eksekusi hanya memerlukan ruang konstan untuk merepresentasikan informasi ini.

EIP-4844

EIP-4844 memperkenalkan format transaksi baru yang disebut 'Transaksi Shard Blob' yang dirancang untuk memperluas ketersediaan data Ethereum secara sederhana dan kompatibel ke belakang. Usulan ini mencapai tujuannya dengan memperkenalkan 'transaksi pengangkut blob' yang mengandung sejumlah besar data yang tidak dapat diakses oleh EVM tetapi dapat diakses oleh komitmen mereka. Format ini sepenuhnya kompatibel dengan format yang digunakan oleh full-sharding masa depan, memberikan bantuan sementara namun signifikan bagi skalabilitas rollup.

EIP-5656

EIP-5656 memperkenalkan instruksi EVM baru, MCOPY, untuk penyalinan wilayah memori yang efisien. Proposal ini bertujuan untuk mengurangi overhead operasi penyalinan memori pada EVM dengan langsung menyalin data antara memori menggunakan instruksi MCOPY. MCOPY memungkinkan tumpang tindih alamat sumber dan tujuan, dirancang dengan mempertimbangkan kompatibilitas mundur, dan bertujuan untuk meningkatkan efisiensi eksekusi dalam berbagai skenario, termasuk konstruksi struktur data, akses efisien, dan penyalinan objek memori.

EIP-6780

EIP-6780 memodifikasi fungsionalitas opcode SELFDESTRUCT. Dalam proposal ini, SELFDESTRUCT hanya menghapus akun dan mentransfer semua ether dalam transaksi yang sama dengan pembuatan kontrak. Selain itu, saat menjalankan SELFDESTRUCT, kontrak tidak akan dihapus tetapi akan mentransfer semua ether ke target yang ditentukan. Perubahan ini mengakomodasi penggunaan masa depan dari pohon Verkle, bertujuan untuk menyederhanakan implementasi EVM, mengurangi kompleksitas perubahan status, sambil tetap mempertahankan beberapa kasus penggunaan umum dari SELFDESTRUCT.

EIP-7516

EIP-7516 memperkenalkan instruksi EVM baru, BLOBBASEFEE, untuk mengembalikan nilai biaya dasar untuk blob dalam eksekusi blok saat ini. Instruksi ini mirip dengan opcode BASEFEE yang diperkenalkan dalam EIP-3198, dengan perbedaan bahwa itu mengembalikan biaya dasar blob yang ditentukan sesuai dengan EIP-4844. Fungsionalitas ini memungkinkan kontrak untuk mempertimbangkan secara programatik harga gas data blob, memungkinkan kontrak rollup untuk menghitung biaya penggunaan data blob tanpa kepercayaan atau mengimplementasikan masa depan gas blob untuk meratakan biaya data blob.

Pertimbangan Keamanan Resmi

EIP-1153

Pengembang kontrak pintar harus memahami siklus hidup variabel penyimpanan sementara sebelum menggunakannya. Karena penyimpanan sementara secara otomatis dihapus di akhir transaksi, pengembang kontrak pintar mungkin mencoba untuk menghindari membersihkan slot selama panggilan untuk menghemat gas. Namun, hal ini bisa mencegah interaksi lebih lanjut dengan kontrak dalam transaksi yang sama (misalnya, dalam kasus kunci reentrant) atau menyebabkan kesalahan lain. Oleh karena itu, pengembang kontrak pintar harus berhati-hati dan hanya menyimpan nilai non-nol saat slot penyimpanan sementara dipesan untuk panggilan masa depan dalam transaksi yang sama. Jika tidak, perilaku opcode ini identik dengan SLOAD dan SSTORE, sehingga semua pertimbangan keamanan umum berlaku, terutama mengenai risiko reentransi.

Pengembang kontrak pintar juga dapat mencoba menggunakan penyimpanan sementara sebagai alternatif untuk pemetaan memori. Mereka harus menyadari bahwa penyimpanan sementara tidak dibuang seperti memori ketika panggilan mengembalikan atau dikembalikan dan harus memprioritaskan memori dalam kasus penggunaan tersebut untuk menghindari perilaku yang tidak terduga selama reentry dalam transaksi yang sama. Biaya tinggi penyimpanan sementara dalam memori seharusnya sudah menakutkan pola penggunaan ini. Sebagian besar kasus penggunaan untuk pemetaan dalam memori dapat lebih baik diimplementasikan melalui daftar terurut entri berdasarkan kunci, dan penyimpanan sementara dalam pemetaan memori jarang diperlukan dalam kontrak pintar (yaitu, tidak ada kasus penggunaan yang diketahui dalam produksi).

EIP-4844

EIP ini meningkatkan persyaratan bandwidth untuk setiap blok beacon hingga sekitar 0,75 MB. Ini adalah peningkatan 40% dari ukuran maksimum teoretis blok saat ini (30M Gas / 16 Gas per byte calldata = 1,875M byte), sehingga tidak signifikan meningkatkan bandwidth dalam skenario terburuk. Setelah penggabungan, waktu blok statis daripada didistribusikan Poisson secara tidak terduga, memberikan kerangka waktu yang dijamin untuk penyebaran blok besar.

Bahkan dengan data panggilan yang terbatas, beban berkelanjutan dari EIP ini jauh lebih rendah dari solusi alternatif yang dapat mengurangi biaya data panggilan karena penyimpanan Blob tidak perlu dipertahankan selama beban eksekusi. Hal ini memungkinkan untuk menerapkan strategi yang memerlukan pengingatan blob ini setidaknya untuk jangka waktu tertentu. Nilai spesifik yang dipilih adalah epoch MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, yang kurang lebih 18 hari, jauh lebih pendek dari waktu rotasi satu tahun (yang belum diimplementasikan) untuk menjalankan riwayat payload yang valid.

EIP-5656

Klien harus berhati-hati agar implementasi mereka tidak menggunakan buffer-buffer perantara (misalnya, fungsi memmove C stdlib tidak menggunakan buffer perantara) karena ini merupakan potensi vektor penolakan layanan (DoS). Sebagian besar fungsi bawaan bahasa / fungsi pustaka standar yang digunakan untuk memindahkan byte memiliki karakteristik kinerja yang benar di sini.

Selain itu, analisis serangan penolakan layanan (DoS) dan kehabisan memori sama seperti untuk opcode yang menyentuh memori lain karena ekspansi memori mengikuti aturan penetapan harga yang sama.

EIP-6780

Aplikasi-aplikasi SELFDESTRUCT berikut ini akan rusak, dan aplikasi yang menggunakannya dengan cara ini tidak lagi aman:

Di mana CREATE2 digunakan untuk mendeploy ulang kontrak di lokasi yang sama untuk membuat kontrak dapat diupgrade. Fungsionalitas ini tidak lagi didukung dan seharusnya digantikan dengan ERC-2535 atau jenis kontrak proksi lainnya.

Jika sebuah kontrak bergantung pada pembakaran ether ke kontrak melalui SELFDESTRUCT sebagai penerima manfaat, kontrak tersebut tidak dibuat dalam transaksi yang sama.

Resiko Terkait Kontrak Pintar

EIP1153

Pertimbangkan dua skenario menggunakan opcode TLOAD dan TSTORE:

1. Kontrak yang dipanggil menggunakan opcode-opcode ini.
2. Manggil kontrak menggunakan opcode-opcode ini.

Risiko 1:

Dibandingkan dengan SSTORE dan SLOAD tradisional, pengenalan penyimpanan sementara terutama mengubah durasi penyimpanan data. Data yang disimpan oleh TSTORE dibaca melalui TLOAD dan akan dilepaskan setelah eksekusi transaksi, bukan dicatat secara permanen di kontrak seperti SSTORE. Pengembang harus memahami karakteristik opcode ini saat menggunakannya untuk menghindari penggunaan yang salah, yang dapat mengakibatkan data tidak tertulis dengan benar ke kontrak, menyebabkan kerugian. Selain itu, data yang disimpan oleh TSTORE bersifat pribadi dan hanya dapat diakses oleh kontrak itu sendiri. Jika akses eksternal ke data ini diperlukan, harus dilewati melalui parameter atau disimpan sementara dalam variabel penyimpanan publik.

Risiko 2:

Risiko potensial lainnya adalah jika pengembang smart contract tidak mengelola siklus hidup variabel penyimpanan sementara dengan benar, hal ini dapat menyebabkan data dibersihkan pada waktu yang tidak tepat atau disimpan dengan tidak benar. Jika sebuah kontrak mengharapkan untuk menggunakan data yang disimpan di penyimpanan sementara dalam panggilan transaksi berikutnya tetapi gagal mengelola siklus hidup data ini dengan baik, maka data tersebut mungkin secara keliru dibagikan atau hilang antara panggilan yang berbeda, mengakibatkan kesalahan logis atau kerentanan keamanan. Kegagalan untuk menyimpan data dengan benar, seperti saldo atau data izin dalam proyek token, dapat menyebabkan kesalahan logis dalam kontrak, menyebabkan kerugian. Demikian pula, menggunakan opcode ini untuk menetapkan alamat pemilik dapat mengakibatkan alamat yang diizinkan tidak tercatat dengan benar, menyebabkan kehilangan modifikasi terhadap parameter penting dari kontrak.

Pertimbangkan kontrak pintar yang menggunakan penyimpanan sementara untuk sementara mencatat harga transaksi pada platform perdagangan cryptocurrency. Kontrak memperbarui harga setelah setiap transaksi dan memungkinkan pengguna untuk menanyakan harga terbaru dalam jangka waktu pendek. Namun, jika desain kontrak tidak mempertimbangkan pembersihan otomatis penyimpanan sementara pada akhir transaksi, mungkin ada periode antara akhir satu transaksi dan awal transaksi berikutnya di mana pengguna mungkin menerima harga yang tidak benar atau kadaluarsa. Hal ini tidak hanya dapat menyebabkan pengguna membuat keputusan berdasarkan informasi yang tidak benar tetapi juga dapat dimanfaatkan secara jahat, memengaruhi reputasi platform dan keamanan aset pengguna.

EIP-6780

Usulan ini mengubah perilaku opcode selfdestruct sebelumnya, di mana kontrak tidak dibakar tetapi hanya transfer token terjadi, dan hanya kontrak yang dibuat dalam transaksi yang sama dengan kontrak selfdestruct yang akan dibakar. Dampak dari EIP ini cukup signifikan.

Menggunakan create2 untuk redeploy kontrak di alamat yang sama untuk upgrade kontrak tidak lagi didukung. Fungsionalitas ini sebaiknya digantikan dengan ERC-2535 atau jenis kontrak proksi lainnya. (Hal ini dapat memengaruhi keamanankontrak on-chain menerapkan kontrak yang dapat ditingkatkan menggunakan create2).

Operasi SELFDESTRUCT dalam kontrak pintar memungkinkan kontrak untuk dibakar, dan saldo kontrak dikirim ke alamat target yang ditentukan. Dalam kasus ini, kontrak menggunakan SELFDESTRUCT untuk membakar Ether dan mengirimkan Ether yang terbakar ke kontrak. Namun, kontrak ini hanya boleh dibuat dalam transaksi yang sama dengan kontrak lain (kontrak yang dibuat oleh kontrak ini atau kontrak lain dalam transaksi yang sama). Jika tidak, Ether hanya akan ditransfer tanpa membakar kontrak (misalnya, selfdestruct dengan penerima menjadi kontrak selfdestruct, yang tidak akan menghasilkan perubahan apa pun). Hal ini akan memengaruhi semuakontrakyang bergantung pada fungsi selfdestruct untuk penarikan atau operasi lainnya.

Token Gas yang mirip dengan Token CHI 1inch berfungsi sebagai berikut: mempertahankan offset, selalu mendeploy CREATE2 atau SELFDESTRUCT pada offset ini. Setelah pembaruan ini, jika kontrak pada offset saat ini belum benar-benar melakukan self-destruct, CREATE2 selanjutnya tidak akan dapat berhasil mendeploy kontrak.

Implementasi proposal ini tidak dapat langsung menyerang kontrak, tetapi akan merusak logika normal dari kontrak yang ada yang mengandalkan operasi selfdestruct (kontrak yang hanya mengandalkan selfdestruct untuk transfer dana tidak terpengaruh, tetapi kontrak yang memerlukan operasi lanjutan untuk menghapus kontrak selfdestruct terpengaruh), menyebabkan kontrak berfungsi secara tidak terduga, dan dapat menyebabkan serangan kontrak, kehilangan dana, dll. (misalnya, kontrak yang awalnya menggunakan create2 untuk mendeploy kontrak baru di alamat asli dan self-destruct kontrak asli untuk upgrade, tidak dapat lagi berhasil dideploy). Pada akhirnya, memodifikasi fungsionalitas opcode dapat menimbulkan isu-isu sentralisasi.

Sebagai contoh, ada kontrak brankas yang sudah ada untuk pembaruan:

• Kontrak penyimpanan sementara, create2, digunakan untuk sementara mengamankan dana untuk brankas.
• Hancurkan kontrak brankas, transfer dana ke kontrak sementara (hanya dana yang ditransfer tanpa membakar kontrak).
• Buat kontrak brankas baru di alamat asli menggunakan create2 (gagal karena kontrak brankas asli belum dibakar).
• Menghancurkan kontrak sementara untuk mengembalikan dana ke brankas (dana hilang, kontrak brankas belum dibuat).

Bacaan Lanjutan:

Peningkatan Cancun akan lebih meningkatkan keunggulan kompetitif Ethereum. Namun, perubahan pada lapisan kontrak pintar inti dalam peningkatan ini membawa risiko yang akan memengaruhi operasi aman DApps yang ada. Selama pengembangan kontrak pintar, perubahan ini dan risiko potensial yang mungkin mereka bawa perlu dimonitor dengan cermat. Anda dapat menghubungi Salus untuk pemeriksaan risiko atau dukungan audit, atau membaca lebih lanjut untuk memahami perubahan tersebut.

Spesifikasi Pembaruan Jaringan Cancun

EIP-1153

EIP-4788

EIP-4844

EIP-5656

EIP-6780

EIP-7516

kontrak Metapod

kontrak GasToken2

Disclaimer:

1. Artikel ini dicetak ulang dari [ Aicoin], Teruskan Judul Asli 'Salus Insights：Sebelum Upgrade Cancun, Beberapa Pemeriksaan Keamanan yang Harus Dilihat oleh Pengembang Proyek'. Seluruh hak cipta dimiliki oleh penulis asli [ *Odaily Planet Harian]. Jika ada keberatan terhadap cetak ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penolakan Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apapun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel terjemahan dilarang.