Introduction
StarkEx est une solution de scalabilité Layer 2 self-custody construit au-dessus d’Ethereum. Il utilise les preuves de validité STARK et propose différentes solutions de data availability.
Lancé en juin 2020, StarkEx est un moteur dédié à la scalabilité self-custody conçus par StarkWare.
À la différence de StarkNet, il n’est pas sans permission (permissionless), il est conçu spécialement pour répondre aux besoins spécifiques d’applications. Il permet actuellement d’effectuer des opérations complexes telles que :
- la création de produit financier, spot trading et dérivés (Rhino.fi; dYdX; GammaX)
- bridge L2 avec Layer2 Finance par Celer Network
- application de trading NFT (Sorare)
- jeux utilisant des NFT (Immutable)
Sur StarkEx les transactions sont regroupées par lots et validées (off-chain) s’ensuit la génération d’une preuve STARK et sont envoyées par lots sur L1 (on-chain). De plus la Data Availability (DA) est stockée off-chain faisant de StarkEx une solution Validium (au niveau de la DA).
StarkEx – Un système Self-custody
Plusieurs dicton incarne la vision de la blockchain, tel que “Ne faites pas confiance, vérifiez” avec l’arrivé des systèmes de preuve, cependant un est particulièrement encré il s’agit de «not your keys, not your coins.» Or en raison des limitations de débit cet idée à changer pour favoriser une meilleur scalabilité et une liquidité qui en découle, bien sur porté par les exchanges centralisé. Ils portent la garde des actifs cryptographique des utilisateurs et offre de la liquidité en retour.
Néanmoins depuis quelques années avec les avancées d’ingénierie derrière les systèmes Zero-Konwledge Proof (zkp) et particulièrement les STARKs tendent à remettre la lumière sur les systèmes Self-Custody.
Les systèmes ZKP sont à la fois capables de fournir la scalabilité et la confidentialité d’une manière trustless (sans confiance) aux blockchains sans permission. Pour exécuter un sytème self-custody il en va de soit le besoin d’une infrastructure trustless, toute hypothèse de confiance est proscrit.
En effet, en s’appuyant sur la ”Computational Integrity” des systèmes ZKP, une entité nommé prouver va générer une preuve off-chain pour n’importe quel calcul ou transition d’état et permet à n’importe quel nombre d’entités nommé “vérifieur” de vérifier le preuve on-chain.
Il n’y a pas d’hypothèse de confiance dans le prouver (ni en temps réel ni en prétraitement) car les preuves STARKs ne nécessite aucune configuration initiale de confiance via une entité externe (à la différence des preuves SNARKs). Pour ce qui est du vérifieur, il s’exécute on-chain et sa source est disponible.
Quelles sont les caractéristiques pouvant définir un système “Self-Custody” ?
- Les fonds ne peuvent être changer manuellement sans une signature explicite de l’utilisateur
- Lors de la signature, toutes les informations sont mises à disposition de l’utilisateur afin de comprendre ce qu’il est entrain d’effectuer (via l’UX du wallet)
- Les fonds peuvent toujours être retirés
- La logique ci-dessus ne peut-être altéré en abusant d’un mécanisme de mise à niveau du code
En opposition aux système Custody tel que les exchanges, Self-Custody vise à éliminer certains risques et protéger et avertir les utilisateurs sur leurs propres responsabilités.
(Source)
StarkEx système et composants
Cette partie détails les flux d’interactions au sein du système StarkEx et comment ses interactions sont exécutées.
- Application – Opérateur du système
C’est la porte d’entrée entre les actions des utilisateurs et le système StarkEx, en effet ce composant (off-chain) reçoit les transactions des utilisateurs et définit la business logic et l’ordre d’exécution et transmet les transactions au service StarkEx.
- Service StarkEx – Batching et coordination
Ce composant (off-chain) est chargé de regrouper (batching) un ensemble d’opérations sous forme de lot et ainsi mettre à jour l’état du système en fonction des opérations.
Chaque lot d’opérations est envoyé sous la forme d’une trace d’exécution Cairo à SHARP afin de prouver sa validité. Une fois la preuve vérifiée, le nouvel état est publié on-chain. Cet état est représenté par un arbre de Merkle dont la structure et le contenu de chaque vault varient en fonction de la logique opérationnelle mise en œuvre (plus de détails ici).
En outre, la racine Merkle représente l’engagement de l’état à soumettre on-chain.
- SHARP – Attestation de validité
SHARP reçoit les demandes de preuves et produit des preuves attestant la validité des exécutions Cairo. (en savoir plus ici)
- Stark Vérifieur – Vérification
Ce composant on-chain reçoit les preuves de validités pour la mise à jour de l’état et vérifie que la preuve est bien valide.
- StarkEx Contract – Mise à jour d’état et exécution des opérations
Ce contrat on-chain possède deux fonctionnalités :
- il gère la mise à jour de l’état du système après avoir vérifié que les conditions de validité soit complète
- il gère les dépôts et les retraits à destination et en provenance de StarkEx de manière non-dépositaire de sorte que l’utilisateur soit en mesure de retirer ses fonds
Qu’est-ce que Data Availbaility ?
La Data Availability (DA) et en français la “Disponibilité des Données” garantit que l’état stocker dans les vaults des utilisateurs soit parfaitement synchronisé avec l’état stocké par StarkEx.
C’est pourquoi les applications alimentées par StarkEx doivent pouvoir rendre les données de leurs utilisateurs toujours disponibles afin d’agir en cas de besoins.
Différent mode de Data Availability
L’une des caractéristiques de StarkEx est d’être disponibles en plusieurs modes de Data Availability (DA) :
- Rollup : les données sont stockées on-chain ainsi les transactions sont enregistrées en tant que données d’appel (calldata)
- Validium : les données sont stockées off-chain. DA off-chain est plus scalable car ce mode consomme une quantité essentiellement fixe de ressources quel que soit le volume et est rendu possible avec le DAC (voir ci-dessous)
- Volition : solution hybride ou les données sont stockées on-chain/off-chain au choix des utilisateurs
Quelles sont les compromis des différents modes ?
- Avec le mode Rollup la publication des données on-chain décentralise les données, les rendant disponibles afin que les utilisateurs puissent les suivre et superviser. Le coup de publication des données on-chain est plus élevé que de la faire off-chain.
- En mode Validium le stockage des données étant effectué off-chain ceci réduit les coûts et améliore la confidentialité, car les données ne sont pas exposées au grand public. En revanche, l’utilisateur doit faire confiance à l’Opérateur pour gérer et stocker correctement ses données, cependant des mesures sont prises pour minimiser cette confiance (voir ci-dessous la partie DAC)
- Le mode Volition permet aux utilisateurs de choisir quelle solution convient le mieux pour chaque besoin, et ce, pour n’importe quelles transactions. Certains utilisateurs seront plus soucieux de la décentralisation de leurs données et choisiront le mode Rollup, pour d’autres la réduction des coûts en gas sera le plus important.
Pour conclure, le mode Rollup ou Validium vérifie tous deux les preuves avec une sécurité d’Ethereum cependant ils ont un modèle de menace différent.
En effet, Validium dispose d’une sécurité partagée pour la publication des données
Data Availability Committee (DAC)
Afin de garder un esprit sans confiance au sein de StarkEx, un Data Availability Committee est mis en place afin que les utilisateurs ne fassent pas uniquement confiance aux opérateurs StarkEx.
Par exemple, StarkEx ne soumet pas de nouvel état on-chain sans l’approbation signée du DAC.
Les membres du DAC sont chargés de :
- conserver des copies des données off-chain
- les remettre dans le domaine public en cas d’urgence*
- recevoir chaque transition d’état, calculer le nouvel état et signer l’engagement envers le nouvel état.
*En cas d’urgence : c’est-à-dire dans le cas ou les opérateurs StarkEx ne répondent pas aux demandes de retrait des utilisateurs.
Ainsi, le Smart Contract d’Application (ASC) n’accepte plus la mise à jour des nouvelles transitions d’état et autorisera que les retraits directs de fonds par des utilisateurs. Les utilisateurs peuvent accéder au chemin de Merkle vers leurs comptes afin d’utiliser ce chemin pour récupérer leurs fonds auprès de l’ASC de façons turstless car ne faisant à aucun moment confiance aux opérateurs StarkEx.
Il est aussi prévu de crypter les données stockées par la DAC dans le but de garantir que les membres du DAC ne soient plus au courant des données relatives aux utilisateurs de StarkEx et réduit la responsabilité et la confiance implicite des utilisateurs envers les membres du DAC.
Quelles sont les responsabilisées de StarkWare ?
C’est une question légitime de se demander quelle influence porte StarkWare dans tout ça.
StarkWare est responsable :
- du calcul des preuves et du maintien du Smart Contract Vérifieur (basé sur L1) ainsi les partenaires n’ont pas besoin de savoir quelconque informations sur les preuves générés
- met en œuvre les fonctions de dépôts et de retrait on-chain ainsi que le mécanisme de retrait d’urgence – Escapte Hatch
- implémente un système de suivi blockchain qui gère les réorganisations des blocs et notifie au client si la réorganisation rend une transaction invalide
Le mode Volition sur StarkEx
“Avec le mode Volition chaque compte StarkEx sera défini comme un OFFD ou un OND. Imaginez un trading firm qui souhaite stocker des fonds en toutes sécurités et souhaite des frais de transactions peu élevés alors la journée commence avec les traders qui transfert des fonds sur le compte de données off-chain (OFFD) permettant de trader à moindre coût. Et à la fin de journée pour plus de sécurité les fonds sont transférés sur un compte de données on-chain (OND). L’utilisation en sera de même au choix de l’utilisateur, StarkEx produit une preuve par lot de transactions, cette preuve comprend des transactions impliquant un compte OND doit inclure comme entrée publique (call data) la balance post-batch (solde précédent le lot) de ces comptes.”
OND : publication des données chiffrées on-chain permettant aux traders de bénéficier de la sécurité d’un Rollup sans compromettre leur vie privé et exposer leurs stratégies de trading
OFFD : la protection de la vie privée permet aux membres du DAC de ne pas abuser de leur rôle (toujours possible d’attester via DA, mais ils ne peuvent connaître les détails des transactions ou des soldes de compte)
/!\ Que faire en quoi d’attaque ou les données ne sont pas disponibles ?
Si l’opérateur et le DAC sont compromis, nous pouvons passer le système à un nouvel état sans publier les données nécessaires en créant un état indisponible.
Cependant, Minimally Viable Rollback (MVR) résout ce problème permettant un rollback d’un état non disponible de données vers un état différent, pour lequel les données sont disponibles. Ceci est fait tout en préservant la solvabilité dans le nouveau état, évitant les doubles dépenses (plus de détails ici).
Sources utilisées pour l’élaboration de cet article :
Web | Github | Documentation technique | Documentation en français | StarkEx audits |