Initialement publié en anglais par StarkWare le 4 mars, 2019

Scaler les paiements avec les STARKs

Résumé : StarkPay, un moteur de scalabilité des paiements basé sur la technologie STARK, remédie à un bon nombre des inconvénients de Lightning, la solution de paiement Layer-2.

La première application de la technologie STARK par StarkWare concerne les moteurs de scalabilité de Layer 2. Nous avons récemment annoncé StarkDEX , un moteur de scalabilité pour les DEX (avec quelques premiers résultats intéressants).

Notre moteur de scalabilité peut être utilisé pour les paiements en crypto-monnaies - nous l'appelons StarkPay. L'avènement des stablecoins remplit une condition nécessaire pour que les crypto-monnaies puissent être utilisées comme moyen d'échange. Il manque encore à l'écosystème un système de paiement scalable. Nous pensons que StarkPay peut répondre à ce besoin.

Cet article compare StarkPay à Lightning, la solution de scalabilité la plus importante pour les paiements en bitcoins. Nous commencerons par passer en revue les avantages et les inconvénients de Lightning, tels que nous les comprenons. Nous décrirons ensuite l'architecture de base de StarkPay, ainsi que son interface utilisateur (UX). Enfin, nous dresserons la liste des avantages et des inconvénients de StarkPay, ainsi que des mesures d'atténuation possibles via certaines idées prometteuses que nous entrevoyons pour l'avenir.

Cet article ne traitera pas des fonctions de confidentialité qui peuvent être ajoutées aux deux solutions.

Lightning, un protocole de paiement scalable de Layer 2, a suscité beaucoup d'enthousiasme depuis son white paper, publié par Poon et Dryja en 2016. Il existe actuellement plus de 3 000 nodes Lightning, avec plus de 2 millions de dollars de valeur totale bloquée TVL). La Lightning Torch vaut plus de 100 $, et elle est transmise par des titans de la hi-tech comme Jack Dorsey & Reid Hoffman, et des mastodontes financiers comme Fidelity.

Lightning vise à scaler Bitcoin. Lightning a été l'une des premières solutions de Layer 2, proposant ingénieusement de prendre les transactions off-chain, tout en continuant à s'appuyer sur la sécurité de la blockchain. Il promet non seulement de faire évoluer les paiements, mais aussi de le faire avec une faible latence et des frais minimes.

Lightning présente également plusieurs inconvénients. Passons en revue certains d'entre eux :

Exigence d’Authenticité : Un Payeur doit être en ligne pour effectuer un paiement - rien d'étonnant à cela. Mais dans Lightning - contrairement à Bitcoin - le bénéficiaire doit également être en ligne, afin de signer la transaction avec sa clé privée (nous reviendrons plus tard sur les considérations de sécurité des opérations). Pire encore, à partir de ce moment, le bénéficiaire doit surveiller la blockchain pour s'assurer que le Payeur ne soumet pas un état périmé (outdated state) de son solde, et fermer le channel. Les nœuds de routage doivent également être en ligne entre les délais d'expiration des canaux en amont et en aval (upstream and downstream), afin de participer au protocole (c'est-à-dire transmettre la préimage), avant que le HTLC en amont n'expire.

Lightning tente de résoudre ce dernier problème, celui de la surveillance de la blockchain, en introduisant des tours de garde, un service auquel les utilisateurs peuvent déléguer, contre des frais, la responsabilité de surveiller le réseau.

Inefficacité du Capital : En général, en échange de l’utilité, les Payeurs sont prêts à immobiliser du capital - pensez aux cartes de débit, par exemple. Mais dans Lightning, le capital doit être bloqué par channel, et pas seulement par le Payeur.

Pire encore, si le paiement n'est pas envoyé directement du Payeur au bénéficiaire, mais qu'il passe par d'autres nœuds de routage, ces nœuds doivent également bloquer au moins le montant payé.

Dans le cas idéal - du point de vue de l'efficacité du capital - d'un nœud central unique dans un réseau en étoile, la limite supérieure de la liquidité du réseau est le montant du capital que le nœud central est prêt à bloquer ; de manière non intuitive, le montant bloqué par les Payeurs ne contribue en rien à la liquidité du réseau. En d'autres termes, les nœuds de routage doivent apporter de la liquidité au réseau, ce qui est un trait quelque peu surprenant et indésirable.

Que faire si l'on souhaite éviter ces réseaux centralisés ? Plus il y a de sauts (par des noeuds de routage), plus le coût du capital est élevé - car il s'agit d'un capital bloqué, au lieu de générer des intérêts ailleurs. Par exemple, si Alice veut envoyer 1 coin à Bob via 5 nœuds de routage, il faudra bloquer 5 coins dans le Lightning network. Ce coût (et le coût supplémentaire des griefing attacks où les nœuds de routage deviennent non coopératifs) devra se traduire par des frais supportés par les transacteurs ; l'absence de tels frais aujourd'hui pourrait s'expliquer par le comportement altruiste des premiers adoptants de Lightning.

La motivation à réduire l'inefficacité du capital est une force de centralisation dans l'écosystème Lightning. Le degré de centralisation de Lightning est évidemment un sujet d'intérêt.

Challenge de la Sécurité des Opérations : Une critique souvent entendue à l'égard des échanges centralisés est qu'ils créent des honey pots de crypto-monnaies, qui attirent les hackers. Mis à l'échelle, les nœuds de routage des réseaux Lightning créeront un honey pot beaucoup plus tentant. Pensez à l'exposition d’avoir une clé privée dans un hot wallet : les échanges centralisés ne doivent être exposés que brièvement, au moment de leur choix. Les nœuds de routage, en revanche, doivent fournir un service quasi instantané, et seront donc exposés à tout moment. Et afin d'être utiles, ils doivent conserver un capital suffisant (par channel !). Cela a l'étoffe d'un honey pot idéal : beaucoup de capital, et une clé privée à proximité. La protection de ce honey pot entraînera une dépense très probablement couverte par les frais.

Le Taux de Réussite Diminue avec la Valeur du Paiement : Étant donné que chaque channel dans un paiement multi-sauts doit avoir un capital bloqué supérieur au montant du paiement, les paiements de valeur élevée ont une probabilité de réussite plus faible, car ils auront simplement moins de routes à choisir dans le réseau. L'offre restreinte peut également se traduire par des frais plus élevés lorsque la valeur du paiement augmente. Idéalement, on souhaiterait bien sûr que le taux de réussite soit indépendant de la valeur de la transaction.

Le Taux de Réussite Diminue avec la Directionnalité : Tout comme l'impact négatif de l'augmentation de la valeur du paiement, lorsque de nombreux Payeurs paient un seul bénéficiaire - un cas d'utilisation très naturel des clients qui paient les commerçants dans le monde réel - ils seront tous en concurrence pour une offre limitée de capacité des nœuds de routage, en route vers leur bénéficiaire. Notez que la Lighning Torch contourne ce cas d'utilisation.

Au sens large, il semblerait que la consommation de ressources de Lightning évolue en fonction de la valeur totale des transactions, et pas seulement en fonction du nombre de participants ou du nombre de paiements effectués. Ce n'est évidemment pas une propriété souhaitée dans une solution de sclabilité des paiements.

[Note : pour des raisons de simplicité, nous supposons ici que le routage de Lightning est résolu à la perfection, gratuitement. Il y a bien sûr ceux qui pensent que c'est un problème difficile]

“Et maintenant, pour quelque chose de complètement différent (M. Python)”

StarkPay a pour objectif d'offrir une solution de paiement non-custodial scalable et capital-efficient, sans exigence d’authenticité.

StarkPay comprend des blocks de construction (building blocks) off-chain et on-chain.

• Un Processeur de Paiement, qui interagit avec les Payeurs et les bénéficiaires.

• Arbre des soldes des Payeurs (Payers’ balances tree) : ils sont mis à jour par le Prouveur, et leur disponibilité est assurée (voir plus loin).

• Un Prouveur, qui génère des preuves STARK attestant de la validité des lots de paiements fournis par le Processeur de Paiement, et de la validité de la mise à jour des soldes des Payeurs.

• Un contrat de paiement, qui est la rampe d'accès et de sortie de StarkPay, et qui contient également un engagement envers les soldes actualisés des Payeurs (stockés off-chain, comme mentionné ci-dessus).

• Un contrat de vérificateur (verifier contract), qui vérifie les preuves générées par le Prouveur, et communique avec le contrat de paiement.

Passons en revue quelques scénarios de base :

Le Payeur dépose des crypto-monnaies dans le contrat de paiement. Les fonds sont transférés, à l'aide de preuves, du contrat de paiement vers l'arbre des soldes off-chain. Cette procédure est analogue à la mise en place d'un channel Lightning, à la différence importante qu'elle n'est pas limitée à un seul destinataire.

Les fonds sont transférés de l'arbre des soldes off-chain vers le contrat de paiement - une fois encore, en utilisant des preuves - et de là, le Payeur peut les transférer ailleurs. Ceci est analogue à la fermeture d'un channel Lightning.

• Alice signe (elle n'a jamais renoncé à la custody !) son paiement à Bob et l'envoie au Processeur de paiement.

• Le Processeur de paiement envoie un lot de paiements, y compris le paiement d'Alice, au Prouveur.

• Le Prouveur génère une preuve STARK attestant de la validité des paiements dans le lot et de la validité de la mise à jour des soldes : il contrôle les signatures numériques, vérifie que le Payeur dispose de fonds suffisants, puis met à jour l'engagement des soldes (par exemple, une racine de Merkle).

• Le Prouveur envoie la preuve et le nouvel engagement au contrat du verifieur on-chain. Une fois la preuve vérifiée, le vérificateur envoie au contrat de paiement le nouvel engagement, qu'il conserve dans le stockage on-chain (comme indiqué ci-dessus).

Il n'y a pas d'hypothèse de confiance à l'égard du prouveur - un prouveur malveillant ou négligent ne sera pas en mesure de convaincre le contrat du vérificateur qu'une preuve invalide est en fait valide.

Nous pensons que cette architecture de système offre les avantages escomptés :

Scalabilité : Les ressources informatiques consommées par StarkPay varient en fonction du nombre de Payeurs et du nombre de paiements effectués. Il est important de noter qu'elles ne varient pas en fonction de la valeur totale des transactions. Nous avons déjà atteint une échelle intéressante : StarkPay pourra prendre en charge plus de 10 000 paiements en un seul block, conformément aux contraintes de gas actuelles d'Ethereum.

Admirablement, les STARKs consomment les ressources informatiques on-chain extrêmement rares avec modération : ceux-ci croissent logarithmiquement avec la taille du calcul off-chain. Pour donner un exemple numérique : pour multiplier StarkPay par 10, la consommation de ressources informatiques on-chain augmentera de moins de 50 %.

Notez que lorsque vous observez un concept potentiellement intéressant tel que la valeur/seconde, et pas seulement les transactions/seconde, StarkPay est effectivement sans limite.

Efficacité du Capital : Comme dans la métaphore de la carte de débit, aucun capital supplémentaire ne doit être bloqué au-delà des fonds que chaque Payeur souhaite payer. En particulier, le Processeur de Paiement et le Prouveur n'ont aucun besoin de liquidité.

Sans que le bénéficiaire soit en ligne (liveness-free) : Une mise à jour du solde d'un bénéficiaire ne nécessite pas qu'il soit en ligne. Dans tous les scénarios (dépôt, retrait et paiement), la transaction peut être effectuée hors ligne, puis envoyée au Processeur de Paiement de la blockchain.

Non-Custodial : Les Payeurs ne confient pas la garde (custody) des crypto-monnaies à StarkPay. La signature du Payeur est requise pour toutes les actions, et il peut retirer des fonds à tout moment directement du contrat de Paiement, même si le Prouveur devient malveillant ou non coopératif (plus d'informations sur cette échappatoire dans un futur blog post).

À cet égard, StarkPay égale la propriété de Lightning, car là aussi, l'utilisateur conserve la garde de la crypto-monnaie.

StarkPay présente quelques inconvénients notables :

Disponibilité des Données : Pour tirer véritablement parti du scaling logarithmique on-chain des STARKs, il est préférable de stocker les données off-chain, ce qui pose un problème de disponibilité des données. La disponibilité des données est un défi que les solutions basées sur Plasma doivent résoudre, afin de rester exemptes de confiance tout en parvenant à briser le plafond de scalabilité.

• Enregistrer les paiements on-chain : Nous pensons que StarkPay, dans ce mode, peut facilement atteindre plusieurs centaines de paiements par seconde.

• Une direction future possible pour les données off-chain : former une fédération de témoins de disponibilité des données qui signent que pour une preuve donnée présentée au vérificateur on-chain, les données étaient disponibles off-chain. Le vérificateur on-chain n'acceptera pas les preuves qui n'ont pas cette attestation. Il est important de noter que la fédération n'est pas chargée de garantir la validité de l'état du système - elle ne peut pas voler de l'argent, ni faire passer le système dans un état invalide. Cette fédération sera ensuite supprimée au profit d'une solution plus décentralisée.

Centralisation : Les Prouveurs seront initialement gérés par StarkWare. Cela présente le risque d'une centralisation et, par voie de conséquence, de la censure.

• Centralisation : d'autres participants au marché, y compris d'autres Processeurs de Paiement, peuvent naturellement fournir leurs propres Prouveurs. À plus long terme, les Prouveurs peuvent s'appuyer sur un protocole de consensus pour se disputer l'activité de génération de preuves dans leur propre réseau. Notez que puisque l'état n'est changé que par des preuves de validité, le Prouveurs ne peut pas attaquer le réseau en passant à un état invalide, et dans ce sens, cela rappelle la façon dont le consensus du Layer-1 est maintenu.

• Censure : Les STARKs peuvent être utilisés pour assurer la confidentialité en plus de StarkPay. En particulier, les Payeurs pourraient protéger leurs paiements même à l'égard du Prouveur lui-même ! La déclaration computationnelle (de calcul) prouvée par le Prouveur serait alors qu'il a vérifié un lot de preuves de paiements individuels reçus des Payeurs.

Temps de Latence : Contrairement au règlement instantané garanti dans un channel Lightning peer-to-peer, le temps nécessaire pour générer des preuves pour des lots importants est actuellement de l'ordre de quelques minutes.

• Le Prouveur peut fournir un engagement au contrat de paiement, immédiatement après avoir vérifié un lot de paiements reçus, tout en générant la preuve. Le risque que prend le bénéficiaire - encore une fois, un risque qui dure plusieurs minutes - est que le Prouveur retienne la preuve indéfiniment. Ce risque peut être compensé par la mise en jeu de fonds par le Prouveur, par exemple. A noter : la latence obtenue sera celle de la chain principale, et non la latence quasi-instantanée de Lightning. Comme toujours, la latence ne doit pas être assimilée au débit : StarkPay peut fournir un débit plus élevé en augmentant (scaling up) les ressources informatiques du Prouveur, qui résident toutes off-chain.

Pas de solution Bitcoin : Dans sa forme actuelle, Bitcoin ne peut pas prendre en charge un vérificateur STARK efficace fonctionnant on-chain.

Atténuation : Faites-nous savoir si vous en avez une. En attendant, nous nous concentrerons sur les blockchains qui supportent efficacement un vérificateur STARK on-chain.

Dans ce post, nous avons présenté StarkPay, un moteur de scalabilité basé sur STARK pour les paiements en crypto-monnaies. Nous avons commencé par analyser Lightning, une solution de scalabilité populaire pour Bitcoin, et l'avons comparée à StarkPay. Nous avons conclu que StarkPay offre une alternative convaincante, qui améliore Lightning dans plusieurs dimensions notables.

Merci à Vitalik Buterin, Patrick McCorry, Jim Posen et Dan Robinson pour leurs commentaires sur les versions préliminaires de ce post.

Tom Brand, Uri Kolodny, and Avihu Levy

Traduction faite par HoVa.

Initialement publié en anglais par StarkWare le 4 mars, 2019

Scaler les paiements avec les STARKs

Résumé : StarkPay, un moteur de scalabilité des paiements basé sur la technologie STARK, remédie à un bon nombre des inconvénients de Lightning, la solution de paiement Layer-2.

La première application de la technologie STARK par StarkWare concerne les moteurs de scalabilité de Layer 2. Nous avons récemment annoncé StarkDEX , un moteur de scalabilité pour les DEX (avec quelques premiers résultats intéressants).

Notre moteur de scalabilité peut être utilisé pour les paiements en crypto-monnaies - nous l'appelons StarkPay. L'avènement des stablecoins remplit une condition nécessaire pour que les crypto-monnaies puissent être utilisées comme moyen d'échange. Il manque encore à l'écosystème un système de paiement scalable. Nous pensons que StarkPay peut répondre à ce besoin.

Cet article compare StarkPay à Lightning, la solution de scalabilité la plus importante pour les paiements en bitcoins. Nous commencerons par passer en revue les avantages et les inconvénients de Lightning, tels que nous les comprenons. Nous décrirons ensuite l'architecture de base de StarkPay, ainsi que son interface utilisateur (UX). Enfin, nous dresserons la liste des avantages et des inconvénients de StarkPay, ainsi que des mesures d'atténuation possibles via certaines idées prometteuses que nous entrevoyons pour l'avenir.

Cet article ne traitera pas des fonctions de confidentialité qui peuvent être ajoutées aux deux solutions.

Lightning, un protocole de paiement scalable de Layer 2, a suscité beaucoup d'enthousiasme depuis son white paper, publié par Poon et Dryja en 2016. Il existe actuellement plus de 3 000 nodes Lightning, avec plus de 2 millions de dollars de valeur totale bloquée TVL). La Lightning Torch vaut plus de 100 $, et elle est transmise par des titans de la hi-tech comme Jack Dorsey & Reid Hoffman, et des mastodontes financiers comme Fidelity.

Lightning vise à scaler Bitcoin. Lightning a été l'une des premières solutions de Layer 2, proposant ingénieusement de prendre les transactions off-chain, tout en continuant à s'appuyer sur la sécurité de la blockchain. Il promet non seulement de faire évoluer les paiements, mais aussi de le faire avec une faible latence et des frais minimes.

Lightning présente également plusieurs inconvénients. Passons en revue certains d'entre eux :

Exigence d’Authenticité : Un Payeur doit être en ligne pour effectuer un paiement - rien d'étonnant à cela. Mais dans Lightning - contrairement à Bitcoin - le bénéficiaire doit également être en ligne, afin de signer la transaction avec sa clé privée (nous reviendrons plus tard sur les considérations de sécurité des opérations). Pire encore, à partir de ce moment, le bénéficiaire doit surveiller la blockchain pour s'assurer que le Payeur ne soumet pas un état périmé (outdated state) de son solde, et fermer le channel. Les nœuds de routage doivent également être en ligne entre les délais d'expiration des canaux en amont et en aval (upstream and downstream), afin de participer au protocole (c'est-à-dire transmettre la préimage), avant que le HTLC en amont n'expire.

Lightning tente de résoudre ce dernier problème, celui de la surveillance de la blockchain, en introduisant des tours de garde, un service auquel les utilisateurs peuvent déléguer, contre des frais, la responsabilité de surveiller le réseau.

Inefficacité du Capital : En général, en échange de l’utilité, les Payeurs sont prêts à immobiliser du capital - pensez aux cartes de débit, par exemple. Mais dans Lightning, le capital doit être bloqué par channel, et pas seulement par le Payeur.

Pire encore, si le paiement n'est pas envoyé directement du Payeur au bénéficiaire, mais qu'il passe par d'autres nœuds de routage, ces nœuds doivent également bloquer au moins le montant payé.

Dans le cas idéal - du point de vue de l'efficacité du capital - d'un nœud central unique dans un réseau en étoile, la limite supérieure de la liquidité du réseau est le montant du capital que le nœud central est prêt à bloquer ; de manière non intuitive, le montant bloqué par les Payeurs ne contribue en rien à la liquidité du réseau. En d'autres termes, les nœuds de routage doivent apporter de la liquidité au réseau, ce qui est un trait quelque peu surprenant et indésirable.

Que faire si l'on souhaite éviter ces réseaux centralisés ? Plus il y a de sauts (par des noeuds de routage), plus le coût du capital est élevé - car il s'agit d'un capital bloqué, au lieu de générer des intérêts ailleurs. Par exemple, si Alice veut envoyer 1 coin à Bob via 5 nœuds de routage, il faudra bloquer 5 coins dans le Lightning network. Ce coût (et le coût supplémentaire des griefing attacks où les nœuds de routage deviennent non coopératifs) devra se traduire par des frais supportés par les transacteurs ; l'absence de tels frais aujourd'hui pourrait s'expliquer par le comportement altruiste des premiers adoptants de Lightning.

La motivation à réduire l'inefficacité du capital est une force de centralisation dans l'écosystème Lightning. Le degré de centralisation de Lightning est évidemment un sujet d'intérêt.

Challenge de la Sécurité des Opérations : Une critique souvent entendue à l'égard des échanges centralisés est qu'ils créent des honey pots de crypto-monnaies, qui attirent les hackers. Mis à l'échelle, les nœuds de routage des réseaux Lightning créeront un honey pot beaucoup plus tentant. Pensez à l'exposition d’avoir une clé privée dans un hot wallet : les échanges centralisés ne doivent être exposés que brièvement, au moment de leur choix. Les nœuds de routage, en revanche, doivent fournir un service quasi instantané, et seront donc exposés à tout moment. Et afin d'être utiles, ils doivent conserver un capital suffisant (par channel !). Cela a l'étoffe d'un honey pot idéal : beaucoup de capital, et une clé privée à proximité. La protection de ce honey pot entraînera une dépense très probablement couverte par les frais.

Le Taux de Réussite Diminue avec la Valeur du Paiement : Étant donné que chaque channel dans un paiement multi-sauts doit avoir un capital bloqué supérieur au montant du paiement, les paiements de valeur élevée ont une probabilité de réussite plus faible, car ils auront simplement moins de routes à choisir dans le réseau. L'offre restreinte peut également se traduire par des frais plus élevés lorsque la valeur du paiement augmente. Idéalement, on souhaiterait bien sûr que le taux de réussite soit indépendant de la valeur de la transaction.

Le Taux de Réussite Diminue avec la Directionnalité : Tout comme l'impact négatif de l'augmentation de la valeur du paiement, lorsque de nombreux Payeurs paient un seul bénéficiaire - un cas d'utilisation très naturel des clients qui paient les commerçants dans le monde réel - ils seront tous en concurrence pour une offre limitée de capacité des nœuds de routage, en route vers leur bénéficiaire. Notez que la Lighning Torch contourne ce cas d'utilisation.

Au sens large, il semblerait que la consommation de ressources de Lightning évolue en fonction de la valeur totale des transactions, et pas seulement en fonction du nombre de participants ou du nombre de paiements effectués. Ce n'est évidemment pas une propriété souhaitée dans une solution de sclabilité des paiements.

[Note : pour des raisons de simplicité, nous supposons ici que le routage de Lightning est résolu à la perfection, gratuitement. Il y a bien sûr ceux qui pensent que c'est un problème difficile]

“Et maintenant, pour quelque chose de complètement différent (M. Python)”

StarkPay a pour objectif d'offrir une solution de paiement non-custodial scalable et capital-efficient, sans exigence d’authenticité.

StarkPay comprend des blocks de construction (building blocks) off-chain et on-chain.

• Un Processeur de Paiement, qui interagit avec les Payeurs et les bénéficiaires.

• Arbre des soldes des Payeurs (Payers’ balances tree) : ils sont mis à jour par le Prouveur, et leur disponibilité est assurée (voir plus loin).

• Un Prouveur, qui génère des preuves STARK attestant de la validité des lots de paiements fournis par le Processeur de Paiement, et de la validité de la mise à jour des soldes des Payeurs.

• Un contrat de paiement, qui est la rampe d'accès et de sortie de StarkPay, et qui contient également un engagement envers les soldes actualisés des Payeurs (stockés off-chain, comme mentionné ci-dessus).

• Un contrat de vérificateur (verifier contract), qui vérifie les preuves générées par le Prouveur, et communique avec le contrat de paiement.

Passons en revue quelques scénarios de base :

Le Payeur dépose des crypto-monnaies dans le contrat de paiement. Les fonds sont transférés, à l'aide de preuves, du contrat de paiement vers l'arbre des soldes off-chain. Cette procédure est analogue à la mise en place d'un channel Lightning, à la différence importante qu'elle n'est pas limitée à un seul destinataire.

Les fonds sont transférés de l'arbre des soldes off-chain vers le contrat de paiement - une fois encore, en utilisant des preuves - et de là, le Payeur peut les transférer ailleurs. Ceci est analogue à la fermeture d'un channel Lightning.

• Alice signe (elle n'a jamais renoncé à la custody !) son paiement à Bob et l'envoie au Processeur de paiement.

• Le Processeur de paiement envoie un lot de paiements, y compris le paiement d'Alice, au Prouveur.

• Le Prouveur génère une preuve STARK attestant de la validité des paiements dans le lot et de la validité de la mise à jour des soldes : il contrôle les signatures numériques, vérifie que le Payeur dispose de fonds suffisants, puis met à jour l'engagement des soldes (par exemple, une racine de Merkle).

• Le Prouveur envoie la preuve et le nouvel engagement au contrat du verifieur on-chain. Une fois la preuve vérifiée, le vérificateur envoie au contrat de paiement le nouvel engagement, qu'il conserve dans le stockage on-chain (comme indiqué ci-dessus).

Il n'y a pas d'hypothèse de confiance à l'égard du prouveur - un prouveur malveillant ou négligent ne sera pas en mesure de convaincre le contrat du vérificateur qu'une preuve invalide est en fait valide.

Nous pensons que cette architecture de système offre les avantages escomptés :

Scalabilité : Les ressources informatiques consommées par StarkPay varient en fonction du nombre de Payeurs et du nombre de paiements effectués. Il est important de noter qu'elles ne varient pas en fonction de la valeur totale des transactions. Nous avons déjà atteint une échelle intéressante : StarkPay pourra prendre en charge plus de 10 000 paiements en un seul block, conformément aux contraintes de gas actuelles d'Ethereum.

Admirablement, les STARKs consomment les ressources informatiques on-chain extrêmement rares avec modération : ceux-ci croissent logarithmiquement avec la taille du calcul off-chain. Pour donner un exemple numérique : pour multiplier StarkPay par 10, la consommation de ressources informatiques on-chain augmentera de moins de 50 %.

Notez que lorsque vous observez un concept potentiellement intéressant tel que la valeur/seconde, et pas seulement les transactions/seconde, StarkPay est effectivement sans limite.

Efficacité du Capital : Comme dans la métaphore de la carte de débit, aucun capital supplémentaire ne doit être bloqué au-delà des fonds que chaque Payeur souhaite payer. En particulier, le Processeur de Paiement et le Prouveur n'ont aucun besoin de liquidité.

Sans que le bénéficiaire soit en ligne (liveness-free) : Une mise à jour du solde d'un bénéficiaire ne nécessite pas qu'il soit en ligne. Dans tous les scénarios (dépôt, retrait et paiement), la transaction peut être effectuée hors ligne, puis envoyée au Processeur de Paiement de la blockchain.

Non-Custodial : Les Payeurs ne confient pas la garde (custody) des crypto-monnaies à StarkPay. La signature du Payeur est requise pour toutes les actions, et il peut retirer des fonds à tout moment directement du contrat de Paiement, même si le Prouveur devient malveillant ou non coopératif (plus d'informations sur cette échappatoire dans un futur blog post).

À cet égard, StarkPay égale la propriété de Lightning, car là aussi, l'utilisateur conserve la garde de la crypto-monnaie.

StarkPay présente quelques inconvénients notables :

Disponibilité des Données : Pour tirer véritablement parti du scaling logarithmique on-chain des STARKs, il est préférable de stocker les données off-chain, ce qui pose un problème de disponibilité des données. La disponibilité des données est un défi que les solutions basées sur Plasma doivent résoudre, afin de rester exemptes de confiance tout en parvenant à briser le plafond de scalabilité.

• Enregistrer les paiements on-chain : Nous pensons que StarkPay, dans ce mode, peut facilement atteindre plusieurs centaines de paiements par seconde.

• Une direction future possible pour les données off-chain : former une fédération de témoins de disponibilité des données qui signent que pour une preuve donnée présentée au vérificateur on-chain, les données étaient disponibles off-chain. Le vérificateur on-chain n'acceptera pas les preuves qui n'ont pas cette attestation. Il est important de noter que la fédération n'est pas chargée de garantir la validité de l'état du système - elle ne peut pas voler de l'argent, ni faire passer le système dans un état invalide. Cette fédération sera ensuite supprimée au profit d'une solution plus décentralisée.

Centralisation : Les Prouveurs seront initialement gérés par StarkWare. Cela présente le risque d'une centralisation et, par voie de conséquence, de la censure.

• Centralisation : d'autres participants au marché, y compris d'autres Processeurs de Paiement, peuvent naturellement fournir leurs propres Prouveurs. À plus long terme, les Prouveurs peuvent s'appuyer sur un protocole de consensus pour se disputer l'activité de génération de preuves dans leur propre réseau. Notez que puisque l'état n'est changé que par des preuves de validité, le Prouveurs ne peut pas attaquer le réseau en passant à un état invalide, et dans ce sens, cela rappelle la façon dont le consensus du Layer-1 est maintenu.

• Censure : Les STARKs peuvent être utilisés pour assurer la confidentialité en plus de StarkPay. En particulier, les Payeurs pourraient protéger leurs paiements même à l'égard du Prouveur lui-même ! La déclaration computationnelle (de calcul) prouvée par le Prouveur serait alors qu'il a vérifié un lot de preuves de paiements individuels reçus des Payeurs.

Temps de Latence : Contrairement au règlement instantané garanti dans un channel Lightning peer-to-peer, le temps nécessaire pour générer des preuves pour des lots importants est actuellement de l'ordre de quelques minutes.

• Le Prouveur peut fournir un engagement au contrat de paiement, immédiatement après avoir vérifié un lot de paiements reçus, tout en générant la preuve. Le risque que prend le bénéficiaire - encore une fois, un risque qui dure plusieurs minutes - est que le Prouveur retienne la preuve indéfiniment. Ce risque peut être compensé par la mise en jeu de fonds par le Prouveur, par exemple. A noter : la latence obtenue sera celle de la chain principale, et non la latence quasi-instantanée de Lightning. Comme toujours, la latence ne doit pas être assimilée au débit : StarkPay peut fournir un débit plus élevé en augmentant (scaling up) les ressources informatiques du Prouveur, qui résident toutes off-chain.

Pas de solution Bitcoin : Dans sa forme actuelle, Bitcoin ne peut pas prendre en charge un vérificateur STARK efficace fonctionnant on-chain.

Atténuation : Faites-nous savoir si vous en avez une. En attendant, nous nous concentrerons sur les blockchains qui supportent efficacement un vérificateur STARK on-chain.

Dans ce post, nous avons présenté StarkPay, un moteur de scalabilité basé sur STARK pour les paiements en crypto-monnaies. Nous avons commencé par analyser Lightning, une solution de scalabilité populaire pour Bitcoin, et l'avons comparée à StarkPay. Nous avons conclu que StarkPay offre une alternative convaincante, qui améliore Lightning dans plusieurs dimensions notables.

Merci à Vitalik Buterin, Patrick McCorry, Jim Posen et Dan Robinson pour leurs commentaires sur les versions préliminaires de ce post.

Tom Brand, Uri Kolodny, and Avihu Levy

Traduction faite par HoVa.