SKALEとは
一言で言うと「AWSのようにElasticであり、巨大なファイルを格納できるのが特徴的なサイドチェーン」。先行するサイドチェーンに関する提案で、言及されていない、Nodeの効率的な運用方法と、キャパシティという実用問題に、一歩踏み込んで掘り下げている点が興味深い。
SKALEのサイドチェーンは1つのNode内にいくつも存在する仮想化されたSubnodeで構成される。必要に応じてSubnodeのサイズは柔軟に変更可能。これがElasticである由縁。また、独自拡張したEVMによって巨大ファイルの格納を可能にしている。EthereumメインネットではGas LimitとGas Costの両面から現実的ではない。
また、ConsenSys Labsやリクルートホールディングスといった名のある企業から計20億近く出資を受けている。
サイドチェーンの文献
サイドチェーン一般に関する解説はしないので、参考となりそうな文献を紹介する。
サイドチェーンの原典。Bitcoin Coreを開発してるBlockstream社の提案。
サイドチェーンの仕組みをわかりやすく解説している。
いくつか存在するサイドチェーンの方式を網羅的にまとめている。趣旨はDrivechainに関する提案。
SKALEの詳細
Whitepaperを元に、SKALEの詳細について見てゆく。
なお、ホワイトペーパーには「Consensus Protocol」や「Virtual Machine」「Parent Blockchain」に到るまでにがカスタマイズ可能という記述がある。したがって、以下はSKALEを使う上でのベーシックな設定。
Node
EthereumのEVMと互換性がある。よって、Ethereum用に開発したSmart Contractをそのまま動かせる。サイドチェーンなのでEtherumのメインネットでは容易に実現できないGas Limit等のカスタマイズが簡単にできる。
Nodeとして参加する方法
参加済Nodeの審査を通る必要がある。機器やネットワーク性能が審査対象。許可されると、後述するSKALE Managerに参加申請できるようになる。この時、ステークするSKALEトークンをデポジットする。
Nodeから離脱する方法
離脱を宣言し新しいNodeが割り当てられるまで待つ。離脱すると、デポジットしたトークンを引き出すことができる。このプロセスを経ない場合、Dead Nodeとみなされる。Node報酬は支払われす、いずれ削除される。
Subnode
SKALEではNodeをSubnodeに分割することで、エンタープライズレベルのパフォーマンスを実現している。Subnodeはdocker化されたLinux OSでSKALE daemon
を動かしており、それぞれが別のサイドチェーンに帰属する。
SubnodeはNode Core
によって管理される。これは3つの機能を持っている。
SKALE Admin Service
Nodeを管理し、EthereumにデプロイされたManagerと交信するためのUIを提供する。
Node Monitoring Service
NodeがペアリングしているNodeのパフォーマンスを監視する。監視対象はManagerから無作為に割り当てられる。監視項目はuptimeとlatencyで、定期的に疎通確認を行い結果を記録する。パフォーマンスの結果をもとに報酬が支払われる。
Virtualized Subnode Orchestration Service
Subnodeを起動しサイドチェーンにアサインしたり、Subnodeを解体しリソースを解放する。また、サイドチェーン間のメッセージ交信を担うエージェントを起動する。
Storage
それぞれのサイドチェーンにはFileStorageというSmart Contractがデプロイされ、最大で100MBのファイルを格納可能。SKALEのEVMは拡張されており、チェーンのBlockサイズを増やすことができる。なので、巨大なファイルをチェーンに格納できる。また、FileStorageからNodeのファイルシステムに直接アクセスできるような拡張も成されている。
ネットワーク内のストレージ資源を有効に使うため、削除することも可能。
SKALE Manager
Ethereumのメインネットにデプロイされたコントラクトで、SKALEエコシステムへのエントリーポイント。Mangaterが個別のサイドチェーンネットワークをマネジメントする。チェーンの作成と削除も範疇。
サイドチェーン作成
Mangerに希望するチェーンの設定を提出し、サイドチェーンを維持するのに必要な必要な費用を支払う。サイドチェーンが作成されると、アクセスするためのエンドポイントが発行される。サイドチェーンに必要なリソースが確保できない場合(全リソースの30%以上は常に利用できる状態にあるが)は、申請はキャンセルされる。
最小のサイドチェーン16のSubnodeで構成され、Subnodeのサイズは1/128 (small)
、 1/16 (medium)
、 1/1 (large)
の3パターンから選べる。
サイドチェーン削除
作成者が意図的に削除する場合と、チェーンを維持するためのデポジット額が枯渇した場合に起きる。後者の場合は、作成者に通知され猶予期間が設けられる。
削除処理はManagerによって実行される。残デポジットは作成者に戻され、チェーンの全てのリソースが解放される。そして、Nodeに報酬が支払われる。
※データは全て破棄されるので永続性はない。Ethereumメインネットとは違う。
Consensus
Asynchronous Byzantine Fault TolerantなPOS。Casper FFGのようなファイナリティガジェットはない。Bitcoinのように非決定的に「いつかは」合意に達する。
POSなので、チェーンの合意形成に参加するにはSKALEを事前にステークする必要がある。Subnodeの選定方法は従来のPOSと異なる。ネットワークのレイテンシーや稼働時間をもとにランダムで選ばれる。ステーク量による荷重がかからない点が異なる。
コンセンサスに参加できるSubnode数は24で、全体の2/3より多くが公正ならば、チェーンの合意形成は正常に行われる。トランザクションはQueueに蓄積される。全てのSubnodeが新しいブロックをProposeできる。SubnodeAを例に以降のプレロセスを説明する。
SubnodeAはMAX_BLOCK_SIZE
以下になるようにトランザクションを古いものから順次ピックアップして、新ブロックを作る。そして、Data Availability Protocol
によって、他の全Subnodeへブロックをブロードキャストする。受け取ったSubnodeは新ブロックを検証し、問題なければThreshold Signature Share
をSubnodeAに返却する。SubnodeAが全体の2/3以上のsignature sharesを受け取ったらSupermajority Signature
を作り、ブロードキャストする。全体の2/3以上の承認を得た新ブロックで投票を行う。1票以上獲得した新ブロックの中から1つのブロックがランダムに選ばれる。SubnodeAが選ばれたとして、SubnodeAはSupermajority Signatureに署名して、新ブロックをブロードキャストする。2/3以上の承認を得たら、新ブロックをコミットする。
従来のPOSは、マイニングを行うリーダーNodeを無作為に選定する。一方、SKALEにはリーダーNodeがそもそも存在しない。
Reward
Nodeは互いにuptimeとlatencyを監視している。結果マトリクスをSKALE Managerに定期的に報告する。24のペアノードから監査され、ノード報酬が決まる。
報酬は、期間内にマイニングされたトークンを16Nodesで均等割する形で支払われる。ネットワークに参加するNode数は計24なので、残りの8Nodeは除外される。対象は、結果マトリクスの上位と下位4Node。上位4Nodeが除かれるのは、悪意あるグループが結託して不正を働く可能性を下げるため。
報酬は、Subnode単位で集計されるがNode単位で支払われる。したがって、Subnodeの一部が意図せずダウンしたとしても、別Subnodeが正常稼働している限り、報酬が支払われる。
なお、報酬はSKALEトークンで支払われる。
Governance
Governanceに関連する権限はSKALE Labs
が設立したN.O.D.E. Foundation
から、オンチェーン投票制に移譲される予定。そして、NODE Foundationはオンチェーン投票が円滑に進むよう尽力する。
一般的なPOSと同じく、SKALEトークンの保有率に応じて票に重がつく。また、トークンは90日以上ステークされている必要がある。デフォルトの投票システムでは、14日の投票期間の後、シンプルに最大投票数を獲得したものがProposalが勝者。
参考:SKALE Network: Open Source and Foundation Launch
Interchain Comunication
SKALEではサイドチェーン間のコミュニケーションが可能。
これはEthereumメインネットにチェーン毎にデプロイされたMessageProxy
というコントラクトで実現する。
送信者は、メッセージを自身のMessageProxyに送信する。すると、EthereumのEventが発火する。これを受信側のMessage Transfer Agent
がWatchする。つまり、受信側が送信側をリッスンしている必要がある。そして検証の後、受信側のMessageProxyに格納する。そして、受信側のチェーンで処理される。