19 September Rayls mengirim sebuah artikel berjudul (Privacy has a price). Di judulnya tertulis honest math, namun seluruh artikel hanya memberikan satu rentang angka: sebuah pembuktian memerlukan ratusan milidetik hingga beberapa detik. Saya sudah menulis tentang arsitektur privasi Rayls selama beberapa minggu; kali ini saya ingin berbagi konten baru. Saya menurunkan kode bukti yang dipublikasikannya, menjalankannya beberapa puluh kali, lalu berbagi kesimpulan menarik ini untuk kalian!
Pertama, mari kita bahas tentang apa yang diceritakan di blog itu. Argumen intinya bisa diringkas menjadi dua kalimat. Kalimat pertama menjelaskan di mana biayanya: transaksi rahasia lebih mahal daripada transaksi transparan—mahalnya ada pada proses pembuatan bukti zero-knowledge, sementara verifikasinya justru lebih murah. Untuk sebuah bukti dari transfer rahasia dasar, dibutuhkan ratusan milidetik hingga beberapa detik pada perangkat keras komersial biasa. Kalimat kedua menjelaskan apa yang seharusnya ditanyakan: institusi tidak semestinya hanya menanyakan TPS, melainkan menanyakan throughput pada tingkat privasi dan kebutuhan audit yang mereka inginkan, saat menghadapi beban kerja bisnis yang nyata. Blog berpendapat bahwa volume penyelesaian antarbank tidak besar, sehingga sepenuhnya masih berada dalam kapasitas sistem penyelesaian yang bersifat rahasia.
Hal yang dilakukan artikel ini sangat sederhana: mengambil pertanyaan yang diajukan blog itu sendiri, lalu menanyakannya pada kode publik Enygma. Di bawah ini, setiap kali tertulis “blog mengatakan”, itu adalah klaim dari naskah asli; yang tertulis “saya mengukur” dan “saya menghitung” adalah hasil dan perkiraan saya sendiri—silakan dipahami secara terpisah.
Bagaimana cara saya mengukurnya
Bukti zero-knowledge bisa dipahami sebagai bukti matematika: pihak pembayar tidak mempublikasikan saldo dan jumlahnya, tetapi masih bisa membuktikan pada jaringan bahwa transaksi itu benar. Sistem bukti yang dipakai Enygma adalah Groth16; kode layanan yang membuat bukti dipublikasikan di GitHub dalam repositori rayls-sovereign-gnark-api. README menjelaskan posisinya sebagai antarmuka bukti yang dipakai di balik Privacy Ledger dan Private Network Hub.
Saya mengukur komit terbaru 67c4c26 di branch main pada 22 Sep 2026. Kode rangkaian dan kode pembuatan bukti tidak berubah sama sekali. Saya hanya menulis beberapa file pengujian tambahan untuk memanggil fungsi bukti milik repositori; data transaksi yang dimasukkan juga diambil dari testset yang disertakan oleh repositori sendiri, dengan satu set untuk k=2 dan satu set untuk k=6.
Di sini, k adalah ukuran himpunan anonimitas. Dari kode rangkaian, satu transaksi transfer akan membuat sebuah komitmen jumlah untuk masing-masing dari k pihak peserta; pengirim menyembunyikan dirinya di antara komitmen-komitmen itu, sehingga pihak lain tidak dapat mengetahui siapa yang membayar siapa. Semakin besar k, semakin dalam penyembunyiannya dan rangkaiannya juga makin besar. Script pressure testing yang disertakan di repositori menggunakan k=6.
Kuncinya saya buat di mesin saya sendiri menggunakan groth16.Setup yang sama. Ini tidak memengaruhi waktu, karena waktu pembuatan bukti ditentukan oleh struktur rangkaian, bukan oleh nilai kunci spesifik. README repositori juga menyatakan bahwa kumpulan kunci di repositori itu sendiri adalah produk pengembangan dan pengujian yang dibuat dengan Setup sepihak, bukan hasil dari upacara setup tepercaya multipihak; untuk deployment produksi perlu dilakukan upacara terpisah—ini konsisten dengan pernyataan blog bahwa Groth16 memerlukan setup tepercaya.
Lingkungan pengujian adalah sebuah virtual machine Linux single-core dengan Intel Xeon 2,1GHz dan RAM 3GB. Untuk setiap level, buat 20 bukti secara berurutan; setelah beberapa menit, seluruh rangkaian pengujian menjalankan putaran kedua secara lengkap.
Angka yang saya dapat
Hasil putaran kedua: bukti k=6, median pada 1,96 detik dari 20 kali percobaan; tercepat 1,94 detik; terlambat 2,12 detik. Median k=2 adalah 0,96 detik. Putaran pertama masing-masing 1,97 detik dan 0,96 detik; selisih kedua putaran kurang dari 1%. Verifikasi sebuah bukti hanya butuh 1,9 milidetik.
Angka-angka ini masuk ke rentang yang diberikan blog. Yang lebih patut diperhatikan adalah rasio antara waktu pembuatan dan verifikasi: 1,96 detik berbanding 1,9 milidetik, kira-kira 1.000 banding 1. Blog mengatakan sebagian besar waktu dihabiskan untuk pembuatan, sedangkan verifikasi sangat murah; rasio ini mengubah kata “sebagian besar” menjadi kelipatan yang konkret.
Saya juga melakukan pengecekan balik. Testset menyertakan dua set data yang sengaja dimodifikasi dengan salah: untuk set k=2, salah satu nilai jumlah transfer diubah dari 0 menjadi 10; untuk set k=6, seseorang memalsukan satu nilai hash. Kedua set tersebut ditolak pada tahap pembuatan bukti, dengan masing-masing melaporkan ketidaksesuaian constraint pada baris 517 dan 1085—sehingga tidak bisa menghasilkan bukti. Tentu saja ini tidak membuktikan bahwa rangkaiannya tidak memiliki celah; ini hanya menunjukkan bahwa dua jenis manipulasi yang jelas-jelas terlihat tersebut akan terhalang.
Detail yang tidak ada di kedua blog tersebut
Detail pertama ada pada skala rangkaian. Setiap kali menambah satu pihak peserta, jumlah constraint bertambah tetap sebanyak 8.112. Dari k=2 sebanyak 37.140, naik terus secara lurus sampai 69.588 pada k=6. Namun, sistem pembuktian saat mengalokasikan ruang komputasi ke rangkaian melakukan pembulatan berdasarkan pangkat dua: dari k=2 sampai k=5 semuanya masuk dalam 65.536, sedangkan k=6 melampaui 4.052, sehingga skala komputasi langsung beralih ke 131.072.
Buktinya ada pada ukuran file kunci bukti. Dari k=2 sampai k=5, ukuran kunci meningkat secara stabil sebesar 918.382 byte tiap tingkat; dari k=6, naik secara “mendadak” sebesar 3.015.534 byte—lebih dari tiga kali lipat kenaikan tiap tingkat sebelumnya. Arah kenaikan waktu juga sesuai: dari k=2 ke k=6 constraint bertambah 87%, dan waktu bukti bertambah 104%. Berapa tambahan waktu spesifik untuk melintasi batas ini—itu baru bisa diketahui bila ada data transaksi dari k=3 sampai k=5. Saat ini repositori hanya menyediakan dua tingkat k=2 dan k=6, jadi yang bisa dipastikan adalah arah yang sama. Jika pada lingkungan produksi yang dipakai memang k=6, maka posisinya tepat di sisi lain dari batas ini; biaya mengganti dari k=5 ke k=6 akan lebih besar daripada antar beberapa tingkat sebelumnya—ini adalah perkiraan saya, bukan klaim blog.
Detail kedua adalah konsistensi. Dari lima level kunci bukti yang saya buat dari kode sumber publik, ukuran file dan produk build resmi repositori sama persis hingga byte. Kunci verifikasi untuk k=6 juga sama. Isi kuncinya pasti berbeda, karena setiap kali Setup dilakukan, ia menghasilkan acak ulang; tetapi ukurannya sepenuhnya identik, yang menunjukkan bahwa struktur rangkaian yang dikompilasi dari kode sumber publik sama dengan struktur build resmi. Di tulisan sebelumnya, saat saya membahas audit Axyl, saya sempat menyebut ada bagian sejarah yang tidak bisa ditelusuri antara repositori publik dan versi privat yang digunakan saat audit. Kali ini pada sisi layanan pembuatan bukti, setidaknya bagian antara kode sumber dan build resmi cocok; apakah build resmi sama dengan deployment produksi, masih belum bisa dijawab oleh materi publik.
把博客的问题代进真实负载
Sambung dulu ke tulisan sebelumnya. Di tulisan sebelumnya, saya mengurai sumber dari beberapa angka untuk 15.000+ TPS; angka-angka itu mendeskripsikan lapisan konsensus Axyl. Kali ini yang saya ukur adalah lapisan lain, yaitu waktu pembuatan bukti yang harus dibayarkan terlebih dahulu oleh pengirim untuk setiap transaksi rahasia. Angka dua lapisan ini tidak bisa dijumlahkan dan juga tidak bisa saling menggantikan.
Skala yang dicontohkan oleh blog adalah: hubungan antar bank agen besar menghasilkan beberapa ribu transaksi per hari, dan layanan settlement real-time full-scale tokenisasi pada level bank sentral menghasilkan puluhan ribu transaksi transfer bernilai besar per hari. Saya mengubahnya menjadi data publik dari dua sistem yang sudah ada. Layanan Fedwire Funds Service dari Federal Reserve memiliki rata-rata 869.187 transaksi per hari pada tahun 2025; CHAPS Inggris untuk 2025 memiliki rata-rata 210.483 transaksi per hari; keduanya adalah puluhan kali dan beberapa kali lipat dari contoh blog.
Berikut adalah perhitungan saya, bukan klaim blog. Berdasarkan verifikasi pengukuran dengan 1 inti: satu bukti k=6 membutuhkan 1,96 detik. Maka, dalam sehari maksimal sekitar 44.000 bukti. Jika semua jumlah transaksi harian rata-rata Fedwire tahun 2025 diubah menjadi bukti k=6, diperlukan sekitar 473 jam CPU; setara dengan 20 hari penuh tanpa henti. Untuk CHAPS diperlukan sekitar 115 jam CPU, kurang dari 5 hari penuh. Materi pengantar Bank of England tahun 2021 mencatat rekor jumlah transaksi harian CHAPS adalah 320.034 transaksi pada 29 Maret 2018, sekitar 1,7 kali dari rata-rata harian tahun itu; dengan memakai puncak tersebut pun hanya butuh sekitar 174 jam CPU.
Ruang lingkup perkiraan ini perlu dijelaskan dengan jelas. Ia menghitung bahwa setiap bukti menempati satu inti CPU, dan bukti-bukti bersifat independen satu sama lain sehingga bisa dibagi ke inti yang berbeda untuk dibuat secara bersamaan. Ia menghitung waktu untuk bukti transfer itu sendiri; commit, extract, dan DvP adalah rangkaian lain. Transmisi jaringan dan penyelesaian di chain juga tidak termasuk di situ. Selain itu, blog mengatakan bahwa bukti dibuat oleh pengirim, sehingga beban secara alami tersebar di node-node milik masing-masing institusi dan tidak terkonsentrasi pada satu mesin.
Jadi kesimpulan saya adalah: klaim blog bahwa volume penyelesaian antarbank masih berada dalam kapasitas sistem penyelesaian rahasia, tetap berlaku pada skala volume yang nyata. Blog menggunakan angka yang lebih kecil daripada sistem nyata; ketika angka nyata dimasukkan, kesimpulannya tetap berdiri—justru ini membuat contoh di artikel tersebut lebih meyakinkan daripada contoh aslinya. Pada bagian pembayaran ritel, blog sendiri mengakui bahwa itu adalah kemacetan yang sebenarnya; kali ini angkanya tidak mengubah penilaian tersebut.
Bagaimana seharusnya memakai rangkaian angka ini
Semua angka kali ini berasal dari pengujian single-core, jadi dapat dianggap sebagai referensi yang sedikit konservatif. Alasannya ada di kode: saat gnark membuat bukti, perkalian multi-skalar (MSM) yang paling berat dipecah menjadi beberapa tugas untuk dihitung secara paralel berdasarkan jumlah inti CPU mesin (langsung membaca runtime.NumCPU() di backend/groth16/bn254/prove.go). Server institusi biasanya multi-core; bukti yang sama akan dibagi ke lebih banyak inti untuk dihitung bersama, sehingga waktunya akan lebih rendah dibanding hasil single-core di sini. Seberapa cepat tepatnya bergantung pada jumlah inti dan performa single-core.
Rentang pengukuran dalam artikel ini adalah proses pembuatan bukti itu sendiri untuk rangkaian transfer. Dalam keseluruhan rantai layanan HTTP lengkap, masih ada penguraian JSON dan overhead jaringan; penyimpanan (commit), penarikan (extract), serta DvP merupakan jenis rangkaian lain. Ukuran kunci yang sama menunjukkan struktur rangkaiannya sama, tetapi tidak berarti isi kuncinya sama—poin ini sudah saya jelaskan sebelumnya.
Pandangan saya
Judul blog adalah honest math, tetapi angka yang diberikan dalam isi hanya berupa sebuah rentang. Setelah saya jalankan, rentangnya benar, dan kesimpulan untuk bagian penyelesaian antarbank juga masih valid.
Yang lebih ingin saya lihat adalah langkah berikutnya. Halaman benchmark Axyl mencantumkan kondisi seperti komite empat node dan transaksi 512 byte; performa pembuktian Enygma juga layak diperlakukan setara: saat angka dipublikasikan berikutnya, tuliskan nilai k dan konfigurasi perangkat keras. Dengan begitu, institusi bisa mereplikasi sendiri seperti yang saya lakukan. Inilah jenis pernyataan performa yang “tahan uji produksi” seperti yang diakhiri oleh blog itu. Replikasi tidak sulit, perintah pada tangkapan layar adalah langkah lengkap.
Sumber referensi: Blog resmi Rayls (Privacy has a price: the honest math behind confidential settlement at scale) (19 Sep 2026); GitHub raylsnetwork/rayls-sovereign-gnark-api, commit 67c4c26 (dibaca dan diuji secara empiris pada 22 Sep 2026); Statistik tahunan Fedwire Funds Service (pembaruan 26 Jan 2026); statistik Payment and settlement Bank of England beserta (A brief introduction to RTGS and CHAPS) (edisi 2021).