Saya mulai melakukan staking RLS sejak fase pre-commitment; membacanya dari materi resmi adalah kebiasaan. Setelah nama “Sovereign” muncul, diskusinya kebanyakan berhenti pada “apakah ini hanya ganti nama”. Saya pikir pertanyaan itu mengarahnya terbalik. Nama itu tidak penting—yang penting adalah apa yang diganti di bawahnya, dan berapa banyak hal yang bisa diverifikasi sendiri oleh sebuah institusi saat melakukan due diligence. Setiap angka di artikel ini saya sudah sertakan sumber yang pasti; Anda bisa mencoba mereplikasi lagi persis berdasarkan itu.
Pertama, saya jelaskan satu hal: karena minggu lalu saya menulis artikel tentang keter-audit-an, ada pembaca yang mungkin sudah melihatnya.
Di artikel ini, sebagian besar kontennya baru: berasal dari repositori kode Axyl, direktori audit di dalam repositori, dan halaman dokumentasi tentang benchmark performa Axyl. Ketiga bagian ini sebelumnya tidak pernah saya sentuh. Hanya bagian kecil tentang key management/penitipan kunci yang merupakan kelanjutan dari kesimpulan tulisan sebelumnya; saya akan menandainya di sana. Memisahkan yang baru dan yang lama itu penting, supaya pembaca bisa membedakan sendiri “apa yang saya cek minggu ini” dan “apa yang saya cek sebelumnya”.
Pertama, luruskan dulu garis waktunya.
Ini bukan sekadar ganti nama.
Axyl dijadwalkan rilis lebih dulu di akhir April 2026 di mainnet publik Rayls. Migrasi Sovereign ke Axyl terjadi pada Juli 2026, setelah mainnet berjalan. Dokumentasi resmi menyatakan migrasi dilakukan secara bertahap, selama periode tersebut institusi tetap menjalankan layanan seperti biasa. Setelah lapisan bawah diganti, barulah muncul nama baru.
Bagian dokumentasi yang membahas What changed mencantumkan lima poin. Di bawah ini saya pilih dua untuk dibahas, karena kedua poin perubahan ini memengaruhi posisi institusi, bukan hanya parameter tumpukan teknis.
Perubahan 1: dari satu node menjadi sebuah komite
Kutipan kata demi kata dari dokumen: ledger Sovereign Rayls yang lebih awal dijalankan dalam bentuk node Geth tunggal dan validator tunggal. Axyl menjalankan konsensus toleransi kesalahan Byzantine lintas komite; risiko ketersediaan single node tidak lagi relevan. Bagian yang sama juga menulis bahwa node EVM berubah dari Geth menjadi Reth, dan Clique proof of authority diganti menjadi Axyl.
Saya pergi mengecek di repositori untuk mencari tahu Axyl itu apa. Ini adalah klien protokol yang ditulis dengan Rust; satu binary bernama rayls-network menjalankan dua bagiannya sekaligus: layer konsensus adalah implementasi Narwhal dan Bullshark, memakai QUIC dari libp2p; layer eksekusi dibangun di atas reth dan alloy, menghasilkan blok EVM Ethereum standar. Node dibagi menjadi validator dan observer; yang terakhir mengikuti rantai melalui sinkronisasi status tetapi tidak masuk komite. Toolchain-nya dikunci pada Rust 1.91.
Untuk sebuah bank, arti poin ini bukan pada throughput, melainkan pada ketahanan operasional. Ledger untuk satu node satu validator: satu kegagalan mesin berarti ledger berhenti, tidak ada redundansi. Dan itulah jenis desain yang paling sulit dijelaskan kepada regulator. Setelah diganti menjadi berbasis komite, masalah ini berubah dari tanpa jawaban menjadi punya jawaban standar; Byzantine Fault Tolerance adalah bahasa yang sudah akrab bagi manajemen risiko dan regulator.
Biayanya juga spesifik. README repositori memberi rekomendasi konfigurasi minimum: 8 core fisik, memori 16 GiB, SSD 500 GiB, dan bandwidth di atas 10 Gbps; dan ini adalah persyaratan untuk setiap anggota komite, bukan untuk satu mesin saja. Dokumen juga memberi dua tingkat konfigurasi untuk deployment ledger milik Sovereign: level ringan 2 vCPU, 4 GB, 100 GB; level enterprise minimal 4 core ke atas, 16 GB, 500 GB.
Ada satu bagian lain yang mudah terlewat: hub jaringan privat tidak diganti mengikuti perubahan; dokumen secara terpisah menjelaskan bahwa ia tetap menjalankan Besu dan bukti kewenangan, tidak terpengaruh oleh migrasi Axyl. Lapisan institusi saat ini memakai Byzantine Fault Tolerance, sementara lapisan antar-institusi masih memakai bukti kewenangan. Dua lapisan ini punya model kepercayaan yang berbeda—saat evaluasi, harus dilihat terpisah.
Perubahan 2: kunci dipindahkan keluar dari komponen transport
Bagian ini melanjutkan kesimpulan dari tulisan saya sebelumnya, bukan penemuan baru minggu ini. Saya taruh di sini karena brief meminta contoh dua perubahan, dan poin ini memang salah satu dari lima poin tersebut.
Poin dalam dokumen tersebut adalah modul manajemen kunci berubah menjadi Cryptographic Trust Suite—komponen penampung kunci yang ter-decouple. Relayer tidak lagi memproses atau menyimpan kunci secara langsung. Saya memverifikasi klaim ini di kode sumber pada tulisan sebelumnya; direktori cryptography di dua repositori—relayer dan governance services—cocok.
Maknanya bagi sebuah institusi ada dua. Pertama, Relayer adalah komunikasi ke luar dan komponen yang paling terekspos. Di struktur lama, ia menyentuh kunci sekaligus; di struktur baru, ia tidak bisa mengaksesnya—jadi jika lapisan transport diserang, itu tidak otomatis berarti kunci ikut diserang. Kedua, penyimpanan kunci bisa dipasang (plug-in) ke KMS milik institusi sendiri yang sudah mereka pakai atau hardware security module; akibatnya jejak audit yang sudah dimiliki institusi tersebut mencakup operasi kunci Rayls, jadi tidak perlu membangun permukaan audit baru untuk itu.
Bahan baru yang benar-benar saya dapat minggu ini: direktori audit.
Di repositori Axyl ada direktori audits/ yang berisi satu README dan tiga PDF. Saya sudah membaca README tersebut; isinya jauh lebih spesifik daripada sekadar kalimat “pernah menjalani audit pihak ketiga”.
Ketiga laporan tersebut semuanya dikeluarkan oleh Halborn. Jendela eksekusi berada pada Februari hingga Maret 2026, dan peninjauan ulang atas perbaikan selesai pada April hingga Mei.
Nama file dokumen protokol konsensus adalah halborn-2026-03-consensus-protocol.pdf. Cakupannya meliputi jalur kode Rust terkait konsensus, sinkronisasi sertifikat, penanganan gossip, dan manajemen kunci validator. Periode eksekusi: 2 Maret hingga 20 Maret, 5 temuan, terdiri dari 1 kritis, 3 sedang, 1 rendah; semuanya sudah diselesaikan.
Berkas untuk node jaringan adalah halborn-2026-03-network-node.pdf. Cakupannya meliputi modul jaringan, worker, sinkronisasi status, eksekusi, orkestrasi, dan penyimpanan. Periode eksekusi: 18 Februari hingga 24 Maret, 22 temuan, terdiri dari 1 kritis, 2 tinggi, 7 sedang, 6 rendah, 6 informatif/penunjuk. Ada 20 perbaikan, dan 2 penerimaan risiko rendah.
Kontrak pintar versi halborn-2026-03-smart-contracts.pdf, cakupannya adalah kontrak-kontrak seperti ConsensusRegistry, StakeManager, DelegationPool, serta kontrak pembagian biaya, yang berada di bawah rayls-contracts/src/. Periode eksekusi: 2 Maret hingga 13 Maret, 15 temuan, terdiri dari 1 kritis, 2 tinggi, 7 sedang, 2 rendah, 3 informatif/penunjuk. Ada 14 perbaikan, dan 1 penerimaan risiko tingkat sedang.
Jika dijumlahkan ada 42 temuan: 3 kritis, 4 tinggi, 17 sedang, 9 rendah, 9 informatif/penunjuk. Ada 39 perbaikan, dan 3 penerimaan risiko. Tiga temuan tingkat kritis semuanya sudah diselesaikan.
Saya mencantumkan angka-angka ini satu per satu karena bagi proses pengadaan, pertanyaan “sudah pernah melakukan audit atau belum” dan “audit apa, berapa lama, berapa banyak temuan, dan ada berapa yang tidak diperbaiki” adalah pertanyaan yang sepenuhnya berbeda. Pertanyaan pertama hampir semua proyek bisa menjawab “ya”. Yang kedua tidak banyak yang bisa menjawab, dan di sini setiap item bisa diverifikasi langsung—secara publik. Tiga temuan tingkat kritis semuanya sudah diperbaiki; itu adalah fakta positif yang benar-benar nyata.
Di README yang sama juga diungkap satu hal lagi
Bagian ini menurut saya adalah yang paling berguna bagi due diligence di seluruh tulisan ini.
README itu punya satu bagian khusus yang membahas persoalan pencatatan submit dan referensi pull request. Inti dari teks aslinya adalah: audit ini dilakukan untuk repositori privat sebelum dipublikasikan. Ketika proyek diopen-source-kan, riwayat repositori dikompresi menjadi satu initial commit. Karena itu, hash commit dan tautan pull request yang dikutip dalam laporan sebagai bukti perbaikan tidak dapat diparsing di repositori publik ini.
Rayls juga menjelaskan bahwa semua perbaikan yang diverifikasi oleh Halborn dimasukkan dalam initial commit repositori publik, dan waktu commit itu lebih lambat daripada window perbaikan ulang (re-review). PDF dipublikasikan apa adanya sesuai dengan yang dikeluarkan oleh Halborn, tanpa modifikasi.
Untuk sebuah institusi yang melakukan due diligence, ini adalah batasan yang spesifik dan nyata: laporan bisa dibaca dan tidak dimodifikasi, tetapi rantai bukti perbaikan yang ditunjukkan oleh laporan tidak bisa ditempuh di repositori publik. Anda bisa melihat Halborn mengatakan bahwa suatu masalah sudah diperbaiki, tetapi Anda tidak bisa menelusuri perubahan kode aktual dari perbaikan tersebut berdasarkan tautan yang mereka berikan.
Saya ingin menekankan bahwa ini bukan penyembunyian; justru sebaliknya—Rayls sendiri secara proaktif menuliskannya dengan jelas di README, sekaligus memberikan alasan dan penjelasan kompensasinya. Saya menuliskannya lagi hanya karena ini adalah pertanyaan pertama yang akan diajukan oleh tim keamanan, dan jawabannya sudah ada di sana; hanya saja ada di dokumen yang kebanyakan orang tidak akan membukanya.
Angka throughput itu, kondisinya juga terbuka
Untuk poin ini, saya sampaikan secara terpisah karena rangkuman komunitas bulan Agustus pernah menyorotnya: ada dua angka TPS yang beredar, dan orang-orang banyak mengutip yang nilainya lebih besar.
Saya sudah memeriksa tiga sumber secara menyeluruh. Dokumentasi resmi, saat membahas performa Sovereign, menuliskan Axyl mencapai 15.000+ TPS dengan finalitas di bawah satu detik (sub-detik). README repositori Axyl menuliskan target protokolnya 10.000+ TPS, dan kata yang dipakai adalah targets (target), bukan hasil pengukuran. Sedangkan kondisi itu ada di tempat ketiga: dokumen berjudul Axyl Performance Benchmarks. Di halaman itu tertulis jelas bahwa ini adalah uji benchmark baseline prototipe layer konsensus. Kondisi pencatatan: komite empat node, transaksi berukuran 512 byte, ukuran batch 500 KB, dan penundaan (batch delay) maksimum 50 milidetik. Selain itu, ada data konsensus untuk testnet yang diberikan secara terpisah.
Jadi formulasi lengkapnya seharusnya: baseline prototipe layer konsensus pada empat kondisi ini, bukan pengukuran produksi end-to-end. Perlu dijelaskan bahwa nilai spesifik di halaman itu diberikan dalam bentuk gambar; saya tidak bisa membaca angka di dalam gambar, tapi yang bisa saya pastikan adalah kondisi dasarnya.
Sekalian saya beri bukti sampingan yang saya jalankan sendiri. Pada 12 September, saya memanggil interface stats pada penjelajah blockchain publik; waktu rata-rata untuk penerbitan blok yang kembali adalah sekitar 500 milidetik. Ini konsisten dengan klaim skala “di bawah satu detik”, dan siapa pun yang memanggil interface yang sama bisa mengeceknya sendiri. Waktu penerbitan blok tidak sama dengan finalitas transaksi, tetapi minimal itu adalah nilai hasil pengukuran yang bisa diambil secara independen, bukan sekadar diteruskan.
Detail yang akan ditanyakan oleh departemen pengadaan, tapi jarang dibahas
Lisensi Axyl adalah BUSL-1.1, lisensi kode sumber komersial—bukan open source dalam pengertian biasanya.
Bagian lisensi repositori ditulis sangat spesifik: penggunaan produksi yang diizinkan adalah menjalankan node di mainnet publik Rayls dan testnet resmi, mencakup empat jenis: validator, observer, relayer, dan RPC. Penggunaan produksi lainnya memerlukan lisensi komersial. Setiap versi pertama kali dipublikasikan empat tahun setelah tanggal perubahan; pada saat itu akan beralih menjadi Apache 2.0.
Kalau dibaca berurutan, sebuah bank menjalankan Axyl di deployment Sovereign miliknya sendiri; itu termasuk penggunaan produksi lain.
Ini bukan kritik. Rayls sendiri pernah mengatakan bahwa platform inti dibuka sebagai open source, sedangkan Axyl dan Enygma adalah komponen komersial; BUSL ditambah empat tahun lalu beralih menjadi Apache—itu juga praktik yang sudah matang di industri. Saya menuliskannya saja karena kata “open source” sering dipakai seolah-olah bebas, sementara batasnya ditulis dengan jelas di berkas lisensi.
Dari mana kode berasal—repositori sendiri yang mengatakan
Bagian ucapan terima kasih di repositori Axyl ditulis secara jujur dan jarang—tampak. Bagian konsensus pada Rust workspace diturunkan dari Telcoin Network, dan Telcoin Network dibangun di atas Narwhal dan Bullshark di Sui. Rayls lalu melakukan restrukturisasi dan modifikasi besar-besaran berdasarkan fondasi ini. Implementasi Bullshark banyak menurunkan dari repositori kode Sui milik Mysten Labs, dengan dasar Apache 2.0. Layer eksekusi menggunakan reth dan alloy. Interface OFT LayerZero mempertahankan lisensi MIT yang asli.
Menuliskan silsilahnya dengan jelas lebih mudah dipercaya oleh tim engineering daripada mengklaim semuanya buatan sendiri, karena pihak yang melakukan audit bisa menelusuri kedewasaan upstream melalui jalur tersebut.
Yang mana yang baru, yang mana kelanjutan, dan yang tidak bisa saya verifikasi
Materi baru yang saya periksa minggu ini: seluruh isi README repositori Axyl, termasuk arsitektur, peran, konfigurasi, lisensi, dan ucapan terima kasih; tabel tiga laporan pada audits/README.md beserta penjelasan kompresi riwayat submit; gambaran umum sistem di doc/index.md; kondisi benchmark di halaman Axyl Performance Benchmarks; dan lima poin What changed serta dua tingkat konfigurasi deployment pada halaman Rayls Sovereign di dokumentasi resmi.
Melanjutkan tulisan sebelumnya: batas kunci pada Cryptographic Trust Suite, serta bahwa Relayer tidak memegang kunci—itu juga sudah saya verifikasi di kode sumber minggu lalu di dua repositori, relayer dan governance services. Bagian ini tidak menambah bukti baru.
Dugaan saya: nilai utama mengubah dari single node menjadi komite adalah ketahanan operasional, bukan throughput; keterbatasan bahwa rantai bukti perbaikan tidak bisa ditempuh di repositori publik adalah batasan nyata pada level due diligence; menuliskan silsilah kode dengan jelas adalah hal positif.
Tanda/sinyal. Di tiga materi itu tidak tertulis seperti itu.
Tidak bisa diverifikasi: saya tidak punya bukti bahwa ada institusi mana pun yang benar-benar menjalankan konfigurasi tersebut. Semua yang dibahas dalam artikel ini adalah kemampuan yang tercatat oleh dokumentasi dan kode.
Jalur replikasi: cari di GitHub raylsnetwork/axyl. Dua berkas di root—README dan audits/README.md—menutupi sebagian besar angka dalam artikel ini. Cari juga di dokumentasi resmi untuk halaman “Rayls Sovereign” dan “Axyl Performance Benchmarks”. Untuk waktu penerbitan blok, tinggal lihat /api/v2/stats pada penjelajah blockchain sidechain.
