TTF : Combien de temps faut-il pour qu’un accord de rollup soit finalisé ?

原文标题 :《Un tweet sur le délai de cumul jusqu’à la finalité (TTF)》

Écrit par : @larry0x

编译 :Frank,Actualités de la prospective

Tout d’abord, qu’est-ce que le TTF et pourquoi est-il important ?

Le caractère définitif est l’état dans lequel une transaction ne peut jamais être annulée, rétablie ou modifiée, c’est-à-dire qu’elle est considérée comme ayant résolu le problème de transaction correspondant.

Le TTF (time to finality) est le temps qu’il faut à un signal de trading pour atteindre son état final à partir du début de la diffusion, et voici les TTF de plusieurs chaînes sélectionnées :

! [TTF : Combien de temps faut-il pour qu’un accord de rollup soit finalisé ?] (https://cdn-img.panewslab.com//panews/2022/11/15/images/1479927338818e02a46e6f57d2b767fd.)

Le TTF est un paramètre important avec une variété d’utilisations :

• Si je suis un commerçant qui accepte les paiements en cryptomonnaies, j’aimerais attendre le TTF avant de livrer les biens ou services afin de savoir que le paiement ne sera pas annulé.
• Si je suis un protocole de pontage inter-chaînes et que la chaîne émettrice soumet un paquet, je veux attendre le TTF avant de le relayer à la chaîne réceptrice.
• …

Deuxièmement, les cumuls

Il existe 2 phases dans le cycle de vie d’un bloc de cumul :

(1) ses données sont publiées sur la couche de disponibilité des données (DA) ;

(2) s’avèrent valides au niveau de la couche de peuplement ;

Il convient de noter que le TTF est différent pour les nœuds complets et légers des chaînes de cumul :

• Pour les premiers, ils n’ont pas besoin d’attendre que (2) se règle, car dès que les données de bloc sont publiées en (1), ils peuvent immédiatement vérifier eux-mêmes la validité ;
• Pour ces derniers, ils doivent attendre le processus de règlement ;

Au cours de la phase de preuve de règlement de la couche de règlement, il existe deux types de cumuls, en fonction du mécanisme qu’ils utilisent :

• Validités cumulatives (ou cumuls à divulgation nulle de connaissance, zkRU). Une fois que le séquenceur a généré un bloc, le testeur (généralement la même personne que le séquenceur) soumet une preuve de validité qui prouve que le bloc est valide grâce à une magie cryptographique.
• Optimistic Rollups(opRUs)。 Le séquenceur génère un bloc, mais il ne prouve pas qu’il est valide. S’il est réellement invalide, n’importe qui (le prouveur) peut le contester en soumettant une preuve de fraude, ce qui entraîne un blocage rejeté. Si personne ne prouve qu’un blocage n’est pas valide pendant une période de temps, connue sous le nom de période de contestation, le blocage est considéré comme valide.

Note : Je n’aime pas le terme zkRU parce que beaucoup de ces systèmes de preuve ne sont pas réellement des techniques à connaissance nulle, donc « Validity Rollup » est un terme plus précis. Cependant, l’utilisation de « zkRU » est si courante, alors je l’utilise.

Il y a aussi quelques choses importantes à savoir :

• En pratique, les données de bloc ne sont généralement pas publiées sur la couche DA immédiatement après la génération d’un bloc. Le séquenceur attend généralement un peu, puis publie quelques blocs en masse (probablement pour économiser sur les frais de gaz) ;
• Les preuves de validité sont également souvent retardées, généralement en raison de la génération de ces preuves, qui nécessite beaucoup de temps et de calcul.
• La preuve de validité et la fraude ne se propage pas seulement sur la chaîne. Par exemple, si quelqu’un m’envoie une preuve de validité off-chain, je peux être sûr que le bloc est valide sans avoir à attendre (2) le processus de règlement on-chain.

Enfin, nous sommes prêts à discuter du temps qu’il faut pour qu’un accord de rollup atteigne le résultat final.

Pour les noeuds complets, le processus est simple : dès que le bloc (1) est publié et complété sur la couche DA, il est finalisé.

Si nous indiquons :

• T1 : Fréquence à laquelle les blocs sont publiés sur la couche DA (par exemple, si le séquenceur publie un lot sur la couche DA toutes les 10 minutes, alors T1 = 10 minutes)
• T2 : TTF de la couche DA

Ensuite, le TTF du cumul = T1 + T2.

Pour les nœuds légers, ils doivent attendre que (1) et (2) se terminent. Pour les opRU, le temps pour (2) est la période de défi, et pour les zkRU, le temps est après que le prouveur a généré et publié la preuve de validité.

Si nous indiquons :

• T3 : Pour opRU, la période de défi ;
• T4 : Pour les zkRUs, l’heure à laquelle la preuve de validité a été publiée au niveau de la couche de tassement ;
• T5 : TTF de la couche de tassement ;

Ensuite, il y a le TTF pour le cumul :

• Pour opRU : max (T1+T2, T3) ;
• Pour zkRU : max (T1 + T2, T4 + T5) ;

Le « maximum » dans ces équations signifie que nous devons attendre la fin de l’AD et du processus de règlement, selon la période la plus longue (presque toujours réglée).

Maintenant, voici le problème ! Rappelez-vous, nous avons dit que les preuves peuvent également être propagées hors chaîne. Pour zkRU, si nous recevons une preuve de validité off-chain, nous pouvons immédiatement dire que la transaction est terminée sans attendre le processus de règlement on-chain.

C’est difficile à dire pour opRU. La période de contestation (T3) a tendance à être plus longue en raison des craintes que le palier de règlement puisse examiner les preuves de fraude. Cela dépend donc vraiment de votre tolérance au risque. Si vous êtes assez sûr que la couche de règlement n’examinera pas la transaction, vous pouvez choisir d’attendre moins longtemps. Sinon, vous attendrez plus longtemps, mais vous n’aurez pas à attendre plus longtemps que le T3.

Résumons :

! [TTF : Combien de temps faut-il pour qu’un accord de rollup soit finalisé ?] (https://cdn-img.panewslab.com//panews/2022/11/15/images/dc879d6785275eb291bbc2cae4b7bc1d.)

Voici deux exemples concrets, Arbitrum et zkSync. Ils utilisent Ethereum pour DA et le règlement, donc T2 = T5 = 13 minutes.

• Le séquenceur d’Arbitrum publie des données environ toutes les T1 = 6 minutes, et la période de challenge d’Arbitrum est T3 = 1 semaine ;
• le séquenceur de zkSync publie des données environ toutes les T1 = 3 minutes, ce qui prouve qu’elles ne sont pas publiées régulièrement, mais en moyenne une fois T4 = 1 heure ;

Nous pouvons également envisager un zkRU hypothétique qui utilise Celestia pour DA, ce qui, je pense, est plus proche du résultat final :

• T1 = 0 (Celestia est bon marché, on suppose donc que le bloc est publié dès qu’il est généré) ;
• T2 = 12 secondes ;
• T4 = temps de génération de l’épreuve, en fonction du système d’épreuve ;

! [TTF : Combien de temps faut-il pour qu’un accord de rollup soit finalisé ?] (https://cdn-img.panewslab.com//panews/2022/11/15/images/edba98503458c791b1db04f99e9d7a91.)

Enfin, une brève discussion sur ce que tout cela signifie

Comme vous le savez, je suis un fan de Cosmos, et IBC utilise un client de nœud léger pour valider les paquets, vous devez donc attendre le TTF, comme indiqué dans la colonne « Pour les nœuds légers » dans l’image ci-dessus.

Pour opRU, cela peut aller jusqu’à 1 semaine (si vous n’êtes pas trop confiant dans la résistance à la censure d’Ethereum), ce qui est trop long à des fins pratiques. C’est pourquoi pour opRU, nous devons utiliser des ponts à nœuds complets, tels qu’Axelar et Wormhole, qui consistent en un groupe d’opérateurs exécutant des nœuds complets.

L’inconvénient est que nous devons faire confiance à cet ensemble de transporteurs, qui ne sont peut-être pas aussi sûrs économiquement que la chaîne d’envoi, c’est pourquoi je suis baissier sur opRU.

Pour les zkRU normaux, il suffit d’attendre que le DA soit finalisé (16 minutes sur Ethereum) + temps de génération des preuves, nous n’avons pas besoin d’attendre que les preuves soient publiées sur Ethereum – c’est le principal avantage par rapport aux opRU !

C’est aussi l’une des façons dont je pense que Celestia peut améliorer l’expérience cross-chain de Rollup. Sur Ethereum, nous n’attendons que 12 secondes + temps de génération de la preuve, pas 16 minutes. Les clients de nœuds légers peuvent utiliser QGB pour vérifier les preuves du validateur Celestia (qui, je suppose, a maintenant été renommé en Blobstream), ou peut-être l’échantillonnage DA.