\Broke down Dusk's block finality states this week because "final" gets used loosely in blockchain documentation and I wanted to know exactly what each state actually means in the whitepaper which uses four distinct terms.

4つのことがある。

成功の認証（success attestation）を付与されたブロックを受理したが、反復 I > 0 であり、かつ以前のすべての反復が失敗の認証（fail attestations）を持っているわけではない。このブロックはチェーンに受け入れられている。ただし、より低い反復番号からの競合ブロックによって置き換えられる可能性がまだある。恒久的に確定（permanently settled）されていない。

認証済み（Attested）：反復 I = 0（最小可能で、置き換えるためのより低い反復が存在しない）である場合、またはすべての過去の反復が失敗の認証を持っている場合。このブロックは、より低い反復番号のブロックによって置き換えられない。これは、単一ブロック自身の認証プロパティだけに基づいて到達し得る、最も強い状態。

確定（Confirmed）：このブロックは受理済み（accepted）または認証済み（attested）のいずれかであり、その後に続くものによって最終性ルールが満たされている。受理済みのブロックは、連続した 2n 個の認証済みまたは確定済みの後続（successors）を得ると確定になる。ここで n は、認証されていない過去の反復（non-attested previous iterations）の数である。認証済みのブロックは、認証済みまたは確定済みの後続が 1 つ得られると確定になる。

最終（Final）：確定（confirmed）であり、その親（parent）も最終（final）。いかなる状況でも置き換えられない。これが唯一の「真のハード保証（hard guarantee）」である。

私は実際、この点は「トランザクションが実際に確定（settled）したタイミングを知る必要がある」アプリケーションにとって最も重要だと思う。単に「含まれた（included）」ではなく。 「accepted」を「settled」の代用（proxy）にすると、置き換えの余地が残る。適切なトリガーは少なくとも「confirmed」であり、高リスクな用途では「final」であるべきだ。

問題は、Dusk の上に構築するアプリケーション開発者が、各状態に対応する明確なAPIシグナルを得られるのか、それともブロック状況をポーリングし、特定のブロックが「final」に到達する時点を追跡するために自前の状態機械を実装しなければならないのか、ということだ。@Dusk

$DUSK #dusk