Propuesta de Mejora a la Minería de Blockchain

En estas semanas, lei el post 25-second irreversible confirmations for instant payments de @sdlerner, donde menciona:

Bitcoin forwards a block by packing the block header with all the transactions contained in the block. This strategy, while being the most easy to analyze, is known to perform badly, both regarding block propagation latency and bandwidth usage. Since the transactions on a block are generally already known to the network, there is no benefit in transmitting them again.

Las transacciones incluidas en un bloque podrían ser sustituidas por una lista de hashes. El nodo que recibe la información del nuevo bloque minado podría reconstruir las transacciones a partir de los hashes. Tiene un conjunto interno de transacciones pendientes: de ahi puede traducir los hashes a transacciones. Los hashes que no correspondan a transacciones conocidas deben ser entonces pedidas al otro nodo. Otra alternativa es enviar el encabezamiento del bloque:

…Still another improvement is to forward the block header before even checking the transactions, and only checking the block PoW and height at forward time.Still another improvement is to forward the block header before even checking the transactions, and only checking the block PoW and height at forward time. This allows the header to spread over the network in less than a second. Nodes can then start mining an empty block on top of the header even if the transactions are still missing, during a fixed interval. After that interval, they resume mining in whatever block they were mining before.

(el énfasis es mío) No soy experto en minería ni eficiencia de red, pero puedo proponer una mejora a esta alternativa, al menos en Ethereum, donde existe el concepto de cuenta. En vez de propagar solamente el header, el nodo remoto puede enviar además un predicado de cuentas P(acc) con las siguientes propiedades:

– P(acc) es verdadero para cualquier cuenta involucrada en una transacción del bloque recibido

Una “cuenta involucrada en una transacción” es tanto la cuenta que envía fondos como la que los recibo. Debemos considerar las cuentas que reciben SI SON CONTRATOS, pues pueden cambiar de estado más allá de recibir fondos. En una transacción que sea “solo transferencia de fondos”, debemos considerar involucrada a la cuenta que envía. El punto a entender es: el nodo que recibe la información resumida del nuevo bloque minado NO PUEDE ESTAR seguro del estado de cualquier cuenta involucrada en las transacciones de ese bloque. De las otras cuentas, todas mantienen EL MISMO ESTADO que antes de ese nuevo bloque minado.

Entonces, toda transacción pendiente que tenga cuenta enviadora con P(acc) en falso, y (cuenta receptora sin contrato O con tipo contrato con P(acc) en falso), puede ser incluida en el armado de un nuevo bloque.

La mejora propuesta consiste: en vez de comenzar a minar un bloque vacío, el nodo receptor puede comenzar a minar el bloque usando transacciones pendientes, que cumplan con la condición anterior. Las cuentas que no ven afectado su estado, pueden participar de las transacciones del nuevo bloque.

¿Cómo enviar ese predicado? Una opción es tener un Bloom filter. De nuevo, no conozco mucho de filtros Bloom, pero puedo imaginar una lista de bits. Como ejemplo concreto, usaré 16 bits. Si una cuenta, involucrada en una transacción, tiene una dirección pública que termina en el hexadecimal 0, prendo el primer bit. Si la cuenta involucrada tiene dirección que termina en hexadecimal A, prendo el bit undécimo. De esta manera, puede haber falsos positivos en este filtro, pero cada cuenta involucrada en una transacción del bloque satisface el predicado, y no será incluida en el próximo bloque.

La longitud en bits de este campo podría ser optimizada de acuerdo a la cantidad media de transacciones incluidas por bloque. Si el número de transacciones (o cuentas involucradas) por bloque es alrededor de 16, entonces la longitud de este campo podría ser de 32 bits, como para tener alguna probabilidad de transacciones pendientes con cuentas que no satisfagan el filtro, y puedan ser minadas inmediatamente.

¿Podría esta propuesta ser adaptada para Bitcoin y otros similares? No parece sencillo, al no existir el concepto de cuenta. Habría que usar un filtro de transacciones, pero no siempre podemos saber cuáles de las transacciones pendientes es candidata a minar, porque el nodo no puede ASEGURAR que conozca TODAS las transacciones involucradas: podría haber latencia en la diseminación de las transacciones. Pero supongo que el nodo puede arriesgarse igual a producir un bloque, si la probabilidad de insertar una transacción inválida es baja.

No sé evaluar si esta propuesta puede ser implementada, o si agrega valor, pero me pareción un camino interesante para explorar.

Nota: Desde hace tres meses, soy miembro del equipo de desarrollo de @RSKsmart donde @sdlerner es el Chief Scientific Officer.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in Bitcoin, Blockchain, Ethereum. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *