取引がデスク(Dusk)に到達したとき、何が起きるのだろうと考えていました。
最初は、質問が1つしかないように感じます。
**「ネットワークはこの取引を受け入れるべきか?」**
しかしよく見ると、実際には2つの異なる質問があります。
まず、その取引はプロトコルのルールに従っているのか?
次に、仮に従っているとして、そこから得られる状態について、参加者は合意しているのか?
この区別は見落とされやすいです。外から見ると、どちらの手順も同じ結果へ向かっているように見えるからです。つまり、受け入れられた状態です。
ですが、設計上は別の仕事です。
何かがうまくいかなかったとき、これらを分けることで「実際に何が失敗したのか」を問いやすくなります。取引が無効だったのか?それとも有効だったが、参加者が結果として得られる状態について意見を一致させられなかったのか?
私は、この分離は強力な設計上の選択だと思います。
ただし、その分離は新たな疑問も生みます。
責務の境界が増えるごとに、引き継ぎ(handoff)が増えます。そして、その引き継ぎは、想定外のことが起きたときにも正しく振る舞う必要があります。
そこで、私は結局ここに戻ってきます。
**「妥当性(validity)と合意(consensus)を分けることで、失敗時にデスクを考えやすくなるのか? それとも、追加される境界ごとに、システムが壊れる可能性のある場所が増えるだけなのか?」**
#Dusk @Dusk $DUSK
最初は、質問が1つしかないように感じます。
**「ネットワークはこの取引を受け入れるべきか?」**
しかしよく見ると、実際には2つの異なる質問があります。
まず、その取引はプロトコルのルールに従っているのか?
次に、仮に従っているとして、そこから得られる状態について、参加者は合意しているのか?
この区別は見落とされやすいです。外から見ると、どちらの手順も同じ結果へ向かっているように見えるからです。つまり、受け入れられた状態です。
ですが、設計上は別の仕事です。
何かがうまくいかなかったとき、これらを分けることで「実際に何が失敗したのか」を問いやすくなります。取引が無効だったのか?それとも有効だったが、参加者が結果として得られる状態について意見を一致させられなかったのか?
私は、この分離は強力な設計上の選択だと思います。
ただし、その分離は新たな疑問も生みます。
責務の境界が増えるごとに、引き継ぎ(handoff)が増えます。そして、その引き継ぎは、想定外のことが起きたときにも正しく振る舞う必要があります。
そこで、私は結局ここに戻ってきます。
**「妥当性(validity)と合意(consensus)を分けることで、失敗時にデスクを考えやすくなるのか? それとも、追加される境界ごとに、システムが壊れる可能性のある場所が増えるだけなのか?」**
#Dusk @Dusk $DUSK
Easier to isolate failures
0%
Clearer system boundaries
0%
More coordination risks
0%
Both equally
0%
0 投票 • 投票は終了しました