AI銘柄10選 ソラナ将来性 米国政権動向 BTC始め方 注目銘柄2024
TOP 新着一覧 チャート 資産運用

ステーキングサービス会社から視たCosmos Validatorの裏側

今回は、ステーキングサービスを提供する会社Stirさんから寄稿していただいたレポートの一部を紹介します。ステーキングサービス提供者の視点から視たCosmosのValidatorについて書いています。

  1. Cosmosでのステーキング
  2. Validatorのハードルと違い
  3. 今回のアップデートの舞台裏

    4. 3-1.Cosmosのバージョンアップの舞台裏

    3-2.何があったのか

    3-3.Cosmosのバージョンアップは誰がどのように決めるのか

    3-4.考察

  4. Stirとは

Cosmosでのステーキング

現在メインネットローンチされているものとしてCosmosというものがあります。これはBFTのPoSブロックチェーンです。BFTベースのものはノード数を制限する必要があり、このCosmosでいうと現在のところ残高トップ100台に制限しています。（今後様子を見て引き上げる予定あり）

Cosomosではこのようにノード数を制限する代わりに、残高をValidatorと呼ばれる100台のノードに委任（デリゲート）することができます。そしてValidatorは各々が定めた手数料を引いて、報酬を受け取ることができます。これがいわゆるステーキングプールと呼ばれる仕組みです。

そして我々Validatorをやっていて驚いたのが、Cosmos Networkにはすでに報酬の分配機能がついているということです。ユーザーが報酬を受け取るというトランザクションを送ったら自動的に報酬が計算され受け取れるということです。ユーザーは任意のタイミングで報酬を受け取れ、かつValidator側が報酬を横取りすることもできなくなっています。Validator側としても送金の手間が省けてとてもありがたい仕組みとなってます。

Validatorのハードルと違い

さて、このValidatorプール、ある程度のハードルが存在します。

  • サーバーの冗長化（もちろんハッキングなどされてはいけないです。また、Validateできるサーバーが同時に立ち上がって二重署名などが起きちゃうなどがあってはいけません。）
  • 鍵の保守（オンプレでLedger Nano Sなどを使っていると望ましい）
  • アップデート内容を随時追う（たまに緊急HFなどが入る場合がある。また3ヶ月に一度くらいHFが入ります。）

はっきりいってかなり大変です。そしてこれお金をかけようと思ったら無限にかけることができます。この記事を書いている間にも、BlockPowerというValidatorがOfflineになったということでRejectされていました。（現在は復帰済み）

https://hubble.figment.network/cosmos/chains/cosmoshub-2/validators/CC05882978FC5FDD6A7721687E14C0299AE004B8

このように一定期間以上オフラインになってしまったり、はたまた二重署名（同じブロックNoのものに二重にサインしてしまうこと。フォーク）を行ってしまうと、罰則が存在します。 一定期間以上オフラインになってしまったものには0.01%、二重署名を行ってしまったものには5%もの罰金が発生します。これはValidatorも、そのValidatorに委任している方も同様です。

今回のアップデートの舞台裏

HFについての話が出たので、ちょうど先日のCosmos Hubのアップデート対応について話をしたいと思います。

9月24日にCosmos Hub 2から3へのアップデートが入る予定だったのですが、移行途中にバグが見つかり急遽中断となったりしました。その舞台裏について書きたいと思います。

Cosmos のバージョンアップの舞台裏

Stir でも Cosmosのステーキングを行なっているため、まさに当事者としてこのバージョンアップを目の当たりにしていたのですが、結論から言うと、当日のバージョンアップは中止になり、Cosmos Hub 2への切り戻しが決定されました。

2019年10月5日 現在でもCosmos Hub 2でメインネットは稼働しています。

何があったのか

さて、どう言う経緯でメンテナンスが中止になり、切り戻しすることになったのでしょうか。 時系列をおって、見て行きましょう。

pm8:38(メンテナンス開始):

  • メンテナンス開始予定ブロックである1933000ブロックに到達。
  • メンテナンス時間は1時間と結構短い。
  • pm9:38にcosmoshub-3が開始する予定。
  • メンテナンス作業量は1時間以内で完了する分量。
  • バリデータ同士はチャットグループで情報を共有しながらアップデートをしている。

pm9:15ごろ(メンテナンス終了25分前):

  • cosmoshub-3のスタートに必要なファイルの一つ(ジェネシスファイル)がバリデータによって違う場合があるとチャットグループで報告がされる。
  • ざわつく。
  • 一部のバリデータは移行手順を完了しており、cosmoshub-3のローンチを待つ状態だった。

pm9:24(メンテナンス終了14分前):

  • バリデータチャットグループ(公式)で開発者チームよりアナウンス「今回のアップグレード手順に問題が見つかった。問題解決に務めるが、切り戻しの準備を。」との報告。
  • ざわつく。
pm9:30(メンテナンス終了8分前):
  • バリデータチャットグループ(公式)で開発者チームよりアナウンス「切り戻し」
  • 各社切り戻し作業を行う。
  • バリデータによっては、1933000以前のブロックをバックアップしていない事態が起こる。
pm10:56(メンテナンス終了予定から約1時間20分後)
  • バリデータの7割以上が正常稼働状態になる。
  • ブロックが進み始める。

当初完了予定時刻のおよそ1時間20分後にCosmos Hub 2が再開したことになります。

テストネットでは正常にバージョンアップが完了したとのことでしたが、pm9:15ごろから不穏な空気が流れ始め、pm9:30ごろから鉄火場の雰囲気でした。

Stirでは、メンテナンスブロック到達前と後でそれぞれデータのスナップショットを取得していたため、比較的スムーズに切り戻しを行うことができましたが、スナップショットのないバリデータのグループもあるようでした。

そういったバリデータは他のバリデータからデータを譲り受けてノードを動かし始めたようです。

Cosmosのバージョンアップは誰がどのように決めるのか

そもそも、Cosmosのバージョンアップは誰がどのように決定したのでしょうか？ その疑問に答えるために、Cosmosのガバナンスを用いたバージョンアップのプロセスについて簡単に触れたいと思います。

Cosmosには送金トランザクションやステーキングトランザクションの他に、ガバナンストランザクションという種類のトランザクションがあります。このガバナンストランザクションを通じて次のプロセスでバージョンアップなどの合意をとる仕組みになっています。

0.プロポーザルの提案
  • だれでもプロポーザルを提案することができます。
  • プロポーザルの一覧はこちらから確認することができます。
    • https://www.mintscan.io/proposals

1.バージョンアップのプロポーザルの承認/拒否
  1. プロポーザルに対して、バリデータは委任された分を代表して承認あるいは拒否の投票(ガバナンストランザクションの発行)を行うことができる。
      2. ■たとえば、100,000atomの委任をうけている場合、100,000atom分の投票を行うことができる。
  2. ステーキングしている人は、自分自身で投票(ガバナンストランザクションの発行)をすることで、バリデータの投票を上書きできる。
      3. ■自分自身でガバナンストランザクションを発行することで、バリデータの投票のうち、自分の委任している分を上書きできる。
  3. プロポーザルは「投票率40%以上」と「投票のうち50%以上が賛成票」と「拒否票が投票の33.4%未満」の3つすべてが閾値を満たして初めて承認されます。
2.プロポーザルが承認されると、そのプロポーザルの内容に従って各バリデータはアップデートを実行する。

まとめると、Cosmosでは「Atomをステーキングを行なっているアカウント全て」がガバナンスに参加することができ、「所定のルールに従ってプロポーザルの承認/拒否 が決まる」といった風になります。

今回のバージョンアップは、プロポーザル16(https://www.mintscan.io/proposals/16

)の承認を受けての実行です。実はほぼ同内容のプロポーザル14(https://www.mintscan.io/proposals/14

) が提案されたのですが、メンテナンス時間のタイミングが悪い(地域によってはすごく早朝などになってしまうため)などの理由で却下になりました。

考察

今回のバージョンアップでは、切り戻しにはなりましたが、正常にネットワークが再稼働することができて、ひとまずは胸をなで下ろしています。ただ、いくつかの課題が見えてきました。

  • 大規模障害に引きずられてネットワークが停止する可能性
      • AWS,GCE,Azureなどのクラウドで全停止になり得る障害が起こった時など、合計で委任額の30%以上のノードが停止するだけでネットワークが停止してしまう可能性が考えられた。
  • メンテナンス時間の見積もりがきつすぎる
      • 切り戻しの時間もいれた方がいいかもしれませんが、ネットワークを止める時間を短くする必要もありますので、一概にどちらにした方がいいとは言い切れないですね。

    IBCが運用フェーズになってからこうしたダウンタイムが発生するupdateが発生してしまうと、非常にまずいと思いますので、そうなった時にネットワークを停止せずに大きなアップグレードを行う方法を考えていかないといけないように思えます。(今後、おそらくそういった提案がなされていくのではないでしょうか)

    一方で、バージョンアップ自体は、ガバナンスであらかじめ決めたことを実行するだけでしたので、コンセンサスが取れない問題が回避できて、速やかに協力関係で進められたと思います。

    近々 kava や その他 tendermint 関連のメインネットローンチが控えていますので、これからの進歩に期待したいと思います。

    Stirとは

    ステーキングに参加するのを容易にするステーキングサービス（Staking-as-a-Service）を提供する会社です。現在Cosmos、Tezos、IOST、NEMなどを取り扱っております。

    ↓ステーキングの開始はこちらから！
    Stir公式サイトはこちら

    他にもノード構築支援やコンサルタントなどを行なっております。

    関連記事はこちら
    ステーキングのネットワーク開発が現在も進んでいますが、さまざまな課題が存在しています。今回のコラムではアップデート時の問題点について触れました。前回のコラムでは、ノードの通信負担について解説しましたので、合わせて読んでいただけるとよりネットワーク開発の理解が深まるでしょう。ぜひご覧ください。 Erlayでフルノードの通信負担を減らす

コメントしてBTCを貰おう