Por Mengerian
El mes pasado, comenzando el 13 de enero de 2018 y durante un par de días, hubo un gran aumento en el número de transacciones en la red de Bitcoin Cash. No está claro si este aumento repentino fue un ataque de spam, un «test de stress», o algún otro uso desconocido de la red.
Las transacciones parecían «no orgánicas», y no estaban asociadas a ninguna forma conocida de uso legítimo, lo cual podría sugerir una intención impía. Las transacciones forzaron los recursos de algunos nodos, lo cual echó abajo algunos servicios (incluído Yours.org). Por otra parte, la tormenta de transacciones no parecía demasiado hostil, puesto que no reventó el conjunto de UTXO (Unspent Transaction Output: Salidas de transacción no gastadas). Es interesante ver que la tormenta de transacciones incrementó inicialmente el tamaño del conjunto de UTXO, pero según se fueron minando las transacciones el UTXO volvió a su tamaño anterior. También es significativo que a la mayoría de usuarios regulares el evento solo los afectó mínimamente, y muchos probablemente ni se dieron cuenta.
Tanto si esta «tormenta de arena» de transacciones constituyó un ataque como si no, hace plantearse algunos asuntos interesantes. Es una buena oportunidad para considerar la resistencia de la red de Bitcoin Cash a futuros ataques, algunos de los cuales podrían suponer un reto mayor. Ahora es un buen momento para asegurarse de que la red sea resistente.
Aproximaciones económicas y técnicas a la defensa anti-spam
Hay dos maneras principales de pensar sobre la defensa contra los ataques: técnica y económica. Las estrategias técnicas suelen proponerse cuando cierto resquicio técnico aprovechado por el atacante es identificado, con la intención de bloquearlo. La tradicional «prioridad de transacción» de Bitcoin sería un ejemplo de medida técnica: mirar la antigüedad de las monedas y el valor tranferido para identificar qué transacciones es improbable que representen un ataque, y por tanto qué transacciones es seguro permitir sin tarifas o con tarifas muy bajas. El límite al tamaño del bloque es otro ejemplo de medida técnica implementada inicialmente para prevenir ataques de «bloque enorme».
El problema con las defensas exclusivamente técnicas es que a menudo restringen también actividades legítimas. Para prevenir los «ataques spam» de transacciones, o las «tormentas de arena», podríamos proponer rechazar las transacciones que creen demasiadas UTXOs. O podríamos rechazar cadenas largas de transacciones no confirmadas. El problema con esto es que también hay casos de uso legítimos que podrían involucrar la creación de transacciones con estas características. El «agrupamiento» de transacciones, por ejemplo, puede crear transacciones con muchas outputs (salidas). Y si la adopción crece rápidamente, los nuevos propietarios de monedas necesitarán UTXOs creadas para ellos, así que no es obvio dónde corresponde dibujar la línea que separa el ataque del uso legítimo.
Esto nos deja con la defensa económica. La defensa económica no busca imposibilitar el ataque, sino simplemente elevar su coste a muchos múltiplos del coste del uso legítimo. Esto da una ventaja asimétrica a los usuarios legítimos al hacer que el ataque sea mucho más costoso para el atacante que para los defensores. Un problema de las defensas económicas es que a menudo tienen costes externos difíciles de registrar.
En las siguientes secciones, consideraré unas pocas aproximaciones posibles a la defensa anti-spam, y discutiré sus aspectos técnicos y económicos.
La estrategia de «comerse el spam»
Muchos defensores de los bloques grandes proponen simplemente «comerse el spam». Básicamente la idea es que, si los bloques son significativamente mayores que la demanda orgánica típica, entonces se necesitará un gran volumen de spam para llenarlos. Incluso con tarifas de transacción modestas, esto quiere decir que el spammer sufrirá costes significativos antes de llenar los bloques lo suficiente como para desplazar las transacciones regulares. Dado que el ataque de spam cuesta mucho, y cuesta poco (o nada) a los usuarios legítimos, esto inclina la balanza del poder en contra del ataque, haciéndolo inútil.
El problema de esta aproximación, sin embargo, es que las tarifas de transacción de los usuarios no son el único coste en el que se incurre. El spam puede añadir otros costes, puesto que genera más datos a procesar por los nodos de la red. También puede conducir a incrementos del conjunto UTXO, lo cual impone costes futuros y constantes, no necesariamente asumidos por quienes hacen cumplir las políticas de selección de transacciones.
La estrategia de «rechazar el spam»
Una solución aparentemente obvia y fácil es simplemente rechazar el spam. No transmitirlo, ni aceptarlo en la «mempool», ni minarlo en los bloques. Usando este método, podría tenerse un límite al tamaño del bloque lo suficientemente grande como para aceptar todas las transacciones legítimas, pero no más que eso.
Sin embargo, esto no es tan fácil como parece. Una vez que empezamos a pensar en cómo implementar esta política, comenzamos a encontrar problemas.
Un problema importante es que no siempre es obvio qué transacciones son «legítimas». Esto pone a los desarrolladores en la posición de decidir qué es legítimo y qué no. En el pasado, hemos visto debates sobre qué transacciones deberían permitirse, por ejemplo si se debería permitir poner datos arbitrarios en OP_RETURN, o si las transacciones de Satoshidice son un uso legítimo del espacio en el bloque. Algún caso de uso legítimo podría parecer spam. Por ejemplo, servicios tales como Yours.org podrían encontrar útil generar largas cadenas de transacciones no confirmadas, las cuales pueden asemejarse a patrones de generación de spam.
Enfoques híbridos
Históricamente, Bitcoin ha empleado estrategias híbridas para limitar el spam. Métricas técnicas tales como la «antigüedad de la moneda» y la cantidad enviada se usaron para definir algunas transacciones como de «prioridad alta», y una porción del bloque fue reservada para ellas. En la era previa a que los bloques estuviesen llenos, estas transacciones de alta prioridad se confirmaban con tarifa cero.
Al mismo tiempo, el resto del bloque tenía espacio más que suficiente para incluir las transacciones con tarifas. Esto permitía a los usuarios legítimos de transacciones de prioridad no elevada meter su transacción en los bloques, con un tope que servía para desincentivar el spam. Un problema de este enfoque, sin embargo, es decidir cuán grandes hay que permitir que sean los bloques, y podemos ver que el sistema se estropea cuando los bloques se llenan, como sucedió en la red de Bitcoin Core.
Política de comisiones progresivas
Si se quisiera llevar este concepto más allá, en lugar de dos «contenedores», podríamos extenderlo a muchos contenedores. La manera en que esto funcionaría sería que los mineros aplicarían reglas cada vez más estrictas para aceptar las transacciones según vayan haciéndose más grandes los bloques que construyen. Por ejemplo, el primer MB de espacio en el bloque podría permitir tarifas muy bajas, o transacciones gratuitas; el siguiente MB (hasta bloques de 2MB) aplicaría reglas más estrictas en el crecimiento del UTXO y requeriría algunas tarifas; el siguiente MB aplicaría reglas aún más estrictas y requeriría tarifas más elevadas, y así sucesivamente hasta un tamaño de bloque muy grande. Esto tendría como resultado una política de «tarifa progresiva» que incrementaría la tarifa exigida al ir creciendo los bloques.
La ventaja de esta aproximación es que deja margen para un límite al tamaño máximo de bloque muy grande, mientras sigue limitando la capacidad de los spammers de congestionar la red. También equilibraría los costes que los bloques demasiado grandes imponen a la infraestructura de la red con los costes que los bloques demasiado pequeños imponen mediante tarifas a los usuarios. Según se elevase la demanda de inclusión de transacciones, las tarifas se elevarían gradualmente, manteniéndose dentro de lo razonable. Con el crecimiento de la red, y el consecuente aumento de las tarifas, el tamaño de los contenedores podría incrementarse.
Hacia una auténtica solución de mercado
Leer todas estas aproximaciones a la política de selección de transacciones podría producirte una sensación desagradable, y debería. Ninguno de los enfoques es una solución realmente elegante y satisfactoria al problema. El problema es que las diferentes políticas implican diferentes balances entre costos y beneficios, y sin un precio de mercado real es imposible saber con precisión cuáles son los apropiados. Es un problema de cálculo que no puede resolverse mediante planificación central.
Por ejemplo, sabemos que un UTXO grande tiene costes, muchos de los cuales serán soportados en el futuro. Pero, si Bitcoin Cash está destinado a crecer hacia una adopción global, el UTXO debe crecer. Así que, ¿cuánto debería desincentivarse la creación de UTXO? ¿Dónde está el balance adecuado?
Este problema es evidente con el «descuento Segwit«, que da a la porción de «testigo» de las transacciones Segwit 1/4 de la importancia que al resto de la transacción, para desincentivar la creación de UTXO. ¿Por qué 1/4? La elección es completamente arbitraria, basada en poco más que intuición.
La única manera de salir de este rompecabezas es mediante mercados auténticos. Varias ideas acerca de cómo podría funcionar esto han sido propuestas a lo largo de los años. Un buen ejemplo son los artículos de Justus Ranvier.
Imaginemos cómo podría funcionar esto con el conjunto UTXO. Actualmente todos los mineros deben mantener un registro del UTXO para comprobar que las transacciones no se gasten por duplicado. ¿Pero quién se beneficia del registro de las outputs (salidas) no gastadas? Es el «propietario» de la moneda, que quiere ser capaz de poder gastarla eventualmente, quien realmente necesita un registro de la output ahorrada que ha de conservarse. Así que, ¿por qué no responsabilizar al titular de la moneda de guardar las outputs no gastadas? Esto es precisamente lo que permite la reciente propuesta «UTXO Bit Vector» de Gavin Andresen. Con este plan, no necesitaríamos preocuparnos por el tamaño global de todo el conjunto UTXO, dado que cada poseedor de monedas tendría la responsabilidad de almacenar los datos necesarios, y de proporcionar una prueba de que la Salida No Gastada (Unspent Output) existe cuando gaste sus monedas.
El único modo de asignar racionalmente los recursos escasos es a través del mecanismo de precios en un mercado realmente libre. Puede que lleve algo de tiempo desarrollar todos los mecanismos que se necesitan para facilitar la emergencia de mercados para todos los recursos escasos de la red Bitcoin Cash, y algunos recursos solo comenzarán a escasear después de que la red alcance ciertas dimensiones. Pero Bicoin Cash ya es la moneda más firmemente apoyada en los principios del libre mercado, así que cabe esperar nuevos desarrollos en ese sentido con el paso del tiempo.