Initialement publié en anglais par StarkWare le 23 janvier, 2019

Dans cet article, nous analysons et comparons différentes solutions de scalabilité Layer-2 (L2), en nous basant sur la distinction entre les preuves de fraude (fraud proof) et les preuves de validité (validity proof). Nous affirmons que les preuves de validité ont un avantage fondamental, en ce qu’elles garantissent l’acceptation de transitions d’état correctes.

Au cours des derniers mois, plusieurs tentatives passionnantes basées sur des preuves pour résoudre le problème de scalabilité d’Ethereum ont fait surface – des projets tels que Truebit, Gluon Plasma, dFusion, Roll-Up et Ignis. L’idée de base est simple : au lieu d’écrire de nombreuses transactions dans la blockchain, on produit une preuve qu’une représentation succincte (par exemple un hachage) de ces transactions représente le nouvel état des choses.

Les projets mentionnés ci-dessus sont tous des solutions L2 : ils définissent un protocole (et une logique) qui s’exécute au-dessus de Layer-1 (L1) et s’appuie sur lui pour différents services : dépôts/retraits, registre d’engagements off-chain, et « horloge universelle .» Il est important de noter que L1 n’est pas au conscient de la logique de L2 et ne peut donc pas l’exécuter.

Nous aimerions présenter un cadre de comparaison de ces solutions, en mettant particulièrement l’accent sur la différence entre les preuves de fraude et ce que nous appellerons les preuves de validité. Fondamentalement, les preuves de fraude et les preuves de validité peuvent exister sur L1, mais les tentatives actuelles, et donc notre analyse, sont toutes sur L2.

Les preuves de fraudes prouvent qu’une transition d’État était incorrecte. Ils reflètent une vision optimiste du monde : l’hypothèse est que les blocs ne représentent que des états corrects des données de L2, jusqu’à preuve du contraire. En réalité, un bloc engagé pourrait bien inclure une transition étatique incorrecte.

Les preuves de validité démontrent qu’une transition d’état est correcte. Ils reflètent une vision plus pessimiste du monde. Les blocs contiennent des valeurs représentant l’état L2 si, et seulement si, cet état est correct.

Avant de poursuivre, il est important de souligner : Les systèmes de preuves (p.ex. SNARK, STARK) peuvent être utilisés comme preuves de fraude ou preuves de validité. Il ne faut pas confondre comment nous prouvons (par ex. SNARK, STARK) avec ce que nous prouvons (Fraude ou Validité).

Le principal avantage des preuves de fraude est qu’elles ne sont pas nécessaires pour chaque transition d’État, mais uniquement en cas de panne supposée. En tant que tels, ils nécessitent moins de ressources de calcul et conviennent mieux à un environnement où la scalabilité est limitée. Le principal inconvénient de ces protocoles tient à leur interactivité : ils définissent une «conversation» entre plusieurs parties. Une conversation exige la présence des parties – la partie qui prétend avoir commis une fraude en particulier – et permet à d’autres parties d’interrompre la conversation par différents moyens. Mais le cœur du problème est que le protocole interprète le silence (l’absence de contestation d’un nouvel État) comme un consentement implicite. En effet, un attaquant pourrait tenter de créer un semblant de silence avec des attaques DDoS.

Décrivons le protocole conceptuel : Puisqu’un bloc peut inclure une transition d’état incorrecte, le protocole Fraud Proof prévoit un délai – le Dispute Time Delay (DTD) – pour contester cet état incorrect. Cette fenêtre est mesurée en blocs. Si aucune preuve de fraude n’est soumise dans la DTD, la transition d’état L2 est considérée comme correcte. Si une preuve de fraude est soumise au smart contract et qu’elle est jugée correcte (càd. qu’elle a été soumise dans la DTD et qu’elle démontre effectivement une transition d’état incorrecte), il en résulte, au minimum, que le smart contract revient à l'engagement du dernier état L2 correct. D’autres mesures, telles que des sanctions à l’encontre de la partie contrevenante, peuvent être appliquées.

Le choix de la durée de la DTD est important: plus elle est longue, plus la probabilité de détecter une transition d’état incorrecte est élevée – c’est bien. Mais plus le délai est long, plus les utilisateurs doivent attendre, par exemple, pour retirer des fonds – c’est mauvais.

Il s’agit d’une bête bien plus simple : une représentation d’un calcul off-chain est envoyée à un smart contract. Le smart contract met à jour la blockchain avec cette nouvelle valeur seulement après vérification de son exactitude. Les principaux avantages de Validity Proofs sont que la blockchain reflète toujours un état L2 correct et qu’un nouvel état est immédiatement utilisable. Le principal inconvénient est que des preuves sont nécessaires pour chaque transition d’État, et pas seulement lorsqu’une telle transition est contestée, ce qui nuit à la scalabilité.

Parmi les nombreuses attaques possibles, nous voudrions nous concentrer sur 51% d’attaques contre L1. Nous avons vu une augmentation de ces derniers récemment, y compris une attaque sur Ethereum Classic. Comment les preuves de fraude et les preuves de validité s’en tiendraient-elles contre de telles attaques?

Preuves de fraude : Une attaque de 51% permet à un attaquant d’introduire dans la blockchain un état frauduleux et, par exemple de voler des fonds d’un exchange attaquée.

Plus précisément :

• Les attaquants créent BlockFr avec une transition d’état frauduleuse. Par exemple, cela comprend le transfert de tous les fonds de l’échange à leur propre compte.

• En plus de BlockFr, ils ajouteront des blocs DTD, aboutissant à un bloc qui comprend un retrait des fonds octroyés à BlockFr.

• Ils continuent ensuite d’étendre la chain au-delà de la DTD, et au-delà de la chain actuelle. Ils sont capables de le faire, puisqu’ils contrôlent 51% du hashrate.

• Il est troublant de constater que le coût d’exploitation d’une telle attaque est indépendant du « jackpot » (et remarquablement bas pour le moment : moins de 100 K$/heure d’une attaque sur Ethereum), c’est-à-dire des fonds contrôlés par l’exchange attaqué. Cela signifie qu’à mesure que le volume d’activité des crypto-échange augmente, ils deviennent des cibles de plus en plus attrayantes pour de telles attaques.

En résumé, le problème fondamental est qu’une solution L2 définit sa propre logique, et autorise notamment un bloc contenant une transition étatique frauduleuse. L’état du registre après que notre agresseur ait volé les fonds est un état légal ! Il n’y a jamais eu de double dépense et, pourtant, il y a eu fraude.

Preuves de validité : Une attaque de 51% peut simplement défaire l’histoire enregistrée, et éventuellement offrir une histoire alternative; ce qui est important, cette histoire alternative est également correcte. L’éventail des attaques qui peuvent être menées ici est limité aux attaques possibles en L1. Dans les échanges crypto-crypto (et en particulier lorsque tous les actifs échangés résident sur la même blockchain), le déroulement de l’historique enregistré peut parfois s’avérer extrêmement rentable : un vendeur, par exemple, peut se réjouir de dénouer une transaction qui s’est déroulée à un prix dérisoire, mais dans un échange de donné blockchain il n’y a aucun moyen de vol pur et simple des actifs.

Pourquoi envisage-t-on des systèmes preuve de fraude (p.ex. Gluon Plasma et dFusion), compte tenu de ces inconvénients importants ? La raison principale en est que la preuve de la validité était jusqu’à récemment trop coûteuse et lourde.

Avant l’utilisation de Proof Systems, la seule option pour les «Validity Proofs» dans un système permissionless impliquait une relecture naïve, et donc une scalablité très limitée; en substance, cette relecture est ce qui se fait encore aujourd’hui en L1, avec la pénalité connue de la scalabilité. Les Proof Systems offrent une caractéristique très séduisante : pour valider une transition d’état, il suffit de vérifier une preuve, et cela à un coût qui est effectivement indépendant de la taille de la transition d’état (plus précisément, il est polylogarithmique dans la taille de la transition d’état).

Ignis/Roll-Up s’appuient tous deux sur des SNARKs qui nécessitent une configuration fiable et beaucoup plus de ressources de calcul du proveur que STARKs. StarkWare travaille sur le déploiement de StarkDEX, sa solution de scalabilité pour DEX, qui utilisera STARK pour obtenir des preuves de validité. Nous comptons le voir déployé sur testnet d’ici la fin du premier trimestre 2019.

Ce billet de blog a comparé Fraud Proofs aux Validity Proofs comme outils pour les solutions de scalabilité L2. Nous avons mis en évidence les avantages inhérents des preuves de validité en ce qui concerne les attaques de 51%. Les STARKs, avec leur temps de test rapide, leur vérification succincte et leur configuration trustless, sont un moyen incontournable pour produire des preuves de validité.

Merci à Dan Robinson, Linda Xie, Alexey Akhunov et Georgios Konstantopoulos pour la révision des ébauches de cet article.

Avihu Levy & Uri Kolodny

StarkWare

Traduction faite par @cleminso

Initialement publié en anglais par StarkWare le 23 janvier, 2019

Dans cet article, nous analysons et comparons différentes solutions de scalabilité Layer-2 (L2), en nous basant sur la distinction entre les preuves de fraude (fraud proof) et les preuves de validité (validity proof). Nous affirmons que les preuves de validité ont un avantage fondamental, en ce qu’elles garantissent l’acceptation de transitions d’état correctes.

Au cours des derniers mois, plusieurs tentatives passionnantes basées sur des preuves pour résoudre le problème de scalabilité d’Ethereum ont fait surface – des projets tels que Truebit, Gluon Plasma, dFusion, Roll-Up et Ignis. L’idée de base est simple : au lieu d’écrire de nombreuses transactions dans la blockchain, on produit une preuve qu’une représentation succincte (par exemple un hachage) de ces transactions représente le nouvel état des choses.

Les projets mentionnés ci-dessus sont tous des solutions L2 : ils définissent un protocole (et une logique) qui s’exécute au-dessus de Layer-1 (L1) et s’appuie sur lui pour différents services : dépôts/retraits, registre d’engagements off-chain, et « horloge universelle .» Il est important de noter que L1 n’est pas au conscient de la logique de L2 et ne peut donc pas l’exécuter.

Nous aimerions présenter un cadre de comparaison de ces solutions, en mettant particulièrement l’accent sur la différence entre les preuves de fraude et ce que nous appellerons les preuves de validité. Fondamentalement, les preuves de fraude et les preuves de validité peuvent exister sur L1, mais les tentatives actuelles, et donc notre analyse, sont toutes sur L2.

Les preuves de fraudes prouvent qu’une transition d’État était incorrecte. Ils reflètent une vision optimiste du monde : l’hypothèse est que les blocs ne représentent que des états corrects des données de L2, jusqu’à preuve du contraire. En réalité, un bloc engagé pourrait bien inclure une transition étatique incorrecte.

Les preuves de validité démontrent qu’une transition d’état est correcte. Ils reflètent une vision plus pessimiste du monde. Les blocs contiennent des valeurs représentant l’état L2 si, et seulement si, cet état est correct.

Avant de poursuivre, il est important de souligner : Les systèmes de preuves (p.ex. SNARK, STARK) peuvent être utilisés comme preuves de fraude ou preuves de validité. Il ne faut pas confondre comment nous prouvons (par ex. SNARK, STARK) avec ce que nous prouvons (Fraude ou Validité).

Le principal avantage des preuves de fraude est qu’elles ne sont pas nécessaires pour chaque transition d’État, mais uniquement en cas de panne supposée. En tant que tels, ils nécessitent moins de ressources de calcul et conviennent mieux à un environnement où la scalabilité est limitée. Le principal inconvénient de ces protocoles tient à leur interactivité : ils définissent une «conversation» entre plusieurs parties. Une conversation exige la présence des parties – la partie qui prétend avoir commis une fraude en particulier – et permet à d’autres parties d’interrompre la conversation par différents moyens. Mais le cœur du problème est que le protocole interprète le silence (l’absence de contestation d’un nouvel État) comme un consentement implicite. En effet, un attaquant pourrait tenter de créer un semblant de silence avec des attaques DDoS.

Décrivons le protocole conceptuel : Puisqu’un bloc peut inclure une transition d’état incorrecte, le protocole Fraud Proof prévoit un délai – le Dispute Time Delay (DTD) – pour contester cet état incorrect. Cette fenêtre est mesurée en blocs. Si aucune preuve de fraude n’est soumise dans la DTD, la transition d’état L2 est considérée comme correcte. Si une preuve de fraude est soumise au smart contract et qu’elle est jugée correcte (càd. qu’elle a été soumise dans la DTD et qu’elle démontre effectivement une transition d’état incorrecte), il en résulte, au minimum, que le smart contract revient à l'engagement du dernier état L2 correct. D’autres mesures, telles que des sanctions à l’encontre de la partie contrevenante, peuvent être appliquées.

Le choix de la durée de la DTD est important: plus elle est longue, plus la probabilité de détecter une transition d’état incorrecte est élevée – c’est bien. Mais plus le délai est long, plus les utilisateurs doivent attendre, par exemple, pour retirer des fonds – c’est mauvais.

Il s’agit d’une bête bien plus simple : une représentation d’un calcul off-chain est envoyée à un smart contract. Le smart contract met à jour la blockchain avec cette nouvelle valeur seulement après vérification de son exactitude. Les principaux avantages de Validity Proofs sont que la blockchain reflète toujours un état L2 correct et qu’un nouvel état est immédiatement utilisable. Le principal inconvénient est que des preuves sont nécessaires pour chaque transition d’État, et pas seulement lorsqu’une telle transition est contestée, ce qui nuit à la scalabilité.

Parmi les nombreuses attaques possibles, nous voudrions nous concentrer sur 51% d’attaques contre L1. Nous avons vu une augmentation de ces derniers récemment, y compris une attaque sur Ethereum Classic. Comment les preuves de fraude et les preuves de validité s’en tiendraient-elles contre de telles attaques?

Preuves de fraude : Une attaque de 51% permet à un attaquant d’introduire dans la blockchain un état frauduleux et, par exemple de voler des fonds d’un exchange attaquée.

Plus précisément :

• Les attaquants créent BlockFr avec une transition d’état frauduleuse. Par exemple, cela comprend le transfert de tous les fonds de l’échange à leur propre compte.

• En plus de BlockFr, ils ajouteront des blocs DTD, aboutissant à un bloc qui comprend un retrait des fonds octroyés à BlockFr.

• Ils continuent ensuite d’étendre la chain au-delà de la DTD, et au-delà de la chain actuelle. Ils sont capables de le faire, puisqu’ils contrôlent 51% du hashrate.

• Il est troublant de constater que le coût d’exploitation d’une telle attaque est indépendant du « jackpot » (et remarquablement bas pour le moment : moins de 100 K$/heure d’une attaque sur Ethereum), c’est-à-dire des fonds contrôlés par l’exchange attaqué. Cela signifie qu’à mesure que le volume d’activité des crypto-échange augmente, ils deviennent des cibles de plus en plus attrayantes pour de telles attaques.

En résumé, le problème fondamental est qu’une solution L2 définit sa propre logique, et autorise notamment un bloc contenant une transition étatique frauduleuse. L’état du registre après que notre agresseur ait volé les fonds est un état légal ! Il n’y a jamais eu de double dépense et, pourtant, il y a eu fraude.

Preuves de validité : Une attaque de 51% peut simplement défaire l’histoire enregistrée, et éventuellement offrir une histoire alternative; ce qui est important, cette histoire alternative est également correcte. L’éventail des attaques qui peuvent être menées ici est limité aux attaques possibles en L1. Dans les échanges crypto-crypto (et en particulier lorsque tous les actifs échangés résident sur la même blockchain), le déroulement de l’historique enregistré peut parfois s’avérer extrêmement rentable : un vendeur, par exemple, peut se réjouir de dénouer une transaction qui s’est déroulée à un prix dérisoire, mais dans un échange de donné blockchain il n’y a aucun moyen de vol pur et simple des actifs.

Pourquoi envisage-t-on des systèmes preuve de fraude (p.ex. Gluon Plasma et dFusion), compte tenu de ces inconvénients importants ? La raison principale en est que la preuve de la validité était jusqu’à récemment trop coûteuse et lourde.

Avant l’utilisation de Proof Systems, la seule option pour les «Validity Proofs» dans un système permissionless impliquait une relecture naïve, et donc une scalablité très limitée; en substance, cette relecture est ce qui se fait encore aujourd’hui en L1, avec la pénalité connue de la scalabilité. Les Proof Systems offrent une caractéristique très séduisante : pour valider une transition d’état, il suffit de vérifier une preuve, et cela à un coût qui est effectivement indépendant de la taille de la transition d’état (plus précisément, il est polylogarithmique dans la taille de la transition d’état).

Ignis/Roll-Up s’appuient tous deux sur des SNARKs qui nécessitent une configuration fiable et beaucoup plus de ressources de calcul du proveur que STARKs. StarkWare travaille sur le déploiement de StarkDEX, sa solution de scalabilité pour DEX, qui utilisera STARK pour obtenir des preuves de validité. Nous comptons le voir déployé sur testnet d’ici la fin du premier trimestre 2019.

Ce billet de blog a comparé Fraud Proofs aux Validity Proofs comme outils pour les solutions de scalabilité L2. Nous avons mis en évidence les avantages inhérents des preuves de validité en ce qui concerne les attaques de 51%. Les STARKs, avec leur temps de test rapide, leur vérification succincte et leur configuration trustless, sont un moyen incontournable pour produire des preuves de validité.

Merci à Dan Robinson, Linda Xie, Alexey Akhunov et Georgios Konstantopoulos pour la révision des ébauches de cet article.

Avihu Levy & Uri Kolodny

StarkWare

Traduction faite par @cleminso