#dusk $DUSK @Dusk 取引表示「成功」、本当に完了したのでしょうか?
昨晩 Dusk の開発ドキュメントを見ていたとき、これまであまり気に留めていなかった細部を見つけました。
ある取引を送信すると、ノードは 202 Accepted を返します——これは単にリクエストが受け取られ、処理中であることを意味し、取引がすでに完了したということではありません。
さらに読み進めると、その後に admission、mempool、ブロックの選択、実行といった段階を経ることが分かります。
実行が行われたとしても、まだ終わりではありません。
なぜなら、すでに受け入れられたブロックであっても、後からロールバックされる可能性があるからです。
ブロックが finalized 状態に入ったときに初めて、この取引は本当の意味で最終性を得ます。
この細部はなかなか面白いと思います。
私たちは普段「取引成功」と言いますが、実際にはいくつかのまったく異なる状態を一緒くたにしてしまっています:
ノードが受け取ったのか、ネットワークが受け入れたのか、これは別の話です;
ブロックに入ったことと、実行が成功したことも別の話です;
実行が成功したことが、最終的な清算(ファイナリティ)を意味するわけでもありません。
通常の送金であれば、これらの状態の違いはせいぜい数段階程度かもしれません。
しかし将来、チェーン上で証券、決済、またはその他の金融資産が動くようになったら?
そのとき「だいたい成功」では明らかに足りません。
本当に答えるべきなのは、結局どの状態で、資産の権利と義務が本当に変化するのか、という点です。
これは私が最近、Dusk の「deterministic settlement」を改めて理解するうえでの一つの切り口にもなりました。
それが本当に解決しようとしているのは、取引を速くすることだけではないのかもしれません。参加者がはっきり理解できるようにすることです:
いつ待つ必要がなくなるのか、いつこの取引を「完了した」として本当に扱ってよいのか。
金融インフラにおける「取引完了」という4語の本当の意味は、たぶんここにあるのでしょう。
@Dusk $DUSK #DUSK
昨晩 Dusk の開発ドキュメントを見ていたとき、これまであまり気に留めていなかった細部を見つけました。
ある取引を送信すると、ノードは 202 Accepted を返します——これは単にリクエストが受け取られ、処理中であることを意味し、取引がすでに完了したということではありません。
さらに読み進めると、その後に admission、mempool、ブロックの選択、実行といった段階を経ることが分かります。
実行が行われたとしても、まだ終わりではありません。
なぜなら、すでに受け入れられたブロックであっても、後からロールバックされる可能性があるからです。
ブロックが finalized 状態に入ったときに初めて、この取引は本当の意味で最終性を得ます。
この細部はなかなか面白いと思います。
私たちは普段「取引成功」と言いますが、実際にはいくつかのまったく異なる状態を一緒くたにしてしまっています:
ノードが受け取ったのか、ネットワークが受け入れたのか、これは別の話です;
ブロックに入ったことと、実行が成功したことも別の話です;
実行が成功したことが、最終的な清算(ファイナリティ)を意味するわけでもありません。
通常の送金であれば、これらの状態の違いはせいぜい数段階程度かもしれません。
しかし将来、チェーン上で証券、決済、またはその他の金融資産が動くようになったら?
そのとき「だいたい成功」では明らかに足りません。
本当に答えるべきなのは、結局どの状態で、資産の権利と義務が本当に変化するのか、という点です。
これは私が最近、Dusk の「deterministic settlement」を改めて理解するうえでの一つの切り口にもなりました。
それが本当に解決しようとしているのは、取引を速くすることだけではないのかもしれません。参加者がはっきり理解できるようにすることです:
いつ待つ必要がなくなるのか、いつこの取引を「完了した」として本当に扱ってよいのか。
金融インフラにおける「取引完了」という4語の本当の意味は、たぶんここにあるのでしょう。
@Dusk $DUSK #DUSK

