Pertimbangan lanjutan untuk pasar terdesentralisasi

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 berdasarkan prosedur yang disepakati.

Cara praktis untuk memodelkannya adalah dengan memisahkan mekanisme stabil dari kondisi variabel:

• Mekanisme stabil: apa yang dilakukan sistem secara desain (misalnya, bagaimana pesanan dicocokkan atau bagaimana transfer dikonfirmasi).
• Kondisi variabel: 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 berkinerja dalam kondisi nyata.

Ketergantungan: apa yang harus benar agar sistem berfungsi

Pertimbangan lanjutan dimulai dengan ketergantungan—asumsi yang sering tersembunyi ketika suatu konsep dijelaskan pada tingkat 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.

Kasus tepi utama adalah eksekusi parsial: komponen yang berbeda dapat mengamati atau mengonfirmasi status pada waktu yang berbeda, menyebabkan ketidakcocokan antara apa yang menurut pengguna terjadi dan apa yang dianggap final oleh protokol.

2) Asumsi likuiditas dan perutean

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 masih dapat menghasilkan hasil yang tidak stabil dalam praktik.

Misalnya, suatu sistem mungkin terdesentralisasi tetapi tetap menghadapi diskontinuitas likuiditas—perubahan mendadak dalam kuotasi yang tersedia saat harga bergerak atau saat perdagangan mengonsumsi kedalaman pasar.

3) Kustodi, penyelesaian, dan batas operasional

Bahkan ketika perdagangan terdesentralisasi, penyelesaian mungkin melibatkan jalur kustodi yang berbeda. Batas operasional mencakup:

• apakah aset dipegang langsung di bawah kendali pengguna,
• apakah perantara menyediakan gerbang akses,
• dan bagaimana konfirmasi dipetakan ke status “terisi” yang terlihat pengguna.

Mode kegagalan yang perlu diwaspadai adalah ambiguitas konfirmasi—antarmuka pengguna mungkin melaporkan perdagangan sebagai selesai sebelum finalitas, atau mungkin 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 rusak.

1) Latensi, urutan, dan perubahan status

Sistem terdistribusi sensitif terhadap waktu. Kasus tepi lanjutan meliputi:

• efek urutan transaksi: dua tindakan dapat diamati dalam urutan yang berbeda dari yang diharapkan,
• kondisi yang bergantung pada waktu: status dapat berubah 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 bernalar tentang mengapa suatu hasil menyimpang.

2) Kontrak pintar atau logika eksekusi otomatis

Jika eksekusi otomatis adalah bagian dari desain, maka kebenaran bergantung pada logika itu sendiri dan pada input yang digunakan. Risiko meliputi:

• perilaku tak terduga dari input kasus tepi,
• ketergantungan pada umpan data eksternal (jika digunakan),
• dan masalah operasional seperti eksekusi yang gagal karena kendala.

Keterbatasan material adalah bahwa desentralisasi kontrol tidak secara otomatis menghilangkan risiko perangkat lunak; ia dapat mengalihkannya ke komponen yang berbeda.

3) Struktur biaya dan hasil bersih

Biaya di lingkungan terdesentralisasi tidak hanya tentang satu biaya tunggal. Hasil bersih dapat dipengaruhi oleh:

• biaya jaringan untuk penyebaran dan validasi,
• biaya terkait eksekusi (misalnya, batas sumber daya dalam eksekusi otomatis),
• dan selip yang disebabkan oleh kendala likuiditas.

Kesalahpahaman umum adalah memperlakukan harga kuotasi sebagai hasil bersih. Untuk memverifikasi makna secara independen, Anda memerlukan serangkaian asumsi eksplisit: biaya, waktu eksekusi, dan jumlah yang diperdagangkan relatif terhadap likuiditas yang tersedia.

4) Kendala yurisdiksi dan kebijakan

Bahkan jika mekanisme pasar terdesentralisasi, akses mungkin tetap dibatasi oleh yurisdiksi, kebijakan penyedia, atau ketersediaan layanan. Ini dapat muncul sebagai:

• pembatasan siapa yang dapat berinteraksi melalui antarmuka tertentu,
• perlindungan pengguna yang berbeda tergantung pada bagaimana akses disediakan,
• dan ketersediaan jalur masuk/keluar yang berubah.

Ini tidak bertentangan dengan desentralisasi; ini berarti akses operasional sebagian bersifat eksternal terhadap protokol inti.

Bukti dan contoh: bagaimana berpikir tentang verifikasi

Karena tidak ada hubungan tunggal yang dijamin antara desain terdesentralisasi dan hasil, verifikasi harus fokus pada komponen yang dapat diuji.

Daftar periksa pernyataan yang dapat diverifikasi

Saat Anda mengevaluasi klaim tentang pasar terdesentralisasi, verifikasi bahwa klaim tersebut 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.”

Contoh perhitungan sederhana yang digerakkan asumsi

Untuk mengilustrasikan cara bernalar tanpa menyiratkan hasil yang dapat diprediksi, pertimbangkan skenario umum:

• Anda mengasumsikan ukuran perdagangan kecil relatif terhadap likuiditas yang tersedia, sehingga selip terbatas.
• Anda mengasumsikan kondisi jaringan berada dalam kisaran normal.
• Anda menyertakan perkiraan biaya eksplisit dan perkiraan selip eksekusi eksplisit.

Maka “perkiraan biaya bersih” Anda adalah:

• harga masuk + biaya + dampak selip.

Poin lanjutan bukanlah aritmetika; ini adalah bahwa setiap istilah harus dibenarkan secara independen oleh asumsi yang dapat diperiksa. Jika asumsi likuiditas gagal, istilah selip dapat mendominasi.

Keterbatasan dan risiko yang perlu disertakan dalam penjelasan Anda

Ketika pembaca dapat menjelaskan konsep secara independen, mereka juga harus dapat menggambarkan apa yang bisa salah.

1) Hasil bervariasi dengan kondisi pasar

Bahkan dengan mekanisme stabil, kondisi variabel dapat mendominasi hasil. Hubungan historis tidak menetapkan hasil masa depan.

2) Mode kegagalan ada bahkan dalam desain terdesentralisasi

Keterbatasan material meliputi efek latensi, ambiguitas konfirmasi, diskontinuitas likuiditas, dan kasus tepi eksekusi otomatis.

3) Dokumentasi dan antarmuka mungkin tidak sesuai dengan harapan pengguna

Status perdagangan di antarmuka dapat bergantung pada kecepatan pengindeksan, interpretasi konfirmasi, dan bagaimana “final” didefinisikan. Tanpa membaca definisi tersebut, Anda berisiko membingungkan “dikirim,” “diajukan,” “divalidasi,” dan “difinalisasi.”

Verifikasi dan pertanyaan berikutnya yang perlu diajukan

Untuk memverifikasi informasi tentang pasar terdesentralisasi, fokuskan pertanyaan Anda pada mekanisme, batas, dan lapisan penerjemahan:

• Apa aturan yang dinyatakan sistem 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 pilihan Anda?