Crypto · 3 min read · 6 views
Insiden Liquid Network 2026: Mengapa Cache Validasi Bisa Mengguncang Jaminan LBTC
Insiden Liquid 2026 menunjukkan bagaimana ambiguitas serialisasi pada cache validasi dapat merusak backing LBTC. Artikel ini membedah mekanisme bug, dampak cadangan, perbaikan Elements v23.3.4, dan langkah praktis bagi operator serta pengguna.
GD
I Gusti Agung Ganes Satsangga Dipa
Backend & Software Developer
# Insiden Liquid Network 2026: Mengapa Cache Validasi Bisa Mengguncang Jaminan LBTC
Pada September 2026, Liquid Network mengalami insiden keamanan yang menembus asumsi paling mendasar aset terbungkus: setiap LBTC seharusnya didukung bitcoin dalam cadangan. Laporan resmi Blockstream menyebut transaksi tak valid diterima node akibat kelemahan pada cache bukti kriptografis, lalu sekitar 4.000 LBTC tanpa jaminan tercipta dan diproses melalui jalur *peg-out*.
Kasus ini penting bukan hanya bagi pengguna Liquid. Ia menunjukkan bahwa kriptografi yang kuat tetap dapat gagal pada lapisan implementasi—terutama ketika optimasi performa seperti cache ikut menentukan apakah bukti perlu diverifikasi ulang.
## Apa yang sebenarnya gagal?
Liquid adalah sidechain Bitcoin yang memakai **confidential transactions**. Jumlah dan jenis aset dapat disamarkan, sementara *range proof* membuktikan secara kriptografis bahwa nilai keluaran masih berada dalam rentang sah. Agar node tidak menghitung bukti yang sama berulang kali, Elements—software yang menjalankan Liquid—menyimpan hasil pemeriksaan dalam cache.
Menurut penilaian insiden Blockstream, masalah muncul pada cara kunci cache dibentuk. Beberapa field, termasuk bukti, commitment aset, dan `scriptPubKey`, digabung sebagai rangkaian byte tanpa pemisah panjang yang tegas. Dua kumpulan input berbeda dapat menghasilkan susunan byte gabungan identik. Akibatnya, hasil “valid” milik satu bukti bisa dipakai kembali untuk transaksi lain yang sebenarnya tidak valid.
Ini bukan tabrakan fungsi hash klasik. Hash bekerja pada byte stream yang sama; kekeliruannya terjadi sebelum hashing, ketika batas antar-field menjadi ambigu. Dalam keamanan protokol, detail serialisasi seperti ini sama pentingnya dengan algoritma kriptografi itu sendiri.
## Dampak terhadap LBTC dan cadangan
Laporan resmi menyatakan exploit menginflasi suplai sekitar 4.000 LBTC tanpa bitcoin pendukung. LBTC tersebut kemudian masuk ke proses *peg-out*, yaitu mekanisme penukaran dari Liquid kembali ke Bitcoin. Penarikan sekitar 4.000 BTC dikonfirmasi di Bitcoin, dan peg-out lain yang berjalan membuat cadangan Liquid turun dari sekitar 4.205 BTC menjadi 197 BTC.
Blockstream menghentikan bridge node publik untuk membatasi kerusakan dan berkoordinasi agar deposit maupun penarikan LBTC dihentikan. Pelaku mengidentifikasi diri sebagai *whitehat* lewat pesan on-chain dan mengembalikan 3.400 BTC. Namun, dalam laporan bertanggal 23 September, sekitar 602 BTC masih disebut belum kembali dan proses pemulihan masih berlangsung.
Aset lain yang diterbitkan di Liquid, seperti USDt dan DePix, menurut laporan tidak terdampak secara nilai oleh exploit. Meski demikian, aset-aset tersebut sempat tidak dapat digunakan ketika jaringan dihentikan. Ini menegaskan bahwa risiko pengguna bukan hanya kehilangan langsung, tetapi juga hilangnya likuiditas dan akses ketika operator melakukan respons darurat.
## Perbaikan teknis dan pemulihan jaringan
Elements v23.3.4 dirilis pada 9 September 2026. Catatan rilis GitHub mengonfirmasi perubahan yang memperkuat kunci cache *range proof* serta menambahkan opsi `-norangeproofcache` untuk menonaktifkan cache.
Perbaikannya menggunakan serialisasi yang memberi penanda panjang eksplisit pada setiap field sebelum di-hash. Dengan demikian, dua tuple input berbeda tidak dapat lagi dibaca sebagai byte stream yang sama hanya karena batas komponennya bergeser. Blockstream juga memutar ulang chain tanpa cache untuk mengidentifikasi transaksi invalid dan turunannya, lalu menjalankan pemulihan bertahap.
Bagi operator node, tindakan praktisnya jelas:
- gunakan rilis Elements yang telah diperbaiki dan verifikasi checksum paket;
- jangan mengaktifkan kembali layanan sebelum status resmi pemulihan dinyatakan aman;
- pantau kesesuaian suplai LBTC dengan cadangan Bitcoin, bukan hanya status block production;
- pertimbangkan menonaktifkan cache saat investigasi atau validasi independen, dengan memahami konsekuensi performanya.
## Pelajaran untuk pengguna dan pengembang crypto
Pertama, label “federated sidechain” atau “didukung Bitcoin” tidak menghapus risiko software. Jaminan aset bergantung pada implementasi konsensus, proses peg, kontrol operasional federation, dan respons pihak yang memegang otorisasi peg-out.
Kedua, optimasi harus diperlakukan sebagai bagian dari permukaan konsensus. Cache validasi memerlukan pengujian terhadap input ambigu, serialisasi kanonik, perbedaan kondisi cache hangat dan dingin, serta *differential testing* dengan implementasi independen. Pengujian yang hanya memastikan transaksi normal lolos belum cukup.
Ketiga, pengguna sebaiknya memeriksa status jaringan dan bursa sebelum menyetor atau menarik LBTC. Jangan menganggap transaksi tertunda sebagai alasan untuk mengulang permintaan. Untuk treasury atau aplikasi, tetapkan batas eksposur, jalur penghentian otomatis, dan kebijakan likuiditas saat peg dinonaktifkan.
Insiden Liquid memperlihatkan rantai kegagalan yang konkret: ambigu dalam encoding memengaruhi cache, cache memengaruhi validasi, lalu validasi yang salah merusak backing aset. Patch teknis penting, tetapi transparansi cadangan, pemulihan dana, audit proses peg-out, dan pengujian lintas implementasi sama pentingnya untuk memulihkan kepercayaan.
Sumber utama: [Blockstream—Liquid Network Security Incident Assessment](https://blog.blockstream.com/liquid-network-security-incident-assessment/) dan [rilis resmi Elements v23.3.4](https://github.com/ElementsProject/elements/releases/tag/elements-23.3.4).
> **Disclaimer:** Artikel ini bersifat edukatif dan bukan nasihat keuangan atau rekomendasi investasi.
Tags: #Liquid Network#LBTC#Bitcoin sidechain#Elements#range proof#confidential transactions#blockchain security#incident response
GD
Tentang Penulis — Ganes Satsangga
Backend Developer berpengalaman membangun aplikasi web, sistem ERP/CMS, integrasi API, dan database menggunakan Laravel, PHP, dan Go.
