Peningkatan Cancun akan datang tidak lama lagi, apakah perkara yang perlu diberi perhatian dan potensi risiko?

Pendek cerita: Peningkatan Cancun semakin hampir, dan peningkatan ini terutamanya mengandungi perubahan lapisan eksekutif 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 masing-masing pada 17 Januari, 30 Januari dan 7 Februari, 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

EIP-1153

EIP-1153 memperkenalkan opcode storan sementara, yang digunakan untuk memanipulasi keadaan dan berkelakuan hampir sama seperti storan, tetapi storan sementara akan 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 (dengan "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.

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.

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.

EIP-5656

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

EIP-6780

EIP-6780 Mengubah suai fungsi kod opDESTRUCT DIRI. Dalam cadangan ini, SELFDESTRUCT hanya akan memadamkan akaun dan memindahkan semua eter dalam urus niaga yang sama seperti kontrak dibuat. Jika tidak, apabila melaksanakan SELFDESTRUCT, kontrak tidak akan dipadamkan, tetapi semua 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.

EIP-7516

EIP-7516 memperkenalkan arahan EVM baharu BLOBBASEFEE yang mengembalikan nilai yuran asas gumpalan dalam pelaksanaan blok semasa. Perintah ini serupa dengan opcode BASEFEE daripada EIP-3198, kecuali ia mengembalikan yuran asas gumpalan seperti yang ditakrifkan dalam EIP-4844. Ciri ini membolehkan kontrak mengambil kira 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 perkara 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 lanjut dengan kontrak dalam urus niaga yang sama (contohnya, dalam kes penguncian yang masuk 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. Jika tidak, opcode ini berkelakuan sama seperti SSTORE dan SLOAD , jadi semua pertimbangan keselamatan biasa dikenakan, 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 kependaman yang jauh lebih pendek daripada 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.

EIP-6780

Aplikasi berikut SELFESTRUCT akan rosak dan aplikasi yang menggunakannya dengan cara ini tidak lagi selamat:

WhereCREATE2 digunakan untuk mengatur semula kontrak di lokasi yang sama untuk menjadikan kontrak boleh dinaik taraf. 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 yang berkaitan dengan kontrak pintar

EIP1153

Pertimbangkan dua senario menggunakan opcodes TLOAD dan TSTORE:

1. Kontrak yang dipanggil menggunakan opcode ini
2. Kontrak panggilan opcode

Kontrak panggilan ini

Opcode

Berbanding dengan SSTORE dan SLOAD tradisional, storan sementara baharu terutamanya mengubah tempoh penyimpanan data Data yang disimpan dalam tstore dibaca melalui tload, dan data akan dikeluarkan selepas pelaksanaan urus niaga tidak direkodkan secara kekal seperti sstore . 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 pemaju 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 dagangan 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 yang boleh dinaik taraf)

Operasi DESTRUCT dalam kontrak pintar membolehkan kontrak dimusnahkan dan baki kontrak dihantar ke alamat sasaran yang ditetapkan. 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 kemusnahan sendiri Jika kontrak yang dimusnahkan dipadamkan, ia akan terjejas), menyebabkan kontrak berfungsi secara tidak dijangka Hanya untuk kontrak dan pengguna, ia boleh menyebabkan mogok kontrak, kehilangan dana dan lain-lain bahaya (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:

cipta 2 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)
• Kontrak sementara yang merosakkan diri memulangkan dana ke bilik kebal (dana hilang, bilik kebal kontrak tidak dibuat)

Atas ialah kandungan terperinci Peningkatan Cancun akan datang tidak lama lagi, apakah perkara yang perlu diberi perhatian dan potensi risiko?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!