Initialement publié en anglais par StarkWare le 10 Mars, 2021

Un élément constitutif pour l’interopérabilité L1-L2

Cet article présente la solution proposée par StarkEx pour soutenir les retraits rapides: la possibilité de retirer des fonds de L2 vers n’importe quelles adresses L1, à la vitesse de la blockchain. Cette solution est indépendante de la fréquence à laquelle les preuves de validité sont produites par l’opérateur L2.

La fonctionnalité de retrait rapide fonctionne déjà sur Ethereum Mainnet dans StarkEx (à partir de StarkEx 2.0, Décembre 2020) et alimente les échanges de DeversiFi et dYdX.

La solution ci-dessous peut être appliquée à un large éventail de cas d’utilisation, au-delà des retraits rapides. Décrivons d’abord le besoin abstrait.

Les blockchains permettent une interaction trustless entre deux parties, Alice et Bob. Alice pourrait vouloir publier une transaction qui ne peut être exécutée que lorsqu’un événement conditionnel se produit; Bob voudrait exécuter la transaction d’Alice une fois cette condition remplie, sans avoir à obtenir à nouveau son approbation. Nous appelons la première qui soutient cette spécification, une transaction conditionnelle (TC).

L’implémentation d’une TC sur une L1 est simple, car un smart contract peut forcer le couplage entre l’événement et l’exécution de la transaction. Lorsque l’on passe aux systèmes L2, cela devient un challenge. Par exemple, dans StarkEx, le signataire transmet la transaction signée à l’exploitant, qui est chargé de l’exécuter, et rien n’empêche l’exploitant d’exécuter la transaction avant que la condition demandée ne soit remplie.

Dans cet article, nous nous concentrons sur une TC spécifique sur une L2, qui dépend d’un événement L1 (i. e. L2 | L1). En d’autres termes, l’EC permet à l’opérateur d’exécuter une transaction signée seulement si un événement on-chain s’est produit. À l’avenir, nous ajouterons une TC qui dépend d’un événement sur un autre événement d’une L2 (i. e. L21 | L22), ce qui permettra l’interopérabilité entre les instances StarkEx et StarkNet.

Ci-dessous, nous formalisons la notion de tels événements on-chain et voyons comment ils peuvent être utilisés pour les TC dans StarkEx.

Les TC utilisent les contrats du Fact Registry pour suivre les événements on-chain. Une TC ne peut être conditionné à des événements que s’ils sont enregistrés dans un registre factuel. Par exemple, si Alice transfère 1 ETH à Bob directement sur Ethereum, il n’y a pas d’événement on-chain qui pourrait être utilisé comme une TC.

Dans l’exemple ci-dessus, le contrat Fact Registry nécessiterait un transfert de fonction (), qu’Alice invoque avec l’adresse de Bob comme paramètre de destinataire.

Le transfert () fait deux choses: (a) envoie l’ETH transmis au destinataire, et (b) conserve un enregistrement du transfert, par exemple en stockant un hachage des paramètres de transfert (expéditeur, destinataire et quantité) dans la mémoire du contrat.

Le Fact Registry a aussi une fonction isValid (), qui reçoit un hachage en paramètre, et retourne un booléen – True si et seulement si c’est un hachage d’une transaction enregistrée par ce contrat. Le hachage de la transaction (les paramètres de transfert, dans notre exemple ci-dessus) est appelé un fait – représentant l’occurrence de l’événement. Le processus d’introduction d’un nouveau fait dans un registre des faits est souvent appelé enregistrement des faits.

Un événement on-chain signé dans une TC contient deux champs (en réalité, leur hachage), (a) l’adresse d’un contrat d’enregistrement des faits et (b) un fait qui devrait être enregistré avant l’exécution de la transaction.

StarkEx regroupe les transactions, et les règle toutes on-chain avec une seule preuve STARK. Si l’une des transactions du lot est une TC, StarkEx s’assurera que le fait associé est bien enregistré afin de régler le lot; sinon, le lot entier est retourné.

Dans cette section, nous montrerons les cas d’utilisation et la façon dont ils peuvent être mis en œuvre à l’aide des TC

Dans n’importe quelle solution L2, la façon naïve de transférer des fonds entre une L2 et une L1 est de finaliser une mise à jour de statut du L2, y compris une transaction de retrait sur une L1. Dans les systèmes basés sur la Validity Proof, comme StarkEx, la finalisation d’une mise à jour d’état L2 se produit lorsqu’une preuve valide l’attestant est acceptée on-chain, ce qui prend habituellement 10 secondes. Cela signifie que si un utilisateur veut transférer ses fonds d’une L2 à une L1, il est obligé d’attendre.

Le but des retraits rapides est de découpler cette dépendance, et permettre aux utilisateurs de retirer sans confiance leurs fonds vers une L1 “à la vitesse de la blockchain”, c’est-à-dire au sein d’une transaction Ethereum.

Comment cela fonctionnerait-il ? Si Alice veut retirer 1 ETH de L2 à L1, Alice peut signer une TC transférant 1 ETH à un fournisseur de liquidités (LP) en L2, à condition que le LP transfère 1 ETH (moins certains frais) à Alice en L1. La TC d’Alice ne peut être exécuté que si elle obtient d’abord ses fonds sur L1, donc elle n’encourt aucun risque de contrepartie.

Regardons dans cet exemple un contrat de registre de faits qui peut faciliter un tel transfert -

Nous pouvons voir que le contrat a un transfert de fonction payable () qui fait les deux choses suivantes -

1. Transfère la quantité d’eth à l’adresse

2. Enregistre keccack (account, address, nonce) comme “true”

La TC signée par Alice ne peut être exécutée que si le Fact keccack (1 ETH, Alice, nonce) est enregistré dans le Fact Registry. Ce fait, à son tour, ne peut être enregistré que si le transfert de 1 ETH à Alice a déjà eu lieu.

Alice a été en mesure de retirer 1 ETH à son adresse sans confiance, et tout ce qu’il fallait était sa signature et une seule transaction Ethereum de la LP.

Un flux semblable peut saisir les types d’événements suivants dans le cadre d’une TC de L2, par exemple:

• Alice veut vendre son 1ETH sur une L2 pour 1000DAI sur une L1, si le prix de l’ETH monte à 1010 DAI (tel qu’enregistré on-chain par un oracle connu)

• Alice veut donner à Bob 10ETH sur une L2, si Bob dépose 9,5 ETH sous le nom d’Alice dans une dApp de son choix (comme Aave ou Compound)

• Alice veut donner 10 ETH pour Bob sur la L2 de DeversiFi si Bob dépose 9,5 ETH sur le compte DyDx d’Alice sur une L2

Le premier cas d’utilisation d’une TC sont les retraits rapide, mais les opérateurs StarkEx peuvent implémenter de nombreuses interactions L2-L1 en utilisant ce module.

Michael Riabzev, Ohad Barta et Tom Brand

Traduction faite par @Theozz

Initialement publié en anglais par StarkWare le 10 Mars, 2021

Un élément constitutif pour l’interopérabilité L1-L2

Cet article présente la solution proposée par StarkEx pour soutenir les retraits rapides: la possibilité de retirer des fonds de L2 vers n’importe quelles adresses L1, à la vitesse de la blockchain. Cette solution est indépendante de la fréquence à laquelle les preuves de validité sont produites par l’opérateur L2.

La fonctionnalité de retrait rapide fonctionne déjà sur Ethereum Mainnet dans StarkEx (à partir de StarkEx 2.0, Décembre 2020) et alimente les échanges de DeversiFi et dYdX.

La solution ci-dessous peut être appliquée à un large éventail de cas d’utilisation, au-delà des retraits rapides. Décrivons d’abord le besoin abstrait.

Les blockchains permettent une interaction trustless entre deux parties, Alice et Bob. Alice pourrait vouloir publier une transaction qui ne peut être exécutée que lorsqu’un événement conditionnel se produit; Bob voudrait exécuter la transaction d’Alice une fois cette condition remplie, sans avoir à obtenir à nouveau son approbation. Nous appelons la première qui soutient cette spécification, une transaction conditionnelle (TC).

L’implémentation d’une TC sur une L1 est simple, car un smart contract peut forcer le couplage entre l’événement et l’exécution de la transaction. Lorsque l’on passe aux systèmes L2, cela devient un challenge. Par exemple, dans StarkEx, le signataire transmet la transaction signée à l’exploitant, qui est chargé de l’exécuter, et rien n’empêche l’exploitant d’exécuter la transaction avant que la condition demandée ne soit remplie.

Dans cet article, nous nous concentrons sur une TC spécifique sur une L2, qui dépend d’un événement L1 (i. e. L2 | L1). En d’autres termes, l’EC permet à l’opérateur d’exécuter une transaction signée seulement si un événement on-chain s’est produit. À l’avenir, nous ajouterons une TC qui dépend d’un événement sur un autre événement d’une L2 (i. e. L21 | L22), ce qui permettra l’interopérabilité entre les instances StarkEx et StarkNet.

Ci-dessous, nous formalisons la notion de tels événements on-chain et voyons comment ils peuvent être utilisés pour les TC dans StarkEx.

Les TC utilisent les contrats du Fact Registry pour suivre les événements on-chain. Une TC ne peut être conditionné à des événements que s’ils sont enregistrés dans un registre factuel. Par exemple, si Alice transfère 1 ETH à Bob directement sur Ethereum, il n’y a pas d’événement on-chain qui pourrait être utilisé comme une TC.

Dans l’exemple ci-dessus, le contrat Fact Registry nécessiterait un transfert de fonction (), qu’Alice invoque avec l’adresse de Bob comme paramètre de destinataire.

Le transfert () fait deux choses: (a) envoie l’ETH transmis au destinataire, et (b) conserve un enregistrement du transfert, par exemple en stockant un hachage des paramètres de transfert (expéditeur, destinataire et quantité) dans la mémoire du contrat.

Le Fact Registry a aussi une fonction isValid (), qui reçoit un hachage en paramètre, et retourne un booléen – True si et seulement si c’est un hachage d’une transaction enregistrée par ce contrat. Le hachage de la transaction (les paramètres de transfert, dans notre exemple ci-dessus) est appelé un fait – représentant l’occurrence de l’événement. Le processus d’introduction d’un nouveau fait dans un registre des faits est souvent appelé enregistrement des faits.

Un événement on-chain signé dans une TC contient deux champs (en réalité, leur hachage), (a) l’adresse d’un contrat d’enregistrement des faits et (b) un fait qui devrait être enregistré avant l’exécution de la transaction.

StarkEx regroupe les transactions, et les règle toutes on-chain avec une seule preuve STARK. Si l’une des transactions du lot est une TC, StarkEx s’assurera que le fait associé est bien enregistré afin de régler le lot; sinon, le lot entier est retourné.

Dans cette section, nous montrerons les cas d’utilisation et la façon dont ils peuvent être mis en œuvre à l’aide des TC

Dans n’importe quelle solution L2, la façon naïve de transférer des fonds entre une L2 et une L1 est de finaliser une mise à jour de statut du L2, y compris une transaction de retrait sur une L1. Dans les systèmes basés sur la Validity Proof, comme StarkEx, la finalisation d’une mise à jour d’état L2 se produit lorsqu’une preuve valide l’attestant est acceptée on-chain, ce qui prend habituellement 10 secondes. Cela signifie que si un utilisateur veut transférer ses fonds d’une L2 à une L1, il est obligé d’attendre.

Le but des retraits rapides est de découpler cette dépendance, et permettre aux utilisateurs de retirer sans confiance leurs fonds vers une L1 “à la vitesse de la blockchain”, c’est-à-dire au sein d’une transaction Ethereum.

Comment cela fonctionnerait-il ? Si Alice veut retirer 1 ETH de L2 à L1, Alice peut signer une TC transférant 1 ETH à un fournisseur de liquidités (LP) en L2, à condition que le LP transfère 1 ETH (moins certains frais) à Alice en L1. La TC d’Alice ne peut être exécuté que si elle obtient d’abord ses fonds sur L1, donc elle n’encourt aucun risque de contrepartie.

Regardons dans cet exemple un contrat de registre de faits qui peut faciliter un tel transfert -

Nous pouvons voir que le contrat a un transfert de fonction payable () qui fait les deux choses suivantes -

1. Transfère la quantité d’eth à l’adresse

2. Enregistre keccack (account, address, nonce) comme “true”

La TC signée par Alice ne peut être exécutée que si le Fact keccack (1 ETH, Alice, nonce) est enregistré dans le Fact Registry. Ce fait, à son tour, ne peut être enregistré que si le transfert de 1 ETH à Alice a déjà eu lieu.

Alice a été en mesure de retirer 1 ETH à son adresse sans confiance, et tout ce qu’il fallait était sa signature et une seule transaction Ethereum de la LP.

Un flux semblable peut saisir les types d’événements suivants dans le cadre d’une TC de L2, par exemple:

• Alice veut vendre son 1ETH sur une L2 pour 1000DAI sur une L1, si le prix de l’ETH monte à 1010 DAI (tel qu’enregistré on-chain par un oracle connu)

• Alice veut donner à Bob 10ETH sur une L2, si Bob dépose 9,5 ETH sous le nom d’Alice dans une dApp de son choix (comme Aave ou Compound)

• Alice veut donner 10 ETH pour Bob sur la L2 de DeversiFi si Bob dépose 9,5 ETH sur le compte DyDx d’Alice sur une L2

Le premier cas d’utilisation d’une TC sont les retraits rapide, mais les opérateurs StarkEx peuvent implémenter de nombreuses interactions L2-L1 en utilisant ce module.

Michael Riabzev, Ohad Barta et Tom Brand

Traduction faite par @Theozz