[論文レビュー] F3B: A Low-Overhead Blockchain Architecture with Per-Transaction Front-Running Protection

Haoqian Zhang, Louis-Henri Merino+4 more|arXiv (Cornell University)|May 17, 2022

Blockchain Technology Applications and Security被引用数 5

ひとこと要約

F3B は、最終確定後にのみ鍵を復号できる閾値暗号を用いて取引を暗号化することで、1件あたりの前もっての取引（front-running）を防ぐ低コストのブロックチェーンアーキテクチャである。Ethereum上で0.026%の遅延オーバーヘッドで実現しており、コンSENSUS やスマートコントラクトを変更せずに、未確定取引のプライバシーを強固に保証する。

ABSTRACT

Front-running attacks, which benefit from advanced knowledge of pending transactions, have proliferated in the blockchain space since the emergence of decentralized finance. Front-running causes devastating losses to honest participants and continues to endanger the fairness of the ecosystem. We present Flash Freezing Flash Boys (F3B), a blockchain architecture that addresses front-running attacks by using threshold cryptography. In F3B, a user generates a symmetric key to encrypt their transaction, and once the underlying consensus layer has finalized the transaction, a decentralized secret-management committee reveals this key. F3B mitigates front-running attacks because, before the consensus group finalizes it, an adversary can no longer read the content of a transaction, thus preventing the adversary from benefiting from advanced knowledge of pending transactions. Unlike other mitigation systems, F3B properly ensures that all unfinalized transactions, even with significant delays, remain private by adopting per-transaction protection. Furthermore, F3B addresses front-running at the execution layer; thus, our solution is agnostic to the underlying consensus algorithm and compatible with existing smart contracts. We evaluated F3B on Ethereum with a modified execution layer and found only a negligible (0.026%) increase in transaction latency, specifically due to running threshold decryption with a 128-member secret-management committee after a transaction is finalized; this indicates that F3B is both practical and low-cost.

研究の動機と目的

• DeFiにおける前もっての取引の増加する脅威が公平性を損ない、顕著な財務的損失をもたらすという問題に対処すること。
• 既存のコンSENSUS アルゴリズムやスマートコントラクトを変更せずに、1件あたりの前もっての取引保護を提供するブロックチェーンアーキテクチャを設計すること。
• ネットワーク遅延が生じても、未確定取引のすべてに対して強固なプライバシー保証を維持しつつ、遅延オーバーヘッドを最小限に抑えること。
• Ethereumの実行レイヤーと統合し、効率的な閾値暗号を用いることで、実用的な展開を可能にすること。

提案手法

• ユーザーが取引を秘密管理委員会（SMC）の秘密鍵で暗号化した後、ブロックチェーンに送信する1件あたりの対称暗号化を採用する。
• コンSENSUSグループによる最終確定後にのみ、SMCが鍵の一部を公開する閾値復号プロトコルを導入する。
• キー管理の柔軟性と事前処理コストのトレードオフを提供する2つの暗号方式（TDH2 および PVSS）を採用する。
• ブロックチェーン上での暗号化取引のスパムを防ぐために、預け金返還型のストレージ手数料を導入する。
• 遅延実行および復号をサポートする新しい取引タイプを実行レイヤーに追加する。
• 復号鍵をブロックチェーンのメタデータとして保存することで、コンSENSUSノードの可用性と整合性を保証する。

実験結果

リサーチクエスチョン

• RQ1 コンSENSUSアルゴリズムやスマートコントラクトを変更せずに、実行レイヤーで前もっての取引を緩和できるか？
• RQ2 閾値復号による1件あたりのプライバシーを実現するための最小限の遅延オーバーヘッドは何か？
• RQ3 取引が遅延したり、即座に確定されない場合でも、取引機密性をどのように維持できるか？
• RQ4 最終確定後にのみ鍵を公開する秘密管理委員会を、安全かつ効率的に調整できるか？
• RQ5 既存の「コミット・アンド・リーベール」または1ブロックあたりの暗号化方式と比較して、提案されたシステムのパフォーマンスとセキュリティはどの程度か？

主な発見

• TDH2方式を用い、128名の秘密管理委員会を用いるF3Bは、Ethereum上で0.026%の遅延オーバーヘッドを達成している。
• PVSSベースのバージョンは0.027%の遅延オーバーヘッドを示し、取引量にかかわらずほぼ一定のパフォーマンスを発揮している。
• F3Bは、PoS、PoA、PoWを含む既存のコンSENSUSメカニズムと完全に互換性がある。
• ネットワーク遅延が生じても、取引が最終確定されるまで機密性が保たれるため、前もっての取引が防止される。
• F3Bは、3回のブロックチェーン通信が必要なSubmarineよりも優れており、200%の遅延オーバーヘッドを回避している。
• 1件あたりの取引でブロックチェーンへの書き込みを1回のみ行うため、ストレージおよび遅延コストを最小限に抑える。