彭鱼宴啊

Binance juga diretas??????

Melihat orang lain mendapatkan hadiah mingguan, jadi iri.

#币安神算子

Susah banget, teman-teman. Gimana cara main orang-orang yang ada di posisi atas papan peringkat?

#币安神算子

Bagaimana cara mendapatkan ratusan ribu poin?

#币安神算子

LPL benar-benar sudah tamat, begitu bangun tidur, semua taruhan yang kupasang kalah
#币安神算子

Kenapa sekarang tidak bisa memprediksi harga BTC lagi? Padahal itu yang seru!

#币安神算子

Kamu bisa mencoba event Binance Oracle ini. Check-in untuk mendapatkan poin.

Gunakan poin untuk membuat prediksi, lalu hadiah akan dibagikan berdasarkan peringkat.

Gratis!
#币安神算子

Kalau main Alpha selama sebulan sekarang, bisa makan sekali di Haidilao nggak??

Koreksinya sudah selesai belum, teman-teman? Atau masih akan terus turun?

#dusk $DUSK @Dusk Dalam mekanisme “punishment” Dusk, ada satu pengaturan yang ingin saya bahas secara terpisah: perilaku seperti node yang putus koneksi, atau tidak menghasilkan blok saat seharusnya—ini tidak bisa dibilang tindakan berniat jahat, namun tetap menjadi penghambat. Cara penanganannya adalah memberi peringatan terlebih dahulu, lalu memindahkan sebagian aset yang dijaminkan ke status sementara agar tidak dapat menghasilkan imbalan. Pokoknya tidak dibakar sedikit pun; hanya saja untuk sementara tidak bisa memperoleh reward, dan dikeluarkan dari konsensus dalam jangka waktu tertentu. Hal yang benar-benar “membakar uang” hanya untuk tindakan jahat yang sudah terbukti, seperti tanda tangan ganda palsu atau pemalsuan blok.
Saya paham maksud perancangannya: ambang jaminan terendah hanya seribu koin. Jika setiap kali putus koneksi langsung dipotong pokok, banyak node yang sebenarnya ingin ikut berpartisipasi dengan serius tetapi kondisi teknisnya biasa saja akan menjadi takut—dan pada akhirnya jaringan justru akan lebih mudah terkonsentrasi pada segelintir lembaga profesional. Pertukaran antara “hukuman yang tidak menyakitkan” untuk mendapatkan partisipasi yang lebih luas—keseimbangan seperti itu masuk akal.
Namun penilaian saya sendiri adalah bahwa ada premis tersembunyi dalam logika ini yang tidak disebutkan secara eksplisit: sistem ini mengasumsikan bahwa “jumlah orang di jaringan yang benar-benar bersedia menjalankan node cukup banyak”. Barulah dengan begitu hukuman lunak tidak akan merusak efisiensi operasional nyata jaringan. Jika suatu hari banyak node mulai mengandalkan secara terkonsentrasi penyedia layanan cloud yang sama, atau pusat data yang sama, lalu ketika infrastruktur dasar itu bermasalah, sejumlah besar node akan sekaligus memicu hukuman lunak dan sekaligus dikeluarkan sementara dari konsensus. Pada kondisi seperti itu, “pokok tidak dibakar” justru berubah menjadi faktor yang seolah memberi kelonggaran agar orang tidak terlalu peduli pada kestabilan node mereka—bagaimanapun putus koneksi tidak terlalu sakit, siapa yang benar-benar akan berani mengeluarkan usaha besar untuk menjamin tingkat online yang benar-benar maksimal? Dalam jaringan dengan model hukuman keras, rasa biaya seperti ini akan memaksa operator untuk lebih serius memperhatikan infrastrukturnya. Kelonggaran yang diperoleh dari hukuman lunak—dalam jangka panjang, apakah diam-diam juga menurunkan tingkat perhatian seluruh jaringan terhadap “operasional dan pemeliharaan yang benar-benar serius”? Menurut saya ini masalah yang layak terus dipantau, bukan sesuatu yang bisa diputuskan tuntas hanya dengan melihat sekilas tabel parameter.

#dusk $DUSK @Dusk Saya penasaran dengan sebuah skenario yang spesifik: misalnya jika giliran seseorang untuk membuat blok, lalu node orang tersebut ternyata macet atau sedang offline, apakah jaringan akan menunggu begitu saja, atau ada mekanisme otomatis untuk berpindah? Kali ini saya khusus menelusuri bagian di dalam alur konsensus Dusk: bagaimana desainnya.
Pembuatan blok di Dusk melewati tiga langkah. Pertama, node yang terpilih mengusulkan sebuah blok. Lalu, sekelompok node memberikan suara bertanda tangan untuk mengonfirmasi blok tersebut valid. Setelah itu, kelompok node lain melakukan putaran pemungutan suara kedua, mengumpulkan hasil dari putaran sebelumnya, dan akhirnya secara resmi mencapai kesepakatan. Ketiga langkah ini dianggap satu putaran. Jika node yang terpilih untuk mengusulkan blok tidak bisa mengirimkan blok tersebut dalam waktu yang ditentukan, atau jika pemungutan suara di tengah tidak bisa mengumpulkan jumlah yang cukup, maka putaran itu akan gagal karena timeout dan masuk ke iterasi berikutnya—mengganti sekelompok orang lagi untuk mencoba, dan terus berulang sampai benar-benar tercapai kesepakatan.
Awalnya saya mengira mekanisme "timeout lalu mengulang" ini bersifat kaku—setiap kali timeout, jaringan hanya menunggu dengan durasi tetap tertentu, lalu mengulang. Namun setelah melihat log pengembangan mereka, ternyata tidak seperti itu. Ada satu perubahan yang secara khusus tertulis "mengimplementasikan adaptive timeout". Selain itu ada juga catatan "mengizinkan kembali ke blok pada putaran yang lebih rendah". Ini menunjukkan bahwa mekanisme tersebut tidak menggunakan satu waktu tunggu tetap dari awal sampai akhir, melainkan akan menyesuaikan jendela tunggu berdasarkan kondisi nyata jaringan. Ia juga menangani kondisi seperti "jika sebelumnya sudah ada blok dari putaran yang lebih awal yang diterima semua orang, maka putaran berikutnya tidak perlu dibongkar-bongkar lagi". Detail ini saya perhatikan hanya ketika melihat catatan pembaruan siklus pengembangan mereka pada salah satu waktunya. Hanya dari nama protokol dan penjelasan langkah-langkahnya saja, sulit terlihat bahwa di balik itu ada desain penyesuaian dinamis.
Bagi saya, mekanisme ini menyelesaikan masalah yang cukup realistis: ketika jumlah node di jaringan bertambah, selalu ada yang mengalami jitter jaringan atau terputus. Jika tidak ada mekanisme seleksi ulang otomatis dan penyesuaian timeout yang dinamis, jaringan bisa saja langsung macet hanya karena satu node malang tidak merespons. Namun saya belum menemukan data historis yang spesifik—misalnya sampai saat ini, berapa kali di mainnet benar-benar dipicu oleh mekanisme timeout dan pemilihan ulang seperti ini. Setelah dipicu, rata-rata butuh berapa lama agar jaringan kembali normal untuk membuat blok; bagian ini sementara belum saya temukan sumber data operasional yang bisa dijadikan verifikasi.

#dusk $DUSK @Dusk Senja memiliki dua sistem akun: satu adalah akun biasa yang bisa dilihat publik, dan satu lagi adalah akun privasi yang dienkripsi dan disembunyikan. Sebelumnya sering dengar orang mengatakan bahwa kedua sisi ini bisa saling dikonversi. Kali ini saya sengaja mencobanya untuk memastikan bagaimana cara kerja fitur konversinya, detail lain jangan dulu dibahas.
Alur spesifiknya begini: Di level bawah Senja ada sebuah kontrak khusus yang menangani logika transfer. Untuk token yang sama, dari kondisi tersembunyi menjadi kondisi publik—atau sebaliknya—semuanya dilakukan melalui operasi konversi dalam kontrak tersebut. Bukan seperti cara yang “kasar” yaitu “keluarkan uang yang tersembunyi dulu, lalu simpan lagi ke akun publik”. Yang terjadi adalah aset yang sama mengalami perubahan status langsung dalam satu kali operasi, tanpa melalui langkah antara yang bisa diamati pihak eksternal secara terpisah.
Saat saya mengujinya di testnet, pada percobaan pertama saya salah arah saat mengklik. Saya sebenarnya ingin mengubah dari akun tersembunyi menjadi akun publik, tapi malah mengisinya terbalik—dari akun publik ke arah akun tersembunyi. Uangnya memang berhasil ditransfer, tetapi hasilnya sama sekali tidak sesuai dengan yang saya inginkan. Saya baru sadar setelah sedikit beres-beres: ternyata bukan fitur konversinya yang bermasalah, melainkan saya sendiri yang salah membalik dua arah pada antarmuka saat beroperasi.
Setelah mencobanya, kesan saya: fitur konversi ini dibuat cukup mulus—langsung selesai dalam satu langkah. Tidak seperti beberapa skema yang harus melewati alamat perantara dulu untuk melakukan perpindahan status yang mirip. Tapi saya juga menemukan satu hal yang mudah terlewat: konversi ini hanya mengurusi pergantian status uang itu sendiri. Jika asetnya adalah aset jenis sekuritas yang terikat aturan kepatuhan (misalnya yang harus melalui proses verifikasi daftar, atau yang memiliki aturan transfer khusus), maka alurnya sepenuhnya menggunakan mekanisme terpisah. Tidak bisa langsung diterapkan fitur konversi ini untuk menangani keduanya. Kedua hal ini dirancang secara terpisah. Awalnya saya sempat mengira semua aset bisa ditransfer dengan cara yang sama, tapi setelah dicoba barulah saya memastikan saya salah paham.

#dusk $DUSK @Dusk Saya terus mendengar Dusk membahas istilah "privasi yang dapat diprogram" ini, tetapi setiap kali istilah itu disebut, yang dibawa-bawa biasanya beberapa ciri sekaligus. Kali ini saya ingin hanya mengambil satu poin, yaitu "selective disclosure" (pengungkapan selektif), untuk dipahami secara spesifik: itu sebenarnya merujuk pada apa, dan yang lain sementara saya abaikan.
Dari pemahaman saya, selective disclosure menyelesaikan skenario seperti ini: dalam kondisi normal, pihak luar tidak bisa melihat jumlah maupun pihak-pihak yang terlibat dalam sebuah transaksi—itu bagian privasinya. Tetapi jika otoritas pengawas atau auditor perlu melakukan verifikasi, pengguna atau institusi harus punya cara untuk membuat satu pihak yang berwenang dapat melihat informasi yang memang perlu dilihat, tanpa harus mempublikasikannya ke semua orang. Ini berbeda dari pemikiran lama "atau semuanya dibuka, atau semuanya disembunyikan"; pendekatannya justru membuka sebuah jalur yang dapat dikendalikan di antara dua ekstrem tersebut.
Awalnya saya mengira "selektif" ini diwujudkan lewat operasi manual di luar rantai (off-chain), misalnya ketika terjadi masalah barulah ditempuh proses di luar rantai untuk mengekspor catatan transaksi agar bisa ditunjukkan kepada regulator. Setelah mencari referensi barulah saya tahu itu bukan begitu. Versi resmi mengatakan kemampuan tersebut langsung dibuat ke dalam protokol menggunakan alat-alat kriptografi: pengguna atau institusi sendiri yang memutuskan apakah perlu membuat sebuah kredensial yang bisa dilihat oleh objek tertentu, tanpa harus meminta bantuan orang untuk mengakses database internal setelah kejadian.
Namun, saya juga harus jujur: dalam materi resmi, bagian tentang "siapa yang berwenang untuk mengajukan permintaan pengungkapan tersebut" maupun "kredensial itu bisa menampilkan informasi sedetail apa" dijelaskan secara agak umum. Tidak ada panduan operasional yang spesifik langkah demi langkah yang bisa langsung diikuti. Ini berarti, saat ini, "selective disclosure" lebih terlihat sebagai kemampuan yang sudah ada di level protokol. Untuk penerapannya dalam skenario nyata—bagaimana caranya digunakan, siapa yang memicu, dan seberapa lama alur persetujuannya—mungkin perlu melihat detail produk yang benar-benar dijalankan bersama mitra seperti NPEX. Saya belum berhasil menemukan contoh kasus yang sudah berjalan, jadi untuk saat ini saya hanya bisa memastikan kemampuan itu memang ada, dan belum bisa menilai apakah cara penggunaannya nanti terasa mulus atau tidak.

#dusk $DUSK @Dusk Terus terang, aku penasaran dengan dana pengembangan di ekosistem Dusk—bagaimana sebenarnya cara kerjanya? Apakah tim yang menentukan semuanya sendiri, atau ada alur yang membuat pihak luar juga bisa mengajukan dana ini. Setelah aku menelusuri penjelasan terkait tata kelola, ternyata alur ini lebih resmi daripada yang semula kupikirkan.
Sumber dana yayasan ini cukup jelas: setiap kali mainnet menghasilkan satu blok, dari hadiah tersebut akan dipotong sebagian secara tetap, lalu akumulasi dalam jangka panjang ke dalam kumpulan dana (fund pool) ini. Dana itu khusus untuk mendukung pengembangan ekosistem dan pekerjaan riset ke depannya, bukan bergantung pada penggalangan dana dadakan atau uang pribadi tim.
Bagian yang benar-benar membagi wewenang ada pada proses persetujuan. Untuk perubahan yang berkaitan langsung dengan protokol—misalnya, sebuah usulan perbaikan teknis tertentu—jalurnya adalah pengajuan, penilaian, lalu keputusan apakah usulan itu akan diadopsi. Dari sisi format, persyaratannya cukup ketat, mirip dokumen usulan teknis yang formal, bukan sekadar memposting sesuatu sembarangan lalu langsung dianggap berlaku. Sedangkan untuk pengeluaran yang tidak berhubungan langsung dengan kode protokol—misalnya, pengembangan alat dompet (wallet tool) atau pendanaan riset untuk topik tertentu—jalurnya berbeda: dinilai dan diputuskan oleh tim tata kelola khusus yang bertanggung jawab atas alokasi dana bagian tersebut. Secara teori, anggota komunitas dari luar juga dapat ikut berpartisipasi dalam proses persetujuan melalui mekanisme pemilihan anggota tim tersebut.
Awalnya aku mengira ini hanyalah kotak hitam “persetujuan internal tim”. Tapi setelah membaca penjelasan, setidaknya pada level dokumen, kedua jalur ini cukup jelas pemisahannya. Dan keduanya menyediakan akses bagi pihak luar untuk mengajukan permohonan bahkan ikut dalam penilaian, bukan sepenuhnya tertutup. Namun, penjelasan dokumen dan pelaksanaan nyata adalah dua hal berbeda. Untuk beberapa tahun terakhir, proyek apa saja yang pernah disetujui, berapa kira-kira tingkat persetujuannya, dan seberapa besar porsi permohonan yang diajukan oleh pihak luar—saat ini aku belum menemukan data pelaksanaan yang spesifik dari yang bisa kupakai. Jadi, yang bisa kukatakan: dari sisi desain prosesnya, sistemnya terbuka; tetapi apakah operasinya transparan atau tidak, perlu verifikasi dengan lebih banyak catatan historis. Saat ini aku belum bisa memberikan penilaian yang pasti.

#dusk $DUSK @Dusk Awalnya, bayangan saya tentang “mem- stake DUSK sebagai provisioner” itu sederhana—tinggal pindahkan koinnya, jalankan node, lalu menunggu imbalannya. Sampai saya benar-benar membaca panduan resmi tentang praktik keamanan, mengikuti alurnya dengan tangan sendiri, barulah saya sadar bahwa ambang batasnya ternyata jauh lebih tinggi daripada yang saya kira.
Dalam panduan, cara yang direkomendasikan adalah membuat owner key yang memiliki otorisasi untuk staking langsung di perangkat USB terenkripsi LUKS, bukan menyimpannya di hard disk komputer yang terhubung ke internet setiap hari—langkahnya, pertama gunakan cryptsetup untuk mengenkripsi seluruh isi U disk dengan LUKS, buat sandi yang kuat, lalu kunci kepunyaan pemegang wallet (wallet holder key) langsung dibangkitkan di partisi terenkripsi tersebut. Saat keseharian, USB itu tidak perlu dipasang; baru dipasang ketika benar-benar ingin melepas staking atau menarik reward.
Logikanya begini: meskipun USB tersebut hilang atau dicuri, tanpa sandi apa pun data tersebut tidak bisa dibaca. Untuk operasi node sehari-hari, digunakan kumpulan kunci lain dengan otorisasi yang lebih rendah, yang terpisah dari owner key yang benar-benar bisa digunakan untuk menggerakkan modal staking.
Saya sudah mengikuti alur itu, dan kesan terbesar saya adalah: ini bukan lagi “tinggal klik beberapa tombol”, melainkan pekerjaan yang menuntut Anda memahami pengetahuan operasional seperti enkripsi disk dan manajemen kunci secara offline. Buat saya yang biasanya menulis kode tetapi bukan orang yang benar-benar profesional di bidang operasional, hanya untuk memastikan /dev/sdX harus diisi dengan perangkat yang mana, dan tidak salah format sampai menghapus partisi yang keliru, saja sudah memakan banyak waktu untuk verifikasi berulang.
Ini membuat saya berpikir lagi tentang tingkat partisipasi staking Dusk—ambang staking terendah hanya 1000 DUSK, terdengar sangat rendah untuk masuk, tapi jika benar mengikuti standar keamanan yang direkomendasikan secara resmi, ambang operasionalnya ternyata jauh lebih dari sekadar “punya 1000 koin”. Anda juga perlu kemampuan teknis dan kesabaran untuk menjalankan prosedur keamanan sampai tuntas. Kemungkinan besar, ini akan secara alami menyaring sekelompok pengguna biasa yang hanya ingin “praktis langsung staking”. Sisanya adalah mereka yang bersedia memperlakukan keamanan node dengan serius—ini tentu hal baik untuk keamanan jaringan, tetapi untuk tujuan “partisipasi staking yang cukup desentralisasi”, ambang operasional itu sendiri mungkin juga menjadi penyaring yang mudah terabaikan.

#termmax @TermMax Tadinya saya mengecek TermMax whitepaper dengan tujuan memahami suku bunga pinjaman—bagian visi hampir saja saya lewati begitu saja. Kalimat seperti ini terlalu sering muncul di whitepaper: "Membangun pasar kredit yang lengkap untuk setiap pasangan token, seperti di dunia nyata". Awalnya saya tidak terlalu menganggapnya. Tapi setelah membaca dua baris lagi, saya menemukan hal yang sama, pada daftar yang sama, ternyata "melakukan long dan short pada aset spot" juga dimasukkan. Di situ saya berhenti dan membacanya lagi.
Reaksi pertama saya: keduanya terdengar agak janggal jika digabung. Pinjaman dengan suku bunga tetap adalah sebuah instrumen finansial, sementara long dan short aset spot adalah urusan yang berbeda. Kenapa bisa muncul dalam visi produk yang sama? Setelah saya mengaitkannya dengan mekanisme GT one-click leverage dan pinjaman berulang di bagian sebelumnya, saya baru paham: suku bunga tetap di sini sebenarnya bukan tujuan, melainkan fondasi. Mengubah "pinjam A lalu jual" menjadi "beli dan long B" (atau sebaliknya short), selama biaya pendanaan bisa dikunci di awal, maka strategi ini tidak akan diam-diam dimakan oleh fluktuasi suku bunga. Ternyata, pinjaman dengan suku bunga tetap adalah fondasi untuk lapisan strategi perdagangan di atasnya.
Setelah itu saya mulai meragukan diri sendiri—mungkin saya terlalu berasumsi. Saya kembali mengecek kedalaman (depth) dari Range Order dan Limit Order saat ini, dan sepertinya memang terkonsentrasi di beberapa pasar teratas. Ini membuat saya ragu: agar strategi seperti "pinjam A untuk long B" benar-benar bisa jalan, baik sisi aset jaminan maupun sisi aset utang harus punya kedalaman harga yang memadai. Jika tidak, kurva pasangan aset yang berada di pinggir mungkin bahkan tidak bisa terbentuk dengan stabil. Jadi, sekarang saya melihat kalimat "membangun pasar kredit yang lengkap seperti di dunia nyata" lebih seperti penyediaan antarmuka di level arsitektur—belum sampai tahap benar-benar diwujudkan.
Selanjutnya saya tidak akan lagi terlalu mengawasi berapa banyak pasar pinjaman yang didukung. Saya ingin melihat apakah ada orang yang benar-benar memakai perdagangan berarah murni seperti "pinjam A untuk long B", bukan kembali lagi ke siklus lama yang dilakukan melalui one-click leverage. Celah antara visi dan produk—itulah kunci untuk menilai sampai tahap mana cerita ini benar-benar sudah berjalan.

#dusk $DUSK @Dusk Beberapa waktu lalu, saat menjelaskan kepada seorang teman tentang mekanisme konsensus Dusk, tanpa sadar saya mengutip penjelasan yang dulu pernah saya lihat—bahwa Dusk menggunakan Proof of Blind Bid, identitas pembuat blok bersifat anonim, dan melalui bukti pengetahuan nol menyembunyikan jumlah aset yang dipertaruhkan untuk memperebutkan hak pembuatan blok. Setelah selesai, saya langsung kepikiran: apakah penjelasan itu benar-benar mekanisme yang masih digunakan Dusk sampai sekarang, atau saya hanya mengingat materi yang sudah sangat lama? Saya lalu mengecek kembali dan ternyata saya memang salah.
Pada versi awal whitepaper Dusk, Proof of Blind Bid memang merupakan rancangan yang cukup brilian: calon pembuat blok (Block Generator) mengirimkan sebuah "Bid Transaction", menyimpan jumlah pertaruhan ke dalam pohon Poseidon, lalu menghasilkan bukti pengetahuan nol yang sesuai. Selama proses pemilihan, pihak luar tidak bisa melihat siapa yang ikut serta atau bertaruh berapa. Tujuan desainnya sangat realistis—jika identitas pembuat blok dan jumlah pertaruhan dipublikasikan, maka penyerang pada dasarnya akan mendapat "daftar target prioritas" untuk menyerang langsung pihak-pihak yang sudah diketahui, terutama pembuat blok dengan nilai taruhan besar. Pemilihan secara anonim adalah skema kriptografi yang dipakai Dusk pada tahap awal untuk melawan serangan terarah seperti itu.
Namun saat ini, dokumentasi resmi Dusk tentang konsensus mainnet menyebut Succinct Attestation, yaitu desain proof of stake berbasis komite. Prosesnya bergantung pada provisioner yang menghasilkan calon pembuat blok dan komite pemungutan suara melalui pemilihan deterministik, dan di seluruh alur tersebut tidak lagi disebut konsep "pemilihan anonim". Dengan kata lain, saat Dusk beralih dari desain awal menuju penerapan di mainnet, mereka diam-diam mengubah fitur "identitas pembuat blok anonim", menjadi mekanisme komite yang lebih menekankan efisiensi dan kepastian finalitas.
Perubahan ini tidak diumumkan secara besar-besaran, tapi dampaknya cukup signifikan—masalah "mencegah serangan terarah" yang ingin diselesaikan oleh Proof of Blind Bid pada tahap awal ditangani dengan pendekatan berbeda dalam Succinct Attestation, lebih mengandalkan ukuran komite dan ketidakpastian hasil pemilihan, bukan membuat identitas benar-benar menghilang. Bagi saya, ini mengingatkan satu hal: dalam menilai desain teknis sebuah proyek, kita tidak bisa hanya menjadikan tulisan dari beberapa tahun lalu sebagai satu-satunya rujukan. Mekanisme inti Dusk sendiri terus mengalami iterasi. Skema pemilihan anonim yang terdengar sangat keren pada tahap awal mungkin sudah tidak seperti yang dijalankan sekarang.

Akhirnya sudah menunggu $ALIGN TGE

Hari ini pukul 23:00 waktu Beijing, Aligned akan memulai TGE.

Sebagai proyek yang berfokus pada verifikasi ZK Proof dan infrastruktur komputasi terverifikasi untuk Ethereum, pembangunan produk Aligned sejauh ini cukup solid.

Menantikan performa hari ini, dan juga menantikan ekosistem Aligned untuk terus berkembang.

Ditambah lagi, bursa seperti Coinbase juga punya rencana untuk listing, berharap bisa ikut merasakan hasilnya
$ALIGN 🚀

#dusk $DUSK @Dusk Selama ini, pemahaman saya tentang Phoenix adalah: "ini adalah versi Dusk dari Zcash/Monero"—sebuah model transaksi privasi yang mengejar anonimitas sepenuhnya, di mana kedua pihak yang melakukan transfer tidak dapat saling melihat. Namun sampai baru-baru ini, ketika saya membandingkannya dengan penjelasan resmi dari whitepaper versi pembaruan tahun 2024, saya baru sadar bahwa pemahaman saya sudah ketinggalan zaman.
Dalam catatan pembaruan, pihak resmi menuliskannya sangat jelas: mereka menambahkan ke Phoenix kemampuan "agar penerima dapat mengenali identitas pengirim", dan secara tegas menyatakan langkah ini mengubah Phoenix dari sebuah protokol anonim (anonymity protocol) menjadi protokol yang menjaga privasi (privacy-preserving protocol), dengan tujuan untuk memenuhi regulasi Uni Eropa saat ini. Di dokumen yang sama juga disebutkan bahwa motivasi langsung memasukkan Moonlight (model akun transparan) adalah karena tim menyadari bahwa jika mereka ingin berintegrasi dengan bursa dan institusi dengan lancar, model akun yang benar-benar anonim saja tidak cukup—bahkan mereka menulis dengan gamblang bahwa mereka melakukannya untuk "memastikan kepatuhan dan menghilangkan risiko diblacklist/dikeluarkan".
Bagi saya, titik balik ini ternyata lebih besar daripada yang kebanyakan orang kira. "Anonim" dan "privasi" bukanlah dua kata yang sinonim dalam komunitas kriptografi—protokol anonim berupaya membuat pihak ketiga mana pun (termasuk penerima) tidak dapat menentukan siapa pengirimnya; protokol yang menjaga privasi hanya memastikan pihak luar tidak melihat detailnya, tetapi keteridentifikasian di antara kedua pihak dalam transaksi bisa dipertahankan, bahkan sengaja dirancang. Dusk secara sadar meninggalkan pendekatan yang pertama dan memilih pendekatan yang kedua. Ini bukan kompromi teknis, melainkan penyesuaian positioning produk yang sangat sadar—ambisi Phoenix di whitepaper awalnya sebenarnya lebih dekat ke mata uang privasi murni, lalu kemudian dibelokkan oleh realitas kepatuhan.
Dulu saya mengira "anonim" adalah daya tarik paling inti dari Phoenix, tetapi setelah menengok ke belakang, saya sadar pemahaman itu sendiri menilai sebuah protokol yang sudah berevolusi menggunakan whitepaper lama yang sudah tidak relevan. Bagi orang yang masih menilai Phoenix dengan kerangka "apakah Dusk adalah koin anonim", mungkin pertanyaan itu sudah keliru—yang seharusnya ditanyakan adalah: dengan asumsi "penerima dapat mengenali pengirim", batas privasi yang tersisa di Phoenix tepatnya berada di mana, dan apakah batas tersebut cukup untuk menopang skenario kepatuhan institusional yang ingin dilayaninya.

#termmax @TermMax TermMax mengubah setiap posisi leverage menjadi sebuah GT, yaitu ERC-721. Saat pertama kali melihat desain ini, saya tidak banyak berpikir, sampai saya menyadari bahwa NFT bisa dipindahtangankan—yang berarti "posisi yang membawa utang", secara teori dapat dijual kepada orang lain.

Pada posisi leverage biasa, risiko dan imbal hasil terikat pada diri pembuka posisi: jika rugi, ditanggung sendiri; jika untung, diambil sendiri. GT memecah hal itu. Jika GT bisa beredar di pasar sekunder, pembeli tidak membeli "aset yang pasti", melainkan "kondisi rasio jaminan pada saat ini + risiko likuidasi di masa depan". Orang yang bersedia menjadi pembeli pada dasarnya sedang memberi harga pada tingkat kesehatan posisi saat ini—tidak ada perbedaan yang mendasar dengan membeli obligasi diskon, hanya saja jaminan dan struktur leverage jauh lebih rumit dibanding obligasi.

Jika desain TermMax benar-benar berjalan, ia dapat menciptakan bentuk perilaku perdagangan yang baru: ada pihak yang secara khusus membeli posisi GT dengan harga murah yang LTV-nya sudah terlalu tinggi, tetapi belum memicu LLTV, dengan taruhan bahwa ia akan menemukan pembeli berikutnya sebelum garis likuidasi, atau dengan taruhan bahwa ia mampu mengelola posisi itu lebih baik daripada pemilik sebelumnya. Ini terdengar seperti upaya memberi risiko kepada pihak yang lebih profesional untuk menanggungnya, tetapi juga bisa jadi hanya memindahkan risiko likuidasi dari satu orang yang tidak terlalu paham ke orang lain yang sama-sama tidak terlalu paham, hanya saja berani mengambil taruhan. Protokolnya sendiri tidak akan menjadi lebih aman hanya karena GT berganti pemilik.

Yang lebih ingin saya pahami adalah: apakah saat ini di pasar sekunder GT ada catatan perpindahan tangan yang benar-benar terjadi? Ketika terjadi transaksi, apakah informasi tentang kondisi jaminan saat ini simetris antara pembeli dan penjual, atau apakah "dapat dialihkan" ini sejauh ini hanya berhenti di tingkat kontrak, sementara pada praktiknya tidak ada yang benar-benar memakainya. Apakah satu posisi TermMax bisa diperdagangkan dan apakah ia benar-benar diperdagangkan adalah dua hal yang sepenuhnya berbeda.