2つの夕暮れステーキングプールは同じプロトコル報酬を獲得でき、それでもユーザーに対しては異なるリターンを支払うことができます。
私は@Dusk のステーク抽象化(Stake Abstraction)設計に関するある1つのディテールに何度も立ち返りました。
スマートコントラクトはステークを保有し、報酬を受け取り、そしてそれらの報酬をどう分配するか、あるいはどう再投資するかを決められます。
最初は、それはステーキングプールのためのインフラのように聞こえます。
しかしそれは、ユーザーが実際に比較しているものを変えてしまいます。
2つのプールが同じDuskのステーキングシステムとやり取りし、プロトコルレベルでは同様に振る舞うとしても、そのプールに預ける人々の最終的なリターンは依然として異なる可能性があります。
なぜなら:
プロトコル報酬 ≠ 預け手(デポジター)の利回り。
ステーキングのロジックがスマートコントラクトに移ると、経済性の一部も一緒に移動します。
コントラクトは、報酬のうち預け手にどれだけ届くか、どれだけがオペレーターに保持されるか、報酬が複利で増えるかどうか、また別の参加者が取り分を受け取るかどうかを定義できます。
この柔軟性は役に立ちます。
これがなければ、より洗練されたステーキング商品を作るのはずっと難しくなるでしょう。
ただしその一方で、ステーキング商品の見出しとなる利回りは、バリデータのパフォーマンスだけでは説明できなくなります。
コントラクトのポリシーも重要です。
そして私は、この部分がユーザーにとって非常に分かりやすく提示されているのを見たいと思っています。
単に:
「このプールはどんなAPYを表示しているのか?」
ではなく:
このコントラクトがプロトコルから稼ぐ100 DUSKごとに、ステークを提供する人々に最終的にどれだけ届く(または複利として増える)のか?
2つのプールが似たプロトコル報酬を得ていても、デポジターのリターンが大きく異なるなら、面白い変数はもはやコンセンサスではありません。
コンセンサスがすでに報酬を支払った後、その報酬がどこへ行くかを決めるレイヤーが本質的な違いです。
#dusk $DUSK @Dusk
$ZEC $TRUMP
私は@Dusk のステーク抽象化(Stake Abstraction)設計に関するある1つのディテールに何度も立ち返りました。
スマートコントラクトはステークを保有し、報酬を受け取り、そしてそれらの報酬をどう分配するか、あるいはどう再投資するかを決められます。
最初は、それはステーキングプールのためのインフラのように聞こえます。
しかしそれは、ユーザーが実際に比較しているものを変えてしまいます。
2つのプールが同じDuskのステーキングシステムとやり取りし、プロトコルレベルでは同様に振る舞うとしても、そのプールに預ける人々の最終的なリターンは依然として異なる可能性があります。
なぜなら:
プロトコル報酬 ≠ 預け手(デポジター)の利回り。
ステーキングのロジックがスマートコントラクトに移ると、経済性の一部も一緒に移動します。
コントラクトは、報酬のうち預け手にどれだけ届くか、どれだけがオペレーターに保持されるか、報酬が複利で増えるかどうか、また別の参加者が取り分を受け取るかどうかを定義できます。
この柔軟性は役に立ちます。
これがなければ、より洗練されたステーキング商品を作るのはずっと難しくなるでしょう。
ただしその一方で、ステーキング商品の見出しとなる利回りは、バリデータのパフォーマンスだけでは説明できなくなります。
コントラクトのポリシーも重要です。
そして私は、この部分がユーザーにとって非常に分かりやすく提示されているのを見たいと思っています。
単に:
「このプールはどんなAPYを表示しているのか?」
ではなく:
このコントラクトがプロトコルから稼ぐ100 DUSKごとに、ステークを提供する人々に最終的にどれだけ届く(または複利として増える)のか?
2つのプールが似たプロトコル報酬を得ていても、デポジターのリターンが大きく異なるなら、面白い変数はもはやコンセンサスではありません。
コンセンサスがすでに報酬を支払った後、その報酬がどこへ行くかを決めるレイヤーが本質的な違いです。
#dusk $DUSK @Dusk
$ZEC $TRUMP
