Les Blockchains se présentent aujourd'hui sous une forme assez standard composée de deux parties. La première partie est l’algorithme de consensus, qui assure la sécurité. La deuxième partie est la machine à états, qui fournit les aspects de la chaîne qui méritent d’être sécurisés. Ethereum, Bitcoin, Zcash et d’autres blockchain sont tous protégés par des variantes du consensus Proof-of-Work, mais les types de transactions et de comptes qu’ils gèrent - les éléments qui constituent leur machine à états unique - sont tous différents. Imaginez un développeur qui a une excellente idée pour une nouvelle blockchain, une chaîne capable de fournir une confidentialité efficace, une distribution des richesses ou une autre fonctionnalité intéressante.
Alors que le développeur s’emploie à implémenter cette machine à états unique, il doit également implémenter une sorte d’algorithme de consensus, et lors du lancement de sa chaîne, il doit faire concurrence aux autres pour les ressources de sécurité. Cela engendre des frais généraux et de l'insécurité pour le développement de nouveaux projets de blockchain.
Une parachain (chaîne parallélisable) est une forme plus simple de blockchain, qui s'attache à la sécurité fournie par une «chaîne de relais» plutôt que de fournir la sienne. La chaîne de relais est appelée ainsi car elle apporte non seulement la sécurité aux parachains attachées, mais fournit également une garantie de transmission sécurisée des messages entre elles. Une caractéristique essentielle des parachains est que les calculs qu’ils effectuent sont intrinsèquement indépendants. Les systèmes entièrement généralisés de contrats intelligents turing-complete se heurtent à des difficultés pour déterminer quelles transactions vont «se heurter», ce qui signifie que les transactions potentiellement parallélisées sont souvent exécutées en séquence, ce qui entraîne une perte de temps de calcul. Tracer des limites claires entre les parachains signifie que nous pouvons toutes les exécuter en même temps sans crainte de collision .
Les parachains hautement spécialisées ont un autre objectif: elles peuvent implémenter les opérations de stockage et de transaction de données de la manière la plus efficace, sans pour autant vous obligé d’utiliser un langage de script spécifique à une blockchain ou une machine virtuelle. Des modèles tels que Bitcoin Script et EVM - Ethereum Virtual Machine - ont été conçus dans un souci d’interopérabilité, mais les systèmes utilisant ces modèles ont un coût d’exécution plus élevé pour toutes les parties de leur mise en œuvre. En revanche, les parachains Polkadot communiquent entre elles par transmission de messages asynchrone et, en tant que telles, ne paient que le coût de l'uniformité des données exactement aux limites où les parachains se rencontrent.
Notez qu’il est toujours possible de créer une parachain qui fournit une framework pour des contrats intelligents turing-complete totalement généraux et complets. Un exemple simple serait une parachain alimentée par la machine virtuelle Ethereum EVM. Les contrats mis en œuvre sur cette chaîne de connexion vont beneficier mais seront en même temps incommoder de la généralité et de l’interopérabilité des contrats intelligent Ethereum pour les raisons susmentionnées. La principale différence est que tout est complètement opt-in (avec consentement préalable). Nous considérons que la capacité de Polkadot à intégrer des solutions ciblées tout en conservant la faculté d’utiliser des frameworks extrêmement généraux constitue l’une de ses fonctionnalités les plus puissantes.
L'un des cas d'utilisation des parachains les plus intrigants est celui de l'évolutivité. Il est possible de créer des parachains qui ont leurs propres parachains, etc. Cela crée une structure arborescente qui peut être utilisée pour effectuer des calculs hautement distribués sans réduire la charge globale sur la chaîne de relais racine. En effet, Polkadot offre la possibilité d'exécuter plusieurs parachain, chacune traitant plusieurs transactions en parallèle, ce qui permet aux réseaux d'obtenir une évolutivité infinie.
Le principal problème est de garantir la disponibilité des données - les blocs de parachain sont censés être accompagnés d'une preuve de validité qui reste disponible pour contrôle pendant un certain temps. Les validateurs sont responsables de la disponibilité des blocs vérifiés. Malheureusement, il n’est pas possible (ou du moins très difficile) de prouver que des messages censés être envoyés ne l’ont pas été, sans qu’ils soient on-chain. Nous pouvons éviter ce problème avec des garanties largement liées à la réputation: lorsque des parties relativement dignes de confiance découvrent qu'un validateur fait de la rétention de données, il peut être sanctionnées. Cela peut aussi être généralisé à un système de vote par jeton ou à des tribunaux sur plusieurs niveaux. Afin de réduire l'efficacité et le caractère pratique des déclarations fausse et malveillantes, chaque signalement d'un comportement répréhensible devrait être accompagné d'un paiement en jetons non remboursable.Ces jetons seront “brûlé” par la suite. Lorsque suffisamment de personnes regardent un calcul, comme dans le cas des parachains de premier niveau, les données nécessaires sont généralement disponibles. Une autre stratégie d'atténuation consiste à concevoir des parachains de telle sorte que la valeur stockée puisse être retirée lorsqu'une chaîne semble bloquée ou attaquée, bien que cela soit difficile lorsque cette chaîne exécute des contrats intelligents qui bloquent des fonds ou gèrent leurs propres dépenses de manière autonome.
Peut-être une approche encore plus intéressante de l'évolutivité consiste-t-elle à utiliser des preuves ZK (zero-knowledge). Les preuves ZK non interactives modernes, telles que ZK-SNARK ou ZK-STARK, nous permettent de vérifier si un programme avec certaines entrées connue et d’autres inconnues a été exécuté correctement, et de savoir quelle a été l’output de ce programme sans pour autant fuité des informations sur les entrées privée. informations sur les entrées privées. Le plus souvent, les preuves ZK comme celle-ci sont considérées comme un outil de protection des données et de la vie privée, mais elles peuvent également être mises à profit pour améliorer les performances: étonnamment, le temps nécessaire pour vérifier ce type de preuve est plus ou moins constant, quelle que soit la complexité du programme. lui-même. Quelques preuves sont réalisées en moins de temps que l'exécution du programme correspondant! Cela signifie que même les transactions extrêmement complexes pouvant nécessiter des heures de traitement peuvent être vérifiées en un temps limité par les validateurs de la chaîne. Malheureusement, les coûts de calcul et de mémoire nécessaires à la création de preuves ZK restent très élevé pour des utilisateurs moyens. Tant que ces coûts resteront élevé, les preuves ZK resteront une pratique d’avenir
L'environnement d'exécution Polkadot
Les Parachains peuvent fonctionner et interagir entre elles puisqu'elles partagent une ou plusieurs couches de base communes, appelées environnement d'exécution Polkadot.
L'environnement d'exécution Polkadot (PRE) est un composant important de la plate-forme Polkadot. Le PRE peut être vu comme les trois couches inférieures d'une pile de quatre couches et sera commun à chacune des chaînes natives au sein de Polkadot.
Les trois couches du PRE sont le Wasm Interpreter, la couche consensus et le couche de réseau. Le code du PRE peut être compilé pour s'exécuter de manière native. La partie supérieure de la pile de Polkadot appelée le runtime (autrement connu sous le nom de machine à états) sera unique pour chaque chaîne et doit être écrit dans un langage qui se compile pour Wasm.
https://slides.com/paritytech/paritysubstrate#/8
En somme, Polkadot se compose de nombreuses parachains avec des caractéristiques potentiellement différentes qui peuvent faciliter l’anonymat ou la vérification formelle. Les transactions peuvent être réparties sur toutes les chaînes, ce qui permet d'en traiter beaucoup plus dans le même laps de temps. Polkadot veille à ce que chacune de ces blockchains reste sécurisée et à ce que toute transaction entre elles soit exécutée convenablement. Les Parachains sont gérés par des collateurs dont la principale tâche est de collecter les transactions des utilisateurs, de produire des preuves de transition d'état pour les validateurs, et de surveiller le comportement répréhensible des validateurs.
Des liaisons spécialisées appelées "Bridge" peuvent être créées pour lier des chaînes indépendantes alors que la chaîne de relais ou "Relay chain" coordonne le consensus et la livraison des transactions entre les Parachains.
Référence:
https://medium.com/polkadot-network/polkadot-the-parachain-3808040a769a
https://polkadot.network/Polkadot-lightpaper.pdf
https://github.com/w3f/Web3-wiki/wiki/Parachains
https://github.com/w3f/Web3-wiki/wiki/Polkadot-Runtime-Environment