Le Mempool Bitcoin : Mempool privé

Dans le Dernier article de Mempool, j’ai parcouru la dynamique de la propagation des transactions lorsque différents nœuds sur le réseau exécutent différentes politiques de relais MecPool. Dans cette pièce, je vais examiner la dynamique des mempools privés et les implications qui ont pour l’utilité du MecOpool public, les incitations minières et la santé du réseau Bitcoin dans son ensemble.

Au cœur de l’objectif du MecOpol, c’est faciliter les incitations alignées de deux parties, mineurs et utilisateurs de transactions différents. Les utilisateurs souhaitent transformer et sont prêts à payer les frais de transaction des mineurs pour ce faire. Les mineurs veulent gagner de l’argent et les frais de transaction sont une source supplémentaire de revenus en plus de la nouvelle subvention de la pièce dans chaque bloc, ainsi qu’une source de revenus primaire nécessaire pour cultiver à long terme à mesure que la subvention diminue.

Bitcoin est un système garanti par des incitations. Cette dynamique de base est ce qui motive la sécurité du système, vous avez un ou des clients et un fournisseur, et les deux qui tentent de répondre à leurs désirs et besoins sont ce qui garantit que la blockchain continue de cocher avec une quantité suffisante de sécurité thermodynamique.

Les tentatives d’introduction de frottement dans ce mécanisme de facilitation ne font finalement rien du tout pour changer les incitations de ces deux parties. Un utilisateur qui veut effectuer un certain type de transaction voudra toujours effectuer cette transaction et le payer. Un mineur qui est prêt à accepter ce type de transactions va toujours les accepter et percevoir les frais en les incluant dans un bloc.

Si la transaction est valide, ces deux parties vont toujours avoir leurs désirs et leurs besoins non satisfaits, et seront toujours fortement motivés pour les rencontrer sous une forme ou une manière.

API mineur

Les utilisateurs finaux individuels ne sont pas nécessairement suffisamment capitalisés ou suffisamment compétents afin de faire le tour des frictions introduites artificiellement entre les deux extrémités d’une coïncidence de désirs, mais les mineurs le sont certainement. Comme le dit le vieil adage, « Si vous le construisez, ils viendront. »

La situation préférentielle pour les mineurs est évidemment d’acquérir des transactions de paiement des frais en bande via le Mempool public. Cela nécessite les frais généraux les plus bas possibles, en exécutant simplement un client Bitcoin standard hors de la boîte, il s’agit d’un mécanisme de propagation très résilient qui garantit un degré de fiabilité très élevé pour obtenir les mineurs les transactions de paiement les plus élevées, et ils n’ont rien à faire. Téléchargez simplement le client et exécutez-le.

Cependant, dans un environnement très hostile tel qu’un effort à large étendue de réseau pour filtrer les transactions valides au consensus pendant leur propagation à travers le réseau, cette hypothèse traditionnelle peut être remise en question.

Dans un tel scénario, les mineurs ont toute incitation à mettre en place des mécanismes hors bande pour accepter des transactions qui ne sont pas correctement relayées sur le réseau. L’API Slipstream de Marathon pour les transactions non standard n’est pas le seul exemple de cela. Il y a en fait un précédent de longue date d’il y a près de dix ans qui a été largement mis en œuvre par beaucoup piscines minières et existe toujours à ce jour : les accélérateurs de transaction.

Nous vivons maintenant dans un monde de Full-RBF, où toute transaction, indépendamment de l’utilisation du drapeau historique « opt-in », peut être bombardée. Tout nœud qui a été mis à niveau vers le Full-RBF relayera toute transaction qui dépense une production non confirmée déjà en attente dans le MecOpool tant qu’elle paie des frais plus élevés. Cela n’a pas toujours été le cas. Historiquement, seules les transactions qui ont été effectuées à l’origine avec un drapeau pour s’opposer à l’utilisation de RBF pouvaient être remplacées et devraient se propager à travers le réseau.

Les accélérateurs de transaction ont été créés par des mineurs afin de faciliter ce comportement pour les transactions qui n’ont pas opté pour l’utilisation de RBF.

API tiers

Bien que les frais généraux ne soient pas exorbitants pour un mineur ou un pool pour créer leur propre API de soumission de transaction, elle n’est pas gratuite. Il faut toujours au moins un développeur et le temps pour passer par le cycle de conception et de publication de tout logiciel. La courbe n’est pas particulièrement exagérée, mais elle favorise toujours les plus grands mineurs par rapport aux plus petits en termes de ressources qu’ils devront consacrer à une telle entreprise.

Mempool.space a prouvé qu’il s’agit d’une entreprise viable pour un tiers, sans rapport avec les mineurs, de créer une telle API, permettant aux mineurs de se connecter simplement à leur service plutôt que de dépenser l’effort pour en créer un eux-mêmes à partir de zéro. Cela a ses problèmes cependant, un tel tiers ne va pas construire et exploiter un tel service gratuitement. Ils voudront leur coupe.

Il y a deux façons dont cette dynamique peut aller, soit ces services finissent par nécessiter un coût plus élevé afin de permettre aux mineurs et aux prestataires de services de gagner des revenus, ou les mineurs devront partager une réduction plus faible des revenus afin que de tels services restent compétitifs avec des mineurs directement exploités par des mineurs. Cela signifie que les mineurs utilisant une API de soumission tiers plutôt que les leurs gagneront moins de revenus que les mineurs qui exploitaient leur propre API.

Flux de commandes privées

L’une ou l’autre des possibilités ci-dessus introduit de graves problèmes en ce qui concerne les incitations globales du système, la fiabilité des logiciels de l’utilisateur final, et potentiellement même le modèle de sécurité des systèmes de deuxième couche qui reposent sur l’utilisation des transactions pré-signées et un modèle de sécurité réactif afin de protéger les fonds d’utilisateurs.

Lorsque les transactions sont soumises à une API privée, elles ne sont pas visibles pour les participants au réseau tant qu’elles ne sont pas confirmées dans un bloc. La file d’attente entière de transactions non confirmées utilisant ces systèmes est opaque. Cela pourrait être rendu public par les opérateurs de ces API, mais pas de manière sans confiance. Il n’y a aucun moyen de prouver ou de garantir que les opérateurs ne retiennent pas des informations.

La retenue des transactions de la vue du public pourrait déformer les estimations des frais que les utilisateurs effectuent, et même ouvrir la porte à la possibilité de manipuler ces fédérations en remplissant les blocs avec leurs propres transactions. Les transactions utilisées dans le fonctionnement des systèmes de deuxième couche pourraient être retenues de la vue publique jusqu’à la confirmation, ce qui peut retarder la capacité des utilisateurs à réagir aux transactions auxquelles ils doivent répondre afin de garantir la sécurité de leurs fonds.

Enfin, la simple existence de telles API si la demande ou le besoin pour eux est suffisamment élevée, est une pression de centralisation massive. Le fait de devoir gérer la connexion à chaque API individuelle pour soumettre une transaction est une complexité de tracas, de mauvaise UX et potentielle. Cela tend à renforcer l’utilisation des plus grandes API et en ignorant le Tailend, ce qui crée une boucle de rétroaction.

Les opérateurs d’API avec le plus grand hashrate auront les confirmations les plus rapides et les plus fiables, garantissant que ces mineurs les plus importants gagnent de manière fiable ces revenus supplémentaires, ce qui leur donne plus de capital pour augmenter, etc.

Mempools parallèles

À l’autre extrémité du spectre est la possibilité de créer des réseaux de relais publics totalement indépendants. Bien que cela reproduise l’ouverture actuelle du Mempool public existant et évite le pire des pressions de centralisation des API centrales, ce n’est toujours pas idéal.

Avoir plusieurs mempools introduisant la complexité pour les mineurs, pour les utilisateurs finaux et pour les applications utilisateur final. Les utilisateurs doivent désormais garder une trace de tous les mempools indépendants, en particulier ceux utilisés pour les systèmes avec lesquels ils interagissent qui ne sont pas propagés sur le réseau de relais principal, afin d’avoir une vue de transactions non confirmées.

Si la foudre (ou une autre couche 2) devait commencer à utiliser un mempool parallèle, le suivre serait critique pour tout utilisateur de Lightning (ou cette autre couche 2). Il serait également nécessaire de suivre tous des réseaux de relais parallèles afin d’avoir une vue précise des autres transactions non confirmées contre lesquelles vous soumissionnez pour inclusion dans le bloc suivant. Le suivi uniquement d’un sous-ensemble entraînerait des marges d’erreur potentiellement importantes dans les frais de tout utilisateur.

Tu aggraves juste les choses

Essayer d’empêcher les transactions avec des frais de paiement volontaires sans les aborder au niveau du consensus n’est tout simplement pas possible. Le bitcoin est un moteur entraîné par des incitations, et lorsque les incitations de plusieurs parties s’alignent, elles seront facilitées sous une forme ou une autre.

Essayer de prétendre que ce n’est pas le cas, et que les choses peuvent être arrêtées, désincitées ou autrement retardées est une course d’un imbécile. Non seulement cela, mais essayer à n’importe quelle échelle est avec des conséquences négatives très graves, en plus d’être vouée à l’échec.

Les règles de consensus de Bitcoin sont le cadre dans lequel les incitations sont jouées. La seule chose qui peut l’emporter sur les incitations est de modifier ce cadre. C’est littéralement ce qui informe et façonne les incitations en premier lieu.

Essayer d’interférer avec ces incitations à n’importe quelle autre couche est une course d’un imbécile et ne peut rien faire d’autre que des résultats négatifs motivés par les incitations, c’est-à-dire la centralisation.