Initialement publié en anglais par StarkWare le 3 jun, 2020

StarkEx, un moteur de scalabilité self-custodial, vient d’être lancé sur Ethereum Mainnet (pour plus d’informations sur l’architecture générale du système et les flux). StarkEx implémente le protocole STARK Zero-Knowledge Proof (ZKP). Le chemin vers une solution self-custodial est difficile : les solutions custodial sont plus simples, moins chères et, surtout, bien mieux comprises – le monde construit des custodial software depuis des décennies. Le terme «Self-custodial», ou le synonyme «non-custodial», est utilisé assez libéralement. Ils sont utilisés par des opérateurs qui peuvent, d’un simple clic, assumer la garde complète des fonds de leurs utilisateurs : une situation surprenante, puisque les blockchains permissionless ont été conçues comme une alternative aux systèmes de garde. Nous sommes conscients des défis que pose l’établissement d’un véritable système self-custodial et de l’espace de conception multidimensionnel mis à la disposition des innovateurs dans cet espace. Nous nous rendons également compte que beaucoup trouvent utile de migrer vers une solution de plus en plus self-custodial au fil du temps. Cette série d’articles détaille les choix que nous avons faits, et la direction que nous prévoyons pour StarkEx, à cet égard.

Cet article est le premier d’une série soulignant les efforts que nous avons déployés sur plusieurs fronts pour garantir que StarkEx est, et restera toujours, une solution self-custodial.

Tout d’abord, il vaut la peine de définir ce que «self-custodial» signifie. À notre avis, un système ne peut être qualifié “self-custodial» que s’il satisfait aux caractéristiques suivantes :

1. Les fonds utilisateurs ne peuvent pas changer de mains sans leur signature explicite.

2. Lors de la signature, toutes les informations sont mises à la disposition de l’utilisateur (via le portefeuille UX).

3. Les fonds peuvent toujours être retirés.

4. La logique ci-dessus ne peut pas être altérée en abusant d’un mécanisme de mise à jour de code.

Cet article se concentrera sur les raisons pour lesquelles

• les systèmes de preuve sont spécialement conçus pour prendre en charge les solutions self-custodial

• les audits pour les smart contracts StarkEx. Les articles suivants de cette série décriront

• les mécanismes de mise à niveau des smart contrats que nous avons mis en place

• wallet support (le schéma de signature STARK et l’intégration)

• data availability (allant du comité de disponibilité des données qui soutient notre premier déploiement à la conception d’une solution de disponibilité des données off-chain totalement fiable).

Le Saint Graal self-custodial remonte à la vision originale de la blockchain, incarnée par le dicton «not your keys, not your coins.» Très tôt, en raison des limites de débit du Layer-1, cet idéal self-custodial a été échangé contre la scalabilité et la liquidité qui en découle. Les enfants-phares de ce compromis sont bien sûr des centralized exchanges : ils ont pris la garde des actifs cryptographiques des traders, et leur ont offert de la liquidité en retour (avec un peu de risque de contrepartie). Mais aujourd’hui, la science et l’ingénierie derrière les systèmes ZKP en général, et STARK en particulier, ils ont progressé au point où ils sont prêts pour leur heure de gloire – le compromis ci-dessus n’est plus nécessaire.

Les systèmes ZKP ont une histoire belle et complexe. Remarquablement, pour les blockchains permissionless, les systèmes ZKP sont capables de fournir à la fois la scalabilité et la confidentialité d’une manière trustless. Une solution self-custodial nécessite naturellement une infrastructure trustless. En d’autres termes, toute hypothèse de confiance peut facilement réduire à néant la self-custody, sinon la rendre totalement dénuée de sens.

Les systèmes ZKP sont composés d’une layer de base assurant la Computational Integrity (CI), avec une layer possible au sommet assurant le zero-knowledge. Pour prendre en charge les applications de scalabilité, nous nous appuyons en fait strictement sur la CI layer. La CI permet à une entité (le proveur) de 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 (vérifieur) de vérifier la preuve on-chain avec un effort de calcul minimal.

Idéalement, il y a aussi peu d’hypothèses de confiance que possible. Plus précisément, pour les STARKs :

• Proveur : Il n’y a pas d’hypothèses de confiance dans le Proveur, ni en temps réel ni en ce qui concerne tout prétraitement, car les STARKs ne nécessitent aucune configuration fiable. Pris à l’extrême, même si un proveur fonctionne sur du matériel malveillant par une organisation maléfique, ils ne peuvent pas produire de preuves valables pour de fausses déclarations.

• Verifieur: Le vérifieur s’exécute on-chain, et sa source est disponible.

StarkEx est un moteur de scalabilité pour les exchanges, mais STARK pourrait également être utilisé pour fournir la scalabilité pour d’autres applications. Lorsque vous l’utilisez, une partie de la logique d’application est implémentée off-chain, tandis que les parties de la logique qui interagissent avec les entités on-chain (contrats, comptes, etc.) sont implémentées sous la forme Application Smart Contract (ASC).

La première application à utiliser StarkEx est avec notre partenaire DeversiFi, un exchange self-custodial, qui l’utilisera pour développer ses activités (trading et transferts). L’ASC veille à ce que les fonds des utilisateurs ne puissent pas changer de mains sans leur signature explicite (les signatures sont validées par une preuves STARK). StarkEx oblige les utilisateurs à déposer leurs fonds dans l’ASC, ce qui en fait une cible évidente pour les pirates informatiques. Le code ASC a fait l’objet d’un audit et d’essais approfondis pour en garantir l’exactitude et la sécurité. De plus, nous prévoyons utiliser continuellement d’autres outils, comme la vérification officielle, pour garantir l’exactitude et la sécurité de notre code.

Les audits ne font pas un système sécurisé, car son administrateur peut trivialement «upgrade» vers un nouvel ensemble de smart contract qui rendent le self-custody obsolète. Les mises à jour des smart contracts (ou, alternativement, les migrations) permettent de corriger les bugs et d’étendre les fonctionnalités au fil du temps. Le prochain article de cette série se concentrera sur la façon dont nous avons conçu notre mécanisme d’upgrade des smart contracts pour garantir que StarkEx reste un moteur de scalabilité self-custodial à tout moment.

Une remarque sur le langage : malheureusement, le terme communément utilisé pour « self-custodial» est « non-custodial.» Nous n’aimons pas ce terme, comme il le définit par la négation. Il suggère que les systèmes de conservation (tels que les centralized exchanges) constituent la référence, le point de référence. Mais les solutions custodial vont directement à l’encontre de l’esprit des blockchains permissionless. Ramener custody à soi-même a été le cri de ralliement pour Bitcoin et Ethereum, et c’est pourquoi nous préférons «self-custodial».

~ Tom Brand & Uri Kolodny

Initialement publié en anglais par StarkWare le 3 jun, 2020

StarkEx, un moteur de scalabilité self-custodial, vient d’être lancé sur Ethereum Mainnet (pour plus d’informations sur l’architecture générale du système et les flux). StarkEx implémente le protocole STARK Zero-Knowledge Proof (ZKP). Le chemin vers une solution self-custodial est difficile : les solutions custodial sont plus simples, moins chères et, surtout, bien mieux comprises – le monde construit des custodial software depuis des décennies. Le terme «Self-custodial», ou le synonyme «non-custodial», est utilisé assez libéralement. Ils sont utilisés par des opérateurs qui peuvent, d’un simple clic, assumer la garde complète des fonds de leurs utilisateurs : une situation surprenante, puisque les blockchains permissionless ont été conçues comme une alternative aux systèmes de garde. Nous sommes conscients des défis que pose l’établissement d’un véritable système self-custodial et de l’espace de conception multidimensionnel mis à la disposition des innovateurs dans cet espace. Nous nous rendons également compte que beaucoup trouvent utile de migrer vers une solution de plus en plus self-custodial au fil du temps. Cette série d’articles détaille les choix que nous avons faits, et la direction que nous prévoyons pour StarkEx, à cet égard.

Cet article est le premier d’une série soulignant les efforts que nous avons déployés sur plusieurs fronts pour garantir que StarkEx est, et restera toujours, une solution self-custodial.

Tout d’abord, il vaut la peine de définir ce que «self-custodial» signifie. À notre avis, un système ne peut être qualifié “self-custodial» que s’il satisfait aux caractéristiques suivantes :

1. Les fonds utilisateurs ne peuvent pas changer de mains sans leur signature explicite.

2. Lors de la signature, toutes les informations sont mises à la disposition de l’utilisateur (via le portefeuille UX).

3. Les fonds peuvent toujours être retirés.

4. La logique ci-dessus ne peut pas être altérée en abusant d’un mécanisme de mise à jour de code.

Cet article se concentrera sur les raisons pour lesquelles

• les systèmes de preuve sont spécialement conçus pour prendre en charge les solutions self-custodial

• les audits pour les smart contracts StarkEx. Les articles suivants de cette série décriront

• les mécanismes de mise à niveau des smart contrats que nous avons mis en place

• wallet support (le schéma de signature STARK et l’intégration)

• data availability (allant du comité de disponibilité des données qui soutient notre premier déploiement à la conception d’une solution de disponibilité des données off-chain totalement fiable).

Le Saint Graal self-custodial remonte à la vision originale de la blockchain, incarnée par le dicton «not your keys, not your coins.» Très tôt, en raison des limites de débit du Layer-1, cet idéal self-custodial a été échangé contre la scalabilité et la liquidité qui en découle. Les enfants-phares de ce compromis sont bien sûr des centralized exchanges : ils ont pris la garde des actifs cryptographiques des traders, et leur ont offert de la liquidité en retour (avec un peu de risque de contrepartie). Mais aujourd’hui, la science et l’ingénierie derrière les systèmes ZKP en général, et STARK en particulier, ils ont progressé au point où ils sont prêts pour leur heure de gloire – le compromis ci-dessus n’est plus nécessaire.

Les systèmes ZKP ont une histoire belle et complexe. Remarquablement, pour les blockchains permissionless, les systèmes ZKP sont capables de fournir à la fois la scalabilité et la confidentialité d’une manière trustless. Une solution self-custodial nécessite naturellement une infrastructure trustless. En d’autres termes, toute hypothèse de confiance peut facilement réduire à néant la self-custody, sinon la rendre totalement dénuée de sens.

Les systèmes ZKP sont composés d’une layer de base assurant la Computational Integrity (CI), avec une layer possible au sommet assurant le zero-knowledge. Pour prendre en charge les applications de scalabilité, nous nous appuyons en fait strictement sur la CI layer. La CI permet à une entité (le proveur) de 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 (vérifieur) de vérifier la preuve on-chain avec un effort de calcul minimal.

Idéalement, il y a aussi peu d’hypothèses de confiance que possible. Plus précisément, pour les STARKs :

• Proveur : Il n’y a pas d’hypothèses de confiance dans le Proveur, ni en temps réel ni en ce qui concerne tout prétraitement, car les STARKs ne nécessitent aucune configuration fiable. Pris à l’extrême, même si un proveur fonctionne sur du matériel malveillant par une organisation maléfique, ils ne peuvent pas produire de preuves valables pour de fausses déclarations.

• Verifieur: Le vérifieur s’exécute on-chain, et sa source est disponible.

StarkEx est un moteur de scalabilité pour les exchanges, mais STARK pourrait également être utilisé pour fournir la scalabilité pour d’autres applications. Lorsque vous l’utilisez, une partie de la logique d’application est implémentée off-chain, tandis que les parties de la logique qui interagissent avec les entités on-chain (contrats, comptes, etc.) sont implémentées sous la forme Application Smart Contract (ASC).

La première application à utiliser StarkEx est avec notre partenaire DeversiFi, un exchange self-custodial, qui l’utilisera pour développer ses activités (trading et transferts). L’ASC veille à ce que les fonds des utilisateurs ne puissent pas changer de mains sans leur signature explicite (les signatures sont validées par une preuves STARK). StarkEx oblige les utilisateurs à déposer leurs fonds dans l’ASC, ce qui en fait une cible évidente pour les pirates informatiques. Le code ASC a fait l’objet d’un audit et d’essais approfondis pour en garantir l’exactitude et la sécurité. De plus, nous prévoyons utiliser continuellement d’autres outils, comme la vérification officielle, pour garantir l’exactitude et la sécurité de notre code.

Les audits ne font pas un système sécurisé, car son administrateur peut trivialement «upgrade» vers un nouvel ensemble de smart contract qui rendent le self-custody obsolète. Les mises à jour des smart contracts (ou, alternativement, les migrations) permettent de corriger les bugs et d’étendre les fonctionnalités au fil du temps. Le prochain article de cette série se concentrera sur la façon dont nous avons conçu notre mécanisme d’upgrade des smart contracts pour garantir que StarkEx reste un moteur de scalabilité self-custodial à tout moment.

Une remarque sur le langage : malheureusement, le terme communément utilisé pour « self-custodial» est « non-custodial.» Nous n’aimons pas ce terme, comme il le définit par la négation. Il suggère que les systèmes de conservation (tels que les centralized exchanges) constituent la référence, le point de référence. Mais les solutions custodial vont directement à l’encontre de l’esprit des blockchains permissionless. Ramener custody à soi-même a été le cri de ralliement pour Bitcoin et Ethereum, et c’est pourquoi nous préférons «self-custodial».

~ Tom Brand & Uri Kolodny