Aller au contenu
Financial Context Wiki

Minage égoïste

L'exploitation minière égoïste retient stratégiquement des blocs de preuve de travail valides et publie une branche privée pour faire perdre aux mineurs concurrents davantage de travail accepté. Analysez la stratégie exacte, la part de hachage, le comportement en cas d'égalité, les récompenses, l'ajustement de la difficulté, les preuves et les mesures d'atténuation sans traiter un seuil de modèle comme un fait du réseau.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Le minage égoïste est une famille de politiques stratégiques de minage par preuve de travail dans lesquelles un mineur ou une coalition coordonnée retient un ou plusieurs blocs valides, étend en privé une branche et publie sélectivement des blocs dans le but de faire dépenser aux autres mineurs une plus grande fraction de leur travail sur des branches qui ne seront pas acceptées. L’objectif est généralement modélisé comme l’augmentation de la part à long terme de la coalition dans les récompenses acceptées par rapport à sa part compatible de hachage, et non comme la création de preuve de travail à partir de rien.

La stratégie classique Eyal-Sirer, souvent appelée SM1, suit l’avance privée de la coalition. À une avance nulle, un bloc de la coalition est retenu. À une avance d’un, un autre bloc de la coalition prolonge la branche secrète, tandis qu’un bloc public concurrent déclenche la publication pour créer une égalité visible. Si l’avance privée est d’au moins deux, la publication est programmée pour dépasser ou rester en avance par rapport à la branche publique. Chaque bloc publié doit toujours satisfaire aux règles de validité et de preuve de travail du réseau.

Deux paramètres de modèle sont communément désignés alpha et gamma. alpha est la fraction du taux de découverte de blocs compatible de la coalition. Dans l’abstraction originale du réseau instantané, gamma est la fraction de puissance de hachage non appartenant à la coalition qui mine sur la branche de la coalition lors d’une égalité publique. Ce n’est pas simplement la latence, la fraction de nœuds qui ont vu un bloc en premier, ou une propriété permanente d’un pool de minage. La topologie, la politique de relais, le temps de validation des blocs, le rafraîchissement des modèles, le contenu des frais et les stratégies des autres mineurs peuvent tous modifier le comportement effectif en cas d’égalité.

Il n’existe pas de seuil universel pour le minage égoïste. Les valeurs familières d’un tiers ou d’un quart proviennent d’un modèle particulier à récompense constante, à deux parties, stationnaire, basé sur la plus longue chaîne, et d’une stratégie spécifiée. Des travaux ultérieurs étendent l’espace des stratégies, incluent le délai de propagation, les frais variables, plusieurs coalitions, les conditions d’éclipse, et différents algorithmes d’ajustement de la difficulté. Un seuil issu d’un modèle est un résultat conditionnel, non une limite de sécurité mesurée pour chaque réseau de preuve de travail.

L’exploitation minière égoïste n’est pas non plus synonyme de tout type de blocage de bloc. Un participant à un pool peut soumettre des parts partielles tout en cachant des solutions complètes pour saboter un pool ; c’est une attaque différente au niveau du pool. La publication retardée accidentelle, les forks temporaires, les attaques de blocs invalides, la censure, le fee sniping, la sous-enchère, la double dépense, la réorganisation majoritaire et les variantes de minage obstiné se chevauchent sur certains mécanismes mais nécessitent des définitions et des preuves distinctes.

Comment analyser le minage égoïste

  1. Fixez le réseau et l’objectif. Consignez le bloc genesis, le client et les activations, l’algorithme de preuve de travail, le choix de branche et le départage, la cible et l’ajustement de difficulté, la maturité, la subvention, les frais, les blocs stale, l’observateur et la période ; précisez si l’objectif est le revenu accepté relatif, le revenu par temps réel, le bénéfice net des coûts, la censure ou la réorganisation.
  2. Spécifiez la stratégie comme une machine d’état. Définissez les branches publiques et privées, le travail cumulé, l’avance privée non publiée, les actions attendre, adopter, égaler, dépasser ou publier, la coordination de la coalition, la profondeur maximale retenue et le comportement après chaque découverte. « Minage égoïste » ne constitue pas à lui seul un algorithme complet.
  3. Définir les paramètres de hachage et de propagation. Lier alpha au taux effectif de détection de blocs compatibles sur le même intervalle. Définir exactement comment gamma ou un modèle de délai plus sophistiqué répartit le travail non lié à une coalition pendant chaque course ; inclure la topologie de relais, la validation, le changement de modèle, le comportement des blocs compacts, les partitions et la capacité d’éclipse lorsque pertinent.
  4. Modélisez séparément récompenses acceptées et temps. Suivez les blocs acceptés de la coalition et des autres mineurs, les blocs valides stale ou abandonnés, la subvention, les frais, les récompenses ommer ou d’inclusion, la maturité, le temps de découverte, la croissance de la chaîne publique et les périodes de difficulté. La part acceptée relative n’est pas automatiquement un revenu horaire ni un bénéfice.
  5. Résolvez et validez le modèle indiqué. Utilisez une analyse exacte Markov, un processus de décision borné Markov, ou une simulation d’événements reproductible appropriée à la stratégie. Signalez la troncature, la convergence, la mise en chauffe, les graines, les intervalles de confiance, la sensibilité, et une base de référence de minage honnête ; reproduisez indépendamment les petites transitions d’état à la main.
  6. Tester les preuves et les alternatives. Préserver les en-têtes vus en premier, les heures d’arrivée au niveau des pairs, les branches concurrentes, le travail, l’attribution de coinbase ou de paiement, les modèles, les frais, les horodatages et les changements de pool. Comparer la rétention avec la variance ordinaire Poisson, le délai de propagation, les pannes, les défauts logiciels, les partitions, le sniping de frais et l’erreur d’étiquette. Les données de chaîne publique seules peuvent ne pas révéler les blocs perdants non publiés.
  7. Évaluez les contrôles sans exagérer. Testez des relais plus rapides et diversifiés, les améliorations de validation, les règles de départage, les changements de fork-choice ou de récompense, les algorithmes de difficulté, la concentration des pools, la mobilité des mineurs, la surveillance, la réponse et la politique de confirmation. Chaque contrôle peut modifier les incitations ou l’observabilité et créer de nouvelles stratégies ; réanalysez toutes les règles du réseau.

La sortie doit distinguer la définition de la stratégie, le résultat du modèle, le résultat de la simulation, les preuves observées du réseau et la conclusion opérationnelle. Aucun ne peut se substituer silencieusement à un autre.

Exemples travaillés

1. Une trace menée en privé et une course publique

Soit une coalition ayant alpha = 0.30. En partant d’un indice public, supposons que les découvertes suivantes soient coalition, coalition, puis non-coalition. La probabilité de ce préfixe indépendant exact dans le modèle simplifié est :

0.30 * 0.30 * 0.70 = 0.063 = 6.3%

La coalition peut publier sa branche à deux blocs contre la branche publique à un bloc ; si les deux branches sont valides et que chaque bloc représente un travail égal, sa branche l’emporte et le bloc concurrent devient obsolète. Cette trace donne à la coalition deux blocs acceptés, mais elle n’établit pas la rentabilité à long terme car toutes les autres traces, branches privées échouées, temps écoulé, frais et règles d’ajustement comptent également.

Si, en revanche, la séquence atteint une égalité publique d’un bloc, définissez gamma = 0.50. Conditionnellement à la prochaine découverte résolvant cette course, la coalition la trouve avec une probabilité de 0.30 et obtient deux blocs acceptés ; les mineurs non membres de la coalition étendent la branche de la coalition avec une probabilité de 0.70 * 0.50 et la coalition obtient un bloc ; l’autre résultat lui rapporte zéro. Les blocs attendus conditionnels de la coalition sont :

0.30 * 2 + 0.70 * 0.50 * 1 = 0.95

Il y a deux blocs acceptés après la résolution dans chaque branche de cette course jouet, donc la part conditionnelle est 0.95 / 2 = 47.5%. Comparer cet événement sélectionné directement avec 30% est un biais de sélection ; un modèle d’état à long terme doit inclure la probabilité et le coût d’atteindre la course.

2. Pourquoi le seuil classique est conditionnel

Pour SM1 dans l’abstraction à récompense constante originale avec alpha < 0.50, le seuil de répartition du hash rapporté pour l’équilibre est :

alpha* = (1 - gamma) / (3 - 2 * gamma)

Chez gamma = 0, le seuil est 1 / 3 = 33.3333%. Chez gamma = 0.50, il est 0.50 / 2 = 25%. Chez gamma = 0.90, il est 0.10 / 1.20 = 8.3333%. Ces valeurs montrent une sensibilité à l’hypothèse d’égalité ; elles ne signifient pas qu’un réseau mesuré avec huit, 25 ou 34 pour cent de part de hachage soit nécessairement rentable, sûr, malveillant ou contrôlé par un seul acteur. L’optimisation de la stratégie, le délai réel, la variance des récompenses, les frais, la difficulté et les coûts modifient la question.

3. La part relative acceptée n’est pas le revenu immédiat du moment

Supposons qu’un intervalle simulé contienne des découvertes de blocs 1,000. Une coalition ayant une part de hachage modélisée 28% obtient 270 blocs acceptés, les autres mineurs obtiennent 650, et 80 découvertes valides sont abandonnées. La part de la coalition dans les blocs acceptés est :

270 / (270 + 650) = 270 / 920 = 29.3478%

C’est 1.3478 points de pourcentage au-dessus de sa part de hachage. Pourtant, un benchmark proportionnel honnête sur les mêmes 1,000 découvertes est de 280 blocs de coalition, donc son nombre accepté avant toute normalisation du temps est 10 de moins, ou 10 / 280 = 3.5714% en dessous de ce benchmark. Un ajustement de difficulté ultérieur peut restaurer la fréquence des blocs de la chaîne publique et modifier la récompense par temps réel, mais seulement sous ses hypothèses exactes de fenêtre, d’horodatage, de limitation, de taux de hachage, de frais et de stratégie continue. La part relative seule ne prouve pas un profit immédiat.

4. Une anomalie de partage de bloc n’est pas une preuve d’attribution

Suppose une part de coalition estimée indépendamment de p = 0.30 et, uniquement comme modèle nul approximatif, n = 10,000 blocs acceptés indépendamment. Le nombre attendu est n * p = 3,000, et l’écart type binomial est :

sqrt(10,000 * 0.30 * 0.70) = 45.8258 blocks

Un compte attribué de 3,080 donne z = (3,080 - 3,000) / 45.8258 = 1.7457. Ce n’est pas un détecteur de selfish mining. Les blocs acceptés ne sont pas nécessairement indépendants avec un p fixe ; les estimations de hachage et les étiquettes de pool comportent des erreurs ; la sélection des frais, les pannes, la chance, la propagation et les changements peuvent modifier les comptes ; et les blocs privés non réussis peuvent ne jamais atteindre l’observateur. L’investigation nécessite des preuves de en-têtes concurrents et d’arrivée des pairs ainsi qu’un modèle causal déclaré, pas seulement un score z des parts de blocs.

Risques et échecs de révision

Erreurs de modèle et de protocole

  • Stratégie non définie : SM1, variantes obstinées, politiques optimales, retenue consciente des frais, et sabotage de pool prennent différentes actions. Publiez un tableau complet des états et des actions.
  • Hauteur remplacée par le travail cumulé : Le choix de la branche suit les règles du réseau concernant le travail valide, et non une comparaison universelle du nombre de blocs. Reconstruisez les deux branches et le travail exact.
  • Réclamation de seuil universel : Un tiers, un quart ou toute autre valeur dépend d’un modèle et d’un objectif. Indiquez l’équation, le domaine, la stratégie et les hypothèses.
  • Mauvaise lecture de gamma : Il s’agit d’une allocation modélisée de l’exploitation minière hors coalition pendant une course, et non d’un score de latence global directement observé. Définissez comment elle est estimée ou simulée.
  • Hypothèse de récompense constante égale : Les subventions , les frais hétérogènes, les récompenses aux oncles, la maturité et la sélection des transactions peuvent modifier les incitations. Modélisez le vecteur de récompense réel.
  • Ignorer l’ajustement de difficulté : La croissance perdue de la chaîne publique peut affecter la difficulté ultérieure et les revenus en temps réel. Simulez l’époque exacte, les horodatages, les limites et la réponse du taux de hachage.
  • Appeler une politique optimale : Un MDP borné optimum dépend de son état, action, récompense, délai et choix de troncature. Signalez les bornes et la sensibilité plutôt que l’optimalité universelle.

Preuves et erreurs de sécurité

  • Confusion entre blocage de pool et retenue : Cacher une solution complète d’un pool tout en soumettant des parts diffère de l’extension privée d’une branche de consensus. Gardez les participants et les mécanismes de récompense séparés.
  • Confondre le double usage ou le contrôle majoritaire : La manipulation des récompenses peut se produire sans paiement contradictoire, tandis que les objectifs de réorganisation et de censure nécessitent un état supplémentaire et des preuves.
  • Traiter une retenue valide comme une acceptation invalide-bloc : Les blocs publiés de la coalition sont toujours soumis à la preuve de travail ordinaire et à la validation des transactions. La part de hachage ne peut pas autoriser des transitions d’état invalides.
  • Inférence de gagnant consécutif : Poisson l’extraction produit naturellement des séquences. Utilisez de longues fenêtres, l’incertitude, des branches concurrentes, le timing d’arrivée, des modèles et des hypothèses alternatives.
  • Certitude du taux périmé : La couverture des observateurs , la politique de relais, la topologie, les courses accidentelles, les pannes et les blocs perdants cachés biaisent les mesures obsolètes. Préservez les limitations du point de vue.
  • Certitude de l’étiquette du pool : Les étiquettes Coinbase, les adresses de paiement, les empreintes de modèle, les contributeurs au hachage et le contrôle effectif ne correspondent pas parfaitement. Versionnez l’attribution et indiquez son incertitude.
  • En ignorant les cloisons et les effets d’éclipse : Les vues réseau restreintes peuvent modifier les courses, mesuréesgamma, et faisabilité de la stratégie. Tester la diversité des pairs et la connectivité adversaire.

Économie et erreurs de mitigation

  • Part relative appelée profit : Convertissez les récompenses acceptées en flux de trésorerie réels, soustrayez les coûts d’énergie, d’hébergement, de pool, de capital, de financement, d’impôt, de variance et de blocs échoués.
  • En supposant une économie immédiatement après l’ajustement : La persistance de la stratégie , la sortie ou l’entrée de concurrents, les variations du prix du hash, les frais, le prix de la monnaie et le retard dans les ajustements peuvent invalider les projections en régime permanent.
  • Traiter la quote-part de participation comme un contrôle permanent : Les contributeurs de hachage peuvent changer, mais les contrats, le micrologiciel, la garde des paiements, les retards de coordination, la géographie et la concentration peuvent les contraindre.
  • Détection à métrique unique : Le partage de bloc , le taux périmé, la latence ou le modèle de frais à eux seuls ne permettent pas d’identification. Combinez la télémétrie indépendante avec une règle de décision statistique explicite.
  • Atténuation sans analyse d’équilibre : Relais plus rapide, résolution aléatoire des égalités, règles de fraîcheur, modifications des récompenses ou pénalités peuvent déplacer les incitations et ajouter des surfaces de manipulation. Re-modéliser l’adoption et les adversaires.
  • Confirmation compte comme une correction complète : Une plus grande profondeur peut réduire une certaine exposition à la réorganisation des transactions, mais n’élimine pas la distorsion des récompenses, le travail gaspillé, la pression de centralisation ou les effets de vivacité.

Idées reçues

L’exploitation minière égoïste nécessite une puissance de hachage majoritaire

Non. Les résultats originaux étudient quand une coalition minoritaire peut améliorer sa part de récompense acceptée relative modélisée. Le point d’équilibre dépend du comportement en cas d’égalité et d’autres hypothèses ; le pouvoir de la majorité n’est ni la définition ni une condition préalable universelle.

Retenir un bloc prouve le minage égoïste

Non. Les opérateurs peuvent retarder la publication accidentellement ou pour d’autres raisons stratégiques et techniques, et un observateur extérieur peut ne pas savoir quand un bloc a été trouvé. L’exploitation minière égoïste est une politique conditionnelle selon les États, et non un retard isolé.

Plus de blocs acceptés que de partages de hachage prouvent la stratégie

Non. La découverte de blocs est aléatoire, la part du hash est estimée, les étiquettes sont imparfaites, et les mineurs changent. Même un écart statistiquement inhabituel nécessite une propagation, une branche, un modèle, une récompense et des preuves de cause alternative.

Le minage égoïste crée des blocs invalides ou un travail gratuit

Non. Ses blocs publiés doivent être valides et contenir une véritable preuve de travail. L’avantage modélisé provient du fait de changer quelles découvertes valides sont acceptées et de la réaction des autres mineurs ainsi que des règles de difficulté.

Une amélioration du relais ou plus de confirmations élimine le problème

Aucun contrôle unique ne prouve la compatibilité des incitations. Le relais peut changer les probabilités de course, tandis que les confirmations traitent certains risques de renversement de transaction ; aucun seul ne résout la conception des récompenses, les variantes stratégiques, la concentration, les règles d’ajustement ou les incitations aux frais.

Sujets liés

Sources

Navigation

Rechercher dans le wiki...