Posteriormente en este post, mostraremos cómo el ScriptSig asegura que solo Alice puede desbloquear la salida de la transacción anterior de 1.08 blancoin y cómo el ScriptPubKey asegura que solo Smith podrá desbloquear la salida de la transacción de un blancoin. Una transacción solo se considera válida si tanto el ScriptSig como el ScriptPubKey tiene éxito sin errores. Bitcoin y Blancoin implementan un procesador de pila simple para verificar que estos scripts se ejecuten correctamente. Habrás notado que desbloqueamos 1.08 blancoin pero transferimos solo 1
blancoin a Smith. ¿Qué ha pasado con el resto de 0,08 blancoin? Este exceso de monto se denomina tarifa de transacción o feed. Es un incentivo para los mineros incluyan la transaccion de Alice en un bloque que los mineros pretenden extraer. Si un minero extrae con éxito un bloque que contiene la transacción de Alice, entonces el minero puede reclamar estos 0.08 blancoin.
La lógica anterior se puede aplicar para manejar las entradas de varias transacciones anteriores que contienen productos que Alice posee (habrá más de una transacción anterior vout de lista), y la transacción puede dirigir salidas a varias direcciones de Blancoin(la transacción tendrá más de un elemento vout).
Los pasos que se han descrito anteriormente, normalmente los llevaría a cabo la wallet de Alice. En una transacción típica de moneda fiduciaria, en una caja registradora, entregas algo de dinero y recuperas algo de cambio. El cambio se maneja de la siguiente manera en una criptomoneda. Suponga que Alice tiene una transacción anterior con 5.08 blancoin y tiene la intención de utilizar estos blancoin en su transacción con Smith. Alice crearía una dirección pública y dirija 4 blancoin a esta dirección. Por lo tanto, Smith recibiría un blancoin a la dirección que le dio a Alice, Alice recibiría cambio de 4 blancoin en la dirección que ella ha creado, y la tarifa de transacción sería de 0,08 helios. Este aspecto de una transacción también sería manejado de forma transparente por una wallet de blancoin.
scriptsig y scriptpubkey
El ScriptPubKey en un elemento vout de una transacción que se usa para bloquear el valor especificado en este elemento. Solo el propietario de la dirección pública a la que pertenece este valor transferido puede desbloquear el valor.
El ScriptSig en un elemento Vin de una transacción describe un valor en una
transacción que se consumirá en la presente transacción. Este valor será transferido a una o más direcciones públicas. El valor consumido se puede identificar completamente de la identificación de la transacción anterior y el índice del elemento vout en esta transacción. El ScriptSig asegura que este valor en la anterior transacción solo puede ser transferida por la entidad propietaria del valor.
Observe que cada elemento vin en una transacción hace referencia exactamente a un elemento vout en una transacción anterior y dicho elemento vin debe consumir la totalidad del valor en este elemento vout.
Los scripts ScriptPubKey y ScriptSig son listas simples. Son procesados por un
lenguaje de pila simple que ahora describiemos.
Un elemento (elemento de lista) en estos scripts es un símbolo de operador o un
operando. Llamaremos código de operación a un símbolo de operador. Un operando es un valor; por ejemplo, el entero 5 y la cadena «hola mundo» son operandos. Los códigos de operación son operaciones simbólicas que realizan operaciones en operandos. Por ejemplo, el operador de suma + es un código de operación que opera con números. Cada elemento de la lista contiene exactamente un código de operación o un operando. Los códigos de operación se designan entre paréntesis angulares.
Una pila de ejecución es una lista de códigos de operación y operandos. Por ejemplo, ScriptPubKey y ScriptSig son ambas pilas de ejecución.
Cada elemento de las listas vin y vout es un código de operación o un operando. Cada lista
se comporta como una pila y, por lo tanto, solo permite dos operaciones en la pila, PUSH
y POP. La operación POP saca un elemento del encabezado de una pila y un PUSH
La operación empuja un elemento hacia la cabeza de una pila.
Finalmente, también especificamos una pila de resultados. Un código de operación en la pila de ejecución funcionará en los valores de la pila de resultados, y el resultado de la operación puede volver a insertarse en la pila de resultados si la semántica del código de operación así lo requiere. Si el valor de la ejecución es un operando, simplemente se inserta en la pila de resultados.
Los códigos de operación válidos son DUP, HASH-160, PK_HASH, EQ-VERIFY y CHECK-SIG. El significado de estos códigos de operación se describe a continuación. Los operandos válidos deben ser cadenas. Esta especificación describe un lenguaje de pila simple. Como se indicó anteriormente, los códigos de operación se indicarán encerrándolos entre corchetes angulares. Los operandos, que denotan valores, no se incluirán entre corchetes angulares. El código de operación que se va a ejecutar se indicará mediante un puntero de ejecución (una flecha gruesa).
Vamos a examinar los scripts P2PKHASH . Estos tipos de scripts transfieren valor de una sola entidad a otra sola entidad. Scripts P2PKHASH constituyen del 98% al 99% de todas las transacciones en redes típicas de criptomonedas.
script scriptsig
La lista ScriptSig en cada uno de los elementos vin de una transacción P2PKHASH tiene la
siguiente estructura:
Un script ScriptSig está compuesto por dos operandos. PUBKEY es la clave pública
(cadena hexadecimal) que se utilizó para crear la dirección pública que recibió la
salida de la transacción anterior.
SIG es una firma que se crea al firmar el valor:
RIPEMD-160(SHA256(public key of previous transaction input))Este valor también está disponible en el elemento vout de la transacción anterior.
script scriptpubkey
Considere una transacción P2PKHASH. En este tipo de transacción, el ScriptPubKey en
cada uno de los elementos vout de la transacción se puede visualizar como la pila en el lado izquierdo:
Este diagrama también muestra una pila de resultados vacía en el lado derecho. Esta pila mantendrá operandos sobre los que actuarán los códigos de operación en la pila de ejecución.
El significado de los códigos de operación en la pila de ejecución es el siguiente: DUP
significa tomar el valor al principio de la pila de resultados y enviar una copia de
este valor de nuevo en la pila de resultados. HASH-160 significa colocar el valor al principio de la pila de resultados y generar el valor RIPEMD-160 (SHA-256 (valor emergente)) y luego poner el la cima de stack el hash del mensaje. PK-HASH es un string. EQ-VERIFY significa extraer dos elementos de la pila de resultados y verificar
que son iguales. CHECK-SIG significa extraer dos elementos de la pila de resultados y verificar la firma.
mecanismo de scriptpubkey y scriptsig
Veamos cómo se utilizan el ScriptSig y ScriptPubKey para validar una transaccion P2PKHASH. Dicha transacción es válida si ambos scripts se ejecutan sin error.
Una transacción válida desbloquea salidas de transacciones anteriores que se utilizan en la transacción. Usaremos nuestro ejemplo anterior donde Alice transfiere una moneda de blancoin a Smith. En primer lugar, concatenamos las listas ScriptSig y ScriptPubKey y obtenemos la siguiente pila de ejecución (el encabezado de esta lista está en la parte superior):
Ahora ejecutaremos los códigos de operación en esta pila. Cualquier operando que esté presente en esta pila simplemente se insertará en la pila de resultados. La pila de ejecución indicará la siguiente operación a realizar con un puntero de ejecución, que es una flecha gruesa:
La primera operación es SIG. Alice toma el valor RIPEMD-160 (SHA256 (clave pública))
que está disponible en el elemento ScriptPubKey del vout de la transacción anterior
elemento y genera la firma de este valor. Este valor se inserta en el resultado de la pila. Las dos pilas ahora se ven así:
La siguiente operación está en PUBKEY, que es la clave pública que Alice usó para generar
la dirección en la transacción anterior cuya salida está siendo consumida por Alice. Esta
La cadena hexadecimal de clave pública se inserta en la pila de resultados. Las dos pilas ahora estan así:
El siguiente código de operación es DUP. Esta operación requiere que el elemento en la cima de la pila de resultados sea un string. Si lo es, lo duplicará y volverá a colocar en la pila de resultados una cópia. Después de esta operación,
las dos pilas se parecen asi:
El siguiente código de operación HASH-160 requiere el valor al principio de la pila de resultados para ser eliminado y el valor RIPEMD-160 (SHA256 (valor emergente)) para ser calculado y luego puesto en la cima de la pila de resultados. El resultado de esta operación está en la imagen:
La siguiente operación pone el valor PK-HASH a la pila de resultados. PK-HASH
se creó en el momento en que se creó la última transacción; su valor es RIPEMD-160 (SHA256(clave pública de la entrada de transacción anterior)) :
El siguiente comando en la pila de código de operación es EQ-VERIFY. Este código de operación requiere que comparemos los dos valores al principio de la pila de resultados. Si los dos hashes RIPEMD-160 no son iguales, el desbloqueo de la entrada falla.
Si la operación tiene éxito, las dos pilas se ven como en la imagen:
El último código de operación CHECK-SIG verifica la transacción anterior de la siguiente manera:
- Dada la clave pública que Alice usó para la transacción anterior
salida, se verifca que la clave privada correspondiente a esta clave pública ha generado la firma del valor RIPEMD-160 (SHA256 (clave pública))
2. Si la firma es válida, saca los dos elementos de la pila de resultados.
El elemento vin de la transacción ha desbloqueado válidamente la salida
de la transacción anterior.
3. Si todos los elementos vin en la transacción actual están desbloqueados, decimos que el
la transacción está desbloqueada.
transacciones multifirma
Considere una cuenta corriente en moneda fiduciaria que requiere que ambos cónyuges firmen un cheque. La transferencia válida de valor en este caso requiere la firma de ambos cónyuges. La entrega de dicho cheque es una transacción de firma múltiple o firma múltiple. En una red de criptomonedas, una transacción multifirma se refiere a una transacción que involucra a más de una entidad, donde cada entidad proporciona una dirección pública para la transacción. Entonces al menos m de estas n entidades deben proporcionar sus firmas antes de que se transfiera el valor a un destinatario. Este tipo de transacción se denomina frecuentemente transacción n: m; es implementado a través de un script que verifica múltiples firmas. Nuestro ejemplo de comprobación es un
Transacción 2: 2. Hay varios casos de uso interesantes para transacciones multisig.
En una transacción de depósito en garantía 2: 2, una de las partes es un árbitro neutral cuya función es supervisar que se cumplan las condiciones acordadas para la transferencia de valor. El árbitro solo proporciona su firma si se cumplen estas condiciones. También podemos tener m: n transacciones de depósito en garantía donde m <n árbitros tienen que firmar una transacción. En una transacción de autenticación de dos factores, una salida en la transacción anterior es bloqueada por dos direcciones públicas. La primera dirección pública la genera una wallet en línea. La segunda dirección se genera a partir de claves que se almacenan en frío. La salida de la transacción anterior se transferirá cuando se verifiquen ambas firmas.
El lenguaje de pila simple que hemos especificado se puede utilizar para crear scripts para transacciones multifirma, así como otros escenarios. Tenga en cuenta que, dado que este lenguaje de pila no admite construcciones de flujo de control (como if … else if …) y bucles, no es Turing completo. Esta fue una omisión deliberada de Satoshi Nakamoto ya que fueun objetivo de diseño para hacer que el procesamiento de guiones sea rápido, simple y seguro.
comisiones de transaccion
Una persona que transfiere valor en una transacción generalmente brinda a los mineros un incentivo para incluir la transacción en un nuevo bloque que se extraerá. Esta tarifa de transacción es la diferencia entre la suma de las entradas y las salidas. No es necesario proporcionar una tarifa de transacción, pero el no hacerlo puede retrasar significativamente el procesamiento de la transacción, ya que los mineros no están incentivados para incluir la transacción en bloques candidatos para ser extraídos.
validacion de las transacciones
Una vez que se ha creado una transacción de blancoin, ésta se transmite por la red peer-to-peer. Un minero que reciba esta nueva transacción puede optar por incluirla en un bloque que él está minando. La decisión del minero de incluir la transacción se verá parcialmente influenciada por la tarifa de transacción ofrecida por la transacción.
Antes de incluir la transacción en un bloque, el minero verificará la transacción para
determinar su validez. Solo las transacciones válidas se incluirán en el bloque que se va a extraer.
Si un minero extrae un bloque que tiene una transacción no válida, otros nodos de la red se negarán a incorporar este nuevo bloque en sus versiones locales de la blockchain ya que cada nodo que recibe un bloque minado también prueba la validez del bloque como las transacciones en el bloque.
Estas son algunas de las pruebas que se realizan en una transacción para validarla:
- La sintaxis de la transacción es válida; esto significa que los campos de la transacción están presentes y sus tipos son válidos.
- Las entradas de la transacción son números enteros positivos. En particular, no son números de coma flotante.
- Las salidas de la transacción son números enteros positivos. En particular, no son números de coma flotante.
- Las entradas y salidas de las transacciones no son inferiores a un centavo de blancoin
- La suma de las entradas de la transacción es menor que el valor de MAX_BLANCOIN_COINS en el módulo hconfig.
- La suma de las salidas de la transacción es menor que el valor de MAX_BLANCOIN_COINS en el módulo hconfig.
- La suma de las entradas de la transacción es igual o mayor que la suma de las salidas de la transacción.
- El locktime de la transacción no es menor que cero.
- El locktime no es mayor que el valor de LOCKTIME_INTERVAL en el módulo hconfig
- Cada transacción tiene al menos 100 bytes de longitud.
- El número de entradas es menor que MAX_INPUTS en elmódulo hconfig
- El número de salidas es menor que MAX_OUTPUTS enel módulo hconfig.
- El ScriptSig tiene valores válidos.
- El ScriptPubKey tiene valores válidos.
- Los ScriptSig y ScriptPubKey logran transferir valor.
- Las salidas de una transaccion coinbase no se gastan hasta que la blockchain crece en un numero de bloques COINBASE_INTERVAL en el que se encuentra la transacción de coinbase. Hablaremos de las transacciones de coinbase posteriormente.
- Una transacción de coinbase no tiene ninguna entrada (la lista de vin está vacía)
- El bloque génesis no tiene entradas.
En el próximo post, estudiaremos los árboles de Merkle. Estas estructuras de árbol se utilizan para determinar si se ha manipulado una lista de transacciones. Los árboles Merkle también pueden ser utilizados para determinar si una transacción en particular está en un bloque.
BlockchainLanzarote 