#dusk Minggu lalu terjadi sesuatu yang memalukan. Aku pergi ke bank untuk mengurus urusan, tetapi kartu penanganan (dari teller) macet di sebuah halaman verifikasi identitas, seolah-olah “hidup” tapi tidak bergerak. Di belakangku, antrian makin panjang. Pada akhirnya, cara yang dipakai petugas penanggung jawab untuk menyelesaikannya sangat sederhana: langsung mematikan sistem baru yang memunculkan error, lalu kembali ke perangkat lunak internal yang lama. Kejadian ini membuatku melihat sebuah kenyataan: personel di lapangan sama sekali tidak peduli seberapa canggih teknologi di belakang layar. Selama menghambat operasi di lokasi, seberapa indah pun alatnya, pada saat itu juga akan dibuang. $RE

Jalur kepatuhan di rantai (on-chain compliance) sebenarnya menginjak lubang yang sama. Banyak proyek dengan gembar-gembor perlindungan privasi, tapi begitu bagian depan menghasilkan bukti Zero-Knowledge, kipas komputer langsung kencang, halaman jadi macet beberapa menit. Staf manajemen risiko dari lembaga lebih memilih terus menggunakan laporan offline tradisional, dan tidak mungkin menemani browser menunggu halaman itu diproses pelan-pelan.

Beberapa waktu lalu aku meninjau rencana teknis milik @Dusk . Mereka mencoba mengubah “jalan buntu” ini dari sumbernya. Piecrust VM yang dirancang khusus untuk bukti zero-knowledge menggantikan lapisan eksekusi tradisional, sehingga biaya komputasi bisa ditekan—itulah yang membuat in-browser proving menjadi mungkin untuk benar-benar diterapkan. Lalu ditambah dengan verifikasi identitas berbasis zero-knowledge dari protokol Citadel, mereka mencoba menyelesaikan penilaian kepatuhan dengan syarat data tidak keluar dari domain.

Namun, meninggalkan jalur EVM umum untuk membangun virtual machine sendiri pada dasarnya adalah pedang bermata dua. Meski meningkatkan efisiensi eksekusi kriptografi, hambatan untuk mengintegrasikan aplikasi eksternal dan memindahkan likuiditasnya justru sangat meningkat. Apalagi, dalam tekanan beban konkurensi yang ekstrem, apakah perangkat kantor biasa bisa tetap “tidak mati” saat menjalankan kompilasi sirkuit—data pendukung berupa uji beban berskala besar di dunia nyata masih kurang. $BTC

Saat mengamati $DUSK , aku tidak pernah peduli seberapa tinggi kemasan naskah (copywriting) yang dipakai. Yang aku lihat hanya apakah itu sanggup melewati ujian pada layanan keuangan yang benar-benar nyata. Jika arsitektur dasarnya dibangun sedemikian indah, tapi pada akhirnya orang tidak bisa menunggu karena ambang akses aplikasi tinggi atau waktu komputasi terminal terlalu lama, apa bedanya dengan sistem bank hari itu yang akhirnya terpaksa kembali ke perangkat lunak lama? Bukankah meja transaksi yang sibuk benar-benar akan membayar biaya—meski hanya tambahan beberapa detik menunggu—demi “keanggunan teknis” yang diklaim?