Kondisi Memprihatinkan dari Audit Web3, dan Apa yang Bisa Dilakukan

Balancer, sebuah protokol lama dan telah diaudit dengan baik, baru-baru ini "diretas." Yearn Finance yang juga telah diaudit dengan baik mengalami hal serupa. Beberapa tahun lalu Euler Finance "diretas" melalui fungsi yang diperkenalkan sebagai respons terhadap audit sebelumnya. USPD telah diaudit sebelum penerapan dan kemudian proses penerapan yang tidak diaudit itu sendiri diretas yang menyebabkan penghapusan total dalam waktu sekitar 3 bulan sejak peluncuran. Tidak ada yang memperhatikan percaya bahwa audit adalah jaminan sesuatu itu aman. Banyak yang mempertanyakan apakah audit tersebut berharga sama sekali.

Ini bukanlah hal baru. Ini bukan masalah web3. Dan, sejujurnya, ini bukanlah observasi yang sangat mendalam. Tetapi audit masih sangat menjadi hal yang penting. Proyek membayar untuk audit. Proyek mempromosikan audit. Orang berpura-pura membaca audit. Seringkali ketika produk yang telah diaudit dieksploitasi, orang bertanya mengapa dan bagaimana hal itu bisa terjadi.

Daripada menjawab semua itu secara langsung, kami akan menelaah beberapa audit terbaru untuk produk yang baru diluncurkan. Tujuan di sini bukan untuk mengolok-olok atau mengkritik siapa pun. Ini dipilih secara acak, terutama karena fokus pada hal-hal terkini. Itu tidak berarti mereka sangat buruk. Bahkan mereka tidak begitu buruk!

Maksud kami di sini bukan bahwa auditor melakukan sesuatu yang salah. Auditor melakukan apa yang diminta oleh proyek yang melibatkan mereka. Ruang lingkup audit ditetapkan oleh proyek. Sebagai contoh ekstrem: jika Do Kwon telah melibatkan auditor untuk skema stablecoin-nya, mereka akan mencatat bahwa itu berpotensi tidak stabil. Masalah tersebut akan ditandai "diakui" dan tidak ada yang akan dilakukan atau berbeda.

Masalah ini sama sekali tidak ada hubungannya dengan studi seperti yang mengklaim ekosistem Terra-LUNA Do sangat kuat. Sulit untuk memprediksi masa depan dan studi semacam itu dengan tepat dipandang sebagai pemasaran yang menguntungkan diri sendiri yang, pada akhirnya, mengakui masalah inti. Penelitian yang disponsori proyek diharapkan menggambarkan hal-hal dalam cahaya positif. Seluruh tujuan audit adalah untuk memberikan perspektif pihak ketiga yang objektif. Pujian berlebihan tidak dapat dipercaya dan audit bukanlah jaminan atau asuransi. Begitulah hidup.

Tujuan dari survei ini adalah untuk menekankan bahwa masalah sebenarnya di sini bukanlah kesalahan pemrograman dasar dari jenis yang auditor dapat mengidentifikasi dengan baik dan proses audit dirancang dengan baik untuk menyelesaikannya. Auditor cukup baik dalam menangkap hal-hal tersebut. Jadi, dalam hal ini, programmer yang membangun hal-hal ini sejak awal juga demikian. Secara empiris umpan balik semacam ini sampai ke orang yang tepat dan masalah sempit diperbaiki.

Tidak, masalah sebenarnya adalah produk yang bekerja persis seperti yang dimaksudkan dan di mana "risiko" yang diketahui terwujud untuk menghancurkan semuanya. Apa yang akan Anda lihat sekarang adalah auditor mencoba melindungi diri mereka terhadap semua masalah masa depan yang diketahui-tidak diketahui. Sebagai latihan perlindungan-dari-tanggung jawab-dan-ejekan mungkin ini adalah hal yang berharga. Tetapi, secara umum, ini tidak membantu siapa pun.

Dan kemudian pada akhirnya kami akan membahas apa yang dapat dilakukan oleh berbagai pihak yang akan membantu dan melayani kepentingan sempit mereka sendiri. Jika resep Anda tentang cara meningkatkan audit melibatkan altruisme maka, yah, itu tidak terlalu berguna.

Jovay

Jovay adalah L2 yang terkait dengan Ant Financial atau Alibaba atau sesuatu di area umum itu. Tetapi tidak terlalu penting apa yang dilakukan Jovay. Ini adalah sesuatu yang dibangun dari perangkat lunak dari organisasi besar dan didanai dengan baik. Audit ini mencantumkan delapan masalah:

1. Kesalahan pemrograman yang sah yang kemudian diperbaiki.
2. Bahwa protokol tidak trustless. Ini adalah masalah dalam beberapa hal tetapi juga merupakan bagian inti dari desain.
3. Serangan "fake-recharge" yang berlaku untuk sebagian besar ekosistem dan tidak spesifik untuk proyek.
4. Server RPC menggunakan HTTP daripada HTTPS. Antarmuka ini tidak memproses informasi rahasia. Ini berlaku untuk miliaran situs web read-only yang sangat aman.
5. Komputasi kuantum menimbulkan risiko bagi Ethereum. Oke. Sangat on-topic yang satu itu.
6. Kontrak pintar EVM dapat rentan. Tidak serius. Ini mengatakan "Kontrak pintar Evm rentan terhadap berbagai vektor serangan karena penerapan kode yang tidak dapat diubah dan interaksi kompleks, yang berpotensi menyebabkan pencurian dana,.." Oke. Sekali lagi sangat menghormati fokus sempit dari audit ini.
7. Desain sequencer tunduk pada MEV. Seperti seluruh ekosistem Ethereum lainnya. Itu juga terlalu gelap di malam hari.
8. Kualitas kode dapat ditingkatkan. Tidak seperti sebagian besar kode lain yang ditulis sejak fajar komputasi.

Hanya satu dari ini yang merupakan masalah nyata. Ya, perlu dicatat bahwa produk itu sendiri tidak trustless jika dokumentasi menyatakan bahwa itu trustless. Tetapi produk ini cukup baik dalam hal itu. Mencatat bahwa komputasi kuantum berpotensi menimbulkan risiko masa depan dan kontak pintar bisa berisiko...itu adalah upaya untuk membuat laporan lebih panjang dengan menemukan masalah yang dibuat-buat atau mereka adalah upaya untuk memberikan semacam "bukan salah kami" jika sesuatu akhirnya diretas. Mungkin campuran dari keduanya.

Dalam semangat poin-poin tersebut kami mengusulkan sebagai masalah kesembilan bahwa jaringan akan mati ketika matahari mati kecuali kita menjadi spesies antarbintang dan entah bagaimana mencari tahu komunikasi lebih cepat dari cahaya. Jika tidak, relativitas membatasi masa pakai sistem ini menjadi sekitar 5 miliar tahun. Sejujurnya itu lebih berguna daripada menyatakan bahwa kualitas kode dapat ditingkatkan karena bahkan setelah Matahari mati masih akan ada kode buruk yang dieksekusi di suatu tempat. Tapi kami bercanda.

Hyperliquid

Hyperliquid telah menerbitkan beberapa laporan audit. Laporan audit pertama menemukan enam masalah dan laporan kedua mengonfirmasi bahwa masalah tersebut telah diselesaikan. Tetapi ruang lingkup audit mengecualikan:

1. Kontrak pintar lain yang merupakan bagian dari sistem Hyperliquid
2. Komponen off-chain, seperti validator
3. Komponen front-end
4. Infrastruktur yang berkaitan dengan proyek
5. Penyimpanan kunci

Itu tampaknya seperti area masalah potensial! Yang diaudit hanyalah satu kontrak bridge. Tetapi sistemnya, yah, jauh lebih rumit dari itu.

Mengaudit satu sudut kecil sistem yang hanya melakukan beberapa hal yang didefinisikan dengan ketat cukup tidak berguna. Cara Hyperliquid dirancang, kontrak yang diaudit adalah titik masuk dan keluar eksternal untuk semua orang. Jadi itu akan menjadi masalah serius jika kontrak itu penuh dengan kesalahan. Tetapi mengonfirmasi kontrak bekerja memberikan sedikit atau tidak ada kenyamanan.

Ondo

Audit ini menyoroti "RISIKO SENTRALISASI UNTUK ENTITAS DAN PERAN TERPERCAYA" yang diakui oleh tim. Itu dikapitalisasi seperti itu dalam laporan. Benar.

Audit ini mencatat bahwa sistem mungkin runtuh jika stablecoin yang terlibat depeg terlalu keras. Mereka menyatakannya sebagai sistem "akan memungkinkan pencetakan token OUSG yang berlebihan selama peristiwa depeg USDC." Pada akhirnya "solusi" yang mereka masukkan adalah referensi ke oracle Chainlink dan tombol off jika harga dilaporkan terlalu rendah. Jadi daripada meledak dengan nilai yang jatuh, protokol akan berhenti dengan nilai yang jatuh. Benar. Ini bukan masalah yang dapat dipecahkan karena tidak ada mekanisme untuk menghindari hasil kehilangan nilai jika USDC meledak. Dan, sejalan dengan fakta itu, solusinya tidak benar-benar memperbaiki apa pun.

Audit tersebut relatif baru. Tetapi untuk memberikan beberapa konteks, audit ini dari Oktober 2022 mengidentifikasi banyak masalah nyata. Hampir 200 dari mereka. Sebagian besar diperbaiki, beberapa mirip dengan yang di atas dan hanya diakui. Intinya adalah bahwa audit dulu melakukan sesuatu yang konkret dan substansial: mencari kesalahan pemrograman yang tidak mungkin menjadi niat programmer. Programmer biasa memperbaiki kesalahan ini karena mereka, Anda tahu, kesalahan asli bukan hanya keputusan desain yang dipertanyakan yang dibangun ke dalam produk.

Dan kemudian pada tahun 2024 kami melihat audit yang menemukan relatif sedikit masalah teknis dan menyatakan sebagai di luar cakupan serangan terkait keuangan. Satu-satunya cara yang masuk akal untuk menafsirkan perubahan ini dari waktu ke waktu adalah bahwa programmer, dan programmer-sebagai-auditor, menyadari bahwa kode yang berfungsi bukan satu-satunya risiko. Tentu bug pemrograman dieksploitasi dari waktu ke waktu. Tetapi pada pertengahan 2024 semua orang bisa melihat bahwa mekanisme ekonomi yang cacat juga merupakan risiko besar. Mereka adalah risiko terbesar.

Proyek yang bekerja persis seperti yang dimaksudkan – bukan seperti yang diimpikan, seperti yang dimaksudkan dalam kenyataan – meledak dari waktu ke waktu karena impian stabilitas desainer pecah ketika dihadapkan dengan dunia nyata.

Anda dapat melihat evolusi ini dalam audit dari satu proyek ini.

Mutuum Finance

Sekarang kami memiliki reductio ad absurdum dari audit. Yang satu ini mengidentifikasi satu masalah:

Masalahnya adalah kurangnya transparansi seputar distribusi token awal dan bagaimana hal itu mungkin terkait dengan masalah sentralisasi. Ini telah "dimitigasi" karena:

Kemudian ada banyak detail multisig. Dan akhirnya respons auditor:

Jadi risiko dengan proyek ini adalah bahwa tim kecil mengendalikan segalanya dan cara di mana kontrol itu akan, atau mungkin tidak akan, dibubarkan benar-benar tidak transparan. Dan solusi yang diusulkan tim untuk menulis posting blog untuk memperjelas niat mereka tidak, dalam arti yang ketat, memperbaiki ini.

Untuk catatan, tim telah menerbitkan daftar rinci tentang token apa yang akan pergi ke mana dan kapan. Dan mereka mengakui ini tidak lengkap dengan komentar seperti "Kami sedang mempertimbangkan model distribusi blok-demi-blok atau mingguan." Mereka juga mengakui semuanya akan dikelola dari multisig manual. Jadi mereka jujur. Hanya saja kejujuran itu sama dengan "ya kami masih bisa melakukan apa pun yang kami inginkan dan Anda harus mempercayai kami."

Apa tujuan dari audit ini? Jika kode tidak memiliki bug yang dapat diidentifikasi, auditor bisa saja menulis itu. Kadang-kadang perjalanan ke dokter atau mekanik menghasilkan tagihan kesehatan yang bersih. Jadi kami bertanya-tanya apakah hanya sejumlah kecil kode yang diaudit? Atau mungkin proyek itu sendiri hanya sejumlah kecil kode? Apakah auditor merasa perlu memasukkan sesuatu dalam laporan karena semuanya terlalu hampa? Mengapa ada orang yang repot-repot dengan semua ini?

Sekali lagi kami tidak benar-benar menyalahkan auditor di sini. Sejauh ada orang yang melakukan sesuatu yang salah di sini, hampir pasti itu adalah masalah insentif dengan siapa pun yang menugaskan audit. Dan fakta bahwa mereka menghabiskan uang investor untuk menghasilkan dokumen yang sebagian besar tidak berguna untuk tujuan pemasaran. Itu bukan urusan auditor!

Perbaikan

Ini adalah hal yang tidak diragukan lagi baik bahwa lebih banyak bug tertangkap, lebih sedikit kode yang rusak dirilis ke produksi dan lebih banyak perbaikan yang diusulkan diimplementasikan. Dan kami tidak cukup belum dewasa untuk menyarankan bahwa masalahnya adalah pengguna dan investor peduli tentang hal-hal yang salah seperti, misalnya, menempatkan nilai dan kepercayaan pada audit yang tidak berarti banyak. Orang peduli tentang apa yang mereka pedulikan dan mencoba mengubahnya adalah tugas orang bodoh.

Tetapi ada beberapa perbaikan nyata yang dapat kami sarankan. Ethena memimpin jalan dengan menjelaskan beberapa dari banyak mode kegagalan produk mereka di muka. Tim konsisten dengan pesan bahwa USDe tidak bebas risiko. Dan mereka menguraikan cara-cara yang bisa bermasalah. Produk telah bertahan, dengan beberapa guncangan, dan cukup besar hari ini. Ini memberi kami poin tindakan untuk investor: bersikeras proyek jujur tentang "serangan terkait keuangan" yang mungkin ada.

Ethena menunjukkan bahwa bersikap jujur tidak membuat proyek terpuruk! Anda dapat berargumen bahwa dengan lebih jujur proyek menarik lebih banyak minat. Kejujuran juga memiliki bonus tambahan untuk memberikan lebih banyak perlindungan hukum jika sesuatu yang salah terjadi. Proyek harus ingin melakukan ini sudah.

Auditor, juga, dapat mengatur ulang cara mereka melakukan analisis untuk membuat pekerjaan mereka lebih berguna. Atau setidaknya kurang tidak berguna dan berpotensi menyesatkan. Jangan memasukkan masalah insentif ekonomi atau kekhawatiran umum seperti keamanan kuantum di bagian yang sama dengan bug. Saat ini ini biasanya diberi label dengan cara yang sedikit membedakan mereka dari kesalahan pengkodean. Atau mereka terdaftar sebagai "informasional" sebagai lawan dari "kritis."

Tetapi ini melewatkan intinya. Keamanan kuantum mungkin saja menjadi risiko "kritis" untuk sistem – tetapi itu memiliki karakter yang sama sekali berbeda dari pemeriksaan tanda tangan yang buruk atau tanda minus yang salah! Masukkan hal-hal ini di bagian terpisah. Demikian pula "skema stablecoin ini tidak stabil dalam kondisi yang wajar-kemungkinan" tidak sama dengan bug logika dalam kode. Membersihkan kebingungan ini harus meningkatkan penampilan dokumen audit dan memoles reputasi auditor.

Akhirnya, bursa dapat membantu ini. Bursa besar mendapat banyak kritik karena mencantumkan proyek yang buruk, atau memecoin berisiko yang bergerak liar yang membuat orang kehilangan uang, atau semua cara keputusan bisnis aneh yang menimbulkan kerugian lainnya. Bagaimana jika bursa bersikeras pada audit yang wajar yang mencakup stabilitas ekonomi dengan jujur dan tidak mencampuradukkan risiko seperti "kontrak pintar dapat rentan" dengan pemeriksaan logika nyata?

Satu cara untuk menafsirkan auditor yang mengisi hasil mereka dengan pengisi semacam ini adalah bahwa tidak ada yang akan menganggap hasil audit kosong dengan serius. Cukup adil bahwa dokumen semacam itu akan menimbulkan pertanyaan. Tetapi jika bursa besar mencantumkan token dengan, katakanlah, dua hasil audit "kosong" yang cocok yang tidak termasuk masalah khusus proyek dan mengambil posisi ini adalah hal yang baik...itu mungkin membantu memindahkan bola sedikit ke depan. Kami juga berada di titik dalam siklus di mana menjadi bursa yang lebih "jujur" dan "wajar" harus memberi Anda lebih banyak pelanggan daripada kurangnya pemasaran ke bulan yang konyol membebani Anda.

Demikian pula, tidak boleh ada stigma yang melekat pada mengaudit proyek dan mengatakan itu terlihat baik. Yang satu ini ada pada auditor. Mungkin sekelompok auditor dapat mengeluarkan beberapa pernyataan bersama di area ini. Ya, kami dapat memahami bahwa auditor akan ingin memasukkan peringatan untuk masalah potensial yang dikesampingkan dari ruang lingkup ketika keterlibatan dimulai. Juga cukup adil. Tetapi mengisi hasil dengan masalah potensial umum yang tidak berguna bukanlah jawabannya. Juga tidak mengatakan tim mengurangi risiko sentralisasi dengan membuat posting blog tentang distribusi token yang mereka maksudkan untuk mengurutkan secara manual, segera, pada beberapa jadwal yang masih harus ditentukan.

Audit dapat berguna. Audit dapat membantu. Dan kenyataannya adalah bahwa audit web3 telah menangkap masalah nyata dan, untuk periode waktu yang signifikan, dipenuhi dengan konten yang berguna dan menarik. Tetapi insinyur telah meningkat dari waktu ke waktu karena mereka, Anda tahu, insinyur dan itulah yang mereka lakukan. Auditor perlu mengikuti dan, untuk meminjam kata, berinovasi sedikit. Dan banyak bagian yang lebih besar dari ekosistem, seperti bursa, dapat membantu memindahkan ini juga.