Protocolo#
Detalles Prácticos Criptográficos#
Descripción#
Esta sección describe todos los detalles de los algoritmos criptográficos que se utilizan para:
Cree claves públicas y privadas a partir de semillas.
Crear direcciones a partir de claves públicas.
Creación de bloques y firma de transacciones.
Usamos los algoritmos Blake2b256 y Keccak256 (en forma de cadena hash) para crear hashes criptográficos. Y Curve25519 (ED25519 con claves X25519) para crear y verificar firmas. Base58 para crear la forma de cadena de bytes.
Codificación de Bytes Base58#
Todas las matrices de bytes en el proyecto están codificadas por el algoritmo Base58 con el alfabeto de Bitcoin para que sea más fácil de leer para los humanos (legibilidad del texto).
Ejemplo
La cadena teststring está codificada en los bytes \([5, 83, 9, -20, 82, -65, 120, -11]\). Los bytes \([1, 2, 3, 4, 5]\) están codificados en la cadena 7bWpTW.
Creación de una Clave Privada desde una Semilla#
Una cadena semilla es una representación de la entropía, a partir de la cual puede volver a crear de manera determinista todas las claves privadas para una billetera. Debe ser lo suficientemente largo para que la probabilidad de selección sea despreciable y poco realista. De hecho, la semilla debe ser una matriz de bytes, pero para facilitar la memorización, lite wallet usa Brainwallet, para garantizar que la semilla esté compuesta de palabras y sea fácil de escribir o recordar. La aplicación toma los bytes UTF-8 de la cadena y los usa para crear claves y direcciones. Por ejemplo,
seed string manage manual recall harvest series desert melt police rose hollow moral pledge kitten position add
Después de leer esta cadena como bytes UTF-8 y codificarlos en Base58, la cadena se codificará como:
xrv7ffrv2A9g5pKSxt7gHGrPYJgRnsEMDyc4G7srbia6PhXYLDKVsDxnqsEqhAVbbko7N1tDyaSrWCZBoMyvdwaFNjWNPjKdcoZTKbKr2Vw9vu53Uf4dYpyWCyvfPbRskHfgt9q
Una cadena semilla está involucrada en la creación de claves privadas. Para crear una clave privada utilizando la billetera web oficial o el nodo, a \(4\) bytes del campo int “nonce” (representación big-endian), que inicialmente tiene un valor de \(0\) y aumenta cada vez que crea la nueva dirección, debe anteponerse a los bytes iniciales. Luego usamos esta matriz de bytes para calcular hash keccak256 (blake2b256 (bytes)). Esta matriz resultante de bytes la llamamos semilla de cuenta, a partir de ella definitivamente puede generar un par de claves pública y privada. Luego, este hash de bytes pasó en el método de creación de un par de claves públicas y privadas del algoritmo Curve25519. DecentralChain usa la firma Curve25519-ED25519 con claves X25519 (forma de Montgomery), pero la mayoría de los dispositivos y bibliotecas de criptografía integrados no admiten claves X25519. Hay bibliotecas con funciones de conversión de:
Claves ED25519 para X25519 (Curve25519) crypto_sign_ed25519_pk_to_curve25519(curve25519_pk, ed25519_pk) para clave pública.
Crypto_sign_ed25519_sk_to_curve25519(curve25519_sk, ed25519_skpk) para clave privada.
NOTA: No todos los \(32\) bytes aleatorios se pueden usar como claves privadas (pero cualquier byte de cualquier tamaño puede ser una semilla). El esquema de firma para el ED25519 introduce restricciones en las claves, así que cree las claves solo a través de los métodos de las bibliotecas Curve25519 y asegúrese de hacer una prueba de la capacidad de firmar datos con una clave privada y luego verifíquelo con una clave pública. por obvia que parezca esta prueba. Hay realizaciones de Curve25519 válidas para diferentes idiomas:
Además, algunas bibliotecas Curve25519 (como la que se usa en nuestro proyecto) tienen el hash Sha256 integrado, otras no (como la mayoría de las bibliotecas c/c++/python), por lo que es posible que deba aplicarlo manualmente. Tenga en cuenta que la clave privada está sujeta, por lo que ningún \(32\) byte aleatorio puede ser una clave privada válida.
Ejemplo
Cadena de semillas Brainwallet
manage manual recall harvest series desert melt police rose hollow moral pledge kitten position add
Como bytes UTF-8 codificados
xrv7ffrv2A9g5pKSxt7gHGrPYJgRnsEMDyc4G7srbia6PhXYLDKVsDxnqsEqhAVbbko7N1tDyaSrWCZBoMyvdwaFNjWNPjKdcoZTKbKr2Vw9vu53Uf4dYpyWCyvfPbRskHfgt9q
Contabilice bytes iniciales con nonce \(0\) antes de aplicar la función hash en Base58
1111xrv7ffrv2A9g5pKSxt7gHGrPYJgRnsEMDyc4G7srbia6PhXYLDKVsDxnqsEqhAVbbko7N1tDyaSrWCZBoMyvdwaFNjWNPjKdcoZTKbKr2Vw9vu53Uf4dYpyWCyvfPbRskHfgt9q
blake2b256(bytes de semilla de cuenta)
6sKMMHVLyCQN7Juih2e9tbSmeE5Hu7L8XtBRgowJQvU7
Semilla de cuenta (keccak256(blake2b256(bytes de semilla de cuenta)))
H4do9ZcPUASvtFJHvESapnxfmQ8tjBXMU7NtUARk9Jrf
Semilla de cuenta después del hashing Sha256 (opcional, si su biblioteca no lo hace usted mismo)
49mgaSSVQw6tDoZrHSr9rFySgHHXwgQbCRwFssboVLWX
Clave privada creada
3kMEhU5z3v8bmer1ERFUUhW58Dtuhyo9hE5vrhjqAWYT
Clave pública creada
HBqhfdFASRQ5eBBpu2y6c6KKi1az6bMx8v1JxX4iW1Q8
Creación de una Dirección desde una Llave Privada#
Nuestra dirección de red obtenida de la clave pública depende del byte chainID (“T” para Testnet, “W” para Mainnet, “S” para Stagenet), por lo que diferentes redes obtuvieron una dirección diferente para una sola semilla (y, por lo tanto, claves públicas) .
Ejemplo
Para la clave pública:
HBqhfdFASRQ5eBBpu2y6c6KKi1az6bMx8v1JxX4iW1Q8
Clave pública creada:
3PPbMwqLtwBGcJrTA5whqJfY95GqnNnFMDX
Firma#
Curve25519 se utiliza para todas las firmas del proyecto. El proceso es el siguiente: cree los bytes especiales para firmar transacciones o bloques, luego cree una firma usando estos bytes y los bytes de la clave privada. Para la validación de firmas basta con bytes de firma, bytes de objeto firmado y la clave pública. No olvide que hay muchas firmas válidas (¡no únicas!) para una matriz de bytes (bloque o transacción). Además, no debe asumir que la ID del bloque o transacción es única. ¡La colisión puede ocurrir algún día! Ya han tenido lugar para algunas claves débiles.
Ejemplo
Datos de la Transacción:
Campo |
Valor |
|---|---|
Dirección del remitente (no utilizada, solo para información) |
3N9Q2sdkkhAnbR4XCveuRaSMLiVtvebZ3wp |
Clave privada (usada para firmar, no en datos tx) |
7VLYNhmuvAo5Us4mNGxWpzhMSdSSdEbEPFUDKSna6eBv |
Llave pública |
EENPV1mRhUD9gSKbcWt84cqnfSGQP5LkCu5gMBfAanYH |
Dirección del receptor |
3NBVqYXrapgJP9atQccdBPAgJPwHDKkh6A8 |
ID del Activo |
BG39cCNUFWPQYeyLnu7tjKHaiUGRxYwJjvntt9gdDPxG |
Cantidad |
\(1\) |
Tarifa |
\(1\) |
ID de Activo de la Tarifa |
BG39cCNUFWPQYeyLnu7tjKHaiUGRxYwJjvntt9gdDPxG |
Marca de Tiempo |
\(1479287120875\) |
Adjunto (como matriz de bytes) |
\(1[1, 2, 3, 4]\) |
Bytes:
# |
Nombre del campo |
Tipo |
Posición |
Longitud |
Valor |
Valor de bytes base58 |
|---|---|---|---|---|---|---|
\(1\) |
Tipo de transacción (0x04) |
\(0\) |
\(1\) |
\(4\) |
\(5\) |
|
\(2\) |
Clave pública del remitente |
Bytes |
\(1\) |
\(32\) |
… |
EENPV1mRhUD9gSKbcWt84cqnfSGQP5LkCu5gMBfAanYH |
\(3\) |
Bandera de la cantidad de activos (0-DecentralCoins, 1-Activo) |
\(33\) |
\(1\) |
\(1\) |
\(2\) |
|
\(4\) |
ID de activo de la cantidad (*si se usa) |
Bytes |
\(34\) |
\(0 (32*)\) |
… |
BG39cCNUFWPQYeyLnu7tjKHaiUGRxYwJjvntt9gdDPxG |
\(5\) |
Bandera de activo de la tarifa (0-DecentralCoins, 1-Activo) |
\(34 (66*)\) |
\(1\) |
\(1\) |
\(2\) |
|
\(6\) |
ID de activo de la tarifa (**si se usa) |
Bytes |
\(35 (67*)\) |
\(0 (32**)\) |
… |
BG39cCNUFWPQYeyLnu7tjKHaiUGRxYwJjvntt9gdDPxG |
\(7\) |
Marca de Tiempo |
\(35 (67\_ ) (99*\_ )\) |
\(8\) |
\(1479287120875\) |
11frnYASv |
|
\(8\) |
Cantidad |
\(43 (75\_ ) (107*\_ )\) |
\(8\) |
\(1\) |
\(11111112\) |
|
\(9\) |
Tarifa |
\(51 (83\_ ) (115*\_ )\) |
«\(8\)» |
\(1\) |
\(11111112\) |
|
\(10\) |
Dirección del destinatario |
Bytes |
\(59 (91\_ ) (123*\_ )\) |
\(26\) |
… |
3NBVqYXrapgJP9atQccdBPAgJPwHDKkh6A8 |
\(11\) |
Longitud del archivo adjunto (N) |
\(85 (117\_ ) (149*\_ )\) |
\(2\) |
\(4\) |
\(15\) |
|
\(12\) |
Bytes del archivo adjunto |
Bytes |
\(87 (119\_ ) (151*\_ )\) |
N |
\([1,2,3,4]\) |
2VfUX |
Bytes de datos totales por signo
Ht7FtLJBrnukwWtywum4o1PbQSNyDWMgb4nXR5ZkV78krj9qVt17jz74XYSrKSTQe6wXuPdt3aCvmnF5hfjhnd1gyij36hN1zSDaiDg3TFi7c7RbXTHDDUbRgGajXci8PJB3iJM1tZvh8AL5wD4o4DCo1VJoKk2PUWX3cUydB7brxWGUxC6mPxKMdXefXwHeB4khwugbvcsPgk8F6YB
Firma de bytes de datos de transacción (una de un número infinito de firmas válidas)
2mQvQFLQYJBe9ezj7YnAQFq7k9MxZstkrbcSKpLzv7vTxUfnbvWMUyyhJAc1u3vhkLqzQphKDecHcutUrhrHt22D
Total de bytes de transacción con firma:
6zY3LYmrh981Qbzj7SRLQ2FP9EmXFpUTX9cA7bD5b7VSGmtoWxfpCrP4y5NPGou7XDYHx5oASPsUzB92aj3623SUpvc1xaaPjfLn6dCPVEa6SPjTbwvmDwMT8UVoAfdMwb7t4okLcURcZCFugf2Wc9tBGbVu7mgznLGLxooYiJmRQSeAACN8jYZVnUuXv4V7jrDJVXTFNCz1mYevnpA5RXAoehPRXKiBPJLnvVmV2Wae2TCNvweHGgknioZU6ZaixSCxM1YzY24Prv9qThszohojaWq4cRuRHwMAA5VUBvUs
Cálculo de ID de Transacción#
El ID de transacción no se almacena en los bytes de transacción y para la mayoría de las transacciones (excepto Pago) se puede calcular fácilmente a partir de los bytes especiales para firmar usando blake2b256(bytes_for_signing). Para los pagos, el ID de la transacción es solo la firma de esta transacción.
Solución DecentralChain-M5#
Razonamiento#
La tasa máxima de transacciones en los sistemas de cadena de bloques está limitada por la elección de dos parámetros: el tamaño del bloque y el intervalo del bloque.
El intervalo de bloque define la cantidad promedio de tiempo que pasa entre la creación de dos bloques. Si reducimos este tiempo, las bifurcaciones aparecerán con más frecuencia, lo que conducirá a bifurcaciones no resueltas o a una disminución del rendimiento, ya que se dedicaría una cantidad considerable de tiempo a resolver estas bifurcaciones. Los bloques más grandes conducen a grandes picos de uso de la red durante la propagación del bloque, lo que a su vez generará problemas de rendimiento y enormes bifurcaciones.
Solución DecentralChain-M5 con Detalles Técnicos#
DecentralChain aborda este problema al permitir que el minero cultive continuamente un bloque durante el tiempo de la minería. Este bloque que aumenta continuamente se denomina bloque líquido, que se vuelve inmutable cuando se construye y agrega el siguiente bloque que hace referencia a él. Un bloque líquido consta de un bloque clave y una cadena de microbloques. El proceso de creación de bloque líquido es el siguiente:
Cuando un nodo minero observa que tiene derecho a crear un bloque, crea y envía keyBlock, que normalmente es solo un bloque vacío.
Después de eso, crea y envía microbloques cada \(3\) segundos. El microbloque es muy similar a un bloque regular: es un paquete de transacciones no vacío, que hace referencia a su padre: microbloque anterior o bloque clave.
Los microbloques se extraen continuamente y se propagan a la red hasta que aparece un nuevo bloque clave, que hace referencia al bloque líquido actual.
Estructura de Microbloques#
generator: PublicKeyAccount
transactionData: Seq[Transaction]
prevResBlockSig: BlockId
totalResBlockSig: BlockId
signature: ByteStr
totalResBlockSig is the new total signature of a block with all transactions from blockId=prevResBlockSig and transactionData. This means that having a liquid block consisting of 1 keyblock and 3 microblocks:
KEYBLOCK() <-MICRO1(tx1,tx2) <-MICRO2(tx3,tx4) <-MICRO3(tx5,tx6)
We have 4 versions of last block:
ID |
Transacciones |
|---|---|
KEYBLOCK.uniqueId |
|
MICRO1.totalResBlockSig |
tx1,tx2 |
MICRO2.totalResBlockSig |
tx1,tx2,tx3,tx4 |
MICRO3.totalResBlockSig |
tx1,tx2,tx3,tx4,tx5,tx6 |
El próximo minero puede hacer referencia a cualquiera de estos identificadores en su keyBlock.
Economía#
Para un minero, puede parecer una buena idea hacer referencia a KEYBLOCK del ejemplo anterior y empaquetar todos los txs de los microbloques en su propio (micro)bloque(s). Para hacer que las transacciones de «robo» sean menos rentables que hacer referencia a la versión más conocida de Liquid Block (= el último microbloque conocido), cambiamos la mecánica de las tarifas: después de activar M5, el minero recibirá \(40\% ` de tarifas del bloque que crea y :math:`60\%\) de tarifas del bloque al que hace referencia.
Configuración#
Se pueden ajustar los siguientes parámetros mineros (aunque es mejor no cambiarlos para maximizar la versión final de su bloque líquido en la cadena de bloques resultante):
Tamaño de KeyBlock (maxTransactionsInKeyBlock, predeterminado = \(0\)). Si se modifica, no se retransmitirá y se utilizará la mecánica habitual de solicitud de prórroga.
Intervalo de minería de microbloques (microBlockInterval, predeterminado = \(3\) s).
Cantidad máxima de transacciones por microbloque (maxTransactionsInMicroBlock, predeterminado = \(200\)).
Miner intentará hacer referencia al microbloque más conocido con al menos minMicroBlockAgeage (predeterminado = \(3\) s). Esto es necesario para que un minero haga referencia a un bloque ya propagado para que su bloque clave no quede huérfano.
El mecanismo de sincronización de microbloques se puede ajustar con waitResponseTimeout(predeterminado = :matemáticas:`2` s), procesadoMicroBlocksCacheTimeout(predeterminado = :matemáticas:`10` s), invCacheTimeout(predeterminado = :matemáticas:`10` s) que son básicamente el tiempo de en espera de un microbloque y tiempos para almacenar en caché las identificaciones de un microbloque procesado y una lista de nodos que tienen un microbloque (por identificación).
Cambios en la API#
Al aplicar cada microbloque, se cambia el último bloque, lo que significa que /blocks/laststand/blocks/at/… reflejará eso.
/peers/blacklistednow expone el motivo de la prohibición, uno puede borrar la lista negra de un nodo a través de/peers/clearblacklist
/debug/and/consensus/section are expanded, stateHash doesn’t take liquid block into consideration.
Protocolo DecentralChain-M5#
Límites de Escalabilidad y Desafíos en los Sistemas Blockchain Actuales#
Declaración del Problema y Motivación#
Los protocolos de cadenas de bloques tienen algunos límites de escalabilidad y desafíos que compensan el rendimiento y la latencia. La tecnología blockchain actual no es lo suficientemente rápida y no se escala para incluir más transacciones en el sistema, por lo que tenemos un desafío de rendimiento que considerar. Existe un acuerdo conjunto entre mineros, consumidores y desarrolladores con varias perspectivas de que necesitamos implementar medidas de escalabilidad, y ha habido un debate continuo sobre cómo mejorar la escalabilidad de Bitcoin. Las propuestas actuales se han centrado en el tamaño de los bloques y cómo manejar los aumentos de tamaño de los bloques en el futuro.
Todas las propuestas sufren un gran cuello de botella de escalabilidad: no importa qué tamaño de bloque se elija, el sistema de cadena de bloques puede, en el mejor de los casos, alcanzar un rendimiento de transacciones adecuado, aumentando de ~ \(3\) transacciones por segundo a ~ \(7\) transacciones por segundo. Esto está muy lejos de las \(30,000\) transacciones por segundo que son necesarias para competir con los sistemas existentes como las transacciones VISA. Las mismas limitaciones principales se aplican a litecoin, Ethereum y todas las demás monedas que comparten el protocolo de cadena de bloques de Bitcoin.
DecentralChain-M5 abordará el cuello de botella de escalabilidad al hacer que la red alcance el rendimiento más alto según las condiciones de la red. No solo mejorará el rendimiento de las transacciones, sino que también reducirá las latencias de las transacciones. Por lo tanto, será posible obtener una confirmación de transacción inicial en segundos en lugar de minutos.
Debilidades de las Propuestas Actuales para Mejorar la Escalabilidad#
Los sistemas blockchain pueden procesar transacciones y la tasa máxima de estas transacciones está limitada por la elección de dos parámetros: tamaño de bloque e intervalo de bloque.
El intervalo de bloque define la cantidad promedio de tiempo que pasa entre la creación de dos bloques. Al decidir reducir el intervalo de bloque para resolver el límite de latencia, el sistema tendrá menos seguridad (aumentará la probabilidad de bifurcaciones) debido a la razón de que habrá nuevos mineros por cada segundo, lo que conducirá a una inestabilidad en la que la cadena de bloques está sujeta a reorganización y el sistema está en desacuerdo (Figura 1). Si reducimos el tiempo por bloque, tendremos una situación en la que se resolverá un número significativo de bloques en menos tiempo del que se tarda en transmitir un bloque resuelto a través de la red. Por lo tanto, no habrá forma de saber qué bloque es el ealy cuál es un forkporque las transacciones que parecían tener múltiples confirmaciones de repente tienen menos confirmaciones (o posiblemente vuelven a estar sin confirmar).
Figura 1: El aumento de la frecuencia de los bloques con un tamaño de bloque estático dará como resultado una menor seguridad.
El rendimiento de un sistema está limitado por el tamaño máximo del bloque (dado un intervalo de bloque fijo), ya que el número máximo de transacciones incluidas depende directamente del tamaño del bloque.
Sin embargo, los bloques más grandes causan velocidades de propagación más lentas, lo que genera más bloques descartados (riesgo de huérfano). Un tamaño de bloque ilimitado podría, por ejemplo, dar lugar a un ataque DoS en el sistema al crear un bloque que tarda mucho tiempo en validarse. Si la opción es aumentar el tamaño del bloque para mejorar el rendimiento, habrá picos de red con más tiempo para propagarse en la red (Figura 2).
Figura 2: aumentar el tamaño del bloque con la frecuencia de bloque estático dará lugar a más bloques descartados y picos de red.
Breve Resumen de Bitcoin-M5#
Es un protocolo de cadena de bloques de nueva generación que es una solución alternativa de escalado de bitcoin que no implica aumentar el tamaño de los bloques ni disminuir el intervalo de tiempo del bloque. Esto reduce el riesgo de horquillas entre otras ventajas. Bitcoin-M5 describe que las compensaciones básicas en Bitcoin se pueden reducir con un protocolo de cadena de bloques alternativo, que ofrece un retraso de consenso y un ancho de banda limitado solo por el plano de la red. El protocolo divide el tiempo en períodos de tiempo (época). En cada período de tiempo, un líder en particular es responsable de serializar las transacciones (Figura 3). Los líderes toman la regla de generar bloques:
Bloques clave para la elección de un líder.
Microbloques para registros contables.
Figura 3: estructura de períodos de tiempo de Bitcoin-M5 con transacciones serializadas.
Marco DecentralChain-M5#
DecentralChain-M5 se basa en el protocolo de próxima generación de bitcoin que serializa las transacciones y ofrece importantes mejoras en la latencia de la transacción (menor latencia) y el ancho de banda (mayor rendimiento) en comparación con Bitcoin sin sacrificar otras propiedades. DecentralChain aborda esta cuestión de escalabilidad al proporcionar al minero la capacidad de cultivar un bloque durante el tiempo de minería en un enfoque continuo. Este bloque continúa con incrementos llamados bloques líquidos. Este bloque líquido no se puede cambiar con el tiempo una vez que se crea y se agrega la siguiente referencia de bloque. Este enfoque aumenta el ancho de banda efectivo y la velocidad de creación de bloques, que se describe como «especialmente importante para las empresas» que utilizan el protocolo DecentralChain-M5, ya que permite realizar microtransacciones, sin los retrasos típicos de los sistemas de cadena de bloques tradicionales. Además, permite que la cadena de bloques soporte grandes cargas, como la distribución de tokens después de las ventas masivas y los lanzamientos aéreos de tokens de bonificación. La velocidad de procesamiento de transacciones comerciales en el intercambio también aumenta.
Operaciones DecentralChain-M5#
La idea principal y central de DecentralChain-M5 es dividir el bloque Liquid en dos tipos, Key blocks y Microblocks. El proceso de creación de bloques líquidos funciona de la siguiente manera:
El nodo minero obtiene el permiso para crear un bloque.
El nodo minero crea y envía el bloque de claves (que no contiene transacciones).
El nodo minero crea y envía los microbloques (que contienen transacciones como en los bloques normales con referencia a microbloques o bloques clave anteriores) con un intervalo de tiempo de minería de tres segundos.
Los mineros extraerán esos microbloques y los propagarán directamente a la red hasta que aparezca el siguiente bloque clave nuevo con una referencia al bloque líquido.
Todas las transacciones son parte del mismo bloque y se aportan todas juntas. Entre bloques, el sistema tradicional de Bitcoin parece inactivo para un espectador, ya que los mineros están trabajando para descubrir el siguiente bloque, pero sin un progreso aparente en el frente del consenso. En contradicción, en DecentralChain-M5, los bloques de claves pueden ser pequeños porque necesitan contener solo la transacción coinbase, que define la clave pública que el minero usará para firmar microbloques. Debido a que un bloque clave requiere una prueba de participación, los mineros no pueden simplemente producir uno y expropiar el liderazgo a voluntad. Siguiendo el bloque de claves, el minero principal puede emitir rápidamente microbloques, simplemente firmándolos con la clave privada correspondiente a la clave pública nombrada en la base de monedas del bloque de claves (Figura 4).
Figura 4: Proceso de firma de Key-blocks y Micro-blocks.
Bloques líder
También se denominan «Bloques Clave», estos bloques se generan con prueba de participación pero no contienen transacciones. Sirven como mecanismo de elección de líder y contienen una clave pública que identifica al líder elegido. Cada bloque tiene un encabezado que contiene, entre otros campos, la referencia única de su predecesor, que es un hash criptográfico del encabezado anterior (ya sea un bloque clave o un microbloque).
Micro Bloques
Una vez que un nodo genera un bloque clave, se convierte en el líder. Como líder, el nodo puede generar microbloques a una tasa establecida más pequeña que un máximo predefinido. Estos microbloques contendrán las entradas del libro mayor sin ningún requisito de prueba de participación y son generados por el líder electo en cada ciclo de generación de bloques. Este ciclo de generación de bloques es iniciado por un bloque líder. El único requisito es firmar los microbloques con la clave privada del líder electo. El líder elegido (minero) puede generar los microbloques a una velocidad muy alta, lo que resulta en un mayor rendimiento y velocidad de transacción.
Para que un microbloque sea válido, todas sus entradas deben ser válidas según la especificación de la máquina de estado y la firma debe ser válida. La Figura 5 ilustra la estructura. Tenga en cuenta que los microbloques no afectan el peso de la cadena, ya que no contienen prueba de participación. Cuando se hayan validado todos los microbloques, se fusionarán con su bloque clave en un solo bloque.
Mecanismos de Recompensa de DecentralChain-M5#
La remuneración consta de dos partes. Primero, cada bloque clave da derecho a su generador a una cantidad fija. En segundo lugar, cada entrada del libro mayor conlleva una tarifa. Esta tarifa se divide entre el líder que coloca esta entrada en un microbloque y el líder posterior que genera el siguiente bloque clave.
Para motivar a los participantes a seguir el protocolo, DecentralChain-M5 utiliza los siguientes mecanismos: cada transacción paga una tarifa al sistema, pero a diferencia de Bitcoin, esta tarifa se distribuye, con \(40\%\) al líder, y \(60\%\) al siguiente líder. Finalmente, si un líder bifurca la cadena generando dos microbloques con el mismo padre, es sancionado con la revocación de los ingresos del subsidio; quien detecta el fraude gana una tarifa nominal (Figura 5).
Figura 5: estructura de cadena del Protocolo DecentralChain-M5. Los microbloques (círculos) se firman con la clave privada que coincide con la clave pública en el último bloque de claves (cuadrados). La tarifa se distribuye \(40\%\) al líder y \(60\%\) al siguiente.
En la práctica, la remuneración se implementa haciendo que cada bloque clave contenga una sola transacción de base de monedas que acuña nuevas monedas y deposita los fondos a los líderes actuales y anteriores. Al igual que en Bitcoin, esta transacción solo se puede gastar después de un período de vencimiento de \(100\) bloques clave, para evitar transacciones no fusionables después de una bifurcación.
Prueba Justa de Participación#
En este modelo, la elección de la cuenta que tiene derecho a generar el siguiente bloque y recibir las tarifas de transacción correspondientes se basa en la cantidad de tokens en la cuenta. Cuantos más tokens se mantengan en la cuenta, mayor será la posibilidad de que la cuenta obtenga el derecho a generar un bloqueo.
En DecentralChain estamos convencidos de que cada participante en la cadena de bloques debe participar en el proceso de generación de bloques de forma proporcional a su participación: hemos decidido corregir la fórmula PoS. Por el momento no tenemos el objetivo de cambiar completamente el algoritmo, ya que no hay necesidad; simplemente queremos hacer algunos ajustes. Presentamos un algoritmo PoS mejorado que hace que la elección del creador de bloques sea justa y reduce la vulnerabilidad a los ataques de ramificación múltiple, de acuerdo con las deficiencias del algoritmo actual.
Analizamos el modelo del nuevo algoritmo para su correspondencia con la participación de participación y la participación de bloques, y los resultados fueron positivos. Además, se analizó la vulnerabilidad del algoritmo a los ataques y los resultados obtenidos con el nuevo modelo fueron mejores que con el antiguo. Los resultados de los ataques para el atacante no fueron tan exitosos en términos de las ganancias obtenidas. El número de horquillas y su longitud disminuyó.
Tipos de Datos del Blockchain#
The blockchain data types are the data types that are used to describe the binary format of blockchain entities. Here’s a list of blockchain data types:
# |
Palabra clave |
Valores posibles |
Tamaño variable en bytes |
|---|---|---|---|
\(1\) |
Booleano |
\(0\) y \(1\). |
\(1\) |
\(2\) |
Entero de \(-128\) a \(127\) inclusive. |
\(1\) |
|
\(3\) |
Número entero de \(-2,147,483,648\) a \(2,147,483,647\) inclusive. |
\(4\) |
|
\(4\) |
Entero de \(-9,223,372,036,854,775,808\) a \(9,223,372,036,854,775,807\) inclusive. |
\(8\) |
|
\(5\) |
Número entero de \(-32,768\) a \(32,767\) inclusive. |
\(2\) |
|
\(6\) |
Desde \(0\) hasta \(2,147,483,647\) caracteres inclusive. |
Desde \(1\) hasta \(4\) bytes por carácter. |
Reglas de Validación#
Validación de Cuenta#
La cuenta es válida, entonces es una cadena Base58 válida y la longitud de la matriz correspondiente es \(26\) bytes. La versión de la dirección (1er byte) es igual a \(1\). El byte de red (segundo byte) es igual a la ID de red. La suma de comprobación de la dirección (últimos \(4\) bytes) es correcta.
Validación de Transacciones#
Validación de Transacción para Transferencia#
La transacción para transferencia es válida entonces:
La dirección del destinatario es válida. De lo contrario, se devolverá el resultado de validación de InvalidAddress.
El tamaño del archivo adjunto es menor o igual a MaxAttachementSize(\(140\) bytes). En otro caso, se devolverá el resultado de la validación de TooBigArray.
El monto de la transacción es mayor que \(0\); de lo contrario, se devuelve el resultado de la validación NegativeAmount.
La tarifa de la transacción es positiva; de lo contrario, se devuelve el resultado de validación de tarifa insuficiente.
Agregar una tarifa a la cantidad no conduce a un desbordamiento largo. En caso de desbordamiento prolongado, se devolverá el resultado de la validación OverflowError.
La firma de la transacción es válida; de lo contrario, se devuelve el resultado de la validación InvalidSignature.
Validación de Transacción para Emisión#
La transacción para emisión es válida entonces:
La dirección del remitente es válida. De lo contrario, se devolverá el resultado de validación de InvalidAddress.
La cantidad de activos es positiva; de lo contrario, se devuelve el resultado de la validación NegativeAmount.
La tarifa de la transacción es mayor o igual a MinFee(\(100000000\) Decentralites = \(1\) DecentralCoin), en otro caso, se devuelve un resultado de validación de tarifa insuficiente.
El tamaño de la descripción es menor o igual a MaxDescriptionLength(\(1000\) bytes); de lo contrario, se devuelve TooBigArray.
El tamaño del nombre es mayor o igual a MinAssetNameLength y menor o igual a MaxAssetNameLength; en otro caso, se devolverá el resultado de validación de InvalidName.
Decimals es positivo y menor o igual a MaxDecimals; en otro caso, se devuelve TooBigArray.
La firma de la transacción es válida; de lo contrario, se devuelve el resultado de la validación InvalidSignature.
Validación de Transacción para Reemisión#
La transacción para reemisión es válida entonces:
La cuenta del remitente es válida. De lo contrario, se devuelve el resultado de validación de InvalidAddress.
Quantity es positivo; en otro caso, se devolverá el resultado de la validación NegativeAmount.
La tarifa de la transacción es positiva, en caso contrario, se devolverá el resultado de Tarifa Insuficiente.
La firma de la transacción es válida; de lo contrario, se devuelve el resultado de la validación InvalidSignature.
Validaciones de Bloque#
El bloque es válido entonces:
La cadena de bloques contiene bloques a los que se hace referencia.
La firma del bloque es válida.
Los datos de consenso del bloque son válidos.
Las transacciones del bloque son válidas.
Validación de Datos de Consenso#
Los datos de consenso del bloque son válidos entonces:
El tiempo de creación del bloque no es más que MaxTimeDrift(\(15\) segundos) en el futuro.
Las transacciones del bloque están ordenadas. Esta regla solo funciona después de \(1477958400000\) en Testnet y \(1479168000000\) en Mainnet.
La cadena de bloques contiene el bloque principal o la altura de la cadena de bloques es igual \(1\).
El objetivo base del bloque es válido.
La firma del generador del bloque es válida.
El saldo del generador es mayor o igual a MinimalEffectiveBalanceForGeneration(\(1000000000000\) Decentralites). Esta regla siempre funciona en Testnet y funciona solo después de \(1479168000000\) en Mainnet.
El golpe del bloque es menor que el objetivo del bloque calculado.
Las características votadas se ordenan en orden ascendente y no se repiten.
Validación de Datos de Transacciones#
Las transacciones del bloque son válidas entonces:
El tiempo de creación de cada transacción en el bloque es menor que el tiempo de creación del bloque no más que en MaxTxAndBlockDiff(:matemáticas:`2` horas).
Todas las transacciones son válidas contra el estado.
Validación de transacciones contra el estado. Las transacciones son válidas entonces:
La transacción es válida según las reglas de validación de transacciones.
El tiempo de creación de la transacción es más que el tiempo de creación del bloque no más que en MaxTimeForUnconfirmed(\(90\) minutos). Esta limitación funciona siempre en Testnet y solo después de \(1479168000000\) en Mainnet.
La aplicación de la transacción a las cuentas no debe dar lugar a un saldo negativo temporal. Esta regla funciona después de \(1479168000000\) en Mainnet y después de \(1477958400000\) en Testnet.
Los cambios realizados por transacción deben ordenarse por su monto. Esta regla funciona tanto en Mainnet como en Testnet después de \(1479416400000\).
La aplicación del monto de la transacción al saldo actual no debe conducir a un desbordamiento largo.
Después de la aplicación de todas las transacciones del bloque, los saldos afectados no deben ser negativos.
Validación del Grupo de Transacciones no Confirmadas#
La transacción podría insertarse en el grupo de transacciones no confirmadas entonces:
La transacción es válida según las reglas de validación de transacciones.
Si la tarifa de la transacción es mayor o igual a la tarifa mínima establecida por el propietario de un nodo.
Hay un espacio para una nueva transacción si hay un grupo de transacciones no confirmadas. De forma predeterminada, el grupo está limitado por \(1000\) transacciones.
El grupo de transacciones no confirmadas no contiene transacciones con el mismo ID.
Transacción creada a más tardar MaxTimeForUncofimed(:matemáticas:`90` minutos) después de la creación del último bloque.
El tiempo de creación de la transacción no es más que MaxTimeDrift(\(15\) segundos) en el futuro.
La transacción es válida contra el estado.