Tes properti umum untuk brankas ERC4626

Seiring DeFi tumbuh dan matang, infrastruktur yang dapat diskalakan dan komposisi menjadi hal utama bagi pengembang. Ethereum Requests for Comments (atau ERC) — toolkit standar untuk membangun aplikasi berbasis Ethereum, seperti standar token yang banyak digunakan ERC20 — melayani peran penting dalam memberikan pedoman yang konsisten bagi pengembang untuk berkontribusi pada ekosistem tanpa memulai dari awal. Awal tahun ini, standar kubah tokenized ERC4626 dibuat untuk mendorong kompatibilitas silang di antara token yang menghasilkan. Menstandardisasi detail implementasi juga dapat mengatasi masalah komposisi yang mendesak, membuat integrasi protokol menjadi lebih mudah dan pada akhirnya mengurangi kemungkinan kesalahan.

Beberapa proyek DeFi sudah diadopsi standar, mencari untuk meningkatkan komposisi kubah mereka, dan kami mengantisipasi adopsi yang lebih luas di seluruh ekosistem. Namun, mengadaptasi brankas yang ada memang menyebabkan beberapa rasa sakit; kritis, kesalahan implementasi tertentu dapat mengekspos target baru untuk serangan. Bahkan kesalahan kecil (sekecil salah menafsirkan antarmuka standar) dapat memiliki konsekuensi yang signifikan baik untuk keamanan dan pengalaman pengguna, menggarisbawahi perlunya lebih banyak alat dan tindakan keamanan, terutama dalam ekosistem DeFi yang lebih dapat disusun. 

Untungnya, kesalahan sederhana dapat memiliki solusi yang relatif sederhana jika terdeteksi dengan baik sebelum dieksploitasi (dan idealnya bahkan sebelum diterapkan). Untuk itu, kami merilis Tes properti ERC4626 untuk fuzzing dan eksekusi simbolis untuk membantu pembuat vault mendeteksi pelanggaran standar yang dapat merusak integrasi atau menyebabkan kerentanan di masa mendatang. Dalam posting ini, kami menjelaskan masalah yang memotivasi, menelusuri pendekatan kami, dan menyimpulkan dengan beberapa saran yang dapat ditindaklanjuti.

Pertama, sedikit latar belakang tentang standar ERC4626

Selesai pada bulan Maret, ERC4626 adalah standar untuk brankas yang diberi token. Itu diperkenalkan untuk memperluas yang banyak digunakan ERC20 standar (saat ini merupakan basis untuk ratusan token), mendorong standarisasi di seluruh vault yang menghasilkan, dan memastikan komposisi untuk aplikasi dan protokol (misalnya agregator hasil) yang perlu berinteraksi dengannya. Ini berarti bahwa aplikasi apa pun yang dibangun di brankas ERC4626 dapat dengan mudah diperluas untuk bekerja dengan brankas ERC4626 lainnya. 

Vault yang di-token memungkinkan pengguna untuk dengan bebas menyetorkan aset ke saham vault, dan kemudian menebus saham tersebut untuk menarik pokok dan bunga dari vault. Saham vault ini adalah token ERC20, dan dengan demikian dapat dengan mudah diperdagangkan atau digunakan sebagai jaminan untuk meminjam aset lain. Misalnya, pengguna dapat menyimpan aset mereka di brankas Yearn untuk mencetak token yVault, yang kemudian dapat diperdagangkan di Uniswap, dipertaruhkan untuk hasil tambahan, atau digunakan sebagai jaminan untuk protokol pinjaman.

Logika bisnis untuk menghasilkan dan mendistribusikan hasil (dan menentukan harga saham) dapat bervariasi di seluruh implementasi. Untuk mencakup sebanyak mungkin vault (dengan tujuan menjadikannya interoperable vs. identik), standar ERC4626 berfokus pada penggambaran antarmuka pengguna, sehingga sebagian besar detail implementasi tidak ditentukan. Ini memungkinkan variasi dalam logika bisnis selama brankas memenuhi persyaratan khusus antarmuka, dan mendorong interoperabilitas di berbagai jenis aplikasi dan jenis brankas ERC4626.

Karena lebih banyak vault dibuat, kami berharap untuk melihatnya diimplementasikan sesuai dengan standar ERC4626 sejak awal; tetapi kami saat ini berada dalam fase transisi, di mana pengembang yang ingin memanfaatkan komposisi yang lebih besar perlu memperbarui vault, aplikasi, dan protokol yang ada agar sesuai dengan standar. Dan saat mereka meningkatkan, mereka menghadapi sejumlah kompleksitas dan tantangan. 

Tantangan kesesuaian standar (dan perangkap kegagalan untuk menyesuaikan diri)

Mengikuti standar baru tidak selalu mudah. Setiap lemari besi ERC4626 harus dengan setia (dan tepat) menerapkan persyaratan standar seperti yang dijelaskan. Jika tidak, integrasi brankas ERC4626 menjadi semakin kompleks untuk memperhitungkan variasi yang berbeda. Kompleksitas ini membuat integrasi secara inheren rawan kesalahan; dan karena mereka tidak cukup bukti di masa depan, mereka dapat menyebabkan kerentanan keamanan dari waktu ke waktu.

Token ERC20 non-standar (misalnya, Tether USD) memerlukan banyak sistem DeFi untuk menggunakan pustaka tambahan (seperti SafeERC20) saat melakukan transfer token untuk menangani perilaku divergen dengan aman (misalnya tidak mengembalikan apa pun saat transfer berhasil alih-alih mengembalikan true). Ini berarti bahwa sistem apa pun yang berinteraksi dengan token ini dapat menjadi rentan jika sistem tidak dirancang untuk menangani kasus “pengembalian yang hilang” dengan benar. Skenario ini berpotensi menimbulkan jebakan keamanan umum, dan meningkatkan biaya pengembangan dan pemeliharaan secara keseluruhan (saat mempertimbangkan logika dan dependensi tambahan yang diperlukan untuk mengurangi masalah). Sesuai dengan standar karena itu sangat penting tidak hanya untuk implementasi individu tetapi juga untuk keamanan seluruh ekosistem. Satu kerentanan dalam satu sistem atau ketergantungan dapat menyebabkan masalah yang meluas.

Idealnya, standar akan ditentukan secara formal tanpa ambiguitas (misalnya, spesifikasi formal ERC20), dan setiap implementasi dapat diverifikasi secara formal terhadap spesifikasi standar. Namun dalam prakteknya, hal ini tidak mudah untuk dicapai dalam waktu singkat, karena membutuhkan biaya dan tenaga dari masyarakat.

Memperkenalkan properti ERC4626 yang dapat dieksekusi untuk mengidentifikasi masalah kesesuaian 

Saat kami bekerja menuju keadaan ideal (setiap lemari besi diverifikasi secara formal terhadap spesifikasi formal yang ketat), kami telah menulis standar ERC4626 properties untuk menangkap perbedaan dalam detail persyaratan standar yang halus dan mudah terlewatkan.  

Pengembang Vault dapat menjalankan pengujian untuk mendeteksi potensi pelanggaran standar dalam penerapannya sebelum penerapan. Dan integrator vault dapat memeriksa apakah vault yang diberikan mengikuti standar sebelum mengintegrasikannya ke dalam sistem mereka. Properti juga dapat diuji terhadap vault langsung yang sudah digunakan di mainnet, melalui pengujian fork mainnet. Pengujian live vault mungkin berguna — terutama ketika vault telah diterapkan atau ditingkatkan baru-baru ini — untuk memastikan bahwa semua parameter sistem telah disetel dengan benar. 

Kami memilih pengujian berbasis properti — ditulis dalam Foundry dan siap dijalankan oleh fuzzernya — agar properti dapat dieksekusi (dan karenanya dapat diuji). Di masa depan, mereka juga dapat dijalankan oleh eksekusi simbolis atau alat pemeriksaan model untuk memverifikasi secara formal bahwa vault yang diberikan memenuhi properti untuk semua input dan kondisi yang mungkin.

Kami menulis properti agar cukup umum untuk diterapkan ke berbagai vault yang menerapkan logika bisnis yang berbeda. Kami hanya menggunakan fungsi antarmuka publik untuk membuatnya agnostik terhadap detail implementasi. (Namun, karena pembatasan ini, persyaratan standar tertentu yang merujuk pada data internal khusus implementasi dihilangkan dari properti.)

Misalnya, properti berikut sesuai dengan salah satu persyaratan dari: convertToShares() fungsi, "TIDAK HARUS menunjukkan variasi apa pun tergantung pada penelepon.” Mengingat dua alamat akun dan jumlahnya, itu membuat masing-masing akun menelepon convertToShares() dengan jumlah yang sama, dan memastikan kedua nilai pengembalian sama. Properti ini tidak tergantung pada detail implementasi dari convertToShares(), yang bervariasi di seluruh vault dan harus dipenuhi oleh vault yang menerapkan ERC4626. Properti ini dapat dieksekusi dengan memberikan nilai input spesifik (untuk pengujian unit), banyak input acak (untuk pengujian fuzz), atau nilai simbolis (untuk eksekusi simbolis dan verifikasi formal). Itu juga dapat dijalankan secara lokal atau melawan garpu mainnet (untuk pengujian integrasi).

Use case: properti yang menguji kesalahan pembulatan

Kesalahan pembulatan, misalnya, adalah kelas penting dari bug (tampaknya kecil) yang dapat memiliki beberapa implikasi seri. Logika akuntansi yang mendasari ERC4626, misalnya, menghitung jumlah saham yang akan dicetak, atau jumlah aset yang akan ditarik, diimplementasikan menggunakan aritmatika titik tetap — kesalahan pembulatan tidak dapat dihindari. Untuk keamanan, namun, standar secara eksplisit menentukan arah pembulatan yang disukai untuk setiap fungsi antarmuka, sementara membiarkan batas kesalahan tidak ditentukan dan bergantung pada implementasi. Secara khusus, deposit() dan redeem() fungsi harus kembali dan bawah-perkiraan nilai eksak, sedangkan mint() dan withdraw() fungsi harus kembali dan lebih-perkiraan. Misalnya, jika harga saham saat ini (yaitu, jumlah aset per saham) adalah 2, maka deposit() dengan 3 wei aset hanya boleh mencetak hingga 1 wei saham (yaitu, floor(3/2)), sementara withdraw() dengan 3 wei aset harus membakar setidaknya 2 wei saham (yaitu, ceil(3/2)).

Kami menulis properti terkait pembulatan menjadi independen dari logika akuntansi yang mendasarinya dengan memperlakukannya sebagai kotak hitam. Secara khusus, kami merumuskannya sebagai apa yang disebut properti "pulang pergi", yang menggambarkan hubungan antara dua fungsi yang berlawanan. Misalnya, properti berikut menetapkan bahwa penarikan aset yang baru saja diwakafkan dengan mencetak N saham harus membakar tidak kurang dari N saham. Dengan kata lain, tidak ada yang bisa mendapatkan keuntungan gratis dengan mengkonversi aset dan saham vault bolak-balik dengan mencetak dan menarik berulang kali.

Memang, kami menemukan bahwa beberapa brankas ERC4626 di mainnet gagal memenuhi properti di atas karena kesalahan pembulatan. Ini berarti bahwa siapa pun dapat memperoleh, misalnya, beberapa satoshi BTC (1 satoshi ~= 0.02 sen pada saat penulisan) hanya dengan (dan berulang kali) mencetak dan menarik, perlahan-lahan menguras brankas. Ini sebenarnya dapat menghasilkan keuntungan pada rantai yang menikmati biaya gas yang sangat rendah (misalnya, Fantom), atau jika harga aset menjadi cukup tinggi di masa depan.

Menguji standar ERC4626 di alam liar

Kami menguji properti kami terhadap ~100 kubah ERC4626 di mainnet, dan menemukan banyak brankas yang gagal mengikuti persyaratan standar — sebagian besar karena kesalahan pembulatan (misalnya, menggunakan pembulatan lantai di mana langit-langit diinginkan, seperti yang kami jelaskan). Secara khusus, brankas tertentu gagal mencetak jumlah pasti saham yang diminta oleh mint() fungsi, meskipun standar secara eksplisit membutuhkan ini. Beberapa dari mereka juga mengeluarkan suara yang tidak konsisten Deposit peristiwa di mana data yang dicatat berbeda dari apa yang sebenarnya dicetak. Yang mengejutkan kami, beberapa brankas tidak pernah dicetak di tempat sama sekali; sebagai gantinya, mereka hanya memasukkan permintaan mint ke dalam antrian, dan memprosesnya nanti dalam batch sebagai transaksi terpisah.

Meskipun perilaku yang berbeda ini tidak dapat dieksploitasi, mereka mungkin menjadi rentan ketika diintegrasikan ke dalam sistem lain yang hanya mengharapkan perilaku standar. Masalah-masalah ini akan membuat integrasi vault jauh lebih sulit, berpotensi menetralkan upaya yang sedang berlangsung dan mendorong motivasi di balik standardisasi.

Menggunakan pengujian properti kami, dan langkah-langkah lain yang dapat ditindaklanjuti menuju kesesuaian standar

Mengikuti standar dengan tepat dapat mencegah perilaku yang berbeda (idealnya sebelum diterapkan). Kami berharap properti kami membantu, bersama dengan beberapa item tindakan tambahan. Bagi mereka yang mengembangkan dan/atau mengintegrasikan brankas ERC4626:

• Kami sangat merekomendasikan menjalankan properti kami tes terhadap brankas Anda. Mereka akan segera menemukan masalah jika ada pelanggaran standar yang jelas.
• Kami juga menyarankan untuk meninjau kami properties untuk memeriksa silang pemahaman Anda tentang persyaratan standar, dan menyesuaikan penerapan Anda jika ada perbedaan yang tidak disengaja.
• Jika lemari besi Anda harus menyimpang dari standar, sebaiknya dokumentasikan dengan jelas perilaku non-standar, sehingga orang lain dapat menangani penyimpangan ini dengan benar saat berintegrasi dengan lemari besi Anda. Harap dicatat bahwa ini harus dianggap sebagai upaya terakhir.

***
Vault ERC4626 berpotensi menjadi blok bangunan penting untuk DeFi di masa mendatang — dan, demi kompatibilitas, penting bagi vault baru dan yang sudah ada untuk mengikuti standar. Implementasi baru akan muncul mengikuti standar, jadi tidak ada waktu yang lebih baik daripada saat ini untuk menstandarisasi brankas yang ada. 

Saat kami bekerja menuju keadaan ideal (di mana berbagai vault dapat dikomposisi secara seragam), pengujian properti ERC4626 dapat dijalankan untuk lebih mudah mendeteksi pelanggaran standar dalam implementasi vault. Tes properti (dengan dokumentasi dan contoh) semuanya tersedia untuk umum di Github . kami gudang. Kami menyambut umpan balik dan kontribusi Anda!

***
Pandangan yang diungkapkan di sini adalah pandangan individu AH Capital Management, LLC (“a16z”) yang dikutip dan bukan pandangan a16z atau afiliasinya. Informasi tertentu yang terkandung di sini telah diperoleh dari sumber pihak ketiga, termasuk dari perusahaan portofolio dana yang dikelola oleh a16z. Meskipun diambil dari sumber yang dipercaya dapat dipercaya, a16z belum memverifikasi informasi tersebut secara independen dan tidak membuat pernyataan tentang keakuratan informasi saat ini atau yang bertahan lama atau kesesuaiannya untuk situasi tertentu. Selain itu, konten ini mungkin termasuk iklan pihak ketiga; a16z belum meninjau iklan tersebut dan tidak mendukung konten iklan apa pun yang terkandung di dalamnya.

Konten ini disediakan untuk tujuan informasi saja, dan tidak boleh diandalkan sebagai nasihat hukum, bisnis, investasi, atau pajak. Anda harus berkonsultasi dengan penasihat Anda sendiri mengenai hal-hal itu. Referensi ke sekuritas atau aset digital apa pun hanya untuk tujuan ilustrasi, dan bukan merupakan rekomendasi investasi atau penawaran untuk menyediakan layanan konsultasi investasi. Selanjutnya, konten ini tidak ditujukan atau dimaksudkan untuk digunakan oleh investor atau calon investor mana pun, dan dalam keadaan apa pun tidak dapat diandalkan saat membuat keputusan untuk berinvestasi dalam dana yang dikelola oleh a16z. (Penawaran untuk berinvestasi dalam dana a16z hanya akan dilakukan dengan memorandum penempatan pribadi, perjanjian berlangganan, dan dokumentasi lain yang relevan dari dana tersebut dan harus dibaca secara keseluruhan.) Setiap investasi atau perusahaan portofolio yang disebutkan, dirujuk, atau dijelaskan tidak mewakili semua investasi dalam kendaraan yang dikelola oleh a16z, dan tidak ada jaminan bahwa investasi tersebut akan menguntungkan atau bahwa investasi lain yang dilakukan di masa depan akan memiliki karakteristik atau hasil yang serupa. Daftar investasi yang dilakukan oleh dana yang dikelola oleh Andreessen Horowitz (tidak termasuk investasi yang penerbitnya tidak memberikan izin kepada a16z untuk mengungkapkan secara publik serta investasi yang tidak diumumkan dalam aset digital yang diperdagangkan secara publik) tersedia di https://a16z.com/investments /.

Bagan dan grafik yang disediakan di dalamnya hanya untuk tujuan informasi dan tidak boleh diandalkan saat membuat keputusan investasi apa pun. Kinerja masa lalu tidak menunjukkan hasil di masa depan. Konten berbicara hanya pada tanggal yang ditunjukkan. Setiap proyeksi, perkiraan, prakiraan, target, prospek, dan/atau pendapat yang diungkapkan dalam materi ini dapat berubah tanpa pemberitahuan dan mungkin berbeda atau bertentangan dengan pendapat yang diungkapkan oleh orang lain. Silakan lihat https://a16z.com/disclosures untuk informasi penting tambahan