Penulis: Xiao Bai
Artikel ini adalah kontribusi orisinal penulis, pandangan hanya mewakili pemahaman pribadi penulis, ETHPanda melakukan penyuntingan dan penyusunan konten.
Setelah AI Agent on-chain, masalahnya tidak lagi sekadar "bisakah dia mengobrol".
Dia mungkin menandatangani, menerima pembayaran, memulai transaksi, mendeploy kontrak, mengelola dompet, memanggil API, bahkan berkolaborasi dengan agent lain untuk menyelesaikan tugas. Pada saat ini, yang benar-benar dipedulikan pengguna bukan apakah dia punya nama yang bagus, melainkan:
Seberapa andalkah agent ini?
Apakah dompetnya bersih? Apakah kontrak yang terkait benar-benar ada? Apakah situs web dan API-nya berisiko? Apakah konten media yang dipublikasikannya dipalsukan? Apakah kode Solidity-nya memiliki kerentanan yang jelas? Apakah dia sudah pernah diserang?
ERC-8126 membidik masalah verifikasi semacam ini.
Sederhananya, ERC-8126 adalah lapisan verifikasi untuk AI Agent. Ia dibangun di atas agent registration (pendaftaran identitas) ERC-8004, memungkinkan verification provider independen untuk melakukan verifikasi multi-lapis di sekitar identitas agent yang sama, dan mengubah hasilnya menjadi sinyal risiko yang dapat dikonsumsi oleh dompet, pasar, aplikasi, dan agent lainnya.
Tujuannya bukan membuktikan suatu agent dapat dipercaya selamanya, melainkan menstandarkan "bagaimana memverifikasi sebuah agent, bagaimana mengekspresikan hasil verifikasi, dan bagaimana sistem lain membaca hasil tersebut".
Memiliki Identitas, Tidak Sama dengan Dapat Dipercaya
ERC-8004 menyelesaikan masalah identitas agent.
Anda dapat memahaminya seperti ini: pertama-tama, berikan AI Agent sebuah identitas di on-chain yang dapat didaftarkan, dapat ditemukan, dan dapat diindeks. Identitas ini akan sesuai dengan sebuah agentId, dan melalui metadata menggambarkan nama, dompet, endpoint, situs web, alamat kontrak, dan informasi lainnya dari agent tersebut.
Tapi identitas itu sendiri tidak sama dengan kepercayaan.
Sebuah agent jahat juga bisa mendaftarkan identitas. Sebuah agent phishing juga bisa menulis metadata yang bagus. Sebuah agent normal hari ini, tidak menjamin endpoint-nya tidak akan dibajak besok. Sebuah agent memiliki avatar, situs web resmi, alamat dompet, juga tidak berarti kontraknya aman, dompetnya bersih, kontennya asli.
Jadi, ERC-8004 lebih seperti menjawab:
Siapakah agent ini?
ERC-8126 selanjutnya bertanya:
Apakah agent ini layak untuk diinteraksi?
Bagaimana ERC-8126 Melakukan Verifikasi?
Pertama, permintaan verifikasi akan merujuk pada agentId di ERC-8004 Identity Registry. Verification provider kemudian membaca metadata yang sesuai melalui agentId ini, dan menganalisis informasi seperti dompet, kontrak, situs web, endpoint, konten media, dll., akhirnya menghasilkan skor risiko dan bukti verifikasi.
Proses ini dapat dibagi menjadi empat langkah:
- AI Agent pertama-tama mendaftarkan identitas melalui ERC-8004.
- Provider ERC-8126 membaca agentId dan metadata agent ini.
- Provider melakukan verifikasi multi-lapis pada agent.
- Hasil verifikasi dikonsumsi oleh dompet, pasar, dApp, atau agent lain dalam bentuk risk score, proof, attestation, dll.
Poin penting di sini adalah: ERC-8126 tidak memperkenalkan satu-satunya "lembaga sertifikasi resmi".
Ia lebih seperti pasar verification provider yang terbuka. Provider yang berbeda dapat menggunakan metode mereka sendiri untuk melakukan pemeriksaan keamanan, tetapi hasil output harus diekspresikan dalam format yang distandarkan. Dengan cara ini, dompet, agent marketplace, task market, dan aplikasi lain dapat membaca sinyal ini lintas platform.
Ini lebih maju daripada "proyek mengklaim sendiri bahwa mereka aman": ia memecah penilaian kepercayaan menjadi sinyal yang dapat diperiksa, dicatat, dan dibaca oleh pihak ketiga.
Verifikasi Lima Lapis: Memecah Agent untuk Diamati
ERC-8126 terutama mendefinisikan lima jenis verifikasi, masing-masing mencakup beberapa aspek yang paling mudah bermasalah setelah agent on-chain: kontrak, media, kode, situs web, dan dompet. Yang distandarkan adalah jenis verifikasi, ekspresi hasil, dan antarmuka yang dapat dikonsumsi, bukan mengubah setiap metode pemeriksaan keamanan menjadi satu-satunya metode audit resmi. Verification provider yang berbeda tetap dapat menggunakan proses deteksi dan model risiko mereka sendiri.
ETV: Token / Contract Verification
ETV memeriksa token atau kontrak yang terkait dengan agent.
Jika metadata agent menuliskan sebuah contractAddress, provider akan memeriksa apakah alamat ini benar-benar memiliki kode kontrak di chain yang sesuai, apakah ada risiko yang jelas, atau apakah hanya alamat palsu yang dimasukkan sembarangan.
Bagi pengguna, ETV menjawab:
Aset on-chain atau kontrak yang diklaim terkait oleh agent ini, apakah benar-benar nyata?
Karena begitu sebuah agent mulai menerima pembayaran, mengeluarkan token, melakukan staking, mengeksekusi strategi, kontrak di belakangnya bukan lagi sekadar hiasan, melainkan tempat di mana dana pengguna benar-benar akan bersentuhan.
MCV: Media Content Verification
MCV memeriksa konten media yang digunakan agent, seperti avatar, gambar, materi merek, gambar bukti, dll.
Ini terdengar tidak seperti masalah inti, tetapi sangat penting dalam skenario AI Agent. Sebuah agent palsu dapat menyalahgunakan logo proyek, memalsukan tangkapan layar resmi, bahkan menggunakan gambar yang dihasilkan AI untuk menciptakan kesan dukungan.
MCV memeriksa informasi seperti sumber konten, integritas, tanda-tanda pemalsuan, watermark, tanda tangan, dll.
Ia menjawab:
Apakah konten yang ditampilkan agent ini kepada pengguna telah dipalsukan atau dirusak?
SCV: Solidity Code Verification
SCV memeriksa keamanan kode Solidity atau kontrak yang terkait dengan agent.
Jika metadata berisi informasi kode atau kontrak terkait, provider dapat memeriksa risiko umum, seperti reentrancy, masalah izin, panggilan berbahaya, permukaan serangan flash loan, dll.
SCV dapat mengurangi beberapa risiko kontrak umum, tetapi tidak sama dengan audit manual lengkap.
Ia lebih seperti pintu masuk standar untuk pemeriksaan keamanan kontrak. Melalui SCV, tidak berarti kontrak benar-benar aman; ini menunjukkan bahwa kode atau kontrak agent ini telah melalui pemeriksaan oleh provider tertentu, dan menghasilkan sinyal risiko yang dapat dikonsumsi.
WAV: Web Application Verification
WAV memeriksa situs web, API, dan endpoint agent.
Banyak agent meskipun memiliki identitas on-chain, tetapi pintu masuk interaksi sebenarnya masih di off-chain, seperti situs web resmi, API, server MCP, endpoint A2A, atau dashboard.
Sekali tempat-tempat ini bermasalah, risikonya mungkin tidak lebih kecil daripada kontrak. Sertifikat situs web kedaluwarsa, pengguna mungkin diserang man-in-the-middle; API dibajak, agent mungkin mengeksekusi instruksi yang salah; front-end disuntik skrip berbahaya, pengguna mungkin menandatangani transaksi berbahaya.
WAV menjawab:
Apakah pintu masuk Web dan titik layanan agent ini aman?
WV: Wallet Verification
WV memeriksa risiko dompet agent.
Ia akan melihat apakah dompet ini memiliki riwayat transaksi, apakah baru dibuat dan kosong, apakah terkait dengan alamat berisiko tinggi, alamat phishing, alamat penyerang, atau objek lain dalam basis data threat intelligence.
WV menjawab:
Apakah catatan perilaku on-chain agent ini bersih?
Skor Risiko Terpadu: Membuat Dompet dan Aplikasi Benar-Benar Dapat Digunakan
ERC-8126 akan mengubah hasil verifikasi menjadi skor risiko 0 hingga 100.
Semakin rendah skor, semakin rendah risiko; semakin tinggi skor, semakin tinggi risiko.
- 0-20: Risiko rendah
- 21-40: Risiko sedang
- 41-60: Risiko meningkat
- 61-80: Risiko tinggi
- 81-100: Risiko serius
Desain ini memiliki makna produk yang sangat langsung.
Dompet tidak mungkin meminta pengguna biasa untuk membaca laporan keamanan lengkap setiap kali. Marketplace juga tidak cocok hanya mengandalkan penjelasan sendiri dari proyek untuk pengurutan. Sebuah risk score yang terpadu dapat menjadi input untuk strategi produk.
Misalnya:
- Jika skor risiko terlalu tinggi, dompet dapat memberikan peringatan atau mencegah interaksi.
- Tanpa hasil verifikasi, marketplace dapat mengurangi bobot tampilan.
- Jika risiko dompet tidak normal, task market dapat membatasi penerimaan pesanan.
- Jika risiko endpoint Web tinggi, front-end dapat memperingatkan pengguna untuk mengakses dengan hati-hati.
Namun, satu skor total tidak dapat mewakili semua situasi.
Risiko kontrak, risiko dompet, risiko situs web, risiko media, pada dasarnya adalah jenis risiko yang berbeda. Desain produk yang lebih baik adalah menampilkan skor total dan skor per item secara bersamaan, sehingga pengguna tahu di mana tepatnya masalahnya.
PDV dan ZKP: Membuktikan Telah Lulus Verifikasi, Tidak Sama dengan Membuka Semua Detail
Verifikasi agent akan melibatkan banyak informasi sensitif.
Misalnya kode sumber, konfigurasi infrastruktur, laporan keamanan, log privat, profil dompet, dll. Jika semuanya dipublikasikan, justru dapat memperluas permukaan serangan.
Karena itu, ERC-8126 memperkenalkan PDV dan ZKP.
PDV adalah Private Data Verification, ZKP adalah Zero-Knowledge Proof. Fungsinya adalah: memungkinkan agent membuktikan bahwa dirinya telah lulus verifikasi tertentu, tanpa harus membuka semua detail internal.
Anda dapat memahaminya seperti ini:
Yang dilihat dunia luar adalah "telah lulus verifikasi, berapa skor risikonya, di mana proof-nya", bukan bahan keamanan internal yang lengkap.
Ini membuat ERC-8126 lebih seperti ringkasan due diligence yang dapat diverifikasi, daripada membentangkan semua data langsung untuk dilihat seluruh jaringan.
ERC-8004 / ERC-8126 / ERC-8183: Identitas, Verifikasi, Transaksi
Jika ekonomi AI Agent dipecah menjadi tiga lapisan, dapat dipahami seperti ini. Di sini perlu dijelaskan statusnya: ERC-8126 telah masuk status Final, sedangkan ERC-8004 dan ERC-8183 masih dalam tahap Draft, jadi ketiganya lebih tepat dipahami sebagai arah infrastruktur yang sedang terbentuk, bukan tumpukan protokol yang sudah sepenuhnya terbentuk.
- ERC-8004: Identity membuat agent memiliki identitas, dapat didaftarkan, dapat ditemukan.
- ERC-8126: Verification membuat sinyal keamanan dan risiko agent dapat diverifikasi, dapat dikonsumsi.
- ERC-8183: Commerce membuat agent dapat menerima tugas, mengirimkan hasil, masuk ke proses escrow dan penyelesaian.
Lebih lugas:
- ERC-8004 menjawab: Siapa kamu?
- ERC-8126 menjawab: Apakah kamu dapat diandalkan?
- ERC-8183 menjawab: Bisakah kamu bekerja, menerima uang, menyelesaikan pembayaran?
Ketiganya disatukan, menampilkan narasi ekonomi agent yang cukup jelas:
Pertama memiliki identitas, kemudian verifikasi, baru akhirnya lebih mudah masuk ke transaksi dan penyelesaian.
Hubungan ini juga dapat dijelaskan lebih rinci. ERC-8126 memang dibangun di atas ERC-8004; ERC-8183 dan ERC-8126 lebih seperti pelengkap alami, bukan hubungan yang terikat kuat.
Dengan kata lain, protokol agent commerce seperti ERC-8183 secara alami dapat mengonsumsi sinyal verifikasi ERC-8126, misalnya memeriksa skor risiko agent sebelum menerima tugas, memverifikasi proof sebelum evaluator melepaskan pembayaran. Tapi ini lebih seperti arah kombinasi teknis, bukan ketergantungan keras ERC-8183 pada ERC-8126.
Apa Artinya Bagi Pengembang?
Jika hanya melihat AI Agent dari narasi pasar, diskusi mudah terjebak pada token, peluncuran, marketplace, dan panasnya transaksi. Tapi bagi mereka yang benar-benar ingin membuat produk agent, integrasi dompet, jaringan tugas, atau infrastruktur protokol, pertanyaan yang lebih krusial adalah: Ketika sebuah agent mulai mengelola aset, memanggil layanan, mengirimkan hasil, berkolaborasi dengan agent lain, siapa yang menanggung biaya kepercayaan?
Dulu, biaya ini kebanyakan dibebankan kepada pengguna. Pengguna sendiri yang menilai apakah proyek dapat diandalkan, sendiri yang melihat apakah kontrak diaudit, sendiri yang memeriksa apakah dompet bersih, sendiri yang mengidentifikasi apakah situs web resmi palsu, akhirnya sendiri yang menanggung konsekuensi tertipu atau interaksi gagal.
Nilai ERC-8126 terletak pada upayanya untuk memecah penilaian ini menjadi sinyal verifikasi yang terstandarisasi, dapat dikombinasikan, dan dapat dibaca oleh produk.
Ia tidak akan menghilangkan risiko, juga tidak dapat menjamin suatu agent dapat dipercaya selamanya. Tapi jika sinyal verifikasi semacam ini diadopsi oleh lebih banyak dompet, marketplace, dApp, dan jaringan agent, banyak keputusan produk dapat tidak lagi hanya bergantung pada penjelasan proyek sendiri.
Secara spesifik:
Bagi dompet, risk score dapat menjadi input untuk kontrol risiko sebelum transaksi dan peringatan risiko.
Bagi agent marketplace, hasil verifikasi dapat memengaruhi pengurutan, penyaringan, bobot tampilan, dan label risiko.
Bagi aplikasi AI x ETH, ia dapat menjadi pemeriksaan keamanan sebelum agent terhubung.
Bagi kolaborasi agent-to-agent, ia dapat membantu agent menyaring objek yang jelas berisiko tinggi sebelum bekerja sama.
Inilah alasan ERC-8126 layak diperhatikan: Ia bukan lagi sekadar ERC konsep AI, melainkan mencoba mendorong agent on-chain dari "dapat didaftarkan" ke "dapat diverifikasi, dapat dikontrol risiko".
Ia Masih Satu Set Standar, Bukan Jaringan yang Sudah Berjalan
Bagian ini dapat dilihat dari sudut pandang lain.
ERC-8126 mendefinisikan antarmuka standar dan kerangka kerja verifikasi. Ia menjelaskan bagaimana verifikasi dapat dilakukan, bagaimana hasil dapat diekspresikan, tetapi tidak sama dengan sekarang sudah ada jaringan verifikasi publik matang yang berjalan seragam lintas dompet, lintas marketplace, lintas chain.
Dari spesifikasi saat ini, ia telah menjelaskan beberapa hal:
- ERC-8126 mendefinisikan proses standar verifikasi agent.
- Ia meminta verifikasi mengikat ke agentId ERC-8004.
- Ia mencakup lima jenis risiko: token/kontrak, media, Solidity, Web, dompet.
- Ia mendukung skor risiko, proof, dan attestation.
- Ia menyediakan dasar bagi dompet, marketplace, dApp untuk mengonsumsi sinyal verifikasi.
Kemampuan ini benar-benar berfungsi, masih tergantung pada seberapa banyak provider, dompet, marketplace, dan aplikasi yang bersedia mengadopsi selanjutnya. Dengan kata lain, ia sekarang belum dalam keadaan seperti di bawah ini:
- Semua dompet sudah terintegrasi.
- Semua agent marketplace sudah mengadopsi.
- Semua provider menggunakan standar penilaian yang sepenuhnya konsisten.
- Seluruh industri telah membentuk verification network yang matang.
- ZKP dan skor risiko sudah sepenuhnya disatukan dalam lingkungan produksi.
Dengan kata lain:
ERC-8126 pertama-tama menstandarkan bahasa verifikasi AI Agent. Untuk menjadi lapisan kepercayaan publik, masih memerlukan provider, dompet, pasar, dan aplikasi untuk terus bergabung.
Kesimpulan
Setelah AI Agent memasuki ekonomi on-chain, identitas hanyalah titik awal, di belakangnya masih akan menghadapi masalah yang lebih praktis: apakah ia dapat diverifikasi.
ERC-8004 membuat agent memiliki identitas. ERC-8126 membuat risiko di balik identitas ini dapat diverifikasi. ERC-8183 kemudian memberi kesempatan pada agent untuk menggunakan sinyal verifikasi ini dalam skenario tugas, escrow, dan penyelesaian.
Jadi, makna ERC-8126 bukan memberikan lencana "dapat dipercaya selamanya" kepada agent, melainkan menstandarkan masalah yang lebih realistis:
Ketika sebuah AI Agent akan masuk ke dompet, pasar, jaringan tugas, dan alur transaksi on-chain, bagaimana seharusnya kita memeriksanya? Bagaimana seharusnya hasil pemeriksaan diekspresikan? Bagaimana seharusnya sistem lain mengonsumsi hasil ini?
Inilah mungkin lapisan kepercayaan yang perlu ditambahkan oleh ekonomi AI Agent selanjutnya.
Referensi
- ERC-8126: AI Agent Verification
- ERC-8126 Raw Markdown
- ERC-8004: Trustless Agents
- ERC-8183: Agentic Commerce
- Ethereum Magicians: ERC-8126 Discussion
- DonJohnson X Thread: Introducing ERC-8126
- Cybercentry Web3 Security & Verification Services
- ERC-8126 Scan







