Cosmos Validator Part 1 ~小宇宙を覗く~
3月13日 7 PM EST に Cosmos Hub のメインネットがローンチされました。バリデータはブロック生成やガバナンスに参加するノードです。Cosmos Hubでは PoS（Proof of Stake）を採用しているためステーキングトークンである Atoms の重みが重要になってきます。この記事ではバリデータおよび Atoms を委譲するデリゲータの概要とフルノードを動かす手順について解説しています。バリデータの構築はまた次回で行います。
※ Inter-Blockchain Communication（IBC）はまだドラフト中です
バリデータ
Cosmos Hub は Tendermint ベースのパブリックブロックチェーンで、 PoS（Proof of Stake）による合意形成を執り行うバリデータにより運用されています。バリデータはフルノードを運用し、自身の秘密鍵を使用してブロック生成の投票へ参加します。ステーキングトークンである Atoms の比率によって、ブロックを提案できる頻度やトランザクションによる報酬が変化するため、この Atoms のステーク量は非常に重要です。[1]
バリデータになるためには２つの技術的な必要条件があります。
- フルノードを運用する（サーバやコンピュータ）
- declare-candidacyトランザクションを送付する
また追加条件で Atoms のステーク量が上位でないとバリデータにはなれないようになっています。現段階（初年度）では上位 100 位までですが、次年度には上位 113位までがバリデータになれます。事前に10年後までのバリデータ数が決定していて、2029年次で上位 300 位のノードがバリデータとして稼働する予定です（以下表を参照のこと）。
フルノードを運用していても declare-candidacy のトランザクションを送出しない、もしくは各段階で明記されている上位バリデータになっていない場合はバリデータとしてフルノードを運用することはできません（バリデータではない単純なフルノードです）。
バリデータを運用する上では以下のような対応も求められます。
- 最新のソフトウェアへのアップデート
- ガバナンスプロセスへの参加 — 全提案への投票が義務付けられる
- セキュリティと可用性 — 秘密鍵の保全とアップタイム
フルノードがバリデータとしてネットワークに参加するには declare-candidacy トランザクションを送信する必要があります。以下のようなパラメータを設定します。
- Validator’s PubKey: バリデータの公開鍵、
prevotesおよびprecommitへ署名するために使用される秘密鍵に対応する、バリデータはこの署名用のアカウントおよび Atoms を保有するアカウントなど複数のアカウントを保有できる - Validator’s name: バリデータの名前
- Validator’s website (オプショナル): バリデータのWebサイト、なくてもよいがバリデータの運営会社についてや運営方法について情報を掲載できる
- Validator’s description (オプショナル): バリデータの説明
- Initial commission rate: 初期コミッションレート
- Maximum commission: 最大コミッションレート
- Commission change rate: 日別のコミッションの可能な最大の変化量
- Minimum self-bond amount: バリデータが自身でステークする Atoms の最低量、この数値を下回った場合はプールのすべてステークが解除される（非常に危険ｗ）
- Initial self-bond amount: バリデータの Atoms ステークの初期値
フルノードがこの宣言を行いバリデータとなると、他の Atoms 保有者はこのバリデータのプールに Atoms をステーキングできるようになります。バリデータ自身の Atoms もプールへ Self-bond できるので、ステーキングプールのトータルはバリデータ自身がステークした分とデリゲータがこのバリデータにステークした合計です。
バリデータはデリゲータのステークした Atoms を盗むことはできませんが、アップタイムの低下やハッキングなどの被害によるペナルティによってデリゲータは Atoms を失う可能性があります。
デリゲータ
デリゲータはフルノードを運用しない、または運用していてもバリデータとして Cosmos Hub に参加したくない Atoms 保有者で、Atoms をバリデータへ預けるユーザのことです。バリデータへ権限を委譲することで、ブロック生成やガバナンスへ間接的に関与します。責任を共有することと同時に、ステークした Atoms の比率に応じて報酬（リワード）を得ることができます。
ただしバリデータによる不正行為や発生した障害によってステークした Atoms がスラッシュにより減損される可能性があります。
Deligators share revenue with their validators, delegators also share responsiblity. Should a validator misbehave, each of its delegators will be partially slashed in proportion to their stake.
したがってデリゲータはバリデータに対してデューデリすることが重要で、場合によってステークするバリデータを分散させるなどのリスクオフの姿勢が必要でしょう。
この点は分散投資とも考え方が似てくるかもしれません。スプリターネットなどの地政学的リスクも考え、ステークするノードは国や地域を分ける、もしくはトップのバリデータと比較的中位のバリデータでステーク先を分けるなど様々な手法が考えられます。
後で述べますがトップバリデータはハッキングや DoS 攻撃の対象となりやすいためスラッシュの可能性が高まります。
デリゲータがバリデータを選定する主な基準を見てみましょう。
- バリデータ自身の Atoms ステーク — バリデータがプールにどれぐらいの Atoms を自身でステークしているかを評価します
- デリゲートされている Atoms ステーク — デリゲータからどれぐらいの Atoms を合計でステークされているかを評価します、多くのデリゲータからデリゲートされていることで信用が高まります
- コミッションレート — 報酬に対するコミッションレートの高低を評価します
- トラックレコード — バリデータ歴などの情報を評価します、過去の提案（プロポーサル）への投票履歴、アップタイムやハッキングによる不正攻撃にあったかなどの情報が含まれます
バリデータは自身のWebサイトなどでも情報を公開するなどしてレピュテーションに配慮した運営を行う必要がありますが、同時に多くの情報を公開することはハッカーにとっても都合がよいためリスクとのバランスを考慮した上でノード運用を行う必要があります。
ステーキングにより得られる報酬は数種類ありますが、計算方法などについては他に詳しい解説がありますので割愛します。[3]
スラッシング
Deligators share revenue with their validators, delegators also share responsiblity. Should a validator misbehave, each of its delegators will be partially slashed in proportion to their stake.
バリデータにおける不正行為や障害によってプールにステークした Atoms がスラッシュ（毀損）される可能性があります。バリデータおよびデリゲータともにスラッシングの影響をうけるためデリゲータはどのバリデータへステークするか慎重に検討する必要があります。
スラッシングの対象となる行為は主に３つです。
- Double Signing（二重署名） — あるバリデータが Chain A と Chain B において同じブロック高へ署名した、ということを誰かが Chain A で報告した場合に Chain A でバリデータがスラッシュされる、現在のローンチ段階では 5% のペナルティが規定されています（Cosmos / ATOM Staking Guide）
- Unavailability（可用性） — バリデータの署名が直近の X ブロックへ含まれていない場合、X に比例した限界額がスラッシュされる、現在のローンチ段階ではバリデータが 10,000 ブロックウィンドウでその 95% を見逃した場合に 0.01 %のペナルティが課されています（Cosmos / ATOM Staking Guide）
- Non-voting（未投票） — バリデータは提案（プロポーザル）への投票が義務付けられている、未投票であることが報告されると少額のスラッシュが発生する
上記以外にもアップタイムの低下や、DDoS などの被害に合った場合、また秘密鍵漏洩などのハッキング被害にあった場合もスラッシュされるようです。詳細はまた追って公開されるとのことです。
また注意点としてステークした Atoms を引き揚げるunbonding transaction の間にもスラッシュされる可能性があるようです。このプロセスは 3 週間かかります。
フルノードを構築
公式サイトのサービスプロバイダーの章にフルノードの構築について書かれています。Rest Server や Rest API についても記載されていますが、今回はフルノード構築の部分のみやってみたいと思います。[5]
※環境は Ubuntu 16.04.1 LTS です
- Full-nodes: To interact with the blockchain
- Rest Server: This acts as a relayer for HTTP calls
- Rest API: Define available endpoints for the Rest Server
メインネットの chain-id は現在 cosmoshub-2 です。 cosmoshub-1 から cosmoshub-2 へのアップグレードについては以下の記事が参考になります。[6]
Goのインストールは gvm を使いましょう。 gvm はGo Version Managerでローカルで複数のバージョンのGoを管理できるようになります。 ruby の rbenv や python の pyenv といったツールの Go 版です。[8]
インストールします。
$ bash < <(curl -s -S -L https://raw.githubusercontent.com/moovweb/gvm/master/binscripts/gvm-installer)
Cloning from https://github.com/moovweb/gvm.git to /home/.gvm
which: no go in (/home/.nvm/versions/node/v10.15.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/bin)
No existing Go versions detected
Installed GVM v1.0.22Please restart your terminal session or to get started right away run
`source /home/.gvm/scripts/gvm`$ source .gvm/scripts/gvm
$ gvm version
Go Version Manager v1.0.22 installed at /home/.gvm
gvm listall でローカルにインストールできるバージョンを確認します。 go1.12.x があることを確認してください。Go 1.12+以上でないと Gaia が動作しません。
$ gvm install go1.12.3 --binary
Installing go1.12.3 from binary source
$ gvm use go1.12.3 --default
Now using version go1.12.3Go のインストールは完了です。
次にCosmos SDKのアプリであるGaiaとそれをインタラクティブに操作する CLI ツールの gaiacli をインストールします。Cosmos SDKのリポジトリをクローンして、v0.34.x のいずれかをチェックアウトしてビルドしていきます。[9]
$ mkdir -p $GOPATH/src/github.com/cosmos
$ cd $GOPATH/src/github.com/cosmos
$ git clone https://github.com/cosmos/cosmos-sdkThe current version of Gaia running the Cosmos Hub (v0.34.x) is NOT maintained in this repository. Gaia and the Cosmos SDK have been recently split. All future versions of Gaia, including the next major upgrade, will be maintained in this repository. However, until the next major upgrade, Gaia should be fetched and built from the latest released v0.34.xversion in the SDK repository. In addition, this repository should be considered unstable until the next major release of Gaia. Please bear with us while we continue the migration process and update documentation.
ここでは v0.34.7 を選択しています（v0.34.3では Error on replay: Wrong Block.Header.AppHash のエラーが発生しました）。
$ cd cosmos-sdk/ && git checkout v0.34.7
HEAD is now at 1127446... Release v0.34.7
$ makego install -mod=readonly ./cmd/gosum/
go: finding github.com/tendermint/tendermint v0.31.4
go: finding github.com/rs/cors v1.6.0
...? github.com/cosmos/cosmos-sdk/x/staking/tags
ok github.com/cosmos/cosmos-sdk/x/staking/types 0.077s
gaiad というガイアのデーモンと gaiacli のツールが正しくインストールされていることを確認します。
$ gaiad version --long
cosmos-sdk: 0.34.7
git commit: 1127446f71fa6aeada1bce2718f7f903cc18e548
vendor hash:
build tags: netgo ledger
go version go1.12.3 linux/amd64$ gaiacli version --long
cosmos-sdk: 0.34.7
git commit: 1127446f71fa6aeada1bce2718f7f903cc18e548
vendor hash:
build tags: netgo ledger
go version go1.12.3 linux/amd64
gaiad init コマンドでコンフィグファイルを生成します。 <moniker> にはノードを識別できる名前を入力してください。※あとから .gaiad/config/config.tomlで変更可能です
$ gaiad init <moniker>
{
"moniker": "<moniker>",
"chain_id": "test-chain-gJkOVx",
"node_id": "b0cde30064515ddbc92dbe99f4391e23926ef4a2",
"gentxs_dir": "",
"app_message": {
"accounts": null,
"auth": {
"collected_fees": [],
"params": {
"max_memo_characters": "256",
"tx_sig_limit": "7",
"tx_size_cost_per_byte": "10",
"sig_verify_cost_ed25519": "590",
"sig_verify_cost_secp256k1": "1000"
}
...
デフォルトの genesis.json ファイルを削除し、メインネット cosmoshub-2 の genesis.jsonファイルをダウンロードしてきます。
$ rm .gaiad/config/genesis.json
...$ cd .gaiad/config/
$ wget https://raw.githubusercontent.com/cosmos/launch/master/genesis.json
gaiad startコマンドでノードを起動します。
$ gaiad start --log_level="*:info"Couldn’t connect to any seeds と表示される場合は、 Ctrl + X でノードを止めてピアの設定をする必要があります。
ここでは Seed Nodesの１つを persistent_peers に設定してみました。[10]
.gaiad/config/config.toml の中でピアを設定できます。
# Comma separated list of nodes to keep persistent connections to
persistent_peers = "3e16af0cead27979e1fc3dac57d03df3c7a77acc@3.87.179.235:26656"再度ノードを起動しましょう。ピアとのやり取りが確立していることが確認できました。
$ gaiad start --log_level="*:info"
gaiacli コマンドでステータスが確認できます。ブロックが完全にシンクするまでは少し時間がかかります。
$ gaiacli status
{"node_info":{"protocol_version":{"p2p":"7","block":"10","app":"0"},"id":"e1d334ec62d9cf137fe03fcd3badefbb3b7fcc81","listen_addr":"tcp://0.0.0.0:26656","network":"<moniker>","version":"0.31.4","channels":"4020212223303800","moniker":"cosmos-hub.com","other":{"tx_index":"on","rpc_address":"tcp://0.0.0.0:26657"}},"sync_info":{"latest_block_hash":"7D8926A4FE119596462804C2D93EA531C897F9FB4441FAE8E3839226A358F5C6","latest_app_hash":"D9CD410079D342D2C6AA92FB1B070742F4CD3CDB7FD07C101058C2E5F2F9D2C7","latest_block_height":"6499","latest_block_time":"2019-04-23T05:24:25.370822898Z","catching_up":true},"validator_info":{"address":"DF3F87B7A952EFD8D2F6F83424738FF8F507661E","pub_key":{"type":"tendermint/PubKeyEd25519","value":"b6AuJZfIG0ZyZHVO+h+kCOpu40B5CwXC2FPEGj90ufw="},"voting_power":"0"}}未承認のトランザクションはノードの mempool に蓄積されていきます。最小ガスコストを設定しておくことで、そのガスコスト未満のトランザクションを破棄できるため、最小ガスコストを設定しておくことが推奨されています。推奨のガスコストは 0.025uatom です。[11]
The initial recommended min-gas-prices is 0.025uatom, but you might want to change it later..gaiad/config/gaiad.toml で設定します。
##### main base config options ###### The minimum gas prices a validator is willing to accept for processing a
# transaction. A transaction's fees must meet the minimum of any denomination
# specified in this config (e.g. 0.25token1;0.0001token2).
minimum-gas-prices = "0.025uatom"
以上です。
バリデータへの攻撃手法
上位のバリデータはハッキングなどの攻撃対象となる可能性があります。秘密鍵を引き抜きぬくこともそうですが、Webサイトの改竄によるレピュテーション被害や、またDDoSなどで通信を止め意図的にスラッシングさせられることも考えられます。
簡単に主要な攻撃手法を見てみます。
- ノードのハッキング — 脆弱性を突いてリモートコントロールを奪取する、それによって秘密鍵を引き抜き Atoms を毀損する
- DDoS攻撃 — IP通信をフラッドさせてノード間の通信を輻輳させる、結果ステークができないことやスラッシングが発生する
- Webサイト攻撃 — Webサイトの改善やDNSキャッシュポイズニングなどによる偽サイトへの誘導によって風評被害が引き起こされる
バリデータの構築まで行う場合は Validators FAQ に掲載の要件を参考にしたほうが良いと思います。データセンターでの冗長化ネットワークや HSM（Hardware Security Module）による鍵管理などが推奨されています。
運用するノードの監視やセキュリティインシデントが発生した場合の、インシデントレスポンスの体制などを敷く必要もでてくると考えられます。
What are hardware requirements?
Validators should expect to provision one or more data center locations with redundant power, networking, firewalls, HSMs and servers. We expect that a modest level of hardware specifications will be needed initially and that they might rise as network use increases. Participating in the testnet is the best way to learn more.
How to handle key management?
Validators should expect to run an HSM that supports ed25519 keys. Here are potential options:
YubiHSM 2
Ledger Nano S
Ledger BOLOS SGX enclave
Thales nShield support
Tendermint SGX enclave
まとめ
- Cosmos Hub は Tendermint ベースのパブリックブロックチェーンで、 PoS（Proof of Stake）を採用している
- バリデータというブロック生成やガバナンスへ参加するユーザと、バリデータへ Atoms をステークすることで権限移譲するデリゲータというユーザが存在する
- スラッシングによってバリデータやデリゲータのステークした Atoms は毀損する可能性がある
- バリデータは格好の攻撃対象であるため十分なセキュリティ対策や体制と監視が求められる
References
- [1] Cosmos Hub
- [2] Validators FAQ
- [3] 仮想通貨Cosmos(ATOM)とは？ バイナンスDEXをサポートする相互運用可能なプラットフォームを解説
- [4] Cosmos / ATOM Delegation Guide
- [5] Cosmos SDK Documentation / Service Providers
- [6] How to Upgrade Your Cosmos Full Node to Mainnet
- [7] How to Install Cosmos and Run Your Full Node (Mainnet)
- [8] moovweb / gvm
- [9] Install Gaia
- [10] Cosmos Hub Launch
- [11] Join the mainnet
