Il y a beaucoup d'articles philistins et de discussions sur Internet, mais pas assez d'informations sur le fond. À un moment donné, l'auteur a réalisé que la mécanique et de nombreuses nuances de sécurité associées n'étaient pas entièrement comprises, même par de nombreux développeurs de crypto-monnaie. Cela a été révélé dans un cas réel de portage de l'implémentation PoS pour l'une des crypto-monnaies et dans la publication ultérieure d'informations sur les vulnérabilités trouvées par des experts tiers.
Cet article sera utile à tous les développeurs qui ont déjà rencontré des vulnérabilités PoS ou qui sont encore à venir.
Horrifié sous la coupe.
Un grain d'histoire
Sur Internet, l'émergence du Proof-of-Stake (PoS) dans Peercoin est retracée après une discussion sur l'un des forums en 2011, son utilisation ultérieure dans Novaoin et sa distribution ultérieure dans PIVX et d'autres fourches Bitcoin. Une logique kernel.h assez primitive a été introduite dans le kernel.cpp kernel.h / kernel.cpp , qui parcourt les espaces des fourches sous la forme de divers modules Frankenstein.
L'algorithme PoS a traversé plusieurs étapes de développement, quelqu'un leur donne des versions. Maintenant, les options PoS sont divisées pour des raisons naturelles, DPoS est apparu. L'une des solutions les plus avancées est le protocole Casper dans Ethereum.
Toute blockchain nécessite la génération de blocs et quelqu'un devrait avoir le droit de construire un nouveau bloc. Si l'auteur le fait sans trop de concurrence dans une chaîne de blocs telle que le système de contrôle de version Git, alors dans les crypto-monnaies, il y a une lutte acharnée pour la récompense du bloc dans le cadre de la preuve de travail (PoW) - trouver une telle combinaison de paramètres d'entrée variables en sélectionnant qui donne un résultat correspondant à déterminé par un objectif donné (exploitation minière, exploitation minière).
PoS remplace Proof-of-Work (PoW) pour éviter de gaspiller des ressources sur l'exploitation minière. Au lieu de cela, tous les paramètres d'entrée sont strictement définis avec une caractéristique constante basée sur les économies existantes des porte-pièces. Par conséquent, PoW est requis comme point de départ pour PoS, si vous ne recourez pas à diverses options pour l'enrichissement hypothécaire initial des créateurs de la pièce.
Pourquoi?
Les économies d'énergie sont à peu près aussi importantes pour les développeurs et les détenteurs de pièces que la limitation des émissions de gaz à effet de serre pour les producteurs et les consommateurs. La cruelle vérité est différente:
- Les projets basés sur PoW sont soumis à ce que l'on appelle «51% des attaques»: les attaquants peuvent exploiter de grandes puissances, créer une chaîne parallèle, puis la publier soudainement avec un mouvement de pièces différent (c.-à-d. Double gaspillage),
- Les mineurs PoW doivent couvrir leurs coûts et investir dans le renforcement des capacités - il s'agit d'une sortie directe de capitaux des projets,
- les propriétaires d'épargne veulent maintenir leur pouvoir d'achat en levant des capitaux, plutôt qu'en examinant l'inflation naturelle.
Sur un exemple vivant: en novembre-décembre 2018, il y a eu des tentatives d'attaques; puis en décembre-février, il y a eu un remue-ménage comme la pièce la plus rentable pour l'exploitation sur des cartes vidéo; le taux est passé de 2+ à 0,5 USD; Après le passage au PoS, le taux est passé à 1 USD en une semaine et l'afflux d'investissements a augmenté.
Points techniques
Attention: dans cette section, nous parlons des PoS "traditionnels" sous la forme comme c'est le cas dans Peercoin, PIVX et leurs fourches.
Vous devez comprendre qu'il n'y a pas de centralisation et de comptabilisation des «points». Dans cette version, le même principe de chance fonctionne que dans PoW.
1. Terminologie
La terminologie est relativement générale, mais dans différentes implémentations, ses nuances sont:
- Cible PoW - cible = cible de base, généralement 2 ^ 240 (0x0000ffff ...) divisé par la complexité du bloc (augmente le nombre de zéros en face).
- Difficulté du bloc - la complexité du bloc par rapport à l'objectif de base, déterminée de manière déterminante en fonction du taux de croissance de la chaîne actuelle.
- UTXO - Sortie de transaction non dépensée , une paire d'un hachage de transaction et un numéro de sortie.
- CoinBase est une transaction spéciale avec l'index 0 dans le bloc qui contient la récompense.
- Stake ou CoinStake est une transaction spéciale avec l'index 1 dans un bloc.
- Entrée de mise - UTXO qui répond aux exigences d'un pari par taille et par âge.
- Modificateur de mise - un paramètre spécial calculé de manière déterministe pour chaque entrée de mise .
- Stake Hash est un résultat de hachage qui devrait être arithmétiquement inférieur à Stake Target .
- Cible de mise - la même que la cible PoW, mais augmentée proportionnellement du montant de la contribution de mise par rapport à l'enchère minimale.
- Bloquer la signature - Bloquer la signature .
- Fork - une chaîne de ramification.
- Split - partage en réseau.
- Orphelin - blocs jetés en raison du choix d'une autre alternative.
2. Anatomie
Processus de génération:
- Nous trouvons tous les UTXO qui répondent aux exigences de Stake Input
- Trouvez le modificateur de mise.
- Multiplier la cible PoW par entrée de pieu
- en millionièmes en fait - c'est pourquoi 1 MH PoW hashrate sort expérimentalement égal à une pièce.
- Nous
Stake Hash = H(Stake Modifier, Stake Block Time, UTXO output index, UTXO txid, Current Block Time) .
- paramètre variable uniquement Temps de blocage actuel
- Si
Stake Hash >= Stake Target , essayez de trouver Current Block Time dans la plage acceptable.
- vous devez tenir compte de la possibilité de débordements de cibles de mise lorsqu'il est multiplié par la quantité de données de mise, selon la mise en œuvre.
- Nous mettons Coinbase dans tx [0] et CoinStake dans tx [1].
- le bénéficiaire de Coinbase est le même script (adresse) que Stake Input.
- Nous signons le bloc.
2.1. Temps de blocage:
Il est facile de voir qu'une arnaque peut apporter certains avantages au fil du temps. Le consensus standard limite les limites inférieure et supérieure.
Les inférieurs définissent toujours la durée moyenne des blocs sur les N derniers blocs, généralement supérieure à 11. Il s'agit de la tolérance pour l'inexactitude du temps au niveau des nœuds générateurs.
La limite supérieure historique a été fixée pour PoW avec un doigt vers le ciel à 2 heures. L'augmentation des intervalles réduit la complexité et rend la branche moins attrayante - par conséquent, cela n'a aucun sens. Mais pour PoS, cela a du sens.
PIVX et d'autres limitent le temps futur à un maximum de 3 minutes. Certains mettent une restriction plus sévère, mais cela crée des problèmes pour les utilisateurs. Certaines implémentations PoS ont décidé de changer les intervalles de temps de bloc actuels d'une seconde à 15-16 secondes.
2.2. Modificateur de mise:
Le Stake Modifier a été conçu comme un moyen de rendre la prédiction difficile et de construire la chaîne à venir, mais quelque chose s'est mal passé ...
Il existe différentes options pour le calculer: les derniers bits de hachage de blocs à la fin d'intervalles de temps progressivement spécifiés, des valeurs [pas très] mal prédites des blocs précédents, etc. À certains endroits, cela ressemble plus à du code obscurcissant qu'à quelque chose de sensé.
L'original prend un intervalle de 64 intervalles. Cet écart est progressivement divisé en 64 parties inégales. Les bordures sont arrondies en minutes. Aux frontières, les blocs existants sont sélectionnés et un dernier bit en est extrait. Il s'avère donc un nombre 64 bits, quelque chose de similaire à Nonce.
L'intervalle à Peercon est de 20 minutes, mais les gars de PIVX ont décidé que l'intervalle de 1 minute, arrondi à la minute, était ce que le médecin avait ordonné.
En général, dans certaines implémentations comme Blackcoin V2 +, tout est fixe et le modificateur Stake est compté de la tête, tandis que dans Peercoin V03, PIVX, Blackcoin V1 et d'autres du bloc Stake Input. Ce dernier détruit presque complètement le sens. On suppose que la confusion a disparu à cause du problème banal de nommage des variables, de métamorphoses supplémentaires et de copier-coller irréfléchi. Et l'auteur lui-même a découvert le problème assez tard alors que toute son attention était concentrée sur la protection contre le DoS. Ne te fais pas prendre!
2.3. Bloquer la signature
Étant donné que le hachage du bloc ne sert plus de preuve de travail et que n'importe qui peut prendre la transaction CoinStake signée à partir du bloc de quelqu'un d'autre, vous devez vérifier que le bloc a été créé par le propriétaire de Stake. Par conséquent, l'en-tête est signé avec la même clé privée que CoinStake.
2.4. Script de sortie CoinBase et CoinStake
Les mêmes scripts de sortie, ou que les gens appellent les adresses de portefeuille, sont nécessaires pour préserver la confidentialité et éviter de lier des adresses individuelles dans un portefeuille.
2.5 Quoi et où?
Il existe différentes variantes sur la façon dont ils gèrent les montants dans CoinBase et CoinStake. Logique et motivation dans un cas particulier:
- Les montants doivent être conservés séparément pour éviter même la plus petite perte de fonds utilisateur possible en raison d'erreurs de traitement.
- CoinBase conserve ses 100 confirmations, mais CoinStake peut être dépensé immédiatement, ce qui laisse bien sûr le risque de doubler les dépenses.
- l'accrochage à la profondeur des blocs contredit également la qualification d'âge pour une utilisation comme entrée de pieu.
- CoinBase et CoinStake ne devraient jamais entrer dans mempool, et toutes les transactions basées sur eux devraient être supprimées lors de la reconstruction de la chaîne.
3. Blocs complets contre les en-têtes
L'entrée d'un nœud à part entière dans le réseau commence par la synchronisation. Dans Bitcoin, la synchronisation est principalement basée sur les en-têtes de bloc, comme ils contiennent suffisamment d'informations pour une vérification préliminaire du consensus. Tout d'abord, des en-têtes relativement petits sont extraits et vérifiés par lots de jusqu'à 2000 pièces à partir d'un nœud latéral. Si la vérification initiale a réussi, tous les blocs sont extraits en parallèle de tous les nœuds connectés.
La protection contre les inondations est basée sur le fait que le nœud local compare l'en-tête le plus connu avec ce qu'il possède et demande l'ensemble de la chaîne d'en-têtes. Pendant le téléchargement, tout est vérifié par le faible coût de l'espace disque et de l'informatique. Les chaînes sont comparées en poids en fonction d'une caractéristique telle que le travail en chaîne , qui est la somme de la complexité de chaque bloc individuel. Construire une chaîne alternative aussi solide nécessitera des investissements de ressources extrêmement importants, ce qui rend les attaques peu prometteuses.
Avec PoS, cette approche ne fonctionne pas, car Pour vérifier les blocs, vous devez traiter les blocs précédents complets au moins jusqu'à l'âge minimum de Stake. Les implémentations vues par l'auteur n'ont pas commencé à être perverties, mais ont simplement refusé de travailler avec des en-têtes.
Par conséquent, l' auteur a implémenté un téléchargement opportuniste parallèle de blocs suivant les en-têtes, ce qui augmente considérablement la vitesse de synchronisation en raison de l'utilisation de toutes les connexions. Des retards mineurs se produisent uniquement si les homologues sont sur des chaînes différentes - la connexion est alors interrompue après un léger délai d'expiration comme dans le schéma standard. En tant que moins, la tendance à choisir une fausse chaîne au moment de la synchronisation.
Soit dit en passant, le client Bitcoin standard et ses fourchettes récupèrent le nombre standard minimum de connexions sortantes depuis 8 suffisamment longtemps si certaines d'entre elles échouent pour diverses raisons. Ce problème a été résolu par des connexions sortantes asynchrones.
4. Fourchettes, fentes et orphelins
Avec la compétition de construction de blocs, les chaînes alternées de 1-2 maillons sont relativement courantes. Les fourches plus longues dans les réseaux développés ne se produisent naturellement qu'avec des échecs épiques dans le consensus en raison d'une erreur de programmation ou d'une coupure Internet globale.
Même avec la séparation, il n'y a généralement pas de menace pour l'intégrité du traitement des transactions, comme lors du détachement de blocs, toutes les transactions retournent à mempool et sont déjà incluses dans d'autres blocs. Mempool est un référentiel temporaire des transactions après leur création. Mempool lui-même est enregistré sur le disque dans les versions récentes. La récompense pour le bloc est détruite. C'est pourquoi le nombre minimum de confirmations (profondeur) est fixé pour les récompenses.
Il arrive que des segments de réseau local perdent leur connexion avec le monde extérieur et continuent de miner, en supposant qu'il existe une connexion au réseau principal. Ces branches ne constituent généralement pas une menace en raison de leur faiblesse naturelle.
La principale attaque de 51% pour PoW a déjà été décrite ci-dessus - elle est extrêmement gourmande en ressources, mais pour PoS, elle devient relativement abordable. Pour cette raison, il devient techniquement possible de produire de nombreuses branches à partir de différents maillons de la chaîne. L'une des solutions classiques consiste à interdire les fourches en dessous d'une certaine profondeur.
Le principal problème d'une telle protection est l'incapacité des nœuds des segments ermites à retourner indépendamment dans le circuit principal après un redémarrage.
Par conséquent , une approche a été mise en œuvre pour interdire les fourches plus anciennes qu'une certaine période uniquement si le haut de la chaîne est assez jeune.
Avec un intervalle cible de blocs de 1 minute, le critère de l'ancienne fourche a été choisi à 1 heure, ce qui correspond approximativement à 60% des confirmations CoinBase, et le critère de jeunesse de la couronne à 15 minutes est 3+ fois supérieur au délai de blocage statistique maximum.
5. Bloquer et fractionner le hachage
Dans PoW, un hachage de bloc couvre complètement toutes les données. Il est également utilisé pour vérifier la cible. Dans PoS, Stake Hash est une valeur distincte car il faut exclure la possibilité de sa sélection. Cela ouvre la principale menace - la possibilité de produire un nombre illimité de versions différentes du bloc basé sur le même enjeu coïncident, ce qui est facile à inonder et à mettre le réseau ou ses nœuds individuels.
Les approches de défense naïve donnent lieu à des vulnérabilités de division encore plus graves. L'une de ces approches, dans différentes variantes, consiste à n'autoriser l'utilisation de la mise en jeu qu'une seule fois. Une attaque simple consiste à envoyer différents blocs à différents nœuds, ce qui crée immédiatement une séparation douce.
Il est encore plus fatal d'exacerber cela avec une interdiction du DoS, qui divisera non seulement les chaînes, mais le réseau lui-même en différents segments.
D'autres problèmes surviennent - l'impossibilité d'utiliser Stake à partir d'un bloc abandonné.
Par conséquent , la méthode de l'accélérateur a été choisie comme la solution la plus sûre - le même piquet ne peut pas être utilisé plus d'une fois par minute. La logique est simple: une attaque ne peut durer que dans l'intervalle de 1 heure (voir l'ancien fork ci-dessus), pour laquelle il est possible d'inonder pas plus de 60 blocs. Dans le meilleur des cas, sur le bloc suivant, le réseau passera déjà à un seul circuit. Dans le pire des cas, avec une attaque continue, cela arrivera dans une heure. La probabilité du pire des cas - trouver plusieurs blocs d'affilée, fond exponentiellement.
Néanmoins, il reste certains points où les nœuds sont vulnérables à une inondation modérée jusqu'au moment de la synchronisation complète .
6. Âge minimum
Pour certains, cette limitation laisse perplexe, mais elle est extrêmement importante pour la stabilité du réseau, car ce paramètre est directement lié à la longueur maximale du réseau alternatif, que le nœud local pourra vérifier sans distorsions techniques graves.
Comme mentionné précédemment, le nœud local doit traiter tous les blocs jusqu'à la limite d'âge afin de pouvoir vérifier que l'entrée de mise a) a une place pour être b) est vraiment UTXO et n'a pas été dépensée.
Vérifiez que cela n'est possible que grâce à la fonctionnalité de la soi-disant. CoinView, qui est l'état du mouvement des pièces au moment d'un bloc particulier - le haut de la chaîne principale dans la compréhension du nœud local.
La mise en œuvre d'un test à part entière de circuits alternatifs à des intervalles de temps ou même de manière spéciale enregistrée par CoinView semble peu prometteuse, car le nombre de ces chaînes alternatives est infiniment grand.
Une barre trop grande pour la limite d'âge des UTXO affecte négativement les utilisateurs qui souhaitent dépenser ou combiner une partie de leurs pièces.
Si vous spécifiez cette bordure dans la profondeur des blocs, une situation de blocage hypothétique d'un arrêt de chaîne complet en raison du fait qu'il n'y a pas d'UTXO approprié est possible. Dans le cas des unités de temps, au moins certains mouvements se produisent.
Par conséquent , un choix équilibré de 1 heure est utilisé dans d'autres réseaux en unités de temps absolues, plutôt qu'en fonction de la profondeur des blocs.
7. Quoi de mieux que N UTXO pour le montant minimum ou un UTXO avec N total?
Ici, l'analogie s'impose: ce qui est mieux, c'est un pistolet avec une précision de 0,9 ou trois canons avec une précision de 0,3, mais avec des probabilités de l'ordre de 1/2 ^ 20, les résultats de ces calculs semblent être nivelés. Une petite carte confond la maturité de la qualification.
La croyance actuelle selon laquelle de nombreuses petites transactions trouvent plus de blocs remonte probablement au moment où l'âge de la participation a été également pris en compte pour déterminer le poids. À l'époque, les vieilles petites transactions avaient vraiment beaucoup de sens.
À l'heure actuelle, sur la base d'expériences pratiques et de calculs théoriques, les groupes regroupés en grands UTXO apportent plus de blocs. De plus, moins d'UTXO nécessite moins de travail CPU. Quelqu'un prétend le contraire.
Alors pensez par vous-même.
8. Faire avancer les blocs
Les mineurs PoS surpassent naturellement un peu les temps de bloc. Cela affecte la complexité du réseau pour le pire. Le code Bitcoin standard sélectionne le premier bloc reçu, quelle que soit l'heure qui y est indiquée. La plupart des implémentations PoS font de même.
Par conséquent, la logique du mineur PoS a été modifiée de manière à commencer la sélection à partir du temps moyen des blocs si le temps du bloc actuel avance. En même temps, avant de comparer l'ordre, les nœuds comparent le temps indiqué des blocs. Le mineur PoS envoie le bloc trouvé au réseau même s'il voit qu'il génère une fourchette.
De cette façon, le réseau est également protégé contre les blocs hypothétiques envoyés prématurément dont l'entrée de mise ne peut pas être utilisée dans les 60 secondes suivantes avec le même modificateur de mise en raison de la protection DoS. Comme une double punition pour avoir triché avec le temps.
9. Une petite liste de contrôle
- L'entrée de piquet doit être un UTXO valide avant le point de fork:
- dans le cas de la chaîne principale, le point de fourche est la pointe,
- dans le cas d'un circuit alternatif - UTXO après le point de fourche peut conduire à l'auto-DoS lors de la commutation,
- UTXO ne devrait pas être dans mempool par lui-même.
- N'acceptez pas CoinStake dans mempool lors de la reconstruction du circuit principal:
- la même chose se produit avec CoinBase,
- cela peut détruire la chaîne de transaction (peu probable).
- N'acceptez pas les fourches d'anciens blocs si le sommet est bien vivant.
- La limite d'âge en unités de temps absolues pour l'entrée des enjeux est nécessaire pour la stabilité et la sécurité.
- Stake Hash ne devrait changer qu'à partir du temps de blocage.
- Le modificateur Stake ne doit pas être lié au bloc Stake Input.
- Travailler avec des en-têtes de bloc nécessite un traitement spécial sur le réseau et pendant la réindexation.
- CoinStake sont enregistrés dans le portefeuille local et nécessitent quelques modifications pour l'affichage des orfans correctement.
- Les mineurs PoS ont probablement assez de montants et doivent être finalisés avec un fichier.
- La réindexation doit être améliorée, car Il fonctionne par analogie avec les en-têtes - tout d'abord, il charge et vérifie uniquement l'index des blocs, puis essaie uniquement de traiter les blocs.
- Si la transition vers PoS n'est pas codée en dur, mais via spork, vous devez l'attraper au démarrage, car les sporks ne sont pas enregistrées.
- Les points de contrôle dans Dash et Bitcoin sont presque une imposture et nécessitent une révision très sérieuse.
- Si Dash Fork est jusqu'à la version 0.13, il y a des problèmes avec le traitement des données de masternode dans le mode utilisateur simple.
- Avec un redémarrage fréquent du client, la vue du réseau est déformée.
- Il est préférable d'ignorer simplement le cache si vous exécutez en mode graphique.
- Modifiez la sélection du meilleur bloc en tenant compte de la durée du bloc.
- Bitcoin .
- mempool CoinStake .
. mainnet PoW , , PoS, . PoS Ethereum Casper'.
GPU - — ethminer'. 150-200 GH (ethash). - PoS .
PoS PIVX 2.x " ". - PIVX , , . , PIVX 2.x . Dash 0.12 Bitcoin'.
, PoS . , , .
. . whitepaper -.
PoS PIVX Bitcoin/Dash. CoinStake . PoS .
, Stake Modifier Stake Hash , Stake Input . - , - PIVX .
— . :
- .
- .
- — .. , .
- , - , .
. spork' , .
, . spork' .
PoS
, - . spork, , .
, .. . , .
testnet, .
testnet 3 1 mainnet, .
PoW , PoS - , 1e6 PoW.
. mainnet Stake Input.
.
PoS
X spork PoS . - , .
. , . .
, , .
Stake Modifier . . PIVX - … , , Ethereum, .
Conclusion
- , . , PoS , . .
: - .
GitHub