見出し画像

Lisk v4 おさえておきたい機能・用語

おはこんばんちは。万博おじです。
今回はLisk v4のおさえておきたい機能や用語を紹介します。
現在のLSK保有者は特に注意しないといけないこともあるので最後までお付き合いくださいませ😉

記載時点のLisk v4 関連機能 
Lisk Core v4.0.0-beta.1
Lisk SDK v6.0.0-beta.2
Lisk Service v0.7.0-beta.1
Lisk Desktop v3.0.0-beta.0
Lisk Mobile v3.0.0-beta.0

ちなみに、この記事はLiskの用語変更後の用語で記載しています。
どんな用語がどれに当たるのかは前の記事をご覧くださいまし。


Interoperability

読み方は「いんたーおぺらびりてぃ」
和訳すると「相互運用性」
IT用語としては「異なるプログラム同士を接続した際、互いの機能を使用したりデータ連携が出来るような仕組み」のことを言います。(ざっくり説明)
似た用語として「Compatibility(互換性)」があります。

いろんなブロックチェーンを触っている人には馴染み深い用語かもしれませんね。
Lisk v4ではもっぱらサイドチェーン関連の用語と思ってもらえばいいと思います。

で、これがLisk SDK v6でモジュールとして追加されたので、ようやく「ぼくのかんがえたさいきょーのブロックチェーンアプリケーション」がLisk本体とつながる時がきたわけですね!
いやぁ感慨深い…
メインネットに導入見送りにならないことを祈りましょう。
サイドチェーン再度遅延(サイドチェーンさいどちえん)はイヤよ
ちなみに、Lisk ベータネットでは既にサイドチェーンの登録を試している人がいますね。

Interoperabilityについては以下の公式ドキュメントを参照
Lisk Interoperability
Lisk SDK - Modules

Lisk ベータネットのサイドチェーン
Liskscan - Apps

Reward Sharing Mechanism

読み方は「りわーど しぇありんぐ めかにずむ」
和訳すると「報酬共有の仕組み」
これは何かと言うと、バリデータが投票者へ投票報酬を配賦する仕組みを機能として盛り込むよというものです。

現在はバリデータが独自で配賦プログラムを作っているため、報酬計算の方法に差異(バリデータの自己投票分を除外するかどうかなど)があったりと共通したものになっていません。
また、バリデータが管理しているサーバーやネットワーク負荷、プログラムのバグなどで正しく配賦されなかったりと色々問題が発生しることもあります。

万博おじがメンバーの一人として参加しているCommulabというバリデータの報酬配賦プログラムは万博おじお手製ですが、まぁ二重配賦したり配賦が止まってたりすることが時々発生します。
二重配賦は配賦が止まってた際のリカバリミスやLisk Serviceのバグだったりするので、そりゃまぁ色々めんどくさい割と保守に気を使ってるわけですね。
投票者の皆様、配賦ミスったりしてホントご迷惑おかけしてます…
投票してくれてありがとうございます。

で、現在は各バリデータが投票報酬を一定ルール(最低払い出し枚数、払い出しタイミングなど)をもって投票者へ自動的に報酬を払い出していますが、v4では溜まった投票報酬を受け取るためにはトランザクションの発行が必要になります。
そして、バリデータは投票報酬を機能に計算してもらうために自身の取り分を設定するトランザクションの発行が必要になります。
なお、報酬計算はバリデータの自己投票も含めて計算されます。

自動化されていたものが手動になるのでめんどくさいかもしれませんが、受け取るタイミングを個々で決められるので税金計算はしやすくなるかもしれませんね🤣
投票報酬を配賦している側からすると保守作業がなくなるので本当にありがたい…(ありがとうございますありがとうございます)

なお、参考としてLisk Desktop v3.0.0-beta.0の報酬受取方法を載せておきます。(ベータ版なので変わる場合があります)

左側メニューから「Validators」を選択して開いた画面の「Stakes」ボタンを押します
開いた画面の「Claim rewards」ボタンを押します

上記画面の「Commission (%)」がバリデータの取り分になります。
なので、投票報酬となる率(%)は 100 - Commission で求められます。

例:Commission が 100%
 → 投票報酬の払い出しはされません
例:Commission が 70%
 → ブロック生成報酬の30%が投票報酬に使用されます
例:Commission が 0%
 → ブロック生成報酬の100%が投票報酬に使用されます

※Commissionは前回の変更から260000ブロック(約30日)経過後に変更可
※Commissionを増やす際は0.1%~5%までの範囲でのみ変更可
なので、Commission 50%をいきなり100%にするといったことはできません。
もしやる場合は、約1か月ごとに5%ずつ増やして10か月程度かかります。

「Claim rewards」ボタンを押します
「Confirm」ボタンを押します
パスワード入力後「Continue」ボタンを押します

Lisk Desktopではアカウントの複数管理が出来るようになります。
アカウントをLisk Desktopへ追加する際にアカウントごとにパスワードを設定します。
ここで入力するのはその「パスワード」(not パスフレーズ)です。

投票報酬を受け取るためのトランザクションが発行されます

もっと詳しく知りたい方はLIPをご覧ください。
LIP: 0070 - Introduce reward sharing mechanism

Dynamic Block Rewards

読み方は「だいなみっく ぶろっく りわーず」
和訳すると「動的ブロック報酬」
これは何かと言うと、バリデータがブロック生成した際の報酬を動的にするよというものです。

現在はアクティブバリデータ(上位101人)およびスタンバイバリデータがブロック生成した際に受け取る報酬は固定で1LSKとなっていますが、v4ではアクティブバリデータの報酬はアクティブバリデータ全体のValidator Weightと個々のバリデータのValidator Weightの比率から計算されます。
(最低報酬0.1LSK、残りの90.9LSKが上記の比率により配賦)
スタンバイバリデータは1LSK固定のまま変わりません。

[残りの90.9LSKの算出方法]
アクティブバリデータが101人が1ブロックずつ生成した際のLSKの増加量が101LSK、アクティブバリデータ101人の最低報酬が0.1LSKなので
101LSK - (0.1LSK * 101人) = 90.9LSK
となります。

よってアクティブバリデータが1ブロックあたり受け取る報酬は以下の計算式で求められます。(LIP: 0071 より引用)

0.1 + (BFT Weight × 90.9) ÷ アクティブバリデータ全体のBFT Weight

バリデータが1ブロック生成あたりに受け取る報酬の範囲は上記式に当てはめると 約0.1LSK ≦ x ≦約9.19LSK になります。
なお、報酬を1LSKにするにはアクティブバリデータ全体のBFT Weightの約1%を占めている必要があります。

で、「バリデータの報酬が減るかもしれへんのか。大変やな―。」と思っただけの方、注意してください!
あなたにも影響があることなんです!

なぜかというと例を書いて説明しますね😉
以下のようなバリデータがいるとしましょう。

[バリデータA]
Commission:10% (90%が投票報酬に使用)
BFT Weight:アクティブバリデータ全体のBFT Weightの0.5%

[バリデータB]
Commission:50% (50%が投票報酬に使用)
BFT Weight:アクティブバリデータ全体のBFT Weightの1%

バリデータAは1ブロックごとに0.5545LSKを報酬として受け取るため、0.49905LSK (0.5545 × (1 - 0.1))が投票報酬の計算に使用されます。
一方、バリデータBは1ブロックごとに1.009LSKを報酬として受け取るため、0.5045LSK (1.009 × (1 - 0.5))が投票報酬の計算に使用されます。

バリデータの取り分(Commission)が少ないからと言って投票報酬が多くなるというわけではないことに気づきましたね?

なお、実際にあなたの投票報酬となるのは
投票報酬の計算に使用されるLSK × (投票数 ÷ 総得票数) です。

[投票数]
とあるバリデータにあなたが投票している枚数
[総得票数]
とあるバリデータの総得票数

投票報酬が多く貰えるに越したことはないと思うので、多く貰いたい人はご注意ください。
もちろん、投票報酬だけでなくそのバリデータがどんな活動をしているかも加味して投票してあげるとうれしいです。
あまり言いたくはありませんがブロック生成ミスを長期間放置するようなノード管理が杜撰なバリデータもいますので。

もっと詳しく知りたい方はLIPをご覧ください。
LIP: 0071 - Introduce dynamic block rewards module

Derivation Path

読み方は「でりべーしょん ぱす」
和訳すると「導出パス、派生パス」
今までのに比べると用語聞いても「なんのこっちゃわからんwww」と思う人いると思いますが、秘密鍵の導出方法に関連する用語です。

ハードウェアウォレットなどを使用している人は聞いたことがあるかもしれませんね!

このDerivation Pathが追加されるとどうなるかというと、1つのパスフレーズ(シークレットリカバリーフレーズ、ニーモニックとも言う)から複数の秘密鍵(おいては複数のLiskアドレス)が生成されるようになります。

例えば、パスフレーズが「abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about」の場合、現在のLiskではLiskアドレスは lsk9g3k58b3gzcykjyaob9ekbt3a7b3e586h4gkxj となります。

これがDerivation Pathが「m/44'/134'/0'」の場合は lskjwa8y3pj9hjzzbq55y7k66v5t9bxqbckzfxdaf となります。
また、Derivation Pathが「m/44'/134'/1'」の場合は lskr624zwqdvfep8vqgy44mf55heoe3z32ueqqbqz となります。

abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about
はさいよわパスフレーズなのでメインネットでは使用しないようにしましょう。

「え?じゃあ今使ってるアドレスがまた変わるの?」と思った方、とても冴えてますね!
大丈夫です、現在のパスフレーズから秘密鍵生成の仕組みは旧方式として残るのでアドレスは変わりません!
ただし注意しないといけないことがあります。
それは、Lisk DesktopやLisk Mobileにアカウントを追加する際にDerivation Pathを使用しない旧方式を使用する必要があるということです。

参考としてLisk Desktop v3.0.0-beta.0 で旧方式とDerivation Pathを使用する新方式への切り替え方法を載せておきます。
なお、この操作はユーザビリティが考慮されていなかったので万博おじや高性能AI BOTなんじゃないかと疑っている(誉め言葉)przemerさんが指摘して既に修正されているので、この通りの操作ではありません。

左側メニューから「Settings」を選択して開いた画面の「Enable access to legacy Lisk accounts」のチェックをONします
Enable access to legacy Lisk accountsをチェックONにした場合のアカウント追加画面
Enable access to legacy Lisk accountsをチェックOFFにした場合のアカウント追加画面

パスフレーズの入力欄の下にDerivation Pathの欄が増えたことがわかりますね!

なお、Lisk Desktop v3.0.0-beta.0では旧方式を使用せずにアカウントを新規作成した場合、Derivation Pathは「m/44'/134'/0'」になります。

もっと詳しく知りたい方はLIPをご覧ください。
LIP: 0066 - Introduce tree based key derivation and account recovery

おわりに

以上、おさえておきたい機能・用語でした。
今回は4つ紹介しましたが結構長かったので読むのに疲れましたか?疲れましたね。書いてて疲れたしwww
読んでいただき本当にありがとうございました。

他にこれはおさえておきたいと思ったものが出てきたら「その2」を書くかも。

わからないことがあればコメントなどでお気軽にご質問をどうぞ!
TwitterもやってるのでそちらでもOKです。

Twitter:万博おじ(@ys_mdmg)

この記事が気に入ったらサポートをしてみませんか?