QIP-26: Reducir el espaciado de bloques

Jackson Belove

Oct 26 ·

Este blog revisa QIP-26 que propone reducir el espacio entre bloques. Después de una revisión de cómo funciona GitHub para el código y las actualizaciones de funciones, analizamos de cerca el cambio propuesto y detallamos el lenguaje más centrado en el desarrollador en el QIP.

TL; DR: Qtum Improvement Proposal 26 sugiere reducir el espacio entre bloques en la blockchain Qtum, de un promedio de 128 segundos a un promedio de 16 segundos. El QIP revisa la motivación, los parámetros y los problemas para reducir el espacio entre bloques.

Propuestas de mejora de GitHub y Qtum

Qtum es un proyecto de código abierto con código y progreso de desarrollo que se muestra en GitHub, un sitio web que proporciona un sistema de administración de código fuente que permite a los desarrolladores administrar actualizaciones para un proyecto en múltiples versiones y múltiples autores.

Para un proyecto dado, GitHub está organizado en repositorios, donde cada repositorio representa una aplicación, documentación, bibliotecas de soporte, etc. La mayor parte del trabajo de desarrollo y depuración de GitHub se rastrea a través de:

• Ramas, donde los desarrolladores pueden crear una versión de “trabajo en progreso” de un repositorio para desarrollar una nueva función. Se puede usar una rama para crear una nueva versión de la aplicación para realizar más pruebas, y luego los cambios se fusionaron en la rama principal.

• Pull Requests, donde un desarrollador hace una copia del código del software, implementa una nueva función con código nuevo o modificado y devuelve el software modificado para que sea aprobado e incorporado a la aplicación.

Puede ver la solicitud de extracción para el espaciado de bloque reducido en https://github.com/qtumproject/qtum/pull/873.

• Confirma, que son cambios individuales en una línea (o varias líneas de código) para un propósito específico. Se podría implementar una corrección de errores o una nueva característica en muchas confirmaciones.
• Problemas: estos son problemas o errores informados por la comunidad.
• Insights: análisis y gráficos que muestran el trabajo en el repositorio

Una característica adicional de los proyectos de blockchain es la “Propuesta de mejora”, para Qtum esta es la Propuesta de mejora de Qtum (QIP). Los QIP son características nuevas descritas y solicitadas por los desarrolladores o la comunidad y se utilizan para proponer nuevas capacidades para las aplicaciones. Para diferenciar los “problemas” de los QIP, un problema podría ser “el botón no funciona”, mientras que un QIP podría ser “agregar un nuevo botón que haga esto, y este es el motivo …”

Hasta la fecha, el proyecto Qtum tiene 26 QIP, y este blog se concentrará en QIP-26, publicado por su autor, para reducir ese espaciado promedio entre bloques. Consulte los detalles de QIP-26 aquí https://github.com/qtumproject/qips/issues/26

QIP-26 Reducir el espaciado de bloques

El QIP se cita en su totalidad a continuación con comentarios adicionales para este blog agregados en cursiva.

QIP-26Layer: Blockchain ProtocolTitle: Reduce Block SpacingAuthor: Jackson Belove jb395official@gmail.comComments-Summary: Proposing reducing block spacing to provide faster confirmations for transactions, including smart contract transactions.Reduce average block spacing from the current 128 seconds to 16 seconds.Adjust block subsidy, halvings, and other blockchain parameters to preserve previous characteristics.Comments-URI: https://github.com/qtumproject/qips/issues/26Status: DraftCreated: 2020-10-18License: GPLv3

Abstracto

Esta propuesta de mejora de Qtum (QIP) describe cambios en los parámetros y la lógica de la blockchain para reducir el espaciado de bloques de destino (el espaciado promedio entre bloques).

Desde el lanzamiento, Qtum ha utilizado un espaciado de bloque de destino (un parámetro de configuración) de 128 segundos. El objetivo y la dificultad se ajustan para cada bloque para mantener el espaciado promedio de bloques de 128 segundos, con una variación considerable debido a la aleatoriedad necesaria para un consenso descentralizado.

“Objetivo” y “dificultad” aquí son parámetros técnicos que se utilizan en el proceso de consenso (selección de productor de bloque / recompensa de bloque). “Dificultad” establece un número de lo difícil que es resolver el consenso y “objetivo” es el número relacionado utilizado por el algoritmo.

espaciado promedio entre bloques a 16 segundos si hay buenos resultados después de la prueba / ajuste, o quizás 32 segundos. El algoritmo de consenso actualmente evalúa cada UTXO a intervalos de 16 segundos, apuntando a una solución (publicar un bloque) después de 8 intervalos, o 128 segundos. Un bloque podría publicarse después del primer intervalo (en 16 segundos) u ocasionalmente, mucho después del objetivo de 8 intervalos.

Se pueden proponer nuevos encabezados de bloque y nuevos bloques de forma continua en la red, pero la lógica de consenso se valida con una granularidad de 16 segundos, lo que significa que los bloques se validan y registran una marca de tiempo con una granularidad de 16 segundos según el espaciado de intervalo.

La configuración actual de la blockchain permite un nuevo bloque cada 16 segundos, o 32 segundos, o 48 segundos, etc., a intervalos de 16 segundos.

Especificación

Conservar las características de Blockchain

Los objetivos de diseño de alto nivel para la reducción del espacio entre bloques son:

• Mantenga las características críticas de la blockchain cuando corresponda, como la emisión (monto del subsidio en bloque para las recompensas en bloque), el programa de reducción a la mitad, etc.
• Ajuste el tamaño del bloque para mantener el TPS (transacciones por segundo) y el gas máximo por bloque.
• Ajusta el subsidio, el nuevo QTUM que se crea para cada bloque como parte de la recompensa del bloque. Este sería probablemente el subsidio actual (4.0 QTUM) dividido por “mejora de espaciado” (128/16 = 8), o 0.5 QTUM (para bloques de 16 segundos). Esto mantiene la tasa de inflación general igual.
• Disminuya la madurez, si las pruebas lo confirman, para un gasto de Coinstake más rápido (recompensas en bloque) y reembolsos de gasolina más rápidos.
• Con una cadencia de intervalos más rápida, los nodos con procesadores más lentos, lectura / escritura de disco o memoria, especialmente si están apostando grandes conjuntos de UTXO (> 1,000 UTXO) pueden no ser capaces de mantener el ritmo y publicar bloques.

El subsidio de recompensa en bloque actual es de 4.0 QTUM cada 128 segundos, con una reducción a la mitad cada cuatro años. Actualizando a bloques más rápidos, esta emisión de nuevas recompensas de bloque y el período de reducción a la mitad seguirían siendo los mismos. Para bloques de 16 segundos, esto significa una recompensa de bloque de 0.25 QTUM y la primera reducción a la mitad como está programado actualmente para principios de diciembre de 2021. Los bloques de 16 segundos darían 5400 bloques por día con 2700 QTUM en nuevos QTUM acuñados para recompensas de bloque por día, y mantener la tasa de inflación actual del 0,96%.

TPS y tamaño de bloque

La blockchain Qtum tiene actualmente un TPS (Transacciones por segundo) teórico (calculado) de 70, y este QIP conservaría este valor.

Como referencia, se informa que el TPS actual para Ethereum es de aproximadamente 15 TPS, pero esto también depende de las limitaciones de gas por bloque.

El tamaño de bloque actual de 2 millones de bytes puede ajustarse por el tamaño de bloque actual / “mejora de espaciado”. Esto daría un tamaño de bloque de 250.000. El DGP (Protocolo de gobernanza distribuida) mantendría el mismo rango de ajuste del tamaño del bloque en cadena, por ejemplo, el tamaño del bloque posterior al QIP seguiría siendo el segundo paso hasta 4.000.000 bytes (para bloques de 16 segundos).

El ajuste DGP de Qtum para el tamaño del bloque permite configurar el tamaño del bloque de 500.000 bytes a 32.000.000 bytes, actualmente establecido en 2.000.000 bytes. Para un factor de mejora de espaciado de 8, este rango de ajuste de tamaño de bloque cambiaría de 62,500 bytes a 4,000,000 bytes con una configuración de 500,000 bytes.

Distribución de espacio entre bloques

El histograma de espacios entre bloques sigue una curva controlada por el algoritmo de ajuste de destino que proporciona la mayor cantidad de espacios en el primer intervalo, el segundo más en el segundo intervalo, etc. El histograma estándar se ve así:

Bloques 438439–465623 Mainnet 1 de Septiembre — 15 de Octubre de 2019

Este gráfico de histograma clasifica los espacios entre bloques en “cubos” de 16 segundos cada uno, mostrando que la mayoría de los bloques tienen un espacio de 16 segundos, el segundo más espacio es de 32 segundos, etc.

Puede ser posible “arreglar” el uso de intervalos tempranos mientras se mantiene el espaciado promedio de bloques esperado, usando varias modificaciones lógicas, para tener una distribución más suave y uniforme de espaciamientos para los intervalos tempranos. Quizás podría haber un “retraso” para prohibir el uso del primer intervalo, etc. Este es un objetivo exagerado para reducir el espacio entre bloques.

Otra posible modificación lógica es reducir los bloques de espaciado muy largos, que se muestran aquí como bloques> 580 segundos. Esto no es un requisito del QIP, pero es otro objetivo ambicioso.

Nodos de back-end

Con la cadencia de bloque más rápida, se debe tener cuidado con los sistemas de back-end que admiten exploradores, API y billeteras ligeras, para que sean capaces de admitir un rendimiento más rápido.

Bloques huérfanos

Bloques huérfanos (soluciones de consenso simultáneas) que publican dos nuevos bloques en la red para la misma altura de bloque, dividiendo temporalmente la blockchain. Los bloques huérfanos se encuentran actualmente en el rango de 2 a 3% para Qtum mainnet. Usando el Consenso de Nakamoto (la cadena con mayor dificultad sobrevive) un bloque se convierte en huérfano y se descarta. Las soluciones para el espaciado de bloques reducido deben considerar formas de minimizar cualquier aumento en la tasa de bloques huérfanos.

Compatibilidad

Reducir el espaciado de bloques requiere parámetros de bloque y cambios lógicos, el nodo actualizado y otros sistemas de back-end no serán compatibles con versiones anteriores y requerirán un hard fork para la implementación. Sería posible ejecutar una red de prueba separada antes de la implementación y seguir el patrón de las bifurcaciones duras de Qtum anteriores, es decir, activación a una altura de bloque preestablecida en Testnet seguida de activación en Mainnet.

No metas

Las siguientes funciones no son metas y no se proporcionarán en este QIP.

• Aumente el TPS o realice cambios en el Protocolo de gobernanza distribuida, que continuará en efecto.
• Conserve la compatibilidad de hardware con todos los nodos de menor potencia, especialmente si están apostando grandes conjuntos UTXO. Sujeto a pruebas, algunos nodos con CPU más lentas, velocidad de lectura/escritura del disco o velocidad de la memoria pueden quedar obsoletos.

Expresiones de gratitud

El autor desea agradecer al liderazgo de Qtum Chain Foundation y al equipo principal de desarrolladores por su estrategia y diseño arquitectónico de espacio reducido entre bloques.

Referencias

1. Guía del desarrollador http://book.qtum.site/en/
2. Documentación de Qtum https://docs.qtum.site/en/
3. Repositorio de GitHub Qtum Core https://github.com/qtumproject/qtum

Derechos de autor

El código fuente de Qtum Chain y este QIP tienen licencia GNU General Public License v3.