
Les développeurs de la fourchette Litecoin Cash ont présenté une préimpression du document technique «
The Hive: Agent-based Mining in Litecoin Cash », dans lequel ils ont décrit leur proposition de protéger la blockchain de crypto-monnaie basée sur l'algorithme de preuve de travail contre une «attaque de 51%». Leur solution combine l'exploitation minière en utilisant des dispositifs ASIC vieillissants (SHA-256) et l'exploitation minière virtuelle démocratique en utilisant des «abeilles actives» (HiveMine). Dans le cas d'une mise en œuvre correcte de la blockchain, LCC résoudra l'un des plus gros problèmes des projets de blockchain modernes (de Bitcoin à Ethereum): la menace d'une attaque lorsque plus de la moitié de la puissance totale du réseau est concentrée entre les mains de l'attaquant.
51% Problème d'attaque
Ceux qui surveillent le marché des crypto-monnaies ne pouvaient manquer de noter la récente flambée
d'attaques à
51% sur des projets PoW relativement petits (preuve de travail - "preuve de travail effectuée"), lorsque les attaquants ont réécrit les transactions et transféré les fonds le plus rapidement possible via les échanges. «Relatif» dans ce cas signifie qu'une petite fraction d'appareils prenant en charge la sécurité cryptographique d'une grande blockchain (Bitcoin ou Ethereum, par exemple) suffira à briser le consensus d'une petite blockchain travaillant sur le même algorithme de hachage (Bitcoin Cash ou Bitcoin Gold, respectivement) .
Dans le cas des crypto-monnaies qui prennent l'algorithme SHA-256 (LCC ou BCH) comme base de cryptage, le risque est aggravé par le fait que la crypto-monnaie la plus grande et la plus sécurisée au monde fonctionne sur le même algorithme - Bitcoin (BTC).
Dans cet article, nous nous concentrerons sur le modèle mathématique de protection contre les attaques à 51% et soulignerons superficiellement les principaux termes et concepts associés utilisés dans la cryptographie des blockchains.
Introduction à l'exploitation minière élevée
Dans le schéma de sécurité classique de la blockchain PoW, les mineurs se font concurrence en calculant un grand nombre de hachages de blocs potentiels pour en trouver un qui répond aux conditions de complexité spécifiées par le consensus du réseau. Si la complexité est nulle et que tout hachage est accepté par le réseau comme valide, la preuve de travail ne fonctionnera pas et n'importe quel nœud du réseau peut facilement extraire des blocs.
À première vue, ce n'est pas mal: l'exploitation minière deviendra démocratique et peu coûteuse en énergie. Mais dans la pratique, tout le monde va extraire des blocs bon marché et les pousser dans le réseau, ce qui signifie qu'il y aura de nombreux candidats pour la suite de la chaîne de blocs. Comme les mineurs ne comprendront plus sur quel bloc construire la suite de la blockchain, de nombreuses chaînes orphelines apparaîtront. Il y aura du chaos, qui a été observé par PoW-coins avec un algorithme inadéquat pour ajuster la complexité de l'exploitation minière.
Si la complexité est nulle et que la production du bloc n'entraînera aucun coût, personne ne pourra déterminer quelles chaînes candidates valent le plus, ce qui signifie qu'il n'y aura pas de priorité. Les mineurs pourront également travailler sur différentes chaînes sans rien perdre.
Cette expérience de réflexion démontre simplement que l'objectif principal de l'algorithme de preuve de travail, de preuve d'enjeu ou généralement de preuve de quoi que ce soit est de fournir au réseau un moyen déterministe de déterminer le droit à l'extraction, à la frappe ou à la forge d'un bloc, avec lequel les autres participants seront d'accord . De plus, une autre condition importante pour tous les demandeurs de blocs est de ne pas travailler sur plusieurs chaînes simultanément en toute impunité. Dans le système de preuve de mise, une telle approche est sanctionnée par la privation partielle ou totale d'une mise.
L'exploitation minière élevée est une forme alternative de lutte contre les blocs lorsque le droit de produire un bloc est garanti par un agent travaillant pour le compte de l'utilisateur. Ces agents - les «abeilles qui travaillent» - sont sur la blockchain elle-même. Ils sont complètement décentralisés et sont créés lorsqu'un utilisateur effectue une transaction spéciale pour créer un agent.
Après la création, les abeilles actives commencent à agir comme des dispositifs virtuels pour l'exploitation minière (rig) et leurs propriétaires deviennent des "apiculteurs". Lorsque les abeilles ouvrières réussissent à obtenir le bloc, la rémunération du bloc (y compris les commissions incluses dans le bloc) est versée à l'apiculteur. Les abeilles qui travaillent nécessitent très peu d'énergie et n'ont pas besoin d'équipement spécialisé pour la production de blocs. De plus, leur durée de vie est limitée et la création d'une abeille est une action spéculative à un certain prix; cela empêche les tentatives de travailler sur plusieurs chaînes en même temps. Le succès d'une abeille individuelle dépend uniquement de la population d'abeilles vivant dans l'ensemble du réseau. Certaines abeilles ne trouveront jamais de bloc, tandis que d'autres auront une chance disproportionnée (similaire à l'exploitation en solo).
Fig. 1: une abeille active est ajoutée à la blockchain via une transaction de création d'abeilles (BCT) et des blocs de mines au cours de sa durée de vieCréation d'agents (abeilles ouvrières)
Pour créer une abeille qui travaille, l'utilisateur envoie la transaction à une adresse spéciale "morte", par exemple:
CReateLitecoinCashWorkerBeeXYs19YQ
. Notez que tout le monde utilise la même adresse pour créer l'abeille. Cette adresse est analysée comme existante et correcte, mais personne n'a de clé privée; L'utilitaire vanitygen détermine que la recherche d'une clé privée à l'aide de cœurs 24 * 2 GHz prendra environ 1,7 * 10 ^ 31 ans (avec 50% de chances de succès).
Une transaction créant une abeille doit avoir au moins deux sorties. Le premier définit une redevance fixe pour la création d'une abeille, qui est envoyée à une adresse inaccessible. Bien que le prix de la création d'une abeille soit déterminé de manière dynamique, il est supposé qu'il s'agira d'un pourcentage de la récompense en bloc. Ce calcul inclut le coût minimum, de sorte qu'au moment où toutes les pièces sont extraites, il est logique d'utiliser une extraction élevée pour recevoir des frais de transaction.
La deuxième conclusion a un coût nul, mais spécifie l'adresse de base, qui recevra une récompense pour le bloc trouvé par l'abeille à l'avenir. Vous pouvez l'appeler "la future adresse de l'apiculteur". S'il le souhaite, l'utilisateur lui-même peut le clarifier; par défaut, une nouvelle adresse sera générée à chaque fois dans son portefeuille.
Un exemple:
"vout": [ { // Bee creation fee "addr": "CReateLitecoinCashWorkerBeeXYs19YQ" "value": 1.0000000 }, { // Address to receive block rewards for any blocks this bee mines "addr": "CTrdm8YDfjmFJwFnKbvNZ9NYznhMqrNgFR" "value": 0.0000000 }, { // Change address for change from creation fee "addr": "Cd6CRuWCu6p4NLR6XG7BKyC8hzvEoYuKbn" "value": 123.5274346 } ]
Les abeilles arrivent à maturité et deviennent capables de produire des blocs après l'apparition de 576 blocs sur la chaîne de blocs à partir du moment où les abeilles ont été créées. Il s'agit du nombre attendu de nouveaux blocs ajoutés à la blockchain Litecoin Cash en 24 heures. Une fois les abeilles matures, il y a 4032 blocs (environ 1 semaine) et recherchez les blocs, puis ils meurent.
L'abeille est créée dans un portefeuille QT. Quelque chose comme ça ressemble à ceci:
Fig. 2: Disposition du portefeuille LCC avec des abeilles qui travaillentLes abeilles au travail: recherche de blocs
Par exemple, supposons que la hauteur de la chaîne de blocs = 1000, et le réseau devrait déterminer quelle abeille est affectée pour trouver le bloc 1001. L'apiculteur d'Alice a maintenant 4 abeilles (créées entre 576 et 4608 blocs).
Lorsque le bloc 1000 apparaît, le portefeuille d'Alice calcule deux valeurs.
Le premier est une valeur déterministe imprévisible mais facilement vérifiable. Cela est facile à faire en ajoutant des hachages de blocs à différentes profondeurs (codées en dur) entre, disons, 0 et 500000 blocs, en veillant à ce que notre valeur aléatoire soit bien enracinée dans la blockchain:
string deterministicRandString = blocks[blockHeight].hash + blocks[blockHeight-13].hash + blocks[blockHeight-173].hash + blocks[blockHeight-1363].hash + blocks[blockHeight-27363].hash + blocks[blockHeight-496393].hash;
Ensuite, son portefeuille calcule le hachage cible de l'abeille,
beeTargetHash
. Cette valeur est déterminée par la moyenne mobile exponentielle avec une plage dynamique très élevée, qui définit
beeTargetHash
sorte que pour une population d'abeilles donnée, la fréquence des blocs obtenus pendant le processus d'extraction soit déterminée. Sur le plan positif, plus le nombre de blocs PoW a été extrait depuis le dernier bloc de mine élevé, plus
beeTargetHash
plus élevé (plus simple). L'algorithme est défini comme suit; les valeurs de
maxTarget
,
emaWindowsSize
et
emaDesiredSpacing
seront déterminées pendant la simulation.
beeHashTarget = previousBeeHashTarget (default to highest (easiest) target maxTarget) numPowBlocks = number of pow blocks since the previous hive mined block; emaInterval = emaWindowSize / emaDesiredSpacing; beeHashTarget *= (interval - 1) * emaDesiredSpacing + numPowBlocks + numPowBlocks; beeHashTarget /= (interval + 1) * emaDesiredSpacing;
beeHashTarget
et
beeHashTarget
peuvent être calculés par n'importe quel nœud du réseau.
Le portefeuille d'Alice passe maintenant chacune de ses abeilles vivantes à travers une chaîne aléatoire déterministe, combinant les transactions BCT des abeilles et les hachant pour obtenir un nouveau hachage - le hache d'abeille d'une abeille individuelle. Par conséquent, chaque abeille génère un hachage par bloc. Ce hachage est similaire au meilleur hachage généré par une plate-forme d'extraction PoW au cours de la même période.
hash beeHash = sha256(deterministicRandString + bee.creationTransaction.ID)
Étant donné que le portefeuille d'Alice suit les abeilles, dont chacune calcule le
beeHash
, il conserve un enregistrement des meilleurs (plus bas) hachages découverts. Si, en conséquence, le meilleur hachage découvert par le portefeuille d'Alice remplit la condition
beeHash < beeTargetHash
, Alice obtient le droit d'ajouter un bloc.
Supposons qu'Alice ait une abeille vivante, dont le hachage est inférieur à la cible, et l'identifiant de transaction BCT d'une abeille réussie est le suivant:
0f6953f0a0816483c71ae3df45650a997e678588a315d72e9ae06e6a3f1c1841.
Sachant que le portefeuille d'Alice a le droit de signer un bloc, le réseau produit un bloc avec une transaction spéciale avec deux sorties:
"vout": [ { // Zero-value output identifies the bee and proves it's really minting for Alice "value": 0, "n": 0, "scriptPubKey": { "asm": "OP_RETURN OP_BEE 0f6953f0a0816483c71ae3df45650a997e678588a315d72e9ae06e6a3f1c1841 IH3Emz49KJeRbw0q4R48pD6GWPQtvHCxLeQOxxH+yv14Tn5KzUFIXBe9Td8EHudejzebMYt/XpusENzNkGM/a4I=" } }, { // Block reward (subsidy + fees) - must pay to bee's correct coinbase address "value": 250.0001125, "n": 1, "scriptPubKey": { "addresses": [ "CTrdm8YDfjmFJwFnKbvNZ9NYznhMqrNgFR" ] } }
vout[0]
est une sortie à valeur nulle qui ne peut pas être dépensée. Il est utilisé à la fois pour identifier l'abeille qui a obtenu le bloc et pour prouver qu'elle l'a obtenu pour Alice.
vout[1]
est la sortie qui verse à Alice une récompense en bloc.
Confirmation de blocage
Le portefeuille de Bob, recevant le bloc d'Alice, doit maintenant s'assurer qu'il satisfait au consensus. Tout d'abord, il s'assure que la transaction comprend deux entrées, dont la première est zéro, et que le script commence par
OP_RETURN OP_BEE
. Il récupère ensuite l'identifiant de transaction d'abeille d'Alice:
0f6953f0a0816483c71ae3df45650a997e678588a315d72e9ae06e6a3f1c1841.
Digression: Puisque la transaction de création d'une abeille est transférée à une adresse inaccessible, la sortie des transactions non dépensées (UTXO) y reste. Par conséquent, le portefeuille de Bob n'a pas besoin d'activer l'option de ligne de commande txindex
(qui indexe complètement toutes les transactions en raison d'une vérification retardée et d'une utilisation accrue du disque) pour vérifier facilement les sorties BCT d'Alice. En raison de l'utilisation d'UTXO, le portefeuille QT n'a pas besoin de bases de données ou de modifications pour prendre en charge l'extraction élevée. L'onglet abeilles s'intègre également dynamiquement.
En validant le bloc de mine élevé, le portefeuille de Bob implémente l'équivalent de RPC (appel de procédure à distance):
gettxout 0f6953f0a0816483c71ae3df45650a997e678588a315d72e9ae06e6a3f1c1841 0
Cela lui donne la première sortie BTC,
vout [0]
, et garantit que 1) la profondeur de la transaction se situe dans la plage de la durée de vie de l'abeille; 2) une commission a été payée pour la création d'une abeille; 3) il a été envoyé à la bonne adresse sans issue.
Si la vérification réussit, le portefeuille de Bob produira:
gettxout 0f6953f0a0816483c71ae3df45650a997e678588a315d72e9ae06e6a3f1c1841 1
On obtient ainsi la deuxième sortie de BCT,
vout [1]
, confirmant que 1) la valeur est nulle; 2) l'adresse est la même que l'adresse de réception du transfert de pièces dans le bloc (dans l'exemple
CTrdm8YDfjmFJwFnKbvNZ9NYznhMqrNgFR
).
La vérification suivante vérifie la signature du message de la dernière partie de
vout [0]
. Le message doit contenir le numéro de bloc actuel, signé par l'adresse de réception du transfert de pièces, donc le portefeuille de Bob produit:
verifymessage CTrdm8YDfjmFJwFnKbvNZ9NYznhMqrNgFR "IH3Emz49KJeRbw0q4R48pD6GWPQtvHCxLeQOxxH+yv14Tn5KzUFIXBe9Td8EHudejzebMYt/XpusENzNkGM/a 4I=" "1001"
Enfin, Bob calcule
deterministicRandString
et
beeHashTarget
pour le bloc actuel, puis calcule le
beeHash
d'Alice et le
beeHash
à
beeHashTarget
. Si tous les contrôles sont réussis, le bloc est considéré comme valide et vérifié. Le processus de validation des blocs est rapide et ne nécessite pas de vérification coûteuse des blocs historiques.
Jumelage Hi-Mining et PoW Mining
Il est supposé que l'extraction élevée n'est pas la seule méthode pour assurer la sécurité du réseau. Les développeurs de Litecoin Cash veulent non seulement sauver la communauté minière, mais aussi ne pas interférer avec elle de quelque manière que ce soit. L'exploitation minière élevée doit être associée à l'exploitation minière PoW sur une chaîne de blocs.
Actuellement, le fonctionnement du circuit est calculé comme suit:

C'est-à-dire que le fonctionnement du circuit s'accumule en fonction de la complexité dans chaque bloc du circuit. Les développeurs proposent de modifier cette définition comme suit:

Ainsi, chaque bloc de ruche-mine sera récompensé en fonction de la quantité de travail conclue dans le bloc PoW précédent, et la constante
k
est déterminée expérimentalement.
Conclusion: l'exploitation minière élevée comme défense contre l'attaque 51%
Selon Jane 'Tanner' Craig, développeur en chef de Litecoin Cash, l'idée de HiveMine n'est pas seulement de fournir une protection fiable contre les attaques à 51%, mais aussi de démocratiser et de décentraliser l'exploitation minière. Contrairement aux chaînes de blocs PoS, lorsque «les riches s'enrichissent», accumulant leur part, HiveMine a encore besoin du coût de création d'une abeille qui peut ne pas être rentable. L'exploitation minière basée sur les agents satisfait les trois tâches principales de l'équipe: compliquer considérablement l'attaque de 51%, démocratiser l'exploitation minière et la liberté des mineurs à l'aide de l'algorithme SHA-256, qui garantit une haute sécurité du même réseau Bitcoin. Pour une attaque réussie, un attaquant devra prendre plus de 51% de la puissance du réseau, ainsi que 51% de la population d'abeilles du réseau, et étant donné le processus de création d'abeilles, cela deviendra immédiatement évident.
Selon Craig, après avoir testé et implémenté le modèle HiveMine dans le réseau Litecoin Cash, qui n'est pas fourni avec le même taux de hachage SHA-256 que le même Bitcoin Cash, il sera néanmoins plus rapide et plus fiable que les réseaux Bitcoin Cash ou Bitcoin. .
Références:
1. «
The Hive: Agent-based Mining in Litecoin Cash », Iain CRAIG, Sebastian CLARKE, Michał WYSZYŃSKI et Federico DE GONZÁLEZ-SOLER. (2018)