Satu reorg blok Ethereum menyebabkan THORChain menghentikan pertukaran yang melibatkan 10 jaringan blockchain. Bagian yang mengejutkan? Semuanya berawal dari setoran 10 ETH yang sebenarnya tidak pernah sampai ke brankas. Berikut yang terjadi. 1️⃣ Setoran terdeteksi Seorang pengguna mengirimkan 10 ETH ke brankas THORChain. Transaksi muncul di sebuah blok Ethereum, dan THORChain mencatat setoran tersebut. 2️⃣ Reorg blok Ethereum Ethereum mengganti blok asli, menghapus setoran dari rantai kanonik. Namun, THORChain telah mencatat dana tersebut. 3️⃣ Pengembalian dana yang salah Pertukaran gagal memenuhi kondisi batas harga, sehingga memicu pengembalian dana. THORChain mengirimkan 10 ETH ke pengguna, meskipun brankasnya tidak pernah menerima setoran yang sesuai. 4️⃣ Penghentian darurat Pemeriksa solvabilitas THORChain mendeteksi kekurangan dana dan menghentikan pertukaran. Pengguna kemudian mengembalikan 10 ETH tambahan tersebut. Jadi, apa yang salah secara teknis? Masalah utama adalah perbedaan antara mengamati transaksi dan memiliki konfirmasi yang cukup bahwa transaksi tersebut akan tetap ada dalam sejarah kanonik Ethereum. Munculnya transaksi di sebuah blok tidak berarti blok tersebut tidak dapat di-reorganisasi. Di sinilah @ethlabs_org mengusulkan solusi menarik: Fast Confirmation Rule (FCR) Ethereum. Alih-alih hanya menunggu sejumlah blok sembarangan, FCR menganalisis attestasi validator Ethereum untuk menentukan apakah sebuah blok memiliki dukungan yang cukup. FCR dapat memberikan konfirmasi kuat dalam sekitar 15–30 detik, jauh lebih awal daripada finalitas konsensus penuh Ethereum. Namun, FCR bukan finalitas absolut. Jaminannya tetap bergantung pada asumsi jaringan dan validator. Perbedaan penting: • Transaksi teramati ≠ Transaksi difinalisasi • Konfirmasi blok ≠ Konfirmasi berbasis attestasi validator • Konfirmasi cepat ≠ Finalitas konsensus Untuk infrastruktur lintas-chain, menerima setoran hanyalah satu bagian dari proses. Memverifikasi bahwa transaksi di chain sumber cukup aman sebelum melepaskan dana sama pentingnya. Inilah yang membuat insiden ini menjadi contoh sangat berguna mengapa konfirmasi dan finalitas tidak boleh disamakan.