Dans le dernier article de Mempool, j’ai parcouru les différents types de filtres de politique de relais, pourquoi ils existent et les incitations qui décident finalement de l’efficacité de chaque classe de filtre pour prévenir la confirmation de différentes classes de transactions. Dans cette pièce, je vais regarder la dynamique du réseau de relais lorsque certains nœuds sur le réseau exécutent différentes politiques de relais par rapport aux autres nœuds.
Tout le reste étant égal, lorsque les nœuds sur le réseau exécutent des politiques de relais homogène dans leurs mempools, toutes les transactions devraient se propager sur l’ensemble du réseau étant donné qu’ils paient le minimum feeate nécessaire pour ne pas être expulsé à partir du mempool d’un nœud pendant les périodes d’importance de transactions. Cela change lorsque différents nœuds sur le réseau exécutent des politiques hétérogènes.
Le réseau de relais Bitcoin fonctionne au meilleur effort, en utilisant ce qu’on appelle une architecture de remplissage d’inondation. Cela signifie que lorsqu’une transaction est reçue par un nœud, elle est transmise à tous les autres nœuds à laquelle il est connecté, sauf celui dont il a reçu la transaction. Il s’agit d’une architecture de réseau très inefficace, mais dans le contexte d’un système décentralisé, il offre un degré élevé de garantie que la transaction finira par atteindre sa destination prévue, les mineurs.
L’introduction de filtres dans la politique de relais d’un nœud pour restreindre le relais des transactions autrement valides en théorie introduit la friction à la propagation de cette transaction et dégrade la fiabilité de la capacité du réseau à remplir cette fonction. En pratique, les choses ne sont pas aussi simples.
Combien de frottement empêche la propagation
Examinons un exemple simplifié de différentes compositions de nœuds de réseau. Dans les graphiques suivants, les nœuds bleus représentent ceux qui propagent une classe arbitraire de transactions valides consensuelles, et les nœuds rouges représentent ceux qui propageront ces transactions. L’ensemble collectif de mineurs est indiqué dans le centre comme une simple représentation de l’endroit où les utilisateurs de transaction souhaitent finalement que leurs transactions se terminent afin d’être finalement confirmées dans la blockchain.
Il s’agit d’un modèle du réseau dans lequel les nœuds refusant de propager ces transactions sont une minorité claire. Comme vous pouvez le voir clairement, tout nœud sur le réseau qui les accepte a un chemin clair pour les relayer aux mineurs. Les deux nœuds qui tentent de restreindre la propagation des transactions à travers le réseau n’ont aucun effet sur leur réception éventuel par les nœuds des mineurs.
Dans ce diagramme, vous pouvez voir que près de la moitié de l’exemple de réseau instituent des politiques de filtrage pour cette classe de transactions. Malgré cela, seule une partie du réseau qui propage ces transactions est coupée d’un chemin vers les mineurs. Le reste des nœuds qui ne filtraient pas ont toujours un chemin clair vers les mineurs. Cela a introduit un certain degré de frottement pour un sous-ensemble d’utilisateurs, mais les autres peuvent toujours s’engager librement dans la propagation de ces transactions.
Même pour les utilisateurs qui sont affectés par le filtrage des nœuds, une seule connexion au reste des nœuds réseau qui ne sont pas coupées des mineurs (ou une connexion directe à un mineur) est nécessaire pour que cette friction soit supprimée. Si le réseau réel de relais devait avoir une composition similaire à cet exemple, tout ce qu’il faudrait est une nouvelle connexion pour atténuer le problème.
Dans ce scénario, seule une petite minorité du réseau propage ces transactions. Le reste du réseau s’engage dans le filtrage des politiques pour empêcher leur propagation. Même dans ce cas cependant, les nœuds qui ne filtrent pas ont toujours un chemin clair pour les propager aux mineurs.
Seule cette petite minorité de nœuds non filtrants est nécessaire afin d’assurer leur propagation éventuelle aux mineurs. Logique de peering préférentielle, IE Fonctionnalité pour vous assurer que votre nœud préfère les pairs qui implémentent la même version du logiciel ou les mêmes politiques de relais. Ces types de solutions peuvent garantir que les pairs qui propageront quelque chose à d’autres ne se trouvera pas et entretenir des liens entre eux sur le réseau.
La minorité tolérante
Comme vous pouvez le voir, regarder ces différents exemples, même face à une écrasante majorité du réseau public se livrant au filtrage d’une classe spécifique de transactions, tout ce qui est nécessaire pour qu’ils se propagent avec succès à travers le réseau aux mineurs est une petite minorité du réseau pour les propager et les transmettre.
Ces nœuds créeront essentiellement, par le biais du mécanisme technique, une «sous-réseau» dans le réseau de relais public plus large afin de garantir qu’il existe des chemins viables des utilisateurs qui se livraient à ces types de transactions aux mineurs disposés à les inclure dans leurs blocs.
Il n’y a essentiellement rien qui puisse être fait pour contrer cette dynamique, sauf pour s’engager dans une attaque de Sybil contre tous ces nœuds, et les attaques de Sybil n’ont besoin que d’une seule connexion honnête pour être complètement vaincu. De plus, un nœud honnête créant un très grand nombre de connexions avec d’autres nœuds sur le réseau peut augmenter de manière exorbitante le coût d’une telle attaque de Sybil. Plus il crée de connexions, plus les nœuds Sybil doivent être tournés pour consommer toutes ses créneaux de connexion.
Et s’il n’y a pas de minorité?
Et s’il n’y a pas de minorité tolérante? Qu’arrivera-t-il à cette classe de transactions dans ce cas?
Si les utilisateurs veulent toujours les faire et payer des frais aux mineurs pour eux, ils seront confirmés. Les mineurs installeront simplement une API. Le rôle des mineurs est de confirmer les transactions, et la raison pour laquelle ils le font est de maximiser le profit. Les mineurs ne sont pas des entités altruistes, ou motivées par moralement ou idéologiquement, ils sont une entreprise. Ils existent pour gagner de l’argent.
Si les utilisateurs existent qui sont disposés à leur payer de l’argent pour un certain type de transaction, et l’intégralité du réseau de relais public refuse de propager ces transactions aux mineurs afin de les inclure dans des blocs, les mineurs créeront un autre moyen pour les utilisateurs de leur soumettre ces transactions.
C’est simplement la décision rationnelle de faire en tant qu’acteur motivé par le profit lorsque les clients existent qui souhaitent vous payer de l’argent.
La politique de relais ne remplace pas le consensus
À la fin de la journée, la politique de relais ne peut pas avoir réussi à censurer les transactions s’ils sont valides consensus, les utilisateurs sont prêts à payer pour eux, et les mineurs n’ont pas des circonstances atténuantes pour refuser les frais que les utilisateurs sont prêts à payer (comme causer des dommages matériels ou des nœuds sur le réseau, c’est-à-dire des nœuds de collision, des blocs de propagation qui prennent des heures à vérifier sur un PC consommateur, etc.).
Si une classe de transactions est vraiment considérée comme indésirable par les utilisateurs de Bitcoin et les opérateurs de nœuds, il n’y a pas de solution pour les empêcher de confirmer dans la blockchain à court de promulgation d’un changement de consensus pour les rendre invalides.
S’il était possible d’empêcher simplement les transactions de confirmer en filtrant les politiques mises en œuvre sur le réseau de relais, Bitcoin ne serait pas résistant à la censure.
Ce message The Bitcoin Mecpool: Relay Network Dynamics est apparu pour la première fois sur Bitcoin Magazine et est écrit par Shinobi.
