Thin Client Security

最近、ブロックチェーン全体にすべてのブロックの完全なコピーを格納しないビットコインクライアントの提案が数多くありました。このページでは、シンクライアントなどのすべてのクライアントを参照します。このページは、さまざまなスキームのセキュリティと信頼の意味を理解しようとする場所です。

完全なノードvs.シンクライアント

ブロック高さ検証とブロック深度検証を区別することが重要です。

フル・ノード・クライアントは、トランザクションが有効であることを保証するために、先行するすべてのブロックが有効であることを検証します。現在のところ、Satoshiクライアント、libbitcoin、およびbtcdのみが完全ノード検証を行います。完全ノードはBitcoinシステムにおける信頼できないセキュリティの基本的なアンカーです。

クライアントはブロックの深さDを確認することによってブロックの深さDを検証します.Dブロックの後ろに「確認」と呼ばれるDブロックがあり、すべてが整形式であることを確認します。シンクライアントは、前のブロックを検証しません。トランザクションを除外する新しいより長いフォークを生成する可能性の尺度として（有効かどうかにかかわらず）確認の数を使用します（[Chain_Reorganization |ブロックチェーン再編成] 。

完全なノードクライアント

「太い」ビットコインクライアントは、すべてのトランザクション（ヘッダーだけでなく）を含むチェーン全体のコピーをダウンロードします。以下のセキュリティ比較の参照ポイントとして使用されます。

フルノードのクライアントは、 difficultwise-longest有効なブロックチェーンを使用します。トランザクションの「深さ」（ブロックまたは確認後のブロック数）は、より長いフォークの出現のためにトランザクションが二重に消費される可能性を判断するために使用されます。

ブロック保持

フルチェーンのクライアントがチェーン全体をダウンロードすると、一般的にそれが保持されます（Satoshiクライアントが行ったように）。

Satoshiのオリジナルの論文では、個々のトランザクションを枝刈りする可能性について言及しています。これにより、トランザクション履歴全体を確認するが、保持しない完全ノードが可能になります。ユーザーは最初に他のノードからブロックチェーンをダウンロードして検証する必要があるため、この変更にはコストがかかりません。

シンクライアント

このクライアントは、ブロックチェーン全体のすべてのブロックのヘッダーの完全なコピーをダウンロードします。これは、Bitcoinが発明されて以来、ダウンロードとストレージの要件が直線的に拡大することを意味します。

このスキームは、[1]のセクション8で説明されています。

ブロック深度チェック

Satoshiが書いているように、「[シンクライアント]は自分自身でトランザクションを確認することはできませんが、チェーン内の場所にリンクすることでネットワークノードがそれを受け入れたことを知ることができます。それを受け入れた。 「X」を「後に追加されるブロックの数」とすると、シンクライアントは本質的に、トランザクションXブロックが深刻なブロックを偽造するにはコストがかかることを信頼します。

シッククライアントは、トランザクションの入力がそのポイントまでチェーン全体を実際にチェックすることで、トランザクションの入力が消費されていないことを検証します。ここには「Xブロック深く」はありません。その時点で、「Xブロック深度」を使用して、チェーン内の長いフォークが出現してそのトランザクションを除外する可能性がどの程度あるかを判断します。

bitcoinj

bitcoinjのいくつかの問題のセキュリティ分析は、hereにあります。しかしながら：

• 「ノードを10個選んですべてに一貫性を持たせることを要求することは、信頼性がはるかに低い」という主張は、"がんのノードと[http： //en.wikipedia.org/wiki/Sybil_attackシビルの攻撃]。
• セキュリティの主張の多くは、「攻撃者があなたのインターネット接続を制御していると思わない場合」という形式で修飾されています。これがなぜ問題であるのかについては、前のセクションを参照してください。

[2]

ピココインが基づいているライブラリ（libccoin）には、スクリプトとブロックを検証するためのコードが含まれています。これは、フルチェーンクライアントを実装するために潜在的に使用される可能性があります。

Electrum

Electrumは、アドレスによってブロックチェーンを索引付けするBitcoinノードであるElectrumサーバーからブロックチェーン情報をフェッチします。 Electrumは、サーバから返されたトランザクションを確認するために簡易支払確認を実行します。 このため、約10のランダムなサーバーからブロッキンヘッダーを取得します。 さらに、Electrumサーバーは、MITM攻撃からユーザーを保護するために、SSLによって認証されます。

ブロックチェーン（UOT）の未使用出力ツリー

いくつかの提案がありました（最初はthis oneとなっていますが、gmaxwellは「オープントランザクションツリー」と呼んでいましたが、「オープン」という用語は「未使用」ではなく「ブロックチェーンにまだマイニングされていません」）を使用して、チェーン内の各ブロックで未使用トランザクション出力のツリーを形成し、Merkleツリーとしてハッシュし、ブロックチェーン内のルートハッシュをエンコードします（おそらくコインベース入力の一部として）。これは未使用出力ツリー（UOT）と呼ばれます。これまでの最初の詳細な提案は、Alberto Torresの提案です。 etotheipiの[3]はこれの変形です。

このようなUOTハッシュがブロックチェーンに含まれていた場合、UOTを持ったcheckpointブロックに同梱されているクライアントは、チェックポイントの後にブロックをダウンロードするだけで済みます。さらに、クライアントがブロックをダウンロードしてUOTを確認すると、UOTを含む最新ブロック以外のすべてを破棄することができます。

敵対的な鉱夫は、UOTであると主張しているが実際には無効であるブロックをチェーンに挿入することができる。このようなブロックはチェーンの外に出ることはできません。新しいブロック妥当性基準を追加する必要があり、この新しい基準を実装する鉱夫は、フォークの「マイニング」を危険にさらす危険があります。たくさんのお金。したがって、どのUOT戦略も、UOTエントリを含むすべてのブロックを信頼できるわけではないという事実に対処する必要があります。

現時点では、このような未使用出力ツリーハッシュの標準フォーマットは合意されておらず、チェーンのどのブロックにも含まれていないことに注意してください。 bitcoind-0.8に追加されたultraprune機能は、クライアントのディスク上に同様のデータ構造を維持します。このデータ構造やそのハッシュはブロックチェーンのどこにも置かれません。

サーバートラステニングクライアント

これらのクライアントは、信頼されるサーバーに高いレベルの信頼を必要とします。サーバーを認証し、サーバーが侵害されていないことを確認するメカニズムは、通常は説明されていません。

以下にリストされているすべてのシンクライアントは、現在、単一のサーバーに接続しており、二重支出と同様の攻撃に対して脆弱です。この攻撃は、単一のサーバーで実行することができます。サーバーはBitcoinトランザクションを受け取ったばかりであり、実際にBitcoinを交換することなく、サーバーが存在しないと仮定して、サービスを実行したり、資金を移したり、 。したがって、彼らは暗黙のうちにそれを信じています。

クライアントが複数のサーバーと通信し、トランザクションをブロードキャストし、それらのすべてを照会するようになる将来の拡張が提案されました。残念なことに、これは実際にセキュリティを向上させるものではないことをセキュリティ研究者にはよく知られています。単にエクスプロイトをより複雑にして見つけにくくするだけです。セキュリティ研究者はこの現象の名前を持っています：それは "Sybil attack"と呼ばれています<ref> http://en.wikipedia.org/wiki/Sybil_attack </ ref>。 [https://bitcointalk.org/index.php?topic=88208.msg975201#msg975201この記事では、いくつかの政府（特にイランと中国）が、自国の市民に対してこのような攻撃をどのようにして実施しているのかを説明しています。のSSL証明書機関。

チェックポイントを持つクライアント（非常に古いものでも）は、ブロックチェーン全体のヘッダーをダウンロードして検証しますnot vulnerable を次のような意味でSybilの攻撃に適用することができます。攻撃が盗まれた量以上になることを常に保証できます。

その他

• bitcoin-devの[4]
• question on bitcoin.stackexchange.com
• [弱点＃Sybil_attack | sybil攻撃（癌ノードとも呼ばれる]）]段落は、「見ることができるIPアドレスの大半」が何であっても、セキュリティを基盤とするシンクライアントの問題のいくつかを説明しています。
• [5]
• シンクライアントとフルチェーン検証の間の仮説[6]。

<リファレンス>

Category：技術 カテゴリ：クライアント Category：セキュリティ