El próximo hardfork de Kaspa centrado en el pacto: Lo que sabemos

¿Qué es el Hardfork centrado en el pacto de Kaspa?

Según El hilo de Terah, Caspa está preparando un hardfork centrado en el pacto programado para activación de la red principal el 5 de mayo de 2026. La actualización se expande Capa 1 (L1) programabilidad mediante la introducción de activos nativos y funcionalidad extendida de convenios. También sienta las bases para programas verificables (vProgs) y integraciones de conocimiento cero (ZK).

Kaspa opera como una cadena de bloques de prueba de trabajo que utiliza una arquitectura blockDAG. Actualización de Crescendo En mayo de 2025, el rendimiento aumentó a 10 bloques por segundo (BPS). Por lo tanto, la próxima bifurcación dura se basa en esa base sin cambiar los requisitos de los nodos ni los fundamentos del consenso.

Los desarrolladores principales describen el lanzamiento como una actualización de alcance limitado. Se centra en habilitar la emisión nativa de tokens, reglas de gasto programables y la verificación ZK en L1. 

¿Cuál es el cronograma para el Hardfork del 5 de mayo de 2026?

Varios hitos preceden a la activación de la red principal, según el hilo de Terah:

• Restablecimiento de Testnet 12 (TN12): Programado para principios de febrero de 2026 para respaldar las pruebas de convenios y activos nativos.
   
• Compromiso del secuenciador KIP: Se espera que esté disponible alrededor del 12 de febrero de 2026. Esta propuesta introduce compromisos de carga útil de los mineros para fortalecer la descentralización en tiempo real.
   
• Lanzamiento de SilverScript: Un lenguaje de programación de alto nivel para escribir programas en Kaspa. Desarrollado por Ori Newman y colaboradores, simplifica el desarrollo de convenios.
   
• Bifurcación dura de la red principal: Mayo 5, 2026.

Las actualizaciones posteriores al hardfork incluyen DAGKnight, que apunta al consenso adaptativo y al rendimiento por encima de 100 BPS, y la implementación completa de vProgs.

¿Cómo funcionan los activos y convenios nativos en Kaspa?

Activos nativos en la capa 1

El hardfork introduce activos nativos, incluido soporte para Fichas KRC20Estos activos existen directamente en L1 y pueden transferirse atómicamente.

Las transferencias atómicas se aplican a:

• Pactos regulares en línea
• Ejecuciones de pactos ZK y no ZK
• Transferencias de tokens KRC20

Los convenios en línea generan pruebas inmediatas dentro de la billetera. No hay desacoplamiento entre los datos de la transacción y la transición de estado. Este diseño promueve la atomicidad y la ejecución determinista.

Pactos Extendidos (Pactos++)

El sistema de pactos de Kaspa se inspira en la investigación de Bitcoin sobre las condiciones de gasto programables de UTXO. Covenants++ amplía este sistema para permitir reglas de transacción más expresivas.

Descubra proyectos prometedores...

Proyectos prometedores...

(Anuncio)

El artículo continúa...

Los casos de uso incluyen:

• Controles de seguridad estilo bóveda
• Mecanismos de depósito en garantía
• Transferencias condicionales
• Lógica de token estructurada

El sistema mantiene un modelo UTXO en lugar de contratos inteligentes completamente basados ​​en cuentas.

¿Qué es el DAG computacional (CDAG)?

El hardfork introduce el DAG computacional (CDAG)). CDAG registra todas las declaraciones de lectura y escritura realizadas por los programas.

Esta estructura:

• Realiza un seguimiento del uso de recursos
• Regula las dependencias entre programas
• Hace cumplir los compromisos de gas

El diseño es comparable a los modelos de ejecución en cadenas de bloques como Solana y Sui, pero implementado en su forma completa dentro del entorno blockDAG de Kaspa.

El CDAG desempeña un papel central a la hora de permitir la soberanía de vProgs.

¿Qué son los vProgs y en qué se diferencian de los contratos inteligentes?

Los vProgs son programas soberanos que se ejecutan fuera de L1 mientras establecen resultados en L1 a través de pruebas.

Propiedades clave:

• Ejecución soberana: Cada vProg define sus propias reglas de rendimiento y dependencia.
• Control de la dependencia basada en el gas: Un vProg no puede leer el estado de otro vProg a menos que pague gas por el consumo de recursos.
• Transferencias no atómicas: Los vProgs no son transparentes a L1 como los recursos nativos. Las transferencias son asincrónicas y no atómicas.
• Requisito de KAS envuelto: Cualquier contrato no en línea debe usar KAS encapsulado a través de un puente canónico. El KAS L1 nativo no se puede usar directamente.

Este diseño separa el cálculo y el estado de L1 al tiempo que preserva la secuenciación y la liquidación compartidas.

¿Quién debería crear vProgs?

Según las discusiones de la comunidad, es posible que la mayoría de los desarrolladores de aplicaciones habituales no necesiten vProgs.

Sin embargo, vProgs puede resultar atractivo para:

• Arquitectos de Appchain
• Equipos que evalúan sistemas de tipo roll-up
• Proyectos que crean agentes de IA con un gran estado en cadena
• Diseñadores de sistemas que comparan contratos L1, acumulaciones L2 y modelos híbridos

Los vProgs combinan la secuenciación L1 unificada con el estado y el cálculo externalizados.

¿Qué papel juega el conocimiento cero (ZK)?

El hardfork integra la verificación ZK en L1, ampliando propuestas anteriores como KIP-16.

Las capacidades admitidas incluyen:

• Verificación de pruebas de Groth16
• Puentes sin confianza a sistemas L2
• Posibles aplicaciones orientadas a la privacidad

Se espera que las aplicaciones iniciales se ejecuten en línea, con billeteras que generen pruebas directamente. Incluso las implementaciones de ZK basadas en convenios, desarrolladas por colaboradores como Hans y Maxim, se ejecutarán en hardware estándar. No se requiere una infraestructura de probadores especializada para las primeras implementaciones.

Una computadora portátil estándar puede generar pruebas bajo los supuestos actuales.

Los programas centrados en la privacidad son técnicamente posibles tras la bifurcación dura. Sin embargo, la privacidad no figura como un objetivo principal de la hoja de ruta.

¿Cómo se relaciona Sparkle con vProgs?

Sparkle es una arquitectura propuesta por Anton para combinar DAG computacionales y pruebas ZK. Si bien tanto Sparkle como vProgs utilizan componentes CDAG y ZK, abordan diferentes cuestiones de diseño.

La característica distintiva de vProgs es la regulación de dependencias. Cada programa controla su rendimiento y evita dependencias externas arbitrarias. Este modelo facilita la componibilidad, preservando al mismo tiempo el aislamiento.

¿El Hardfork afectará la seguridad, MEV o los requisitos del nodo?

• Presupuesto de seguridad: No se prevé un impacto directo a corto plazo. Las mejoras dependen de la adopción real del producto, más que de cambios en la infraestructura.
   
• Requisitos del nodo: Sin cambios.
   
• Subastas de retroceso de MEV: Se considera prematuro dada la etapa actual de desarrollo del ecosistema.
   
• Molienda de PoW para STARKs: Las discusiones hacen referencia al comportamiento histórico en los inicios de Ethereum, donde las direcciones con ceros a la izquierda redujeron los costos del gas, lo que a su vez provocó la desestabilización de los mercados por prueba de trabajo. La mención era contextual, no una característica actual.

¿Qué añade SilverScript?

SilverScript es un lenguaje de alto nivel diseñado para programas Kaspa. Su objetivo es simplificar el desarrollo de convenios y programas.

Sus objetivos de diseño incluyen:

• Sintaxis legible
• Accesibilidad para nuevos desarrolladores
• Compatibilidad con herramientas automatizadas

Se espera que SilverScript reduzca la barrera para escribir aplicaciones basadas en pactos una vez que los activos nativos entren en funcionamiento.

Conclusión

La bifurcación dura de Kaspa, centrada en convenios, amplía la funcionalidad de la Capa 1 mediante activos nativos, convenios extendidos y verificación ZK. Introduce CDAG para el seguimiento estructurado de dependencias y sienta las bases para vProgs soberanos. La actualización conserva los requisitos de nodo existentes y el consenso de prueba de trabajo, a la vez que permite la emisión de tokens programables y las transferencias atómicas.

La activación del 5 de mayo de 2026 marca un avance técnico en la hoja de ruta de Kaspa. Añade programabilidad estructurada a nivel de protocolo y prepara la red para futuras actualizaciones, como DAGKnight y la implementación completa de vProgs.

Fuentes:

• Hard Fork centrado en Kaspa Convenant:Cuenta regresiva en Kas.live
• Hilo de Terah X: Próximos hitos y bifurcación dura centrada en Covenant
• Investigación Kaspa:Un modelo de columna vertebral formal para el DAG de computación vProg