El elemento central de cada criptomoneda es un libro mayor p煤blico llamado blockchain, que enlaza los bloques entre s铆.
Dado que los bloques en la cadena est谩n ordenados, el historial completo de transacciones se mantiene en el blockchain. Los bloques subsiguientes tienen alturas crecientes que difieren en uno. Cada bloque puede contener hasta 6,000 transacciones (en la red p煤blica), siendo este valor configurable por red.
Los bloques de Bitxor se completan cada 30 segundos, lo que permite que las transacciones se confirmen lo suficientemente r谩pido para su uso diario.
Los nodos almacenan los bloques en una forma serializada de la siguiente manera:
Versi贸n: 0x01
EntityType: 0x8143
En l铆nea:
Propiedad |
Tipo |
Descripci贸n |
|---|---|---|
height |
Altura del blockchain. Cada bloque tiene una altura 煤nica. Los bloques subsiguientes difieren en altura en 1. |
|
timestamp |
N煤mero de milisegundos transcurridos desde la creaci贸n del bloque g茅nesis. |
|
difficulty |
Determina la dificultad para encontrar un nuevo bloque, basado en los bloques anteriores. |
|
generationHashProof |
Prueba de generaci贸n de hash. |
|
previousBlockHash |
Hash del bloque anterior. |
|
transactionsHash |
Hash de las transacciones en este bloque. |
|
receiptsHash |
Hash de los recibos generados por este bloque. |
|
stateHash |
Hash del estado global de la cadena en este bloque. |
|
beneficiaryAddress |
Direcci贸n del beneficiario opcional designado por el recolector. |
|
feeMultiplier |
Multiplicador de tarifas aplicado a las transacciones del bloque. |
|
blockHeader_Reserved1 |
uint32 |
Relleno reservado para alinear el final del encabezado del bloque en un l铆mite de 8 bytes. |
Bitxor llama al primer bloque en la cadena el bloque g茅nesis. El primer bloque se define antes de lanzar una nueva red y establece la distribuci贸n de los tokens de la moneda de la red.
El proceso de creaci贸n de los bloques subsiguientes se llama recolecci贸n.
Los bloques son creados por cuentas, que son elegidas por el algoritmo de consenso en base a su puntuaci贸n de importancia. El algoritmo de consenso determina una nueva cuenta para recolectar el bloque subsiguiente despu茅s de cada creaci贸n de bloque.
La cuenta recolectora recibe las tarifas por las transacciones agregadas en el bloque y los tokens creados por inflaci贸n. Esto brinda al recolector un incentivo para agregar tantas transacciones como sea posible al bloque.
Para garantizar tiempos de respuesta r谩pidos, el blockchain de Bitxor est谩 dise帽ado de tal manera que, en caso de una falla o partici贸n de la red, las solicitudes a煤n se responden y las transacciones se agregan al blockchain.
Esto conduce naturalmente a las bifurcaciones, es decir, se crean cadenas diferentes en las partes desconectadas de la red. Una vez que se restablece la conectividad, se lleva a cabo la resoluci贸n de bifurcaci贸n para fusionar las cadenas divergentes en una sola.
Este proceso puede requerir que algunos bloques se reversen: se eliminan del blockchain, por lo que todas sus transacciones pasan al estado no confirmado y deben ser validadas nuevamente. En este punto, existe la posibilidad de que sus plazos expiren sin volver a confirmarse.
Por esta raz贸n, las transacciones confirmadas (que ya se han agregado al blockchain) no se pueden considerar confiables hasta que su bloque se haya finalizado, como se muestra a continuaci贸n.
Este es el proceso de hacer cambios en un libro mayor blockchain de forma permanente. Antes de que los bloques alcancen la finalidad, a煤n pueden ser revertidos en caso de una falla o partici贸n de la red. Sin embargo, una vez que los bloques se finalizan, se vuelven inmutables.
La finalizaci贸n ocurre en rondas. En cada ronda, un algoritmo de ordenaci贸n selecciona las cuentas responsables de validar todos los bloques pendientes de finalizaci贸n. Si un bloque propuesto coincide con los registros de un nodo de una cuenta, la cuenta emite un voto positivo.
Una vez que m谩s del 67% de las apuestas seleccionadas para votar han emitido votos positivos, el bloque se finaliza. En ese momento, las transacciones vinculadas al bloque se registran de forma permanente en el blockchain.
Note
Para ser elegible como votante, una cuenta debe:
Ser el propietario de un nodo.
Tener al menos minVoterBalance unidades de la moneda de la red.
Estar registrada como votante anunciando una VotingKeyLinkTransaction a la red.
Cuando hay baja conectividad o muchos actores maliciosos, la finalizaci贸n puede llevar m谩s tiempo de lo habitual y generar grandes reversiones. Sin embargo, ning煤n bloque finalizado ser谩 revertido.
Por lo tanto, los clientes que conf铆an en la inmutabilidad del historial del blockchain solo deben confiar en las transacciones de bloques finalizados.
Las rondas de finalizaci贸n en realidad se llaman 茅pocas y ocurren cada 1440 bloques o aproximadamente 12 horas (consultar votingSetGrouping en las propiedades de la red). Cada 茅poca se divide en m煤ltiples Puntos de Finalizaci贸n (consultar la secci贸n Technical Reference 15.2 para m谩s detalles).
Id |
Tipo |
Descripci贸n |
|---|---|---|
0x4143 |
Vincula una cuenta con una clave p煤blica BLS. Requerido para los operadores de nodos que deseen votar por bloques finalizados. |
Conseguir un bloque por altura
Title overline too short.
Title overline too short.
Last updated by John Doe
on 2023‑06‑07.
