Guia para construir una blockchain. Parte 9

Este es un post de código intensivo. En los dos post anteriores, hemos examinado la
teoría de las transacciones de criptomonedas y visto cómo se puede utilizar el merkle root para verificar que las transacciones de un bloque no hayan sido manipuladas. En este post vamos a poner en práctica este conocimiento teórico mediante la implementación de código Python para procesamiento de transacciones de blancoin.

procesamiento de las transacciones

El flujo de trabajo de procesamiento de transacciones es el siguiente. Una entidad crea un
transacción y luego coloca la transacción en la red peer-to-peer de Blancoin para su proceso. Luego, los nodos de minería de blancoin recogen la transacción. Estos nodos
se dedican a la actividad de procesamiento de transacciones y bloques de minería con el fin de obtener recompensas.

En el caso de Bitcoin, la recompensa es la emisión de algunos bitcoins nuevos y la recolección de tarifas de transacción que se adjuntan a las transacciones en el bloque que se extrae correctamente por el nodo. Una transacción puede tener una tarifa de transacción cero. La cantidad de la tarifa de transacción queda a discreción exclusiva de la entidad que transfiere valor. Un minero puede optar por incluir una transacción en un bloque que está minando o rechazarla. Por lo tanto, diferentes mineros normalmente extraerán diferentes bloques al mismo tiempo. Si un minero logra agregar un bloque a la cadena de bloques, decimos que el minero ha minado el bloque. El flujo de trabajo de procesamiento de transacciones es idéntico en Blancoin. Cuando un minero recibe un bloque, lo primero que hará es verificar la integridad de la transacción. Verificación significa que la transacción se examina para asegúrarse de que contiene valores válidos. Por ejemplo, el locktime de la transacción no será válido si es un número negativo. Un aspecto importante de la verificación es asegurarse de que el transmisor de valor esté gastando los valores que posee.

Este post aborda la validación de transacciones. Si una transacción es válida, puede convertirse en parte de un bloque que un minero pretende minar. Después de que un minero ha extraído un bloque, agrega el bloque a su blockchain local. El minero luego transmite el bloque recién extraído a la red Blancoin. Otros mineros reciben este bloque y luego lo agregan a su blockchain local. Supongamos que un minero extrae un bloque con una transacción no válida. Puede que la quiera agregar maliciosamente a este bloque a su copia local de su blockchain. Pero otros mineros se negarán a agregar el bloque a sus blockchains locales, porque verán que el bloque contiene una transacción no válida. Vale la pena señalar que los mineros en una red de blancoin pueden tener blockchainns locales que difieren entre sí. Pero debido al mecanismo de consenso distribuido, la red siempre convergerá a una cadena de bloques dominante. Discutiremos esto en un post futuro. Debido a la forma en que funciona el consenso distribuido, la confianza no es necesaria en la red. No nos importa que un nodo minero esté actuando de mala fe. Esta es la visión revolucionaria de Satoshi Nakamoto.
Muy bien, comencemos con el tutorial del código. Copie el código del programa que sigue
en un archivo llamado tx.py y guárdelo en el directorio transactions.

En lenguajes tipados dinámicamente como Python, el proceso de depuración consiste principalmente en detectar y corregir errores en tiempo de ejecución. Esta carga de trabajo se eleva exponencialmente a medida que aumenta el tamaño del programa. Este factor hace que los lenguajes interpretados de tipo dinámico sean inadecuados para el desarrollo de programas a gran escala. Go y C ++ estan fuertemente tipados y por ello, los programas Go y C ++ simplemente rechazarán la compilacion si hay un error de tipo en el programa. En Go, una vez que el programa ha compilado, la depuración de errores en tiempo de ejecución suele ser muy rápido (del orden de O(n)).

La función importante en el módulo tx es validate_transaction; verifica la integridad de una transacción. Esta función realiza las siguientes pruebas:

Verifica que todos los atributos de la transaccion estan presentes
El locktime es mayor o igual a cero
El valor de locktime es menor que el maximo especificado en el archivo hconfig
El numero de version es valido
El id de la transaccion tiene formato correcto
La lista Vin tiene más de un item si no es el bloque genesis o si la transaccion no es de tipo coinbase
Para las transacciones del bloque genesis o para una transaccion coinbase, la lista Vin esta vacia
La lista Vin no es más gransde que lo especificado en el archivo hconfig
La lista Vin tiene formato adecuado
La lista Vout es mayor que cero
La lista Vout no es más grande que el especificado por el archivo hconfig
La lista Vout tiene formato valido
La transaccion implementa un script de tipo p2pkh
La referencia a la transaccion previa cuya output es consumida es valida
La valor total gastado es menor o igual al total gastable
Todos los valores gastados en la transaccion son mayores que cero
Las inputs de la transaccion deben de ser desbloqueadas
Una transaccion coinbase no se puede consumir antes de que su locktine haya expirado

En el módulo tx, la función prevtx_value hace referencia a un valor no gastado en una transacción. Esta función no se tiene en cuenta en las pruebas unitarias ya que no hemos implementado una base de datos LevelDB para obtener cantidades de transacciones no gastadas. Examinaremos las bases de datos de Blancoin en el próximo post. La función transaction_fee calcula la tarifa de transacción para la transacción.

La función unlock_transaction_fragment determina si los valores de una transacción se puede desbloquear para su uso en la transacción actual. Esta función implementa el procesador de pila p2pkhash de los que se habló anteriormente.