En el último artículo de Mempool, pasé por la dinámica de la propagación de transacciones cuando los nodos diferentes en la red están ejecutando diferentes políticas de retransmisión de Mempool. En esta pieza, analizaré la dinámica de las Mempools privadas y las implicaciones que tienen para la utilidad de la Mempool pública, los incentivos mineros y la salud de la red de Bitcoin en general.
En el corazón del propósito de la Mempool, es facilitar los incentivos alineados de dos partes diferentes, mineros y usuarios de transacciones. Los usuarios quieren realizar transacciones y están dispuestos a pagar las tarifas de transacción de los mineros para hacerlo. Los mineros quieren ganar dinero, y las tarifas de transacción son una fuente adicional de ingresos además del nuevo subsidio de monedas en cada bloque, así como una fuente de ingresos primaria necesaria para cultivar a largo plazo a medida que el subsidio disminuye.
Bitcoin es un sistema asegurado por incentivos. Esta dinámica central es lo que impulsa la seguridad del sistema, usted tiene un cliente y un proveedor, y los dos que intentan satisfacer sus deseos y necesidades es lo que garantiza que la cadena de bloques continúe avanzando con una cantidad suficiente de seguridad termodinámica.
Los intentos de introducir la fricción en este mecanismo de facilitación no hacen nada en absoluto para cambiar los incentivos de estas dos partes. Un usuario que quiere hacer un cierto tipo de transacción todavía querrá hacer esa transacción y pagarla. Un minero que está dispuesto a aceptar ese tipo de transacciones todavía querrá aceptarlas y cobrarlas al incluirlas en un bloque.
Si la transacción es válida, entonces estas dos partes aún tendrán sus necesidades y necesidades insatisfechas, y aún estarán muy motivados para conocerlos de alguna forma o manera.
API minero
Los usuarios finales individuales no están lo suficientemente capitalizados o lo suficientemente competentes como para enrutar la fricción introducida artificialmente entre ambos extremos de una coincidencia de deseos, pero los mineros definitivamente lo son. Como dice el viejo adagio, “Si lo construyes, vendrán”.
La situación preferencial para los mineros es obviamente adquirir tarifas que pagan transacciones en la banda a través de la memoria pública. Requiere la sobrecarga más baja posible para ellos, simplemente ejecutar un cliente de bitcoin estándar de la caja, es un mecanismo de propagación muy resistente que garantiza un alto grado de confiabilidad para obtener los mineros en las transacciones de pago más alta, y no tienen que hacer nada. Simplemente descargue el cliente y ejecutarlo.
Sin embargo, en un entorno muy hostil, como un esfuerzo de red para filtrar las transacciones válidas de consenso durante su propagación a través de la red, esa suposición tradicional puede ser cuestionada.
En tal escenario, los mineros tienen todos los incentivos para establecer mecanismos fuera de banda para aceptar transacciones que no se transmiten adecuadamente en toda la red. La API Slipstream de Marathon para transacciones no estándar no es el único ejemplo de esto. De hecho, hay un precedente de larga data de hace casi diez años que fue ampliamente implementado por muchos grupos mineros, y aún existe hasta el día de hoy. Aceleradores de transacción.
Ahora vivimos en un mundo de RBF completo, donde cualquier transacción, independientemente del uso de la bandera histórica de “opción”, puede ser de tarifa. Cualquier nodo que haya actualizado a Full-RBF transmitirá cualquier transacción que esté gastando una producción no confirmada que ya esté pendiente en la Mempool siempre que pague una tarifa más alta. Este no siempre ha sido el caso. Históricamente, solo las transacciones que se hicieron originalmente con una bandera para optar por el uso de RBF podrían reemplazarse y esperar que se propagen a través de la red.
Los aceleradores de transacciones fueron creados por mineros para facilitar este comportamiento para las transacciones que no optaron por el uso de RBF.
API de terceros
Si bien la sobrecarga no es exorbitantemente alta para que un minero o una piscina cree su propia API de envío de transacciones, no es gratuito. Todavía requiere al menos un desarrollador y tiempo para pasar por el ciclo de diseño y lanzamiento de cualquier software. La curva no es particularmente exagerada, pero aún favorece a los mineros más grandes sobre los más pequeños en términos de la cantidad de recursos que tendrán que dedicar a tal esfuerzo.
Mempool.space ha demostrado que es un esfuerzo viable para un tercero que no está relacionado con los mineros para crear dicha API, lo que permite a los mineros simplemente conectarse a su servicio en lugar de gastar el esfuerzo para crear uno desde cero. Sin embargo, esto tiene sus problemas, tal tercero no va a construir y operar dicho servicio de forma gratuita. Querrán su corte.
Hay dos formas en que puede ir esta dinámica, o estos servicios terminan requiriendo un costo más alto para permitir que tanto los mineros como los proveedores de servicios obtengan ingresos, o los mineros tendrán que compartir un recorte más pequeño de los ingresos para que dichos servicios sigan siendo competitivos con los mineros directamente operados. Esto significa que los mineros que usan una API de sumisión de terceros en lugar de la suya obtendrán menos ingresos que los mineros que operan su propia API.
Flujo de pedido privado
Cualquiera de las posibilidades anteriores introduce serios problemas cuando se trata de los incentivos generales del sistema, la confiabilidad del software del usuario final y potencialmente incluso el modelo de seguridad de los sistemas de segunda capa que dependen del uso de transacciones previas firmadas y un modelo de seguridad reactivo para mantener seguros los fondos de los usuarios.
Cuando las transacciones se envían a una API privada, no son visibles para los participantes de la red hasta que realmente se confirman en un bloque. Toda la cola de transacciones no confirmadas que utilizan estos sistemas es opaca. Esto podría ser público por los operadores de estas API, pero no de manera confiable. No hay forma de probar o garantizar que los operadores no retengan información.
La retención de transacciones de la vista pública podría distorsionar las estimaciones de tarifas que hacen los usuarios, e incluso abrir la puerta a la posibilidad de manipular esos feerates rellenando bloques con sus propias transacciones. Las transacciones utilizadas en la operación de los sistemas de segunda capa podrían retener desde la vista pública hasta la confirmación, lo que puede retrasar la capacidad de los usuarios para reaccionar a las transacciones a las que deben responder para garantizar la seguridad de sus fondos.
Por último, solo la existencia de tales API si la demanda o la necesidad de ellas es lo suficientemente alta es una presión de centralización masiva. Tener que manejar la conexión a cada API individual para enviar una transacción es una molestia, una UX pobre y una posible complejidad de back -end. Esto tiende a reforzar el uso de las API (s) más grandes e ignorar el Tailend, lo que crea un circuito de retroalimentación.
Los operadores de API con el hashrate más grande tendrán las confirmaciones más rápidas y confiables, lo que garantiza que solo esos mineros más grandes obtengan de manera confiable estos ingresos adicionales, dándoles más capital para crecer, etc.
Mempools paralelos
En el otro extremo del espectro está la posibilidad de crear redes de retransmisión públicas totalmente independientes. Si bien esto replica la apertura actual de la Mempool pública existente, y evita lo peor de las presiones centralizadas de las API centrales, todavía no es ideal.
Tener múltiples Mempools introduciendo complejidad para los mineros, los usuarios finales y para las aplicaciones de los usuarios finales. Los usuarios ahora deben realizar un seguimiento de todas las MemPools independientes, especialmente los utilizados para los sistemas con los que interactúan que no se propagan sobre la red de retransmisión primaria, para tener una vista de transacciones no confirmadas.
Si los rayos (o alguna otra capa 2) comenzaran a utilizar una memoria paralela, el seguimiento sería crítico para cualquier usuario de rayos (o esa otra capa 2). También sería necesario rastrear todo De las redes de retransmisión paralelas para tener una visión precisa de las otras transacciones no confirmadas contra las que está ofertando para su inclusión en el siguiente bloque. El seguimiento solo de un subconjunto de ellos conduciría a márgenes de error potencialmente grandes en cualquier estimación de tarifas de usuarios.
Solo empeoras las cosas
No es posible tratar de evitar transacciones con los usuarios que pagan tarifas dispuestas sin abordarlos a nivel de consenso. Bitcoin es un motor impulsado por incentivos, y cuando los incentivos de múltiples partes se alineen, se facilitarán de una forma u otra.
Tratar de fingir que ese no es el caso, y que las cosas pueden detenerse, desincentivarse o retrasarse de otra manera es un mandado tonto. No solo eso, sino que intentar a una escala grave viene con consecuencias negativas muy graves, además de estar condenado a fallar.
Las reglas de consenso de Bitcoin son el marco en el que se juegan incentivos. Lo único que puede superar los incentivos es cambiar ese marco. Es literalmente lo que informa y da forma a los incentivos en primer lugar.
Intentar interferir con esos incentivos en cualquier otra capa es un mandado de tontos, y no puede hacer nada más que exacerbar los resultados negativos impulsados por los incentivos, es decir, la centralización.
Esta publicación The Bitcoin Mempool: Private Mempools apareció por primera vez en la revista Bitcoin y está escrita por Shinobi.
