Minage
Ce document vise à faciliter l'intégration d'Alephium pour les piscines de minage et les mineurs. Il comprend principalement:
- le protocole de communication entre la piscine de minage et le nœud complet
- la manière dont le mineur calcule le hachage de bloc en fonction des travaux de minage
En ce qui concerne la mise en œuvre du protocole de communication entre la piscine de minage et les mineurs, vous pouvez vous référer au protocole Stratum ici. Notez que les piscines de minage ne suivent pas exactement ce protocole.
Dans ce document, je vais utiliser le code de mining-pool et gpu-miner comme référence.
Piscine de minage
La piscine de minage doit se connecter au nœud complet Alephium pour obtenir des travaux de minage,
et le serveur API de minage par défaut est localhost:10973
.
La piscine de minage communique avec le nœud complet via un protocole binaire, le format du message est le suivant:
Obtention des travaux à partir du nœud complet
Chaque fois que le nœud complet reçoit un nouveau bloc, il envoie un message Jobs
à la piscine de minage.
Vous pouvez également définir l'intervalle de temps dans la
configuration de minage
du nœud complet pour envoyer des messages Jobs
lorsqu'il n'y a pas de nouveaux blocs.
Étant donné qu'il y a maintenant 16 chaînes dans Alephium, il y aura 16 modèles de blocs dans chaque message Jobs
.
Et le modèle de bloc se compose des champs suivants:
fromGroup
ettoGroup
: l'index de la chaîne du modèle de bloc.headerBlob
: es données binaires sérialisées de l'Entête de bloc, à l'exclusion des 24 premiers octets (nonce).txsBlob
: les données binaires sérialisées des transactions.targetBlob
: les données binaires sérialisées de la Cible.
Vous pouvez vous référer au code fourni ici pour en savoir plus sur le format du message Jobs et comment analyser le message Jobs
.
Une fois que la piscine de minage reçoit le message Jobs
du nœud complet,
elle peut envoyer les travaux de minage aux mineurs en fonction de leur taux de hachage.
Pour chaque chaîne, le calcul du nonce ne nécessite que les champs targetBlob
et headerBlob
.
Par conséquent, la piscine de minage peut économiser de la bande passante en excluant le champ txsBlob
lors de l'envoi des travaux de minage aux mineurs. Vous pouvez vous référer au code fourni
ici.
Soumission des blocs au nœud complet
Une fois que la piscine de minage reçoit un nonce
valide du mineur, elle peut envoyer le bloc au nœud complet,
où le bloc est composé de nonce, headerBlob
et txsBlob
, vous pouvez vous référer au code fourni
ici.
Ensuite, vous pouvez vous référer au code fourni ici
pour construire un message SubmitBlock
valide et envoyer ce message au nœud complet.
Après que le nœud complet a vérifié le bloc, il enverra un message SubmitBlockResult
pour indiquer à la piscine
de minage si le bloc est valide, vous pouvez vous référer au code fourni
ici pour analyser le message SubmitBlockResult
´.
Mineur
Calcul du hachage du bloc
Dans Alephium, la taille du nonce
est de 24 octets, et le hachage du bloc est: blake3(blake3(serialize(blockHeader))
.
Comme mentionné précédemment, blockBlob
dans chaque travail est les données binaires sérialisées de BlockHeader
excluant le champ nonce
.
Par conséquent, lorsque le mineur calcule le hachage du bloc, il doit préfixer le nonce à l'avant du headerBlob
,
vous pouvez vous référer au code fourni here et
here.
Vérification de l'index de chaîne
En plus de vérifier la cible, le mineur doit également vérifier l'index de chaîne du bloc car Alephium encode l'index de chaîne dans le hachage du bloc. Vous pouvez vous référer au code fourni ici pour vérifier si l'index de chaîne du hachage du bloc est correct.