La plupart des chaînes en preuve d’enjeu font une chose après qu’un bloc est proposé : un comité vote, et si suffisamment de votes arrivent, le bloc est comptabilisé.
@Dusk le fait deux fois, et le second tour, c’est celui dont personne n’explique la raison.
Succinct Attestation exécute chaque tour en trois étapes. Un proposeur propose un bloc candidat. Un comité sélectionné aléatoirement le valide. Ensuite, un second comité ratifie — et ce qu’il confirme n’est pas le bloc. Il confirme le résultat de la validation.
Il m’a fallu un moment pour bien voir cette distinction.
La validation répond à « ce bloc est-il valide ? ». La ratification répond à « est-ce que le réseau a effectivement accepté qu’il a été validé ? ». Ce sont des questions différentes, et c’est la seconde qui permet la finalité déterministe. Sans elle, on a l’avis d’un comité, propagé sur un réseau, qui arrive à différents nœuds à des moments différents. Avec elle, on a un enregistrement attesté indiquant que l’accord lui-même a eu lieu.
C’est la différence entre « ce bloc est très probablement final » et « ce bloc est final ». Pour une chaîne qui vise le règlement de titres, cet écart n’est pas qu’une question philosophique. C’est la différence entre une garantie de règlement et une estimation du règlement.
Le coût est réel aussi. Deux comités signifient deux tours de signatures, deux occasions pour que la participation échoue, et des partages de récompense qui reflètent cela — la validation et la ratification prennent chacune une part de la récompense du bloc, distincte du générateur du bloc.
La question de savoir si ce tour supplémentaire vaut la latence et le surcoût de coordination est exactement le genre de chose qu’un audit ne peut pas vous dire. La revue d’Oak Security a jugé le protocole bien conçu. « Bien conçu » et « adapté à une charge réelle » sont des affirmations différentes.
Question sincère aux opérateurs de nœuds ici : quelqu’un a-t-il mesuré à quelle fréquence la ratification est l’étape qui se bloque, plutôt que la validation ?
#dusk $DUSK #block
@Dusk le fait deux fois, et le second tour, c’est celui dont personne n’explique la raison.
Succinct Attestation exécute chaque tour en trois étapes. Un proposeur propose un bloc candidat. Un comité sélectionné aléatoirement le valide. Ensuite, un second comité ratifie — et ce qu’il confirme n’est pas le bloc. Il confirme le résultat de la validation.
Il m’a fallu un moment pour bien voir cette distinction.
La validation répond à « ce bloc est-il valide ? ». La ratification répond à « est-ce que le réseau a effectivement accepté qu’il a été validé ? ». Ce sont des questions différentes, et c’est la seconde qui permet la finalité déterministe. Sans elle, on a l’avis d’un comité, propagé sur un réseau, qui arrive à différents nœuds à des moments différents. Avec elle, on a un enregistrement attesté indiquant que l’accord lui-même a eu lieu.
C’est la différence entre « ce bloc est très probablement final » et « ce bloc est final ». Pour une chaîne qui vise le règlement de titres, cet écart n’est pas qu’une question philosophique. C’est la différence entre une garantie de règlement et une estimation du règlement.
Le coût est réel aussi. Deux comités signifient deux tours de signatures, deux occasions pour que la participation échoue, et des partages de récompense qui reflètent cela — la validation et la ratification prennent chacune une part de la récompense du bloc, distincte du générateur du bloc.
La question de savoir si ce tour supplémentaire vaut la latence et le surcoût de coordination est exactement le genre de chose qu’un audit ne peut pas vous dire. La revue d’Oak Security a jugé le protocole bien conçu. « Bien conçu » et « adapté à une charge réelle » sont des affirmations différentes.
Question sincère aux opérateurs de nœuds ici : quelqu’un a-t-il mesuré à quelle fréquence la ratification est l’étape qui se bloque, plutôt que la validation ?
#dusk $DUSK #block
