TLDR: ERC-4626 adalah standar untuk brankas token.
Sebelum pengenalan ERC-4626, setiap lemari besi memiliki spesifikasi dan detail implementasinya sendiri. Hal ini membuat integrasi menjadi sulit, rawan kesalahan, dan pemborosan sumber daya.
ERC-4626 mencoba memecahkan masalah ini dengan spesifikasi standar untuk mengurangi upaya integrasi dan membuat model implementasi yang lebih konsisten dan kuat, seperti halnya ERC-20.
Apa itu ERC-4626?
ERC-4626 adalah standar yang meningkatkan parameter teknis kubah hasil. Ini menyediakan API standar untuk kubah hasil yang mewakili bagian dari satu token ERC-20 yang mendasarinya.
Vault yang diberi token telah menjadi model yang sangat umum di DeFi. Agregator hasil, pasar pinjaman, derivatif taruhan, dan banyak dApps lainnya memanfaatkan dan mengandalkan brankas token. Contoh kubah token termasuk Yearn dan Balancer. Sebagai agregator hasil, Yearn Vault memungkinkan pengguna menyetor aset digital dan mendapatkan hasil. Balancer adalah manajer portofolio otomatis dan penyedia likuiditas yang mengandalkan brankas sebagai inti dari logika bisnisnya. Kubah ini mengelola token di berbagai kumpulan. Pada saat yang sama, mereka memisahkan manajemen token dari logika kumpulan itu sendiri.
Protokol meningkatkan likuiditas dan fleksibilitas dengan menandai brankasnya. Vault yang diberi token memudahkan untuk bertransaksi dan menggunakan aset pada platform DeFi. Selain itu, mereka memungkinkan terciptanya beragam produk keuangan yang saling berhubungan. Industri telah memperjuangkan paradigma ini, yang sering disebut sebagai "lego uang".
Namun, komposisi tanpa kemampuan beradaptasi atau standardisasi yang tepat menghadirkan tantangan. Tidak hanya menyulitkan pengembang untuk mematuhi standar industri seperti ERC-20, tetapi juga dapat membingungkan pengembang baru. Tanpa adaptasi atau standardisasi yang tepat, sulit untuk meninjau perubahan baru dan memverifikasi detail implementasi integrasi.
Jadi ERC-4626 diusulkan untuk mengatasi masalah ini dan menyederhanakan integrasi, sambil memungkinkan peserta DeFi untuk akhirnya mengadopsi spesifikasi brankas terpadu yang lebih aman dan kuat. Ini pada gilirannya akan mengurangi kemungkinan permukaan serangan protokol sambil mengintegrasikan token di beberapa protokol.
Masalah keamanan apa yang dapat dicegah ERC-4626?
Dengan menyediakan standar terpadu, ERC-4626 mempercepat pembangunan integrasi lintas protokol. Standar yang akrab dan konsisten juga lebih mudah dipahami oleh pengembang, mengurangi kemungkinan kesalahan pengkodean. Ini membantu mencegah masalah komposisi. Standardisasi juga mencegah duplikasi upaya, karena komunitas hanya perlu mendesain vault satu kali, bukan secara individual untuk setiap protokol. Karena upaya desain ini sering rawan kesalahan, ini membantu menghindari duplikasi cacat desain yang sudah mapan tetapi meluas.
Kami akan menyajikan dua studi kasus di sini untuk menunjukkan masalah apa yang dapat dicegah oleh ERC-4626.
Acara Rari Capital
Sekitar $11 juta token dicuri dari Rari Capital, yang setara dengan 60% dari semua dana pengguna di kumpulan Rari Capital Ethereum.
Secara keseluruhan, Rari Capital diretas karena implementasi lintas protokol yang tidak aman. Kumpulan Ethereumnya membawa ETH ke dalam kontrak token ibETH Alpha Finance sebagai strategi keluaran. Strategi khusus ini melacak nilai nilai tukar ibETH/ETH melalui kontrak dan formula tertentu (khususnya, fungsi ibETH.totalETH / ibETH.totalSupply), yang mungkin memiliki keluaran yang salah dalam skenario serangan ini, misalnya, saat memanggil ibETH.work ( ) fungsi, nilai utang dapat digelembungkan secara artifisial.
Penyerang dapat menghabiskan Rari Fund Manager hanya dengan berulang kali memanggil fungsi penyetoran dan penarikan dalam kontrak RariFundManager. Fungsi deposit dan penarikan perlu mendapatkan saldo kumpulan untuk menghitung jumlah token REPT yang akan dikeluarkan ke penelepon, atau jumlah ETH yang akan dikeluarkan ke penelepon. Operasi ini akan memanggil fungsi getBalance dari kumpulan Alpha , panggil kontrak ibETH dan fungsi totalETH-nya. Rari tidak mengetahui kemungkinan manipulasi fungsi ini.
Ada fungsi lain dalam kontrak ibETH: ibETH.work. Fungsi ini dapat memanggil kontrak apa pun yang ditentukan oleh pengguna. Hal ini memungkinkan fungsi setoran dan penarikan Rari untuk masuk kembali dan dipanggil berkali-kali.
Fungsi kerja adalah fungsi berbayar, yang berarti pengguna dapat mengontrol jumlah ETH dalam kontrak ibETH melalui fungsi kerja, sehingga mengubah nilai yang dikembalikan oleh fungsi totalETH. Lebih buruk lagi, fungsi kerja juga mendukung pemanggilan kontrak lainnya, seperti RariFundManager.
Melalui fungsi ini, penyerang dapat mengirim ETH lagi dan meningkatkan jumlah totalETH dalam kontrak ibETH, dan pada saat yang sama memanggil penarikan dalam kontrak RariFundManager untuk menebus lebih banyak aset.
Insiden ini menyoroti risiko signifikan yang ditimbulkan oleh integrasi yang tidak memadai dan desain yang tidak kompatibel dalam kontrak DeFi. Ini menyoroti bagaimana standar seperti ERC-4626 dapat mencegah serangan semacam itu dengan menambahkan lapisan keamanan dan prediktabilitas kritis, dan mempromosikan perilaku seragam dan saling pengertian.
Kasus Krim Keuangan
Cream Finance mengalami serangan canggih yang mengeksploitasi dua kelemahan mendasar dalam platform: oracle pencampuran yang dimanipulasi dan pasokan token yang tidak ditutup. Bagian penting dari serangan itu adalah manipulasi oracle pencampuran, yang memengaruhi nilai yang dirasakan dari token yUSD. Ketika penyerang mengirim sejumlah besar token Yearn 4-Curve ke lemari besi yUSD, dia mengubah nilai tukar yang dilaporkan oleh lemari besi dan oleh karena itu juga memengaruhi nilai yang dirasakan dari token yUSD ke oracle.
Pelajaran utama di sini adalah bahwa oracle harga yang kuat dan tidak dapat dimanipulasi sangat penting untuk stabilitas protokol DeFi. Oracle harga rata-rata tertimbang waktu (TWAP) dapat membantu mencegah peretasan semacam itu karena mereka lebih tahan terhadap manipulasi harga mendadak.
Masalah ini, dan pola desain rapuh lainnya, dapat dikurangi melalui penerapan dan penerapan ERC-4626 yang cermat.
Potensi risiko keamanan di ERC-4626
Selalu ada beberapa trade-off dengan menggunakan protokol baru. Untuk brankas token, mungkin ada masalah potensial yang mengintegrasikannya ke dalam kontrak pintar yang memerlukan perhatian khusus.
Kelola token feeOnTransfer
Jika vault dirancang untuk mendukung token feeOnTransfer, periksa apakah jumlah dan pembagian di vault berada dalam kisaran yang diharapkan saat mentransfer aset.
Penggunaan variabel desimal yang tepat
Meskipun fungsi convertTo tidak perlu menggunakan variabel desimal EIP-4626 vault, masih sangat disarankan untuk mencerminkan desimal token yang mendasari jika memungkinkan. Praktik ini membantu menghilangkan potensi sumber kebingungan dan menyederhanakan integrasi untuk berbagai pengguna front-end dan off-chain.
pembulatan
Menurut spesifikasi, pelaksana vault harus menyadari bahwa arah pembulatan yang spesifik dan berlawanan diperlukan dalam metode tampilan dan perubahan yang berbeda, karena lebih aman untuk memprioritaskan vault itu sendiri daripada penggunanya selama perhitungan:
Jika menghitung jumlah saham yang akan diterbitkan kepada pengguna untuk jumlah token dasar yang mereka tawarkan, atau jika beroperasi untuk mentransfer bagian tertentu dari token dasar kepada pengguna, harus dibulatkan ke bawah.
Jika menghitung berapa banyak saham yang harus diberikan pengguna untuk mendapatkan sejumlah token dasar, atau jika menghitung berapa banyak token dasar yang harus diberikan pengguna untuk mendapatkan sejumlah saham tertentu, seharusnya dibulatkan.
Di mana arah pembulatan yang disukai akan menjadi ambigu adalah fungsi convertTo. Untuk memastikan konsistensi di semua implementasi vault EIP-4626, tentukan bahwa fungsi ini harus selalu dibulatkan ke bawah. Integrator dapat meniru versi pembulatan itu sendiri, misalnya dengan menambahkan Wei ke hasilnya.
Jumlah aset dasar yang diterima pengguna dengan menukarkan saham mereka di lemari besi (previewRedeem) dapat sangat bervariasi dari jumlah yang harus dibayarkan untuk mengeluarkan jumlah saham yang sama (previewMint). Perbedaan ini bisa kecil (misalnya karena kesalahan pembulatan) atau besar (misalnya lemari besi menerapkan biaya penarikan atau setoran). Oleh karena itu, integrator harus berhati-hati dalam menggunakan fungsi pratinjau yang paling sesuai dengan kasus penggunaannya, dan jangan pernah berasumsi bahwa keduanya dapat dipertukarkan.
Ganti fungsi inti
Untuk mengimplementasikan atau memperluas fungsionalitas yang dimaksud, disarankan untuk menggunakan hook yang ada daripada mengubah fungsionalitas inti. Praktik ini memastikan jejak yang lebih mudah dikelola untuk pengujian dan audit kode yang efisien.
Nol berbagi
Spesifikasi asli untuk ERC-4626 tidak menjelaskan cara menangani kasing sudut tanpa pembagian di lemari besi, dan apakah lemari besi harus berperilaku seperti biasa atau mundur. Ini bisa menjadi sumber potensial kebingungan dan kesalahan.
Vault sebagai ramalan harga
Sehubungan dengan risiko serangan manipulasi harga oracle, nilai yang dikembalikan oleh metode pratinjau ini seakurat mungkin. Dengan demikian, mereka dapat beroperasi dengan mengubah kondisi on-chain dan tidak selalu aman untuk digunakan sebagai oracle harga. Spesifikasi ERC-4626 mencakup metode konversi dan metode totalAssets yang memungkinkan ketidaktepatan, dan dengan demikian dapat diimplementasikan sebagai oracle harga yang kuat. Misalnya, saat mengonversi antara aset dan saham, sebaiknya gunakan harga rata-rata tertimbang waktu untuk menerapkan metode konversi.
Masalah implementasi konkret
Integrator harus meninjau implementasi vault token sebelum integrasi lebih lanjut, karena mungkin ada implementasi jahat yang tampaknya sesuai dengan spesifikasi antarmuka, tetapi fungsi intinya terdiri dari spesifikasi desain yang sama sekali berbeda.
Akses Langsung EOA
Jika vault ingin diakses secara langsung, implementasinya perlu memiliki fitur yang dapat digunakan untuk mengakomodasi kerugian slippage atau batas setoran/penarikan yang tidak disengaja. Tidak seperti smart contract, EOA tidak memiliki mekanisme failsafe untuk rollback transaksi. Jika output yang tepat tidak tercapai saat memanggil fungsi inti, tidak ada cara untuk melakukan rollback.
Vault Diperpanjang
Semakin banyak pemain yang mulai mengadopsi standar ERC-4626, kami akan melihat lebih banyak ekstensi yang diterapkan untuk standar tersebut. Misalnya, Superform mengembangkan ekstensi Multi Vault eksperimental yang mendukung penggunaan komputasi yang berbeda dalam satu kontrak Vault. Secara alami, semakin implementasi menyimpang dari standar asli, semakin tinggi kemungkinan memperkenalkan kerentanan baru. Pengembang dan auditor dapat menemukan opsi terbaik mereka berdasarkan kasus penggunaan untuk menentukan nilai aktual yang berisiko.
Penting untuk dicatat bahwa bukan penambahan terkecil dari setiap protokol yang mengarah pada peristiwa bencana, tetapi jumlah semuanya saat diintegrasikan.
Vektor serangan potensial yang disebutkan di atas adalah beberapa masalah yang lebih banyak dibahas seputar standar ERC-4626. Saat adopsi meningkat, kami pasti akan mengeksplorasi lebih banyak kasus penggunaan implementasi, dan skenario yang lebih cocok untuk diintegrasikan dengan brankas ERC-4626.
Lihat Asli
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Memahami ERC-4626 dalam satu artikel: standar baru untuk brankas token DeFi
TLDR: ERC-4626 adalah standar untuk brankas token.
Sebelum pengenalan ERC-4626, setiap lemari besi memiliki spesifikasi dan detail implementasinya sendiri. Hal ini membuat integrasi menjadi sulit, rawan kesalahan, dan pemborosan sumber daya.
ERC-4626 mencoba memecahkan masalah ini dengan spesifikasi standar untuk mengurangi upaya integrasi dan membuat model implementasi yang lebih konsisten dan kuat, seperti halnya ERC-20.
Apa itu ERC-4626?
ERC-4626 adalah standar yang meningkatkan parameter teknis kubah hasil. Ini menyediakan API standar untuk kubah hasil yang mewakili bagian dari satu token ERC-20 yang mendasarinya.
Vault yang diberi token telah menjadi model yang sangat umum di DeFi. Agregator hasil, pasar pinjaman, derivatif taruhan, dan banyak dApps lainnya memanfaatkan dan mengandalkan brankas token. Contoh kubah token termasuk Yearn dan Balancer. Sebagai agregator hasil, Yearn Vault memungkinkan pengguna menyetor aset digital dan mendapatkan hasil. Balancer adalah manajer portofolio otomatis dan penyedia likuiditas yang mengandalkan brankas sebagai inti dari logika bisnisnya. Kubah ini mengelola token di berbagai kumpulan. Pada saat yang sama, mereka memisahkan manajemen token dari logika kumpulan itu sendiri.
Protokol meningkatkan likuiditas dan fleksibilitas dengan menandai brankasnya. Vault yang diberi token memudahkan untuk bertransaksi dan menggunakan aset pada platform DeFi. Selain itu, mereka memungkinkan terciptanya beragam produk keuangan yang saling berhubungan. Industri telah memperjuangkan paradigma ini, yang sering disebut sebagai "lego uang".
Namun, komposisi tanpa kemampuan beradaptasi atau standardisasi yang tepat menghadirkan tantangan. Tidak hanya menyulitkan pengembang untuk mematuhi standar industri seperti ERC-20, tetapi juga dapat membingungkan pengembang baru. Tanpa adaptasi atau standardisasi yang tepat, sulit untuk meninjau perubahan baru dan memverifikasi detail implementasi integrasi.
Jadi ERC-4626 diusulkan untuk mengatasi masalah ini dan menyederhanakan integrasi, sambil memungkinkan peserta DeFi untuk akhirnya mengadopsi spesifikasi brankas terpadu yang lebih aman dan kuat. Ini pada gilirannya akan mengurangi kemungkinan permukaan serangan protokol sambil mengintegrasikan token di beberapa protokol.
Masalah keamanan apa yang dapat dicegah ERC-4626?
Dengan menyediakan standar terpadu, ERC-4626 mempercepat pembangunan integrasi lintas protokol. Standar yang akrab dan konsisten juga lebih mudah dipahami oleh pengembang, mengurangi kemungkinan kesalahan pengkodean. Ini membantu mencegah masalah komposisi. Standardisasi juga mencegah duplikasi upaya, karena komunitas hanya perlu mendesain vault satu kali, bukan secara individual untuk setiap protokol. Karena upaya desain ini sering rawan kesalahan, ini membantu menghindari duplikasi cacat desain yang sudah mapan tetapi meluas.
Kami akan menyajikan dua studi kasus di sini untuk menunjukkan masalah apa yang dapat dicegah oleh ERC-4626.
Acara Rari Capital
Sekitar $11 juta token dicuri dari Rari Capital, yang setara dengan 60% dari semua dana pengguna di kumpulan Rari Capital Ethereum.
Secara keseluruhan, Rari Capital diretas karena implementasi lintas protokol yang tidak aman. Kumpulan Ethereumnya membawa ETH ke dalam kontrak token ibETH Alpha Finance sebagai strategi keluaran. Strategi khusus ini melacak nilai nilai tukar ibETH/ETH melalui kontrak dan formula tertentu (khususnya, fungsi ibETH.totalETH / ibETH.totalSupply), yang mungkin memiliki keluaran yang salah dalam skenario serangan ini, misalnya, saat memanggil ibETH.work ( ) fungsi, nilai utang dapat digelembungkan secara artifisial.
Penyerang dapat menghabiskan Rari Fund Manager hanya dengan berulang kali memanggil fungsi penyetoran dan penarikan dalam kontrak RariFundManager. Fungsi deposit dan penarikan perlu mendapatkan saldo kumpulan untuk menghitung jumlah token REPT yang akan dikeluarkan ke penelepon, atau jumlah ETH yang akan dikeluarkan ke penelepon. Operasi ini akan memanggil fungsi getBalance dari kumpulan Alpha , panggil kontrak ibETH dan fungsi totalETH-nya. Rari tidak mengetahui kemungkinan manipulasi fungsi ini.
Ada fungsi lain dalam kontrak ibETH: ibETH.work. Fungsi ini dapat memanggil kontrak apa pun yang ditentukan oleh pengguna. Hal ini memungkinkan fungsi setoran dan penarikan Rari untuk masuk kembali dan dipanggil berkali-kali.
Fungsi kerja adalah fungsi berbayar, yang berarti pengguna dapat mengontrol jumlah ETH dalam kontrak ibETH melalui fungsi kerja, sehingga mengubah nilai yang dikembalikan oleh fungsi totalETH. Lebih buruk lagi, fungsi kerja juga mendukung pemanggilan kontrak lainnya, seperti RariFundManager.
Melalui fungsi ini, penyerang dapat mengirim ETH lagi dan meningkatkan jumlah totalETH dalam kontrak ibETH, dan pada saat yang sama memanggil penarikan dalam kontrak RariFundManager untuk menebus lebih banyak aset.
Insiden ini menyoroti risiko signifikan yang ditimbulkan oleh integrasi yang tidak memadai dan desain yang tidak kompatibel dalam kontrak DeFi. Ini menyoroti bagaimana standar seperti ERC-4626 dapat mencegah serangan semacam itu dengan menambahkan lapisan keamanan dan prediktabilitas kritis, dan mempromosikan perilaku seragam dan saling pengertian.
Kasus Krim Keuangan
Cream Finance mengalami serangan canggih yang mengeksploitasi dua kelemahan mendasar dalam platform: oracle pencampuran yang dimanipulasi dan pasokan token yang tidak ditutup. Bagian penting dari serangan itu adalah manipulasi oracle pencampuran, yang memengaruhi nilai yang dirasakan dari token yUSD. Ketika penyerang mengirim sejumlah besar token Yearn 4-Curve ke lemari besi yUSD, dia mengubah nilai tukar yang dilaporkan oleh lemari besi dan oleh karena itu juga memengaruhi nilai yang dirasakan dari token yUSD ke oracle.
Pelajaran utama di sini adalah bahwa oracle harga yang kuat dan tidak dapat dimanipulasi sangat penting untuk stabilitas protokol DeFi. Oracle harga rata-rata tertimbang waktu (TWAP) dapat membantu mencegah peretasan semacam itu karena mereka lebih tahan terhadap manipulasi harga mendadak.
Masalah ini, dan pola desain rapuh lainnya, dapat dikurangi melalui penerapan dan penerapan ERC-4626 yang cermat.
Potensi risiko keamanan di ERC-4626
Selalu ada beberapa trade-off dengan menggunakan protokol baru. Untuk brankas token, mungkin ada masalah potensial yang mengintegrasikannya ke dalam kontrak pintar yang memerlukan perhatian khusus.
Kelola token feeOnTransfer
Jika vault dirancang untuk mendukung token feeOnTransfer, periksa apakah jumlah dan pembagian di vault berada dalam kisaran yang diharapkan saat mentransfer aset.
Penggunaan variabel desimal yang tepat
Meskipun fungsi convertTo tidak perlu menggunakan variabel desimal EIP-4626 vault, masih sangat disarankan untuk mencerminkan desimal token yang mendasari jika memungkinkan. Praktik ini membantu menghilangkan potensi sumber kebingungan dan menyederhanakan integrasi untuk berbagai pengguna front-end dan off-chain.
pembulatan
Menurut spesifikasi, pelaksana vault harus menyadari bahwa arah pembulatan yang spesifik dan berlawanan diperlukan dalam metode tampilan dan perubahan yang berbeda, karena lebih aman untuk memprioritaskan vault itu sendiri daripada penggunanya selama perhitungan:
Jika menghitung jumlah saham yang akan diterbitkan kepada pengguna untuk jumlah token dasar yang mereka tawarkan, atau jika beroperasi untuk mentransfer bagian tertentu dari token dasar kepada pengguna, harus dibulatkan ke bawah.
Jika menghitung berapa banyak saham yang harus diberikan pengguna untuk mendapatkan sejumlah token dasar, atau jika menghitung berapa banyak token dasar yang harus diberikan pengguna untuk mendapatkan sejumlah saham tertentu, seharusnya dibulatkan.
Di mana arah pembulatan yang disukai akan menjadi ambigu adalah fungsi convertTo. Untuk memastikan konsistensi di semua implementasi vault EIP-4626, tentukan bahwa fungsi ini harus selalu dibulatkan ke bawah. Integrator dapat meniru versi pembulatan itu sendiri, misalnya dengan menambahkan Wei ke hasilnya.
Jumlah aset dasar yang diterima pengguna dengan menukarkan saham mereka di lemari besi (previewRedeem) dapat sangat bervariasi dari jumlah yang harus dibayarkan untuk mengeluarkan jumlah saham yang sama (previewMint). Perbedaan ini bisa kecil (misalnya karena kesalahan pembulatan) atau besar (misalnya lemari besi menerapkan biaya penarikan atau setoran). Oleh karena itu, integrator harus berhati-hati dalam menggunakan fungsi pratinjau yang paling sesuai dengan kasus penggunaannya, dan jangan pernah berasumsi bahwa keduanya dapat dipertukarkan.
Ganti fungsi inti
Untuk mengimplementasikan atau memperluas fungsionalitas yang dimaksud, disarankan untuk menggunakan hook yang ada daripada mengubah fungsionalitas inti. Praktik ini memastikan jejak yang lebih mudah dikelola untuk pengujian dan audit kode yang efisien.
Nol berbagi
Spesifikasi asli untuk ERC-4626 tidak menjelaskan cara menangani kasing sudut tanpa pembagian di lemari besi, dan apakah lemari besi harus berperilaku seperti biasa atau mundur. Ini bisa menjadi sumber potensial kebingungan dan kesalahan.
Vault sebagai ramalan harga
Sehubungan dengan risiko serangan manipulasi harga oracle, nilai yang dikembalikan oleh metode pratinjau ini seakurat mungkin. Dengan demikian, mereka dapat beroperasi dengan mengubah kondisi on-chain dan tidak selalu aman untuk digunakan sebagai oracle harga. Spesifikasi ERC-4626 mencakup metode konversi dan metode totalAssets yang memungkinkan ketidaktepatan, dan dengan demikian dapat diimplementasikan sebagai oracle harga yang kuat. Misalnya, saat mengonversi antara aset dan saham, sebaiknya gunakan harga rata-rata tertimbang waktu untuk menerapkan metode konversi.
Masalah implementasi konkret
Integrator harus meninjau implementasi vault token sebelum integrasi lebih lanjut, karena mungkin ada implementasi jahat yang tampaknya sesuai dengan spesifikasi antarmuka, tetapi fungsi intinya terdiri dari spesifikasi desain yang sama sekali berbeda.
Akses Langsung EOA
Jika vault ingin diakses secara langsung, implementasinya perlu memiliki fitur yang dapat digunakan untuk mengakomodasi kerugian slippage atau batas setoran/penarikan yang tidak disengaja. Tidak seperti smart contract, EOA tidak memiliki mekanisme failsafe untuk rollback transaksi. Jika output yang tepat tidak tercapai saat memanggil fungsi inti, tidak ada cara untuk melakukan rollback.
Vault Diperpanjang
Semakin banyak pemain yang mulai mengadopsi standar ERC-4626, kami akan melihat lebih banyak ekstensi yang diterapkan untuk standar tersebut. Misalnya, Superform mengembangkan ekstensi Multi Vault eksperimental yang mendukung penggunaan komputasi yang berbeda dalam satu kontrak Vault. Secara alami, semakin implementasi menyimpang dari standar asli, semakin tinggi kemungkinan memperkenalkan kerentanan baru. Pengembang dan auditor dapat menemukan opsi terbaik mereka berdasarkan kasus penggunaan untuk menentukan nilai aktual yang berisiko.
Penting untuk dicatat bahwa bukan penambahan terkecil dari setiap protokol yang mengarah pada peristiwa bencana, tetapi jumlah semuanya saat diintegrasikan.
Vektor serangan potensial yang disebutkan di atas adalah beberapa masalah yang lebih banyak dibahas seputar standar ERC-4626. Saat adopsi meningkat, kami pasti akan mengeksplorasi lebih banyak kasus penggunaan implementasi, dan skenario yang lebih cocok untuk diintegrasikan dengan brankas ERC-4626.