L’architecture du réseau Oasis : Conçue pour évoluer

Avertissement : cette publication est une traduction communautaire réalisée par un membre de la communauté du réseau Oasis. Des contrôles rigoureux sont effectués pour fournir des traductions exactes, mais elles peuvent être sujettes à des erreurs ou à des omissions. Oasis Network n’est pas responsable de l’exactitude, de la fiabilité ou de l’actualité des informations traduites. Publication originale en anglais : Oasis Network Architecture: Designed for Scaling

La seule blockchain avec un support natif pour les rollups au niveau de la couche de consensus.

Les solutions de mise à l’échelle de couche 2 ont évolué, passant des “sidechains”, aux “commitchains”, aux “rollups” et aux passerelles de validation. Le “rollup” fait référence à l’exécution d’une machine virtuelle (VM) de contrat intelligent où l’état de la VM est périodiquement vérifié et engagé sur une blockchain sous-jacente pour fournir la fonctionnalité de contrat intelligent à un coût réduit et à un débit plus élevé, par opposition à l’exécution de contrats intelligents directement sur la blockchain sous-jacente. La vérification effectuée sur la blockchain sous-jacente sécurise les transitions d’état, et le calcul hors chaîne permet de faire évoluer l’exécution des contrats intelligents.

Nous ne les avons pas appelés rollups, mais c’est ainsi que fonctionnent les ParaTimes ou la couche de traitement d’Oasis Network.

Dès sa création, le réseau Oasis a séparé le calcul du consensus comme principe de conception modulaire. Cette séparation signifie que les entités de la couche ParaTime ne gèrent que l’exécution des contrats intelligents, et que les entités de la couche consensuelle ne gèrent que le consensus. et les deux sont grandement simplifiés. Cela présente de nombreux avantages, notamment la facilité d’audit, l’isolation des pannes et la réduction de la réplication des calculs sans sacrifier la sécurité. La séparation, le calcul effectué dans une machine virtuelle (rollup) et les résultats vérifiés et enregistrés dans une blockchain, constitue exactement la raison d’être des rollups.

Le réseau Oasis n’est pas seulement un réseau qui supporte nativement les rollups, l’architecture est optimisée pour les rollups et seulement pour les rollups : il dissuade de placer des traitements de manière générale dans la couche de consensus, et permet uniquement aux contrats intégrés de s’y exécuter. Ces contrats intégrés sont les contrats passerelles de validation dans le jargon des rollups. Alors que les objectifs de la conception de l’architecture d’Oasis étaient une blockchain modulaire de couche 1 qui supporte les contrats intelligents, on pourrait dire que le résultat de la modularité est que la couche de consensus d’Oasis est une blockchain qui ne supporte que les rollups, puisque vu à travers la perspective du rollup, tous les ParaTimes sont des machines virtuelles de rollup de couche 2.

En particulier, la passerelle de validation d’Oasis dans la couche de consensus utilise une technique de preuve de fraude appelée “détection de divergence” pour valider les résultats de la couche de calcul. Cette technique, issue de la co-conception de la détection des fraudes et de l’architecture du système, utilise des “bare metal proofs” qui sont simples et donc plus fiables, car il y a moins de risques d’erreur. Comme nous le verrons, la simplicité des preuves “bare metal” donne également aux concepteurs de ParaTime une plus grande marge de manœuvre : la mise en œuvre d’un environnement d’exécution de contrats intelligents dans lequel les contrats intelligents sont du code natif “sandbox” devient possible, ce qui donne au système une marge de manœuvre pour améliorer les performances au-delà de celles de l’exécution concurrente de ParaTime.

On pourrait également dire que le réseau Oasis est le premier réseau qui supporte nativement les rollups. Et que la nomenclature “Couche 1”/”Couche 2" est trop peu descriptive/précise.

C’est ce qu’on appelle la modélisation convergente. Décortiquons ce que cela signifie et entrons dans les détails.

Propriétés des rollups

Les rollups ont principalement été conçus pour accélérer le traitement des smart contracts Ethereum. Plus précisément, ils ont été conçus pour exécuter des contrats intelligents Ethereum, mais dans une machine virtuelle séparée et indépendante, distincte de la machine virtuelle Ethereum (EVM) sur la “chaîne de base” de la couche 1 d’Ethereum, afin de réduire la charge de travail de la couche 1. Toute l’exécution du contrat réel est effectuée dans la machine virtuelle de la couche 2. Le seul travail effectué par la blockchain sous-jacente consiste à valider l’exécution de la machine virtuelle du rollup à l’aide d’un contrat intelligent “passerelle de validation”. Normalement, la machine virtuelle rollup est également une instance de l’EVM, et dans certains modèles, par exemple Arbitrum, la machine virtuelle rollup est modifiée pour faciliter la validation dans la chaîne de base. Tant que la vérification de la validation dans la couche 1 est moins chère que l’exécution des smart contracts du rollup directement dans la couche 1, nous avons un gain d’efficacité puisque l’exécution de la machine de la couche 2 est censée être moins coûteuse. C’est le principe de la manière dont les rollups permettent de mettre à l’échelle le débit des transactions.

Notez qu’au-dessus de la blockchain de couche 1, il pourrait y avoir de nombreuses machines virtuelles de couche 2. Il n’y a pas de limites architecturales autres que le débit de validation de la couche 1. Plus le contrat de la passerelle de validation est efficace et moins la charge d’exécution des contrats intelligents non-passerelle est importante pour la blockchain de couche 1, plus le nombre de rollups pris en charge est élevé. Évidemment, un contrat de type passerelle de validation pourrait également être exécuté à l’intérieur du rollup, mais il existe des limites à cette récursion que nous n’aborderons pas ici.

La plupart des conceptions de rollup engagent d’abord les données de transaction dans la chaîne de base, puis engagent plus tard l’état résultant de la machine virtuelle rollup dans une transaction ultérieure. Cela permet d’assurer la finalité de l’ordre des transactions et, d’une certaine manière, de résoudre le problème de disponibilité des données puisque l’état de la machine virtuelle du rollup peut être reconstruit à partir des données de la transaction au prix de la réexécution de toutes les transactions depuis l’état de genèse de la machine virtuelle du rollup. Les passerelles de validation peuvent être plus générales, avec un stockage d’état hors chaîne qui est vérifiable à l’aide de preuves Merkle, de sorte qu’une solution distincte pour la disponibilité des données est possible, par exemple, les données de transaction peuvent être résumées par cryptographie de la même manière que l’état de la machine virtuelle, ce qui réduit les coûts de stockage de la couche 1 et sépare la disponibilité, assurée par le stockage hors chaîne, de l’authenticité des données. Il y a là un compromis avec la validation : un problème temporaire de débit de disponibilité des données — parce que l’accès aux données d’entrée nécessaires à la vérification peut être lent — pourrait retarder la validation.

La façon dont les rollups effectuent la validation de la machine virtuelle se présente sous deux formes :

• Les rollups optimistes, où un résultat d’exécution revendiqué est affiché publiquement et potentiellement contesté.
• Les rollups zk, où les SNARKs sont utilisés pour construire une preuve d’exactitude.

La différence essentielle est que les rollups optimistes utilisent des “preuves de fraude” où les challengers rassemblent des preuves pour prouver que le résultat d’exécution revendiqué est incorrect ou frauduleux, et les rollups zk utilisent une “preuve de validité” que les exécuteurs publient avec l’état de la machine virtuelle du rollup, et le contrat intelligent de la passerelle de validation vérifiant l’exactitude de la preuve. Dans les deux cas, un délai est nécessaire pour permettre aux autres participants de voir le nouvel état et de découvrir que l’état est incorrect et de construire une preuve de fraude, dans le cas des rollups optimistes, ou d’exécuter un algorithme de vérification de la preuve pour rejeter une prétendue preuve lorsqu’elle est incorrecte, dans le cas d’un rollup zk. Bien que la distinction puisse sembler mineure, dans les deux cas, il faut travailler soit pour construire une preuve de fraude, soit pour vérifier si la preuve de validité est correcte. La différence réside dans le fait que les preuves de fraude impliquent généralement la réexécution des transactions, alors que la vérification de la preuve de validité est censée être moins coûteuse, grâce à des techniques cryptographiques (preuves vérifiables de manière probabiliste ; SNARKs). En pratique, les techniques cryptographiques impliquent une surcharge importante et ne sont pas (encore) généralisées à l’exécution de contrats intelligents arbitraires.

Notez que, en général, la machine virtuelle du rollup n’a pas besoin d’être compatible avec Ethereum, et le mécanisme de validation n’a pas besoin de fonctionner au-dessus d’Ethereum. Tout substrat de calcul décentralisé peut faire l’affaire, en étendant sa sécurité à celle de la machine virtuelle du rollup. Bien sûr, le fait que la machine virtuelle du rollup soit compatible avec Ethereum rend trivial le portage du code EVM existant.

Les différents types de preuves de fraude

Pour comprendre pourquoi la co-conception de la détection de fraude et de l’architecture du système du réseau Oasis a abouti à un système plus efficace et plus général, nous devons d’abord discuter des différents types de preuves de fraude.

Preuves de simulation

La façon dont les systèmes de rollup optimistes comme Arbitrum et Optimism fonctionnent est que les challengers qui prétendent qu’un calcul est faux doivent soumettre une preuve de fraude. La preuve de fraude est censée montrer que le calcul qui a conduit à l’état résultant incorrect a divergé d’une exécution correcte de la machine virtuelle dans une seule instruction de la VM, ce qui peut être “facilement” vérifié en utilisant un simulateur de machine virtuelle rollup fonctionnant sur la chaîne de base.

Ce n’est pas facile. C’est extrêmement complexe. Cela couple fortement le jeu d’instructions de la machine virtuelle du rollup avec la mise en œuvre du contrat de la passerelle de validation. La clé pour pouvoir vérifier l’exécution est de ne pas simuler l’exécution complète de la machine virtuelle rollup, car cela serait extrêmement coûteux en frais de gaz. Au lieu de cela, le challenger est censé fournir une preuve irréfutable que l’affirmation de l’exécuteur de l’état de sortie de la VM rollup en indiquant l’instruction exacte de la VM qui n’a pas été exécutée correctement, en utilisant la bissection pour comparer les états d’exécution et les preuves de Merkle. La construction de la preuve peut être effectuée hors ligne, et seule la vérification doit être effectuée en ligne, par le contrat de la passerelle de validation — en vérifiant qu’effectivement l’exécution de l’instruction VM indiquée n’a pas respecté la sémantique VM.

Pour que cela fonctionne, le contrat passerelle de validation doit être capable de simuler n’importe quelle instruction de la VM rollup. Garantir que le simulateur est correct et qu’il est sémantiquement équivalent à la VM rollup réelle est techniquement difficile. Bien que la complexité d’un simulateur dépende de la complexité du jeu d’instructions de la VM, il est probable qu’il faille de nombreuses années d’efforts pour construire un simulateur précis et robuste, comme c’est le cas pour Arbitrum et Optimism.

Un challenger qui revendique la fraude est censé soumettre une preuve de fraude avec une nouvelle revendication pour l’état de résultat correct. Si la trace d’exécution frauduleuse F diverge de la trace d’exécution correcte à un moment t_0, un contestataire pourrait construire une trace d’exécution C qui diverge de la trace correcte à un pas de temps ultérieur t_1> t_0 et soumettre une preuve de fraude qui réussirait à renverser F, mais qui est elle-même un résultat frauduleux. Ainsi, une preuve de fraude contre F ne prouve pas que C est correct, et une contestation réussie avec un résultat différent devrait remettre à zéro l’horloge de soumission de la contestation afin que C puisse être lui-même contesté. La contestation réussie n’est pas une preuve que le résultat associé à C est correct sans vérification supplémentaire par d’autres vérificateurs.

Un avantage des preuves de simulation est qu’elles sont précises, et en supposant que tout fonctionne, nous sommes sûrs quand un résultat est incorrect parce que nous savons où la sémantique VM a été violée. Notez cependant que la passerelle de validation est un contrat intelligent s’exécutant sur une blockchain, et que l’exactitude de son résultat n’est que probabiliste, que le consensus sur son exécution se produise sur une chaîne PoW ou PoS. (Dans le premier cas, probabilité qu’une attaque réussie de 50%+ε se produise ; dans le second cas, probabilité que ⅔ de la mise totale passe sous le contrôle d’acteurs byzantins. Dans les deux cas, il y a également la probabilité d’une défaillance en mode commun, comme une vulnérabilité de type zero-day dans le code de la blockchain sous-jacente ou le système d’exploitation hôte permettant des défaillances généralisées). Comme la vérification de la preuve de la fraude est probabiliste, l’avantage d’avoir une preuve déterministe est plus théorique que réel.

Preuves en métal à nu (Bare Metal Proofs)

Qu’entendons-nous par “preuves en métal à nu” ? Un schéma de preuve bare metal :

• Doit être robuste. Les preuves peuvent être de nature probabiliste (comme les ZKP), avec la possibilité de choisir des paramètres de sécurité pour que la probabilité d’erreur soit aussi proche de zéro que nécessaire.
• Il devrait fonctionner avec n’importe quelle machine virtuelle (déterministe) sans adaptations spécifiques à la machine, y compris les machines virtuelles qui sont de simples extensions d’architectures à jeu d’instructions courantes telles que x86–64. Le schéma doit permettre l’exécution de binaires de code natif sandboxés (avec des restrictions pour éviter un comportement non déterministe) à pleine vitesse, “bare metal”, avec des extensions d’instructions de blockchain comme appels de fonction.

En particulier, ces exigences signifient qu’un système basé sur des preuves de fraude en métal nu sera beaucoup plus simple que ceux basés sur des preuves de simulation. Le contrat de la passerelle de validation n’a pas besoin d’accéder à l’état de la machine virtuelle du rollup, car la vérification de l’état nécessite de connaître le type de structures de données Merklized utilisées et la façon de les vérifier, ce qui est spécifique à la VM du rollup : cela introduirait la nécessité d’interfaces/mécanismes pour la blockchain sous-jacente pour avoir accès à l’état du rollup et rendrait les interfaces du module plus complexes. En outre, aucune simulation au niveau des instructions spécifiques à la VM n’est nécessaire. Éviter la complexité (inutile) est un objectif de sécurité important, car la complexité engendre des bogues.

Il est intéressant de noter qu’en exigeant que le schéma de preuve de fraude soit plus général, il relâche également les contraintes sur la conception de la machine virtuelle rollup. Bien que nous puissions continuer à écrire des contrats intelligents dans un langage qui se compile en bytecode et à utiliser des interpréteurs de bytecode comme machine virtuelle (ce qui facilite l’étape unique et la collecte d’une trace d’exécution Merklized), nous ne sommes plus contraints à cette approche. Des techniques plus avancées et plus efficaces peuvent être appliquées, de sorte qu’il existe une énorme marge de manœuvre pour améliorer l’efficacité des contrats intelligents. Par exemple, les instructions/bytecodes des machines virtuelles peuvent être compilées en code machine pour être exécutés dans une sandbox d’isolation des fautes logicielles (SFI) telle que RLBox, ce qui permet d’obtenir des performances proches du code natif.

Oasis ParaTimes

Dans le cas d’Oasis, la séparation de l’exécution des contrats intelligents et du consensus a fait que nous nous sommes retrouvés avec une conception de type rollup. Il existe un ParaTime compatible EVM, le ParaTime Emerald, parmi d’autres qui exécutent des contrats intelligents basés sur Rust, qui utilisent tous un contrat intelligent de validation unique, intégré, orienté objet. Aucune autre blockchain ne limite la chaîne de base à l’exécution de contrats de validation de type rollup.

Détection de divergences et preuves de fraude

Nous avons mentionné précédemment qu’Oasis n’exécute que des contrats de validation intégrés dans la couche de consensus. Actuellement, il s’agit d’une passerelle de validation de type “bare metal”, à l’épreuve de la fraude, où nous utilisons une technique appelée “détection des divergences” pour détecter la fraude et, si elle est détectée, “résolution des divergences” pour la résoudre. L’idée clé derrière la “détection des divergences” est que nous pouvons être plus efficaces pour détecter la fraude que pour la corriger, de la même manière que des bits redondants supplémentaires dans la théorie du codage peuvent être utilisés pour détecter plus d’erreurs qu’ils ne peuvent en corriger. Sous l’hypothèse qu’ils présentent une indépendance de défaillance, un adversaire compromettant un nœud d’exécution ne l’aide pas à en compromettre d’autres, par exemple en soudoyant le personnel opérationnel, en devinant leurs mots de passe, etc., nous pouvons utiliser des comités de calcul plus petits où nous exigeons que tous arrivent au même résultat d’exécution du contrat intelligent.

La sécurité pratique de cette conception est plus facile à comprendre. Une conception basée sur un comité fournit un paramètre de sécurité publiquement connu, la taille du comité, qui exécute les contrats de manière semi-synchronisée de sorte que les utilisateurs connaissent à la fois le nombre de contre-vérifications et savent quand les contre-vérifications seront terminées, les membres du comité ont un SLA et pourraient être réduits par manque de disponibilité. Cela contraste avec les rollups optimistes, où l’utilisateur attend un temps fixe pour un nombre inconnu de challengers potentiels ou vérifie lui-même les calculs. Notez que la conception n’empêche pas les non-membres du comité de soumettre des preuves de fraude, et même les preuves de fraude “tardives” provenant de non-membres du comité peuvent être traitées, voir la section “checkpointing” dans cet article ci-dessous, de sorte que la validation n’est pas fermée.

Lorsqu’une divergence se produit, une phase de résolution/récupération des divergences est exécutée. Pour les résultats du comité semi-synchrone, nous lançons immédiatement un comité plus large pour déterminer quel est le résultat correct. La taille de ce comité de résolution est beaucoup plus grande — la résolution pourrait être exécutée par l’ensemble du comité de consensus, par exemple — de sorte qu’il y aura une confiance dans ce résultat. Bien que cela soit plus coûteux en termes de calcul répliqué et de communications, ce n’est pas grave : cela devrait être extrêmement rare, et le coût est amorti sur la grande majorité des cas où la résolution n’est pas nécessaire.

Le gain d’efficacité est dû à l’application d’une optimisation de chemin rapide/chemin lent, courante dans la conception de systèmes. Le cas probable d’absence de fraude/de divergence est traité efficacement, et le cas improbable de devoir déterminer lequel de deux résultats divergents ou plus est correct peut être plus lent. Voir ici pour plus de détails sur les paramètres de sécurité.

La couche de consensus du réseau Oasis n’exécute pas de contrats intelligents généraux. Au lieu de cela, nous intégrons la fonctionnalité de passerelle de validation qui est autrement instanciée comme un contrat intelligent dans un rollup basé sur Ethereum. Nous utilisons la détection des divergences pour valider les résultats des nœuds de la couche de calcul (ParaTime), car elle est à la fois plus efficace et plus générale.

Pour comprendre pourquoi la détection des divergences est plus efficace, considérons la durée prévue avant qu’une sélection aléatoire des membres du comité de calcul puisse permettre à un adversaire de compromettre le calcul. Si, sur un total de 100 candidats, 33 au maximum sont byzantins et que nous choisissons aléatoirement 20 d’entre eux pour servir de comité de calcul, même si de nouvelles compositions de comité étaient sélectionnées à un rythme de 100 000 par heure, l’adversaire contrôlant ces 33 nœuds byzantins devrait attendre 1 066 ans avant qu’un comité entièrement byzantin soit choisi et puisse être utilisé pour attaquer le système. Un schéma de tolérance aux pannes byzantin commun peut utiliser une réplication de 100 fois pour atteindre le consensus ; ici, nous répliquons le calcul seulement 20 fois.

Les détails de l’analyse technique des calculs et les raisons pour lesquelles la détection des divergences est plus efficace se trouvent dans l’annexe de notre livre blanc.

Étant donné que la détection des divergences ne compare que les résultats du calcul, elle est plus générale que tout schéma qui nécessite la comparaison d’états intermédiaires via une exécution en une seule étape, l’approche utilisée dans la plupart des conceptions de rollup optimistes. Le travail nécessaire au contrat de la passerelle de validation de la détection des divergences dans la couche de consensus est faible, ce qui facilite la mise à l’échelle arbitraire du système en faisant tourner plusieurs ParaTimes simultanément pour une exécution parallèle.

Extensibilité à d’autres systèmes de preuve de fraude/validité

Notez que si la couche de consensus du réseau Oasis intègre la détection des divergences, elle est néanmoins extensible sur le plan architectural pour permettre la mise en œuvre d’autres techniques de validation de l’exécution des rollups. Nous ne voyons pas la nécessité de le faire pour le moment.

Si/quand les schémas de preuve zk-rollup seront suffisamment matures pour un calcul général, un vérificateur zkSNARK serait un excellent complément ; puisque les passerelles de validation intégrées sont implémentées en Go, elles devraient également fonctionner beaucoup plus rapidement que les smart contracts Solidity.

Il existe d’autres variations/dimensions dans l’espace de conception de la preuve de la fraude qui n’ont pas été couvertes ici. Voir ici pour plus d’informations sur la conception d’une preuve de fraude.

Point de contrôle

La détection des divergences nous permet de fixer le paramètre de la taille du comité pour être sûr que la probabilité d’une compromission de l’ensemble du comité est négligeable. Il reste deux problèmes :

1. Détection des divergences — si elle n’est effectuée que pour le comité de calcul, elle n’est pas totalement ouverte, puisque pour être qualifié de nœud de calcul, le demandeur doit être soumis à des limites de ressources telles que les mises, afin d’éviter les attaques de type Sybil.
2. Les défaillances en mode commun, telles que les erreurs de programmation dans le code du réseau Oasis ou le noyau Linux, pourraient permettre à un adversaire d’utiliser un compromis de type “zero-day” pour prendre le contrôle de tous les nœuds de calcul — et de consensus ! — du réseau.

Notez que la préoccupation concernant les erreurs de programmation existe pour tout réseau, bien sûr, et n’est en aucun cas propre à Oasis. En fait, nous pensons que la qualité du code d’Oasis et les processus de révision sont parmi les meilleurs de leur catégorie.

La gestion des vulnérabilités de type “zero-day” est difficile. En effet, comme tous les systèmes logiciels, aucune blockchain n’a de solution générale autre qu’un éventuel hard fork. Dans Oasis, nous abordons les défaillances catastrophiques — des scénarios extrêmement improbables tels qu’une compromission de tous les comités, l’exploitation d’une vulnérabilité de type “zero-day” / des défaillances en mode commun, etc. — en distinguant la détermination de l’ordre des transactions et la détermination du résultat des transactions et en permettant à quiconque de contester les résultats des transactions.

Qu’est-ce que cela signifie ? Nous ajoutons une journalisation sécurisée des hachages de points de contrôle d’état périodiques et de l’ordre des transactions. Ces données permettent de rejouer facilement les transactions à partir d’un point de contrôle connu et bon après qu’une défaillance catastrophique ait été identifiée par un défi et traitée.

La journalisation doit être monotone/finale, car nous incluons les attaques à longue portée/perte de contrôle des clés cryptographiques comme modes de défaillance potentiels. Cette propriété peut être obtenue en écrivant le journal sur de grands livres distribués à appendice unique tels qu’une autre blockchain, par exemple Ethereum ; en écrivant sur un support à appendice unique physique, par exemple une imprimante à alimentation continue ; en écrivant sur un support à écriture unique (CD-R/DVD-R) ; en écrivant sur un support qui est périodiquement copié sur des services de sauvegarde hors ligne ; etc. L’écriture sur Ethereum utiliserait la finalité d’Ethereum pour essentiellement horodater la création de l’enregistrement du journal, tandis que l’écriture sur d’autres mécanismes d’annexe seulement nécessitera la vérification, par exemple en comparant des copies indépendantes, que le support n’est pas une copie nouvelle, mais modifiée du journal légitime. Voir le document Shades of Finality (qui sera publié prochainement) pour une discussion plus approfondie de la finalité de l’ordre des transactions et de la finalité de la valeur de l’état.

Une fois cette étape terminée, n’importe qui peut contester les résultats de la couche de calcul, même après que la détection des divergences ait accepté les résultats. Cela signifie que les défaillances catastrophiques telles qu’un comité entièrement byzantin ou une vulnérabilité de type “zero-day” peuvent être traitées si elles sont détectées à temps. Tant qu’il existe un point de contrôle d’état valide antérieur à la défaillance catastrophique, nous disposons d’un état connu et bon à utiliser comme base de récupération.

La politique recommandée pour gérer les échecs catastrophiques est de respecter l’ordre des transactions. Cela signifie que si un challenger montre qu’une transition d’état incorrecte s’est produite, nous pouvons rejouer les transactions enregistrées soumises après un bon état connu pour calculer l’état actuel correct en utilisant autant de réplication/vérification que nécessaire pour le faire. Tout comme la détection des divergences qui permet un chemin rapide efficace pour le cas où il n’y a pas de divergence contre un schéma plus coûteux pour le cas peu fréquent où une divergence est détectée, le point de contrôle et la relecture pour récupérer des défaillances catastrophiques peuvent être coûteux puisque de telles défaillances catastrophiques sont censées être extrêmement improbables.

Résumé

L’architecture du réseau Oasis résulte d’une co-conception entre la détection de la fraude et l’architecture du système. Il y a une séparation modulaire des tâches entre les couches de calcul et de consensus, l’interface entre elles consistant en un système simple et efficace de preuve de fraude à nu.

Les avantages de la conception d’Oasis sont les suivants :

• Une architecture propre et modulaire, qui rend la conception plus facile à comprendre et à raisonner que les conceptions monolithiques. La modularité se traduit également par des implémentations plus propres, ce qui facilite l’audit de sécurité.
• Détection efficace des fraudes, avec des paramètres de sécurité explicites qui permettent aux concepteurs de ParaTime de choisir les paramètres appropriés pour les cas d’utilisation prévus.
• Les preuves de fraude à nu permettent le développement futur d’environnements d’exécution de contrats intelligents très performants, tels que le code natif sandboxé, ce qui rendra possibles à l’avenir les contrats intelligents à forte intensité de calcul ou de données.
• Les utilisateurs disposent d’une limite inférieure sur la quantité de vérification indépendante effectuée, plutôt que d’espérer que les validateurs soient disponibles/opérationnels pendant la période du défi, comme dans le cas des rollups optimistes.

Le résultat est que le réseau Oasis est une blockchain de type rollup, où la couche de consensus n’exécute que des contrats passerelles de validation. Plusieurs ParaTimes — des machines virtuelles indépendantes de type rollup — ont été déployés avec succès au-dessus de la couche de consensus d’Oasis. Actuellement, le ParaTime Emerald permet l’exécution de contrats intelligents compatibles EVM, et le ParaTime Cipher fournira un environnement d’exécution de contrats intelligents confidentiels, dès sa sortie au premier trimestre 2022.