Pourquoi les performances de la blockchain sont difficiles à mesurer

Les performances et l'évolutivité sont des défis très discutés dans l'espace cryptographique, pertinents à la fois pour les projets de couche 1 (blockchains indépendantes) et pour les solutions de couche 2 (comme les rollups et les canaux hors chaîne). Pourtant, nous ne disposons pas de mesures ou de critères de référence standardisés. Les chiffres sont souvent communiqués de manière incohérente et incomplète, ce qui rend difficile la comparaison précise des projets et occulte souvent ce qui compte le plus dans la pratique. 

Nous avons besoin d’une approche plus nuancée et approfondie pour mesurer et comparer les performances – une approche qui décompose les performances en plusieurs composantes et compare les compromis sur plusieurs axes. Dans cet article, je définis la terminologie de base, décris les défis et propose des lignes directrices et des principes clés à garder à l'esprit lors de l'évaluation des performances de la blockchain. 

Évolutivité vs performances

Tout d’abord, définissons deux termes, évolutivité et performances, qui ont des significations informatiques standards qui sont souvent utilisées à mauvais escient dans les contextes de blockchain. Performance mesure ce qu'est un système actuellement capable d'atteindre. Comme nous le verrons ci-dessous, les mesures de performances peuvent inclure les transactions par seconde ou le temps médian de confirmation des transactions. Évolutivité, en revanche, mesure le capacité d'un système à améliorer les performances en ajoutant des ressources.

Cette distinction est importante : de nombreuses approches visant à améliorer les performances n’améliorent pas du tout l’évolutivité, lorsqu’elles sont correctement définies. Un exemple simple consiste à utiliser un système de signature numérique plus efficace, tel que les signatures BLS, qui font environ la moitié de la taille des signatures Schnorr ou ECDSA. Si Bitcoin passait de l'ECDSA au BLS, le nombre de transactions par bloc pourrait augmenter de 20 à 30 %, améliorant ainsi les performances du jour au lendemain. Mais nous ne pouvons le faire qu'une seule fois : il n'existe pas de système de signature encore plus économe en espace vers lequel basculer (les signatures BLS peuvent également être regroupées pour économiser plus d'espace, mais il s'agit d'une autre astuce ponctuelle).

Un certain nombre d'autres astuces ponctuelles (telles que SegWit) sont possibles dans les blockchains, mais vous avez besoin d'une architecture évolutive pour obtenir une amélioration continue des performances, où l'ajout de ressources supplémentaires améliore les performances au fil du temps. C'est également la sagesse conventionnelle dans de nombreux autres systèmes informatiques, comme la création d'un serveur Web. Avec quelques astuces courantes, vous pouvez créer un serveur très rapide ; mais en fin de compte, vous avez besoin d'une architecture multi-serveurs capable de répondre à une demande toujours croissante en ajoutant continuellement des serveurs supplémentaires.

Comprendre la distinction permet également d'éviter l'erreur de catégorie courante trouvée dans des déclarations telles que « La Blockchain X est hautement évolutive, elle peut gérer Y transactions par seconde ! » La deuxième affirmation est peut-être impressionnante, mais c'est une performant métrique, pas une métrique d’évolutivité. Cela ne parle pas de la capacité d’améliorer les performances en ajoutant des ressources.

L'évolutivité nécessite intrinsèquement d'exploiter le parallélisme. Dans l’espace blockchain, la mise à l’échelle de la couche 1 semble nécessiter un partitionnement ou quelque chose qui ressemble à un partitionnement. Le concept de base du partitionnement – ​​diviser l'état en morceaux afin que différents validateurs puissent traiter indépendamment – ​​correspond étroitement à la définition de l'évolutivité. Il existe encore plus d'options sur la couche 2 qui permettent d'ajouter un traitement parallèle, notamment des canaux hors chaîne, des serveurs de cumul et des chaînes latérales.

Latence vs débit

Classiquement, les performances du système blockchain sont évaluées selon deux dimensions, la latence et le débit : la latence mesure la rapidité avec laquelle une transaction individuelle peut être confirmée, tandis que le débit mesure le taux global des transactions au fil du temps. Ces axes s'appliquent à la fois aux systèmes de couche 1 et de couche 2, ainsi qu'à de nombreux autres types de systèmes informatiques (tels que les moteurs de requête de bases de données et les serveurs Web).

Malheureusement, la latence et le débit sont complexes à mesurer et à comparer. De plus, les utilisateurs individuels ne se soucient pas réellement du débit (qui est une mesure à l’échelle du système). Ce qui les intéresse vraiment, c'est la latence et les frais de transaction – plus précisément, que leurs transactions soient confirmées aussi rapidement et à moindre coût que possible. Bien que de nombreux autres systèmes informatiques soient également évalués sur une base coût/performance, les frais de transaction constituent un axe de performance quelque peu nouveau pour les systèmes blockchain qui n'existe pas vraiment dans les systèmes informatiques traditionnels.

Défis liés à la mesure de la latence

La latence semble simple au premier abord : combien de temps faut-il pour qu’une transaction soit confirmée ? Mais il existe toujours plusieurs manières différentes de répondre à cette question.

Premièrement, nous pouvons mesurer la latence entre différents moments et obtenir des résultats différents. Par exemple, commençons-nous à mesurer la latence lorsque l’utilisateur appuie localement sur un bouton « soumettre » ou lorsque la transaction atteint le pool de mémoire ? Et arrêtons-nous le chronomètre lorsque la transaction se trouve dans un bloc proposé, ou lorsqu'un bloc est confirmé avec un bloc de suivi ou six ?

L'approche la plus courante adopte le point de vue des validateurs, mesurant à partir du moment où un client diffuse pour la première fois une transaction jusqu'au moment où une transaction est raisonnablement « confirmée » (dans le sens où les commerçants du monde réel considéreraient un paiement reçu et libéreraient la marchandise) . Bien entendu, différents commerçants peuvent appliquer différents critères d'acceptation, et même un seul commerçant peut utiliser des normes différentes en fonction du montant de la transaction.

L’approche centrée sur le validateur oublie plusieurs éléments importants dans la pratique. Premièrement, il ignore la latence sur le réseau peer-to-peer (combien de temps faut-il entre le moment où le client diffuse une transaction et le moment où la plupart des nœuds l'ont entendue ?) et la latence côté client (combien de temps faut-il pour préparer une transaction). sur la machine locale du client ?). La latence côté client peut être très faible et prévisible pour des transactions simples comme la signature d'un paiement Ethereum, mais peut être importante pour des cas plus complexes comme prouver qu'une transaction Zcash protégée est correcte.

Même si nous standardisons la fenêtre de temps que nous essayons de mesurer avec la latence, la réponse est presque toujours ça dépend. Aucun système de cryptomonnaie jamais construit n’offre une latence de transaction fixe. Une règle fondamentale à retenir est la suivante :

La latence est une distribution, pas un nombre unique.

La communauté des chercheurs en réseaux l’a compris depuis longtemps (voir, par exemple, ce excellent exposé de Gil Tene). Un accent particulier est mis sur la « longue traîne » de la distribution, car une latence très élevée, même dans 0.1 % des transactions (ou requêtes du serveur Web), aura de graves conséquences. impact les utilisateurs finaux.

Avec les blockchains, la latence de confirmation peut varier pour plusieurs raisons :

Mise en lots: la plupart des systèmes regroupent les transactions d'une manière ou d'une autre, par exemple en blocs sur la plupart des systèmes de couche 1. Cela entraîne une latence variable, car certaines transactions devront attendre que le lot soit rempli. D’autres pourraient avoir de la chance et rejoindre le groupe en dernier. Ces transactions sont confirmées immédiatement et ne subissent aucune latence supplémentaire.

Encombrement variable : la plupart des systèmes souffrent de congestion, ce qui signifie que plus de transactions sont enregistrées (au moins de temps en temps) que le système ne peut en gérer immédiatement. Le degré de congestion peut varier lorsque les transactions sont diffusées à des heures imprévisibles (souvent résumées comme un processus de Poisson) ou lorsque le taux de nouvelles transactions change au cours de la journée ou de la semaine, ou en réponse à des événements externes comme un lancement populaire de NFT.

Variance au niveau du consensus : La confirmation d'une transaction sur la couche 1 nécessite généralement qu'un ensemble distribué de nœuds parvienne à un consensus sur un bloc, ce qui peut ajouter des délais variables quelle que soit la congestion. Les systèmes de preuve de travail trouvent des blocs à des moments imprévisibles (également un processus de Poisson abstrait). Les systèmes de preuve de participation peuvent également ajouter divers retards (par exemple, si un nombre insuffisant de nœuds sont en ligne pour former un comité au cours d'un tour, ou si un changement de vue est nécessaire en réponse à la chute d'un leader).

Pour ces raisons, une bonne ligne directrice est la suivante :

Les allégations concernant la latence doivent présenter une distribution (ou un histogramme) des temps de confirmation, plutôt qu'un nombre unique comme la moyenne ou la médiane.

Même si les statistiques récapitulatives telles que la moyenne, la médiane ou les percentiles fournissent une image partielle, l’évaluation précise d’un système nécessite de considérer l’ensemble de la distribution. Dans certaines applications, la latence moyenne peut fournir un bon aperçu si la distribution de la latence est relativement simple (par exemple gaussienne). Mais dans le domaine des crypto-monnaies, il n’en va presque jamais ainsi : en règle générale, les délais de confirmation sont longs et lents.

Les réseaux de canaux de paiement (par exemple Lightning Network) en sont un bon exemple. Solution classique de mise à l'échelle L2, ces réseaux offrent la plupart du temps des confirmations de paiement très rapides, mais ils nécessitent parfois une réinitialisation du canal, ce qui peut augmenter la latence de plusieurs ordres de grandeur.

Et même si nous disposons de bonnes statistiques sur la répartition exacte de la latence, elles varieront probablement au fil du temps à mesure que le système et la demande qui lui est adressée évoluent. Il n'est pas non plus toujours clair comment comparer les répartitions de latence entre les systèmes concurrents. Par exemple, considérons un système qui confirme les transactions avec une latence uniformément répartie entre 1 et 2 minutes (avec une moyenne et une médiane de 90 secondes). Si un système concurrent confirme 95 % des transactions en 1 minute exactement, et les 5 % restants en 11 minutes (avec une moyenne de 90 secondes et une médiane de 60 secondes), quel système est le meilleur ? La réponse est probablement que certaines applications préféreraient la première solution et d’autres la seconde.

Enfin, il est important de noter que dans la plupart des systèmes, toutes les transactions n'ont pas la même priorité. Les utilisateurs peuvent payer plus pour obtenir une priorité d'inclusion plus élevée. Ainsi, en plus de tout ce qui précède, la latence varie en fonction des frais de transaction payés. En résumé:

La latence est complexe. Plus il y a de données rapportées, mieux c'est. Idéalement, des distributions complètes de latence devraient être mesurées dans diverses conditions de congestion. Les répartitions de la latence en différents composants (local, réseau, traitement par lots, délai de consensus) sont également utiles.

Défis liés à la mesure du débit

Le débit semble également simple à première vue : combien de transactions un système peut-il traiter par seconde ? Deux difficultés principales se posent : qu’est-ce qu’une « transaction » exactement et mesurons-nous ce qu’un système fait aujourd’hui ou ce qu’il pourrait être capable de faire ?

Bien que les « transactions par seconde » (ou tps) soient une norme de facto pour mesurer les performances de la blockchain, les transactions sont problématiques en tant qu'unité de mesure. Pour les systèmes offrant une programmabilité à usage général (« contrats intelligents ») ou même des fonctionnalités limitées comme les transactions multiplex de Bitcoin ou les options de vérification multi-sig, le problème fondamental est :

Toutes les transactions ne sont pas égales.

Cela est évidemment vrai dans Ethereum, où les transactions peuvent inclure du code arbitraire et modifier arbitrairement l’état. La notion de gaz dans Ethereum est utilisée pour quantifier (et facturer des frais) la quantité globale de travail effectuée par une transaction, mais cela est très spécifique à l'environnement d'exécution EVM. Il n'existe pas de moyen simple de comparer la quantité totale de travail effectué par un ensemble de transactions EVM à, par exemple, un ensemble de transactions Solana utilisant l'environnement BPF. Comparer l’un ou l’autre à un ensemble de transactions Bitcoin est tout aussi difficile.

Les blockchains qui séparent la couche de transaction en une couche de consensus et une couche d'exécution peuvent rendre cela plus clair. Au niveau de la couche de consensus (pure), le débit peut être mesuré en octets ajoutés à la chaîne par unité de temps. La couche d’exécution sera toujours plus complexe.

Des couches d'exécution plus simples, telles que des serveurs de cumul qui ne prennent en charge que les transactions de paiement, évitent la difficulté de quantifier les calculs. Mais même dans ce cas, les paiements peuvent varier en termes de nombre d’intrants et de sorties. Canal de paiement les transactions peuvent varier en termes de nombre de « sauts » requis, ce qui affecte le débit. Et le débit du serveur de cumul peut dépendre de la mesure dans laquelle un lot de transactions peut être « réduit » à un ensemble plus restreint de modifications récapitulatives.

Un autre défi en matière de débit consiste à aller au-delà de la mesure empirique des performances actuelles pour évaluer la capacité théorique. Cela introduit toutes sortes de questions de modélisation pour évaluer la capacité potentielle. Tout d’abord, nous devons décider d’une charge de travail de transaction réaliste pour la couche d’exécution. Deuxièmement, les systèmes réels n’atteignent presque jamais la capacité théorique, en particulier les systèmes blockchain. Pour des raisons de robustesse, nous espérons que les implémentations de nœuds seront hétérogènes et diverses dans la pratique (plutôt que tous les clients exécutant une seule implémentation logicielle). Cela rend encore plus difficile la réalisation de simulations précises du débit de la blockchain. 

Dans l'ensemble:

Les allégations de débit nécessitent une explication minutieuse de la charge de travail des transactions et de la population de validateurs (leur quantité, leur mise en œuvre et leur connectivité réseau). En l’absence de norme claire, les charges de travail historiques d’un réseau populaire comme Ethereum suffisent.

Compromis entre latence et débit

La latence et le débit sont généralement un compromis. Comme Lefteris Kokoris-Kogias décrit, ce compromis n'est souvent pas fluide, avec un point d'inflexion où la latence augmente fortement à mesure que la charge du système approche de son débit maximum.

Les systèmes de cumul sans connaissance présentent un exemple naturel du compromis débit/latence. Les gros lots de transactions augmentent le temps de preuve, ce qui augmente la latence. Mais l’empreinte sur la chaîne, tant en termes de taille de preuve que de coût de validation, sera amortie sur davantage de transactions avec des lots de plus grande taille, augmentant ainsi le débit.

Les frais de transaction

Naturellement, les utilisateurs finaux se soucient davantage du compromis entre latence et tarifs, pas la latence et le débit. Les utilisateurs n'ont aucune raison directe de se soucier du débit, seulement qu'ils peuvent confirmer les transactions rapidement pour les frais les plus bas possibles (certains utilisateurs se soucient davantage des frais et d'autres davantage de la latence). À un niveau élevé, les frais sont affectés par plusieurs facteurs :

1. Quelle est la demande du marché pour effectuer des transactions ?
2. Quel débit global est atteint par le système ?
3. Quel revenu global le système fournit-il aux validateurs ou aux mineurs ?
4. Quelle part de ces revenus est basée sur les frais de transaction par rapport aux récompenses inflationnistes ?

Les deux premiers facteurs sont en gros des courbes offre/demande qui conduisent à un prix d’équilibre du marché (bien qu’il ait été affirmé que les mineurs agissent comme un cartel pour augmenter les frais au-delà de ce point). Toutes choses étant égales par ailleurs, un débit plus élevé devrait avoir tendance à entraîner une baisse des frais, mais il se passe beaucoup plus de choses.

En particulier, les points 3 et 4 ci-dessus constituent des questions fondamentales pour la conception d’un système blockchain, mais nous manquons de bons principes pour l’un ou l’autre. Nous comprenons dans une certaine mesure les avantages et les inconvénients de donner aux mineurs des revenus provenant de récompenses inflationnistes par rapport aux frais de transaction. Cependant, malgré de nombreuses analyses économiques des protocoles de consensus blockchain, nous ne disposons toujours pas de modèle largement accepté quant au montant des revenus qui doivent être reversés aux validateurs. Aujourd’hui, la plupart des systèmes reposent sur une estimation éclairée du montant des revenus suffisant pour que les validateurs se comportent honnêtement sans étouffer l’utilisation pratique du système. Dans les modèles simplifiés, il peut être démontré que le coût du montage d'une attaque à 51 % évolue avec les récompenses des validateurs.

Augmenter le coût des attaques est une bonne chose, mais nous ne savons pas non plus dans quelle mesure la sécurité est « suffisante ». Imaginez que vous envisagez d'aller dans deux parcs d'attractions. L’un d’eux affirme dépenser 50 % de moins que l’autre pour l’entretien des manèges. Est-ce une bonne idée d'aller dans ce parc ? Il se peut qu'ils soient plus efficaces et bénéficient d'une sécurité équivalente pour moins d'argent. Peut-être que l'autre dépense plus que ce qui est nécessaire pour assurer la sécurité des manèges, sans aucun bénéfice. Mais il se peut aussi que le premier parc soit dangereux. Les systèmes blockchain sont similaires. Une fois que vous prenez en compte le débit, les blockchains avec des frais inférieurs ont des frais inférieurs car elles récompensent (et donc encouragent) moins leurs validateurs. Nous ne disposons pas aujourd’hui de bons outils pour évaluer si cela est acceptable ou si cela rend le système vulnérable aux attaques. Dans l'ensemble:

Comparer les frais entre les systèmes peut être trompeur. Même si les frais de transaction sont importants pour les utilisateurs, ils sont affectés par de nombreux facteurs autres que la conception du système lui-même. Le débit est une meilleure mesure pour analyser un système dans son ensemble.

Conclusion

Il est difficile d’évaluer les performances de manière équitable et précise. Cela est également vrai pour mesurer les performances d’une voiture. Tout comme pour les blockchains, différentes personnes se soucieront de différentes choses. Avec les voitures, certains utilisateurs se soucieront de la vitesse de pointe ou de l'accélération, d'autres de la consommation d'essence et d'autres encore de la capacité de remorquage. Tous ces éléments ne sont pas triviaux à évaluer. Aux États-Unis, par exemple, l'Environmental Protection Agency maintient des lignes directrices détaillées sur la manière dont la consommation d'essence est évaluée ainsi que sur la manière dont elle doit être présentée aux utilisateurs chez un concessionnaire.

L’espace blockchain est loin de ce niveau de standardisation. Dans certains domaines, nous pourrions y parvenir à l'avenir avec des charges de travail standardisées pour évaluer le débit d'un système ou des graphiques standardisés pour présenter les distributions de latence. Pour l’instant, la meilleure approche pour les évaluateurs et les constructeurs est de collecter et de publier un maximum de données, avec une description détaillée de la méthodologie d’évaluation, afin qu’elles puissent être reproduites et comparées à d’autres systèmes.