ビットコインのボトルネックを解消：BTC Layer2スケーリング技術の包括的監査ガイド

世界初の暗号通貨であるビットコイン（BTC）は、2009年の登場以来、徐々にデジタル資産と分散型金融の要となってきた。しかし、ユーザー数や取引量の増加に伴い、BTCネットワークの問題点が次第に明らかになりつつあり、主に以下のような問題が顕在化しています:

• 。高い取引手数料：ビットコインネットワークが混雑している場合、ユーザーは取引ができるだけ早く確認されるように高い手数料を支払います。

• トランザクションの確認時間：ビットコインのブロックチェーンは平均10分ごとに新しいブロックを生成するため、チェーン上のトランザクションは通常、最終的なものとみなされるまで複数のブロックが確認されるまで待たなければなりません。

• スマートコントラクトの限界：ビットコインのスクリプト言語には、複雑なスマートコントラクトを実装するための機能が限られています。

本稿では、ライトニングネットワーク、サイドチェーン、ロールアップ、その他の技術を総称してBTCレイヤー2スケーリングソリューションと呼び、BTCのスケーリング能力を維持しながら、高速で低手数料の取引を可能にします。Layer2テクノロジーの導入は、取引速度の向上と取引コストの削減、ユーザーエクスペリエンスの最適化、ネットワーク容量の拡大を実現し、BTCの将来の発展に重要な技術的サポートと革新的な方向性を提供します。

現在、Beosinは世界有数のBTCプラットフォームとなっています。Bitmap.Games、Surf Protocol、Savmswap、MineralなどのBTCエコシステムのプロトコルを監査しています。過去の監査では、Ronin Network、Clover、Self Chain、Crust Networkなど、いくつかの有名なパブリックチェーンがBeosinのパブリックチェーンセキュリティ監査に合格しています。Beosinは現在、BTC Layer2の監査ソリューションを開始し、BTCエコシステム全体に包括的で信頼性の高いセキュリティ監査サービスを提供しています。

Lightning Network

ライトニングネットワークの当初のコンセプトは「ペイメントゲートウェイ」と呼ばれ、最終的にビットコインネットワークにブロードキャストされるまで、未確認のトランザクションを新しいものに置き換えてステータスを更新し続けるというものでした。サトシ・ナカモトは、2009年にビットコインを作成したときにペイメント・チャネルのアイデアを思いつき、ビットコイン1.0にペイメント・チャネルのドラフトコードを含め、ネットワークで確認される前にユーザーが取引のステータスを更新できるようにした。しかし、ホワイトペーパー「The Bitcoin Lightning Network: Scalable Off-Chain Instant Payment（ビットコイン・ライトニング・ネットワーク：スケーラブルなオフチェーン即時決済）」がリリースされるまで、ライトニング・ネットワークは真に誕生し、世間の注目を集めることはなかった。

今日、決済ゲートウェイとライトニングネットワークの実装は非常に成熟しています。

https://1ml.com/

ライトニングネットワークでは、送金プロセスにおけるユーザーの資産のセキュリティを確保することが非常に重要です。以下では、ライトニングネットワークの仕組みと、ネットワークノードのサイズに応じたユーザー資産のセキュリティ確保について説明します。

2人のユーザーがメインのビットコインネットワークに2つのトランザクションを提出します：1つはチャネルを開くため、もう1つは閉じるためです。

1.チャネル開設：

まず、参加する両方のユーザーがBTC上のライトニングネットワークのマルチシグネチャウォレットにビットコインを誓約します。ビットコインが正常に誓約されロックされると、両者がオフチェーン取引を行うことができる決済チャネルが開きます。

2.オフチェーン取引：

チャネルがオープンすると、ユーザー間の送金取引はすべてライトニング・ネットワークで処理され、これらのオフチェーン取引の回数に制限はありません。もちろん、これらの取引はすぐにメインのビットコインネットワークに提出する必要はなく、ライトニングネットワークのオフチェーンメカニズムを通じて瞬時に完了する。

このオフチェーン処理により、ビットコインのメインネットワークが取引処理に使用される必要性を回避し、取引速度と効率が大幅に向上します。

このオフチェーン処理により、取引速度と効率が大幅に向上し、ビットコインのメインネットワークの混雑と高い取引手数料を回避できます。

3.チャネル閉鎖とブック決済:

チャネルのいずれかの側のユーザーがチャネルを終了することを決定すると、最終的なブック決済が実行されます。このプロセスは、チャネル内のすべての資金が最新の状態で分配されることを保証します。同時に、両方のユーザーはマルチシグネチャーのウォレットから決済された残高を引き出し、チャネルがクローズされた時点の実際の資金配分を反映します。最終的に、チャネルは台帳トランザクションの最終状態をメインのビットコインネットワークに提出します。

ライトニングネットワークの利点は次のとおりです。:

• 取引速度の向上。ライトニング・ネットワークは、ユーザーがオフチェーンで取引することを可能にします。つまり、ブロックの確認時間を待つことなく、ほぼ瞬時に取引を完了することができます。これにより、セカンドレベルの取引速度が可能になり、ユーザーエクスペリエンスが大幅に向上します。

• プライバシーの強化。ライトニングネットワーク上のオフチェーン取引は、ビットコインのメインチェーン上に公に記録される必要がないため、取引のプライバシーが向上します。チャネルのオープンとクローズのみがメインチェーンに記録される必要があるため、ユーザーの取引は完全には公開されません。

• マイクロペイメントサポート。ライトニング・ネットワークは、コンテンツの支払いやIoTデバイスの支払いなど、少額の支払い（マイクロペイメント）を扱うのに理想的です。従来のビットコイン取引は手数料が高いため、頻繁なマイクロペイメントには適しておらず、ライトニングネットワークはこの問題を解決する。

ライトニングネットワークが直面する課題:

• ネットワークの流動性の問題: ライトニングネットワークは、チャネルにあらかじめロックされたビットコインに依存しています。つまり、ユーザーは取引を行うために、決済チャネルに事前に十分なビットコインを入金しておく必要があります。流動性が不十分だと、特に大規模な決済で決済が失敗する可能性がある。

• ルーティングの問題：支払い送信者から受信者への効率的な経路を見つけることは、特に大規模なネットワークでは複雑な問題になる可能性があります。ネットワークノードとチャネルの数が増えれば増えるほど、支払いを確実に成功させるのは難しくなります。

• Funds Escrow Trust Issues: ノードは悪意のある攻撃を受ける可能性があり、ユーザーは接続先のノードが資金を盗もうとしないことを信頼する必要があります。ノードが秘密鍵の漏洩から保護されているかどうか

• Technical standards and interoperability: 相互運用性を確保するために、異なるライトニング・ネットワーク実装間で一貫した技術標準とプロトコルが必要です。現在、複数の開発チームがLightning Networkの異なる実装に取り組んでおり、互換性の問題につながる可能性があります。

• プライバシーの問題：ライトニングネットワークはビットコイン取引のプライバシーを向上させますが、取引情報は依然として追跡や分析が可能です。さらに、ネットワークノードのオペレータは、自分のノードを通過するトランザクションを見ることができ、特定の個人情報を明らかにする可能性がある。

ライトニングネットワークのセキュリティは、ビットコインのオフチェーン拡張能力とユーザー資金の安全性に直接影響します。そのため、パブリックチェーンの一般的な監査項目に加えて（詳細は記事末の付録を参照）、ライトニング ネットワークは以下の重要なセキュリティ リスク ポイントに焦点を当てる必要があります:

• ライトニング ネットワークのセキュリティは、ビットコインのオフチェーン拡張能力とユーザー資金の安全性に直接影響します。

• チャネルの輻輳：ライトニング・ネットワーク・システムの設計の包括性をチェックし、悲痛な攻撃がチャネルの輻輳を引き起こす可能性があるかどうかを確認する。

• チャネル妨害：チャネル妨害攻撃に対するライトニングネットワークのチャネル構造の安全性をチェックする。

• チャネルのアセットロックとロック解除：ライトニングネットワークのアセットロックとロック解除のプロセスを見直し、決済チャネルを開いたり閉じたりする際のチェーンの上下の資金移動が安全かつセキュアであることを確認します。

• ステータスの更新とクローズ：チャネルのステータス更新プロセスと強制クローズメカニズムを評価し、最新のステータスが正しく認識され、異常時に強制されるようにします。

• タイムロックとハッシュロック契約（HTLC）：タイムロックとハッシュロックの条件が正しく実施され、タイムウィンドウの問題による資金の損失を防ぐために、HTLCの実装を評価する。

• ブロックチェーンのタイムスタンプ依存性：ライトニングネットワークのビットコインブロックチェーンのタイムスタンプへの依存性を評価し、タイムアタックを防ぐためにオンチェーンとオフチェーンの時間を正しく調整できるようにします。

• ルーティングアルゴリズムのセキュリティ：ルーティングアルゴリズムの効率性とセキュリティを検証し、ユーザーのプライバシー暴露と悪意のあるルート操作のリスクを防ぎます。

• チャネルストレージとデータ回復：資金損失を避けるために、ノードの故障や偶発的な切断の場合にチャネル状態を確実に復元できるように、チャネルストレージ機構とデータ回復戦略を検討する。

サイドチェーン

ライトニングネットワークとは異なり、サイドチェーンは独立したブロックチェーンです。メインチェーン（BTCブロックチェーンなど）と並行して動作し、双方向ペグ（Two-Way Anchoring）を介してメインチェーンと相互運用します。サイドチェーンの目的は、メインチェーンのプロトコルを変更することなく、より多くの機能を可能にし、スケーラビリティを向上させることです。

サイドチェーンは独立したブロックチェーンとして、独自のコンセンサスメカニズム、ノード、トランザクション処理ルールを持っています。特定のアプリケーションシナリオのニーズに応じて、メインチェーンとは異なる技術やプロトコルを採用することができる。双方向アンカリングメカニズム（2WP）を通じて、サイドチェーンはメインチェーンと通信し、両者間の自由で安全な資産移転を保証する。2WPの動作メカニズムは以下の通りです：



2.信頼された組織は、サイドチェーン上のユーザーに同価値のトークンを発行する。

3.ユーザーは自由取引の後、サイドチェーン上の残りのトークンをロックします。

4.信頼できる組織が取引の正当性を検証し、メインチェーン上のユーザーに対応する価値のBTCをロック解除してリリースする。

注1：信頼された組織は、資産のロックと解放を管理する、双方向のアンカリングメカニズムにおいて重要な役割を果たします。これらの組織は、ユーザー資産のセキュリティを確保するために、高い評判と技術的能力が必要です。

注2：SPV検証により、ノードはブロックチェーン全体をダウンロードすることなく、特定のトランザクションの有効性を検証することができます。SPVノードは単にブロックヘッダをダウンロードし、そのトランザクションがメルクルツリーを通じてブロックに含まれていることを検証します。

代表的なサイドチェーンプロジェクト：

CKB（Nervosネットワーク）

Nervosネットワークはオープンソースのパブリックブロックチェーンエコシステムで、BTCのPOWコンセンサスメカニズムのセキュリティと分散化の利点を活用する一方、トランザクション処理によりスケーラブルで柔軟なUTXOモデルを導入するように設計されています。その中核となるのがCommon Knowledge Base（CKB）で、RISC-V上に構築され、コンセンサスとしてPoW（Proof of Work）を使用するレイヤー1のブロックチェーンである。CKBはUTXOモデルをCellモデルへと拡張し、あらゆるデータを保存し、あらゆる言語のスクリプトをサポートして、チェーン上でスマートコントラクトとして実行することを可能にする。



Stacks

Stacksは、PoX（移転証明）メカニズムを通じて、各Stacksブロックをビットコインブロックに接続します。スマートコントラクトを開発するために、Stacksは特殊なClarityプログラミング言語を設計した。Clarityでは、get-burn-block-info? 関数でビットコインブロックの高さを渡し、そのブロックのヘッダーハッシュを得ることができる。一方、burn-block-heightキーワードは、ビットコインチェーンの現在のブロックの高さを取得します。これら2つの関数により、Clarityスマートコントラクトは基礎となるビットコインチェーンの状態を読み取り、ビットコイントランザクションをコントラクトのトリガーとして機能させることができる。これらのスマートコントラクトを自動化することで、Stacksはビットコインの機能を拡張します。

Stacksの詳細な分析については、Beosin氏の以前の研究記事「Stacksとは何か、BTCの第2層ネットワーク、Stacksが直面するかもしれない課題とは」をお読みください。



サイドチェーンの利点は。strong>:

• サイドチェーンは、メインチェーンの安定性と安全性に影響を与えることなく、さまざまな技術やプロトコルを採用し、あらゆる種類の実験や革新を行うことができます。

• サイドチェーンは、スマートコントラクト、プライバシー保護、トークン発行など、メインチェーンでは利用できない機能を導入し、ブロックチェーンエコシステムのアプリケーションシナリオを豊かにすることができます。

サイドチェーンが直面する課題：

• 独立したコンセンサスメカニズムを持つサイドチェーンは、BTCメインチェーンほど安全ではないかもしれません。サイドチェーンのコンセンサスメカニズムが弱かったり脆弱であったりすると、51%攻撃や他の形態の攻撃につながり、ユーザー資産のセキュリティに影響を与える可能性があります。BTCメインチェーンのセキュリティは、その巨大な演算能力とノードの幅広い分布に依存していますが、サイドチェーンは同じセキュリティ基準を満たすことができない可能性があります。

• 双方向アンカリングメカニズムの実装には、複雑な暗号アルゴリズムとプロトコルが必要であり、そこに抜け穴があれば、メインチェーンとサイドチェーン間の資産移転に問題が生じ、資産の紛失や盗難につながる可能性さえある。

• スピードとセキュリティのバランスを取るために、ほとんどのサイドチェーンはメインチェーンよりも集中化されています。

Layer2は完全なブロックチェーンシステムなので、パブリックチェーンに共通する監査項目がサイドチェーンにも適用されます。

さらに、その特殊性から、サイドチェーンにはいくつかの追加監査が必要です:

• 
  コンセンサス
  

• Layer2 は完全なブロックチェーンシステムです。コンセンサスプロトコルのセキュリティ：サイドチェーンのコンセンサスプロトコル（PoW、PoS、DPoSなど）が適切に検証され、51%攻撃や長距離攻撃などの潜在的な脆弱性や攻撃ベクトルについてテストされているかどうかを確認する。

• コンセンサスノードのセキュリティ：鍵管理、ノード保護、冗長バックアップなど、コンセンサスノードのセキュリティを評価し、ノードの侵入や悪用を防ぐ。

• 資産のロックと放出：サイドチェーンとメインチェーン間の双方向の資産アンカリングメカニズムを見直し、資産のロックと放出のためのスマートコントラクトが安全で信頼できることを確認し、二重支出、資産の損失、ロックの失敗を防ぐ。

• クロスチェーン検証：クロスチェーン検証の正確性と安全性をチェックし、検証プロセスが分散化され、改ざんができないようにし、検証の失敗や悪意のある検証を防ぎます。

• コントラクトコード監査：サイドチェーン上で実行されているすべてのスマートコントラクトを徹底的に監査し、特にクロスチェーン操作を処理する際のコントラクトロジックにおいて、可能性のある抜け穴やバックドアを検出します。

• アップグレードメカニズム：スマートコントラクトのアップグレードメカニズムが安全かどうか、悪意のあるアップグレードやコントラクトの改ざんを防ぐための適切な監査とコミュニティの合意プロセスがあるかどうかをチェックします。

• ノード間通信：サイドチェーンノード間の通信プロトコルが安全かどうか、中間者攻撃やデータ漏洩を防ぐために暗号化されたチャネルが使われているかどうかをチェックする。

• クロスチェーン通信：サイドチェーンとメインチェーン間の通信チャネルをチェックし、データの完全性と真正性を確保し、通信の乗っ取りや改ざんを防ぎます。

• タイムスタンプとブロック時刻：サイドチェーンの時刻同期メカニズムを検証し、ブロック生成時刻の一貫性と正確性を確保し、時差による攻撃やブロックのロールバックを防ぎます。

• オンチェーンガバナンスの安全性：サイドチェーンのガバナンスメカニズムを検証し、投票、提案、意思決定プロセスの透明性と安全性を確保し、悪意のあるコントロールや攻撃を防ぐ。

• トークン経済監査：トークンの割り当て、インセンティブ、インフレモデルなど、サイドチェーンのトークン経済モデルを調査し、経済的インセンティブが悪意のある行動やシステムの不安定性につながらないようにします。

• 手数料メカニズム：サイドチェーンの取引手数料メカニズムを調査し、メインチェーンとサイドチェーンユーザーのニーズにマッチしていることを確認し、手数料の操作やネットワークの輻輳を防ぎます。

• 資産のセキュリティ：オンチェーン資産の管理メカニズムを監査し、資産の保管、移転、破棄が安全かつ確実で、不正アクセスや盗難のリスクがないことを確認する。

• 鍵管理：サイドチェーンの鍵管理戦略をチェックし、秘密鍵のセキュリティとアクセス制御を確保し、鍵の漏洩や盗難を防ぐ。

ロールアップ

ロールアップは、ブロックチェーンのトランザクションの処理能力と効率を向上させるために設計されたレイヤー2の拡張ソリューションです。スループットと効率を向上させるために設計されたレイヤー2拡張ソリューションです。多数のトランザクションをパッケージ化（「ロールアップ」）してオフチェーンで処理し、最終結果のみをメインチェーンに提出することで、メインチェーンの負担を大幅に軽減します。

Rollupは主にzk-Rollupとop-Rollupに分けられますが、ETHとは異なり、BTCのチューリング不完全性のため、BTC上のコントラクトを使用したゼロ知識証明検証は不可能です。従来のzk-RollupソリューションはBTCでは実装できないのです。では、どのようにzk-Rollupを使用してBTC Layer2を実装するのでしょうか？

BTC上でゼロ知識検証を行うために、B² Networkはzk-Rollupとzk-Rollupの両方を組み合わせたTaprootスクリプトを作成しました。これは、zk-Rollupのゼロ知識証明検証とop-Rollupのインセンティブ・チャレンジの両方を組み合わせたスクリプトです。メカニズムは以下の通り：



1.B²はまず、すべてのユーザー・インをロールアップします。ネットワークはまず、すべてのユーザー起動トランザクションをロールアップする。

2.シーケンサーを使用してロールアップトランザクションをソートした後、ロールアップトランザクションは分散型ストレージを使用して保存され、zkEVMによって処理される。

3.zkEVMはBTCチェーンの状態を同期し、契約の実行とその他のトランザクションを処理し、結果をアグリゲーターに送信します。

4.証明者はゼロ知識証明を生成し、アグリゲータに送信します。アグリゲータはトランザクションを集約し、証明をB²ノードに送信します。

5.B²ノードはゼロ知識証明を検証し、証明に基づいてB²ノードに送信します。Taprootスクリプトを作成するために、分散ストレージ内のロールアップデータに基づいてB²ノードに送信します。

6.タップルートは、データ構造内のB²インスクリプションに格納されたすべてのロールアップデータと、タップリーフに格納された証明のためのすべての検証済みデータを持つ、値1サトシのUTXOです。

ロールアップの利点は：

ロールアップは、メインチェーンのセキュリティと分散化された性質を受け継いでいます。定期的に取引データとステータスをメインチェーンに提出することで、データの整合性と透明性を確保します。

• Rollupはイーサなどの既存のブロックチェーンネットワークにシームレスに統合されるため、開発者は既存のスマートコントラクトやアプリケーションを劇的に変更することなく、その利点を簡単に活用することができます。

• Rollupは、オフチェーンで大量のトランザクションを処理し、メインチェーンに提出するために単一のバッチにパッケージ化することで、トランザクション処理能力を劇的に向上させ、その結果、1秒あたりのトランザクション数（TPS）が大幅に増加します。

• ロールアップトランザクションはオフチェーンでのみ処理されるため、オンチェーントランザクションに必要な計算リソースとストレージスペースが劇的に削減され、ユーザーのトランザクションコストが大幅に削減されます。

ロールアップの課題:

• ロールアップトランザクションは、オンチェーン取引に必要な計算リソースとストレージスペースを劇的に削減します。align: left;">オフチェーンデータが利用できない場合、ユーザーはトランザクションを検証できず、ステータスを回復できない可能性があります。

• ロールアップトランザクションはバッチ処理され、最終的にメインチェーンに提出される必要があるため、決済時間が長くなる可能性があります。特にop-Rollupでは紛争期間があり、ユーザーは取引の最終確認まで長く待たなければならないかもしれません。

• ZK Rollupはより高いセキュリティと即時確認を提供する一方で、高い計算とストレージ要件があり、ゼロ知識証明を生成するには大量の計算リソースが必要です。

採用されたスキームはロールアップであるため、その主要なセキュリティ監査項目は基本的にETH Layer2と同じです。

その他（Babylon）

従来のBTC Layer2に加えて、BTCエコシステムに関連するサードパーティプロトコルの新しい概念もいくつかあります。Babylonのようなサードパーティプロトコル：

Babylonの目標は、2100万BTCを分散型の誓約資産に変換することです。BTCの他のLayer2とは異なり、BabylonはBTCチェーンをスケールしません。BTC担保プロトコルを備えた独自のチェーンであり、主にPoSチェーンとのインターフェイスとして設計され、BTCを担保してPoSチェーンにより強力なセキュリティを提供し、チェーンの遠端からの攻撃リスクや集中化などの問題に対処する。

アーキテクチャは3つのレイヤーに分かれています：

ビットコイン・レイヤー：これはバビロンの強固な基盤であり、ビットコインのよく知られたセキュリティを活用して、すべてのトランザクションがビットコイン上と同じように超安全であることを保証します。セキュアであることを保証します。

バビロンレイヤー: バビロンの中心はバビロンレイヤーで、ビットコインを様々なプルーフ・オブ・ステーク（PoS）チェーンに接続するカスタマイズされたブロックチェーンです。トランザクションを処理し、スマートコントラクトを実行し、エコシステム全体ですべてが円滑に進むようにします。

PoSチェーン層: 最上層は複数のPoSチェーンで構成され、それぞれが独自の利点のために選ばれています。これは、バビロンチェーンに驚くべきスケーラビリティと柔軟性を与え、ユーザーが異なるPoSブロックチェーンの最高の機能を享受することを可能にします。



その方法は、PoSチェーンを保護するために最終ブロックの署名を使用することです。ブロックの署名を使用してPoSチェーンを保護することである。これは本質的に、追加の署名ラウンドで基本プロトコルを拡張する。最後の+1ラウンドの署名にはユニークな特徴があり、抽出可能な1回限りの署名（EOTS）である。目標は、PoSチェックポイントをBTCに統合し、長いアンバンドリング期間とPoSへのリモート攻撃に対処することです。

Babylonの強み:

• PoSのアンバンドリング期間を短縮する

  PoSのアンバンドリング期間を短縮する。

• BTCの誓約のため、価格はBTCに固定され、対応するPoSネットワークのインフレ圧力を緩和することができます

• BTC 利益のための新たな道を開く

Babylon の課題:

• プレッジリターンなどの経済設計は、BTCプレッジインセンティブに大きな影響を与えます

• PoSチェーン間のインセンティブ一貫性規定の欠如

サードパーティのプロトコルは、その実装に基づいて一貫性のないセキュリティ上の懸念があります。 Babylonを例にとると、セキュリティ監査項目のうち、注意を要するものは以下の通りです：

セキュリティ監査項目のうち、注意を要するものは以下の通りです。strong>1. スマートコントラクトのセキュリティ：BTCの誓約コントラクトは、UTXOスクリプトを通じて実現されるため、そのセキュリティに注意を払う必要があります。

2.  Signature Algorithm Security: 契約はユーザーの誓約を管理するために署名を使用し、そのアルゴリズムセキュリティは署名の生成と検証に関連します。

3. プロトコルの経済モデル設計：プロトコルの経済モデルが報酬と罰則の面で合理的に設定されているかどうか、また、それがユーザーの資産の損失につながるかどうか。

Appendix:

Public Chain &; Layer2 Common Audit Items

• 整数オーバーフロー: 整数オーバーフローと整数アンダーフローのチェック

• デッドループ: プログラムのループの判定条件が妥当かどうかをチェックする

• 無限再帰呼び出し：プログラムの再帰呼び出しの終了条件が妥当かどうかをチェックする

• 競合条件：プログラムのアクセス操作をチェックする。condition: 並行状態での共有リソースへのアクセス操作をチェックする

• Exceptional crashes: プログラムが自発的に終了できるような例外を投げるコードをチェックする

• Divide of the recursive call (再帰呼び出しの分割): left;">0による除算の脆弱性: 0による除算をチェックする

• 型変換: 正しい型変換と変換中の重要な情報の損失をチェックする

• 配列の境界外: 配列の境界を超えた要素へのアクセスをチェックします

• デシリアライズの脆弱性: デシリアライズ処理の問題をチェックします

機能実装のセキュリティ：各RPCインターフェースの実装にセキュリティリスクがあるかどうか、RPCインターフェースの機能と整合しているかどうかをチェックする

• 機能設計

• 機能実装のセキュリティ：各RPCインターフェースの実装にセキュリティリスクがあるかどうか、デシリアライズ処理に問題があるかどうかをチェックする

機密性の高いRPCインターフェースのアクセス許可設定が妥当かどうか：機密性の高いRPCインターフェースのアクセス許可設定をチェックします

• 暗号化された伝送メカニズム：例えばTLSなどの暗号化された伝送プロトコルが使用されているかどうかをチェックします

• 例えばTLSなどの暗号化された伝送プロトコルが使用されているかどうかをチェックします。TLS など

• Request data format parsing: リクエストデータのフォーマット解析プロセスをチェックする

• Wallet unlocking attack: ノードがウォレットのロックを解除すると、ノードは攻撃を受けます。そのウォレットのロックを解除すると、RPCリクエストによって盗まれます

• レガシー・ウェブ・セキュリティ: 次の脆弱性をチェックしてください: クロスサイト・スクリプティング(XSS)/テンプレート・インジェクション/

• ネットワークノードの認証および認識メカニズム：ノード識別メカニズムが存在するかどうか、ノード識別メカニズムがバイパス可能かどうかをチェックします

  ルーティングテーブルの汚染：ルーティングテーブルが自由にデータを挿入または上書きできるかどうかをチェックする

• ノード発見アルゴリズム：ノード発見アルゴリズムがバランスよく予測不可能かどうかをチェックする、例えば距離アルゴリズムにおける不均衡などの問題

• 接続占有監査：p2pネットワークにおける接続ノード数の制限と管理が妥当かどうかをチェックする

  食攻撃：食攻撃のコストと害を評価する。必要に応じて定量的な分析を提供する

• 魔女攻撃：投票コンセンサスメカニズムを評価し、投票適格性チェック戦略を分析する

• 魔女攻撃：投票コンセンサスメカニズムを評価し、投票適格性チェック戦略を分析する

• 魔女攻撃。left;">盗聴攻撃：通信プロトコルがプライバシーを漏らすかどうかをチェックする

• 同型攻撃：ノードが類似のチェーンノードを識別できるかどうかを評価する

• 同型攻撃：ノードが類似のチェーンノードを識別できるかどうかを評価する

• 投票コンセンサスメカニズムの評価。left;">Time hijacking: ノードのネットワーク時間計算メカニズムをチェックする

• Memory exhaustion attack: 大量のメモリを消費する場所をチェックする

• Hard Drive exhaustion attack: 大きなファイルが保存されている場所をチェックする

• Socket stress attack: リンク数の制限ポリシーをチェックする

• Socket stress attack: リンク数の制限ポリシーをチェックする

• Socket stress attack: リンク数の制限ストラテジーをチェックするカーネル ハンドルの枯渇攻撃: ファイル ハンドルなど、カーネル ハンドル作成の制限をチェックする

• 永続的なメモリ リーク: 発生しているメモリ リークをチェックする

• ハッシュアルゴリズムのセキュリティ：ハッシュアルゴリズムの衝突耐性をチェックする

• デジタル署名アルゴリズムのセキュリティ：署名アルゴリズムのセキュリティ、アルゴリズム実装のセキュリティをチェックする

  が妥当かどうかをチェックする

• BFT実装セキュリティ：BFTアルゴリズムの実装セキュリティを評価する

• フォーク選択ルール：フォーク選択ルールをチェックし、安全性を確保する

• 。

• 中心性検出：システム設計に過度の集中設計があるかどうかを特定します

• 中心性検出：システム設計に過度の集中設計があるかどうかを特定します

• 中心性検出：システム設計に過度の集中設計があるかどうかを特定します。インセンティブ監査：インセンティブがセキュリティに与える影響を評価する

• ダブルフラワー攻撃：コンセンサスがダブルフラワー攻撃を防御できるかどうかをチェックする

• MEV攻撃監査：ブロックパッキングノードのチェーンの公平性に対するMEVの影響をチェックする

• ブロック同期プロセス監査：同期プロセスの安全性をチェックする

• ブロックフォーマット解析プロセス監査：フォーマット解析プロセスに、クラッシュにつながる解析エラーなどのセキュリティ上の問題がないかチェックする

• ブロック生成プロセス監査：ブロック生成プロセスに、以下のようなセキュリティ上の問題がないかチェックする。Merkle treeのルート構築方法が妥当かどうか

• ブロック検証プロセスの監査：ブロック署名の内容項目と検証ロジックが十分かどうかをチェックする

• ブロック生成プロセスの監査：ブロック生成プロセスにおけるセキュリティ問題をチェックする。align: left;">ブロック検証ロジックの監査：ブロック検証アルゴリズムと実装が妥当かどうかをチェック

• ブロックハッシュ衝突：ブロックハッシュ衝突の構築方法、衝突の処理が妥当かどうかをチェック

• ブロックハッシュ衝突：構築方法、衝突の処理が妥当かどうかをチェック

• ブロック処理リソースの制限：孤児ブロックプール、検証計算、ハードドライブのアドレス指定などのリソースの制限が妥当かどうかをチェックする

• トランザクション同期監査：同期プロセス中にセキュリティ上の問題があるかどうかをチェックする

トランザクション同期監査：同期プロセス中にセキュリティ上の問題があるかどうかをチェックする

• トランザクションハッシュの衝突：トランザクションハッシュの衝突がどのように構築され、衝突した場合にどのように処理されるかをチェックする

• トランザクションフォーマットの解析。トランザクションフォーマットの解析：クラッシュの原因となる解析エラーなど、フォーマット解析中のセキュリティ問題をチェックする

• トランザクションの正当性の検証：様々な種類のトランザクション署名の内容項目と検証ロジックの妥当性をチェックする

• トランザクションの正当性の検証：様々な種類のトランザクション署名の内容項目と検証ロジックの妥当性をチェックする

トランザクション処理リソースの制限：トランザクションプール、検証計算、ハードディスクアドレッシングなどのリソースの制限が妥当かどうかをチェックする

• トランザクション拡張攻撃：トランザクションが内部フィールド（例えばScriptSig.ScriptSig）を変更し、その結果トランザクションの有効性に影響を与えることなくトランザクションハッシュを変更できるかどうか

• トランザクションリプレイ攻撃監査：トランザクションリプレイのシステムの検知をチェックする

  契約バイトコード検証：整数オーバーフロー、デッドループなど、契約のVM検証プロセスのセキュリティをチェックします

• 契約バイトコード実行：バイトコードのVM実行プロセスのセキュリティをチェックします。例えば、整数オーバーフロー、デッドループなど

  ガスモデル：トランザクション処理/契約実行の各アトミック操作の処理料が、リソース消費量に比例しているかどうかをチェックする

• 契約バイトコード実行：トランザクション処理/契約実行の各アトミック操作の処理料が、リソース消費量に比例しているかどうかをチェックする

• ロギングの完全性：重要な情報がログに記録されているかどうかをチェックする

• ロギングの安全性：ログの不適切な処理が、整数オーバーフローなどのセキュリティ問題を引き起こしていないかどうかをチェックする

• ログにプライベートな情報が含まれている: ログにキーなどのプライベートな情報が含まれているかどうかをチェックする

• ログの保存: ログに記録される内容が多すぎて、ノードのリソースを消費していないかどうかをチェックする

• ログの保存。ノードのリソース消費を引き起こす

• ノードコード・サプライチェーン・セキュリティ：すべてのサードパーティライブラリ、コンポーネント、およびパブリックチェーンフレームワークの対応するバージョンの既知の問題をチェックします