#dusk $DUSK @Dusk
ねえ、ひとつ聞きたいんだ。@DuskFoundation について考えていると、ずっと引っかかっていることがあるんだ。出金に対して「202 Accepted」が返ってきたとして、なぜジョブが完了していないの?
私たちは「完了」を示すレスポンスとして「done」と読みがちだよね。でもブロックチェーンでは、提出と決済は別のタイミングなんだ。
Dusk L1では、「202 Accepted」は、そのノードがルーティングのためにトランザクションを受け付けたことを意味するだけだ。トランザクションがメンプールに入った、ピアに到達した、正常に実行された、あるいは最終確定したことを証明するものではない。
Duskはこれらのステップを分けている。「transactions/included」はローカルのメンプールへの入場を示す。「transactions/executed」は、そのトランザクションが受け入れられたブロック内で実行されたことを意味し、このとき「err」フィールドが null である必要がある。最終確定は「blocks/statechange」イベントが「finalized」としてマークされたときに到達する。それまでは、受け入れられたブロックでも巻き戻される可能性がある。
仮に、取引所に対して DUSK を出金するケースを想像してみる。取引所のシステムが Moonlight トランザクションに署名し、そのバイト列とIDを保存して、ブロードキャストする。202 のレスポンスはルーティングの確認であって、完了の確認ではない。取引所は、実行が行われ、かつ最終確定されたブロックの状態になっていることを検証する必要がある。
でも、私はここで一度立ち止まった。
最終確定は、合意(コンセンサス)の機能だけではないのかもしれない。運用上の責任でもある。
では、出金が「本当に完了」するのはいつ? API が応答したときなのか、それともリバーサル(取り消し)がもう不可能になったときなのか。まだ考え中だよ。🤔
ねえ、ひとつ聞きたいんだ。@DuskFoundation について考えていると、ずっと引っかかっていることがあるんだ。出金に対して「202 Accepted」が返ってきたとして、なぜジョブが完了していないの?
私たちは「完了」を示すレスポンスとして「done」と読みがちだよね。でもブロックチェーンでは、提出と決済は別のタイミングなんだ。
Dusk L1では、「202 Accepted」は、そのノードがルーティングのためにトランザクションを受け付けたことを意味するだけだ。トランザクションがメンプールに入った、ピアに到達した、正常に実行された、あるいは最終確定したことを証明するものではない。
Duskはこれらのステップを分けている。「transactions/included」はローカルのメンプールへの入場を示す。「transactions/executed」は、そのトランザクションが受け入れられたブロック内で実行されたことを意味し、このとき「err」フィールドが null である必要がある。最終確定は「blocks/statechange」イベントが「finalized」としてマークされたときに到達する。それまでは、受け入れられたブロックでも巻き戻される可能性がある。
仮に、取引所に対して DUSK を出金するケースを想像してみる。取引所のシステムが Moonlight トランザクションに署名し、そのバイト列とIDを保存して、ブロードキャストする。202 のレスポンスはルーティングの確認であって、完了の確認ではない。取引所は、実行が行われ、かつ最終確定されたブロックの状態になっていることを検証する必要がある。
でも、私はここで一度立ち止まった。
最終確定は、合意(コンセンサス)の機能だけではないのかもしれない。運用上の責任でもある。
では、出金が「本当に完了」するのはいつ? API が応答したときなのか、それともリバーサル(取り消し)がもう不可能になったときなのか。まだ考え中だよ。🤔