Dengan standar ERC-8004 (Trustless Agents) yang telah di-deploy secara resmi ke mainnet Ethereum, manajemen identitas dan reputasi AI Agent memasuki tahap baru yang dapat diverifikasi dan tanpa kepercayaan. Standar ini menyediakan "sistem identitas" yang dapat diverifikasi di chain melalui tiga registri inti: registri identitas, registri reputasi, dan registri verifikasi. Artikel ini akan membahas dari perspektif audit keamanan, menggabungkan detail teknis ERC-8004, menganalisis poin-poin risiko setiap registri, dan memberikan panduan audit praktis bagi pengembang dan auditor.
Detail Teknis dan Poin Audit
Kunci dari ERC-8004 terletak pada tiga registrinya (Registry):
1. Registri Identitas (Identity Registry)
Berdasarkan handle on-chain minimal ERC-721, dengan ekstensi URIStorage, yang diurai ke file pendaftaran agen, memberikan pengenal yang dapat dibawa dan tahan sensor untuk setiap agen.
Dalam arsitektur ERC-8004, registri identitas dibangun di atas ERC-721 dan memperluas fungsionalitas URIStorage. Dengan kata lain, setiap agen di chain sesuai dengan NFT yang unik, NFT ini disebut AgentID.
Ketika pengembang membuat sebuah agen, mereka akan memanggil fungsi register dari kontrak registri, mencetak AgentID baru. Token ini mengikat sebuah tokenURI, yang menunjuk ke file JSON yang disimpan off-chain — yang disebut "file pendaftaran agen". File pendaftaran harus mengikuti spesifikasi ketat, biasanya mencakup tiga jenis konten inti:
- Informasi dasar, seperti nama, deskripsi, URL avatar;
- Titik akhir layanan, yaitu alamat jaringan di mana agen dapat diakses, mendukung berbagai protokol seperti HTTP, WebSocket, Libp2p, A2A, MCP;
- Pernyataan kemampuan, yaitu daftar tugas yang dapat dieksekusi agen, seperti pembuatan gambar, perdagangan arbitrase, atau audit kode.
Hanya pernyataan diri jelas tidak cukup untuk membangun kepercayaan, oleh karena itu ERC-8004 memperkenalkan mekanisme verifikasi domain. Agen harus menghosting file tanda tangan di domain yang dinyatakan, dengan path /.well-known/agent-card.json. Registri on-chain akan memverifikasi tautan ini, sehingga mengikat AgentID on-chain dengan domain DNS yang sesuai. Langkah ini bertujuan untuk mencegah serangan phishing dan peniruan identitas, agen tidak dapat secara sembarangan mengklaim milik domain tertentu, harus membuktikan kontrol dengan tanda tangan kriptografi.
Poin Audit:
● Periksa kontrol akses fungsi setTokenURI, pastikan hanya mengizinkan pemilik agen atau peran yang diotorisasi (seperti onlyOwnerAfterMint) untuk memperbarui URI.
● Tinjau apakah URI mendukung skema penyimpanan yang tidak dapat diubah (seperti IPFS, Arweave). Jika menggunakan tautan HTTP terpusat, perlu mengevaluasi keamanan kontrol domain, mencegah perampokan DNS.
● Verifikasi keabsahan format URI, hindari penunjuk nol atau URI tidak valid yang menyebabkan pengecualian kontrak.
● Verifikasi bahwa kontrak secara ketat mengeksekusi verifikasi tanda tangan kriptografi (seperti EIP-712) saat memverifikasi tanda tangan domain, mencegah pemalsuan tanda tangan atau serangan pemutaran ulang.
● Periksa mekanisme kedaluwarsa bukti kepemilikan domain, mencegah tanda tangan yang berlaku lama digunakan kembali.
● Pastikan proses resolusi domain tidak bergantung pada oracle terpusat, hindari kegagalan atau manipulasi titik tunggal.
2. Registri Reputasi (Reputation Registry)
Antarmuka standar untuk menerbitkan dan mendapatkan sinyal umpan balik. Pemberian skor dan agregasi terjadi baik on-chain (dapat dikomposisi) maupun off-chain (algoritma kompleks), memungkinkan terwujudnya ekosistem layanan profesional seperti penilaian agen, jaringan audit, dan kolam asuransi.
Digunakan untuk memberikan umpan balik evaluasi terhadap AI Agent yang telah terdaftar. Umpan balik sederhana dikirimkan on-chain, dapat diperluas off-chain untuk agregasi kompleks yang kemudian di-on-chain-kan.
ERC-8004 juga dapat mencegah penilaian curang melalui mekanisme "Payment-Proof Linking". Ketika Agen A menyelesaikan evaluasi terhadap Agen B, ia memanggil fungsi giveFeedback. Fungsi ini tidak hanya menerima skor (0-100) dan hash komentar, tetapi juga memungkinkan memasukkan bidang paymentProof, biasanya hash transaksi x402. Hal ini membuat biaya untuk mengevaluasi secara curang menjadi sangat tinggi, secara signifikan mengurangi kemungkinan serangan Sybil. Pada akhirnya, sistem secara alami akan memberi penghargaan kepada agen yang berkinerja stabil dan berkualitas tinggi.
Poin Audit:
● Verifikasi bahwa fungsi giveFeedback mewajibkan parameter paymentProof, dan periksa apakah parameter tersebut adalah hash transaksi x402 yang valid (atau memenuhi standar pembayaran lainnya). Pastikan bukti pembayaran tidak dapat digunakan kembali (seperti mencatat hash yang telah digunakan), mencegah evaluasi berkali-kali untuk satu pembayaran.
● Periksa apakah rentang penilaian (0-100) diberlakukan pada tingkat kontrak, hindari penilaian di luar batas yang merusak logika agregasi.
● Evaluasi ketahanan algoritma agregasi off-chain terhadap manipulasi: misalnya, apakah menggunakan median, memotong nilai ekstrem, atau rata-rata tertimbang, apakah memberikan hukuman untuk perilaku tidak normal (seperti sejumlah besar evaluasi dalam waktu singkat).
● Tinjau kondisi slashing yang jelas dan dapat diverifikasi, misalnya apakah bergantung pada bukti on-chain atau oracle pihak ketiga yang mengajukan bukti penipuan.
● Pastikan logika slashing tidak mengandung hak istimewa terpusat (seperti administrator dapat menyita jaminan secara sembarangan), kondisi pemicu slashing harus sepenuhnya dieksekusi secara otomatis oleh kontrak pintar.
● Uji periode penguncian dan kondisi penarikan jaminan, mencegah agen menarik dana darurat sebelum menghadapi slashing.
3. Registri Verifikasi (Validation Registry)
Pengait umum untuk meminta dan mencatat pemeriksaan oleh verifier independen (misalnya, verifier zkML, oracle TEE, wasit tepercaya).
Reputasi mencerminkan masa lalu, tetapi dalam skenario berisiko tinggi (seperti pengaturan dana besar), hanya mengandalkan sejarah saja tidak cukup. Registri verifikasi memungkinkan agen untuk menyerahkan hasil kepada pihak ketiga atau sistem otomatis untuk verifikasi, dapat menggunakan seperti eksekusi ulang inferensi aman yang dipertaruhkan, verifier zkML, atau oracle TEE untuk memverifikasi atau menolak permintaan.
Model pertama adalah verifikasi kripto-ekonomi, desain keamanan berbasis teori permainan. Agen harus mempertaruhkan sejumlah token asli atau stablecoin di registri. Jika agen gagal memenuhi kewajiban atau memberikan hasil yang salah, jaringan verifier dapat mengajukan bukti penipuan, memicu kontrak pintar untuk secara otomatis menyita jaminannya. Model ini cocok untuk tugas yang hasilnya mudah diverifikasi tetapi proses komputasinya tidak transparan, seperti pengambilan data atau layanan API sederhana.
Model kedua adalah verifikasi kriptografi, desain keamanan berbasis prinsip matematika. Sertifikasi TEE (Trusted Execution Environment) memungkinkan agen berjalan di lingkungan perangkat keras yang diamankan, seperti Intel SGX atau AWS Nitro. Registri verifikasi dapat menyimpan dan memverifikasi laporan autentikasi jarak jauh dari perangkat keras, membuktikan bahwa kode yang dijalankan agen确实是 versi spesifik yang belum dirusak.
zkML (Pembelajaran Mesin Zero-Knowledge) adalah cara verifikasi kriptografi lainnya. Agen, saat mengirimkan hasil inferensi, juga mengirimkan bukti zero-knowledge. Bukti ini dapat diverifikasi oleh kontrak verifikasi on-chain dengan biaya sangat rendah, secara matematis menjamin bahwa output tersebut确实 dihasilkan oleh model tertentu (seperti Llama-3-70B) dengan input tertentu. Ini dapat mencegah serangan "penukaran model", di mana penyedia layanan mengklaim menggunakan model high-end tetapi实际上 menggunakan model rendah untuk menghemat biaya.
Poin Audit
Jika verifikasi kripto-ekonomi, perlu diperiksa:
● Periksa periode pengajuan bukti penipuan: apakah memberikan waktu yang cukup bagi verifier untuk menemukan dan mengajukan bukti? Periode yang terlalu singkat mungkin melewatkan perilaku jahat, terlalu lama menyebabkan dana terkunci untuk waktu lama.
● Verifikasi logika adjudikasi bukti penipuan: apakah bergantung pada kumpulan verifier multi-tanda tangan? Jika ya, perlu meninjau tingkat desentralisasi pemilihan verifier dan pengaturan ambang batas; jika adjudikasi sepenuhnya on-chain, pastikan dasar adjudikasi (seperti hasil yang dapat diverifikasi on-chain) ada dan tidak ambigu.
● Pastikan jumlah jaminan sesuai dengan risiko, cegah perilaku jahat berbiaya rendah (seperti pertaruhan terlalu sedikit, keuntungan berbuat jahat jauh lebih besar daripada kerugian).
Jika sertifikasi TEE, perlu diperiksa:
● Periksa apakah kontrak memverifikasi ketepatan waktu bukti TEE (seperti mengandung stempel waktu atau tinggi blok), mencegah bukti kedaluwarsa diterima.
● Verifikasi apakah konten bukti mengandung hash kode agen, ringkasan input output, pastikan bukti terikat dengan tugas spesifik, hindari penggunaan kembali lintas tugas.
● Evaluasi apakah logika verifikasi bukti TEE bergantung pada oracle eksternal (seperti Intel IAS), jika bergantung, perlu mengaudit keamanan dan tingkat desentralisasi oracle.
Jika verifikasi zkML, perlu diperiksa:
● Konfirmasi bahwa kontrak mengintegrasikan library verifikasi zk yang telah diaudit (seperti SnarkVerifier), dan mengonfigurasi kunci verifikasi dengan benar untuk sistem bukti tertentu (seperti Groth16, PLONK).
● Periksa apakah kontrak verifikasi membatasi model dan rentang input yang berlaku untuk bukti, cegah serangan penukaran model (misalnya bukti dihasilkan untuk model kecil, tetapi diklaim sebagai output model besar).
● Evaluasi tingkat desentralisasi generasi bukti: apakah bergantung pada prover tunggal? Jika ada多个 prover, perlu merancang mekanisme konsensus untuk mencegah prover jahat.
Kesimpulan
ERC-8004 menyediakan standar untuk membangun kepercayaan AI Agent, keamanannya adalah kunci dari seluruh ekosistem Agen on-chain. Pekerjaan audit keamanan perlu memahami secara mendalam maksud desain dan risiko potensial dari tiga registri. Selain itu, kompleksitas interaksi antar kontrak dan kerentanan rutin juga tidak boleh diabaikan. Perlu melalui audit yang komprehensif dan ketat untuk memastikan ERC-8004 benar-benar memenuhi janji "tanpa kepercayaan" nya, meletakkan batu fondasi yang aman untuk masa depan agen otonom.
