ちょっと難しいかもしれませんが、挑戦してみましょう🔥
Cardanoチェーンのコアシステムの構造
上記が全体像ですが、あなたはプールを運営している、と考えるとわかりやすいです…かなりざくっというとこんな感じです。ポイントは「細かく役割分担させるシステムになっている」というところです。何も考えずにノードを作ると、DBSyncの機能やWalletBackendの機能までノードに含めて作られていることもあります…(実際のところ、Byronの初期の設計ではこれらがミックスされていた側面がありました。)
しかし、とくに「プール、ノード」がやりたいことは突き詰めればブロックの生成=検証です。それ以上の機能がプールにあっても、開発が複雑になり、セキュリティの議論も複雑化するだけです。
RemoteNodes:あなた以外が運用している1,000以上のプールたち
Node process:あなたのプール
CLI:あなたがあなたのプールを操作したりする道具
WalletBackend:Daedalus
DBSync、PostgreSQL…:エクスプローラやプール情報集約ツールや取引所との連携などのツール
プールの構造の全体像
図は難しいですが、ざっくりいうと、
コンセンサス(取引に悪さがないか検証)+ネットワーク(ダイダロスや他のプールと通信)+データベース(誰が何ADA持っているかデータベース)
の3つで構成されていて、おまけで、監視ログシステムもついているようなイメージです。
これも、この4つが分離されているため、例えば「コンセンサス」だけをパワーアップするのが簡単です。自転車のタイヤをアップグレードしたいとき、タイヤが本体と分離できると簡単に交換できますよね、そんな感じです!
ネットワーク・コンセンサスを深くみていきましょう…なぜCardanoはこれをゼロから再開発する必要があったのですか?
POWは①攻撃側は防御側と比べて、攻撃に多大なコストがかかり、②ステートレスに、つまりチェーンのすべての状態を把握していなくても検証できます。
POSは①攻撃側がほぼ0コストで攻撃でき、②ステートフルな状態、つまりチェーンのすべての状態を把握し検証を行う設計が望ましいです。
したがって、いままでずっと研究されてきた普通のネットワークの技法では十分ではなく、0コストで攻撃していくる敵対者がいるなかでチェーンのすべての状態を把握し検証を行うことが必要なので、ゼロから開発される必要がありました。
チェーン伝送、検証、選択の3つの部分が相互に連結され、ネットワークが構築されます。
それでは、コンセンサスのデザイン原則などを確認しましょう!
原則:システムがオープンであるにもかかわらず(利害関係のない、または最小限の人がアクセス可能)、敵がお金を盗んだり、システム破壊を試み、ネットワークの負荷、帯域幅、レイテンシが大きく変動し、予測不可能なパブリック・インターネット上で、Cardanoのユーザーが有効なトランザクションを提出し、それが暗号通貨台帳の不変の接頭辞に組み込まれることに依存できることを、設計上保証
具体的には以下の3STEPでそのような実装を実現します。
- 学術論文:アルゴリズム数学的基礎。非常に弱い仮定でprogress (liveness) and persistenceを保証。
- 実装設計:
(a) 数学的記述と同等と示す(最初は非公式に、時間が許す限り正式な証明を行う)。
(b) 実世界でのPCで実装。
(c) 数学的に攻撃者がシステムを混乱破壊する可能性がない、または緩和策があること。 - ソフトウェア実装:
(a) テスト,プロパティチェック等を通じてチェックされるデザイン対応。
(b) 効率的で,モジュール化されており,保守が容易であること。
(c) 数学的に攻撃者がシステムを混乱破壊する可能性がない、または緩和策があること。
①Interleaving transmission and validation= Reliable chain broadcast; 送信+ Chain validation 検証+ Chain selection 選択
すべてのウロボロスバージョンでこの構図。95%で必ず全員に配信される。しかしこの送信機能だけで、チェーン全体の状態を把握せずに機能させることはできない。攻撃をあまりにもうけやすいから。
POWは仕組みそのものが正直運用者に有利ですが、POSは正直運用者と攻撃運用者が対等です。POWのヘッダーはほとんどコストをかけずにチェックでき、既存の送信システムに組み込めます。対するPOSは、POSは正直運用者と攻撃運用者が対等なのでいくらでも攻撃チェーンを作れます。さらに元帳全体を把握していないといけないので検証機能と選択機能に依存します。
- 各ノードは、現在のチェインを直属の隣人に送信します。(すべてではないので、論文やよくあるbroadcastシステムと違う!)
- 各ノードは、各隣人からの着信チェーンを検証します。
- 各ノードは候補のチェーンを選択します。
- 選択されたチェーンがノードの新しい現在のチェーンとなり、再び隣人に送信する準備が整います。
- ノードがスロットリーダである場合、ノードは新しいブロックで自分の現在のチェインを拡張します。
②Block/body splitting :ヘッダーとボディの分割:ブロック生成に必要なヘッダーだけを扱える、効率化され、DOS攻撃リスクも下げられる。
③Stateful chain-following :ステートフルチェーンフォロー :ステートレスか?ステートフルか?→セキュリティ、パフォーマンス等の点からステートフル:元帳全体の状態を把握する方法とした。
④Storage subsystem :ブロックハッシュではなく 、ブロックのスロット番号とブロックハッシュのペアでぽいんとを見つける仕組み。これはパフォーマンスの利点や、順序を整合させたりするのに役立つ。
コンセンサスの「パーツ」たちをみていきましょう!
以下を可能とするように、非同期設計で、監査、拡張容易なように、意図的にモジュール化しています。
- ブロックボディのダウンロード
- 新しいトランザクションの検証
- ブロック生成ノードへのトランザクションの転送
- チェーン同期、ブロックダウンロード、トランザクション送信を複数のアップストリームおよびダウンストリームのピアと同時並行で行う
chain databas ーチェーン元帳保存し永続性+チェーンにリンクしない浮いたブロック保持+ブロック最終検証実施+チェーン最終選択+チェーン元帳読取許可
chain sync client ーチェーンヘッダを検証しつつ取得する
block fetch ーチェーン選択し対応ブロックを取得する
chain sync server and block fetch server ーチェーンヘッダとブロックを送信する
mempool ー保留中のトランザクションのセットの保存と検証
tx-submission client ー tx を mempool へ入れる
tx-submission server ー tx を送信する
block forge ーノードがスロットリーダーになると新しいブロックを作成