Initialement publié en anglais par StarkWare le 14 juin, 2020

La data availability n’est pas une dichotomie on-chain / off-chain

La data availability est un domaine riche, et non une dichotomie on-chain / off-chain. Les déploiements StarkEx couvriront tout ce domaine. Les instances StarkEx peuvent actuellement être déployées en mode Rollup (données on-chain) ou en mode Validium (données off-chain). Le tout premier déploiement de StarkEx est un Validium.

Nous décrivons un nouveau design : Volition, une solution de données hybride on-chain/off-chain, qui permet aux utilisateurs de choisir de manière dynamique l’endroit où ils souhaitent stocker leurs données. StarkEx supportera Volition bientôt.

Nous avons récemment lancé le premier déploiement StarkEx sur Ethereum Mainnet. Ce déploiement alimente le DEX DeversiFi . La solution Data Availability (DA) sélectionnée par DeversiFi dispose de données stockées off-chain par un comité DA (DAC). DeversiFi a choisi cette solution pour la V1.0 de son DEX car ses clients – les traders professionnels – ne peuvent pas enregistrer leurs historiques de trading on-chain, car cela exposerait leurs stratégies aux concurrents. DeversiFi a opté pour une solution qui répond à un besoin important de ses clients, tout en minimisant leur confiance dans le DAC. A noter : une autre raison pour laquelle DeversiFi a opté pour une solution de données off-chain est la scalabilité : elle permet la liquidité, une propriété importante pour un DEX émergent.

Une discussion sur la nomenclature a suivi notre lancement pour nommer correctement différentes solutions de scaling, en tenant compte de leur approche DA. Nous avons proposé d’améliorer les définitions comme suit.

Selon ces définitions, le nouveau DEX DeversiFi fonctionne en mode Validium.

Nous croyons que DA est une propriété importante d’une solution de scaling. Nous savons que différentes applications, différents utilisateurs, différents opérateurs ont tous leurs besoins particuliers, qui influencent leurs choix DA. Les entreprises qui développent des solutions de scaling devront offrir une gamme d’offres pour répondre à cette diversité de besoins des clients/utilisateurs.

Au cours de la dernière année, nous avons consacré des efforts considérables à la recherche de l’espace design DA. Il s’agit d’un espace multidimensionnel riche, et la compréhension de l’écosystème progressera sûrement à mesure que les blockchains se développeront. Notre espoir est d’expliquer les compromis existants que nous observons et de rechercher des moyens de les réduire. Plus précisément, nous nous engageons à poursuivre des modèles de DA qui évoluent sous-linéairement (càd. qui scale mieux que ZK-Rollups); à mesure que la congestion sur Ethereum augmente, de tels modèles deviendront de plus en plus importants. Si Ethereum devient l’infrastructure publique omniprésente que nous nous attendons à ce qu’il soit, il est impossible d'éviter cette exigence. Cet article décrit quelques tentatives différentes pour y remédier.

La proposition de valeur que nous visons est simple : donner aux utilisateurs la liberté de choisir – de leur plein gré – leurs préférences en matière de data availability au niveau de chaque transaction, à tout moment, pour n’importe quel type d’actif et pour n’importe quel montant. Imaginez une trading firm, avec son profil risque/rendement, qui dicte ses préférences pour stocker des fonds en toute sécurité et bénéficier de frais de transaction peu élevés. Dans une telle entreprise, une journée de trading commencerait par le transfert de fonds de ses traders sur le compte de données off-chain (OFFD), où ils peuvent trader fréquemment et à moindre coût tout au long de la journée. À la fermeture des bureaux, pour des raisons de sécurité, tous les fonds seront transférés à un compte de données on-chain (OND).

Conceptuellement, chaque compte StarkEx sera défini comme un OFFD ou un OND. Un utilisateur peut contrôler plusieurs comptes et transférer des fonds entre eux, au besoin. StarkEx produit une preuve par lot de transactions. Une preuve qui 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.

Il convient donc de mettre à jour le diagramme ci-dessus :

Nous mettons en œuvre cette conception et fournirons bientôt des détails supplémentaires sur son déploiement.

Les solutions actuellement disponibles sur le marché souffrent de problèmes de protection de la vie privée. Comme mentionné ci-dessus, les préoccupations en matière de protection de la vie privée ont poussé DeversiFi à choisir sa première version StarkEx. Les systèmes combinant Zero-Knowledge Proofs (ZKP) et cryptage permettent de rendre les données privées. Ceci peut être appliqué à OND (Rollup) et OFFD (Validium), pour offrir aux utilisateurs une meilleure confidentialité.

OND : Nous avons un design pour publier des données chiffrées on-chain. Cela permettrait aux traders de bénéficier de la sécurité d’un Rollup, sans compromettre leur vie privée 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 : ils pourraient toujours attester de la data availability, mais sans connaître les détails des transactions ou des soldes. Par conséquent, le nombre de membres du DAC StarkEx pourrait être multiplié par dix (par rapport à sa taille actuelle d’une demi-douzaine de membres). Avec un DAC plus grand, le quorum pour les signatures par lots pourrait également être augmenté. De plus, les responsabilités des membres du DAC seraient réduites à la signature stricte pour chaque lot traité par StarkEx ; les données pourraient être rendues publiques – les membres du DAC ne seraient plus chargés de garder les données confidentielles.

En conclusion, l’ajout de la confidentialité à StarkEx, quelle que soit la configuration choisie, peut en faire une offre meilleure et plus sécurisée.

Lors de l’examen des solutions OFFD, une préoccupation est une attaque de données indisponibles : si l’opérateur et le DAC sont compromis, on peut passer le système à un nouvel état sans publier les données nécessaires (créer un état indisponible).

MVR résout ce problème en permettant un rollback d’un état non disponible de données vers un état différent, pour lequel des données sont disponibles. Il le fait tout en préservant la solvabilité dans le nouvel état rétroactif (state_new), évitant ainsi les doubles dépenses. Dans un système MVR, chaque retrait est accompagné de la soumission, on-chain, des détails de toutes les transactions qui alimentent le vault retiré (dans les derniers lots). State_new est basé sur un état récent (state_recent), dont les données sont disponibles, mais n’en est pas une simple copie. Il s’agit plutôt d’un état « solvant », intégrant tous les flux récents entrants et sortants de StarkEx (dans les derniers lots) qui ont abouti à des retraits. Cela permet aux utilisateurs de se retirer du nouvel état.

La conception MVR empêche l’attaque suivante («double dépense») : l’attaquant retire des fonds après state_recent, puis déplace le système vers un état non disponible ; une fois que le système revient à state_recent, l’attaquant récupère les fonds déjà retirés.

Avec MVR, tant que l’attaque est détectée dans des lots k, le système peut revenir à state_new, car les preuves soumises dans ces lots contiennent suffisamment d’informations pour construire un état solvable.

En terme de scalabilité, certaines données sont donc envoyées on-chain, comme dans le cas courant, moins que dans un rollup (dans le pire des cas : autant qu'un rollup). Avec une conception correcte du système utilisant des retraits rapides, il n’y aura même pas d’entrée publique supplémentaire par rapport à un Validium.

Pour une description un peu plus détaillée, y compris la façon dont state_new est calculé, lisez ici.

Dans TODA, les utilisateurs peuvent fonctionner en toute confiance, en choisissant de devenir un Power User (PU). Les fonds d’un PU sont toujours sous leur garde : en général, un UP fournit une signature par preuve, tout comme les membres du DAC. Par sa signature, un UP confirme qu’il a accès à son propre OFFD, ce qui lui permet d’activer la trappe d’urgence, même si les membres du DAC ne respectent pas leur rôle de publication de toutes les données. En l’absence d’une telle signature en temps opportun, les fonds de l’UP sont automatiquement retirés on-chain dans le smart contract d’application – il s’agit d’un retrait protecteur, qui est au cœur de l’amélioration trustlessness TODA.

Un utilisateur qui préfère ne pas être un PU peut choisir à la place de faire confiance à une entité off-chain, bien qu'il ne soit plus limité à faire confiance à un membre du DAC - il peut choisir de faire confiance à tout PU désireux de servir de tour de guet en son nom (et devra autoriser ce PU à le faire). Nous publierons une description complète de ce protocole dans quelques temps.

La DA est un élément essentiel de tout système blockchain scalable. L'écosystème blockchain, et StarkWare en particulier, déploie des efforts considérables pour explorer cet espace de conception. Cet article a décrit quelques-unes des conceptions les plus intéressantes que nous avons en tête, notamment Volition, où les utilisateurs sont libres de choisir si leurs données résident on-chain/off-chain, chaque fois qu'ils effectuent une transaction.

~Tom Brand, Avihu Levy, Uri Kolodny

Traduction faite par @cleminso