「ステーキングするのは自分ではない」版のステーキングがある。

私としては、ステーキングというのはウォレットだけができるものだと思っていました。接続して、委任して、待つ。これが、私がこれまで使ってきたどこでも当たり前のモデルでした。

でも @Dusk stake abstraction セクションを読んだとき、これは単に委任に別名を付けただけだろうと考えました。ドキュメントを何度か読み直してようやく、それは違うとわかりました。

結局のところ、Duskが契約をどう扱うかの話です。ウォレットのように、契約はロジックを実行するだけでなく、状態を保持・管理できます。つまり、ステーキングできるのはウォレットだけではありません。契約もできます。

流れはこうです。契約はステーキング関数を直接呼び出しません。まず資金が契約に入ります。その後、契約からステーキング用の契約へ、契約間の転送が行われます。アンステーキングや報酬はコールバック経由で戻ってきます。最低条件は引き続き 1,000 DUSK、有効化ルールも通常どおり同じです。

ここでいう「抽象化（abstraction）」が意味するのは、複雑さが減ることではなく、担当者が変わることです。ウォレットでのステーキングは、人が判断するのでシンプルです。一方で契約でのステーキングは、コードが自分自身であらゆる判断を正しく行う必要があります。コールバックを一つ間違えるだけで、報酬が詰まってしまいます。

それでも、何かが壊れたときに責任の境界がどこにあるのかはまだ確信が持てません。ワークフローは契約が所有しますが、合意形成（コンセンサス）の適格性はプロトコルが所有しています。なので、プール型のステーキング契約がミスった場合、それは契約のバグなのか、それともプロトコル上のリスクなのか？—まだ答えを見つけられていません。

@Dusk $DUSK #dusk