ホワイトペーパー

Liquidホワイトペーパー日本語訳9

更新日:

本稿について

BlockStream開発のLiquid(Strong Federations)のホワイトペーパー、最終更新日: 2017/1/6時点のものを対象とします。本稿では「VI. Evaluation」の「A. Comparison to existing solutions」と「B. Protection Mechanisms」の日本語訳を掲載します。

原文はこちらになります。

スポンサードサーチ

6. 評価

Strong Federationを通過する情報は非常にセンシティブなものになるだろう。結果として潜在的なセキュリティ脅威の徹底的な理解が非常に重要である。これは特にトランザクションの取り消しができないBitcoinに対応する際に重要だ。言い換えればネットワーク継続運営は二次的な優先度なのだ。自分の手元に遅れて戻ってくるのに対して高速に送金するのに泥棒に渡すことを選ぶ人はほぼいないだろう。Strong Federation内のアセットの合計価値が増えるにつれて攻撃者のインセンティブも増えるので、あらゆるファンクショナリーだけでなくコードベースの保守管理者を標的とする場合でも攻撃が成功できないようにすることが重要になる。ありがたいことにStrong Federationの参加者はシステムを流れるアセットの価値をスケールアップさせるので、支配下にある連合署名者へのアクセスを管理するインセンティブが自然と与えられる。従って、連合セキュリティモデルは参加者の利益ときちんと合致する。

A. 既存ソリューションとの比較

Bitcoinライクなシステムのコンセンサスを形成しようとする既存の提案は2つのカテゴリに分類できる。効率性やスループットを改善しながらもBitcoinの非中央集権性を保持しようとするものと、全く異なる信頼モデルを採用するものである。一つ目のカテゴリにあたるものはGHOST[49]やブロックDAG[50][51]、Jute[52]である。これらのスキームはBitcoinの匿名マイナーの動的セットによりブロック生成のモデルを引き継ぎ、コンセンサスが非中央集権的な方法で維持されることを確約するために複雑かつ微妙なゲーム理論の仮定に基づいている。二つ目のカテゴリにはStellar[53]やTendermint[54]などがあり、これらは新規参加者が信用する既存参加者を選ぶ必要がある。これらの事例はパーティの信頼に関連する故障リスクがあり、複雑なネットワークトポロジーに広まると深刻かつ分析困難な故障モードを引き起こす[55]。

相互に信頼しないが特定可能なパーティの固定のセットの文脈での私たちの提案は、それゆえに単純な信頼モデルをサポートする。つまり、一定数の参加者が誠実にふるまう限り、システムは動き続けるというものだ。

コンセンサスシステムと並列なシステムは、高速化す安価なトランザクション実行を得るために既存のコンセンサスシステムの利用を模索するシステムだ。この主な例がLightning Network[56]で、ここではパーティが単独で互いにインタラクションすることで取引ができ、基盤のブロックチェーンに戻るのはセットアップの間か片方がプロトコルに従わなかった場合だけである。これらのシステムは既存ブロックチェーン上で動いており、本文で述べたものも含めて新たなコンセンサスシステムを補完することから注目している。

非常に新しく際笑めて興味深いが提案が最近Eyalらによりなされた[57]。まだ市場で利用することはできないが、EyalらのBitcoin-NGのスキームはスケーリングのために設計された新しいブロックチェーンプロトコルである。彼らが行った実験に基づくと、Bitcoin-NGは各ノードのキャパシティにより制限される帯域幅とネットワークの伝搬時間により制限されるレイテンシ下で、最適にスケーリングするソリューションのようだ。

B. 防御メカニズム

攻撃者がシステムに攻撃するにはまずそのシステムと通信しなければならない。従って、Strong Federationの通信ポリシーはありふれた攻撃ベクトルから隔てられるように設計されている。信頼の置けないパーティがファンクショナリーと通信するのを防ぐために、いくつかの異なる手法が採用されている。

  • ファンクショナリーの通信は、既知のピアファンクショナリーに対応することが分かっているハードコードされたTor秘匿サービス(Tor Hidden Service)アドレスに限られる。
  • ファンクショナリー間のトラフィックはハードコードされた公開鍵とファンクショナリーごとの署名鍵を使って認証される。
  • RPC(Remote Procedure Calls, 遠隔手続き呼び出し)は、ファンクショナリーのハードウェアとローカルシステム上の呼び出し元のLiquidウォレットデプロイメントに限られる。

上記に加えてさらに鍵ポリシーがネットワーク保護に機能する。ブロック署名者はどんな状況でも復元不可能な秘密鍵で設計されるが、警備員は鍵復元プロセスを念頭において作成されなければならない。ブロック署名者の鍵の喪失はStrong Federationのコンセンサスプロトコルのハードフォークが必須だろう。これは困難ではあるが不可能ではなく、資金喪失のリスクにもならない。しかし、十分な数の警備員の鍵が失われるとbitcoinが失われるのであってはならない。

Strong Federationの設計はビザンチンロバストであるが、ファンクショナリーがセキュリティ侵害を避けるのは非常に重要であることに変わりはない。ファンクショナリーに対する攻撃を検知するよう設計された不正発見センサーがあるとして、攻撃が進行中であることが明らかであれば、ネットワーク内の他のファンクショナリーに完全性をもはや担保できないということを知らせることが重要だ。この場合、取りうる手段は各人のシステムをシャットダウンすることで、最悪のシナリオの場合、つまりネットワークのビザンチンロバスト性が脅かされる場合は、ネットワーク自体をシャットダウンすべきである。これにより、ユーザの資金の直接的なセキュリティとシステムが正しいオペレーションを続けるという信頼の両方を約束し、システム劣化に対する大きなセーフティマージンが保証される。

Liquidホワイトペーパー日本語訳8 ←← 前)|(次 →→ Liquidホワイトペーパー日本語訳10

免責

邦訳には誤りがある場合がございます。予めご承知おき下さい。

確実な情報を知るためには冒頭に示した原文をご参照くださいますようお願いいたします。

-ホワイトペーパー
-, , , , ,

Copyright© 暗号通貨界隈のメモ書きなど。 , 2024 All Rights Reserved Powered by STINGER.

%d人のブロガーが「いいね」をつけました。