Pemeriksaan keselamatan penting sebelum menaik taraf di Cancun

Pendek cerita: Peningkatan Cancun semakin hampir, peningkatan ini mengandungi perubahan lapisan pelaksanaan yang dicadangkan oleh enam EIP, EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 dan EIP-7516. EIP-4844 ialah protagonis peningkatan ini, yang bertujuan untuk meningkatkan skalabiliti Ethereum, mengurangkan kos transaksi dan meningkatkan kelajuan transaksi untuk L2. Peningkatan Cancun telah selesai pada testnet Ethereum Goerli, Sepolia dan Holesky pada 17 Januari, 30 Januari dan 7 Februari masing-masing, dan dijadualkan akan diaktifkan pada mainnet Ethereum pada 13 Mac. Sebelum menaik taraf, Salus telah menyusun langkah berjaga-jaga keselamatan yang penting untuk peningkatan ini untuk pemaju menyemak sendiri.

Semakan cadangan EIP

Pertimbangan keselamatan didedahkan secara rasmi

Risiko berkaitan kontrak pintar

Bacaan lanjutan

Semakan cadangan EIP

1. EIP-1153

   1 storan sementara

1

1 IP ini operasi Kod digunakan untuk keadaan operasi dan berkelakuan hampir sama seperti storan, tetapi storan sementara dibuang selepas setiap transaksi. Ini bermakna storan sementara tidak menyahsiri nilai daripada atau menyerikan nilai kepada storan, jadi storan sementara adalah lebih murah kerana tiada akses cakera diperlukan. Kontrak pintar boleh mengakses storan sementara melalui dua opcode baharu, TLOAD dan TSTORE (di mana "T" bermaksud "sementara"). Cadangan ini bertujuan untuk menyediakan penyelesaian yang berdedikasi dan cekap untuk komunikasi antara pelbagai rangka kerja pelaksanaan bersarang dalam pelaksanaan transaksi Ethereum.

2. EIP-4788

EIP-4788 direka bentuk untuk mendedahkan akar pokok cincang blok rantai suar kepada EVM untuk membenarkan akses kepada akar ini dalam kontrak pintar. Ini memberikan akses tanpa amanah kepada keadaan lapisan konsensus, menyokong berbilang kes penggunaan seperti kumpulan staking, struktur staking semula, jambatan kontrak pintar, mitigasi MEV dan banyak lagi. Cadangan ini menyimpan akar ini melalui kontrak pintar dan menggunakan penimbal cincin untuk mengehadkan penggunaan storan, memastikan setiap blok pelaksanaan hanya memerlukan ruang tetap untuk mewakili maklumat ini.

3. EIP-4844

EIP-4844 memperkenalkan format transaksi baharu yang dipanggil "urus niaga gumpalan beling" yang direka untuk melanjutkan ketersediaan data Ethereum dengan cara yang mudah dan serasi ke hadapan. Cadangan ini berfungsi dengan memperkenalkan "urus niaga pembawa gumpalan" yang mengandungi sejumlah besar data yang tidak boleh diakses oleh pelaksanaan EVM, tetapi boleh mengakses komitmennya. Format ini serasi sepenuhnya dengan format yang digunakan oleh sharding penuh pada masa hadapan, memberikan kelegaan sementara tetapi ketara untuk pengembangan rolling.

4. EIP-5656

EIP-5656 memperkenalkan MCOPY arahan EVM baharu untuk penyalinan kawasan memori yang cekap. Cadangan ini bertujuan untuk mengurangkan overhed melaksanakan operasi penyalinan memori pada EVM dan terus menyalin data antara ingatan melalui arahan MCOPY. MCOPY membenarkan alamat sumber dan destinasi bertindih Ia direka dengan mengambil kira keserasian ke belakang dan bertujuan untuk meningkatkan kecekapan pelaksanaan dalam pelbagai senario termasuk pembinaan struktur data, capaian yang cekap dan penyalinan objek memori.

5. EIP-6780

EIP-6780 Mengubah suai fungsi kod opDESTRUKT DIRI. Dalam cadangan ini, SELFDESTRUCT hanya akan memadamkan akaun dan memindahkan semua syiling eter dalam urus niaga yang sama seperti penciptaan kontrak Selain itu, apabila melaksanakan SELFDESTRUCT, kontrak tidak akan dipadamkan, tetapi semua syiling eter akan dipindahkan ke destinasi yang ditentukan. Perubahan ini adalah untuk menyesuaikan diri dengan penggunaan pepohon Verkle pada masa hadapan, bertujuan untuk memudahkan pelaksanaan EVM dan mengurangkan kerumitan perubahan keadaan, sambil mengekalkan beberapa senario biasa SELFSTRUCT.

6. EIP-7516

EIP-7516 memperkenalkan arahan EVM baharu BLOBBASEFEE, yang digunakan untuk mengembalikan nilai yuran asas gumpalan dalam pelaksanaan blok semasa. Arahan ini serupa dengan opcode BASEFEE dalam EIP-3198, kecuali ia mengembalikan yuran asas gumpalan seperti yang ditakrifkan dalam EIP-4844. Ciri ini membenarkan kontrak untuk mempertimbangkan harga gas bagi data gumpalan secara pemrograman, contohnya, membenarkan kontrak rollup mengira kos penggunaan data gumpalan secara tidak amanah atau melaksanakan niaga hadapan gas gumpalan berdasarkan ini untuk melicinkan kos data gumpalan.

Pertimbangan keselamatan yang didedahkan secara rasmi

EIP-1153

Pemaju kontrak pintar harus memahami kitaran hayat pembolehubah storan sementara sebelum digunakan. Memandangkan storan sementara dikosongkan secara automatik pada penghujung urus niaga, pembangun kontrak pintar mungkin cuba mengelak mengosongkan slot semasa panggilan untuk menjimatkan gas. Walau bagaimanapun, ini mungkin menghalang interaksi selanjutnya dengan kontrak dalam urus niaga yang sama (contohnya, dalam kes kunci kemasukan semula) atau menyebabkan ralat lain, jadi pemaju kontrak pintar harus berhati-hati untuk hanya menempah slot storan bukan sementara apabila ia ditempah. Nilai sifar. Bertujuan untuk digunakan oleh panggilan masa hadapan dalam transaksi yang sama. SSTORE Jika tidak, opcode ini berkelakuan sama seperti SLOAD dan SLOAD , jadi semua pertimbangan keselamatan biasa digunakan, terutamanya mengenai risiko kemasukan semula.

Pemaju kontrak pintar juga boleh cuba menggunakan storan sementara sebagai alternatif kepada pemetaan memori. Mereka harus sedar bahawa storan sementara tidak dibuang seperti memori apabila panggilan kembali atau disambung semula, dan ingatan harus diutamakan dalam kes penggunaan ini untuk mengelakkan tingkah laku yang tidak dijangka pada kemasukan semula dalam transaksi yang sama. Kos penyimpanan sementara pada memori semestinya tinggi, yang sepatutnya tidak menggalakkan corak penggunaan ini. Kebanyakan penggunaan pemetaan dalam memori dilaksanakan dengan lebih baik dengan senarai entri tersusun kunci, dan pemetaan dalam ingatan jarang diperlukan dalam kontrak pintar (iaitu pengarang mengetahui tiada kes penggunaan yang diketahui dalam pengeluaran).

EIP-4844

EIP ini meningkatkan keperluan lebar jalur sehingga lebih kurang 0.75 MB setiap blok suar. Ini adalah 40% lebih besar daripada saiz maksimum teori blok hari ini (30M Gas / 16 Gas setiap bait data panggilan = 1.875M Bait), jadi ia tidak meningkatkan lebar jalur terburuk dengan ketara. Selepas penggabungan, masa blok adalah statik dan bukannya taburan Poisson yang tidak dapat diramalkan, memberikan tempoh masa yang terjamin untuk penyebaran blok besar.

Walaupun dengan data panggilan terhad, beban berterusan EIP ini jauh lebih rendah daripada alternatif yang mengurangkan kos data panggilan kerana gumpalan tidak perlu disimpan selagi beban dilaksanakan. Ini memungkinkan untuk melaksanakan dasar di mana gumpalan ini mesti disimpan sekurang-kurangnya untuk beberapa waktu. Nilai khusus yang dipilih ialah zaman MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, iaitu kira-kira 18 hari, yang merupakan kelewatan yang lebih singkat berbanding dengan putaran satu tahun yang disyorkan (tetapi belum dilaksanakan) untuk melaksanakan sejarah muatan.

EIP-5656

Pelanggan harus sedar bahawa pelaksanaan mereka tidak menggunakan penimbal perantaraan (cth. fungsi C stdlibmemmove tidak menggunakan penimbal perantaraan) kerana ini merupakan vektor Penafian Perkhidmatan (DoS) yang berpotensi. Kebanyakan fungsi perpustakaan terbina dalam/standard untuk bait bergerak mempunyai ciri prestasi yang betul di sini.

Jika tidak, analisis Denial of Service (DoS) dan serangan keletihan memori adalah sama seperti opcode lain yang menyentuh memori, kerana sambungan memori mengikut peraturan harga yang sama. . Ciri ini tidak lagi disokong dan ERC-2535 atau jenis kontrak proksi lain harus digunakan sebaliknya.

Jika kontrak bergantung pada pembakaran Eter dengan mempunyai kontrak SELFESTRUCT sebagai benefisiari, kontrak itu tidak dibuat dalam transaksi yang sama.

Risiko berkaitan kontrak pintar

EIP1153

Pertimbangkan dua senario menggunakan opcodes TLOAD dan TSTORE:

Kontrak yang dipanggil menggunakan opcode ini

Kontrak panggilan opkod

ini

Berbanding dengan tradisional SSTORE dan SLOAD, storan sementara baharu terutamanya mengubah tempoh penyimpanan data Data yang disimpan dalam tstore dibaca melalui tload Data akan dikeluarkan selepas pelaksanaan transaksi, bukannya pada masa yang sama direkodkan secara kekal. Pembangun harus mengenali ciri opcode ini apabila menggunakannya untuk mengelakkan penggunaan yang salah yang boleh menyebabkan data ditulis secara salah ke dalam kontrak dan menyebabkan kerugian. Selain itu, data dalam tstore adalah pembolehubah persendirian dan hanya boleh diakses oleh kontrak itu sendiri. Jika anda ingin menggunakan data secara luaran, anda hanya boleh menghantarnya dalam bentuk parameter atau menyimpannya buat sementara waktu dalam pembolehubah stroage awam.

🎜Risiko 2: 🎜🎜Satu lagi potensi risiko ialah jika pembangun kontrak pintar tidak mengurus kitaran hayat pembolehubah storan sementara dengan betul, ia mungkin mengakibatkan data dikosongkan apabila ia tidak sepatutnya atau disimpan secara tidak betul. Jika kontrak menjangkakan untuk menggunakan data yang disimpan dalam storan sementara dalam panggilan berikutnya kepada transaksi, tetapi gagal mengurus kitaran hayat data ini dengan betul, data mungkin tersalah kongsi atau hilang antara panggilan, mengakibatkan ralat logik atau kelemahan Keselamatan. Memandangkan baki atau data elaun yang serupa dengan projek Token tidak dapat disimpan dengan betul, ia akan membawa kepada ralat dalam logik kontrak dan menyebabkan kerugian. Atau menggunakan opcode ini apabila menetapkan alamat pemilik akan menyebabkan alamat istimewa tidak direkodkan dengan betul dan dengan itu kehilangan pengubahsuaian parameter penting kontrak. 🎜

Pertimbangkan kontrak pintar yang menggunakan storan sementara untuk merekodkan harga transaksi buat sementara waktu di bursa mata wang kripto. Kontrak mengemas kini harga apabila setiap perdagangan selesai dan membolehkan pengguna menanyakan harga terkini untuk tempoh masa yang singkat. Walau bagaimanapun, jika reka bentuk kontrak tidak mengambil kira ciri bahawa storan sementara dikosongkan secara automatik pada penghujung urus niaga, maka pengguna mungkin mendapat urus niaga yang salah atau lapuk dalam tempoh dari penghujung satu urus niaga hingga permulaan urus niaga seterusnya. harga transaksi. Ini bukan sahaja boleh menyebabkan pengguna membuat keputusan berdasarkan maklumat yang salah, tetapi juga boleh digunakan secara berniat jahat, menjejaskan kredibiliti platform dan keselamatan aset pengguna. . Kesan EIP ini agak besar.

Gunakan create2 untuk mengatur semula kontrak di alamat yang sama untuk menaik taraf kontrak. Ciri ini tidak lagi disokong dan ERC-2535 atau jenis kontrak proksi lain harus digunakan sebaliknya. (Ini mungkin menjejaskan keselamatan kontrak dalam rantaian menggunakan create2 untuk melaksanakan kontrak boleh dinaik taraf)

Operasi DIRI dalam kontrak pintar membolehkan kontrak dimusnahkan dan baki kontrak dihantar ke alamat sasaran yang ditentukan. Dalam kes ini, kontrak menggunakan SELFESTRUCT untuk memusnahkan eter dan menghantar eter yang dimusnahkan kepada kontrak. Tetapi kontrak hanya boleh menjadi kontrak yang dibuat dalam transaksi yang sama (kontrak yang dibuat oleh kontrak ini atau kontrak lain dalam transaksi yang sama). Jika tidak, hanya eter akan dipindahkan tanpa memusnahkan kontrak (contohnya, jika ia memusnahkan diri sendiri dan benefisiari adalah kontrak yang memusnahkan diri, ini tidak akan menghasilkan sebarang perubahan). Ini akan menjejaskan semua kontrak yang bergantung pada selfdestruct untuk pengeluaran atau operasi lain.

Token Gas yang serupa dengan Token CHI 1 inci berfungsi dengan mengekalkan offset dan sentiasa melaksanakan CREATE2 atau SELFSTRUCT pada offset ini. Selepas kemas kini ini, jika kontrak pada offset semasa tidak dimusnahkan sendiri dengan betul, CREATE2 berikutnya tidak akan berjaya menggunakan kontrak tersebut.

Pelaksanaan cadangan ini tidak akan membawa kepada serangan langsung ke atas kontrak, tetapi akan merosakkan logik biasa kontrak asal yang digunakan yang bergantung pada operasi pemusnahan diri (kontrak yang hanya bergantung pada pemusnahan diri untuk pemindahan dana tidak akan terjejas. Jika operasi berikutnya mesti memerlukan pemusnahan diri Jika kontrak yang musnah dipadamkan, ia akan terjejas), menyebabkan kontrak berfungsi secara tidak dijangka Hanya untuk kontrak dan pengguna, ia boleh menyebabkan kontrak itu mogok, kehilangan dana dan bahaya lain (. contohnya, pada asalnya menggunakan create2 untuk menggunakan kontrak baharu di alamat asal, memusnahkan sendiri kontrak asal Kontrak yang dinaik taraf tidak lagi boleh digunakan dengan jayanya). Dalam jangka panjang, mengubah suai kefungsian opcode boleh membawa kepada isu pemusatan.

Sebagai contoh, bilik kebal kontrak perbendaharaan sedia ada dikemas kini:

create2 kontrak simpanan sementara digunakan untuk menyimpan sementara dana dalam bilik kebal

• Memusnahkan sendiri kontrak bilik kebal, dan dana dipindahkan ke kontrak sementara (hanya dana dipindahkan tanpa memusnahkan kontrak) )

• buat2 kontrak bilik kebal baru di alamat asal (gagal kerana kontrak bilik kebal asal tidak dimusnahkan)

• Hancurkan sendiri kontrak sementara dan pulangkan dana kepada bilik kebal (dana hilang, kontrak bilik kebal tidak dibuat)

• Bacaan lanjutan

Naik taraf Cancun akan meningkatkan lagi kelebihan daya saing Ethereum. Walau bagaimanapun, peningkatan ini membawa risiko kepada perubahan pada lapisan kontrak pintar teras, yang akan menjejaskan operasi selamat DApps sedia ada. Semasa pembangunan kontrak pintar, perubahan ini dan risiko yang mungkin disebabkan olehnya juga memerlukan perhatian yang tinggi. Anda boleh menghubungi Salus untuk semakan risiko atau sokongan audit, atau baca lebih lanjut untuk mengetahui tentang perubahan.

Atas ialah kandungan terperinci Pemeriksaan keselamatan penting sebelum menaik taraf di Cancun. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!