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.
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.
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é.
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.
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.
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.