al1ex/blockchainconstructionBlockChain Security Construction
この記事では、主に注目に値するパブリックチェーン監査のいくつかの側面を紹介します。セキュリティ監査者とパブリックチェーン開発者にとって、これは参考と考察に値するプロジェクトです。
パブリックチェーンシステムの構築を紹介する前に、ブロックチェーンのアーキテクチャを見てみましょう。
ブロックチェーン1.0時代：
アーキテクチャ：下図のとおり
代表的な製品：bitcoin、reborn coin、dogcoin、Leyte coin、MasterCard coinなど
ブロックチェーン2.0時代：
アーキテクチャ：下図のとおり
代表的な製品：Ethereum、lisk、hyperledgerなど
主な変更点：
ブロックチェーン2.0時代
アーキテクチャ：下図のとおり
代表的な製品：EOS、VaR、AE、ash、ELA、dfinity
主な変更点：金融業界以外のあらゆる分野におけるブロックチェーンのアプリケーションシナリオが、より複雑なビジネスロジックに対応できるようになったこと
次に、ブロックチェーンのアーキテクチャに基づき、ブロックチェーンのパブリックチェーンにおけるセキュリティ構築で検討に値する問題について簡単に紹介します。これらの問題の約75％がパブリックチェーンのセキュリティ問題を引き起こしており、パブリックチェーンのセキュリティ監査においても注目に値するポイントです。ここでは、思考を促すために質問形式で提示します。さらに議論したい場合は、issueで直接行うことができます：
データ層は最下層の技術であり、その主な機能はデータストレージ、アカウントとトランザクションの実装、およびセキュリティです。データストレージは主にマークルツリーに基づいており、ブロックとチェーン構造によって実現されます。そのほとんどはKVデータベースによって永続化されています。例えば、bitcoinや、Ethereumが採用しているleveldbなどです。
データ層に関しては、以下の点が検討に値します：
ネットワーク層の主な目的は、ブロックチェーンネットワークのノード間における情報のやり取りを実現することです。ブロックチェーンの本質はピアツーピア（P2P）ネットワークです。各ノードは情報を受信できると同時に、情報を生成することもできます。ノードは共通のブロックチェーンを維持することで通信を維持します。ブロックチェーンネットワークでは、各ノードが新しいブロックを作成できます。新しいブロックが作成されると、ブロードキャストによって他のノードに通知されます。そして、他のノードがそのノードを検証します。ブロックチェーンネットワーク内の51％以上のユーザーが検証を通過すると、新しいブロックがメインチェーンに追加されます。
ネットワーク層に関しては、以下の点が検討に値します：
パブリックチェーンのノード発見アルゴリズムの設計は合理的か？
パブリックチェーンのノード設計は合理的か？
罰則メカニズムの設計は合理的か？
通信プロトコルの設計は合理的か？
パブリックチェーンノードのリクエスト処理設計は合理的か？
リクエスト処理パケットのサイズに制限はあるか？
パブリックチェーンのトランザクション通信メカニズムの設計は合理的か？
ブロックデータの同期メカニズムは合理的か？
トランザクション処理のロジック設計は合理的か？
コンセンサス層は、分散システムにおいて高度に分散されたノードがブロックデータの有効性についてコンセンサスに達することを可能にします。稼働中のすべてのブロックチェーンは、ブロック出力の有効性と順序を保証するためにコンセンサスアルゴリズムを必要とします。一般的なコンセンサスアルゴリズムには、pow、POS、dpos、Poa、POCなどがあります。
コンセンサスレベルでは、以下の点を考慮すべきです：
パブリックチェーンのコンセンサスアルゴリズムの設計は安全か？
パブリックチェーンのコンセンサス検証の設計は合理的か？
パブリックチェーンのコンセンサス没収の設計は合理的か？
パブリックチェーンのサービス手数料の設計は合理的か？
パブリックチェーンのマイニング設計は合理的か？
ブロック難易度の動的調整の設計は合理的か？
ブロック難易度チェックのロジック設計は合理的か？
チェーン再編成、チェーンリセット、チェーン分岐などの設計はどうか？
パブリックチェーンのインセンティブ層の目的は、ブロックチェーンのセキュリティ検証にノードが参加することを促すための一定のインセンティブ施策を提供し、ブロックチェーンエコシステムのバランスと健全な発展を保証することです。分散型パブリックチェーンでは、ルールを遵守する記帳参加ノードを奨励するための対応するインセンティブメカニズムを設定し、ルールを遵守しない記帳参加ノードを罰するための罰則メカニズムを確立する必要があります。ブロックチェーンのインセンティブ層は、ブロックチェーン技術システムに経済的要因を導入し、エコシステム内の組織的協力と価値交換の効率を向上させます。パブリックチェーンのインセンティブメカニズムは、ブロックチェーンの健全な発展を保証する重要なメカニズムです。
インセンティブレベルに関しては、以下の点が検討に値します：
パブリックチェーンの発行メカニズムの設計は合理的か？
パブリックチェーンの罰則メカニズムの設計は合理的か？
コントラクト層は、ブロックチェーンシステムのさまざまなスクリプトコードとアルゴリズム、およびそれらから生成されるより複雑なスマートコントラクトをカプセル化します。データ層、ネットワーク層、コンセンサス層の3つのレベルが、ブロックチェーンの基盤となる「仮想マシン」として、それぞれデータ表現、データ伝播、データ検証の機能を担うとすれば、コントラクト層はブロックチェーン仮想マシンに基づくビジネスロジックとアルゴリズムであり、ブロックチェーンシステムの柔軟なプログラミングとデータ操作を実現するための基盤です。bitcoinを含むほとんどのデジタル暗号通貨は、非チューリング完全な単純なスクリプトコードを使用してトランザクションプロセスをプログラムおよび制御しており、これもスマートコントラクトの原型です。技術の発展に伴い、Ethereumなどのチューリング完全なスクリプト言語が登場し、より複雑で柔軟なスマートコントラクトを実現できるようになり、ブロックチェーンはマクロな金融システムや社会システムの多くのアプリケーションをサポートできます。
コントラクト層に関しては、以下の点を考慮すべきです：
コントラクト仮想マシンのセキュリティ設計はどうか？
コントラクトのデプロイ/実行/インターフェースはどうか？
スマートコントラクトに関連するセキュリティはどうか？
アプリケーション層は、ブロックチェーンのさまざまなアプリケーションシナリオとケースをカプセル化します。これは、コンピュータ上のさまざまなソフトウェアプログラムに似ています。一般ユーザーが実際に直接使用できる製品であり、B/Sアーキテクチャ製品におけるブラウザとして理解することもできます。
アプリケーション層に関しては、以下の点を考慮すべきです（パブリックチェーンのみを対象とし、ウォレットアプリ/取引所/DEFIなどは対象としません）：
ウォレットアカウントのCRUDロジック設計はどうか？
ウォレットのインポート・エクスポート権限は確認されているか？
ウォレットパスワードの複雑さの設計はどうか？
ウォレットアカウントアドレスの有効性は確認されているか？
パブリックRPCインターフェースは外部のパブリックネットワークを必要とするか？
パブリックチェーンのRPCインターフェースの権限は明確に分離されているか？
パブリックRPCインターフェースに機密系の操作はあるか？
パブリックRPCインターフェースは例外を処理しているか？
パブリックチェーンRPCインターフェースのデータ処理の最大制限はどうか？
パブリックチェーンRPCインターフェースのリクエストデータのエンコードとデコードはどうか？
パブリックチェーンのRPCリクエスト処理でSSLは有効か？
パブリックチェーンにおける高並行リクエスト処理の設計はどうか？
最大接続数は設定されているか？
パブリックチェーンのWeb UIインターフェースはリモートアクセスを許可しているか？
パブリックチェーンのwebuiインターフェースにWeb系の脆弱性はあるか？
パブリックチェーンのwebuiインターフェースはパスワード情報のローカル保存を許可しているか？
実際、パブリックチェーンには「コード層」は存在しません。ここで筆者がこれを提案するのは、主にパブリックチェーン開発の過程で考慮が必要となる可能性のある問題を分類するためです：
パブリックチェーン開発言語の特徴。例えば、Go言語のデータ読み取りにおけるreadall()やappendの特徴など
パブリックチェーン開発言語のバージョン。例えば、Go言語の一部のバージョンにはリモートコマンド実行の脆弱性があります
パブリックチェーン開発仕様のコーディング。例えば、ヌルポインタ、スライシング、例外処理などの操作
パブリックチェーンの暗号化・復号処理。例えば、長さチェックなしの高複雑度なエンコード・デコードなど
データ型変換処理。例えば、hextobyte、integer. Parseint()など
基本的なビジネスロジック設計。例えば
上記のブロックチェーンアーキテクチャレベルで検討に値する問題に加えて、以下のセキュリティ問題も考慮する必要があります：
データストレージは暗号化されているか？
ファイルの権限設定は合理的か？
実行環境は安全か？
ノードはroot以外で起動されているか？
ノード側に脆弱性のあるWebサービスはあるか？
ノードのサーバー側に安全でない設定はあるか？
ノードのサーバー側に不正アクセスの脆弱性はあるか？
ノードのサーバー側でSSHアカウントのパスワードが漏えいしていないか？
51%攻撃
パブリックチェーンのハードフォーク
計算力のハイジャック（ワームがマイニングマシンに感染）
脆弱性のあるサードパーティライブラリを使用していないか。例えば、Jackson databind、fastjsonなど
脆弱性のあるミドルウェアを使用していないか。例えば、低バージョンのtendermintなど
クロスチェーンの方式は信頼性が高く、適切か？
同型クロスチェーンと異種クロスチェーンの実装方式はどうか？
上記のセクションのセキュリティ問題を再確認する
issueで関連する問題のディスカッションに直接参加してください。
