Un zoom sur FAFO de Layer Zero : 1 million de TPS sur Ethereum ?

Les informations clés

• FAFO (Fast Ahead-of-Formation Optimization) est un protocole qui réorganise les transactions pour optimiser leur exécution.
• FAFO permet une implémentation de la parallélisation qui peut être adaptée à la plupart des machines virtuelles actuellement sur le marché.
• En phase de test, FAFO a permis à un nœud seul d’exécuter 1,12 millions de transferts d’ETH par seconde ou 565 000 transferts ERC20.

---

Présentation de FAFO

FAFO (Fast Ahead-of-Formation Optimization), est un protocole développé par LayerZero qui réorganise l’ordre des transactions afin d’optimiser leur exécution. À la différence des bases de données classiques qui utilisent massivement la parallélisation, les blockchains majeures reposent sur un fonctionnement séquentiel où les transactions sont exécutées les unes après les autres.

Ce système, bien que peu efficace, permet d’éviter les collisions, c’est-à-dire une situation où plusieurs transactions interagissant avec les mêmes données on-chain seraient exécutées simultanément. Ainsi, la plupart des blockchains reposent sur une exécution purement linéaire qui n’exploite pas au mieux les multiples cœurs des processeurs utilisés par les nœuds.

Certaines blockchains comme Sei ont été développées dès le début avec l’objectif d’utiliser la parallélisation afin d’optimiser les performances. Cependant, cela nécessite le développement de nouveaux consensus, l’usage de langage de programmation spécifiques et contribue à fragmenter la liquidité disponible.

Avec FAFO, LayerZero propose un protocole qui réorganise les transactions afin d’optimiser le débit sans modifier le consensus ni la couche d’exécution d’Ethereum. À noter que l’équipe de LayerZero a développé FAFO autour de la machine virtuelle d’Ethereum, mais qu’il pourrait fonctionner sur la majorité des machines virtuelles actuellement disponibles.

---

Le fonctionnement de FAFO

L’architecture de FAFO peut se résumer en trois éléments : ParaLyze, ParaFramer et ParaSchedule.

ParaLyze

Pour que la parallélisation fonctionne, il est nécessaire que les transactions qui entrent en conflit soient exécutées de manière séquentielle. Par exemple, si deux transactions veulent effectuer un swap sur la même pool, il est essentiel qu’un ordre soit défini.

Pour savoir si deux transactions peuvent potentiellement entrer en conflit, on peut analyser les champs de mémoire auxquels chaque transaction cherche à avoir accès. Le rôle de ParaLyze est d’analyser les transactions en attente de validation dans la mempool et de réaliser des simulations pour estimer les parties de la mémoire avec lesquelles cette transaction va interagir.

Ici, l’ordre des transactions n’est pas encore définitif, mais il s’agit d’un premier tri dont le rôle est de repérer les transactions qui devront être traitées de manière séquentielle.

ParaFramer

Une fois que ParaLyze a estimé les zones de la mémoire lues et écrites pour chaque transaction en attente, ParaFramer peut commencer à organiser les transactions. Celles-ci sont regroupées en frames, chaque frame étant un ensemble de transaction n’entrant pas en conflit, et qui peuvent donc être exécutées en parallèle.

Pour détecter efficacement les chevauchements potentiels entre les transactions, ParaFramer s’appuie sur ParaBloom, une structure de données qui permet de comparer rapidement et avec peu de ressources les ensembles de lecture et d’écriture.

Il s’agit d’un processus itératif au cours duquel les transactions sont examinées, puis placées une à une soit dans une frame existante s’il n’y a aucun conflit, soit dans une nouvelle frame. Ainsi, cela permet d’obtenir une séquence de groupes de transactions statistiquement non conflictuels.

ParaScheduler

La dernière étape est effectuée par le ParaScheduler qui va transformer chaque frame en un graph acyclique (DAG). Pour faire simple, il s’agit d’un schéma qui décrit la séquence des transactions. Par exemple, si une transaction doit s’effectuer avant une autre, car elles touchent la même zone de la mémoire, alors un lien de priorité est établi.

Grâce à ce graph, ParaScheduler peut lancer immédiatement l’exécution de l’ensemble de transactions de manière parallèle. Lorsqu’une transaction est effectuée, les dépendances se mettent à jour et les transactions suivantes dans l’ordre du graph peuvent à leur tour être exécutées.

À la fin de l’exécution, le système compare les accès mémoire effectifs avec ceux prédits par ParaLyze. Dans les rares cas où des divergences sont remarquées, la transaction est retirée du bloc et renvoyée dans la mempool. Cela garantit que l’ordre final du bloc généré ne contient aucun conflit, tout en gardant un débit de transaction élevé.

---

Limites de FAFO

Lors de phases de test, l’équipe de LayerZero a réussi à exécuter 1,12 millions de transfert d’ETH par seconde ou 565 000 transferts d’ERC20.

Ce débit est très impressionnant en comparaison des 15 TPS en moyenne sur Ethereum, cependant il n’est pas juste de comparer les deux performances purement sur ce critère et ce pour plusieurs raisons.

Il faut savoir que le test de l’équipe de LayerZero a été réalisé sur un serveur AWS seul avec la configuration suivante : 96 coeurs virtuels, 786 GiB de DRAM et 6 SSD NVMe monté en configuration RAID0 pour un total de 22,5 TB de stockage. Pour ceux qui ne seraient pas familiers avec le matériel informatique, cette configuration coûte 6000 dollars par mois, aux tarifs actuels chez AWS, et est 6 à 12 fois plus puissante que la majorité des nœuds Ethereum professionnels.

Dans l’hypothèse d’un usage sur Ethereum, les performances de FAFO seraient donc 6 à 12 fois moins importantes sachant que l’algorithme a des performances qui varient de manière linéaire.

Il faut rajouter à cela que le test a été réalisé sur un serveur seul. Sur Ethereum, la transmission des informations sur les transactions se fait de manière pair-à-pair, ce qui nécessite plusieurs relais entre les nœuds avant d’atteindre tout le réseau, avec des ralentissements possibles selon la bande passante de chacun d’entre eux.

Dans le cas d’un usage sur Ethereum, les performances de FAFO seraient donc très probablement beaucoup moins importantes, limitées par la performance du nœud le moins puissant.

Il faut ici rappeler que FAFO est uniquement un protocole de réorganisation des transactions en vue de l’optimisation de l’exécution. Il s’insère entre la mempool et la production des blocs, sans interférer avec la couche de consensus ou d’exécution. Bien qu’il permettrait d’améliorer théoriquement le débit de transactions, son usage sur Ethereum serait actuellement totalement inutile. Le temps de bloc de douze secondes crée une limite au nombre de transactions qui peuvent être traitées.

À titre de comparaison, utiliser FAFO sur Ethereum actuellement serait comme avoir une voiture de course ultra rapide, mais avec un feu rouge tous les cent mètres.

De plus, FAFO optimise l’ordre des transactions selon la vitesse d’exécution, un critère qui importe peu pour les validateurs qui préfèrent choisir les transactions qui paient le plus. Dans le contexte actuel et la limitation du temps de bloc, l’usage de FAFO a donc un intérêt très limité.

---

Usages possible de FAFO

FAFO reste néanmoins un protocole intéressant qui explore les limites de ce dont l’EVM est capable, avec quelques usages possibles.

Merkleisation des blocs

Une caractéristique de FAFO que l’on n’a pas encore abordée est la merkleisation à chaque bloc. Pour faire simple, un arbre de Merkle est une structure de données qui résume l’état d’un système via un hash unique. Dans le cas des blockchains, cela permet de vérifier qu’une information a bien été incluse sur le réseau sans tout retélécharger. À chaque fois qu’un nouveau bloc est ajouté, on peut calculer un nouveau hash. Le processus de merkleisation consiste à ajouter un bloc à l’arbre de Merkle, ce qui permet donc à ceux qui ne possèdent pas l’intégralité de la blockchain que leur transaction a bien été ajoutée.

Sur Ethereum, cette merkleisation s’effectue à chaque bloc, mais sur des blockchains ou L2 plus rapides, cette étape n’est pas systématique. Cela veut dire que bien que la transaction ait été validée très rapidement, il faut parfois attendre plusieurs secondes ou dizaines de secondes avant d’avoir une preuve que ce soit bien le cas (sauf si on a un nœud complet).

FAFO permet de maintenir un débit élevé et une merkleisation à chaque bloc. FAFO pourrait être ainsi implémenté sur des réseaux très rapides comme MegaETH afin de fournir performance et vérification à très haut débit.

Implémentation pour EVM

Un second cas d’usage possible serait une implémentation sur Ethereum. Comme on l’a vu, même si les performances obtenues par l’équipe de LayerZero sont impossibles à reproduire sur une blockchain comme Ethereum, FAFO offre un moyen d’accélérer l’exécution des transactions sur l’EVM. Si FAFO était progressivement ajoutés aux clients Ethereum et que la limite de gas était augmentée ou le temps de bloc réduit, cela ouvrait potentiellement la voie à une augmentation considérable du nombre de transactions possibles sur mainnet sans réduire la décentralisation du réseau.

L’enjeu ici est que dans le cadre actuel, les validateurs ont plus d’intérêt à maximiser le gas par bloc que le temps d’exécution. Une implémentation effective de FAFO nécessiterait donc conjointement son ajout aux clients d’exécution et une modification de la limite de gas ou un abaissement du temps de bloc.

Cependant, l’impact réel de ce type de mesure serait probablement une réduction de la décentralisation. Les validateurs les plus petits seraient contraints d’utiliser une exécution rapide, mais non optimisée en gas, tandis que les validateurs les plus gros pourraient continuer d’optimiser le gas et donc leur revenu simplement en investissant dans du matériel plus performant.

---

Conclusion

En conclusion, avec le développement de FAFO, l’équipe de LayerZero a présenté une solution innovante pour repousser les limites de l’EVM. Cependant, parce que les incitations ne sont pas claires pour les validateurs, une implémentation en l’état serait probablement un net négatif pour le réseau, bien que cela pourrait théoriquement augmenter le débit de transactions.