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

2024.08.15

共有先

TechFlow厳選深潮セレクト

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

ライトニングネットワーク（Lightning Network）、サイドチェーン（Sidechains）、Rollup などの技術は、総称してBTC Layer2のスケーリングソリューションと呼ばれる。

2024.08.15 - 17:22:31

Web3業界の深掘り報道に専念し潮流を洞察

執筆：Beosin

Bitcoin（BTC）は世界初の暗号資産として、2009年の登場以来、デジタル資産および分散型金融の基盤となりつつあります。しかし、ユーザー数と取引量の増加に伴い、BTCネットワークの課題も顕在化しており、主に以下の通りです。

高額な取引手数料：ビットコインネットワークが混雑すると、ユーザーは取引を迅速に確認してもらうために高い手数料を支払う必要があります。
取引確認時間：ビットコインブロックチェーンは平均10分ごとに新しいブロックを生成するため、オンチェーン取引は通常、複数のブロックによる確認を待つ必要があり、最終的な確定まで時間がかかります。
スマートコントラクトの制限：ビットコインのスクリプト言語は機能に制限があり、複雑なスマートコントラクトの実現が困難です。

本稿では、ライトニングネットワーク（Lightning Network）、サイドチェーン（Sidechains）、Rollupなどの技術を総称して「BTC Layer2 拡張ソリューション」と呼びます。これらの技術は、迅速かつ低コストの取引を実現しつつ、BTCネットワークの分散性と安全性を維持することを目指しています。Layer2技術の導入により、取引速度の向上とコストの削減が可能になり、ユーザー体験の最適化やネットワーク容量の拡大につながり、BTCの将来に向けた重要な技術的支援と革新の方向性を提供します。

ライトニングネットワーク

ライトニングネットワークの起源となる概念は「ペイメントチャネル」であり、未確認の取引状態をトランザクション置換によって継続的に更新し、最終的にビットコインネットワークにブロードキャストするという設計思想に基づいています。中本聡は2009年にビットコインを創造した際、すでにペイメントチャネルのアイデアを提示しており、Bitcoin 1.0にはそのコード草案が含まれていました。この草案は、ネットワークによる確認前でも取引状態を更新できる仕組みを許容していました。しかし、『The Bitcoin Lightning Network: Scalable Off-Chain Instant Payment』というホワイトペーパーが公開されるまでは、ライトニングネットワークは広く知られることはありませんでした。

現在では、ペイメントチャネルおよびライトニングネットワークの実装は非常に成熟しています。現時点での統計によると、ライトニングネットワークには13,325のノードと49,417のチャネルが存在し、合計で4,975 BTCがステーキングされています。

https://1ml.com/

ライトニングネットワークにおいて、ユーザー資産の移転過程における安全性の確保は極めて重要です。以下では、ネットワークノードの規模に基づき、ライトニングネットワークの動作原理および資産保護の仕組みについて説明します。

双方のユーザーはビットコインメインネットに2つのトランザクションを提出します。1つはチャネル開設用、もう1つはチャネル閉鎖用です。具体的には以下の3ステップで構成されます。

1. チャネル開設：

まず、参加する両当事者はビットコインをBTC上にあるマルチシグウォレットにステーキングします。ビットコインが正常にステーキングされロックされると、ペイメントチャネルが開設され、双方はこのチャネル内でオフチェーン取引を行うことができるようになります。

2. オフチェーン取引：

チャネルが開設された後、ユーザー間のすべての送金取引はライトニングネットワーク上で処理され、回数制限なく行われます。これらオフチェーン取引は即時に完了し、ビットコインメインネットに直ちに提出する必要はありません。

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

3. チャネル閉鎖と台帳決済：

いずれかのユーザーがチャネルを終了することを決定した場合、最終的な台帳決済が行われます。このプロセスにより、チャネル内のすべての資金が最新の状態に応じて分配されます。その後、双方はマルチシグウォレットから決済後の残高を引き出し、これはチャネル閉鎖時の実際の資金配分を反映しています。最終的に、チャネルの最終状態の台帳トランザクションがビットコインメインネットに提出されます。

ライトニングネットワークの主な利点は以下の通りです。

取引速度の高速化：ライトニングネットワークはオフチェーン取引を可能にし、ブロック確認を待たずにほぼ瞬時に取引を完了できます。これにより秒単位での取引が実現し、ユーザー体験が大きく向上します。
プライバシーの強化：ライトニングネットワークのオフチェーン取引はビットコインメインチェーン上に記録されないため、取引のプライバシーが向上します。チャネルの開設と閉鎖のみがメインチェーンに記録されるため、ユーザーの取引行動は完全に公開されることはありません。
マイクロペイメントのサポート：ライトニングネットワークは、コンテンツ課金、IoT機器の支払いなど、小額取引（マイクロペイメント）に最適です。従来のビットコイン取引は手数料が高いため頻繁な小額取引には不向きでしたが、この問題を解決しています。

一方で、ライトニングネットワークが直面する課題も存在します。

ネットワーク流動性の問題：ライトニングネットワークはチャネル内に事前にロックされたビットコインに依存しています。つまり、ユーザーは取引を行うためにチャネルに十分なビットコインを前もって預ける必要があります。流動性が不足すると、特に大口の支払いにおいて支払い失敗のリスクがあります。
ルーティングの問題：送信者から受信者までの有効な経路を見つけることは、ネットワーク規模が大きくなるほど複雑になります。ノードとチャネルの増加に伴い、支払いが正常に完了する保証を得るのが難しくなる可能性があります。
資金託管における信頼問題：ノードは悪意ある攻撃を受けうるため、ユーザーは接続するノードが資金を盗もうとしないことを信頼しなければなりません。また、ノードが秘密鍵の漏洩を防げるかどうかが問われます。
技術標準と相互運用性：異なるライトニングネットワーク実装間では一貫した技術標準とプロトコルが必要であり、相互運用性を確保しなければなりません。現在、複数の開発チームが異なる実装を開発しており、互換性の問題が生じる可能性があります。
プライバシーの問題：ライトニングネットワークはビットコイン取引のプライバシーを向上させますが、依然として取引情報が追跡・分析される可能性があります。さらに、ネットワークノードの運営者は自らのノードを通る取引を観測でき、一部のプライバシー情報が漏れる恐れがあります。

ライトニングネットワークの安全性は、ビットコインのオフチェーン拡張能力およびユーザー資金の安全に直接影響します。そのため、一般的なパブリックチェーンの監査項目（詳細は本文末尾の付録参照）に加え、以下の重要なセキュリティリスクにも注意を払う必要があります。

チャネルの混雑：ライトニングネットワークシステムの設計が包括的であるか、悲観的攻撃（griefing attack）によってチャネルが混雑する可能性があるかを確認します。
チャネル妨害：チャネル構造の安全性を検証し、チャネル妨害攻撃（channel jamming attack）のリスクがないかを確認します。
チャネル資産のロック・アンロック：資産のロックおよびアンロックプロセスを審査し、ペイメントチャネルの開設・閉鎖時におけるオンチェーン・オフチェーン間の資金移動が安全かつ信頼できることを確認します。
状態更新と強制閉鎖：チャネルの状態更新プロセスおよび強制閉鎖（force-close）メカニズムを評価し、異常発生時に最新の状態を正しく識別・実行できるかを確認します。
タイムロックおよびハッシュタイムロック契約（HTLC）：HTLCの実装を評価し、タイムロックおよびハッシュロック条件が正しく実行されることを確認し、時間枠の問題による資金損失を防止します。
ブロックチェーンのタイムスタンプ依存：ライトニングネットワークがビットコインブロックチェーンのタイムスタンプに依存しているかを評価し、オンチェーン・オフチェーン間の時間同期が正確に行われ、タイム攻撃を防止できるかを確認します。
ルーティングアルゴリズムの安全性：ルーティングアルゴリズムの効率性と安全性を検証し、ユーザーのプライバシー漏洩や悪意あるルーティング操作のリスクを防止します。
チャネルのストレージとデータ復旧：チャネルの保存メカニズムおよびデータ復旧戦略を確認し、ノード障害や予期せぬ切断時にチャネル状態を復元でき、資金を失わないようにします。

サイドチェーン

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

サイドチェーンは独立したブロックチェーンとして、独自の合意形成メカニズム、ノード、取引処理ルールを持っています。特定のユースケースに応じて、メインチェーンとは異なる技術やプロトコルを採用することが可能です。双方向ペグ（2WP）メカニズムを通じて、メインチェーンと通信を行い、資産が両者間で自由かつ安全に移転されることを保証します。双方向ペグ（2WP）の動作メカニズムはおおよそ以下の通りです。

ユーザーがメインチェーン上でBTCをロックすると、信頼された機関1がSPV検証2を使用して、ユーザーのロック取引が確認されたかを確認します。
信頼された機関がサイドチェーン上でユーザーに等価のトークンを発行します。
ユーザーが自由に取引を行った後、サイドチェーン上で残りのトークンをロックします。
信頼された機関が取引の正当性を検証した後、メインチェーン上で対応する価値のBTCをユーザーに解放します。

注1：信頼された機関は双方向ペグメカニズムにおいてキーロールを果たし、資産のロックと解放を管理します。これらの機関は、ユーザー資産の安全を確保するために、高い信頼性と技術力を備えていなければなりません。

注2：SPV検証は、完全なブロックチェーンをダウンロードせずに特定の取引の有効性を検証できる仕組みです。SPVノードはブロックヘッダーのみをダウンロードし、Merkle Treeを使って取引がブロックに含まれているかを検証します。

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

CKB（Nervos Network）

Nervos Networkはオープンソースのパブリックブロックチェーンエコシステムであり、BTCのPoWコンセンサスが持つ安全性と分散性の利点を活かしつつ、よりスケーラブルで柔軟なUTXOモデルを導入して取引処理を行います。その核となるのがCommon Knowledge Base（CKB）で、RISC-Vアーキテクチャに基づき、PoW（作業量証明）をコンセンサスとするLayer1ブロックチェーンです。UTXOモデルをCellモデルへ拡張することで、任意のデータの保存や、任意の言語によるスクリプト（スマートコントラクト）の実行を可能にしています。

Stacks

StacksはPoX（Proof of Transfer）メカニズムを通じて、各Stacksブロックをビットコインブロックと紐付けます。スマートコントラクトの開発のために、Stacksは専用のClarityプログラミング言語を設計しました。Clarityでは、get-burn-block-info? 関数を使ってビットコインブロックの高さを指定し、そのブロックヘッダのハッシュを取得できます。また、burn-block-height キーワードによりビットコインチェーンの現在のブロック高さを取得可能です。これらの機能により、Clarityのスマートコントラクトはビットコインベースチェーンの状態を読み取り、ビットコイン取引をコントラクトのトリガーとして利用できます。これにより、Stacksはビットコインの機能を拡張しています。

Stacksに関する詳細な分析は、Beosinの過去のリサーチ記事をご覧ください：《Stacksとは？BTCレイヤー2ネットワークStacksが直面する可能性のある課題とは？》

サイドチェーンの利点は以下の通りです。

サイドチェーンは異なる技術やプロトコルを採用し、さまざまな実験や革新を行うことができ、メインチェーンの安定性や安全性に影響を与えません。
メインチェーンが持たない機能（例：スマートコントラクト、プライバシー保護、トークン発行など）を導入でき、ブロックチェーンエコシステムのユースケースを豊かにします。

一方で、サイドチェーンが直面する課題も存在します。

サイドチェーンは独立した合意形成メカニズムを持つため、BTCメインチェーンほどの安全性がない可能性があります。もしサイドチェーンのコンセンサスに脆弱性や欠陥があれば、51％攻撃などのリスクが生じ、ユーザー資産の安全が脅かされる可能性があります。BTCメインチェーンの安全性は膨大な計算力と広範なノード分布に依存していますが、サイドチェーンは同レベルのセキュリティを達成できないかもしれません。
双方向ペグの実装には複雑な暗号アルゴリズムとプロトコルが必要であり、そこに脆弱性があれば、メインチェーンとサイドチェーン間の資産移転に問題が生じ、資産の紛失や盗難につながる可能性があります。
速度と安全性のバランスを取るために、多くのサイドチェーンはメインチェーンよりも高い中央集権性を持っています。

Layer2は完全なブロックチェーンシステムであるため、パブリックチェーンの一般的な監査項目はサイドチェーンにも適用されます。詳細は本文末尾の付録を参照してください。

さらに、その特殊性から、サイドチェーンには以下の追加監査が必要です。

コンセンサスプロトコルの安全性：サイドチェーンのコンセンサスプロトコル（PoW、PoS、DPoSなど）が十分に検証・テストされており、51％攻撃、長期攻撃（long-range attack）などの潜在的な脆弱性や攻撃ベクトルがないかを確認します。
コンセンサスノードの安全性：コンセンサスノードの安全性を評価し、鍵管理、ノード保護、冗長バックアップなどを含め、ノードが攻撃されたり悪用されたりしないかを確認します。
資産のロックと解放：サイドチェーンとメインチェーン間の双方向ペグメカニズムを審査し、資産のロック・解放を行うスマートコントラクトが安全かつ信頼できることを確認し、二重使用（double spend）、資産喪失、ロック失敗などが起きないよう検証します。
クロスチェーン検証：クロスチェーン検証の正確性と安全性を確認し、検証プロセスが分散化されて改ざん耐性を持っているか、検証失敗や悪意ある検証を防げるかを検証します。
コントラクトコード監査：サイドチェーン上で稼働するすべてのスマートコントラクトを深く監査し、特にクロスチェーン操作に関わるコントラクトロジックに脆弱性や裏門（backdoor）がないかを検出します。
アップグレードメカニズム：スマートコントラクトのアップグレードメカニズムが安全か、適切な監査およびコミュニティ合意プロセスがあるかを確認し、悪意あるアップグレードやコントラクト改ざんを防止します。
ノード間通信：サイドチェーンノード間の通信プロトコルが安全か、中間者攻撃やデータ漏洩を防ぐために暗号化チャネルが使用されているかを確認します。
クロスチェーン通信：サイドチェーンとメインチェーン間の通信チャネルを確認し、データの完全性と真正性を保ち、通信の乗っ取りや改ざんを防止します。
タイムスタンプとブロック時間：サイドチェーンの時間同期メカニズムを検証し、ブロック生成時間の一貫性と正確性を確保し、時間差による攻撃やブロックロールバックを防ぎます。
オンチェーンガバナンスの安全性：サイドチェーンのガバナンスメカニズムを審査し、投票、提案、意思決定プロセスの透明性と安全性を確保し、悪意ある支配や攻撃を防止します。
トークンエコノミー監査：サイドチェーンのトークンエコノミーモデル（トークン分配、インセンティブメカニズム、インフレーションモデルなど）を検証し、経済的インセンティブが悪意ある行動やシステム不安定を引き起こさないよう確認します。
手数料メカニズム：サイドチェーンの取引手数料メカニズムを確認し、メインチェーンおよびサイドチェーンユーザーのニーズに合致しており、手数料操作やネットワーク混雑を防げるかを検証します。
資産の安全性：オンチェーン資産の管理メカニズムを監査し、資産の保管、移転、破棄プロセスが安全かつ信頼でき、不正アクセスや盗難のリスクがないかを確認します。
鍵管理：サイドチェーンの鍵管理戦略を確認し、秘密鍵の安全性とアクセス制御が確保されており、鍵の漏洩や悪用を防げるかを検証します。

Rollup

Rollupは、ブロックチェーンの取引スループットと効率を向上させるためのLayer2拡張ソリューションです。大量の取引をまとめて（「Rollup」）オフチェーンで処理し、その結果のみをメインチェーンに提出することで、メインチェーンの負担を大幅に軽減します。

Rollupは主にzk-Rollupとop-Rollupに分けられます。ただしETHとは異なり、BTCはチューリング完全でないため、ゼロ知識証明の検証をスマートコントラクトで実行できません。従来のzk-RollupソリューションはBTC上で実現できません。それでは、どのようにしてBTCのLayer2にzk-Rollupを適用できるのでしょうか？ここではB² Networkプロジェクトを例に説明します。

BTC上でゼロ知識証明の検証を実現するため、B² NetworkはTaprootスクリプトを創出しました。これはzk-Rollupのゼロ知識証明検証とop-Rollupのインセンティブチャレンジを組み合わせています。その動作メカニズムは以下の通りです。

B² Networkはまず、ユーザーが発信したすべての取引をRollupします。
ソーターがRollup取引を順序付けした後、分散型ストレージに保存し、同時にzkEVMに処理を委ねます。
zkEVMはBTCチェーンの状態を同期した後、コントラクト実行などの取引を処理し、結果をまとめ、アグリゲータに送信します。
Proverがゼロ知識証明を生成しアグリゲータに送信、アグリゲータは取引と証明をまとめてB² Nodesに送信します。
B² Nodesはゼロ知識証明を検証し、分散型ストレージ内のRollupデータを使ってTaprootスクリプトを作成します。
Taprootは1 satoshiの価値を持つUTXOであり、そのデータ構造内のB² InscriptionにはすべてのRollupデータが格納され、Tapleafにはすべての証明の検証データが保存されます。インセンティブチャレンジメカニズムを経た後、zk証明検証のコミットメントとしてBTCに送信されます。

Rollupの利点は以下の通りです。

Rollupはメインチェーンの安全性と分散性を継承します。定期的に取引データと状態をメインチェーンに提出することで、データの完全性と透明性を確保します。
Rollupは既存のブロックチェーンネットワーク（例：イーサリアム）にシームレスに統合可能であり、開発者は既存のスマートコントラクトやアプリを大幅に変更することなくその利点を活用できます。
Rollupは多数の取引をオフチェーンで処理し、まとめて1つのバッチとしてメインチェーンに提出することで、取引処理能力を大幅に向上させ、TPS（1秒あたりの取引数）を著しく増加させます。
Rollup取引はオフチェーンで処理されるため、オンチェーン取引に必要な計算リソースとストレージスペースを大幅に削減し、ユーザーの取引手数料を著しく低下させます。

Rollupが直面する課題は以下の通りです。

オフチェーンデータが利用不可の場合、ユーザーは取引を検証したり状態を復元したりできなくなる可能性があります。
Rollup取引はバッチ処理され、最終的にメインチェーンに提出されるため、決済に時間がかかることがあります。特にop-Rollupでは異議期間（dispute period）があり、ユーザーは取引の最終確定まで長い待ち時間が発生する可能性があります。
zk-Rollupは高い安全性と即時確定を提供しますが、計算およびストレージの要件が高く、ゼロ知識証明の生成には大量の計算リソースが必要です。

採用されたソリューションがRollupであるため、重点的なセキュリティ監査項目はETH Layer2と基本的に一致します。

その他（Babylon）

従来のBTC Layer2に加え、最近ではBTCエコシステムに関連する全く新しい概念のサードパーティプロトコルも登場しています。その一例がBabylonです。

Babylonの目標は、2100万BTCを分散型ステーキング資産に変えることです。他のBTC Layer2とは異なり、BabylonはBTCチェーンの拡張を行いません。それ自体が独自のチェーンであり、特別なBTC担保プロトコルを持ち、主にPoSチェーンとの接続を目的としています。BTCをステーキングすることでPoSチェーンに強固な安全性を提供し、遠隔からの攻撃リスクや中央集権化の問題を解決します。

アーキテクチャは3層に分かれます。

ビットコイン層：Babylonの堅固な基盤であり、ビットコインが持つ著名な安全性を利用して、すべての取引がビットコインネットワークと同様に非常に安全であることを保証します。
バビロン層：Babylonの核心であり、ビットコインとさまざまなステークプルーフ（PoS）チェーンを接続するカスタムブロックチェーンです。取引処理、スマートコントラクト実行を行い、エコシステム全体の円滑な運営を保証します。
PoSチェーン層：最上層は複数のPoSチェーンから構成され、それぞれの優れた特徴によって選ばれています。これにより、BabylonChainは驚異的なスケーラビリティと柔軟性を獲得し、ユーザーは異なるPoSブロックチェーンの最良の機能を享受できます。

その動作方式は、BTCチェーン上で最終ブロックに署名することでPoSチェーンを保護することです。これは本質的に基礎プロトコルを追加の署名ラウンドで拡張するものです。最後の+1ラウンドの署名には独特の特性があり、抽出可能なワンタイム署名（EOTS）です。目的はPoSチェックポイントをBTC上に統合し、PoSの長期アンステーキング期間と遠隔攻撃の問題を解決することです。

Babylonの利点は以下の通りです。

PoSのアンステーキング期間を短縮できる
BTCをステーキングすることで価格がBTCと連動し、対象PoSネットワークのインフレ圧力を緩和できる
BTCに新たな収益創出の道を開く

Babylonが直面する課題は以下の通りです。

ステーキング報酬率などの経済設計が、BTCのステーキング意欲に大きな影響を与える
PoSチェーン間の報酬整合性規定が不足している

サードパーティプロトコルは実装方法によって注目すべきセキュリティポイントが異なりますが、Babylonを例に挙げると、以下の監査項目に注意が必要です。

スマートコントラクトの安全性：BTC上のステーキングコントラクトはUTXOスクリプトで実現されており、その安全性に注意を払う必要があります。
署名アルゴリズムの安全性：コントラクトは署名でユーザーのステーキングを管理しており、そのアルゴリズムの安全性が署名の生成と検証に直結します。
プロトコルの経済モデル設計：報酬やペナルティなどの経済モデルが適切に設計されており、ユーザー資産の損失を招かないかを確認します。

付録：

パブリックチェーン & Layer2 共通監査項目

整数オーバーフロー：整数のオーバーフローおよびアンダーフローを確認
無限ループ：プログラムのループ判定条件が妥当か確認
無限再帰呼び出し：プログラムの再帰呼び出しの終了条件が妥当か確認
競合状態：並列状態下での共有リソースへのアクセス操作を確認
異常クラッシュ：プログラムを意図的に終了させる例外スローのコードを確認
ゼロ除算の脆弱性：ゼロ除算の状況がないか確認
型変換：型変換が正しく行われており、変換中に重要な情報が失われていないか確認
配列範囲外アクセス：配列境界を超える要素にアクセスしていないか確認
逆シリアル化の脆弱性：逆シリアル化プロセスに問題がないか確認
機能実装の安全性：各RPCインターフェースの実装にセキュリティ上の懸念がないか、またRPCインターフェースの機能設計と一致しているか確認
機能設計と一致
センシティブなRPCインターフェースの権限設定：センシティブなRPCインターフェースのアクセス権限設定が適切か確認
暗号化伝送メカニズム：TLSなどの暗号化伝送プロトコルを使用しているか確認
リクエストデータ形式の解析：リクエストデータの形式解析プロセスを確認
ウォレットアンロック攻撃：ノードがウォレットをアンロック中にRPCリクエストによって資金を盗まれるリスクを確認
従来のWebセキュリティ：以下の脆弱性がないか確認：クロスサイトスクリプティング（XSS）／テンプレートインジェクション／
サードパーティコンポーネントの脆弱性／HTTPパラメータ汚染／SQLインジェクション／XXEエンティティインジェクション／逆シリアル化脆弱性／SSRF脆弱性／コードインジェクション／ローカルファイルインクルード／リモートファイルインクルード／コマンド実行インジェクションなどの従来の脆弱性
ネットワークノードの認証および識別メカニズム：ノード識別メカニズムの存在を確認し、それがバイパス可能かを検証
ルーティングテーブル汚染：ルーティングテーブルに自由にデータを挿入または上書きできるかを確認
ノード発見アルゴリズム：ノード発見アルゴリズムが均等かつ予測不能か（例：距離アルゴリズムの不均衡など）を確認
接続数使用監査：P2Pネットワークの接続ノード数の制限と管理が適切か確認
日蝕攻撃（Eclipse Attack）：日蝕攻撃のコストと被害を評価し、必要に応じて定量的分析を提供
シビル攻撃（Sybil Attack）：投票コンセンサスメカニズムを評価し、投票資格のチェック戦略を分析
盗聴攻撃：通信プロトコルがプライバシーを漏らしていないか確認
異種攻撃（Alien Attack）：ノードが同種チェーンのノードを識別できるかを評価
時間乗っ取り：ノードのネットワークトイム計算メカニズムを確認
メモリ枯渇攻撃：大量のメモリを消費する箇所を確認
ディスク枯渇攻撃：大容量ファイルの保存場所を確認
Socket負荷攻撃：接続数の制限戦略を確認
カーネルハンドル枯渇攻撃：ファイルハンドルなどカーネルハンドルの作成制限を確認
持続的なメモリリーク：メモリリークの発生箇所を確認
ハッシュアルゴリズムの安全性：ハッシュアルゴリズムの衝突耐性を確認
デジタル署名アルゴリズムの安全性：署名アルゴリズムの安全性および実装の安全性を確認
暗号化アルゴリズムの安全性：暗号化アルゴリズムの安全性および実装の安全性を確認
乱数生成器の安全性：重要な乱数生成アルゴリズムが適切か確認
BFT実装の安全性：BFTアルゴリズムの実装安全性を評価
フォーク選択ルール：フォーク選択ルールを確認し、安全性を確保
中央集権度の検出：システム設計に過度な中央集権設計がないか識別
インセンティブメカニズム監査：インセンティブメカニズムが安全性に与える影響を評価
二重使用攻撃：コンセンサスが二重使用攻撃を防御できるか確認
MEV攻撃監査：ブロック作成ノードのMEVがチェーンの公平性に与える影響を確認
ブロック同期プロセス監査：同期プロセス中のセキュリティ問題を確認
ブロックフォーマット解析プロセス監査：フォーマット解析プロセス中のセキュリティ問題（例：解析エラーによるクラッシュ）を確認
ブロック生成プロセス監査：ブロック生成プロセス中のセキュリティ問題（例：Merkle tree rootの構築方法の妥当性）を確認
ブロック検証プロセス監査：ブロック署名内容および検証ロジックが十分か確認
ブロック確認ロジック監査：ブロック確認アルゴリズムおよび実装が妥当か確認
ブロックハッシュ衝突：ブロックハッシュ衝突の構築方法および衝突時の処理が妥当か確認
ブロック処理リソース制限：孤立ブロックプール、検証計算、ディスクシークなどのリソース制限が妥当か確認
取引同期プロセス監査：同期プロセス中のセキュリティ問題を確認
取引ハッシュ衝突：取引ハッシュ衝突の構築方法および衝突時の処理を確認
取引フォーマット解析：フォーマット解析プロセス中のセキュリティ問題（例：解析エラーによるクラッシュ）を確認
取引合法性検証：各種取引の署名内容および検証ロジックが十分か確認
取引処理リソース制限：取引プール、検証計算、ディスクシークなどのリソース制限が妥当か確認
取引伸縮性攻撃：取引内部フィールド（例：ScriptSig）を変更して取引ハッシュを変更しても、取引の有効性に影響を与えないか確認
取引リプレイ攻撃監査：システムが取引リプレイを検出できるか確認
コントラクトバイトコード検証：仮想マシンがコントラクトを検証するプロセスのセキュリティ問題（例：整数オーバーフロー、無限ループなど）を確認
コントラクトバイトコード実行：仮想マシンがバイトコードを実行するプロセスのセキュリティ問題（例：整数オーバーフロー、無限ループなど）を確認
gasモデル：取引処理／コントラクト実行の各原子操作に対応する手数料がリソース消費に比例しているか確認
ログ記録の完全性：重要な情報がログに記録されているか確認
ログ記録の安全性：ログ処理中に不適切な処理によりセキュリティ問題（例：整数オーバーフローなど）が発生しないか確認
ログにプライバシー情報が含まれるか：ログに鍵などのプライバシー情報が含まれていないか確認
ログ保存：ログに過剰な内容が記録され、ノードリソースを消費していないか確認
ノードコードのサプライチェーンセキュリティ：すべてのサードパーティライブラリ、コンポーネント、パブリックチェーンフレームワークの既知の問題を確認