Initialement publié en anglais par StarkWare le 29 Jul, 2022

Ceci est notre contribution a The Great Reddit Scaling Bake-off. C’est un Rollup StarkEx (données on-chain).

Cordialement,

StarkWare (@StarkWareLtd)

https://s3.us-west-2.amazonaws.com/secure.notion-static.com/0686f2d8-08b9-46a2-aa14-b88bc0d98203/reddit_bakeoff_deck.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=AKIAT73L2G45EIPT3X45%2F20220419%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-Date=20220419T204050Z&X-Amz-Expires=86400&X-Amz-Signature=b3f2be81bbf3ba1e4ae1f05956c0484e6a8d2f9bcc8a1725b4a46c30680d8578&X-Amz-SignedHeaders=host&response-content-disposition=filename%20%3D%22reddit%2520bakeoff%2520deck.pdf%22&x-id=GetObject

StarkEx - General

• Aperçu du système

• Documentation du produit

StarkEx- The Reddit Bake-off

• Analyse des coûts

• Architecture du système

• Code

La machine StarkEx a des composants on-chain et off-chain. Généralement, les composants off-chain sont utilisés pour le calcul et le stockage important, alors que ceux on-chain sont utilisés pour la vérification computationelle, l’engagement de l’état et la disponibilité des données nécessaire à l’utilisation d’un mécanisme d’évacuation.

Pour obtenir un aperçu plus détaillé, lisez notre post medium. Notez cependant que cet article décrit StarkEx en mode Validium (données off-chain), alors que dans ce bake-off nous avons fait une démonstration de StarkEx en mode Rollup (données on-chain). Note terminologique: Les Rollups utilisant des preuves cryptographiques sont souvent appelés «ZK-Rollups» même quand les preuves ne sont pas Zero-Knowledge (ZK); nous utiliserons ce terme commun pour désigner la classe générale des Rollups basés sur des preuves.

Voir ici

TL;DR

• StarkEx peut fonctionner avec des données on-chain (mode Rollup) ou off-chain (mode Validium).

• Dans ce bake-off, nous avons fonctionné en mode Rollup. Notre coût total sur Mainnet s’élevait à 94,47 M de gas, ce qui correspond à une moyenne de 315 gas/tx. Les coûts off-chain n’en représentaient qu’une petite partie. Il s’agit de coûts réels mesurés sur Mainnet, et non d’estimations optimistes.

• Exécuter le bake-off en mode Validium aurait coûté 5M de gas au total, soit moins de 17 gas/tx. StarkWare dispose déjà d’un système StarkEx en mode Validium déployé sur Mainnet.

• StarkEx surpasse les autres solutions de Rollups

• Il surpasse les ZK-Rollups existants en ce qui concerne les coûts on-chain et off-chain.

• Il surpasse fondamentalement les Optimistic Rollups (OR) en termes de coûts on-chain. Comme le coût est dominé par les coûts on-chain, il présente un avantage de coût fondamental par rapport aux OR.

Il y a deux types de coûts avec le système StarkEx:

1. Coûts on-chain

• Soumettre et vérifier les preuves

• (Uniquement en mode Rollup) Publication des données relative aux changements d’états

1. Coûts off-chain: gestion du service cloud StarkEx, et plus particulièrement des prouveurs

En mode Rollup, la partie on-chain est la partie prédominante du coût. Notez que le coût réel on-chain/tx est beaucoup plus faible dans les solutions ZK-Rollup que dans les solutions OR, car la quantité de données à publier est beaucoup plus faible.

Dans le cas du bake-off, les coûts réels on-chain s’élevaient à 94,47 M (moyenne de 315 gas/tx) et les coûts off-chain étaient négligeables en comparaison (moins de 5% des coûts on-chain).

Avec un coût de 70 gwei, cela nous a coûté 6,6 ETH, ce qui, avec le prix d’un ETH de 230 $, coûtait 1518 $ (coût moyen on-chain de 0,5 ¢ par tx). Naturellement, le prix USD fluctue avec le prix du gas sur Ethereum, et le prix de l’ETH.

94,5% des coûts on-chain étaient imputables au fonctionnement en mode Rollup, c’est-à-dire à l’affichage des données de transaction sur on-chain (section 1. b ci-dessus). Si nous avions fait la même chose en mode Validium, les coûts on-chain n’auraient été que de 5M de gas (moyenne de moins de 17 gas/tx) et auraient coûté 0,35 ETH, soit un total de 80,5 $ (moyenne de 0,02 ¢ par tx).

Résumé des coûts du gas on-chain:

Avec StarkEx, le coût de vérification augmente uniquement de façon poly-logarithmique par rapport à la taille du lot. Ceci est démontré le plus clairement en mode Validium, où les données ne sont pas affichées on-chain, et donc les coûts on-chain augmentent de manière sous-linéaire (logarithmique) avec la taille du lot. Par conséquent, à grande échelle, le coût amorti on-chain d’une seul tx en mode Validium est nul avec la taille du lot, et le coût off-chain prédomine. En termes de coûts off-chain, les STARK présentent un avantage significatif par rapport aux solutions SNARK: les derniers prouveurs STARK sont 20 fois plus rapides que les prouveurs SNARK de pointe et cette accélération est basée sur des raisons¹ cryptographiques fondamentales.

En général, le coût réel dépend de divers facteurs, notamment:

1. Comme indiqué ci-dessus, sur le prix du gas sur Ethereum, et le prix de l’ETH.

2. Le débit du système (nombre de tx/secondes): StarkEx est efficace grâce au batching, car le coût de vérification n’est que logarithmique par rapport a la taille du lot. Plus les lots sont grands, plus le coût par Tx est faible. D’une manière générale, un débit plus élevé se prête à des lots plus importants, et donc un coût moyen par Tx plus faible.

3. La latence maximale permise entre la tx et sa soumission on-chain: plus la latence permise est grande, plus les lots sont grands, et plus le coût par Tx est faible. Une plus grande latence permet également de mieux présenter des preuves temporelles lorsque les coûts du gas sont plus faibles.

4. Solution de disponibilité des données: comme mentionné ci-dessus, le bake-off actuel était en mode Rollup, où la plupart des coûts du système sont la disponibilité des données on-chain. L’exécution en mode Validium aurait réduit le coût on-chain d’un facteur x20.

5. Le nombre d’opérateurs concurrents de preuves off-chain et mécanisme de répartition des preuves entre elles: d’une manière générale, si plusieurs opérateurs produisent des preuves en parallèle et se font concurrence pour les soumettre, les coûts des preuves off-chain augmentent, car ces opérateurs doivent tous être dédommagés de leurs coûts du cloud en continu.

6. La relation d’affaires/accord avec les opérateurs de preuves: si Reddit gère l’opérateur de preuves lui-même, les coûts off-chain ne sont que les coûts d’exploitation du service (y compris les frais de licence/d’utilisation des prouveurs). Si d’autres entités fournissent le service, le coût pourrait être plus élevé.

7. Que les preuves contiennent uniquement des tx Reddit, ou qu’elles soient regroupées avec des Tx provenant d’autres applications : puisque le batching réduit les coûts, le regroupement de tx Reddit avec des tx provenant d’autres applications dans les mêmes épreuves peuvent abaisser le coût moyen par tx.

8. L’optimisations basées sur les schémas d’utilisation: StarkEx contient différentes optimisations au sein de chaque lot (par exemple, le regroupement de différentes Tx liés aux mêmes comptes). Dans certains cas, les schémas d’utilisation de l’application bénéficient davantages de ces optimisations (par exemple, si souvent un lot contient plusieurs Tx pour les mêmes comptes, le coût moyen sera plus faible).

Le coût indiqué ci-dessus pour le bake-off peut fournir une estimation approximative du coût d’un système en direct (encore une fois, en supposant que les données soient disponibles on-chain; sinon, ils seraient fortement inférieurs). Des estimations plus précises pourraient être fournies une fois que nous aurons obtenu des spécifications plus strictes pour la configuration souhaitée du système.

Notez que les coûts cités ci-dessus sont les coûts variables réels pour l’exécution du bake-off sur Mainnet. Nous avons lu diverses publications de solutions scalable concurrentes qui citent des coûts qui ne sont que des estimations et négligent souvent des éléments importants de la structure des coûts réels, car ils n’ont généralement pas encore de produit pleinement fonctionnel. Pour autant que nous le sachions, STARK (comme protocole cryptographique) et StarkEx (notre implémentation spécifique pour ce cas d’utilisation) sont nettement plus efficaces que d’autres systèmes de preuve cryptographique. Par exemple, ethSTARK, notre code open-source financé par EF, est 20 fois plus rapide que tout autre système de preuve que nous connaissons. Cette efficacité se traduit par un avantage de coût par rapport aux autres solutions, lorsque toutes les considérations sont prises en compte.

• Scalabilité: Débit élevé activé par le batching des transactions.

• Intégrité: les preuves cryptographiques et les engagements garantissent la véritable propriété des Points.

• Accessibilité: Soutiens par les principaux wallets, et aucune opération on-chain requise des utilisateurs.

Minting (1)

Le mint s’effectue en transférant des Points des comptes modérateurs aux utilisateurs sélectionnés (selon les spécifications de Reddit, les utilisateurs réclament ces Points). Ceci est fait via l’API Moderator.

Ux - Subscribe, Tip, and Burn (2)

Démarrage des commandes utilisateur

StarkWare a construit une extension Chrome Reddit (RCE) qui surveille l’activité des utilisateurs sur le site Reddit. Le RCE capture des événements tels que Subscribe (en cliquant sur le bouton «JOIN» de sous-réseau), et Tip (en ajoutant une réponse commençant par «/tip»), et les interprète de manière appropriée. Chaque fois que le RCE capture une commande utilisateur, il construit la transaction StarkEx requise, et demande à l’utilisateur de la signer avec son wallet sélectionné. Les transactions signées sont transmises par le RCE au StarkEx Scalability Engine (SESE) dans le cloud. StarkEx regroupe les transactions, génère une preuve STARK attestant de leur intégrité, et écrit la preuve à Ethereum, un engagement à la structure de données des soldes utilisateur mis à jour, et les soldes utilisateur modifiés.

Expérience utilisateur Frictionless

Les utilisateurs se limitant aux interactions de base avec le Point (à savoir: réclamer des Points, s’abonner à un subreddit, aider d’autres utilisateurs, et burn des Points) n’ont pas besoin d’interagir avec Ethereum, et en particulier, aucune inscription on-chain n’est requise. Ce n’est que lorsque les utilisateurs choisissent d’interagir avec Ethereum, par exemple pour retirer ou déposer des Points, qu’ils doivent également s’inscrire on-chain. L’enregistrement on-chain signifie simplement lier l’adresse Ethereum d’un utilisateur avec leur compte StarkEx.

Support du wallet (3)

Intégration native

Plusieurs wallets prennent en charge le schéma de signature StarkEx ECDSA et les API, offrant une sécurité maximale à leurs utilisateurs. Ces wallets présentent en toute sécurité à l’utilisateur les transactions StarkEx dans un format clair et lisible, afin que l’utilisateur sache ce qu’ils signent. Cela garantit que toute tentative d’altération du message (par exemple par un logiciel malveillant) peut être détectée par l’utilisateur avant la signature.

Fourni par: Ledger, Authereum, Portis et Argent (via WalletConnect).

Intégration standard

Là où l’intégration native avec StarkEx n’est pas encore terminée, nous avons opté pour l’intégration standard. Pour le bake-off Reddit, ces wallets servent strictement au stockage sécurisé de la clé privée de l’utilisateur. Lorsqu’il utilise un tel wallet, le RCE signe lui-même le message avec la clé qu’il obtient du wallet

Fourni par: MetaMaks et Thorus

StarkEx Scalability Engine (4)

Le SESE (StarkEx Scalability Engine) fonctionne dans le cloud, et est responsable du batching des transactions, de la génération d’une preuve STARK attestant de leur intégrité et de la mise à jour d’un engagement (un hachage) vers le nouvel état des comptes après ce batch. StarkEx envoie à Ethereum la preuve STARK, aux côtés de l’engagement. Le système de smart contract StarkEx vérifie la preuve, et si elle est acceptée, il stocke l’engagement on-chain. StarkEx accompagne chaque preuve envoyée à Ethereum avec la liste des soldes modifiés vérifiés par la preuve ainsi (aka disponibilité des données on-chain), assurant ainsi le mécanisme anti-censure décrit ci-dessous.

L’explorateur de batch StarkEx (5)

L’explorateur de batch StarkEx se connecte au SESE. Il permet de visualiser les lots créés, ainsi que les transactions de chaque lot. L’explorateur de batch affiche également un format lisible des données de compte modifiées que StarkEx met on-chain, que l’explorateur lit directement à partir de la blockchain. Notez que l’ensemble des transactions affichées nécessite la confiance de l’explorateur, car il ne peut être dérivé de la simple observation de l’engagement et des comptes modifiés enregistrés sur la blockchain.

Mécanisme d’anti-censure

Servir tout le monde ou personne

Dans StarkEx, un utilisateur devrait toujours pouvoir retirer ses Points de la blockchain Ethereum, comme des tokens ERC-20. Dans le flux standard, un utilisateur envoie une demande de retrait au SESE via une API off-chain. Le service API off-chain nécessite une confiance en l’opérateur (par exemple, la disponibilité du système). Si une demande de retrait n’est pas traitée par l’Opérateur, l’utilisateur soumet une demande de retrait complète (considérez-la comme l’équivalent de dépot de plainte auprès d’une partie trustless) au Smart contract StarkEx-Reddit. Ceci déclenche un délai de grâce pendant lequel l’Opérateur peut soumettre une preuve signifiant la demande de rétractation. Si cela se produit, le système retourne à son fonctionnement normal. Sinon, le smart contract gèle le système StarkEx en refusant de traiter d’autres mises à jour.

Retirer des points d’un StarkEx gelé

Lorsque le système est gelé, les utilisateurs peuvent réclamer leurs points et les retirer on-chain, en démontrant au smart-contract qu’ils sont bien propriétaires des actifs réclamés. L’engagement stocké on-chain est en fait un engagement d’arbre de Merkle pour les soldes de l’utilisateur. Un utilisateur peut retirer des fonds directement du contrat en fournissant un chemin d’authentification Merkle depuis son compte (une feuille dans l’arborescence) jusqu’à la racine (l’engagement maintenu on-chain). La disponibilité des données on-chain envoyée avec chaque lot traité contient les informations nécessaires pour permettre à l’utilisateur de construire de tels chemins d’authentification (les données sont diffusées uniquement à cette fin).

Contrat du serveur:

https://etherscan.io/address/0x7737d2afcd437a07dc8d58792344e76b4f8e93b6#code

Contrat de l’implémentation:

https://etherscan.io/address/0x4126cf347cd0d3aa900041756329de4c319933b0#code

¹ Brièvement, les SNARKs nécessitent une cryptographie numérique lourde, alors que les STARKs utilisent une cryptographie symétrique sans danger post-quantique. Voir cet article pour une étude plus détaillée et une comparaison des systèmes de preuve déployés.

Traduction faite par @Theyozz

Initialement publié en anglais par StarkWare le 29 Jul, 2022

Ceci est notre contribution a The Great Reddit Scaling Bake-off. C’est un Rollup StarkEx (données on-chain).

Cordialement,

StarkWare (@StarkWareLtd)

https://s3.us-west-2.amazonaws.com/secure.notion-static.com/0686f2d8-08b9-46a2-aa14-b88bc0d98203/reddit_bakeoff_deck.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=AKIAT73L2G45EIPT3X45%2F20220419%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-Date=20220419T204050Z&X-Amz-Expires=86400&X-Amz-Signature=b3f2be81bbf3ba1e4ae1f05956c0484e6a8d2f9bcc8a1725b4a46c30680d8578&X-Amz-SignedHeaders=host&response-content-disposition=filename%20%3D%22reddit%2520bakeoff%2520deck.pdf%22&x-id=GetObject

StarkEx - General

• Aperçu du système

• Documentation du produit

StarkEx- The Reddit Bake-off

• Analyse des coûts

• Architecture du système

• Code

La machine StarkEx a des composants on-chain et off-chain. Généralement, les composants off-chain sont utilisés pour le calcul et le stockage important, alors que ceux on-chain sont utilisés pour la vérification computationelle, l’engagement de l’état et la disponibilité des données nécessaire à l’utilisation d’un mécanisme d’évacuation.

Pour obtenir un aperçu plus détaillé, lisez notre post medium. Notez cependant que cet article décrit StarkEx en mode Validium (données off-chain), alors que dans ce bake-off nous avons fait une démonstration de StarkEx en mode Rollup (données on-chain). Note terminologique: Les Rollups utilisant des preuves cryptographiques sont souvent appelés «ZK-Rollups» même quand les preuves ne sont pas Zero-Knowledge (ZK); nous utiliserons ce terme commun pour désigner la classe générale des Rollups basés sur des preuves.

Voir ici

TL;DR

• StarkEx peut fonctionner avec des données on-chain (mode Rollup) ou off-chain (mode Validium).

• Dans ce bake-off, nous avons fonctionné en mode Rollup. Notre coût total sur Mainnet s’élevait à 94,47 M de gas, ce qui correspond à une moyenne de 315 gas/tx. Les coûts off-chain n’en représentaient qu’une petite partie. Il s’agit de coûts réels mesurés sur Mainnet, et non d’estimations optimistes.

• Exécuter le bake-off en mode Validium aurait coûté 5M de gas au total, soit moins de 17 gas/tx. StarkWare dispose déjà d’un système StarkEx en mode Validium déployé sur Mainnet.

• StarkEx surpasse les autres solutions de Rollups

• Il surpasse les ZK-Rollups existants en ce qui concerne les coûts on-chain et off-chain.

• Il surpasse fondamentalement les Optimistic Rollups (OR) en termes de coûts on-chain. Comme le coût est dominé par les coûts on-chain, il présente un avantage de coût fondamental par rapport aux OR.

Il y a deux types de coûts avec le système StarkEx:

1. Coûts on-chain

• Soumettre et vérifier les preuves

• (Uniquement en mode Rollup) Publication des données relative aux changements d’états

1. Coûts off-chain: gestion du service cloud StarkEx, et plus particulièrement des prouveurs

En mode Rollup, la partie on-chain est la partie prédominante du coût. Notez que le coût réel on-chain/tx est beaucoup plus faible dans les solutions ZK-Rollup que dans les solutions OR, car la quantité de données à publier est beaucoup plus faible.

Dans le cas du bake-off, les coûts réels on-chain s’élevaient à 94,47 M (moyenne de 315 gas/tx) et les coûts off-chain étaient négligeables en comparaison (moins de 5% des coûts on-chain).

Avec un coût de 70 gwei, cela nous a coûté 6,6 ETH, ce qui, avec le prix d’un ETH de 230 $, coûtait 1518 $ (coût moyen on-chain de 0,5 ¢ par tx). Naturellement, le prix USD fluctue avec le prix du gas sur Ethereum, et le prix de l’ETH.

94,5% des coûts on-chain étaient imputables au fonctionnement en mode Rollup, c’est-à-dire à l’affichage des données de transaction sur on-chain (section 1. b ci-dessus). Si nous avions fait la même chose en mode Validium, les coûts on-chain n’auraient été que de 5M de gas (moyenne de moins de 17 gas/tx) et auraient coûté 0,35 ETH, soit un total de 80,5 $ (moyenne de 0,02 ¢ par tx).

Résumé des coûts du gas on-chain:

Avec StarkEx, le coût de vérification augmente uniquement de façon poly-logarithmique par rapport à la taille du lot. Ceci est démontré le plus clairement en mode Validium, où les données ne sont pas affichées on-chain, et donc les coûts on-chain augmentent de manière sous-linéaire (logarithmique) avec la taille du lot. Par conséquent, à grande échelle, le coût amorti on-chain d’une seul tx en mode Validium est nul avec la taille du lot, et le coût off-chain prédomine. En termes de coûts off-chain, les STARK présentent un avantage significatif par rapport aux solutions SNARK: les derniers prouveurs STARK sont 20 fois plus rapides que les prouveurs SNARK de pointe et cette accélération est basée sur des raisons¹ cryptographiques fondamentales.

En général, le coût réel dépend de divers facteurs, notamment:

1. Comme indiqué ci-dessus, sur le prix du gas sur Ethereum, et le prix de l’ETH.

2. Le débit du système (nombre de tx/secondes): StarkEx est efficace grâce au batching, car le coût de vérification n’est que logarithmique par rapport a la taille du lot. Plus les lots sont grands, plus le coût par Tx est faible. D’une manière générale, un débit plus élevé se prête à des lots plus importants, et donc un coût moyen par Tx plus faible.

3. La latence maximale permise entre la tx et sa soumission on-chain: plus la latence permise est grande, plus les lots sont grands, et plus le coût par Tx est faible. Une plus grande latence permet également de mieux présenter des preuves temporelles lorsque les coûts du gas sont plus faibles.

4. Solution de disponibilité des données: comme mentionné ci-dessus, le bake-off actuel était en mode Rollup, où la plupart des coûts du système sont la disponibilité des données on-chain. L’exécution en mode Validium aurait réduit le coût on-chain d’un facteur x20.

5. Le nombre d’opérateurs concurrents de preuves off-chain et mécanisme de répartition des preuves entre elles: d’une manière générale, si plusieurs opérateurs produisent des preuves en parallèle et se font concurrence pour les soumettre, les coûts des preuves off-chain augmentent, car ces opérateurs doivent tous être dédommagés de leurs coûts du cloud en continu.

6. La relation d’affaires/accord avec les opérateurs de preuves: si Reddit gère l’opérateur de preuves lui-même, les coûts off-chain ne sont que les coûts d’exploitation du service (y compris les frais de licence/d’utilisation des prouveurs). Si d’autres entités fournissent le service, le coût pourrait être plus élevé.

7. Que les preuves contiennent uniquement des tx Reddit, ou qu’elles soient regroupées avec des Tx provenant d’autres applications : puisque le batching réduit les coûts, le regroupement de tx Reddit avec des tx provenant d’autres applications dans les mêmes épreuves peuvent abaisser le coût moyen par tx.

8. L’optimisations basées sur les schémas d’utilisation: StarkEx contient différentes optimisations au sein de chaque lot (par exemple, le regroupement de différentes Tx liés aux mêmes comptes). Dans certains cas, les schémas d’utilisation de l’application bénéficient davantages de ces optimisations (par exemple, si souvent un lot contient plusieurs Tx pour les mêmes comptes, le coût moyen sera plus faible).

Le coût indiqué ci-dessus pour le bake-off peut fournir une estimation approximative du coût d’un système en direct (encore une fois, en supposant que les données soient disponibles on-chain; sinon, ils seraient fortement inférieurs). Des estimations plus précises pourraient être fournies une fois que nous aurons obtenu des spécifications plus strictes pour la configuration souhaitée du système.

Notez que les coûts cités ci-dessus sont les coûts variables réels pour l’exécution du bake-off sur Mainnet. Nous avons lu diverses publications de solutions scalable concurrentes qui citent des coûts qui ne sont que des estimations et négligent souvent des éléments importants de la structure des coûts réels, car ils n’ont généralement pas encore de produit pleinement fonctionnel. Pour autant que nous le sachions, STARK (comme protocole cryptographique) et StarkEx (notre implémentation spécifique pour ce cas d’utilisation) sont nettement plus efficaces que d’autres systèmes de preuve cryptographique. Par exemple, ethSTARK, notre code open-source financé par EF, est 20 fois plus rapide que tout autre système de preuve que nous connaissons. Cette efficacité se traduit par un avantage de coût par rapport aux autres solutions, lorsque toutes les considérations sont prises en compte.

• Scalabilité: Débit élevé activé par le batching des transactions.

• Intégrité: les preuves cryptographiques et les engagements garantissent la véritable propriété des Points.

• Accessibilité: Soutiens par les principaux wallets, et aucune opération on-chain requise des utilisateurs.

Minting (1)

Le mint s’effectue en transférant des Points des comptes modérateurs aux utilisateurs sélectionnés (selon les spécifications de Reddit, les utilisateurs réclament ces Points). Ceci est fait via l’API Moderator.

Ux - Subscribe, Tip, and Burn (2)

Démarrage des commandes utilisateur

StarkWare a construit une extension Chrome Reddit (RCE) qui surveille l’activité des utilisateurs sur le site Reddit. Le RCE capture des événements tels que Subscribe (en cliquant sur le bouton «JOIN» de sous-réseau), et Tip (en ajoutant une réponse commençant par «/tip»), et les interprète de manière appropriée. Chaque fois que le RCE capture une commande utilisateur, il construit la transaction StarkEx requise, et demande à l’utilisateur de la signer avec son wallet sélectionné. Les transactions signées sont transmises par le RCE au StarkEx Scalability Engine (SESE) dans le cloud. StarkEx regroupe les transactions, génère une preuve STARK attestant de leur intégrité, et écrit la preuve à Ethereum, un engagement à la structure de données des soldes utilisateur mis à jour, et les soldes utilisateur modifiés.

Expérience utilisateur Frictionless

Les utilisateurs se limitant aux interactions de base avec le Point (à savoir: réclamer des Points, s’abonner à un subreddit, aider d’autres utilisateurs, et burn des Points) n’ont pas besoin d’interagir avec Ethereum, et en particulier, aucune inscription on-chain n’est requise. Ce n’est que lorsque les utilisateurs choisissent d’interagir avec Ethereum, par exemple pour retirer ou déposer des Points, qu’ils doivent également s’inscrire on-chain. L’enregistrement on-chain signifie simplement lier l’adresse Ethereum d’un utilisateur avec leur compte StarkEx.

Support du wallet (3)

Intégration native

Plusieurs wallets prennent en charge le schéma de signature StarkEx ECDSA et les API, offrant une sécurité maximale à leurs utilisateurs. Ces wallets présentent en toute sécurité à l’utilisateur les transactions StarkEx dans un format clair et lisible, afin que l’utilisateur sache ce qu’ils signent. Cela garantit que toute tentative d’altération du message (par exemple par un logiciel malveillant) peut être détectée par l’utilisateur avant la signature.

Fourni par: Ledger, Authereum, Portis et Argent (via WalletConnect).

Intégration standard

Là où l’intégration native avec StarkEx n’est pas encore terminée, nous avons opté pour l’intégration standard. Pour le bake-off Reddit, ces wallets servent strictement au stockage sécurisé de la clé privée de l’utilisateur. Lorsqu’il utilise un tel wallet, le RCE signe lui-même le message avec la clé qu’il obtient du wallet

Fourni par: MetaMaks et Thorus

StarkEx Scalability Engine (4)

Le SESE (StarkEx Scalability Engine) fonctionne dans le cloud, et est responsable du batching des transactions, de la génération d’une preuve STARK attestant de leur intégrité et de la mise à jour d’un engagement (un hachage) vers le nouvel état des comptes après ce batch. StarkEx envoie à Ethereum la preuve STARK, aux côtés de l’engagement. Le système de smart contract StarkEx vérifie la preuve, et si elle est acceptée, il stocke l’engagement on-chain. StarkEx accompagne chaque preuve envoyée à Ethereum avec la liste des soldes modifiés vérifiés par la preuve ainsi (aka disponibilité des données on-chain), assurant ainsi le mécanisme anti-censure décrit ci-dessous.

L’explorateur de batch StarkEx (5)

L’explorateur de batch StarkEx se connecte au SESE. Il permet de visualiser les lots créés, ainsi que les transactions de chaque lot. L’explorateur de batch affiche également un format lisible des données de compte modifiées que StarkEx met on-chain, que l’explorateur lit directement à partir de la blockchain. Notez que l’ensemble des transactions affichées nécessite la confiance de l’explorateur, car il ne peut être dérivé de la simple observation de l’engagement et des comptes modifiés enregistrés sur la blockchain.

Mécanisme d’anti-censure

Servir tout le monde ou personne

Dans StarkEx, un utilisateur devrait toujours pouvoir retirer ses Points de la blockchain Ethereum, comme des tokens ERC-20. Dans le flux standard, un utilisateur envoie une demande de retrait au SESE via une API off-chain. Le service API off-chain nécessite une confiance en l’opérateur (par exemple, la disponibilité du système). Si une demande de retrait n’est pas traitée par l’Opérateur, l’utilisateur soumet une demande de retrait complète (considérez-la comme l’équivalent de dépot de plainte auprès d’une partie trustless) au Smart contract StarkEx-Reddit. Ceci déclenche un délai de grâce pendant lequel l’Opérateur peut soumettre une preuve signifiant la demande de rétractation. Si cela se produit, le système retourne à son fonctionnement normal. Sinon, le smart contract gèle le système StarkEx en refusant de traiter d’autres mises à jour.

Retirer des points d’un StarkEx gelé

Lorsque le système est gelé, les utilisateurs peuvent réclamer leurs points et les retirer on-chain, en démontrant au smart-contract qu’ils sont bien propriétaires des actifs réclamés. L’engagement stocké on-chain est en fait un engagement d’arbre de Merkle pour les soldes de l’utilisateur. Un utilisateur peut retirer des fonds directement du contrat en fournissant un chemin d’authentification Merkle depuis son compte (une feuille dans l’arborescence) jusqu’à la racine (l’engagement maintenu on-chain). La disponibilité des données on-chain envoyée avec chaque lot traité contient les informations nécessaires pour permettre à l’utilisateur de construire de tels chemins d’authentification (les données sont diffusées uniquement à cette fin).

Contrat du serveur:

https://etherscan.io/address/0x7737d2afcd437a07dc8d58792344e76b4f8e93b6#code

Contrat de l’implémentation:

https://etherscan.io/address/0x4126cf347cd0d3aa900041756329de4c319933b0#code

¹ Brièvement, les SNARKs nécessitent une cryptographie numérique lourde, alors que les STARKs utilisent une cryptographie symétrique sans danger post-quantique. Voir cet article pour une étude plus détaillée et une comparaison des systèmes de preuve déployés.

Traduction faite par @Theyozz