Mengapa keuangan tingkat institusi selalu mengernyitkan dahi terhadap blockchain? Setelah dipikir-pikir, tetap saja dua kata ini: kinerja. Setiap kali tim teknologi menyebut "bukti pengetahuan nol" dan "perlindungan privasi", reaksi lembaga keuangan biasanya adalah—seberapa lambatnya ini harus?
Sistem pembuktian Rushel dari Dusk ingin mematahkan stereotip ini. Ambisinya sangat jelas: benar-benar memasukkan kemampuan privasi ZK ke dalam kisaran TPS yang dapat diterima lembaga, bukan memaksa lembaga memilih salah satu.
Yang disebut "variasi kinerja tinggi", inti pemikirannya sebenarnya adalah menyeimbangkan antara pembuatan dan verifikasi bukti. Terutama untuk skenario transaksi keuangan yang memiliki pola tertentu, mungkin bukan solusi ZK serba bisa yang menyelesaikan semua masalah, melainkan secara spesifik menyiapkan rangkaian yang lebih efisien untuk operasi keuangan (seperti transfer aset, verifikasi saldo). Atau dengan kata lain, menggunakan teknologi pembuktian rekursif untuk "mengompresi" bukti dari beberapa transaksi menjadi satu, sehingga di rantai hanya perlu memverifikasi bukti gabungan ini. Dengan cara ini, peningkatan TPS langsung terlihat—yang sebelumnya harus diproses satu per satu, sekarang menjadi proses batch.
Istilah "menyisipkan batas TPS" juga sangat penting. Tujuan Rushel bukanlah mengejar TPS maksimal di atas kertas, melainkan menemukan titik kritis di mana lembaga merasa "cukup bisa digunakan, pengalaman tidak buruk". Transaksi frekuensi tinggi yang membutuhkan waktu mikrodetik? Tentunya tidak realistis. Tapi untuk skenario perdagangan besar, penyelesaian aset, clearing pasar over-the-counter, setiap detik memproses puluhan hingga ratusan transaksi privasi, ditambah konfirmasi akhir dalam beberapa detik? Itu sudah cukup membuka banyak peluang aplikasi.
Pertanyaannya: apakah optimisasi yang spesifik untuk skenario keuangan ini akan melemahkan fleksibilitasnya? Bisakah tetap menjaga manfaat kinerja sekaligus kemampuan beradaptasi? Produk keuangan berkembang terlalu cepat, akankah Rushel mampu mengikuti? Inilah ujian sebenarnya—kinerja tidak pernah angka tetap, harus seimbang secara dinamis dengan kompleksitas bisnis.
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
11 Suka
Hadiah
11
5
Posting ulang
Bagikan
Komentar
0/400
DeFiGrayling
· 14jam yang lalu
Kinerja ini, Rushel, jika benar-benar bisa dikendalikan, akan luar biasa, tapi saya masih sedikit meragukan apakah itu bisa mengikuti kecepatan iterasi gila di bidang keuangan.
Lihat AsliBalas0
GhostInTheChain
· 15jam yang lalu
Semua orang mengklaim bahwa Rushel dapat memecahkan kebuntuan kinerja, tetapi sebenarnya mereka hanya berfokus pada cerita di dalam bidang keuangan yang sempit ini. Apakah performa umum benar-benar terjamin? Saya kurang yakin.
Lihat AsliBalas0
ThesisInvestor
· 15jam yang lalu
Singkatnya, mereka ingin mencari keseimbangan antara privasi dan kecepatan. Kedengarannya bagus, tapi apakah bisa direalisasikan? Orang-orang di bidang keuangan paling takut gagal, kan?
Lihat AsliBalas0
PensionDestroyer
· 15jam yang lalu
Haha, ini lagi-lagi pola lama dalam performa. Rushel dengan teknik kompresi rekursif ini terlihat bagus, tapi saat benar-benar digunakan di lingkungan produksi? Pasti tetap akan mengalami masalah.
Lihat AsliBalas0
SelfStaking
· 15jam yang lalu
Hmm, tetap masalah lama, performa ZK menjadi penghambat... Dusk kali ini berusaha mengatasi latensi melalui pre-kompilasi rangkaian + kompresi rekursif, ide bagus tapi apakah benar-benar bisa diterapkan?
Mengapa keuangan tingkat institusi selalu mengernyitkan dahi terhadap blockchain? Setelah dipikir-pikir, tetap saja dua kata ini: kinerja. Setiap kali tim teknologi menyebut "bukti pengetahuan nol" dan "perlindungan privasi", reaksi lembaga keuangan biasanya adalah—seberapa lambatnya ini harus?
Sistem pembuktian Rushel dari Dusk ingin mematahkan stereotip ini. Ambisinya sangat jelas: benar-benar memasukkan kemampuan privasi ZK ke dalam kisaran TPS yang dapat diterima lembaga, bukan memaksa lembaga memilih salah satu.
Yang disebut "variasi kinerja tinggi", inti pemikirannya sebenarnya adalah menyeimbangkan antara pembuatan dan verifikasi bukti. Terutama untuk skenario transaksi keuangan yang memiliki pola tertentu, mungkin bukan solusi ZK serba bisa yang menyelesaikan semua masalah, melainkan secara spesifik menyiapkan rangkaian yang lebih efisien untuk operasi keuangan (seperti transfer aset, verifikasi saldo). Atau dengan kata lain, menggunakan teknologi pembuktian rekursif untuk "mengompresi" bukti dari beberapa transaksi menjadi satu, sehingga di rantai hanya perlu memverifikasi bukti gabungan ini. Dengan cara ini, peningkatan TPS langsung terlihat—yang sebelumnya harus diproses satu per satu, sekarang menjadi proses batch.
Istilah "menyisipkan batas TPS" juga sangat penting. Tujuan Rushel bukanlah mengejar TPS maksimal di atas kertas, melainkan menemukan titik kritis di mana lembaga merasa "cukup bisa digunakan, pengalaman tidak buruk". Transaksi frekuensi tinggi yang membutuhkan waktu mikrodetik? Tentunya tidak realistis. Tapi untuk skenario perdagangan besar, penyelesaian aset, clearing pasar over-the-counter, setiap detik memproses puluhan hingga ratusan transaksi privasi, ditambah konfirmasi akhir dalam beberapa detik? Itu sudah cukup membuka banyak peluang aplikasi.
Pertanyaannya: apakah optimisasi yang spesifik untuk skenario keuangan ini akan melemahkan fleksibilitasnya? Bisakah tetap menjaga manfaat kinerja sekaligus kemampuan beradaptasi? Produk keuangan berkembang terlalu cepat, akankah Rushel mampu mengikuti? Inilah ujian sebenarnya—kinerja tidak pernah angka tetap, harus seimbang secara dinamis dengan kompleksitas bisnis.