Open1

ブロックチェーンと暗号資産に関するセキュリティについてのレポートのメモ

YuheiNakasakaYuheiNakasaka

とりあえず手を動かすのは一旦気が済んだ。以降しばらくは腰を据えてレポートや本などを読んでいくことにする。

ブロックチェーンと暗号資産に関するセキュリティについてのレポートのメモ

リソース

やること

  • ブロックチェーンに関して交わされている議論を追う

メモ

  • 暗号資産関連のインシデントは暗号資産取引所から不正にユーザーの署名鍵が流出して発生することが一番多い。署名鍵をユーザーが個別で管理できていれば良いが現実的には無理があり、取引所が代わりに預かり管理していたりする。このため取引所がクラックされる可能性(=単一障害点)になってしまっている。
    • やはり被害額ではcoincheckが群を抜いている...
    • Image
  • ソフトウェアの脆弱性が存在すると発覚した時に「正しく行動するとあらかじめわかっている、全体のハッシュパワーの 51%以上のハッシュパワーをもつマイナー」を事前に特定することは難しい。強制的にチェーンの分岐を行う際のガバナンスは課題。
  • 攻撃
    • 51%攻撃
    • Finney Attack
    • Brute Force Attack
    • Selfish Mining Attack
    • Sybil Attack
  • Blockchainに基づく暗号資産システム全体におけるセキュリティ目標を達成するための 6 つのレイヤー
    • 暗号技術レイヤー
      • ハッシュ関数・電子署名
      • 米国連邦政府標準を定めるNIST が、量子計算機が存在しても安全な暗号アルゴリズムに関する標準化に向けたコンペティションを行っている。

    • バックボーンプロトコル
      • ブロックチェーンの分散合意アルゴリズムなどの安全性証明
      • 51%攻撃を防ぐインセンティブ設計=ゲーム理論サイドからの研究中である課題
      • P2Pネットワーク自体の脆弱性を突いて全体の参加者の50%を操作して二重支払いを可能にする問題
    • アプリケーションプロトコル
      • トランザクション処理やスケーラビリティに関わる問題
      • Layer2技術を使ったライトニングネットワークがSPOFになる可能性
        • トラフィックの偏りの問題があり、ビットコインと同等の信頼モデルを実現できない
      • トランザクションとそこで使われた暗号資産のプライバシ保護。お金に色なし vs マネーロンダリング対策
    • アプリケーションロジック
      • 決済・その他ビジネスロジック(=帳簿の書き換え)の設計
      • 主にSolidityによるスマートコントラクトのバグ(Reentracy Attackなど)が主なインシデントの原因
      • 形式検証で事前に攻撃可能な状態遷移を検知する
    • 実装レイヤー
    • 運用レイヤー
      • システム全体を人含めてどう運用・監視するか
      • 非中央集権的なコミュニティでポリシー等を規定するのが難しい問題がある
      • 現実には、暗号資産取引所のシステムは、それぞれの取引所が独自の実装をしており、共通のアーキテクチャや安全性が確認された実装が存在しないというのが現状である

  • トレードオフ
    • スケーラビリティとセキュリティのトレードオフ
      • スケーラビリティを向上させるためには、単純にはブロックサイズを増やせばよいが、ブロックサイズを増やすと各ノードで記録すべき情報量が増えるために、マイニングを行うフルノードの運営コストが増加する。その結果全体のハッシュパワーが減少し、パーミッションレス・ブロックチェーンにおける 51%攻撃の成功確率が上がる

  • 暗号技術レイヤーやバックボーンレイヤーはだいぶ研究が進んでいるが、スケーラビリティを得るためのLayer 2 技術やより広い応用のためのスマートコントラクトのセキュリティについてはまだ今後の研究が必要