Initialement publié en anglais par StarkWare le 9 aout, 2021

Comment transférer des fonds entre les sidechains et StarkEx en toute confiance, en toute sécurité et à faible coût ?

• Le transfert de fonds entre sidechains et L2s est une nécessité croissante

• Méthodes actuelles : via L1 (Ethereum) – lente, coûteuse, mais trustless; ou via App (ou LP) – nécessite de la confiance, mais rapide et peu coûteuse

• Nous proposons un bridge trustless, sécurisé et peu coûteux sidechain-to-StarkEx bridge, qui s’appuie sur la sécurité de Ethereum

• En prolongeant un tel bridge entre StarkEx et plusieurs sidechains, nous créons un bridge efficace reliant ces sidechains

Alors que Ethereum reste la blockchain « capitale » de la DeFi, avec une traction et une sécurité élevée, et des bridge vers plusieurs chaînes, il est de plus en plus congestionné et souffre d’une augmentation et d’une volatilité des coûts de transactions. Cela conduit les utilisateurs vers d’autres plateformes telles que les sidechains (par exemple, Polygon, BSC, Solana) et les L2s (Optimistic Rollup “OR” ou ZK-Rollups). Ces plateformes varient en termes de coûts, de sécurité, de performances et d’applications disponibles, ce qui alimente la fragmentation.

Par conséquent, de plus en plus d’utilisateurs doivent transférer des fonds entre plusieurs plateformes.

Des solutions offrant des bridge trustless entre les sidechains arrivent en ligne (par exemple, Hop ou MovR). Cependant, l’interopérabilité trustless entre les L2s (en particulier les rollups) et les sidechains n’a pas encore été résolue.

L’interopérabilité avec Optimistic Rollups est problématique de par sa conception, car le long délai de finalité se traduit par des investissements importants pour l’exploitation du bridge, ce qui se traduit par des transferts coûteux.

Et ZK-Rollups ? Les dépôts et retraits trustless sur L1 et ZK-Rollups sont déjà disponibles sur les systèmes en direct (par ex : dYdX, DeversiFi, Loopring). De plus, ils offrent un court délai de finalité grâce aux transferts conditionnels.

Mais les ZK-Rollups sont actuellement incompatibles avec l’interopérabilité sidechain. La raison en est technique : les ZK-Rollups actuellement déployés sur L1 prouvent la validité of specific computational statements (même si les outils qui sont derrière, comme le langage Cairo, supportent l’exhaustivité de Turing). Cela les rend incompatibles avec les systèmes qui exigent un «smart contract d’interopérabilité» dans le cadre du Rollup.

StarkNet, notre ZK-Rollup décentralisé et permissionless va changer cela. Mais que peut-on faire à l’heure actuelle avec StarkEx notre solution scalable et trustless ? Nous montrons ci-dessous comment StarkEx peut prendre en charge l’interopérabilité avec les sidechains.

StarkEx est live sur le Mainnet depuis juin 2020, facilitant des millions de transactions d’une valeur globale de plusieurs milliards de dollars. Nous présenterons le système et les schémas StarkEx pour montrer comment prendre en charge le transfert rapide et peu coûteux vers les sidechains. Permettant d’ouvrir la voie à une meilleure interopérabilité entre les dApps fonctionnant sur ZK-Rollups et les sidechains. Mais d’abord, considérons ce qui définit un bon système d’interopérabilité.

Une bonne solution d’interopérabilité entre les sidechains et les L2 devrait garantir une confiance minimale et offrir une expérience utilisateur simplifié. Plus précisément :

1. Confiance minimale : les utilisateurs doivent être tenus de faire confiance à autant d’entités que possible, avec aussi peu que possible. (with as little as possible.)

2. Finalité rapide : les fonds devraient être disponibles rapidement.

3. Faible coût : les solutions peu coûteuses doivent offrir des prix peu élevés sur les plateformes respectives et un rendement élevé du capital sur le bridge (les coûts supportés par le liquidity provider étant compensés par l’utilisateur).

Jusqu’à présent, les utilisateurs qui souhaitaient transférer des fonds entre une sidechain et L2 devaient choisir entre deux options simple :

• une option trustless mais coûteuse et lente (Figure 1)

• une méthode peu coûteuse et rapide, mais qui exige de la confiance (Figure 2).

• Une option trustless mais coûteuse et lente (Figure 1)

• Une méthode peu coûteuse et rapide, mais qui exige de la confiance (Figure 2).

Nous montrons (Figure 3) notre solution proposée, où StarkEx facilite l’interopérabilité entre un L2 et une sidechain tout en satisfaisant aux trois qualités d’une solution d’interopérabilité efficace. Notez que cela s’applique également à l’interopérabilité entre les sidechains, en utilisant StarkEx comme un conduit.

Pour ceux qui ne connaissent pas StarkEx, nous présentons ces concepts essentiels. Vous trouverez la documentation complète de StarkEx ici. Mais, pour suivre les schémas, il suffit de rappeler le contexte suivant :

StarkEx est trustless

Comme StarkEx s’appuie sur les preuves STARKs, aucune mise à jour d’état ne peut avoir lieu sur L1 sans preuve que cet état est bien valide. Cela signifie que les fonds ne peuvent changer de mains au sein de StarkEx que selon la logique mise en œuvre par Cairo, qui impose ce qui suit :

• Les fonds ne peuvent pas être transférés d’un utilisateur sans sa signature valide sur la demande de transfert correspondante

• L’état StarkEx engagé sur L1 reflète tous les transferts qui se produisent dans l’environnement L2.

• StarkEx ne peut pas exécuter le même transfert deux fois

Le résultat est que l’Opérateur (par exemple, l’exchange) ne peut pas voler les fonds de l’utilisateur. Les transactions forcées, les trappes d’urgence et un mécanisme de mise à niveau dédié complètent le tableau, rendant StarkEx self-custodial

L’Opérateur peut considérer qu’une transaction est réglée une fois qu’elle entre dans la file d’attente de transactions StarkEx. Cela signifie que les utilisateurs peuvent soumettre instantanément des transactions ultérieures ; pas besoin d’attendre d’accord effectif de la transaction on-chain !

Sur StarkEx, même les grands ensembles de transactions perpetual coûtent aussi peu que 1100 gas en mode ZK-Rollup, ce qui est 200 fois moins cher qu’une implémentation L1 de la même logique. Les coûts sont encore moins élevés en mode Validium. De plus, StarkEx est capital efficient, finalisant les transactions dès que la preuve de leur exécution est publiée on-chain, ce qui se produit généralement quelques heures seulement après la transaction.

Étape 1 : L’utilisateur envoie une demande off-chain à l’Application, en précisant le montant et le type d’actif qu’il souhaite retirer. L’application vérifie que l’utilisateur a suffisamment de fonds dans son vault StarkEx.

Étape 2 : L’application verrouille la valeur et le type d’actif spécifiés dans un contrat d’interopérabilité trouvé sur la sidechain. L’application assemble ces fonds avec une demande de transfert (non signée) de StarkEx, qui ordonne à StarkEx de transférer les actifs pertinents du vault de l’utilisateur vers le vault de l’application.

Etape 3 : L’utilisateur signe la demande de transfert indiquée à la Fig. 4, ensuite en activant le contrat d’interopérabilité sur la sidechain. Cette transaction débloque immédiatement les fonds de l’utilisateur pour l’utiliser sur la sidechain.

Plans de secours : si l’utilisateur ne signe pas dans un délai limité, l’Application réclame l’argent du contrat d’interopérabilité.

Etape 4 : L’Application peut désormais exécuter la demande de transfert sur StarkEx et y recevoir les fonds de l’utilisateur.

1. Ce schéma est trustless : l’utilisateur obtient les fonds sur la sidechain avant qu’ils ne donnent les fonds à l’Opérateur sur StarkEx (et ce dernier ne peut pas se produire sans le premier) :

• StarkEx fait valoir que, afin de retirer des fonds de l’utilisateur, l’Application doit connaître sa signature.

• Fournir la signature déverrouille les fonds de l’utilisateur sur la sidechain.

1. C’est rapide ; les fonds sont accessibles à l’utilisateur après le double du temps de finalité de la sidechain.

2. Il est peu coûteux; n’implique pas de transactions L1, et l’application peut accéder aux fonds immédiatement sur StarkEx, et quelques heures plus tard sur L1.

Étape 1 : L’utilisateur verrouille ses fonds sur le compte sidechain du contrat d’interopérabilité. Ces fonds sont couplés à des paramètres de demande de transfert spécifiques sur StarkEx, ce qui permettrait de transférer de l’argent dans le vault de l’utilisateur.

Étape 2 : L’Opérateur exécute la demande de transfert de la Fig. 5 étape 1 dans StarkEx, libérant les fonds dans le vault StarkEx de l’utilisateur. L’utilisateur peut commencer à trader avec ces fonds immédiatement.

Étape 3 : Le transfert de l’étape 2 est mis en lots avec les autres transactions (Figure 5, étape 3.1). StarkEx prouve à L1 que ces transactions ont eu lieu (étape 3.2), et l’état on-chain est mis à jour en conséquence (étape 3.3).

Etape 4 : Un contrat dédié sur Ethereum transmet le nouvel état L1 au contrat d’interopérabilité sur la sidechain. Cet état, c’est-à-dire la racine Merkle de toutes les transactions sur StarkEx, confirme que l’utilisateur a reçu les fonds sur StarkEx comme demandé.

Étape 5 : L’Application ouvre l’engagement Merkle Tree pour prouver à la sidechain que l’utilisateur a bien reçu des fonds sur StarkEx dans la Fig. 5 étape 2, débloquant les fonds dans le contrat d’interopérabilité pour l’Application.

Plans de secours : si l’application ne parvient pas à compléter l’étape 5 de la Fig. 5 dans un délai limité, l’utilisateur peut récupérer les fonds de la sidechain du contrat d’interopérabilité.

Ce schéma est trustless : l’utilisateur reçoit les fonds sur StarkEx avant que l’Application puisse les réclamer sur la sidechain. La logique et les preuves StarkEx imposent que le second ne peut se produire sans le premier :

• Pour recevoir des fonds sur la sidechain, l’Opérateur doit montrer un enregistrement d’un transfert pertinent à l’utilisateur via StarkEx.

• StarkEx fait valoir qu’un tel dossier ne peut être trouvé que si l’utilisateur a reçu les fonds.

1. C’est rapide : une fois qu’une transaction est confirmée dans la sidechain, l’Application peut immédiatement remettre les fonds à l’utilisateur sur StarkEx.

2. C’est peu coûteux : les transactions sur la sidechain ou StarkEx sont peu coûteuses, et le coût élevé de la transaction L1 à l’étape 4 est partagé entre de nombreuses demandes de dépôt.

De plus, l’App peut obtenir ses fonds sur la sidechain après quelques heures.

Les clients de StarkEx profiteront bientôt des schémas d’interopérabilité trustless présentés ci-dessus.

Quant à StarkNet, notre ZK-Rollup décentralisé permissionless : StarkNet Planets Alpha 1 est déjà en service sur Ropsten et nous prévoyons de soutenir l’interopérabilité avec d’autres écosystèmes tels que les sidechains. Comme StarkNet démontre toute logique arbitraire, il peut supporter des mécanismes similaires à ceux décrits ici ou déployer des solutions d’interopérabilité existantes.

D’une manière ou d’une autre, StarkNet facilite un degré élevé d’interopérabilité, et deviendra un pôle centrale d’interopérabilité pour de nombreuses applications DeFi qui cherchent des moyens d’étendre au-delà d’Ethereum.

Traduction faite par @cleminso

Initialement publié en anglais par StarkWare le 9 aout, 2021

Comment transférer des fonds entre les sidechains et StarkEx en toute confiance, en toute sécurité et à faible coût ?

• Le transfert de fonds entre sidechains et L2s est une nécessité croissante

• Méthodes actuelles : via L1 (Ethereum) – lente, coûteuse, mais trustless; ou via App (ou LP) – nécessite de la confiance, mais rapide et peu coûteuse

• Nous proposons un bridge trustless, sécurisé et peu coûteux sidechain-to-StarkEx bridge, qui s’appuie sur la sécurité de Ethereum

• En prolongeant un tel bridge entre StarkEx et plusieurs sidechains, nous créons un bridge efficace reliant ces sidechains

Alors que Ethereum reste la blockchain « capitale » de la DeFi, avec une traction et une sécurité élevée, et des bridge vers plusieurs chaînes, il est de plus en plus congestionné et souffre d’une augmentation et d’une volatilité des coûts de transactions. Cela conduit les utilisateurs vers d’autres plateformes telles que les sidechains (par exemple, Polygon, BSC, Solana) et les L2s (Optimistic Rollup “OR” ou ZK-Rollups). Ces plateformes varient en termes de coûts, de sécurité, de performances et d’applications disponibles, ce qui alimente la fragmentation.

Par conséquent, de plus en plus d’utilisateurs doivent transférer des fonds entre plusieurs plateformes.

Des solutions offrant des bridge trustless entre les sidechains arrivent en ligne (par exemple, Hop ou MovR). Cependant, l’interopérabilité trustless entre les L2s (en particulier les rollups) et les sidechains n’a pas encore été résolue.

L’interopérabilité avec Optimistic Rollups est problématique de par sa conception, car le long délai de finalité se traduit par des investissements importants pour l’exploitation du bridge, ce qui se traduit par des transferts coûteux.

Et ZK-Rollups ? Les dépôts et retraits trustless sur L1 et ZK-Rollups sont déjà disponibles sur les systèmes en direct (par ex : dYdX, DeversiFi, Loopring). De plus, ils offrent un court délai de finalité grâce aux transferts conditionnels.

Mais les ZK-Rollups sont actuellement incompatibles avec l’interopérabilité sidechain. La raison en est technique : les ZK-Rollups actuellement déployés sur L1 prouvent la validité of specific computational statements (même si les outils qui sont derrière, comme le langage Cairo, supportent l’exhaustivité de Turing). Cela les rend incompatibles avec les systèmes qui exigent un «smart contract d’interopérabilité» dans le cadre du Rollup.

StarkNet, notre ZK-Rollup décentralisé et permissionless va changer cela. Mais que peut-on faire à l’heure actuelle avec StarkEx notre solution scalable et trustless ? Nous montrons ci-dessous comment StarkEx peut prendre en charge l’interopérabilité avec les sidechains.

StarkEx est live sur le Mainnet depuis juin 2020, facilitant des millions de transactions d’une valeur globale de plusieurs milliards de dollars. Nous présenterons le système et les schémas StarkEx pour montrer comment prendre en charge le transfert rapide et peu coûteux vers les sidechains. Permettant d’ouvrir la voie à une meilleure interopérabilité entre les dApps fonctionnant sur ZK-Rollups et les sidechains. Mais d’abord, considérons ce qui définit un bon système d’interopérabilité.

Une bonne solution d’interopérabilité entre les sidechains et les L2 devrait garantir une confiance minimale et offrir une expérience utilisateur simplifié. Plus précisément :

1. Confiance minimale : les utilisateurs doivent être tenus de faire confiance à autant d’entités que possible, avec aussi peu que possible. (with as little as possible.)

2. Finalité rapide : les fonds devraient être disponibles rapidement.

3. Faible coût : les solutions peu coûteuses doivent offrir des prix peu élevés sur les plateformes respectives et un rendement élevé du capital sur le bridge (les coûts supportés par le liquidity provider étant compensés par l’utilisateur).

Jusqu’à présent, les utilisateurs qui souhaitaient transférer des fonds entre une sidechain et L2 devaient choisir entre deux options simple :

• une option trustless mais coûteuse et lente (Figure 1)

• une méthode peu coûteuse et rapide, mais qui exige de la confiance (Figure 2).

• Une option trustless mais coûteuse et lente (Figure 1)

• Une méthode peu coûteuse et rapide, mais qui exige de la confiance (Figure 2).

Nous montrons (Figure 3) notre solution proposée, où StarkEx facilite l’interopérabilité entre un L2 et une sidechain tout en satisfaisant aux trois qualités d’une solution d’interopérabilité efficace. Notez que cela s’applique également à l’interopérabilité entre les sidechains, en utilisant StarkEx comme un conduit.

Pour ceux qui ne connaissent pas StarkEx, nous présentons ces concepts essentiels. Vous trouverez la documentation complète de StarkEx ici. Mais, pour suivre les schémas, il suffit de rappeler le contexte suivant :

StarkEx est trustless

Comme StarkEx s’appuie sur les preuves STARKs, aucune mise à jour d’état ne peut avoir lieu sur L1 sans preuve que cet état est bien valide. Cela signifie que les fonds ne peuvent changer de mains au sein de StarkEx que selon la logique mise en œuvre par Cairo, qui impose ce qui suit :

• Les fonds ne peuvent pas être transférés d’un utilisateur sans sa signature valide sur la demande de transfert correspondante

• L’état StarkEx engagé sur L1 reflète tous les transferts qui se produisent dans l’environnement L2.

• StarkEx ne peut pas exécuter le même transfert deux fois

Le résultat est que l’Opérateur (par exemple, l’exchange) ne peut pas voler les fonds de l’utilisateur. Les transactions forcées, les trappes d’urgence et un mécanisme de mise à niveau dédié complètent le tableau, rendant StarkEx self-custodial

L’Opérateur peut considérer qu’une transaction est réglée une fois qu’elle entre dans la file d’attente de transactions StarkEx. Cela signifie que les utilisateurs peuvent soumettre instantanément des transactions ultérieures ; pas besoin d’attendre d’accord effectif de la transaction on-chain !

Sur StarkEx, même les grands ensembles de transactions perpetual coûtent aussi peu que 1100 gas en mode ZK-Rollup, ce qui est 200 fois moins cher qu’une implémentation L1 de la même logique. Les coûts sont encore moins élevés en mode Validium. De plus, StarkEx est capital efficient, finalisant les transactions dès que la preuve de leur exécution est publiée on-chain, ce qui se produit généralement quelques heures seulement après la transaction.

Étape 1 : L’utilisateur envoie une demande off-chain à l’Application, en précisant le montant et le type d’actif qu’il souhaite retirer. L’application vérifie que l’utilisateur a suffisamment de fonds dans son vault StarkEx.

Étape 2 : L’application verrouille la valeur et le type d’actif spécifiés dans un contrat d’interopérabilité trouvé sur la sidechain. L’application assemble ces fonds avec une demande de transfert (non signée) de StarkEx, qui ordonne à StarkEx de transférer les actifs pertinents du vault de l’utilisateur vers le vault de l’application.

Etape 3 : L’utilisateur signe la demande de transfert indiquée à la Fig. 4, ensuite en activant le contrat d’interopérabilité sur la sidechain. Cette transaction débloque immédiatement les fonds de l’utilisateur pour l’utiliser sur la sidechain.

Plans de secours : si l’utilisateur ne signe pas dans un délai limité, l’Application réclame l’argent du contrat d’interopérabilité.

Etape 4 : L’Application peut désormais exécuter la demande de transfert sur StarkEx et y recevoir les fonds de l’utilisateur.

1. Ce schéma est trustless : l’utilisateur obtient les fonds sur la sidechain avant qu’ils ne donnent les fonds à l’Opérateur sur StarkEx (et ce dernier ne peut pas se produire sans le premier) :

• StarkEx fait valoir que, afin de retirer des fonds de l’utilisateur, l’Application doit connaître sa signature.

• Fournir la signature déverrouille les fonds de l’utilisateur sur la sidechain.

1. C’est rapide ; les fonds sont accessibles à l’utilisateur après le double du temps de finalité de la sidechain.

2. Il est peu coûteux; n’implique pas de transactions L1, et l’application peut accéder aux fonds immédiatement sur StarkEx, et quelques heures plus tard sur L1.

Étape 1 : L’utilisateur verrouille ses fonds sur le compte sidechain du contrat d’interopérabilité. Ces fonds sont couplés à des paramètres de demande de transfert spécifiques sur StarkEx, ce qui permettrait de transférer de l’argent dans le vault de l’utilisateur.

Étape 2 : L’Opérateur exécute la demande de transfert de la Fig. 5 étape 1 dans StarkEx, libérant les fonds dans le vault StarkEx de l’utilisateur. L’utilisateur peut commencer à trader avec ces fonds immédiatement.

Étape 3 : Le transfert de l’étape 2 est mis en lots avec les autres transactions (Figure 5, étape 3.1). StarkEx prouve à L1 que ces transactions ont eu lieu (étape 3.2), et l’état on-chain est mis à jour en conséquence (étape 3.3).

Etape 4 : Un contrat dédié sur Ethereum transmet le nouvel état L1 au contrat d’interopérabilité sur la sidechain. Cet état, c’est-à-dire la racine Merkle de toutes les transactions sur StarkEx, confirme que l’utilisateur a reçu les fonds sur StarkEx comme demandé.

Étape 5 : L’Application ouvre l’engagement Merkle Tree pour prouver à la sidechain que l’utilisateur a bien reçu des fonds sur StarkEx dans la Fig. 5 étape 2, débloquant les fonds dans le contrat d’interopérabilité pour l’Application.

Plans de secours : si l’application ne parvient pas à compléter l’étape 5 de la Fig. 5 dans un délai limité, l’utilisateur peut récupérer les fonds de la sidechain du contrat d’interopérabilité.

Ce schéma est trustless : l’utilisateur reçoit les fonds sur StarkEx avant que l’Application puisse les réclamer sur la sidechain. La logique et les preuves StarkEx imposent que le second ne peut se produire sans le premier :

• Pour recevoir des fonds sur la sidechain, l’Opérateur doit montrer un enregistrement d’un transfert pertinent à l’utilisateur via StarkEx.

• StarkEx fait valoir qu’un tel dossier ne peut être trouvé que si l’utilisateur a reçu les fonds.

1. C’est rapide : une fois qu’une transaction est confirmée dans la sidechain, l’Application peut immédiatement remettre les fonds à l’utilisateur sur StarkEx.

2. C’est peu coûteux : les transactions sur la sidechain ou StarkEx sont peu coûteuses, et le coût élevé de la transaction L1 à l’étape 4 est partagé entre de nombreuses demandes de dépôt.

De plus, l’App peut obtenir ses fonds sur la sidechain après quelques heures.

Les clients de StarkEx profiteront bientôt des schémas d’interopérabilité trustless présentés ci-dessus.

Quant à StarkNet, notre ZK-Rollup décentralisé permissionless : StarkNet Planets Alpha 1 est déjà en service sur Ropsten et nous prévoyons de soutenir l’interopérabilité avec d’autres écosystèmes tels que les sidechains. Comme StarkNet démontre toute logique arbitraire, il peut supporter des mécanismes similaires à ceux décrits ici ou déployer des solutions d’interopérabilité existantes.

D’une manière ou d’une autre, StarkNet facilite un degré élevé d’interopérabilité, et deviendra un pôle centrale d’interopérabilité pour de nombreuses applications DeFi qui cherchent des moyens d’étendre au-delà d’Ethereum.

Traduction faite par @cleminso