Quand beaucoup de gens entendent « finalité », ils pensent surtout à « combien de blocs faut-il pour ne plus pouvoir modifier ? », une idée de coupe franche. Après avoir lu la conception de la rolling finality de Dusk, j’ai découvert que cette idée était trop grossière.
Elle découpe l’état des blocs en quatre niveaux : accepted, attested, confirmed, final. On gravit ces niveaux progressivement, ce n’est pas noir ou blanc. Si un bloc à un faible nombre de tours n’a pas réussi à réunir suffisamment de « preuves de défaillance », il peut être remplacé par des blocs des tours suivants. En revanche, plus on empile des blocs confirmés, plus la probabilité de bifurcation diminue de façon exponentielle, jusqu’à ce que tout soit verrouillé dans un état final irréversible. Cette conception transforme en réalité le « temps nécessaire pour se sentir en confiance » en une courbe plutôt qu’en un chiffre fixe.
Ce qui m’intéresse le plus, c’est la manière dont elle empêche l’opportunisme — par exemple, quelqu’un qui se arrange délibérément pour avoir une chance à tour de rôle, en espérant récolter ensuite les récompenses de production de blocs des tours ultérieurs. Le protocole prévoit plusieurs couches de contre-mesures : des récompenses de vote, des points supplémentaires et la suppression de l’éligibilité pour la production de blocs du tour suivant. En plus, il limite le nombre d’itérations. Autrement dit, on bouche les failles au niveau de la théorie des jeux une par une, au lieu de compter seulement sur des pénalités.
Mais plus on regarde dans les détails, plus je me pose des questions : ce mécanisme repose sur le fait que la taille du comité est suffisamment grande et que les communications réseau sont suffisamment rapides. Et si un jour il y avait une partition du réseau, ou un allongement de la latence de propagation des messages, l’hypothèse d’une « accumulation rapide des blocs confirmés » ne s’effondrerait-elle pas d’abord ? La finalité en secondes et la robustesse dans des conditions réseau extrêmes : peut-on vraiment obtenir les deux à la fois ? Pour l’instant, je n’ai pas vu de réponse qui me mette totalement en confiance.
@Dusk #dusk $DUSK
Elle découpe l’état des blocs en quatre niveaux : accepted, attested, confirmed, final. On gravit ces niveaux progressivement, ce n’est pas noir ou blanc. Si un bloc à un faible nombre de tours n’a pas réussi à réunir suffisamment de « preuves de défaillance », il peut être remplacé par des blocs des tours suivants. En revanche, plus on empile des blocs confirmés, plus la probabilité de bifurcation diminue de façon exponentielle, jusqu’à ce que tout soit verrouillé dans un état final irréversible. Cette conception transforme en réalité le « temps nécessaire pour se sentir en confiance » en une courbe plutôt qu’en un chiffre fixe.
Ce qui m’intéresse le plus, c’est la manière dont elle empêche l’opportunisme — par exemple, quelqu’un qui se arrange délibérément pour avoir une chance à tour de rôle, en espérant récolter ensuite les récompenses de production de blocs des tours ultérieurs. Le protocole prévoit plusieurs couches de contre-mesures : des récompenses de vote, des points supplémentaires et la suppression de l’éligibilité pour la production de blocs du tour suivant. En plus, il limite le nombre d’itérations. Autrement dit, on bouche les failles au niveau de la théorie des jeux une par une, au lieu de compter seulement sur des pénalités.
Mais plus on regarde dans les détails, plus je me pose des questions : ce mécanisme repose sur le fait que la taille du comité est suffisamment grande et que les communications réseau sont suffisamment rapides. Et si un jour il y avait une partition du réseau, ou un allongement de la latence de propagation des messages, l’hypothèse d’une « accumulation rapide des blocs confirmés » ne s’effondrerait-elle pas d’abord ? La finalité en secondes et la robustesse dans des conditions réseau extrêmes : peut-on vraiment obtenir les deux à la fois ? Pour l’instant, je n’ai pas vu de réponse qui me mette totalement en confiance.
@Dusk #dusk $DUSK
秒级最终性够用了,鲁棒性问题是过度担心
0%
极端网络条件没验证过,我持保留态度
0%
更想看到真实的分叉/攻击场景压力测试数据
0%
0 Votes • Vote fermé