Table des liens
Résumé / Zusammenfassung
Publications
Remerciements
Chapitre 1: Introduction
-
Introduction
1.1 Aperçu des contributions de la thèse
1.2 Aperçu de la thèse
Chapitre 2: Contexte
2.1 Blongschains et contrats intelligents
2.2 Normes de hiérarchisation des transactions
2.3 Transparence de hiérarchisation et de contention des transactions
2.4 gouvernance décentralisée
2,5 Évolutivité de la blockchain avec des solutions de couche 2.0
Chapitre 3. Normes de hiérarchisation des transactions
-
Normes de hiérarchisation des transactions
3.1 Méthodologie
3.2 Analyser l'adhésion aux normes
3.3 Enquête sur les violations des normes
3.4 Transactions à frais noir
3.5 Remarques finales
Chapitre 4. Transparence de priorisation des transactions et de contention
-
Transparence de hiérarchisation et de contention des transactions
4.1 Méthodologie
4.2 sur la transparence des affirmations
4.3 sur la transparence de la hiérarchisation
4.4 Remarques finales
Chapitre 5. Gouvernance décentralisée
-
Gouvernance décentralisée
5.1 Méthodologie
5.2 Attaques contre la gouvernance
5.3 Gouvernance du composé
5.4 Remarques finales
Chapitre 6. Travaux connexes
6.1 Normes de hiérarchisation des transactions
6.2 Transparence de hiérarchisation et de contention des transactions
6.3 Gouvernance décentralisée
Chapitre 7. Discussion, limitations et travaux futurs
7.1 Commande de transaction
7.2 Transparence des transactions
7.3 Distribution du pouvoir de vote pour modifier les contrats intelligents
Conclusion
Annexes
Annexe A: Analyse supplémentaire des transactions Normes de hiérarchisation
Annexe B: Analyse supplémentaire des transactions priorisation et transparence des affirmations
Annexe C: Analyse supplémentaire de la distribution du pouvoir de vote
Bibliographie
3 Normes de hiérarchisation des transactions
Dans ce chapitre, nous nous plongeons sur les questions de recherche, la méthodologie et les implications d'analyser et de comprendre les normes utilisées par les mineurs lors de la priorité des transactions pour l'inclusion. Comprendre ces normes de hiérarchisation est la clé pour permettre aux émetteurs de transaction de déterminer les frais appropriés pour que leurs transactions soient incluses dans un nombre attendu de blocs.
L'ordre dans lequel les mineurs sélectionnent les transactions pour l'inclusion ont des implications importantes pour le résultat ultime de l'exécution des transactions. En conséquence, nous visons à auditer la blockchain Bitcoin pour répondre aux questions de recherche suivantes.
▶ RQ 1: Quelles transactions sont autorisées ou transmises sur le réseau public P2P? Cette question de recherche concerne la norme III, comme décrit au §2.2. Il suppose que les transactions avec un taux de frais inférieures à un seuil minimum sont rejetées et jamais engagées dans la blockchain. Si les mineurs envisagent des transactions avec des incitations inférieures au seuil établi, leur vision des transactions disponibles pour l'inclusion peut différer.
▶ RQ 2: Comment les mineurs sélectionnent-ils les transactions pour l'inclusion dans un bloc une fois qu'ils sont entrés dans le mempool des mineurs? Cette question de recherche concerne la norme I, qui indique que les mineurs sélectionnent des transactions pour l'inclusion, du MecPool, basées uniquement sur leurs taux de frais. Cependant, si certains mineurs acceptent des incitations supplémentaires pour accélérer la confirmation de transaction telle que les frais sombres ou opaques, la vision des mineurs des frais offerts peut varier. En conséquence, les émetteurs de transactions peuvent avoir du mal à estimer les frais appropriés nécessaires pour que leur transaction soit hiérarchisée, car la distribution des frais peut différer en fonction de la vision individuelle du système du mineur.
▶ RQ 3: Dans quel ordre les mineurs incluent-ils les transactions dans un bloc? Cette question s'aligne sur Norm II, où les transactions de taux de frais plus élevées sont prioritaires et placées avant les transactions de taux de tarifs inférieures pendant la construction du bloc. Si les mineurs mettent en œuvre les transactions dans un bloc, cela peut entraîner différents résultats pour les transactions lorsque le bloc du mineur est sélectionné comme bloc suivant. Les émetteurs de transactions peuvent être sensibles à
Des attaques telles que le premier cycle (Daian et al., 2020; Torres et al., 2021) ou même les attaques sandwichs (Qin et al., 2021; Zhou et al., 2023).
La résolution de ces questions de recherche est cruciale pour comprendre comment les mineurs hiérarchisent réellement les transactions pour l'inclusion. Par conséquent, une connaissance précise de l'ordre dans lequel les mineurs incluent les transactions peuvent aider à estimer les frais appropriés que les émetteurs doivent offrir pour hiérarchiser leurs transactions. Ensuite, nous discutons de notre méthodologie pour rassembler les ensembles de données nécessaires et détecter les transactions accélérées ou fortement prioritaires.
Publication pertinente
Les résultats présentés dans ce chapitre ont été publiés dans (Messias et al., 2020, 2021).
3.1 Méthodologie
Pour comprendre l'importance de l'ordre des transactions aux émetteurs et pour enquêter quand et comment les mineurs violent les «normes» de hiérarchisation des transactions, nous avons recours à une approche empirique basée sur les données. Ci-dessous, nous décrivons brièvement trois ensembles de données différents que nous avons organisés à partir de Bitcoin et soulignons comment nous utilisons les ensembles de données dans différentes analyses dans le reste de cette thèse. En outre, nous présentons notre méthodologie pour détecter l'accélération des transactions, qui peut être appliquée à toutes les blockchains d'incitation fondées sur des frais.
3.1.1 Collection d'ensemble de données
Ensemble de données A. Pour vérifier la conformité des mineurs aux normes de hiérarchisation dans Bitcoin, nous avons analysé toutes les transactions et blocs émis dans Bitcoin sur un délai de trois semaines à partir de
20 février au 13 mars 2019 (voir tableau 3.1). Nous avons obtenu les données en exécutant un nœud complet, un logiciel Bitcoin qui effectue presque toutes les opérations d'un mineur (par exemple, recevant des diffusions de transactions et de blocs, validant les données et les réapprochant des pairs) sauf pour l'exploitation minière. L'ensemble de données contient également un ensemble de instantanés périodiques, enregistrés une fois par 15 secondes pendant toute la période de trois semaines, où chaque instantané capture l'état du MecHepool du nœud complet. Nous traçons la distribution du nombre de blocs et de transactions extraits par le top-20 MPO pour l'ensemble de données A de la figure 3.1A. Si nous classons les MPO dans l'ensemble de données A par le nombre de blocs (b) extraits (ou, essentiellement, la capacité de hachage approximative H), les cinq principaux MPO se révèlent être BTC.com (B: 536; H: 17,18%), Antpool (B: 399; H: 12,79%), F2Pool (B: 352; H: 11,29%), Poolin (B: 352; H: 11,29%), B: 352; H: 11,29%), Poolin (B: 352; H: H: 11,29%), Poolin (B: 352; H: H: 11,29%), Poolin (B: 352; H: H: 11,29%), B: 352; H: 11,29%), B: 352; H: 11,29%), B: 352; H: 11,03%) et Slushpool (B: 279; H: 8,94%). Nous utilisons ces données pour vérifier si les mineurs adhèrent aux normes de hiérarchisation lors de la sélection des transactions pour confirmation ou inclusion dans un bloc.
Ensemble de données B. Les différences de configuration du logiciel Bitcoin peuvent affecter subtilement les inférences tirées de l'ensemble de données A. Un nœud complet se connecte à 8 pairs, par exemple, dans la configuration par défaut, et l'augmentation de ce nombre peut réduire la probabilité de manquer une transaction en raison d'un homologue «lent». La configuration par défaut impose également un seuil de taux de frais minimum de 1 SAT / B (ou 1 satoshi-pour octet) pour accepter une transaction. Nous avons instancié, par conséquent, un autre nœud complet pour étendre la portée de notre collecte de données. Nous avons configuré ce deuxième nœud, par exemple, pour nous connecter à 125 pairs. Nous avons également supprimé le seuil de taux de frais pour accepter même les transactions à frais zéro. B contient des instantanés MEMPOOL de ce nœud complet, également enregistré une fois par 15 s, pendant tout le mois de juin 2019 (référer le tableau 3.1). Nous remarquons que 99,7% des transactions reçues par notre Mempool ont été incluses par des mineurs. La figure 3.1b montre la distribution du nombre de blocs et de transactions extraits par les 20 premiers MPO pour l'ensemble de données B. Les cinq principaux MPO sont BTC.com (B: 889; H: 19,67%), Antpool (B: 577; H: 12,77%), F2Pool (B: 523; H: 11,57%), Slushpool (B: 438; Poolin (B: 433; H: 9,58%).
Ensemble de données C. Les idées dérivées des données ci-dessus nous ont motivés à faire la lumière sur le comportement aberrant des opérateurs de piscine miniers (MPO). À cette fin, nous avons rassemblé tous les blocs Bitcoin (53 214) exploités et leurs 112 542 268 transactions du 1er janvier au 31 décembre 2020. Ces blocs contiennent également une transaction Coinbase par bloc, que le MPO crée pour recevoir le bloc et les récompenses de frais. Cet ensemble de données, étiqueté C, contient 112 489 054 transactions émises (voir tableau 3.1). Les MPO incluent généralement une signature ou un marqueur dans la transaction Coinbase, probablement pour réclamer leur propriété du bloc. Après les travaux antérieurs (par exemple, (Judmayer et al., 2017; Romiti et al., 2019)), nous utilisons ces marqueurs pour identifier le MPO (propriétaire) de chaque bloc. Nous n'avons pas identifié les propriétaires de 703 blocs (ou environ 1,32% du total), mais nous avons déduit 30 MPO dans notre ensemble de données. Dans cette thèse, nous ne considérons que les MPO des 20 premiers dont les taux de hachage normalisés combinés représentent 98,08% de tous les blocs extraits. La figure 3.1C montre le nombre de blocs extraits par les 20 meilleurs MPO selon C. Les cinq premiers MPO en termes de nombre de blocs (b) exploités sont F2Pool (B: 9326; H: 17,53%), Poolin (B: 7876; H: 14,80%), Btc.com (B: 6381; 10,96%) et Huobi (B: 3990; H: 7,5%).
3.1.2 Détection des transactions accélérées.
Compte tenu des frais élevés exigés par Services d'accélération, nous prévoyons que les transactions accélérées seraient incluses dans la blockchain avec la plus haute prioritéc'est-à-dire, dans les premiers blocs extraits par le mineur d'accélération et parmi les premières positions dans le
bloc. Nous prévoyons également que Sans les frais d'accélération, la transaction n'aurait aucune chance d'être incluse dans le bloc en fonction de ses frais de transaction offerts publiquement. Les deux observations ci-dessus suggèrent une méthode potentielle pour détecter les transactions accélérées dans la blockchain Bitcoin: une transaction accélérée aurait un très haut Erreur de prédiction de position signée (SPPE) (Reportez-vous au §3.3.1), car sa position prévue en fonction de ses frais publics serait vers le bas du bloc dans lequel il est inclus, tandis que sa position réelle serait vers le haut du bloc.
Pour tester l'efficacité de notre méthode, nous avons analysé les 6381 blocs et 13 395 079 transactions exploitées par BTC.com Pool Mining Pool dans l'ensemble de données C. Nous avons ensuite extrait toutes les transactions avec SPPE plus ou égal à 100%, 99%, 90%, 50%, 1% et vérifions la fraction de ces transactions, selon le BTC.Com accélérateur API (BTC. 2022).
Auteur:
(1) Johnnatan Messias Peixoto Afonso
