Initialement publié en anglais par StarkWare le 22 Octobre, 2020

Déplacer des fonds entre les différents L2 avec le minimum de frictions

TL;DR

• L’interopérabilité des L2 signifie que les utilisateurs peuvent transférer des fonds entre les L2 avec le minimum de friction sur L1.
• La solution d’interopérabilité L2 proposée repose sur notre primitive cryptographique, Transaction conditionnelle (Tx) suggérée précédemment.
• StarkEx 2.0 (novembre 2020) offrira l’interopérabilité L2-L1 (retrait rapide), en utilisant des Tx conditionnelles on-chain.
• StarkEx 3.0 (février 2021) offrira l’interopérabilité L2-L2 entre les systèmes StarkEx, en utilisant des Tx conditionnelles off-chain.

Background

Les solutions de scaling pour les L2 évoluent rapidement. Il existe déjà plusieurs systèmes de preuve de validité sur Mainnet, ainsi que des systèmes de preuve de fraude sur testnet. Les solutions L2 résolvent les problèmes de scalabilité, mais elles le font à un coût: elles peuvent briser ou diminuer diverses caractéristiques auxquelles on s’attend en travaillant strictement sur L1. Nous ne nous attendons pas à ce qu’une seule solution L2 les règle tous : les besoins des applications nécessitant de la scalabilité sont variés. Les applications choisiront des solutions dans un espace de conception L2 riche.

Avant d’aller plus loin, définissons deux termes importants :

• Interopérabilité : C’est la possibilité de permettre aux utilisateurs de transférer efficacement des fonds de l’app1 (l’environnement Origine) à l’app2 (l’environnement Destination).

• Composabilité : C’est la possibilité d’envoyer une transaction impliquant des opérations sur l’app_1, app_2,. . . , app_n.

  Note : la composabilité fera l’objet d’un autre post.

En plus de ces définitions, nous nous appuierons sur une version renforcée de Conditional-Tx, un primitif important, qui permettra l’interopérabilité.

Transaction conditionnelle (Conditional-TX)

Il s’agit d’un module cryptographique (nous avons d’abord parlé de ce sujet ici) utilisé pour implémenter l’interopérabilité pour les blockchains permissionless. Une Conditional-Tx est une transaction conditionnée à un événement (par exemple un paiement, un changement d’état) se produisant. Conceptuellement, nous définissons une Conditional-Tx dans l’environnement Origine, et il devient valide une fois que sa condition est satisfaite dans un autre environnement (généralement, l’environnement Destination).

Une approche par étapes

En l’absence d’une meilleure solution, l’utilisateur a toujours la possibilité de transférer naïvement des fonds de l’Origine L2 vers L1, et de là vers la Destination L2. Cette approche est à la fois lente et coûteuse, et elle le deviendra encore plus à mesure que la demande d’interopérabilité augmentera.

Nous devons faire mieux. En particulier, nous prévoyons l’approche suivante.

Phase I: StarkEx (L2) → Ethereum (L1) – Retraits rapides

Répondre au besoin des utilisateurs de retirer rapidement des fonds de StarkEx, un système L2, vers L1. Il ne s’agit pas seulement de l’adresse L1 de l’utilisateur, mais plutôt de toute destination sur L1, tel que Compound, Aave, etc. Il permet aux utilisateurs de retirer des fonds en « Blockchain Time », indépendamment de la fréquence avec laquelle StarkEx prouve des lots de transactions.

Étude de cas : Alice souhaite déplacer 1 ETH de son compte dYdX sur L2, vers son adresse L1.

Participants:

• Alice (un utilisateur avec des ETH sur L2)
• LP (fournisseur de liquidités avec des fonds sur L1)
• L’opérateur StarkEx dans l’environnement Origine (dans l’exemple ci-dessus, dYdX)

Circuit : (1) Alice donne au LP une Tx conditionnelle pour 1 ETH (+ les frais du LP), à condition que le LP transfère 1 ETH à l’adresse L1 d’Alice. (2) Après que le LP paie Alice sur le L1, la Tx conditionnelle devient valide, et (3) le LP la soumet à l’Opérateur, pour qu’il l’inclue dans le lot suivant qu’il prouve. (4) Une fois que la preuve suivante est soumise sur L1 et vérifiée, le solde L2 du LP reflète le transfert de fonds d’Alice.

Rééquilibrage périodique : Le LP doit périodiquement réapprovisionner les fonds de son compte L1 en baisse, à partir des fonds accumulés sur son compte L2.

Phase II : StarkEx (L2) → StarkEx (L2)

Les premiers déploiements StarkEx hébergeront chacun une seule application. Dans cette phase, nous souhaitons permettre aux utilisateurs de transférer rapidement des fonds entre ces différentes applications. Tout comme les retraits rapides, nous voulons minimiser les coûts on-chain pour les utilisateurs, et leur épargner la nécessité d’attendre que le lot suivant soit testé.

Étude de cas : Alice souhaite déplacer 1 ETH de son compte dYdX (L2_1) vers son compte DeversiFi (L2_2).

Participants :

• Alice (un utilisateur avec des ETH sur L2_1)
• LP (fournisseur de liquidités avec des fonds sur L2_2)
• L’opérateur StarkEx dans l’environnement d'origine (dans l’exemple ci-dessus, dYdX)

Circuit :

• (1) Alice donne au LP une transaction conditionnelle signée pour 1 ETH (+ les frais du LP) en L2_1, à condition que le LP transfère 1 ETH sur le compte L2_2 d’Alice.
• (2) Le LP paie Alice sur L2_2
• (3) un lot contenant ce paiement est prouvé par l’opérateur L2_2 et vérifié sur L1. Après l’acceptation du lot sur L1, la Conditional-Tx devient valide
• (4) le LP le soumet à l’opérateur L2_1 pour qu’il soit inclus dans le lot suivant qu’il prouve.
• (5) Une fois que le lot suivant de L2_1 est prouvé et soumis au L1 pour vérification, le solde L2_1 de la LP reflète le transfert de fonds d’Alice.

Rééquilibrage périodique : Le LP doit rééquilibrer périodiquement les fonds de ses L2_1 et L2_2, selon le flux net de fonds entre ces deux systèmes.

Le principal coût du soutien à l’interopérabilité consistera à payer aux PL leurs coûts d’investissement ; il faut noter que ces coûts d’investissement s’étendent sur une période très limitée, à savoir le temps qui s’écoule entre la fourniture de liquidités à l’utilisateur et le traitement du lot suivant par l’opérateur. Nous prévoyons que ce délai commencera à quelques heures (au plus) et diminuera ensuite au temps de génération de preuves (minutes) à mesure que la cadence – dans toutes les applications StarkEx – augmente.

Phase III : L2 → L2

Développer la phase II en permettant le transfert de fonds à travers n’importe quelle solution de L2, qu’il s’agisse d’un système de validité ou d’un système de fraude (Optimistic Rollups, Plasma). Il convient de rappeler ici l’inconvénient inhérent à l’efficience du capital auquel les systèmes seront confrontés lorsqu’ils prendront en charge une solution d’interopérabilité utilisant les LPs (voir ici).

Trust Model

Nous exposons maintenant le modèle de confiance sur lequel nous nous appuyons.

Pour les utilisateurs

Entièrement trustless

Pour les LP

Le LP doit faire confiance à l’Opérateur (dans l’environnement d’origine) pour inclure leur Conditional-Tx valide, c’est-à-dire ne pas les censurer, dans le prochain lot traité. Cette exigence de confiance peut être supprimée de plusieurs façons.

Si la Conditional-Tx du LP n’est pas traité rapidement par l’opérateur, le LP peut :

• Contrer la censure : soumettre la Conditional-Tx censurée au smart-contract on-chain de l’Opérateur, ce qui bloquera le traitement ultérieur des preuves de l’Opérateur.
• Dépôt de garantie : soumettre la Conditional-Tx censurée à un smart contract de dépôt de garantie on-chain, et recevoir le paiement directement de celui-ci.

Le chemin à parcourir

• La phase I arrivera sur Mainnet Ethereum en novembre 2020 (StarkEx 2. 0), et la phase II suivra sur Mainnet au T1 2021 (StarkEx 3. 0). Nous avons déjà des LP pour alimenter ces services.
• La phase III suivra peu après. Nous anticipons la demande des différentes applications de L2 pour interagir avec des applications fonctionnant sur d’autres solutions L2, et nous sommes impatients de discuter de ces intégrations avec d’autres acteurs L2.

Pour en savoir plus, regardez Tom Brand’s Lecture on L2 Scaling – Interoperability with Shared State à la conférence Liquidity 2020 (inscription requise).

Tom Brand & Uri Kolodny

¹Plus tard, il s’agira probablement de l’une des rares options de déploiement. Nous imaginons un monde où différentes applications peuvent avoir des préférences différentes, à cet égard.

Traduction faite par @Theyozz