ブロックチェーンの基礎クイズ
このクイズでは、コンセンサス、Merkle tree、ファイナリティ、運用上の特性について理解度を確認します。
多肢選択問題
- 障害モデルはどのように比較すべきですか？
- A) ブロックチェーンは分散型だが、etcdは単一ノードである
- B) 採用するコンセンサスを比較する。etcd/RaftはCFTであり、一部のブロックチェーンはBFTを使う一方、許可型のFabricもCFTのRaftを利用できる
- C) ブロックチェーンは強整合性を提供し、etcdは結果整合性を提供する
- D) etcdは暗号技術を使用しない
回答を表示
回答: B) 採用するコンセンサスを比較する。etcd/RaftはCFTであり、一部のブロックチェーンはBFTを使う一方、許可型のFabricもCFTのRaftを利用できる
解説: Fabric 3.xではSmartBFTも利用できます。参加者が許可制であることや「ブロックチェーン」という名称だけで、ビザンチン障害耐性があるとは限りません。
- フルノードのレプリカを追加しても、ベースチェーンの書き込み容量が自動的に増えないのはなぜですか？
- A) 暗号処理に時間がかかるため
- B) フルノードを複製してもベースチェーンの書き込み容量は自動的に増えないが、RPC読み取りはスケールできるため
- C) P2Pネットワークの帯域幅に制限があるため
- D) ブロックサイズに制限があるため
回答を表示
回答: B) フルノードを複製してもベースチェーンの書き込み容量は自動的に増えないが、RPC読み取りはスケールできるため
解説: フルノード、ライトクライアント、許可型ネットワークのデータ配布モデルにはそれぞれ違いがあります。すべてのノードが常にすべてのトランザクションを検証する、またはレプリカ数がどのようなスループットにも影響しない、といった説明は避けてください。
- Merkle treeがもたらす主な利点は何ですか？
- A) ブロックサイズを圧縮する
- B) トランザクション数をNとすると、Merkle包含証明はlog Nに比例して増えるため、チェーン全体を使わずに検証できる。これはライトクライアントの基礎となる
- C) トランザクションの順序を保証する
- D) コンセンサスを高速化する
回答を表示
回答: B) トランザクション数をNとすると、Merkle包含証明はlog Nに比例して増えるため、チェーン全体を使わずに検証できる。これはライトクライアントの基礎となる
解説: バイナリツリーでトランザクションをペアごとに上位へハッシュしていくため、あるトランザクションの包含を証明するには兄弟ノードのハッシュだけが必要です。トランザクションが100万件あるブロックでも、証明に必要なハッシュは約20個です。これによってライトクライアントが可能になり、ブロックチェーンを既存システムに統合する際の「フルノードを動かすべきか、ライト検証で十分か」という選択の基礎になります。
- コンセンサスでコスト（PoWの電力、PoSのステーク）が必要になる根本的な理由は何ですか？
- A) バリデーターに報酬を与えるため
- B) Sybil攻撃への防御。コストがなければ、1者が無制限にIDとブロック候補を作成してネットワークを停止させられるため
- C) ブロック生成速度を調整するため
- D) ネットワーク帯域幅を節約するため
回答を表示
回答: B) Sybil攻撃への防御。コストがなければ、1者が無制限にIDとブロック候補を作成してネットワークを停止させられるため
解説: 匿名参加が可能な環境では、IDだけでは1者が多数のIDを作成する攻撃（Sybil攻撃）を防げません。PoWでは計算コストを課し、PoSでは資本に加えてスラッシングのリスクを課します。BFT系では最初に参加者を制限するため、この問題を回避し、PoWの電力やPoSのステークなしに投票によるコンセンサスを実現できます。これが金融サービスでコンソーシアムチェーンを選択する技術的な根拠です。
- インフラ運用でファイナリティが最も重要な概念である理由は何ですか？
- A) コンセンサスの速度を決めるため
- B) ノードが返す最新データが未確定の場合があり、reorgが起きると回答が変わるため
- C) ブロックサイズを決めるため
- D) ノードのストレージ容量を決めるため
回答を表示
回答: B) ノードが返す最新データが未確定の場合があり、reorgが起きると回答が変わるため
解説: ノードは把握している最新チェーンに基づいて応答します。そのブロックが後でreorgされると、回答も変わります。これによって実際の障害が起きます。最新ブロックの入金を確定済みとして処理したところ、reorgで入金が消えることがあります。また、チェーンの高さが異なるノード間でロードバランサーが振り分けると、同じ問い合わせに異なる回答が返ることがあります。そのため、アプリケーションでは必要な確認深度を必須とし、インフラではreadinessチェックに同期状態を含め、チェーンの高さの差を監視してください。
- ブロックチェーンノードで永続ボリュームが必須なのはなぜですか？
- A) チェーンデータをネットワークから復元できないため
- B) 履歴を再生すれば状態を復元できるが、その再生には時間がかかり、その間ノードはリクエストを処理できないため
- C) KubernetesではStatefulSetに永続ボリュームが必要なため
- D) データディレクトリに鍵が保存されるため
回答を表示
回答: B) 履歴を再生すれば状態を復元できるが、その再生には時間がかかり、その間ノードはリクエストを処理できないため
解説: ノードの状態（残高、コントラクトストレージ）はブロック履歴の再生によって導出できるため、理論上は再構築できます。しかし、ジェネシスから検証と再生を行うフル同期にはチェーンの経過時間に応じた時間がかかります。数百GBから数TBのデータでは数日かかることもあります。Podの置き換えで状態を失うと、その間ノードはリクエストを処理できません。そのため永続ボリュームは任意ではなく必須です。
- ハードフォークに対応するクライアントのアップグレードは、どのように管理すべきですか？
- A) コンテナイメージのサイズが増える
- B) フォーク互換のクライアントを有効化より前にカナリア展開し、その後の互換性のないロールバックは別途評価する
- C) Podの再起動時間が長くなる
- D) ネットワークポリシーを書き換える必要がある
回答を表示
回答: B) フォーク互換のクライアントを有効化より前にカナリア展開し、その後の互換性のないロールバックは別途評価する
解説: プロトコルは決められた時点で有効化されますが、互換クライアントを早めに導入しても、現在のチェーンを離れることにはなりません。外部の期限までに、すべてのノードの準備を完了してください。
- ブロックチェーンの鍵管理は、既存システムのパスワード管理とどのような点で決定的に異なりますか？
- A) 鍵の方が長い
- B) 使用前に保管と復旧を計画する必要がある。秘密署名鍵を失うと取り返しがつかない場合があり、KMSの秘密鍵はエクスポートできない
- C) 鍵を定期的にローテーションする必要がある
- D) 鍵が平文で転送される
回答を表示
回答: B) 使用前に保管と復旧を計画する必要がある。秘密署名鍵を失うと取り返しがつかない場合があり、KMSの秘密鍵はエクスポートできない
解説: 復旧方法は鍵の生成元、コントラクトやアカウントの制御方法、バックアップ設計によって異なります。バリデーターのスラッシング履歴を保護し、マネージドHSMから秘密鍵を移行用にエクスポートできると思い込まないでください。