Definisi dan model pasar terdesentralisasi
Pasar terdesentralisasi adalah lingkungan perdagangan di mana fungsi pasar tidak dikendalikan oleh satu operator pusat. Sebagai gantinya, aturan dan eksekusi ditangani melalui partisipasi terdistribusi, seperti buku besar bersama, protokol, atau banyak pihak lawan yang beroperasi di bawah prosedur yang disepakati.
Cara praktis untuk memodelkannya adalah memisahkan mekanisme yang stabil dari kondisi yang bervariasi:
- Mekanisme yang stabil: apa yang sistem lakukan berdasarkan desain (misalnya, bagaimana order dipasangkan atau bagaimana transfer dikonfirmasi).
- Kondisi yang bervariasi: apa yang dapat berubah saat runtime (misalnya, likuiditas, kondisi jaringan, kecepatan eksekusi, dan biaya).
Dengan kata lain, elemen terdesentralisasi memberi tahu Anda di mana kontrol dan penegakan berada, sementara hasil pasar bergantung pada bagaimana sistem berperforma dalam kondisi nyata.
Ketergantungan: apa yang harus benar agar sistem bisa bekerja
Pertimbangan lanjutan dimulai dari ketergantungan—asumsi yang sering tersembunyi ketika sebuah konsep dijelaskan pada tingkat yang tinggi.
1) Konektivitas dan aturan validasi
Jika eksekusi bergantung pada protokol terdistribusi, maka partisipasi bergantung pada konektivitas jaringan dan pendekatan validasi protokol. Bahkan ketika “pasar” terdesentralisasi, transaksi tetap memerlukan:
- waktu untuk menyebar,
- waktu untuk divalidasi,
- dan interpretasi aturan yang benar oleh semua komponen yang terlibat.
Salah satu kasus tepi kunci adalah eksekusi parsial: komponen yang berbeda dapat mengamati atau mengonfirmasi status pada waktu yang berbeda, sehingga terjadi ketidaksesuaian antara apa yang dipikirkan pengguna telah terjadi dan apa yang dianggap final oleh protokol.
2) Likuiditas dan asumsi routing
Eksekusi terdesentralisasi sering mengasumsikan bahwa pihak lawan atau sumber likuiditas tersedia di sepanjang rute yang dapat digunakan sistem. Jika likuiditas tipis atau terfragmentasi, maka mekanisme stabil protokol mungkin masih menghasilkan hasil yang tidak stabil dalam praktik.
Sebagai contoh, sebuah sistem mungkin terdesentralisasi tetapi tetap menghadapi diskontinuitas likuiditas—perubahan mendadak pada kuotasi yang tersedia saat harga bergerak atau saat transaksi mengonsumsi kedalaman.
3) Kustodi, settlement, dan batasan operasional
Bahkan ketika perdagangan terdesentralisasi, settlement dapat melibatkan jalur kustodi yang berbeda. Batasan operasional mencakup:
- apakah aset disimpan langsung di bawah kendali pengguna,
- apakah perantara menyediakan gateway,
- dan bagaimana konfirmasi dipetakan ke status “terisi” yang terlihat oleh pengguna.
Mode kegagalan yang perlu diperhatikan adalah ambiguitas konfirmasi—antarmuka pengguna dapat melaporkan perdagangan sebagai selesai sebelum finalitas, atau menunda pembaruan karena komponen pengindeksan atau pelaporan.
Kasus tepi dan mode kegagalan yang penting dalam praktik
Pasar terdesentralisasi dapat berperilaku berbeda dari pasar yang hanya dijelaskan dalam istilah yang disederhanakan. Pada tingkat lanjutan, Anda perlu mengantisipasi di mana model tersebut gagal.
1) Latensi, pengurutan, dan perubahan status
Sistem terdistribusi sensitif terhadap waktu. Kasus tepi lanjutan mencakup:
- efek pengurutan transaksi: dua tindakan dapat diamati dalam urutan yang berbeda dari yang diharapkan,
- kondisi yang bergantung waktu: status dapat berubah di antara pembuatan kuotasi dan eksekusi.
Saat Anda menjelaskan pasar terdesentralisasi, pisahkan “apa yang dikatakan aturan” dari “apa yang terjadi dalam jendela waktu tertentu.” Tanpa pemisahan itu, Anda tidak dapat menalar mengapa sebuah hasil menyimpang.
2) Logika eksekusi smart contract atau otomatis
Jika eksekusi otomatis adalah bagian dari desain, maka kebenaran bergantung pada logikanya sendiri dan pada input yang digunakan. Risikonya meliputi:
- perilaku tak terduga dari input pada kasus tepi,
- ketergantungan pada umpan data eksternal (jika digunakan),
- dan masalah operasional seperti eksekusi yang gagal karena batasan.
Keterbatasan yang material adalah bahwa desentralisasi kontrol tidak otomatis menghilangkan risiko perangkat lunak; ia dapat memindahkannya ke komponen yang berbeda.
3) Struktur biaya dan hasil bersih
Biaya dalam lingkungan terdesentralisasi tidak hanya soal satu biaya tunggal. Hasil bersih dapat dipengaruhi oleh:
- biaya jaringan untuk propagasi dan validasi,
- biaya terkait eksekusi (misalnya, batas sumber daya dalam eksekusi otomatis),
- dan slippage yang disebabkan oleh keterbatasan likuiditas.
Salah paham yang umum adalah memperlakukan harga yang dikutip sebagai hasil bersih. Untuk memverifikasi maknanya secara independen, Anda perlu seperangkat asumsi yang eksplisit: biaya, waktu eksekusi, dan jumlah yang diperdagangkan relatif terhadap likuiditas yang tersedia.
4) Batasan yurisdiksi dan kebijakan
Bahkan jika mekanisme pasar terdesentralisasi, akses tetap dapat dibatasi oleh yurisdiksi, kebijakan penyedia, atau ketersediaan layanan. Ini dapat muncul sebagai:
- pembatasan siapa yang dapat berinteraksi melalui front-end tertentu,
- perlindungan pengguna yang berbeda tergantung pada bagaimana akses disediakan,
- dan perubahan ketersediaan on/off-ramp.
Hal ini tidak bertentangan dengan desentralisasi; ini berarti akses operasional sebagian berada di luar protokol inti.
Bukti dan contoh: cara berpikir tentang verifikasi
Karena tidak ada hubungan yang dijamin tunggal antara desain terdesentralisasi dan hasil, verifikasi harus berfokus pada komponen yang dapat diuji.
A) Daftar periksa pernyataan yang dapat diverifikasi
Saat Anda menilai klaim tentang pasar terdesentralisasi, verifikasi bahwa klaim tersebut adalah tentang sesuatu yang dapat diamati atau diaudit, seperti:
- aturan protokol yang dinyatakan,
- makna konfirmasi dan finalitas dalam istilah operasional,
- perilaku biaya dan kegagalan yang terdokumentasi,
- dan bagaimana antarmuka pengguna menerjemahkan status sistem menjadi “terisi” atau “terkonfirmasi.”
A) Contoh perhitungan sederhana berbasis asumsi
Untuk mengilustrasikan cara menalar tanpa menyiratkan hasil yang dapat diprediksi, pertimbangkan skenario generik:
- Anda mengasumsikan ukuran perdagangan kecil relatif terhadap likuiditas yang tersedia, sehingga slippage terbatas.
- Anda mengasumsikan kondisi jaringan berada dalam kisaran normal.
- Anda menyertakan estimasi biaya yang eksplisit dan estimasi slippage eksekusi yang eksplisit.
Lalu “biaya yang diharapkan bersih” Anda adalah:
- harga masuk + biaya-biaya + dampak slippage.
Poin lanjutan bukanlah aritmatikanya; melainkan bahwa setiap istilah harus dibenarkan secara independen oleh asumsi yang dapat dicek. Jika asumsi likuiditas gagal, istilah slippage dapat menjadi dominan.
Keterbatasan dan risiko yang perlu dimasukkan dalam penjelasan
Ketika pembaca dapat menjelaskan konsep secara mandiri, mereka juga harus mampu mendeskripsikan apa yang bisa salah.
1) Hasil bervariasi dengan kondisi pasar
Bahkan dengan mekanisme yang stabil, kondisi yang bervariasi dapat mendominasi hasil. Hubungan historis tidak menetapkan hasil masa depan.
2) Mode kegagalan ada bahkan dalam desain terdesentralisasi
Keterbatasan yang material mencakup efek latensi, ambiguitas konfirmasi, diskontinuitas likuiditas, dan kasus tepi eksekusi otomatis.
3) Dokumentasi dan antarmuka mungkin tidak sesuai dengan ekspektasi pengguna
Status perdagangan di sebuah antarmuka dapat bergantung pada kecepatan pengindeksan, interpretasi konfirmasi, dan bagaimana “final” didefinisikan. Tanpa membaca definisi-definisi tersebut, Anda berisiko mencampuradukkan “sent,” “submitted,” “validated,” dan “finalised.”
Verifikasi dan pertanyaan berikutnya yang perlu diajukan
Untuk memverifikasi informasi tentang pasar terdesentralisasi, fokuskan pertanyaan Anda pada mekanisme, batasan, dan lapisan penerjemahan:
- Apa aturan sistem yang dinyatakan untuk validasi dan finalitas?
- Bagaimana komponen eksekusi melaporkan status kepada pengguna?
- Biaya dan batas apa yang berlaku untuk eksekusi otomatis?
- Asumsi likuiditas apa yang tersirat dalam desain?
- Kendala akses operasional apa yang ada di yurisdiksi Anda dan melalui antarmuka yang Anda pilih?