El documento técnico de Bitcoin es claro sobre la característica central de Bitcoin: es sin permisos. Cualquiera en el mundo puede realizar un pago a otra persona uniéndose a la red peer-to-peer y transmitiendo una transacción. El consenso de Prueba de Trabajo empodera incluso a cualquier individuo para convertirse en productor de bloques, y significa que la única manera de revertir un pago es superar a los demás a través del hashpower.
Sin embargo, la Prueba de Trabajo solo define cómo elegir un ganador entre cadenas competidoras; no ayuda a un nodo a descubrirlo. Un ataque del 51% (o un ataque del 100%) es mucho más fácil si un atacante puede evitar que los nodos conozcan sobre cadenas competidoras. La tarea de descubrimiento pertenece al módulo peer-to-peer, que maneja muchas tareas contradictorias: encontrar pares honestos en una red donde los nodos continuamente se unen y se van, pero sin autenticación ni reputación. Siempre estar alerta a bloques y transacciones, pero sin sorprenderse si la mayoría de los datos son basura. Ser lo suficientemente robusto para sobrevivir en condiciones adversas extremas, pero ligero lo suficiente para funcionar en una Raspberry Pi.
Los detalles de implementación para una red peer-to-peer sin permisos se omitieron en el documento técnico, pero constituyen la mayor parte de la complejidad en el software de nodos de Bitcoin en la actualidad.
Filtros para el Spam
El documento técnico reconoce que la retransmisión pública de transacciones es la piedra angular de la resistencia a la censura de Bitcoin, pero solo menciona brevemente cómo debería operar: «Las nuevas transacciones se transmiten a todos los nodos. Cada nodo recopila nuevas transacciones en un bloque. Cada nodo trabaja en encontrar una prueba de trabajo difícil para su bloque.»
Muchos consideran divertido que Satoshi sugiriera que cada nodo debería minar. Debido a la presión centralizadora de la variabilidad de la minería, la gran mayoría de los nodos en la red actual no se dedican a encontrar una prueba de trabajo. Quizás eso sea un resultado aceptable o incluso exitoso de los incentivos económicos; hemos intercambiado una porción de descentralización por un aumento en el hashpower y, por lo tanto, en la seguridad. Sin embargo, la resistencia a la censura de Bitcoin se derrumbará si también renunciamos a la retransmisión descentralizada de transacciones.
El deseo de contar con un amplio grupo de nodos retransmisores de transacciones debe enfrentar la realidad de que las computadoras diarias se exponen a una red sin permisos y procesan datos de pares anónimos. Este modelo de amenaza es único y requiere una programación altamente defensiva.
En la descarga de bloques, la prueba de trabajo de un bloque sirve elegantemente tanto como prevención de Denegación de Servicio (DoS) como una forma inequívoca de evaluar la utilidad de los datos. En contraste, los datos de transacciones no confirmadas son prácticamente gratuitos de crear y puede que solo sean spam. Por ejemplo, no podemos saber si la transacción cumple con sus condiciones de gasto hasta que hayamos cargado el UTXO, lo que puede requerir buscar en el disco. A los atacantes no les cuesta absolutamente nada activar esta actividad de alta latencia. Pueden elaborar grandes transacciones utilizando entradas que no les pertenecen o que no existen en absoluto.
Los pasos de validación, como la verificación de firmas y la gestión de dependencias del mempool, pueden ser computacionalmente costosos. Famosamente, las transacciones con una gran cantidad de firmas heredadas (pre-segwit) pueden tardar minutos en validar en cierto hardware, por lo que la mayoría de los nodos filtran transacciones grandes. El uso de recursos no se limita solo al nodo: las transacciones aceptadas se transmiten típicamente a otros pares, utilizando ancho de banda proporcional al número de nodos en la red.
Los nodos se protegen limitando la memoria utilizada para transacciones no confirmadas y colas de validación, restringiendo el procesamiento de transacciones por par y aplicando reglas de política además del consenso. Sin embargo, estos límites también pueden crear vectores de censura si no se diseñan cuidadosamente. La lógica simple de no descargar una transacción que ya ha sido rechazada anteriormente, limitar el tamaño de la cola de transacciones para un solo par, o descartar solicitudes tras intentos de descarga fallidos puede llevar a los nodos a quedarnos ciegos ante una transacción. Estos fallos se convierten en vectores de censura accidentales cuando son explotados por el atacante adecuado.
En este sentido, aunque es completamente lógico no mantener transacciones no confirmadas que son gastos duplicados entre sí (solo una versión puede ser válida), el rechazo de un gasto duplicado significa que una transmisión anterior impide que una posterior sea minada. Un gasto duplicado podría ser un intento intencional de falsificar un pago o, cuando un UTXO es propiedad de múltiples partes, un ataque de pinning que explota la política del mempool para retrasar o evitar que las transacciones de liquidación de segunda capa sean minadas. ¿Cómo deberían los nodos elegir?
Esta pregunta nos lleva al segundo elemento de la retransmisión de transacciones: la compatibilidad de incentivos. Mientras que las tarifas no son relevantes para el consenso más allá de limitar lo que un minero puede reclamar como recompensa de bloque, juegan un papel crucial en la política del nodo como una métrica de utilidad. Suponiendo que los mineros están motivados por incentivos económicos, los nodos pueden aproximar cuáles transacciones son más atractivas para minar y descartar las menos atractivas. Cuando las transacciones gastan el mismo UTXO, el nodo puede conservar la más rentable. Aunque los nodos no recojan tarifas, pueden considerar transacciones de cero tarifa como spam: es probable que consuman recursos de red pero nunca sean minadas, aunque cuesten prácticamente nada de crear.
Estos dos objetivos de diseño —resistencia DoS y compatibilidad de incentivos— están en constante tensión. Aunque es atractivo reemplazar una transacción por una versión de mayor tarifa, permitir reemplazos repetidos con pequeños incrementos de tarifa podría desperdiciar el ancho de banda de la red. Contar con las dependencias entre transacciones no confirmadas puede crear bloques más rentables (y habilitar CPFP), pero puede ser costoso en topologías complejas.
Históricamente, los nodos han confiado en heurísticas y límites de dependencia, lo que causó fricción para el usuario y abrió nuevos vectores de pinning. Los mempools que rastrean clústeres pueden evaluar la compatibilidad de incentivos con mayor precisión, pero aún deben limitar las dependencias del mempool. Este tipo de restricciones crean vectores de pinning para transacciones que involucran a múltiples partes que no confían entre sí: un atacante puede impedir que su co-transactor emplee CPFP al monopolizar el límite.
Es fácil trivializar estos problemas: los ataques de pinning son un tipo de censura especializado que solo se aplica a transacciones compartidas y generalmente solo resultan en retrasos temporales de las transacciones. ¿Vale la pena el esfuerzo para ayudar a los nodos no mineros a obtener unos pocos satoshis adicionales en tarifas?
Un Acuerdo con el Mal
Las transacciones compartidas son la columna vertebral de las soluciones de privacidad de mezcla de UTXO y de protocolos de segunda capa. Gran parte del desarrollo de Bitcoin se centra en crear aplicaciones escalables, privadas y ricas en características en una segunda capa que vuelva a liquidar en la cadena. Un patrón común es retrasar temporalmente los retiros o liquidaciones, permitiendo que las partes respondan a comportamientos inapropiados dentro de una ventana de tiempo. Pero muchos diseños —incluidos aquellos utilizados para motivar cambios en el consenso— pasan por alto el aumento de tarifas en estos escenarios.
Una ventana de tiempo para prevenir comportamientos inapropiados también es una ventana de oportunidad para los atacantes. Estas dos condiciones —transacciones compartidas y plazos de confirmación para prevenir comportamientos inapropiados— crean la tormenta perfecta que eleva la gravedad de los ataques de pinning de retrasos temporales de transacciones (meh) a robos potenciales (¡oh no!).
El pinning ha sido objeto de años de investigación y desarrollo, dando lugar al formato de transacciones Topológicamente Restringidas Hasta la Confirmación (TRUC), el tipo de salida Pay to Anchor (P2A), la política de Polvo Efímero, el Mempool por Clúster, la retransmisión limitada de paquetes y varias mejoras en la confiabilidad de la retransmisión de transacciones. Estas características están diseñadas para proporcionar garantías más fuertes para propagar reemplazos de tarifas más altas de transacciones compartidas.
Aún así, la gestión adecuada de tarifas implica un costo en forma de transacciones más grandes, lógica de billetera más compleja y manejo de casos extremos poco comunes. Un atajo fácil es hacer un trato con un minero: a cambio de una tarifa, el minero garantiza que sus transacciones serán minadas rápidamente. Esta solución puede resultar más confiable que usar la red peer-to-peer, que puede presentar alta latencia y mala propagación debido a políticas de mempool heterogéneas.
La adopción de la presentación directa al minero puede crecer rápidamente cuando hay interés comercial. Las casas de cambio representan una gran proporción del volumen de transacciones y probablemente prefieren tiempos predecibles a la hora de optimizar tarifas. Aplicaciones populares pueden verse afligidas por ataques de pinning o querer usar transacciones no estándar que las políticas de nodos comunes prohíben. Empresas y custodios preocupados por ataques cuánticos a corto alcance pueden crear un canal privado con un minero.
A medida que el valor extraíble de mineros privados se vuelve necesario para mantenerse competitivo, la red podría deslizarse hacia un modelo de corredores de espacio de bloques centralizados. Estos servicios pueden convertirse en puntos críticos para atacantes y mandatos gubernamentales, socavando la premisa de que convertirse en minero es sin permisos.
Si la red de retransmisión de transacciones se vuelve irrelevante para la operación de nodos, participar en ella también puede parecer innecesario. En este futuro hipotético, ¿reiremos de la idea de que cada nodo en la red retransmite transacciones no confirmadas, de la misma manera que encontramos gracioso que Satoshi imaginara que cada nodo sería un minero?
La ironía es que la centralización de la minería no comienza con colusión abierta o captura regulatoria. Comienza con algunos atajos racionales: acuerdos más eficientes, caminos de retransmisión personalizados u optimizaciones de rendimiento que benefician a sus participantes. Nadie puede detener estos acuerdos. Pero podemos intentar reducir la ventaja competitiva que los servicios privados tienen sobre la red pública: eliminar los vectores de pinning del mempool antes de considerar propuestas de cambios en el consenso que incrementen el potencial de Mevil; hacer que la red pública de retransmisión de transacciones sea un mercado eficiente para ofertar (y actualizar ofertas) por espacio en bloques.
La red peer-to-peer es donde muchas de las ideologías centrales de Bitcoin cobran vida. También representa un desafío de ingeniería con dolorosas compensaciones entre la operación eficiente de nodos, la resistencia a la censura, la alineación de incentivos y la complejidad del protocolo. Cada vez será más difícil a medida que Bitcoin crezca. Cómo debería optar por reconciliar estos objetivos de diseño en competencia queda como un ejercicio para el lector.
Fuente: bitcoinmagazine.com