Di tabel perbandingan pemasok di situs Rayls terdapat sembilan baris, dan saya memilih baris “Privasi”. Alasannya sangat sederhana: privasi itu penting, dan Besu bersifat open source—saya bisa memeriksa dokumentasi dan kodenya.
Di tabel perbandingan, Rayls memberi tanda centang pada dua baris: “privasi terisolasi” dan “privasi kriptografi”, sedangkan Besu hanya memberi tanda centang pada baris yang pertama. Saya berencana memverifikasi dengan dokumentasi milik mereka sendiri, jadi saya mencari dokumentasi Besu, lalu mengunduh kodenya dan menghitungnya satu per satu.
Kesimpulannya bukan “Besu tidak bisa”. Perbedaannya yang nyata adalah: kedua pihak menempatkan privasi pada lapisan yang berbeda, dan Besu memindahkannya lebih cepat daripada yang banyak orang kira.
Pihak Besu: dari dokumen ke kode
Di dokumentasi resmi Besu, halaman-halaman yang terkait privasi sekarang di bagian atas dipasang spanduk yang sama: fitur privasi berbasis Tessera dinonaktifkan mulai versi 24.12.0.
Penghapusan yang sesungguhnya terjadi pada 25.6.0. Catatan rilis versi ini mencantumkannya sebagai perubahan destruktif: penghapusan fungsi privasi Tessera, nomor #8369. Pada rilis batch yang sama, juga dihapus manajemen otorisasi on-chain.
Bagian yang saya verifikasi sendiri adalah sebagai berikut. Pertama, gunakan tiga nomor versi untuk mengambil file yang sama: di 25.4.0, PrivateTransaction.java dan Enclave.java sama-sama mengembalikan 200; di 25.6.0 dan 26.2.0, keduanya mengembalikan 404. Lalu cek antarmuka: pada 25.4.0, di enum RpcMethod ada 23 metode yang diawali priv_, eea_, dan privx_. Pada 26.2.0, pada file yang sama, tidak ada satupun. Di sisi command line juga sama: 25.4.0 punya 12 parameter startup yang diawali --privacy; di BesuCommand.java pada 26.2.0, kata “privacy” bahkan tidak bisa ditemukan lewat pencarian. Dari sisi skala: di 25.4.0, ada 153 file Java non-uji yang terkait privasi dan enclave, total 17.875 baris.
Mengapa Besu perlu melakukan ini
Bagian ini wajib ditulis, kalau tidak nanti jadi seperti membidik-cari-cela.
Dalam pengumuman pada 24 September 2024, pemelihara Besu memberikan alasannya: basis kodenya berubah menjadi semacam pisau Swiss Army yang gemuk; fungsionalitas seperti Tessera kurang memadai pada skenario yang sebenarnya ingin diselesaikannya, sementara lapisan aplikasi sudah memiliki solusi yang matang dan yang baru. Pengumuman itu juga menyebut bahwa proyek privasi terprogram open source yang ditujukan untuk EVM segera akan diserahkan ke LF Decentralized Trust Laboratory.
Proyek itu adalah Paladin; sekarang sudah naik status dari proyek laboratorium menjadi proyek resmi LF Decentralized Trust, berlisensi Apache 2.0. Privasi token direalisasikan dengan dua cara: menggunakan zero-knowledge proof atau pre-verification dari pihak penerbit. Ia berjalan di atas rantai EVM mana pun.
Jadi, kalau ingin paling akurat: Besu tidak meninggalkan privasi; ia memindahkan privasi dari klien ke lapisan aplikasi.
Dua cara penempatan, masing-masing ada harganya
Cara Rayls adalah memasukkan privasi ke dalam protokol: Enygma mengenkripsi isi transaksi dengan AES-256, mencatat komitmen saldo dengan Pedersen, dan menggunakan Groth16 untuk membuktikan bahwa transaksi ini benar—dengan melewati jalur transaksi biasa.
Biaya dari jalur ini bisa dikuantifikasi. Pada versi sebelumnya, saya mengukur waktu pembuatan bukti: dalam lingkungan single-core, klaster anonim 6 orang per transaksi butuh 1,96 detik. Hari ini saya mengukur hal lain: ukuran bukti itu sendiri hanya 164 byte, dan ukuran klaster 2 orang sama besar dengan klaster 6 orang karena bukti Groth16 berukuran tetap. Tetapi data publik yang dipublikasikan bersama bukti tidak berukuran tetap: klaster 2 orang 588 byte, klaster 6 orang 1.612 byte.
Angka ini sekaligus mengoreksi satu pernyataan yang sering beredar. Bukan hanya “satu bukti” yang keluar dari lingkungan privat, melainkan muatan terenkripsi, bukti, dan data publik yang diperlukan; isi tetap dirahasiakan, sementara sistem masih dapat memverifikasi dan menyelesaikan transaksi.
Sekalian saya bahas baris lain dari tabel perbandingan. Rayls memberi tanda centang pada “privasi terisolasi”, dengan mengandalkan struktur deployment: buku catatan Sovereign milik setiap institusi ditempatkan di dalam batasnya sendiri. Menurut pernyataan di situs resmi, data privat tidak keluar dari instance tersebut; hanya muatan minimum yang diperlukan untuk menyelesaikan satu transaksi yang akan dikirim ke jaringan eksternal. Jadi dua baris ini bagi Rayls adalah dua hal yang berbeda: antar institusi dipisahkan lewat isolasi deployment, dan penyelesaian lintas institusi dilakukan lewat kriptografi. Yang ini hanya saya lihat dari situs resmi dan dokumentasi; belum pernah saya jalankan deployment-nya secara nyata.
Bagian lisensi juga perlu ditampilkan. Rayls open stack menggunakan Apache 2.0, tetapi dua modul Enygma dan Axyl memakai BUSL 1.1: pengujian gratis, produksi perlu izin. Setelah empat tahun setiap rilis versi, semuanya otomatis berubah menjadi Apache 2.0. Paladin sendiri adalah Apache 2.0.
Apa artinya ini bagi sebuah institusi
Jika jaringan privat sebuah institusi berjalan di Besu, dan menggunakan antarmuka priv_ atau eea_, maka langkah naik ke 25.6.0 bukanlah upgrade, melainkan migrasi. 23 antarmuka dan 12 parameter startup hilang sekaligus; logika privasi harus dipindahkan ke lapisan aplikasi dan ditulis ulang. Kalau tidak dipindahkan, Anda hanya bisa berhenti di seri 25.4, dan setelah itu semua peningkatan performa serta perbaikan keamanan tidak ada hubungannya dengan Anda.
Kalau pilih Rayls, privasi dan ledger adalah satu paket yang sama—versi, audit, dan dukungan sejalan, jadi tidak perlu Anda merangkainya sendiri. Konsekuensinya: setiap transaksi rahasia harus menghitung bukti terlebih dahulu; semakin besar kumpulan anonim, semakin besar juga data publik yang dibutuhkan, dan bagian Enygma harus memakai lisensi BUSL.
“Semakin banyak” itu seberapa banyak—bisa saya hitung. Berikut perhitungan saya. Satu transfer rahasia untuk klaster 6 orang: ukuran total bukti + data publik sekitar 1.776 byte. Dengan menyesuaikan skala berdasarkan rata-rata harian 210.483 transaksi per hari versi Inggris CHAPS 2025, hasilnya sekitar 374 MB per hari, atau sekitar 136 GB per tahun. Untuk penyimpanan institusi, itu bukan apa-apa, tetapi itu merupakan overhead tetap yang tumbuh secara linear seiring jumlah catatan, dan kumpulan anonimnya bisa diatur: kalau diturunkan ke klaster 2 orang, setiap transaksi hanya 752 byte. Di sini saya berasumsi tiap transaksi hanya menghasilkan satu bukti, dan tidak menghitung rangkaian untuk menyimpan, menarik, serta jenis rangkaian DvP.
Dari baris ini, hanya ada tiga kata yang bisa diambil sebagai pertanyaan umum: di lapisan mana. Tanya ke pemasok: fitur privasi itu tinggal di lapisan mana, dikelola oleh siapa, seperti apa siklus hidupnya, dan apakah buku catatannya terikat dengan ledger. Perubahan Besu dalam dua tahun terakhir menunjukkan bahwa jawabannya akan berubah, dan perubahan itu bersifat destruktif.
Yang saya pastikan, dan apa yang saya simpulkan
Bagian yang terkonfirmasi: apakah file ada atau tidak di versi yang berbeda, jumlah antarmuka dan parameter startup, isi pengumuman resmi dan catatan rilis, jumlah byte bukti dan data publik, serta waktu yang dibutuhkan bukti pada versi sebelumnya. Semua ini bisa diulang dengan perintah yang sama persis seperti yang ada di tangkapan layar.
Bagian yang bersifat inferensial: peningkatan akan mengganggu layanan privasi yang sudah ada—ini saya simpulkan dari hilangnya sesuatu di antarmuka; saya tidak benar-benar menaikkan jaringan privat 25,4 ke 25,6 untuk mengujinya. Apakah Paladin bisa menangani skenario spesifik untuk satu institusi tertentu, itu juga belum saya evaluasi.
Dari sisi cakupan, saya hanya melihat rangkaian transfer dan bagian privasi. Pengguna Besu sepenuhnya bisa memelihara cabang sendiri atau menulis plugin—izin lisensinya memungkinkan itu. Untuk delapan baris lain pada tabel perbandingan, saya tidak menyentuhnya.
Pendapat saya
Tabel perbandingan itu adalah gambar statis, sedangkan kemampuan proyek open source akan bergerak. Dalam dua tahun, baris ini berubah dari “dibangun di klien” menjadi “ditangani sendiri di lapisan aplikasi”, tapi tabelnya hanya bisa menandai satu centang saja.
Jadi saya lebih suka menganggap tabel seperti ini sebagai titik awal daftar cek: setiap baris, Anda lihat langsung satu kali di repositori pihak lawan untuk versi yang sedang berjalan. Waktu yang saya habiskan kurang dari satu jam—perintahnya ada di tangkapan layar. Untuk pembaruan tabel Rayls berikutnya, yang layak dilihat adalah apakah mereka menambahkan catatan versi pada kolom Besu.
Sumber referensi: halaman produk Rayls di situs Sovereign dan tabel perbandingan dari pemasok; spanduk penonaktifan pada bagian privasi di dokumentasi resmi Besu; rilis Besu 25.6.0, entri #8369; pengumuman LF Decentralized Trust tanggal 24 September 2024 (Sunsetting Tessera and Simplifying Besu) dan pengumuman proyek Paladin; tiga tag di repositori hyperledger/besu: 25.4.0, 25.6.0, 26.2.0 (dibaca pada 24 September 2026); pengiriman raylsnetwork/rayls-sovereign-gnark-api 67c4c26 (uji lokal).