Reorg (Reorganisasi Chain)

Apa Itu Reorg dalam Kripto?

Reorg, singkatan dari Chain Reorganization, terjadi ketika node blockchain mengganti sebagian riwayat chain yang sedang digunakan dengan cabang chain valid yang berbeda.

Sederhananya, blockchain untuk sementara mengikuti satu jalur, lalu beralih ke jalur lain yang dianggap jaringan lebih baik atau kanonis.

Reorg dapat menghapus satu atau beberapa blok terbaru dari chain aktif dan menggantinya dengan blok berbeda.

Transaksi dalam blok yang dihapus dapat kembali ke mempool, kembali berstatus pending, dimasukkan ke blok berikutnya, atau menjadi tidak valid jika transaksi yang bertentangan dikonfirmasi di chain baru.

Reorg paling sering dibahas dalam chain proof-of-work, chain proof-of-stake, sistem Layer 2, bridge, wallet, pemroses pembayaran, dan platform trading yang harus menentukan kapan transaksi aman dianggap final.

Dokumentasi serangan dan pertahanan proof-of-stake Ethereum mendefinisikan reorg sebagai pengaturan ulang blok ke urutan baru, yang mungkin melibatkan penambahan atau penghapusan blok dari chain kanonis.

Dokumentasi developer Bitcoin menjelaskan bahwa konfirmasi mengukur jumlah blok yang perlu diubah untuk menghapus atau mengubah transaksi. Inilah alasan praktis pengguna menunggu sebelum menganggap pembayaran final.

Reorg tidak otomatis merupakan serangan, tetapi dapat menjadi berbahaya jika membalik transaksi penting, memungkinkan pengeluaran ganda, mengganggu aplikasi, atau memengaruhi sistem lintas blockchain.

Definisi Sederhana Reorg

Reorg adalah perubahan pada blok terbaru yang dianggap sebagai bagian dari chain utama oleh blockchain.

Blok terbaru yang lama menjadi stale, orphaned, atau nonkanonis, bergantung pada istilah yang digunakan jaringan tersebut.

Blok baru menjadi riwayat yang diterima dan harus diikuti node, wallet, explorer, serta aplikasi.

Hal ini dapat terjadi karena validator atau miner yang berbeda membuat blok tandingan pada ketinggian yang sama dalam waktu berdekatan.

Hal ini juga dapat terjadi karena latensi jaringan membuat sebagian node melihat satu blok lebih dahulu dan node lainnya melihat blok berbeda lebih dahulu.

Dalam kasus yang lebih serius, reorg dapat terjadi karena penyerang atau kelompok validator besar mencoba mengganti blok demi keuntungan atau sensor.

Dampak utamanya bagi pengguna adalah transaksi yang tampak sudah dikonfirmasi dapat kembali berstatus belum dikonfirmasi atau digantikan.

Karena itu, sistem kripto menggunakan konfirmasi, aturan finalitas, dan periode tunggu berdasarkan risiko.

Mengapa Reorg Penting?

Reorg penting karena blockchain digunakan untuk menentukan kepemilikan dan penyelesaian transaksi.

Jika pembayaran, swap, deposit bridge, mint, penarikan, atau likuidasi diterima terlalu cepat, reorg selanjutnya dapat menyebabkan kerugian atau kebingungan.

Merchant yang mengirim barang setelah satu konfirmasi yang belum kuat dapat menghadapi risiko jika pembayaran hilang akibat reorg.

Bridge yang melepaskan aset sebelum transaksi di chain sumber mencapai finalitas dapat menciptakan aset ganda atau tanpa dukungan jika transaksi sumber dihapus.

Protokol DeFi yang bertindak sebelum finalitas memadai dapat memproses status yang sudah tidak berlaku.

Wallet yang terlalu cepat menampilkan transaksi sebagai selesai dapat menyesatkan pengguna.

Dokumentasi finalitas dan konfirmasi blok Circle menjelaskan bahwa atestasi yang lebih cepat dapat membawa risiko reorg, sedangkan alur standar menunggu finalitas kuat ketika transaksi kemungkinan tidak akan dibalik oleh reorganisasi chain.

Karena itu, pemahaman tentang reorg merupakan bagian inti dari keamanan blockchain, terutama untuk transfer bernilai tinggi dan aplikasi lintas blockchain.

Bagaimana Reorg Terjadi?

Reorg dimulai ketika terdapat dua atau lebih cabang chain valid secara bersamaan.

Hal ini dapat terjadi secara alami karena blockchain merupakan sistem terdistribusi dan tidak semua node menerima blok baru pada saat yang persis sama.

Sekelompok node mungkin menerima Blok A lebih dahulu.

Sekelompok node lain mungkin menerima Blok B lebih dahulu.

Kedua blok mungkin valid, tetapi hanya satu cabang yang dapat menjadi jalur kanonis.

Aturan konsensus jaringan menentukan cabang mana yang menang.

Ketika sebuah node mengetahui bahwa cabang valid lain lebih kuat menurut aturan pemilihan fork jaringan, node tersebut beralih ke cabang itu.

Peralihan tersebut disebut reorganisasi chain.

Reorg vs. Fork

Fork adalah pemisahan riwayat blockchain yang membuat lebih dari satu cabang valid tersedia.

Reorg adalah proses beralih dari satu cabang ke cabang lain.

Tidak semua fork berkembang menjadi reorg besar.

Banyak fork singkat diselesaikan dengan cepat ketika jaringan memilih satu cabang dan meninggalkan cabang lainnya.

Hard fork berbeda karena mengubah aturan protokol dan dapat menciptakan pemisahan chain permanen jika komunitas terus mendukung kedua sisi.

Reorg biasa umumnya bersifat sementara dan terjadi di bawah aturan konsensus yang sama.

Pemisahan permanen menghasilkan dua jaringan yang terus beroperasi.

Reorg adalah koreksi jalur chain aktif dalam proses konsensus satu jaringan.

Reorg vs. Finalitas

Finalitas adalah kondisi ketika transaksi dianggap sangat sulit atau mustahil dibalik berdasarkan aturan jaringan.

Finalitas berupaya mencegah reorg atau membuatnya tidak layak secara ekonomi.

Dokumentasi proof-of-stake Ethereum menyatakan bahwa transaksi mencapai finalitas ketika menjadi bagian dari blok yang tidak dapat diubah tanpa membakar ETH dalam jumlah besar.

Dokumentasi yang sama menjelaskan bahwa membatalkan blok Ethereum yang telah mencapai finalitas akan mengharuskan penyerang kehilangan setidaknya sepertiga dari total ETH yang di-staking.

Bitcoin menggunakan finalitas probabilistik karena setiap blok tambahan membuat penggantian riwayat sebelumnya semakin sulit.

Solana menggunakan tingkat komitmen seperti processed, confirmed, dan finalized agar klien dapat memahami tingkat kepastian transaksi.

Pelajaran praktisnya adalah transaksi dapat masuk ke blok sebelum mencapai finalitas yang kuat.

Aplikasi harus menentukan tingkat finalitas yang dibutuhkan berdasarkan nilai, kecepatan, dan risiko.

Reorg vs. Orphan Block

Orphan block atau stale block adalah blok yang valid tetapi tidak bertahan di chain kanonis.

Reorg dapat menghasilkan stale block karena cabang lama tidak lagi menjadi chain aktif.

Istilah-istilah ini dapat digunakan dengan sedikit perbedaan oleh komunitas blockchain yang berbeda.

Dalam penggunaan sehari-hari di dunia kripto, pengguna sering mengatakan sebuah blok menjadi orphaned ketika digantikan cabang tandingan.

Hal pentingnya adalah transaksi di dalam blok tersebut mungkin perlu diproses ulang atau hilang dari riwayat yang terkonfirmasi.

Wallet dan blockchain explorer dapat memperbarui status transaksi setelah mendeteksi reorg.

Developer tidak boleh menganggap sebuah blok permanen hanya karena pernah terlihat.

Developer harus melacak konfirmasi dan status finalitas sebelum melakukan tindakan off-chain yang tidak dapat dibatalkan.

Reorg vs. Pengeluaran Ganda

Pengeluaran ganda adalah upaya menggunakan dana yang sama dalam dua transaksi yang saling bertentangan.

Reorg dapat memungkinkan pengeluaran ganda jika transaksi yang membayar satu pihak dihapus, lalu transaksi bertentangan yang membayar pihak lain dikonfirmasi di chain baru.

Dokumentasi pemrosesan pembayaran Bitcoin menjelaskan bahwa pembelanja berniat jahat dapat membuat satu transaksi untuk membayar penerima dan transaksi kedua yang menggunakan input sama untuk membayar dirinya sendiri. Hanya satu dari kedua transaksi itu yang dapat masuk ke blockchain.

Dokumentasi yang sama menjelaskan bahwa setelah transaksi masuk ke blok, penggantiannya mengharuskan perubahan pada riwayat blockchain, yang semakin sulit seiring bertambahnya konfirmasi.

Reorg tidak selalu berarti pengeluaran ganda, tetapi serangan pengeluaran ganda sering memerlukan reorg agar berhasil setelah transaksi pertama dikonfirmasi.

Karena itu, pembayaran bernilai tinggi biasanya memerlukan lebih banyak konfirmasi daripada pembayaran kecil.

Semakin dalam transaksi berada di bawah blok-blok berikutnya, semakin mahal biaya untuk menggantinya.

Kebijakan konfirmasi menjadi pertahanan terhadap pengeluaran ganda berbasis reorg.

Penyebab Umum Reorg

Penyebab umum pertama adalah latensi jaringan.

Ketika blok valid membutuhkan waktu untuk mencapai semua node, produsen blok lain mungkin membuat blok tandingan sebelum mengetahui adanya blok pertama.

Penyebab kedua adalah produksi blok secara bersamaan.

Dua miner atau validator dapat membuat blok valid pada waktu yang hampir sama.

Penyebab ketiga adalah perilaku validator atau miner.

Produsen blok dapat menahan, menunda, atau menerbitkan blok secara strategis sehingga meningkatkan risiko reorg.

Penyebab keempat adalah bug perangkat lunak atau klien.

Jika klien berbeda menafsirkan status secara keliru, mereka dapat sementara tidak sepakat mengenai chain yang benar.

Penyebab kelima adalah serangan berbahaya.

Penyerang mungkin mencoba mengatur ulang blok untuk melakukan pengeluaran ganda, menyensor transaksi, atau mengambil nilai.

Reorg Singkat

Reorg singkat biasanya mengganti satu atau sejumlah kecil blok terbaru.

Reorg singkat lebih umum daripada reorg mendalam karena blok terbaru belum memiliki banyak perlindungan.

Reorg ini dapat terjadi secara alami dalam kondisi jaringan normal.

Bagi banyak pengguna, reorg satu blok mungkin hanya mengubah status transaksi dari confirmed menjadi pending, lalu kembali confirmed setelahnya.

Bagi aplikasi berkecepatan tinggi, reorg singkat sekalipun dapat berdampak penting.

Aplikasi trading, bridge, oracle, bot likuidasi, atau pemroses pembayaran mungkin merespons blok yang sangat baru.

Jika blok tersebut diganti, aplikasi mungkin perlu membatalkan atau memperbaiki status internalnya.

Karena itu, infrastruktur harus dirancang untuk menangani reorg, bukan menganggapnya tidak akan pernah terjadi.

Reorg Mendalam

Reorg mendalam mengganti banyak blok.

Reorg ini jauh lebih serius karena dapat menghapus transaksi yang sudah dianggap tepercaya oleh pengguna.

Reorg mendalam dapat menandakan masalah jaringan besar, serangan, bug konsensus, kegagalan validator, atau pemisahan jaringan yang ekstrem.

Dalam sistem proof-of-work, reorg mendalam semakin mahal ketika lebih banyak proof-of-work dibangun di atas transaksi awal.

Dalam sistem proof-of-stake dengan finalitas ekonomi, reorg mendalam yang memengaruhi blok finalized mungkin memerlukan tindakan yang dapat dikenai slashing dan biaya ekonomi yang sangat besar.

Roadmap single-slot finality Ethereum menjelaskan bahwa jeda finalitas saat ini membuka peluang reorg singkat dan finalitas yang lebih cepat dapat mengurangi risiko ini.

Reorg mendalam jarang terjadi di jaringan yang matang, tetapi penting karena dampaknya dapat parah.

Setiap sistem yang menangani nilai besar harus bersiap menghadapi skenario reorg yang jarang terjadi tetapi berdampak tinggi.

Reorg di Jaringan Proof-of-Work

Dalam jaringan proof-of-work, node biasanya mengikuti chain valid dengan akumulasi kerja terbesar.

Jika muncul dua cabang valid, miner terus membangun cabang yang mereka anggap terbaik.

Cabang dengan akumulasi kerja lebih besar menjadi kanonis.

Node yang mengikuti cabang yang kalah akan beralih ke cabang yang menang melalui reorg.

Dokumentasi mode operasi Bitcoin menjelaskan bahwa full node memverifikasi blockchain dengan mengunduh dan memvalidasi blok. Untuk mengelabui full node, diperlukan riwayat blockchain alternatif dengan tingkat kesulitan yang lebih besar daripada chain yang sebenarnya.

Itulah sebabnya konfirmasi sangat penting dalam penyelesaian transaksi proof-of-work.

Setiap blok baru menambah kerja yang harus dilampaui penyerang.

Risiko reorg menurun seiring bertambahnya kedalaman blok.

Reorg di Jaringan Proof-of-Stake

Dalam jaringan proof-of-stake, perilaku reorg bergantung pada voting validator, aturan pemilihan fork, mekanisme finalitas, penalti, dan kondisi slashing.

Ethereum menggunakan aturan pemilihan fork bernama LMD-GHOST dan sistem finalitas yang didasarkan pada voting checkpoint.

Dokumentasi Ethereum menjelaskan bahwa validator memberikan atestasi terhadap blok yang mereka anggap sebagai head chain dan klien konsensus memilih fork dengan bobot atestasi terbesar.

Artinya, perbedaan pendapat dalam waktu singkat dapat terjadi sebelum finalitas tercapai.

Setelah finalitas tercapai, membalik blok finalized menjadi mahal secara ekonomi karena penyerang dapat kehilangan stake.

Karena itu, analisis reorg proof-of-stake berfokus pada bobot atestasi, status finalitas, partisipasi validator, latensi jaringan, dan risiko slashing.

Reorg proof-of-stake tidak dinilai hanya berdasarkan jumlah blok.

Penilaian juga harus mempertimbangkan apakah blok yang diganti sudah finalized, justified, confirmed, atau baru saja diusulkan.

Reorg dan Konfirmasi

Konfirmasi berarti transaksi telah dimasukkan ke blok dan blok tambahan mungkin telah dibangun di atasnya.

Di banyak chain, satu konfirmasi berarti transaksi berada di blok terbaru yang diterima.

Dua konfirmasi berarti satu blok tambahan telah dibangun di atas blok tersebut.

Semakin banyak konfirmasi biasanya berarti risiko reorg semakin rendah.

Dokumentasi developer Bitcoin menyebutkan bahwa enam konfirmasi umum digunakan untuk transaksi bernilai tinggi, tetapi juga mencatat bahwa jumlah tersebut relatif arbitrer dan didasarkan pada risiko.

Untuk pembayaran kecil, konfirmasi lebih sedikit mungkin dapat diterima.

Untuk deposit besar, bridge, atau pengiriman off-chain yang tidak dapat dibatalkan, konfirmasi lebih banyak mungkin diperlukan.

Kebijakan konfirmasi yang tepat bergantung pada keamanan jaringan, nilai transaksi, insentif serangan, dan toleransi risiko pengguna.

Reorg dan Blok Finalized

Blok finalized adalah blok yang dianggap sangat sulit dihapus oleh jaringan.

Finalitas lebih kuat daripada sekadar masuknya transaksi ke dalam blok.

Di Ethereum, finalitas berarti membalik blok akan mengharuskan penyerang menanggung penalti ekonomi yang berat.

Di Solana, dokumentasi status komitmen menjelaskan bahwa status finalized mensyaratkan 31 blok atau lebih yang telah dikonfirmasi dibangun di atas blok sasaran.

Dalam sistem bridge dan pembayaran, finalitas dapat ditentukan berdasarkan aturan chain sumber dan kebijakan risiko aplikasi.

Transaksi finalized biasanya jauh lebih aman daripada transaksi yang baru diproses atau dimasukkan ke blok.

Namun, model finalitas berbeda-beda di setiap blockchain.

Developer tidak boleh menerapkan aturan tunggu yang sama untuk semua jaringan tanpa memahami desain konsensus masing-masing.

Reorg dan Wallet

Wallet harus dirancang agar dapat menangani reorg dengan baik.

Wallet mungkin pertama-tama menampilkan transaksi sebagai pending.

Kemudian, wallet dapat menampilkan satu atau beberapa konfirmasi.

Jika reorg menghapus blok yang berisi transaksi, wallet harus memperbarui statusnya, bukan berpura-pura tidak ada perubahan.

Transaksi dapat kembali menjadi pending jika masih valid dan menunggu untuk dimasukkan lagi.

Transaksi dapat gagal jika transaksi yang bertentangan dikonfirmasi di chain baru.

Wallet sebaiknya tidak terlalu cepat menandai transaksi bernilai tinggi sebagai final.

Label status yang jelas membantu pengguna memahami perbedaan antara disiarkan, dimasukkan ke blok, dikonfirmasi, dan finalized.

Reorg dan Blockchain Explorer

Blockchain explorer melacak chain kanonis saat ini dan menampilkan status transaksi kepada pengguna.

Saat terjadi reorg, explorer dapat menghapus blok dari tampilan chain utama dan menampilkan blok penggantinya.

Halaman transaksi dapat berubah dari confirmed menjadi dropped, pending, failed, atau replaced, bergantung pada jaringan dan desain explorer.

Explorer yang berbeda dapat menampilkan kondisi sementara yang berbeda saat reorg berlangsung cepat karena menerima data jaringan pada waktu berbeda.

Pengguna sebaiknya tidak mengandalkan satu explorer saja untuk memastikan status konfirmasi penting saat kondisi jaringan tidak biasa.

Developer sebaiknya menggunakan infrastruktur node tepercaya dan pengindeksan yang memperhitungkan finalitas, bukan mengambil data dari halaman explorer untuk logika penyelesaian transaksi.

Indexer harus menyimpan riwayat yang cukup agar dapat membatalkan status yang terdampak setelah reorg.

Explorer adalah alat pemantauan yang berguna, tetapi chain kanonis milik node dan aturan finalitas merupakan sumber kebenaran.

Reorg dan Exchange

Platform trading dan layanan kustodian biasanya menunggu jumlah konfirmasi yang diwajibkan sebelum mengkreditkan deposit.

Tujuannya adalah mengurangi kemungkinan deposit hilang akibat reorg setelah platform mengkreditkannya kepada pengguna.

Tim risiko mungkin meminta lebih banyak konfirmasi untuk jaringan dengan hash power lebih rendah, keamanan stake lebih lemah, ketidakstabilan baru-baru ini, atau insentif serangan yang lebih tinggi.

Tim risiko mungkin meminta lebih sedikit konfirmasi untuk jaringan dengan finalitas deterministik yang lebih cepat.

Deposit dan penarikan juga dapat dihentikan sementara selama aktivitas reorg yang tidak normal.

Pengguna terkadang menganggap masa tunggu deposit hanya sebagai keterlambatan, padahal masa tunggu tersebut juga merupakan kontrol risiko.

Jika platform mengkreditkan deposit terlalu cepat lalu reorg menghapusnya, platform dapat mengalami kerugian.

Karena itu, kebijakan konfirmasi merupakan bagian dari manajemen risiko operasional.

Reorg dan Bridge

Bridge sangat sensitif terhadap reorg karena menghubungkan dua chain atau lebih.

Bridge dapat mengunci atau membakar aset di satu chain lalu melepaskan atau mencetak aset terkait di chain lain.

Jika transaksi di chain sumber dihapus melalui reorg setelah tindakan di chain tujuan dilakukan, bridge mungkin telah melepaskan nilai tanpa peristiwa sumber yang valid.

Hal ini dapat menciptakan aset yang tidak memiliki agunan memadai atau ketidaksesuaian akuntansi.

Sistem bridge mengurangi risiko ini dengan menunggu konfirmasi atau finalitas, menggunakan bukti fraud atau validitas, melacak pesan yang telah diproses, dan menetapkan batas risiko.

Panduan finalitas Circle menunjukkan bahwa sistem transfer lintas blockchain dapat menerapkan waktu tunggu berbeda untuk transfer cepat dan standar karena alur yang lebih cepat memiliki asumsi risiko reorg yang berbeda.

Pengguna harus memahami bahwa bridging yang lebih cepat mungkin mengorbankan tingkat keamanan finalitas atau meningkatkan risiko reorg.

Untuk transfer besar, menunggu finalitas yang lebih kuat biasanya lebih aman.

Reorg dan Jaringan Layer 2

Jaringan Layer 2 sering bergantung pada lapisan penyelesaian untuk ketersediaan data, finalitas, bukti fraud, bukti validitas, atau keamanan penarikan.

Transaksi Layer 2 mungkin tampak final di antarmuka Layer 2 sebelum batch terkait mencapai finalitas di lapisan penyelesaian.

Dokumentasi finalitas Circle mencatat bahwa beberapa sistem Layer 2 bergantung pada waktu batch dikirim ke Ethereum dan waktu blok Ethereum terkait mencapai finalitas.

Hal ini menciptakan dua lapisan finalitas yang perlu dipahami.

Mungkin terdapat konfirmasi lokal di Layer 2 dan finalitas di lapisan penyelesaian.

Untuk transaksi kecil biasa, konfirmasi lokal mungkin cukup.

Untuk transfer lintas blockchain, deposit besar, dan akuntansi protokol, finalitas lapisan penyelesaian mungkin diperlukan.

Pengguna tidak boleh menganggap semua konfirmasi Layer 2 memiliki risiko reorg yang sama.

Reorg dan MEV

MEV, atau maximal extractable value, adalah nilai yang dapat diperoleh produsen blok atau pihak yang mengatur urutan transaksi dengan memasukkan, mengecualikan, atau mengurutkan ulang transaksi.

Reorg dapat berkaitan dengan MEV jika penggantian blok memungkinkan pihak tertentu memperoleh peluang menguntungkan dari pengurutan transaksi.

Dokumentasi serangan dan pertahanan Ethereum menyatakan bahwa reorg berbahaya dapat memungkinkan ekstraksi nilai melalui transaksi front-running dan back-running.

Insentif untuk melakukan reorg singkat menjadi perhatian utama karena pelaku mungkin mencoba mengganti blok jika nilai yang diperoleh cukup besar.

Finalitas mengurangi risiko ini dengan membuat penggantian blok yang lebih dalam menjadi lebih mahal.

Aplikasi dapat mengurangi paparan dengan menunggu finalitas, menggunakan saluran transaksi privat jika sesuai, merancang mekanisme lelang yang lebih aman, dan memantau perilaku chain yang tidak biasa.

Risiko reorg terkait MEV paling penting untuk trading DeFi bernilai tinggi, likuidasi, arbitrase, pembaruan oracle, dan peristiwa bridge.

Pengguna harus memahami bahwa risiko reorg bukan hanya kecelakaan teknis, tetapi juga dapat didorong oleh insentif ekonomi.

Reorg dan Oracle

Oracle membawa data off-chain atau lintas blockchain ke dalam smart contract.

Jika oracle membaca data dari blok yang kemudian dihapus melalui reorg, data tersebut mungkin tidak lagi sesuai dengan riwayat chain kanonis.

Misalnya, oracle dapat melaporkan harga, saldo, deposit, atau peristiwa yang hanya ada di blok yang dihapus.

Sistem oracle yang baik memperhitungkan kedalaman konfirmasi dan finalitas sebelum menerbitkan data sensitif.

Protokol sebaiknya tidak mengandalkan peristiwa yang sangat baru jika reorg dapat menyebabkan kerugian serius.

Untuk oracle lintas blockchain, risiko reorg di chain sumber dapat memengaruhi kontrak di chain tujuan.

Oracle harus mencantumkan asumsi finalitas secara jelas dalam desainnya.

Smart contract yang menggunakan oracle harus memahami apakah data oracle bersifat langsung, sudah dikonfirmasi, atau telah mencapai finalitas.

Reorg dan Indexer

Indexer membaca data blockchain dan mengubahnya menjadi database yang dapat dicari untuk aplikasi, dashboard, wallet, alat analitik, dan API.

Reorg menjadi tantangan besar bagi indexer karena data yang telah diindeks mungkin perlu dibatalkan.

Jika indexer mencatat peristiwa dari blok yang kemudian menjadi stale, indexer harus menghapus atau memperbaiki peristiwa tersebut.

Jika gagal menangani reorg, indexer dapat menampilkan saldo, riwayat transaksi, kepemilikan NFT, data likuidasi, atau status bridge yang salah.

Indexer harus melacak hash blok, hash parent, nomor blok, status finalitas, dan kedalaman rollback.

Indexer sebaiknya tidak langsung menganggap blok baru sebagai permanen.

Untuk aplikasi bernilai tinggi, indexer sebaiknya menyediakan API yang memperhitungkan finalitas.

Indexer yang aman terhadap reorg merupakan infrastruktur penting bagi aplikasi kripto yang serius.

Reorg dan Smart Contract

Smart contract dieksekusi berdasarkan status chain kanonis.

Jika blok yang berisi pemanggilan smart contract dihapus melalui reorg, pemanggilan kontrak tersebut tidak lagi menjadi bagian dari riwayat kanonis.

Transaksi mungkin dimasukkan lagi kemudian, tetapi dapat dieksekusi secara berbeda jika status berubah di chain pengganti.

Hal ini penting untuk DeFi karena status dapat berubah dengan cepat.

Swap, likuidasi, pembaruan oracle, mint, atau klaim dapat bergantung pada status persis saat eksekusi.

Developer tidak boleh membangun sistem off-chain yang menganggap hasil transaksi final sebelum konfirmasi memadai.

Smart contract sendiri tidak akan mengingat riwayat blok yang dihapus kecuali riwayat tersebut merupakan bagian dari chain kanonis.

Layanan off-chain yang terhubung dengan smart contract harus memperhitungkan reorg.

Reorg dan Pemrosesan Pembayaran

Pemroses pembayaran harus menentukan kapan pembayaran kripto cukup aman untuk diterima.

Menerima pembayaran dengan nol konfirmasi memang cepat, tetapi berisiko.

Menerima pembayaran dengan satu konfirmasi mengurangi risiko, tetapi tidak menghilangkannya.

Menunggu lebih banyak konfirmasi mengurangi risiko reorg dan pengeluaran ganda, tetapi memperpanjang waktu tunggu pengguna.

Kebijakan yang tepat bergantung pada nilai pembayaran dan biaya penipuan.

Pembelian digital bernilai kecil mungkin dapat menerima risiko yang lebih besar daripada pengiriman barang fisik bernilai tinggi.

Penyelesaian bernilai tinggi biasanya harus menunggu konfirmasi atau finalitas yang lebih kuat.

Sistem pembayaran harus menampilkan kebijakan konfirmasi dengan jelas kepada pengguna dan merchant.

Reorg dan Status Transaksi

Transaksi dapat melalui beberapa status terkait reorg.

Transaksi dapat disiarkan tetapi belum dikonfirmasi.

Transaksi dapat dimasukkan ke dalam blok.

Transaksi dapat memperoleh konfirmasi.

Transaksi dapat dihapus dari chain kanonis selama reorg.

Transaksi dapat kembali menjadi pending jika masih valid.

Transaksi dapat dikonfirmasi kembali di blok pengganti.

Transaksi dapat digantikan secara permanen jika transaksi yang bertentangan dikonfirmasi.

Reorg dan Biaya Gas

Perilaku biaya gas saat reorg bergantung pada desain blockchain dan status kanonis akhir transaksi.

Jika transaksi masuk ke blok stale tetapi tidak masuk ke chain kanonis akhir, pengguna umumnya perlu mengetahui apakah transaksi tersebut akhirnya dieksekusi di chain yang diterima.

Jika transaksi kemudian dieksekusi di blok kanonis, pengguna membayar sesuai aturan chain tersebut.

Jika transaksi tidak dieksekusi dalam riwayat kanonis, eksekusi tersebut dianggap tidak diselesaikan di chain akhir.

Namun, tampilan wallet dan explorer dapat menunjukkan informasi biaya yang membingungkan sementara waktu selama reorg.

Developer harus melacak tanda terima kanonis, bukan pengamatan blok sementara.

Pengguna sebaiknya menunggu konfirmasi sebelum menganggap biaya dan status eksekusi sudah final.

Saat jaringan mengalami tekanan, reorg dan volatilitas biaya dapat membuat pelacakan transaksi terasa tidak konsisten.

Reorg dan Manajemen Risiko

Manajemen risiko reorg dimulai dengan kedalaman konfirmasi.

Semakin tinggi nilai transaksi, semakin kuat finalitas yang sebaiknya diwajibkan penerima.

Perangkat kedua adalah kebijakan khusus jaringan.

Setiap chain memiliki waktu blok, sistem finalitas, set validator, dan biaya serangan yang berbeda.

Perangkat ketiga adalah pemantauan.

Layanan harus mendeteksi kedalaman reorg yang tidak biasa, slot terlewat, gangguan validator, ketidakstabilan pemilihan fork, dan perbedaan antarexplorer.

Perangkat keempat adalah penyelesaian tertunda.

Bisnis sebaiknya menghindari tindakan off-chain yang tidak dapat dibatalkan hingga transaksi on-chain cukup aman.

Reorg dan Serangan 51%

Serangan 51% terjadi ketika penyerang menguasai cukup banyak daya mining atau pengaruh stake untuk memengaruhi riwayat kanonis chain.

Dalam sistem proof-of-work, penyerang dengan hash power memadai dapat mencoba membangun chain alternatif dan menerbitkannya untuk mengganti blok terbaru.

Dalam sistem proof-of-stake, penyerang dapat mencoba memengaruhi pemilihan fork, menunda finalitas, atau melakukan serangan yang lebih serius sehingga memicu penalti.

Dokumentasi Ethereum mencatat bahwa penyerang proof-of-stake dapat menargetkan reorg, finalitas ganda, atau penundaan finalitas.

Serangan reorg dapat digunakan untuk melakukan pengeluaran ganda atau menyensor transaksi.

Biaya dan kelayakannya bergantung pada model keamanan jaringan.

Jaringan matang umumnya lebih sulit diserang daripada jaringan kecil dengan keamanan mining atau staking yang lebih lemah.

Pengguna sebaiknya menunggu lebih banyak konfirmasi saat menggunakan jaringan dengan keamanan rendah.

Reorg dan Pemisahan Jaringan

Pemisahan jaringan terjadi ketika sebagian jaringan tidak dapat berkomunikasi secara normal dengan bagian lainnya.

Selama pemisahan, kelompok node yang berbeda dapat membangun cabang chain yang berbeda.

Ketika komunikasi membaik, jaringan dapat memilih satu cabang sebagai kanonis dan melakukan reorg dari cabang lainnya.

Pemisahan jaringan dapat disebabkan oleh gangguan perutean internet, masalah klien, serangan denial-of-service, atau gangguan infrastruktur.

Kedalaman reorg dapat bergantung pada lamanya pemisahan dan cara aturan konsensus menangani cabang yang bersaing.

Aplikasi harus memantau kesehatan jaringan, bukan hanya status transaksi individual.

Chain dapat terlihat normal dari satu node, sementara bagian jaringan lainnya melihat kondisi berbeda.

Menggunakan beberapa node tepercaya dapat membantu mendeteksi tampilan chain yang tidak konsisten.

Reorg dan Bug Klien

Bug klien dapat menyebabkan gangguan serupa reorg jika node tidak sepakat tentang blok yang valid.

Jika satu klien menerima blok yang ditolak klien lain, jaringan dapat terpecah hingga masalahnya diselesaikan.

Karena itu, keragaman klien, pengujian, audit, dan koordinasi upgrade sangat penting.

Pemisahan chain akibat bug dapat lebih berbahaya daripada reorg satu blok biasa karena dapat memengaruhi konsensus itu sendiri.

Aplikasi harus memantau pemberitahuan resmi dari klien selama terjadi perilaku tidak biasa.

Operator node harus memperbarui perangkat lunak, tetapi juga memahami instruksi upgrade sebelum rilis besar.

Keragaman klien dapat mengurangi kemungkinan satu bug perangkat lunak merugikan seluruh jaringan.

Dengan demikian, risiko reorg juga berkaitan dengan kualitas perangkat lunak, bukan hanya perilaku miner atau validator.

Reorg dan Rollback

Rollback adalah istilah yang lebih luas untuk mengembalikan status ke titik sebelumnya.

Reorg adalah rollback khusus blockchain yang terjadi akibat peralihan ke cabang chain berbeda.

Aplikasi mungkin perlu melakukan rollback internal setelah reorg.

Misalnya, sistem akuntansi mungkin perlu menghapus kredit deposit jika transaksi deposit dihapus melalui reorg.

Game mungkin perlu menghapus mint item jika transaksi mint tersebut hilang.

Bridge mungkin perlu menunggu lebih lama daripada melakukan rollback setelah melepaskan aset di chain tujuan.

Desain aplikasi yang aman terhadap reorg sering kali berkaitan dengan keputusan kapan rollback dapat diterima dan kapan menunggu lebih aman.

Sistem yang tidak dapat menoleransi rollback harus menunggu finalitas kuat sebelum bertindak.

Reorg dan Keamanan Pengguna

Pengguna dapat mengurangi risiko reorg dengan menunggu konfirmasi sebelum menganggap transaksi final.

Untuk pembayaran bernilai tinggi, pengguna sebaiknya tidak mengirim barang, memberikan layanan, atau mengambil keputusan yang tidak dapat dibatalkan hanya berdasarkan konfirmasi yang sangat baru.

Pengguna harus memahami bahwa setiap chain memiliki standar konfirmasi yang berbeda.

Berhati-hatilah selama fork, gangguan layanan, serangan, peristiwa bridge, dan kondisi jaringan yang tidak normal.

Gunakan wallet dan layanan yang menampilkan status konfirmasi dengan jelas.

Jangan panik jika transaksi yang baru dikonfirmasi kembali menjadi pending setelah reorg singkat.

Dalam banyak kasus, transaksi dapat dimasukkan kembali.

Jika transaksi bertentangan atau hilang, pengguna sebaiknya memeriksa explorer tepercaya, halaman dukungan wallet, atau node sendiri jika memungkinkan.

Reorg dan Keamanan Developer

Developer harus berasumsi bahwa reorg dapat terjadi.

Jangan memproses peristiwa penting setelah melihat satu blok baru saja dibuat, kecuali kasus penggunaan dapat menoleransi pembalikan.

Simpan hash blok dan hash parent, bukan hanya nomor blok.

Sistem harus dapat mendeteksi ketika blok yang sebelumnya diproses tidak lagi kanonis.

Terapkan logika rollback untuk peristiwa yang diindeks.

Tentukan ambang konfirmasi untuk setiap chain dan tingkat nilai transaksi.

Perlakukan finalitas secara berbeda dari sekadar masuknya transaksi ke dalam blok.

Uji sistem di jaringan pengembangan yang dapat mensimulasikan reorg.

Manfaat Memahami Reorg

Manfaat pertama adalah penerimaan pembayaran yang lebih aman.

Manfaat kedua adalah desain bridge yang lebih baik.

Manfaat ketiga adalah tampilan status wallet yang lebih akurat.

Manfaat keempat adalah keandalan indexer dan aplikasi yang lebih tinggi.

Manfaat kelima adalah manajemen risiko yang lebih baik untuk deposit dan penarikan trading.

Manfaat keenam adalah pemahaman yang lebih jelas tentang konfirmasi dan finalitas.

Manfaat ketujuh adalah perlindungan yang lebih baik terhadap upaya pengeluaran ganda.

Pemahaman tentang reorg membantu pengguna menyadari bahwa penyelesaian blockchain adalah sebuah proses, bukan satu momen saja.

Keterbatasan Perlindungan terhadap Reorg

Konfirmasi mengurangi risiko reorg, tetapi tidak menghilangkan semua kemungkinan serangan.

Finalitas semakin mengurangi risiko reorg, tetapi model finalitas berbeda di setiap jaringan.

Jaringan kecil tetap dapat menghadapi risiko reorg mendalam jika keamanannya lemah.

Bridge tetap dapat gagal jika salah memahami finalitas chain sumber.

Wallet tetap dapat menyesatkan pengguna jika menampilkan status dengan buruk.

Smart contract tetap dapat memiliki bug lain meskipun chain itu sendiri stabil.

Perlindungan terhadap reorg hanyalah satu lapisan keamanan, bukan sistem keamanan yang lengkap.

Pengguna dan developer harus menggabungkannya dengan keamanan kustodi, peninjauan smart contract, keamanan oracle, dan kontrol operasional.

Kesalahpahaman Umum tentang Reorg

Kesalahpahaman umum adalah transaksi menjadi final segera setelah muncul di blok.

Padahal, transaksi yang baru dimasukkan ke blok masih dapat terdampak reorg singkat.

Kesalahpahaman lainnya adalah semua reorg merupakan serangan.

Banyak reorg singkat dapat terjadi secara alami karena latensi jaringan dan adanya blok valid yang bersaing.

Kesalahpahaman lainnya adalah semua chain memerlukan jumlah konfirmasi yang sama.

Persyaratan konfirmasi bergantung pada model keamanan chain, aturan finalitas, nilai yang ditransfer, dan toleransi risiko.

Kesalahpahaman lainnya adalah finalitas memiliki arti yang sama di semua jaringan.

Jaringan yang berbeda menggunakan model finalitas yang berbeda, sehingga pengguna harus memeriksa chain yang digunakan.

Tanda Bahaya Reorg

Salah satu tanda bahaya adalah layanan yang mengkreditkan deposit besar tanpa kebijakan konfirmasi.

Tanda bahaya lainnya adalah bridge yang melepaskan aset sebelum finalitas chain sumber jelas.

Tanda bahaya lainnya adalah wallet yang langsung memberi label final pada transaksi setelah disiarkan.

Tanda bahaya lainnya adalah indexer yang hanya menyimpan nomor blok, bukan hash blok.

Tanda bahaya lainnya adalah pemroses pembayaran yang tidak dapat menangani transaksi yang kembali berstatus belum dikonfirmasi.

Tanda bahaya lainnya adalah aktivitas reorg berulang yang tidak biasa di jaringan yang biasanya memiliki finalitas stabil.

Tanda bahaya lainnya adalah chain proof-of-work kecil dengan hash power rendah yang menerima deposit bernilai tinggi setelah terlalu sedikit konfirmasi.

Tanda bahaya lainnya adalah dApp yang merespons blok yang sangat baru tanpa menjelaskan asumsi finalitasnya.

Praktik Terbaik bagi Pengguna

Tunggu lebih banyak konfirmasi saat menerima pembayaran bernilai tinggi.

Gunakan layanan yang menampilkan status pending, confirmed, dan finalized dengan jelas.

Berhati-hatilah selama fork, gangguan layanan, atau aktivitas jaringan yang tidak normal.

Jangan menyerahkan barang atau layanan bernilai tinggi hanya berdasarkan transaksi tanpa konfirmasi.

Pahami bahwa setiap jaringan memiliki model finalitas dan konfirmasi yang berbeda.

Gunakan wallet dan explorer tepercaya untuk melacak transaksi.

Untuk transfer lintas blockchain, pilih opsi finalitas yang lebih lambat jika keamanan lebih penting daripada kecepatan.

Jangan menganggap transaksi tidak dapat dibatalkan sampai mencapai standar konfirmasi atau finalitas yang sesuai untuk chain tersebut.

Praktik Terbaik bagi Developer

Lacak hash blok, hash parent, nomor blok, hash transaksi, dan status finalitas.

Rancang indexer dan database dengan dukungan rollback.

Gunakan ambang konfirmasi khusus untuk setiap chain.

Tunggu finalitas yang lebih kuat sebelum memicu tindakan off-chain yang tidak dapat dibatalkan.

Tampilkan status konfirmasi dengan jelas di antarmuka pengguna.

Gunakan beberapa node atau penyedia tepercaya untuk mendeteksi tampilan chain yang tidak konsisten.

Uji perilaku aplikasi dalam kondisi reorg simulasi.

Dokumentasikan asumsi finalitas bagi pengguna, auditor, dan mitra integrasi.

Mengapa Reorg Penting untuk AEO dan Search Intent?

Orang mencari Reorg untuk mengetahui mengapa status transaksi kripto yang sudah dikonfirmasi terkadang dapat berubah.

Jawaban langsungnya adalah reorg terjadi ketika jaringan mengganti blok terbaru dengan cabang chain valid yang berbeda.

Orang juga mencari Reorg untuk mengetahui apakah dana mereka hilang.

Jawaban praktisnya adalah transaksi yang terdampak reorg dapat kembali menjadi pending, dimasukkan lagi kemudian, atau digantikan transaksi yang bertentangan, bergantung pada situasinya.

Orang mungkin juga mencari Reorg untuk mengetahui jumlah konfirmasi yang cukup.

Jawaban yang berguna adalah kebutuhan konfirmasi bergantung pada blockchain, nilai transaksi, model finalitas, dan toleransi risiko.

Pelajaran utama bagi pengguna kripto sederhana.

Reorg merupakan kemungkinan normal dalam konsensus terdesentralisasi, dan sistem yang aman menunggu konfirmasi atau finalitas yang memadai sebelum menganggap transaksi tidak dapat dibatalkan.

FAQ

Apa Itu Reorg?

Reorg adalah reorganisasi chain ketika node blockchain mengganti sebagian chain yang saat ini diterima dengan cabang chain valid yang berbeda.

Apa Arti Chain Reorganization?

Chain Reorganization berarti riwayat kanonis blockchain berubah untuk blok-blok terbaru karena cabang lain menjadi chain yang diterima.

Bisakah Reorg Menghapus Transaksi Saya?

Ya. Reorg dapat menghapus transaksi dari blok yang baru diterima, meskipun transaksi itu mungkin dimasukkan lagi kemudian jika masih valid.

Apakah Reorg Selalu Merupakan Serangan?

Tidak. Reorg singkat dapat terjadi secara alami akibat latensi jaringan atau produksi blok secara bersamaan, tetapi reorg berbahaya juga dapat terjadi.

Apa Itu Reorg Satu Blok?

Reorg satu blok terjadi ketika jaringan mengganti blok kanonis terbaru dengan blok valid lainnya.

Apa Itu Reorg Mendalam?

Reorg mendalam mengganti banyak blok dan lebih serius karena dapat memengaruhi transaksi yang mungkin sudah dianggap tepercaya oleh pengguna.

Mengapa Konfirmasi Mengurangi Risiko Reorg?

Setiap konfirmasi menambahkan blok lain di atas transaksi sehingga blok transaksi tersebut semakin sulit atau mahal untuk diganti.

Berapa Banyak Konfirmasi yang Cukup?

Jumlah yang diperlukan bergantung pada chain, nilai transaksi, model finalitas, dan toleransi risiko.

Bisakah Blok Finalized Mengalami Reorg?

Di jaringan dengan finalitas ekonomi atau deterministik, reorg terhadap blok finalized dirancang agar sangat mahal atau secara praktis mustahil dalam asumsi normal.

Bagaimana Reorg Memengaruhi Bridge?

Bridge dapat kehilangan dukungan aset atau melepaskan aset secara keliru jika bertindak berdasarkan transaksi chain sumber yang kemudian dihapus oleh reorg.

Bagaimana Reorg Memengaruhi Wallet?

Wallet dapat mengubah status transaksi dari confirmed kembali menjadi pending atau dropped jika blok yang memuatnya dihapus melalui reorg.

Bagaimana Developer Menangani Reorg?

Developer menangani reorg dengan melacak hash blok, menunggu konfirmasi, mendukung rollback, dan menggunakan aturan finalitas khusus chain.

Apa Kesalahan Terbesar terkait Reorg?

Kesalahan terbesar adalah menganggap transaksi yang baru dimasukkan ke blok tidak dapat dibatalkan sebelum mencapai tingkat konfirmasi atau finalitas yang tepat.

Kesimpulan

Reorg, atau Chain Reorganization, adalah peristiwa blockchain ketika blok terbaru yang diterima diganti dengan cabang chain valid lainnya.

Reorg dapat terjadi secara alami karena jaringan terdesentralisasi memerlukan waktu untuk menyepakati blok baru.

Reorg juga dapat terjadi akibat serangan, perilaku validator, pemisahan jaringan, bug perangkat lunak, atau insentif ekonomi seperti MEV.

Dampak praktisnya adalah transaksi yang tampak telah dikonfirmasi dapat kembali menjadi pending, dihapus, atau diganti.

Karena itu, konfirmasi dan finalitas merupakan unsur penting dalam penyelesaian transaksi kripto.

Sistem bergaya Bitcoin sangat mengandalkan bertambahnya kedalaman konfirmasi, sedangkan sistem proof-of-stake bergaya Ethereum menggabungkan pemilihan fork dengan finalitas ekonomi.

Wallet, bridge, pemroses pembayaran, indexer, exchange, dan protokol DeFi semuanya memerlukan desain yang memperhitungkan reorg.

Intinya sederhana: reorg merupakan bagian dari konsensus terdesentralisasi, sehingga pengguna dan developer harus menunggu konfirmasi atau finalitas yang memadai sebelum menganggap transaksi kripto tidak dapat dibatalkan.