Baru-baru ini, API3 mendapatkan $ 4 juta dalam funding strategis, dipimpin oleh DWF Labs dan diikuti oleh beberapa VC terkenal. Secara historis, pasar oracle telah didominasi oleh oracle pihak ketiga seperti Chainlink. Shisi terkejut dengan berita ini ~ Mengapa API3 bisa mengamankan funding? Mungkinkah itu pengganggu oracle tradisional? Apa yang membuatnya unik? Sebagai proyek API terdesentralisasi (dAPI), API3 mendefinisikan dirinya sebagai oracle "pihak pertama". Dengan memanfaatkan Jaringan OEV yang inovatif (berdasarkan ZK-Rollup), ini mengatasi masalah umum yang terkait dengan oracle pihak ketiga seperti kepercayaan perantara, transparansi data yang rendah, dan kontrol atas Oracle Extractable Value (OEV).

1. Bisakah oracle benar-benar memprediksi masa depan?

Istilah "oracle" membawa konotasi mitos, yang dapat dengan mudah menyesatkan publik. Pada kenyataannya, ini mengacu pada alat yang menyediakan data dunia nyata untuk on-chain smart contract. Tapi apa yang merupakan data nyata? Bagaimana integritas oracle itu sendiri dapat dipastikan? Bisakah oracle bertindak jahat? Bisakah beberapa oracle berkolusi? Bagaimana seharusnya kita memahami OVM (Oracle Extractable Value)?

Pada Q1 2024, menyusul lonjakan BTC baru-baru ini, nilai total token yang dikunci dalam proyek DeFi mencapai level tertinggi baru $175 miliar, menandai peningkatan hampir 70% dari $103 miliar pada Q4 2023. Orakel long dianggap sebagai sumber kehidupan DeFi. Di sektor DeFi, pertukaran terdesentralisasi (DEX), platform pinjaman, dan platform perdagangan derivatif semuanya bergantung pada data harga yang akurat agar berfungsi. Pada awal 2023, pinjaman terdesentralisasi protokol BONQ pada rantai Polygon dieksploitasi karena manipulasi kontrak oracle TellorFlex. Penyerang memodifikasi harga oracle dengan biaya rendah untuk melakukan pinjaman yang dijaminkan, menghasilkan keuntungan besar dan menyebabkan kerugian sekitar $ 88 juta untuk proyek tersebut. Serangan semacam itu yang berasal dari masalah harga Oracle telah menjadi hal biasa, menyoroti kebutuhan kritis akan data off-chain yang transparan dan andal untuk dukungan operasi dApp.

2. Bagaimana Oracle Menghubungkan Off-Chain dan On-Chain?

Oracle umumnya beroperasi dalam tiga mode: upload terjadwal, event-driven, dan request-response. Dengan menggunakan model permintaan-respons sebagai contoh, prosesnya secara kasar dapat dibagi menjadi empat langkah berikut:

• STEP 1: On-chain, dApp panggilan memulai permintaan (pada dasarnya transaksi), dan kontrak layanan oracle memicu peristiwa on-chain.
• STEP 2: Off-chain, node oracle mendengarkan acara untuk mendapatkan informasi dan kemudian mengumpulkan data off-chain yang akurat melalui sistem masing-masing.
• STEP 3: Off-chain dan on-chain, oracle menyediakan data ke kontrak layanan oracle dalam bentuk transaksi.
• STEP 4: On-chain, kontrak layanan oracle mengembalikan data ke dApp panggilan. Ini dapat dilakukan baik melalui push aktif atau dengan kueri dApp lagi.

Berikut penjelasan yang diperluas tentang proses ini:

Pertama, permintaan on-chain bersifat publik. Karena peristiwa adalah mekanisme umum dalam blockchain berbasis EVM, seluruh jaringan menyadari bahwa dApp memerlukan informasi tertentu.

Kedua, dorongan data off-chain bersifat non-atomik. Sementara transaksi on-chain diselesaikan secara real-time, data off-chain secara inheren memiliki beberapa latensi.

Akhirnya, jika permintaan on-chain disesuaikan, oracle dapat bertindak sebagai arbiter pihak ketiga dan mendorong data ke dApp. Namun, untuk data umum seperti harga BTC real-time, dApp biasanya akan mengambil data dari kontrak itu sendiri. Selain itu, oracle sering memiliki mekanisme pelaporan terjadwal. Prinsip dasar tetap konsisten di seluruh skenario yang berbeda ini.

3. Luna's Decoupling, Perlombaan Oracle yang Dinamis

Namun, blockchain tidak terbatas pada DeFi saja. Melalui oracle, dApps dapat mengakses data off-chain dengan aman dan efisien, sangat memperluas cakupan bisnis dan skenario aplikasi mereka. Hal ini memungkinkan arah bisnis mereka untuk memperluas ke keuangan, asuransi, manajemen rantai pasokan, IoT, dan banyak bidang lainnya.

Di pasar saat ini, menurut data platform dari DeFiLlama, Chainlink masih memegang posisi dominan, dengan TVL (Total Value Locked, dalam mata uang USD, diamankan oleh infrastruktur penting seperti oracle) menyumbang 45% dari seluruh pasar.

Pembaca yang cermat akan melihat bahwa kurva di sisi kanan grafik mengalami volatilitas yang parah pada Mei 2022. Katalisnya adalah peristiwa kecelakaan Luna yang terkenal selama 7 Mei hingga 13 Mei 2022, di mana utama stablecoin algoritmik UST mengalami dua insiden decoupling, akhirnya berputar menjadi kejatuhan bersama dengan Luna. Secara bersamaan, banyak proyek yang menggunakan oracle internal menghadapi masalah serius karena respons yang tertunda terhadap fluktuasi harga.

Grafik berikut dengan jelas menunjukkan penurunan tajam dalam pangsa pasar untuk oracle internal (ditampilkan dalam warna pink) pada Mei 2022. Oracle Chronicle (ditampilkan dalam warna merah) secara efektif menangkap lonjakan lalu lintas ini, pada dasarnya mengamankan pangsa pasar yang hilang oleh oracle internal.

4. Kesulitan Oracle Pihak Ketiga

Selain peristiwa yang mengguncang industri, tampaknya perkembangan oracle telah terhenti. Memang, karena posisi industri yang jelas sebagai alat untuk menjembatani on-chain dan off-chain data, produk oracle cenderung memiliki fungsi yang relatif mudah. Salah satu aspek yang paling dikritik adalah model keuntungan mereka, yang saat ini berkisar pada biaya berlangganan data dan apresiasi token yang dikeluarkan oleh tim proyek. Jelas, pendapatan yang dihasilkan dari model berlangganan data tunggal terbatas. Misalnya, mengambil fitur penghasil biaya Chainlink untuk Verifiable Random Function (VRF) sebagai contoh, menurut blockchain explorer Etherscan, saya menghitung bahwa total token terkunci untuk versi VRF V1 dan V2 berjumlah sekitar 370.000 (7 + 30), diterjemahkan menjadi sekitar $6 juta pendapatan berdasarkan tarif LINK saat ini ($16). Sejak peluncuran VRF V2 pada akhir Februari 2022, VRF V2 telah menghasilkan pendapatan sekitar $4.8 juta, rata-rata sekitar $170,000 per bulan (11,000 LINK). Dibandingkan dengan skala besar Chainlink, keuntungan ini memang sedikit. Adapun apresiasi token, pendapat bervariasi.

Namun, karena sifatnya sebagai entitas pihak ketiga, oracle secara inheren menempati posisi yang relatif netral dan mulai berfungsi sebagai infrastruktur penting dalam keamanan lapisan aplikasi. Untuk membebaskan diri dari kesan middleware tradisional dan meningkatkan profitabilitas, oracle membutuhkan ekspansi fungsional yang berbeda dan sistematis. Misalnya, LayerZero, sebagai cross-chain bridge biasa, bergantung pada keamanan yang dibawa oleh oracle dengan permintaan ultra-light node. Singkatnya, kesulitan oracle di pasar terletak pada keterbatasan operasional yang melekat, fungsionalitas tunggal, profitabilitas sederhana, dan skalabilitas yang belum diperluas. Meskipun demikian, memahami model eksekusi dari apa yang disebut oracle pihak ketiga mengungkapkan bahwa masalah mereka berasal dari sifat "pihak ketiga" mereka. API3, memposisikan dirinya sebagai pendatang baru di sektor oracle, berfokus untuk menjadi oracle "pihak pertama", yang bertujuan untuk mengatasi tantangan ini.

4.1 Membandingkan Oracle Pihak Ketiga dan Pihak Pertama

API3 telah memilih untuk memanfaatkan kemampuan operasionalnya yang komprehensif dalam mengaktifkan node layanan API, menggunakan pendekatan yang lebih web3-native (ringan + modular) untuk membangun bridge antara konsumen dan penyedia oracle. API operator dapat dengan cepat mengatur node oracle mereka sendiri menggunakan solusi Airnode API3.

Sebagai proyek Oracle pihak pertama, dibandingkan dengan aliran tradisional di mana penyedia API terhubung dengan oracle dan kemudian ke operasi dApp (penyedia API → oracle → dApp), pendekatan API3 (penyedia API + oracle) → dApp memberdayakan penyedia API untuk mengambil peran yang lebih sentral. Mereka tidak lebih lama hanya bertindak sebagai pekerja oracle pihak ketiga tetapi mendapatkan lebih banyak pengaruh dan otonomi dalam ekosistem.

Seperti yang digambarkan di atas, dengan penghapusan intervensi pihak ketiga, rantai data disederhanakan. Ketika penyedia API dan oracle menggabungkan peran, tidak ada lebih lama pertanyaan tentang dari mana data berasal, karena reputasi penyedia API terkait langsung dengan on-chain data.

Karena reputasi penyedia API yang digabungkan erat dengan data yang mereka berikan, pelacakan disederhanakan, dan secara teknis, perilaku jahat tidak boleh luput dari perhatian, didukung oleh mekanisme jaminan. Bahkan jika penyedia API dengan jahat memberikan data palsu untuk keuntungan pribadi, pengguna yang terkena dampak dapat mengajukan banding dan mengklaim kompensasi. Perselisihan yang kompleks, seperti kasus keluhan pengguna jahat untuk penipuan asuransi, akan diputuskan melalui sistem peradilan on-chain. Memanfaatkan mekanisme asuransi yang sepenuhnya terdesentralisasi yang disediakan oleh API3 DAO, API3 dapat secara efisien menghukum penyedia API dan memberi kompensasi kepada pengguna yang terkena dampak semaksimal mungkin.

5. Mendalami Tokenomik

API3 DAO tokenomik API3 DAO beroperasi secara stabil melalui mekanisme staking-nya, memanfaatkan loop umpan balik positif dan negatif.

5.1 Staking Mekanisme Tata Kelola

Mekanisme staking adalah praktik standar dalam tata kelola DAO, yang melibatkan keuntungan dari tata kelola staking dan staking, yang berfungsi sebagai titik awal untuk ekonomi sirkular. API3 telah mengoptimalkan proses ini lebih lanjut:

• Apa yang terjadi jika staker menarik diri setelah menerima hadiah staking? Imbalan inflasi yang dihasilkan dari staking (token yang baru dicetak) ditunda sebelum didistribusikan dan default mengalir kembali ke pool staking.
• Untuk apa lagi token di pool staking dapat digunakan? Mereka dapat digunakan untuk mengkompensasi kerugian pengguna.
• Bagaimana API3 menstabilkan harga token di pool staking? API3 mengendalikan inflasi melalui mekanisme Burn and Token Locking: Pengguna perlu membakar atau mengunci token mereka untuk mendapatkan layanan dAPI.

5.2 Loop Umpan Balik Positif dan Negatif Mengingat loop umpan balik positif dan negatif ini, tren apa yang akan ditunjukkan oleh kuantitas token di pool staking? Apakah ekspansi yang tidak terkendali atau dana yang tidak mencukupi untuk menutupi kompensasi menyebabkan keruntuhan? Mari kita analisis:

• Ketika pengguna dAPI meningkat, risiko sistem meningkat (biaya operasi naik dengan jumlah pengguna), utama lebih banyak peristiwa kompensasi. Akibatnya, token dalam pool staking menurun (digunakan untuk memberi kompensasi kepada pengguna yang terkena dampak), menyebabkan staker (dan manajer) menderita kerugian karena manajemen yang buruk. Namun, mengurangi token di pool staking juga berarti meningkatkan token yang mengalir ke pasar. Mengingat bahwa token yang dipegang oleh pengguna dipengaruhi oleh inflasi, sebagian besar masih kembali ke pool staking karena pertimbangan kepentingan pribadi pengguna.
• Ketika pengguna dAPI menurun, risiko sistem berkurang, menyebabkan token di pool staking meningkat secara bertahap, membuat token di pasar semakin langka. Meskipun demikian, ini tidak menyiratkan peningkatan terus-menerus dalam jumlah token pool staking; API3 DAO secara dinamis menyesuaikan hadiah staking (dan tingkat inflasi) untuk menyelaraskannya dengan nilai sehat yang ditargetkan.

Dua skenario yang dijelaskan di atas membentuk loop umpan balik positif dan negatif, digambarkan dengan baik dalam diagram di sebelah kiri (a). Ketika salah satu skenario mencapai ambang batas, sistem menyesuaikan diri. Pengguna dAPI cenderung stabil, seperti yang ditunjukkan pada diagram kiri (b), yang pada akhirnya utama sistem menuju keadaan operasional yang sehat.

Faktanya, token tata kelola gaya DAO seperti ini long populer di berbagai protokol DeFi. Misalnya, dalam implementasi terperinci dari stablecoin terdesentralisasi, DAI MakerDAO berdiri sebagai tolok ukur dengan MKR sebagai token tata kelola perintisnya.

Yang paling elegan adalah mekanisme empat lelangnya. Untuk bacaan lebih lanjut, lihat "Penjelasan Komprehensif: AAVE, Pemimpin DeFi, dan GHO Proposal Stablecoin Terbaru," khususnya bagian "Undercollateralized, Four Auctions." Oleh karena itu, tata kelola DAO adalah mode operasional utama untuk stabilitas ekonomi, namun inovasi API3 juga patut diperhatikan.

6. Keuntungan Unik - Merintis Jaringan OEV (berdasarkan ZK-Rollup)

6.1 Lahirnya OEV

OEV (Oracle Extractable Value) beroperasi mirip dengan MEV (Penambang Extractable Value). Ini mengacu pada kemampuan oracle untuk menangkap nilai yang seharusnya mengalir ke pihak ketiga. Sementara MEV menangkap nilai melalui pemesanan transaksi, OEV mengeksploitasi perbedaan harga antara data on-chain dan off-chain, terutama dalam data pasar penting atau peristiwa on-chain signifikan seperti likuidasi.

Memahami bagaimana OEV muncul membutuhkan kesadaran akan masalah terkini dengan oracle. Karena biaya pengiriman data on-chain, oracle biasanya menggunakan unggahan data berkala yang ditetapkan dalam interval yang relatif short. Untuk mengurangi dampak fluktuasi harga yang besar, oracle sering menetapkan ambang batas yang memicu pembaruan proaktif ketika pergerakan harga melebihi batas ini. Meskipun langkah-langkah ini mengurangi beberapa masalah, langkah-langkah ini pada dasarnya tidak menyelesaikan masalah latensi yang terkait dengan unggahan data.

DeFi pasar sangat fluktuatif, dan harga aset dapat berubah secara signifikan dalam periode short. Mekanisme umpan oracle memperkenalkan ketidakpastian ke pasar DeFi. Memanfaatkan keterlambatan pembaruan data ini, entitas yang mencari keuntungan dapat memanfaatkan OEV. Untuk dApps yang bergantung pada oracle, penundaan atau pembaruan apa pun dalam umpan data berpotensi menciptakan peluang bagi OEV, seperti frontrunning, arbitrase, dan likuidasi.

Mengaitkan kepemilikan nilai yang dapat dieksploitasi yang timbul dari penundaan feed data dapat menjadi tantangan. Unggahan data secara inheren memiliki fluktuasi, sehingga penundaan tidak selalu dapat dikaitkan dengan niat jahat dari pihak oracle. Oleh karena itu, nilai yang dapat dieksploitasi yang dihasilkan dari penundaan tersebut belum tentu dianggap jahat diciptakan oleh oracle.

6.2 OEV Network - Platform Lelang Multi-pihak

Karena keberadaan OEV, pengguna, dan dApps, sebagai pihak yang berinteraksi, nilainya diekstraksi oleh pihak ketiga, yang jelas tidak diinginkan untuk keduanya. API3 mengidentifikasi kebutuhan untuk terlebih dahulu menolak menangkap kekuatan harga dari semua kebocoran tersebut (kekuatan harga data on-chain), maka Jaringan OEV diusulkan. Sebagai Jaringan berdasarkan rollup zk Polygon, ini adalah aliran pesanan independen (niat peserta mana pun untuk mengubah status blockchain adalah pesanan) platform lelang untuk hak memperbarui data dAPI. API3 mengembangkan platform lelang itu sendiri, menghilangkan ketergantungan pada layanan eksternal, memungkinkan pemangku kepentingan untuk berbagi OEV tanpa berbagi keuntungan dengan platform lelang, dan menginternalisasi OEV di semua umpan data blockchain terintegrasi. Pemenang lelang mendapatkan hak untuk memperbarui data dAPI, dengan sebagian besar keuntungan lelang dikembalikan ke dApp dan sebagian kecil ditahan oleh API3 untuk menutupi biaya operasional. Jelas, ketika juru lelang (pihak ketiga) yakin biaya lelang < keuntungan dari memperbarui harga, mereka akan berpartisipasi dalam lelang, sehingga menguntungkan bagi pihak ketiga juga. Meskipun pengguna platform dApp tampaknya tidak berpartisipasi dalam pembagian keuntungan, mereka mendapat manfaat dari sumber data berkualitas yang disediakan oleh dAPI untuk perdagangan dan manajemen risiko yang lebih baik, yang berpotensi mendapat manfaat darinya. Siklus hidup lelang diilustrasikan dalam diagram di bawah ini. Ketika seorang pencari menemukan OEV, mereka memulai lelang penawaran. Penawar yang menang mendapatkan hak untuk memperbarui data dAPI dari node oracle, dan setelah membayar biaya penawaran, mereka dapat menggunakan hak ini untuk memperbarui data dAPI node oracle. Biaya lelang yang dibayarkan adalah OEV yang ditangkap mengalir ke dApp.

Tren lelang secara alami melibatkan pihak ketiga (pencari) meningkatkan harga penawaran untuk mengejar potensi keuntungan. Harga lelang yang lebih tinggi berarti perbedaan yang lebih kecil antara OEV aktual dan OEV yang ditangkap. Adapun ukuran peluang ini, kita harus menunggu dan melihat setelah jaringan uji stabil untuk beberapa waktu sebelum membuat penilaian. Hasil lelang menciptakan situasi win-win untuk dApps, node oracle API3, pihak ketiga, dan pengguna dApp. dApps yang mengintegrasikan sumber data API3 meminimalkan wol yang ditarik oleh pihak ketiga sambil menangkap sebagian besar nilai OEV. Pada akhirnya, persaingan pasar di antara pihak ketiga memastikan bahwa keuntungan secara bertahap dikompresi, menguntungkan dApps pada akhirnya. Untuk API3, sebagian kecil dari nilai OEV mendukung jalur operasional OEV. Pihak ketiga juga mendapat bagian. Untuk pengguna dApp, memberi insentif kepada peserta pihak ketiga yang sangat khusus untuk menentukan waktu optimal untuk memperbarui titik data on-chain meningkatkan granularitas, menguntungkan pengguna dApp dalam menjalankan long. Dengan demikian, skema lelang OEV API3 secara maksimal menangani distribusi kepentingan dalam permainan multi-pihak, mengarahkan "keuntungan yang salah tempat" dari pihak ketiga kembali ke pemangku kepentingan terkait. Solusi semacam itu dirancang dengan elegan. Untuk bacaan lebih lanjut, jelajahi "Laporan Penelitian UniswapX (Bagian I): Meringkas Jalur Pengembangan V1-3, Memahami Prinsip Inovasi dan Tantangan di Generasi Berikutnya DEX."

7. Kesimpulan

API3 telah membangun ekosistem mandiri berdasarkan ekonomi tokennya, memanfaatkan mekanisme umpan balik positif dan negatif untuk menstabilkan operasi. Bersamaan dengan itu, Jaringan OEV yang diperkenalkan oleh API3 dengan cerdik menyelesaikan masalah aliran OEV melalui mekanisme lelang untuk pembaruan harga dAPI, dengan cekatan mengalihkan konflik yang timbul dari OEV antara oracle dan dApps ke pihak ketiga.

Ketika aplikasi terdesentralisasi berkembang biak dan matang, permintaan akan layanan oracle yang andal dan aman diperkirakan akan tumbuh, menandakan munculnya oracle generasi berikutnya. Namun, API3 menghadapi beberapa tantangan. Model ekonomi, bahkan yang dirancang dengan baik pada awalnya, mungkin berjuang dengan stabilitas jangka long, sering menjadi mangsa tata kelola yang berlebihan atau pengabaian. Selain itu, lelang API, yang bergantung pada reputasi dan pendapatan, secara inheren optimis daripada model pesimis (seperti ZK). Meskipun LayerZero menggunakan struktur reputasi yang sama dan operasinya yang berkelanjutan tanpa masalah pasar, bahkan dalam kombinasi berisiko tinggi seperti oracle plus cross-chain bridges, risiko tetap ada.

Taruhan reputasi lanjutan menyiratkan bahwa pengembalian pasar peserta harus cukup tinggi, dan terkait erat dengan perkembangan pasar API3. Pada akhirnya, kesulitan pasar oracle terletak pada kenyataan bahwa DApps memprioritaskan tidak hanya kemampuan penyediaan data tetapi juga posisi oracle itu sendiri sebagai pihak ketiga. API3 telah mengganggu paradigma ini, namun kekhawatiran tetap ada ketika DApps sendiri berpartisipasi dalam lelang, menimbulkan pertanyaan tentang potensi kolusi meskipun mempertaruhkan reputasi mereka sendiri. Pemain mapan seperti Chainlink juga mampu merilis lebih banyak OEV untuk mempertahankan dominasi pasar.

Penafian:

1. Artikel ini dicetak ulang dari [十四君],. Semua hak cipta adalah milik penulis asli [十四君]. Jika ada keberatan dengan cetak ulang ini, silakan hubungi tim Gate Learn, dan mereka akan segera menanganinya.
2. Penafian Kewajiban: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata milik penulis dan bukan merupakan saran investasi.
3. Penerjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.