@Dusk をまた調べていたら、そのブロック確認が実際にどう機能しているのかについて、より深く掘り下げることになりました。表面上はシンプルな「confirmed（確定済み）」ステータスに見えるものが、実際にはもっと層のあるプロセスになっています。
Dusk は Rolling Finality（ローリング・ファイナリティ）モデルを採用しており、いくつかの段階（accepted、attested、confirmed、そして最終的に finalized）があります。それぞれの段階は、最終性を単なる「はい／いいえ」の結果として扱うのではなく、異なるレベルの確信を提供します。
私の関心を特に引いたのは、ブロックが accepted（受理）されるまでにどれだけ failed（失敗）したイテレーションが起きたかによって、確認にかかる時間が変わり得ることです。その回数が増えるほど、より強いファイナリティに到達するには、ブロックは後続のより多くのブロックを必要とします。
このセキュリティ上のロジックはとても良いと思いますが、同時に使い勝手の疑問もあります。ほとんどのウォレットは、この複雑さをすべて隠して、単に「confirmed」とだけ表示するからです。
そこで気になりました。あなたは実際に基となるファイナリティのステータスを見ていますか？それとも、ウォレットの「確認メッセージ」だけで十分ですか？
#dusk $DUSK @Dusk
Dusk は Rolling Finality（ローリング・ファイナリティ）モデルを採用しており、いくつかの段階（accepted、attested、confirmed、そして最終的に finalized）があります。それぞれの段階は、最終性を単なる「はい／いいえ」の結果として扱うのではなく、異なるレベルの確信を提供します。
私の関心を特に引いたのは、ブロックが accepted（受理）されるまでにどれだけ failed（失敗）したイテレーションが起きたかによって、確認にかかる時間が変わり得ることです。その回数が増えるほど、より強いファイナリティに到達するには、ブロックは後続のより多くのブロックを必要とします。
このセキュリティ上のロジックはとても良いと思いますが、同時に使い勝手の疑問もあります。ほとんどのウォレットは、この複雑さをすべて隠して、単に「confirmed」とだけ表示するからです。
そこで気になりました。あなたは実際に基となるファイナリティのステータスを見ていますか？それとも、ウォレットの「確認メッセージ」だけで十分ですか？
#dusk $DUSK @Dusk
