core white paper introduction

 Introduction

Le Blockchain Trilemma est un problème bien étudié par les universitaires et les acteurs du marché. Il stipule que toutes les crypto-monnaies, y compris Bitcoin, Ethereum, etc. doivent faire des compromis entre sécurité optimale, évolutivité et décentralisation, en privilégiant souvent deux éléments au détriment du troisième, comme le montre la figure 1,

Figure 1 : Trilemme de la chaîne de blocs (https://bit.ly/391b2m2)

​

Notre solution au trilemme ci-dessus est le consensus Satoshi Plus, qui opère au cœur du réseau central. Le consensus Satoshi Plus combine la preuve de travail (PoW) et la preuve de participation déléguée (DPoS) pour tirer parti des forces de chacun tout en améliorant simultanément leurs lacunes respectives. Plus précisément, la puissance de calcul de Bitcoin garantit la décentralisation, les mécanismes DPoS et d'élection des dirigeants garantissent l'évolutivité, et l'ensemble du réseau maintient sa sécurité de manière holistique. Core est la première chaîne à mettre en place notre nouveau mécanisme de consensus. Bien que ce ne soit pas le dernier, nous pensons qu'avec la force de notre communauté, CORE atteindra les effets de réseau nécessaires pour créer une monnaie réussie et servira de tremplin indispensable pour une adoption plus large du Web 3.

Le reste du papier est organisé comme suit. Tout d'abord, nous comparons les compromis effectués par les autres réseaux L1 et L2. Ensuite, nous approfondissons le consensus Satoshi Plus et ses différentes composantes. Nous discutons ensuite des propriétés de sécurité et des orientations futures du réseau central. Nous discutons ensuite de la devise de la couche de base de la chaîne - CORE. Enfin, nous abordons la gouvernance du réseau Core via le Core DAO.

Bitcoin

En 2009, Satoshi Nakamoto a taillé la rareté dans la pierre de l'abondance. Malgré sa possibilité de réplicabilité infinie, Internet pourrait désormais avoir sa propre monnaie native sur la blockchain : Bitcoin - la première solution véritablement numérique au problème de l'argent [Nak]. Bitcoin a introduit l'exploitation minière PoW dans le monde, permettant à toute personne disposant d'une puissance de calcul de participer à la sécurisation du réseau. Tirant parti du consensus de Nakamoto, Bitcoin est devenu la chaîne de blocs la plus décentralisée, mais avec seulement 7 TPS, il lui manque l'évolutivité [Aut] nécessaire pour passer au-delà des cas d'utilisation de "Store of Value". Le rôle de BTC en tant qu '«or numérique» est incontesté, mais comme l'illustre le battage médiatique autour du Lightning Network, de nombreux membres de la communauté Bitcoin en veulent plus.

Ethereum

La plate-forme dapp la plus populaire et la première blockchain complète de Turing [Buta]. Les abstractions offertes par la machine virtuelle Ethereum (EVM) et le langage de programmation populaire Solidity ont permis à des centaines de milliers, voire des millions, de développeurs de créer pour la première fois des applications décentralisées [She], ce qui a donné naissance à DeFi, Play2Earn, NFTs , etc. Ethereum offrait un TPS plus élevé que Bitcoin au détriment d'une certaine décentralisation, mais même avec ses 15 TPS, des goulots d'étranglement majeurs en matière d'évolutivité subsistent [Fri].

Ethereum 2

Le terme fourre-tout pour les mises à niveau d'Ethereum pilotées par la communauté visait à résoudre les problèmes d'évolutivité, de sécurité, d'efficacité, etc. Deux des changements majeurs sont le passage du PoW au PoS et l'introduction du sharding. Sharding offrira prétendument jusqu'à 100 000 TPS [RK], mais la migration vers PoS suscite des inquiétudes concernant la décentralisation [You]. Déjà, nous assistons à une concentration importante parmi les principaux dépositaires CeFi tels que Binance, Kraken, etc. et les pools de jalonnement comme Lido.

Solana

Une chaîne TPS élevée, 50k TPS, qui tire parti à la fois de la preuve d'historique (PoH) et du sharding [Yak]. Solana a des temps de bloc très courts, 400 ms [Tead], ce qui permet aux applications construites au-dessus du réseau de se sentir comme Web 2 en termes de performances. Afin d'atteindre ce niveau de performance, les exigences pour exécuter un validateur dépassent de loin la plupart des autres réseaux [Teae], ce qui exclut de nombreux acteurs. Un autre compromis existe entre les performances et la disponibilité du réseau, qui a été visible plus récemment avec quelques redémarrages notables de la chaîne [McS] [Mil]. Solana possède également l'une des communautés de développeurs les plus actives, mais la transition vers Rust depuis Solidity s'est avérée difficile pour beaucoup.

Polygone

Une solution de mise à l'échelle L2 construite au-dessus d'Ethereum destinée à résoudre de nombreux défis d'évolutivité sur la chaîne principale en tirant parti des PoS et des chaînes latérales [Teac]. Polygon a attiré un nombre important de développeurs compte tenu de sa compatibilité EVM, qui permet aux développeurs dapp de porter leur code avec un minimum ou aucun changement [Teab]. Polygon fait face à des critiques concernant le manque de décentralisation et de stabilité de son ensemble de validateurs, qui est jusqu'à présent resté inchangé depuis testnet, bien qu'ils travaillent activement à l'amélioration de ces dynamiques avec Polygon DAO [Rze].

Chaîne intelligente Binance

Un hard fork de la base de code Go Ethereum (Geth). L'un des principaux différenciateurs entre BSC et Ethereum est la preuve d'autorité (PoSA) de BSC, un mécanisme de consensus qui combine la preuve d'autorité (PoA) et la preuve de participation déléguée (DPoS) [Teaa]. En tirant parti de ce nouveau mécanisme de consensus, BSC a obtenu des temps de transaction plus rapides, un TPS plus élevé et des frais moins élevés [CZ]. Depuis sa création, BSC a fait l'objet de critiques concernant une décentralisation insuffisante étant donné que son ensemble de validateurs est plus ou moins fixe compte tenu de la relation des tiers avec Binance et des exigences de mise élevées (minimum 2,3 millions USD ou 10 000 BNB contre Ethereum 2 32k USD ou 32 ETH à partir de juillet 2022) combiné au fait que seulement 2 des 21 sont impliqués dans des activités de consensus à un moment donné [Tra]. L'affirmation selon laquelle Binance exécute lui-même l'un des nœuds peut être réfutée via les données en chaîne [BsC].

Comparaisons

Core est une évolution de la base de code Geth. Nous avons tiré parti des améliorations apportées par l'équipe BSC pour ajouter un débit plus important et des transactions moins chères grâce au hard fork. Néanmoins, nous différons de BSC à bien des égards. Une différence prééminente est que Core est basé sur Satoshi Plus Consensus, qui s'appuie sur la preuve de travail (PoW) aux côtés de la preuve de participation déléguée (DPoS). Avec ces modifications, nous sommes en mesure de rester décentralisés sans les compromis de performances observés dans les systèmes de consensus PoW traditionnels. De plus, avec notre score hybride basé à la fois sur la puissance de hachage Bitcoin déléguée et la participation déléguée, nous avons créé un marché fluide pour les validateurs et les récompenses auxquels tout le monde peut participer.

Principaux composants, rôles et workflows

Validateurs

Responsable de la production de blocs et de la validation des transactions sur le réseau Core. Devenir un validateur nécessite une inscription auprès du réseau et le blocage d'un dépôt CORE remboursable à inclure dans le validateur défini conformément aux règles de l'élection du validateur. Tout le monde peut déposer et devenir validateur sur Core.

Relais

Responsable du relais des en-têtes de bloc BTC vers le réseau central. Afin de relayer, un relayeur potentiel doit s'inscrire auprès du réseau et bloquer un dépôt CORE remboursable. Tout le monde peut déposer et devenir relayeur sur Core.

Mineurs BTC

Les mineurs chargés de sécuriser le réseau Bitcoin via PoW. Afin d'avoir leur facteur de puissance de hachage dans le consensus Satoshi Plus, les mineurs doivent déléguer leur pouvoir de hachage à un validateur qu'eux-mêmes ou un tiers exécutent. La délégation est un acte non destructif, ce qui signifie qu'en déléguant sur Core, ils réorientent leur travail existant au lieu de choisir entre la sécurisation de Bitcoin et la sécurisation de Core.

Titulaires de base

Détenteurs de la devise CORE, la devise de base de la chaîne CORE. Tous les détenteurs de CORE peuvent participer au jalonnement en déléguant leurs avoirs à un validateur.

Vérificateurs

Responsable du signalement des comportements malveillants sur le réseau. N'importe qui peut agir en tant que vérificateur dans le réseau central. Les drapeaux de vérification réussis peuvent entraîner des coupures (récompenses ou mises) ou l'emprisonnement des validateurs qui se conduisent mal.

Élection du validateur

Le mécanisme dans lequel les 21 meilleurs validateurs sont sélectionnés pour être inclus dans l'ensemble de validateurs. Les validateurs sont élus en fonction de leur score hybride à chaque tour. la ronde.

Score hybride

La sortie de la fonction de protocole utilisée dans les calculs d'élection du validateur. Les entrées de la fonction sont la puissance de hachage BTC et le CORE délégué au validateur.

Rond

Temps de cycle pour que Core mette à jour le quorum des validateurs et distribue les récompenses, qui est actuellement fixé à 1 jour. Chaque jour, 21 validateurs avec les scores hybrides les plus élevés sont élus dans l'ensemble de validateurs, devenant ainsi responsables de la production de blocs sur le réseau central pour l'intégralité du tour. Au dernier bloc de chaque tour, les récompenses accumulées pour le tour seront calculées et distribuées et le quorum des validateurs pour le tour suivant sera également déterminé.

Fente

Chaque tour est divisé en créneaux et tous les validateurs du quorum produisent à tour de rôle des blocs de manière répétée jusqu'à la fin du tour. Actuellement, la durée du créneau est fixée à 3 secondes. Dans chaque emplacement, un validateur honnête produit un bloc ou ne le fait pas.

Époque

La durée du cycle pour que le système vérifie le statut de chaque validateur afin d'exclure les validateurs emprisonnés du quorum pour les empêcher de participer au consensus pour maintenir le TPS plus ou moins constant dans un tour donné. Actuellement, l'époque est définie sur 200 emplacements, soit 600 secondes ou 10 minutes.

Preuve de travail

La preuve de travail est un mécanisme pratique pour mettre en œuvre un réseau décentralisé. PoW est non discriminatoire et permet à quiconque possède une puissance de calcul de participer à l'exploitation minière. Tirant parti du réseau minier BTC existant, les relais Core transmettent chaque bloc Bitcoin en tant que transaction à la chaîne Core. Ce mécanisme de relais est la façon dont Satoshi Plus valide la puissance de hachage déléguée de manière sans confiance. Avec cet élément PoW, Satoshi Plus est en mesure de tirer parti de la sécurité du réseau Bitcoin pour sécuriser Core.

Relais

Les relais dans Core sont chargés de relayer les en-têtes de bloc BTC sur le réseau via le client léger en chaîne. Les relayeurs doivent à la fois s'inscrire et réussir la vérification afin de recevoir des récompenses.

Mineurs BTC

En utilisant leurs clés publiques et privées, les mineurs BTC peuvent déléguer leur pouvoir de hachage à un validateur Core ou se déléguer s'ils choisissent d'exécuter un validateur en vérifiant et en synchronisant leur identité (adresses) sur les blockchains BTC et Core. Lorsque les relais soumettent des transactions, ils synchronisent les blocs extraits par le mineur BTC avec le réseau central. À chaque tour, le réseau Core calcule la puissance de hachage BTC associée à chaque validateur en comptant le nombre de blocs produits par chaque mineur du réseau BTC au cours du même jour de la semaine précédente. L'architecture de la communication de la chaîne de mappage est illustrée dans le schéma ci-dessous.

Figure 4 : Relais de puissance de hachage BTC Miner.

Preuve de participation déléguée

La preuve de participation est une alternative évolutive et économe en énergie au PoW, mais elle limite les utilisateurs à petite participation. Dans une tentative d'uniformiser les règles du jeu, certaines chaînes de blocs ont introduit divers types de mécanismes Delegated Proof of Stake (DPoS), permettant aux détenteurs de jetons de voter et d'élire l'ensemble de validateurs en déléguant leurs avoirs aux validateurs, généralement incités par des récompenses. En utilisant DPoS, même les détenteurs de CORE à petite participation peuvent déléguer leur CORE à des candidats validateurs, ce qui responsabilise la communauté et encourage la démocratisation du CORE délégué.

Élection du validateur

Aperçu

L'élection du validateur de Core adhère aux mécanismes suivants :

Les scores hybrides sont calculés pour tous les validateurs du réseau. La fonction de calcul des scores est définie comme suit :

​

S = rHp/tHp ∗ m + rSp/tSp ∗ (1 − m) (1)

​

où:

rHp = puissance de hachage déléguée au validateur, qui est mesurée via le nombre de blocs BTC produits

tHp = puissance de hachage totale sur Core

rSp = participation déléguée au validateur, qui est mesurée via la quantité de jetons CORE délégués

tSp = mise totale sur Core

m = est une pondération dynamique qui s'ajuste au fil du temps pour assurer une transition en douceur pendant la montée en puissance

​

Sélectionnez les 21 validateurs avec les scores hybrides les plus élevés à inclure dans l'ensemble de validateurs.

​

L'élection a lieu à la fin de chaque tour pour sélectionner les validateurs pour le tour suivant via le mécanisme ci-dessus.

Production de blocs

L'élection du validateur Satoshi Plus est conçue pour sélectionner des validateurs dérivant à la fois des méthodes PoW et DPoS décrites ci-dessus. Après l'élection, le mécanisme trie tous les validateurs et produit des blocs de manière circulaire. Par round robin, nous entendons que chaque validateur a une chance de produire un bloc dans un ordre strict, de 1 à 21 classé par score hybride avant de recommencer à partir du haut. De plus, en limitant le nombre de validateurs, Satoshi Plus offre un taux de transaction plus élevé et une évolutivité accrue. De plus, ce mécanisme offre une résistance supplémentaire à diverses attaques avec une efficacité et une tolérance améliorées d'un certain nombre de joueurs byzantins (malveillants ou piratés).

Autorégulation du validateur

Le noyau contient des mécanismes de suppression et d'emprisonnement pour dissuader les comportements malveillants des validateurs à chaque tour. Lors de la production de blocs, les validateurs de base existants vérifient si un validateur actuel a été emprisonné périodiquement. Si c'est le cas, ils mettront à jour l'ensemble de validateurs après une période d'époque. Par exemple, si Core produit un bloc toutes les trois secondes et que la période d'époque est de 200 blocs, alors l'ensemble de validateurs actuel vérifiera et mettra à jour l'ensemble de validateurs de l'époque suivante en 600 secondes (10 minutes). La conception de l'incarcération est d'exclure les validateurs qui se comportent mal des activités de consensus afin d'améliorer la sécurité du réseau et de maintenir la stabilité du TPS.

Illustration

Au dernier bloc d'un tour, les récompenses sont calculées et distribuées. Actuellement, 90 % des récompenses vont aux validateurs et 10 % des récompenses vont au contrat de récompense du système. Sur les 90 % payés aux validateurs, un certain pourcentage (x %) est pris comme commission par le validateur avant de payer ses délégués. Le contrat de récompense du système accumule des récompenses pour payer à la fois les relais et les vérificateurs avec un plafond maximum actuel de 11 millions de récompenses CORE accumulées (10 millions de récompenses de relais et jusqu'à 1 million de récompenses de vérificateur qui se réapprovisionnent automatiquement) avant de brûler les récompenses excédentaires. Les vérificateurs sont payés immédiatement après la soumission réussie et les relais sont payés tous les 100 blocs BTC.

Récompenses de nœud et distribution aux délégants

Les deux catégories de récompenses pour les validateurs sont (1) les récompenses de base (CORE nouvellement créé) et (2) les frais perçus sur les transactions de chaque bloc. Les validateurs sont tenus de partager les récompenses avec les délégants qui ont jalonné leur CORE avec eux en plus de ceux qui délèguent le pouvoir de hachage. Étant donné que chaque validateur a une probabilité égale de produire des blocs, à long terme, tous les validateurs stables devraient obtenir une part similaire de la récompense.

Les validateurs peuvent décider du montant à redonner aux délégants qui leur ont délégué leur CORE ou leur pouvoir de hachage. Ces validateurs sont incités à récompenser grandement leurs délégants afin d'attirer plus de puissance de hachage et de participation. Après avoir pris leurs frais, le protocole utilise une fonction pour déterminer la répartition entre les récompenses mises en jeu et les récompenses de puissance de hachage pour un validateur défini comme :

rH = rHp/tHp ∗ m/S ∗ R (2)

rS = rSp/tSp ∗ (1 − m)/S ∗ R (3)

où:

rH = récompenses du validateur attribuées à la puissance de hachage

rS = récompenses du validateur attribuées au staking

R = récompenses globales attribuées à tous les délégants

rHu = rH/rHp (4)

rSu = rS/rSp (5)

où:

rHu = récompenses de puissance de hachage du validateur par unité

rSu = récompenses de jalonnement du validateur par unité

Notez que ces fonctions sont conçues pour créer un marché actif pour les récompenses et encourager la concurrence entre l'ensemble de validateurs pour le pouvoir de hachage délégué et la participation déléguée. Par le même mécanisme, les délégants essaieront d'optimiser leurs propres récompenses en choisissant des validateurs avec des quantités inférieures de pouvoir de hachage délégué et de participation.

Exemple appliqué de récompenses et de distribution de nœuds

Supposons qu'il y ait 2 validateurs et que les deux soient élus :

A : 2 unités de puissance de hachage, 1 unité de mise

B : 1 unité de puissance de hachage, 4 unités de mise

Supposons également qu'il y ait 10 unités au total de puissance de hachage BTC sur le réseau central, donc le validateur 1 a 20 % de la puissance de hachage et le validateur 2 a 10 % de la puissance de hachage. De même, nous supposons qu'il y a 20 unités de participation au total sur le réseau CORE, donc le validateur 1 a 5 % de la participation et le validateur 2 a 20 % de la participation. Nous avons également défini m sur 2/3 pour cet exemple.

Pour la simplicité du calcul, nous fixons le nombre de récompenses gagnées à distribuer à 1 pour les deux validateurs.

Scores :

SA = 2/10 ∗ 2/3 + 1/20 ∗ 1/3 = 9/60 (6)

SB = 1/10 ∗ 2/3 + 2/10 ∗ 1/3 = 8/60 (7)

Récompenses:

rHA = (2/10 ∗ 2/3)/SA = 8/9 (8)

rSA = (1/20 ∗ 1/3)/SA = 1/9 (9)

rHB = (1/10 ∗ 2/3)/SB = 1/2 (10)

rSB = (2/10 ∗ 1/3)/SB = 1/2 (11)

Récompense par unité :

rHuA = rHA/2 = 4/9 (12)

rSuA = rSA/1 = 1/9 (13)

rHuB = rHB/1 = 1/2 (14)

rSuB = rSB/4 = 1/8 (15)

Récompenses Relayeur

Les relais gagnent une partie des récompenses du système de base et des frais de transaction pour les communications inter-chaînes. Les récompenses Relayer sont distribuées par lots tous les 100 blocs BTC. Les relayeurs réclament périodiquement leurs récompenses.

Récompenses du vérificateur

Les suggestions de barre oblique CORE peuvent être soumises par n'importe qui et garantissent que les acteurs malveillants et nuisibles sont punis. La soumission de la transaction nécessite des preuves et des frais, mais des soumissions précises rapportent des récompenses qui dépassent les coûts. Les récompenses sont payées immédiatement à partir du contrat de récompenses du système, dans la même transaction, en cas de succès.

Sécurité

Aperçu

Une catégorisation de haut niveau des différents vecteurs d'attaque peut être décomposée en attaques de réseau et attaques de consensus.

Core atténue les attaques réseau (DDoS, Eclipse, BGP Hijack, etc.) grâce à une combinaison de filtrage des transactions, de dispersion géographique des nœuds et de sélection aléatoire de nœuds pour les communications P2P, ainsi qu'une liste de semences officiellement publiée pour les nœuds publics.

Les attaques par consensus sont plus intéressantes et ont une taxonomie plus large de vecteurs de menace. Notre combinaison de PoW, DPoS et notre mécanisme d'élection de validateur nous offrent de nombreuses propriétés souhaitables. Le pré-calcul et l'exploration égoïste ne peuvent pas être actionnés par un validateur fixe défini de manière circulaire car ils tentent de manipuler un mécanisme pseudo-aléatoire qui n'existe pas sur Core. La censure et les retards de transaction sont passibles de poursuites mais sont atténués tant qu'il y a des validateurs honnêtes dans l'ensemble. Dans le même ordre d'idées, certaines attaques comme 51 % et les attaques Sybil ne peuvent pas être entièrement atténuées, mais les deux sont économiquement imprudentes à tenter et très difficiles à réaliser compte tenu de notre classement par le score hybride de leur puissance de hachage et de leur mise. Les attaques à longue portée sont atténuées par notre système de points de contrôle et notre recours au PoW, qui ne souffre pas de cette catégorie d'attaque. Avec les points de contrôle en place, la catégorie d'attaques la plus pertinente sont les diverses attaques à courte portée (longue portée + points de contrôle = courte portée).

Attaques à courte portée

Les attaques à courte portée se présentent sous diverses formes, mais en résumé, elles visent à réécrire un petit nombre de blocs plutôt que de remonter jusqu'à Genesis. Quelques exemples notables sont les attaques de corruption, le déni de vivacité et les attaques raciales. Ci-dessous, nous présentons une preuve mathématique indiquant que tant que moins d'un tiers des nœuds sont malveillants et que suffisamment de blocs sont confirmés, les transactions sur Satoshi Plus sont définitivement sûres.

Preuve mathématique

Dans cette section, nous démontrons que Satoshi Plus est sécurisé si moins d'un tiers des validateurs sont contradictoires. Nous commençons par examiner les actions des ennemis potentiels. Quelle est la stratégie "idéale" de l'adversaire et que pourrait-il réaliser ? Nous affirmons que la limite d'un tiers est serrée en présentant une méthode d'attaque idéalisée : sous une attaque, le système est compromis si l'adversaire prend plus d'un tiers des sièges de validateur. Moins d'un tiers serait un échec. Par la suite, nous discutons de la logique derrière notre preuve ainsi que de la méthodologie de la preuve par contradiction. Enfin, nous présentons la preuve formelle, qui explique mathématiquement les résultats revendiqués.

L'attaque équilibrée

Dans cette section, nous examinons les moyens d'augmenter la probabilité d'une violation de la sécurité d'un point de vue contradictoire. Nous présentons une méthode pour effectuer une attaque à double dépense. Dans cette attaque, les adversaires parviennent à garder une deuxième blockchain cachée et à la libérer lors de l'attaque. L'attaque à double dépense est réussie si la blockchain révélée est plus longue que la blockchain publique la plus longue actuelle. Pour ce faire, les adversaires doivent profiter du protocole et manipuler les blocs honnêtes de telle manière qu'ils assistent à l'attaque sans violer le protocole. Par exemple, ils peuvent maintenir les chaînes de blocs attaquantes et légales aussi équilibrées que possible, comme le montre la figure 6,

3 validateurs sont dans cette attaque, dont un contradictoire. La cible de l'attaque est le bloc sur l'emplacement 0 (avec un signe étoile). Le bloc 1 est à l'origine caché lors de l'attaque. Le bloc avec l'étoile et le bloc 1′ sont visibles pour les validateurs honnêtes, et ils sont orientés pour générer le nouveau bloc, le bloc 2, au-dessus du bloc 1′. L'attaquant génère alors un autre bloc 4 au-dessus du bloc 1, le publie, puis génère le bloc 4′ et le cache au slot 4. En conséquence, lorsque des validateurs honnêtes observent deux blockchains de même hauteur au slot 5, ils sont motivés à générer un nouveau bloc, le bloc 5 au-dessus du bloc 4, et ainsi de suite. Avec cette stratégie, les deux blockchains peuvent être maintenues en équilibre aussi longtemps que possible avec un seul adversaire. La transaction d'un utilisateur n'est pas sécurisée, peu importe le temps qu'il attend. Même si 16 créneaux se sont écoulés dans notre exemple, le bloc ciblé est annulé si l'adversaire décide d'effectuer un assaut au créneau 16.

Méthodologie

Plongeons-nous dans la stratégie d'attaque dans la partie 4.2.2 pour avoir une idée de ce à quoi ressemble une attaque réussie. Chaque validateur honnête, comme nous le savons, génère exactement un bloc dans son emplacement. Dans cette attaque, deux blocs contradictoires sont générés au niveau d'un validateur contradictoire et ont contribué à deux chaînes de blocs. L'idée est de maintenir un équilibre entre les deux blockchains. Par conséquent, à chaque hauteur, une paire de blocs correspondants est nécessaire. Supposons que le bloc 1′ est le début de l'attaque et a le même parent que le bloc avec l'étoile dans notre scénario. La hauteur du bloc 4 est égale à celle du bloc 3, tandis que le bloc 4′ est égal à celle du bloc 5. Le bloc 7′ correspond au bloc 6, tandis que le bloc 7 correspond au bloc 8.

La clé d'une attaque réussie est que chaque adversaire génère deux blocs dans son emplacement respectif et les associe à deux blocs honnêtes distincts. Le modèle « un match-deux » illustre pourquoi, pour une attaque réussie, le rapport adversaire/validateur honnête doit être d'au moins 1 : 2, ce qui implique que la garantie de sécurité est d'un tiers des adversaires. L'adversaire est-il capable de plus ? Est-il possible de construire trois blocs adversaires dans un emplacement et de les faire correspondre à trois blocs honnêtes ? La réponse est non. La raison en est que les deux blocs adversaires formés au même créneau doivent correspondre à deux blocs honnêtes, dont l'un est généré avant le créneau et l'autre après le créneau. Pour correspondre à trois blocs honnêtes, deux blocs adversaires doivent correspondre à deux blocs honnêtes générés à la fois avant et après la fente, ce qui n'est pas possible. La section suivante comprendra une preuve formelle.

La principale technique que nous utilisons est la preuve par contradiction. Pour prouver quelque chose par contradiction, nous supposons que ce que nous voulons prouver n'est pas vrai, puis montrons que les conséquences de cela ne sont pas possibles. Autrement dit, les conséquences contredisent soit ce que nous venons de supposer, soit quelque chose que nous savons déjà être vrai.

Preuve formelle

Nous supposons que le nombre total de validateurs est N, parmi lesquels m validateurs sont honnêtes et les validateurs restants sont contradictoires. Alors,

m > (2/3)N. (16)

Selon le protocole, nous adoptons un modèle discret où les actions se déroulent dans des slots. Si un validateur publie un ou plusieurs blocs dans un créneau, tous les validateurs reçoivent le ou les blocs à la fin du créneau. Un validateur est dit honnête s'il suit toujours le protocole. Chaque validateur est soit honnête, soit contradictoire. Un bloc est dit honnête (resp. contradictoire) s'il est généré par un validateur honnête (resp. contradictoire). De toute évidence, à la fin de chaque créneau, tous les validateurs honnêtes sont entièrement synchronisés. Les validateurs honnêtes ne génèrent de nouveaux blocs qu'en plus de la ou des chaînes de blocs publiées les plus longues sur leurs propres créneaux. Une blockchain est dite honnête dans le slot r si c'est la blockchain la plus longue comme le voient certains validateurs honnêtes dans le slot r. Lorsque nous mentionnons une blockchain, nous supposons toujours que la blockchain est légale (c'est-à-dire acceptée par des validateurs honnêtes) selon le protocole. Définissez un créneau de validateur honnête comme étant un créneau où le générateur légal est un validateur honnête.

En disant blockchain b, nous entendons la blockchain se terminant par le bloc b. Soit T(b) le slot dans lequel le bloc b est généré. La hauteur du bloc b, notée h(b), est définie comme le nombre de blocs (y compris le bloc de genèse) dans la même blockchain. Ensuite nous avons

Lemme 1. Les blocs honnêtes ont des hauteurs identiques.

Preuve. C'est une simple conséquence du fait que tous les générateurs honnêtes ont vu les mêmes blocs et que chaque validateur honnête adopte la blockchain la plus longue à la fin de chaque slot.

Lemme 2. Supposons que deux blocs contradictoires, bloc a et bloc b, satisfassent T(a) = T(b) et correspondent à deux blocs honnêtes c et d, alors (T(a)−T(c))(T(a) −T(d)) < 0. C'est-à-dire que les deux blocs honnêtes ne peuvent pas être générés à la fois avant ou après le slot des blocs antagonistes.

Preuve. Contrairement à l'affirmation, supposons que les blocs c et d puissent être générés à la fois avant ou après l'intervalle T(a). Sans perdre de généralité, supposons qu'ils sont générés après T(a). Par définition, en affirmant que le bloc a correspond au bloc d (le bloc b correspond au bloc c, respectivement), nous avons h(a) = h(d) (h(b) = h(c), respectivement). Selon le protocole, puisque le bloc honnête c est généré après le bloc a sur la même blockchain, nous avons h(c) > h(a) (et h(d) > h(b), respectivement). Ainsi, nous avons,

h(a) = h(d) > h(b) = h(c) > h(a). (17)

La contradiction surgit, donc la preuve.

Notez qu'en conséquence, un adversaire peut correspondre au plus à deux blocs honnêtes pendant un créneau.

Une séquence contradictoire est définie comme une séquence de validateurs contradictoires consécutifs classés par le protocole. Nous disons qu'un bloc contradictoire correspond à un bloc honnête s'ils sont à la même hauteur de différentes blockchains.

Lemme 3. Les blocs contradictoires générés par une séquence contradictoire de n validateurs correspondent au plus à 2n blocs honnêtes.

Preuve. Ceci est une extension naturelle du Lemme 2

Un bloc est dit permanent après le slot r si le bloc reste dans toutes les blockchains honnêtes à partir du slot r. Fondamentalement, si une transaction d'utilisateur est permanente, l'utilisateur peut croire en toute sécurité que sa transaction ne sera pas annulée, peu importe ce que les adversaires feront à l'avenir.

Théorème 4. Si un bloc honnête b reste dans une blockchain honnête dans le slot T(b)+N, alors le bloc b est permanent.

Preuve. Nous prouvons le résultat recherché par contradiction. Pour simplifier, supposons r = T(b). Soit n le nombre d'adversaires dans les N validateurs.

Contrairement à l'affirmation, supposons que s ≥ r+N est le plus petit emplacement lorsqu'il existe une autre blockchain honnête d1 qui n'inclut pas le bloc b. Alors il existe une autre blockchain honnête d2 dans le slot s−1 contenant le bloc b. Alors h(d2) ≤ h(d1). Soit k le nombre de séquences contradictoires dans le premier N rang de validateur à partir du slot r. Soit n1, n2, . . . , nk étant le nombre de validateurs dans chaque séquence contradictoire. On a [Σk i=1] ni = n et k ≤ n. Soit la fonction M(ni) représentant le nombre de blocs honnêtes appariés par la séquence contradictoire ni. Alors, on a M(ni) ≤ 2ni d'après le lemme 3. Soit ℓ = [ (s−r) / N ], alors ℓ est un entier positif puisque s − r ≥ N. Soit k′ le nombre de séquences contradictoires commençant de l'emplacement r + ℓN se terminant par l'emplacement s. Alors n1, n2, . . . , nk′ sont le nombre de validateurs dans les séquences contradictoires pendant le créneau [r + ℓN, s].

Notez que puisqu'il y a k′ séquences contradictoires, il y a au moins Σ[k′ i=1] M(ni) validateurs honnêtes pendant le créneau [r+ℓN, s] pour séparer les séquences. Ainsi le nombre total de blocs honnêtes pendant [r,s] est au moins ℓm + Σ[k′ i=1] M(ni). Notez que chaque bloc honnête a des hauteurs identiques selon le lemme 1, donc l'augmentation de hauteur de la blockchain d1 et de la blockchain b2 sont toutes deux au moins

les blocs sont générés et inclus dans les deux blockchains pendant le slot [r, s].

D'autre part, nous calculons le nombre maximum de blocs que les adversaires peuvent faire correspondre dans les deux blockchains. Chaque séquence contradictoire avec ni validateurs contribue M(ni) blocs pour faire correspondre les blocs honnêtes dans les deux chaînes. Ainsi, le nombre total de blocs honnêtes appariés est

Une contradiction apparaît avec l'équation 18.

Résumé de la sécurité et de la finalité

Sur la base de la preuve mathématique de la section précédente, nous concluons que tant qu'une transaction est confirmée par plus de N blocs, où N est la taille de l'ensemble de validateurs élus, elle ne peut jamais être inversée. Nous avons également prouvé que pour mener à bien une attaque, au moins 1/3 des validateurs doivent être contradictoires.

Notez que le modèle contradictoire utilisé dans la preuve est extrêmement strict. Les adversaires du modèle de preuve sont supposés opérer dans des conditions de coordination parfaite et sont placés dans des créneaux parfaits dans l'ensemble pour compromettre les validateurs honnêtes dans un rapport de 1:2. Dans ce cas, ils ont également la capacité d'inciter les validateurs honnêtes à choisir le bloc requis pour effectuer l'attaque lorsqu'il y a 2 blocs avec la même hauteur de bloc.

En réalité, les conditions mentionnées ci-dessus sont très peu susceptibles de se produire et, dans certains cas, sont impossibles. Core a mis en place des sanctions sévères sur divers comportements malveillants pour dissuader les validateurs de mener de tels comportements. À la suite de ces contre-mesures, pour les transactions normales sur Core, les confirmations de bloc (1/2)N devraient fournir une sécurité suffisante. Pour les transactions plus critiques, nous recommandons les confirmations de bloc (2/3)N+. Pour le cas le plus pessimiste, les confirmations de bloc N atteindront une sécurité de 100 %.

Étuis slash-able

Core a réussi à atténuer la plupart des attaques par divers moyens décrits tout au long de ce document. Notre preuve ci-dessus fournit de fortes garanties qu'avec suffisamment de confirmations de blocage, nous sommes toujours en sécurité. Cependant, nous avons également choisi d'implémenter des mécanismes de barre oblique + prison/éjection pour dissuader davantage les comportements malveillants. Les vérificateurs peuvent soumettre des preuves pour que les validateurs soient coupés et emprisonnés pour différents cas. Deux cas notables pouvant être slashés sont la double signature et l'indisponibilité.

Explorations futures

Mise à l'échelle et inter-chaînes

Là où Core est entièrement compatible EVM, nous pouvons tirer parti des solutions de mise à l'échelle d'Ethereum et d'autres chaînes compatibles, par exemple divers types de cumuls. Nous pouvons également choisir de descendre un relais L0 de style Polkadot ou Cosmos contre un modèle de chaîne de moyeu. L'avenir de la mise à l'échelle est prometteur et nous prévoyons d'intégrer les meilleures technologies d'autres chaînes à mesure que la recherche mûrit.

Sécurité renforcée

Bien que la nature circulaire de la production de blocs offre certains avantages en matière de sécurité, elle implique également des compromis. Par exemple, en ayant un ordre connu à l'avance, le protocole n'est pas sensible à une catégorie entière d'exploits aléatoires potentiels, mais le validateur produisant des blocs est entièrement connu, ce qui peut conduire à des attaques plus ciblées. En réponse, nous nous concentrons sur les moyens d'améliorer la production de blocs. En particulier, la recherche sur l'élection d'un chef secret unique [HG] que des chaînes comme ETH explorent également est d'un grand intérêt.

CŒUR

Alimentation sonore

Suivant le modèle monétaire solide de Bitcoin, l'offre de CORE a un plafond strict de 2,1 milliards de jetons. En plus du plafond strict, un pourcentage de toutes les récompenses en bloc et des frais de transaction sera brûlé de la même manière que le modèle "Ultra Sound Money" d'Ethereum. Le pourcentage exact à brûler sera déterminé par le DAO.

En effet, CORE approchera asymptotiquement le total de 2,1 milliards de jetons mais ne l'atteindra jamais complètement, comme le modèle tokenomics d'Avalanche.

Courbe d'émissions

Les récompenses globales pour CORE seront versées sur une période de 81 ans. Cette période plus longue augmente la probabilité de succès de la chaîne en incitant pleinement tous les participants au réseau avant de passer à une rémunération uniquement par des frais de transaction. Cette récompense de bloc supplémentaire sous la forme de CORE peut également être considérée comme un moyen pour les mineurs BTC existants de continuer à recevoir des subventions après l'arrêt des récompenses de bloc Bitcoin (vers 2040) en devenant des validateurs sur le réseau Core en tirant parti de leur puissance de hachage existante.

Conclusion

Ce document a présenté Core DAO, le réseau décentralisé qui, selon nous, servira de noyau du Web 3. Notre mécanisme de consensus, Satoshi Plus, combine PoW et DPoS pour résoudre le « Blockchain Trilemma » souvent discuté. Nos améliorations en matière d'évolutivité, de sécurité, d'efficacité et de décentralisation ainsi que notre compatibilité EVM libèrent la puissance des applications décentralisées pour tout le monde - développeurs, utilisateurs, etc.

CORE, la monnaie de la couche de base du réseau Core, sera supervisée par le DAO. Grâce à sa rareté prouvée, son mécanisme de contraction, sa gouvernance, etc. CORE vise à devenir à la fois la couche d'accumulation de valeur et d'utilisabilité pour toutes les applications décentralisées.