reorgとconfirmation：何ブロックで安全か
入金をクレジットするあらゆるバックエンドは一つの問いに答えねばならない：トランザクションはいつ行動に移せるほど確定したと言えるのか。ブロックを早すぎるタイミングで確定とみなせば、reorgが既にクレジットした入金を消し去りうる。待ちすぎればユーザーを苛立たせる。正しい答えはチェーンごとに異なる。
そもそもなぜreorgが起こるのか
ほぼ同じ高さで2つの有効なブロックが生成されると、ネットワークは一時的にtipについて意見が分かれる。より多くのブロックが積み上がった一方の分岐が勝ち、負けた分岐のトランザクションはmempoolに戻る。これは攻撃ではなく通常のコンセンサス挙動だ。1〜2ブロックの短いreorgはほとんどのチェーンで日常的に起こる。
finalityモデルは異なる
Bitcoinのようなproof-of-workチェーンは確率的finalityを持つ：confirmationが深いほど巻き戻りの確率は指数的に低下するが、決してちょうどゼロにはならない。Merge後のEthereumはおよそ2エポックごと（約13分）のcheckpointを通じて経済的finalityを加え、それ以降の巻き戻しにはstakeの3分の1のslashingが必要となる。L2はsequencerとsettlement層からそれぞれ独自のreorg面を継承する。一つの閾値がすべてに当てはまることはない。
実践的な閾値
一般的な本番設定：Bitcoinは価値に応じて3〜6 confirmation、Ethereumは12〜32ブロック（あるいはfinalizedタグを待つ）、高スループットのEVMチェーンはブロック時間が短いため比例してより多くのブロックを要する。高額なものにはすべて、生のブロック数ではなくfinalized/justifiedタグを基準にせよ。そうすればチェーン自身のfinality保証を継承できる。
バックエンドでreorgを検出する
高さだけでなく、クレジットの根拠としたブロックハッシュを追跡せよ。新しいheadごとに遡り、親ハッシュが記録したものと依然一致することを確認する。不一致はreorgを意味し、暫定クレジットを巻き戻して対処せねばならない。new headsを購読してハッシュを照合する方が、事後に二重クレジットをデバッグするより安上がりだ。
よくある質問
完全に安全になるためにただ長く待てばよいのでは？
長く待てばリスクは下がるが、確率的チェーンでは決してゼロには届かず、UXを損なう。存在する場合はチェーンのfinalityタグを使う方が、単にブロック数を増やすよりも優れたレバーだ。
L2はreorgするのか？
はい。中央集権的なsequencerは未確認トランザクションを並べ替えたり破棄したりでき、L2はそのsettlement層にも依存する。L2のfinalityはsequencerとL1 settlementの両方の関数として扱え。
関連記事
チャージして、キーを取得し、リリース。
セルフサーブ。暗号資産またはカードで支払い。クレジットで従量課金——重いプリミティブは高く、単純なものは安価。
APIキーを取得