Tabla de contenido
¿Qué es el hardfork centrado en Covenant de Kaspa? ¿Cuál es el cronograma para el Hardfork del 5 de mayo de 2026? ¿Cómo funcionan los activos y convenios nativos en Kaspa? ¿Qué es el hardfork computacional? $DÍA (CDAG)?¿Qué son los vProgs y en qué se diferencian de los contratos inteligentes?¿Qué papel desempeña el conocimiento cero (ZK)?¿Cómo se relaciona Sparkle con los vProgs?¿Afectará el Hardfork los requisitos de seguridad, MEV o de nodo?¿Qué agrega SilverScript?Fuentes de conclusión:Preguntas frecuentes
¿Qué es el Hardfork centrado en Covenant de Kaspa?
De acuerdo a El hilo de Taré,Cuando 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 de convenio extendida. También sienta las bases para programas verificables (vProgs) e integraciones de conocimiento cero (ZK).
Kaspa opera como una cadena de bloques de prueba de trabajo utilizando una arquitectura blockDAG. Es Actualización creciente en mayo de 2025 aumentó el rendimiento a 10 bloques por segundo (BPS). Por lo tanto, el próximo hardfork 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. Se centra en habilitar la emisión de tokens nativos, reglas de gasto programables y verificación ZK en L1.
¿Cuál es el cronograma para el Hardfork del 5 de mayo de 2026?
Cuenta regresiva del Hard Fork centrado en Kaspa al momento de escribir este artículo | Kas.live
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 activos nativos y de convenios.
- KIP de compromiso del secuenciador: Se espera 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 Mainnet: 5 de mayo de 2026.
Las actualizaciones posteriores al hardfork incluyen DAGKnight, que apunta al consenso adaptativo y un rendimiento superior a 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 el soporte para fichas KRC20. Estos activos existen directamente en L1 y pueden transferirse atómicamente.
Las transferencias atómicas se aplican a:
- Convenios en línea regulares
- Ejecuciones de pactos ZK y no ZK
- Transferencias de tokens KRC20
Los convenios en línea generan pruebas inmediatas dentro de la billetera. No existe desacoplamiento entre los datos de la transacción y la transición de estado. Este diseño admite la atomicidad y la ejecución determinista.
Pactos Extendidos (Pactos++)
El sistema de pactos de Kaspa está inspirado en la investigación de Bitcoin sobre condiciones de gasto UTXO programables. Covenants++ amplía este sistema para permitir reglas de transacción más expresivas.
Los casos de uso incluyen:
- Controles de seguridad estilo bóveda
- Mecanismos de custodia
- Transferencias condicionales
- Lógica de token estructurada
El sistema mantiene un modelo UTXO en lugar de contratos inteligentes completos basados en cuentas.
¿Qué es el computacional? $DÍA (CDAG)?
El hardfork introduce el Computacional $DÍA (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 blockchains como Solana y Sui, pero implementado en su totalidad dentro del entorno blockDAG de Kaspa.
CDAG juega un papel central al 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 resuelven los resultados en L1 mediante pruebas.
Propiedades clave:
- Ejecución soberana: Cada vProg define sus propias reglas de rendimiento y dependencia.
- Control de dependencia del gas: Un vProg no puede leer el estado de otro vProg a menos que pague gasolina por el consumo de recursos.
- Transferencias no atómicas: Los vProgs no son transparentes para L1 de la misma manera que los activos nativos. Las transferencias son asincrónicas y no atómicas.
- Envuelto $QUÉ requisito: Cualquier convenio que no esté en línea debe usar envuelto $QUÉ a través de un puente canónico. Nativo L1 $QUÉ no se puede utilizar 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, los vProgs pueden resultar atractivos para:
- Arquitectos de cadenas de aplicaciones
- Equipos que evalúan sistemas estilo rollup
- 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 secuenciación L1 unificada con estado externalizado y computación.
¿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 prueba Groth16
- Puentes sin confianza hacia los sistemas L2
- Posibles aplicaciones orientadas a la privacidad
Se espera que las aplicaciones iniciales se ejecuten en línea y las billeteras generen pruebas directamente. Incluso se espera que las implementaciones ZK basadas en convenios desarrolladas por contribuyentes como Hans y Maxim se ejecuten en hardware básico. No se requiere infraestructura de probador especializada para implementaciones tempranas.
Una computadora portátil estándar puede generar pruebas bajo los supuestos actuales.
Los programas centrados en la privacidad son técnicamente posibles después del hardfork. Sin embargo, la privacidad no figura como un objetivo principal de la hoja de ruta.
¿Cómo se relaciona Sparkle con los 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 definitoria de vProgs es la regulación de dependencia. Cada programa controla su rendimiento y evita dependencias externas arbitrarias. Este modelo admite la componibilidad al tiempo que preserva el aislamiento.
¿El Hardfork afectará los requisitos de seguridad, MEV o de nodo?
- Presupuesto de seguridad: No se espera ningún impacto directo en el 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 sobornos MEV: Considerado prematuro dada la etapa actual de desarrollo del ecosistema.
- Rectificado PoW para STARK: 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 condujo a mercados de molienda de prueba de trabajo. La mención fue contextual más que una característica actual.
¿Qué agrega 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 convenios una vez que los activos nativos entren en funcionamiento.
Conclusión
El hardfork centrado en convenios de Kaspa amplía la funcionalidad de la Capa 1 a través de 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 preserva los requisitos de los nodos existentes y el consenso de prueba de trabajo al tiempo que permite la emisión de tokens programables y transferencias atómicas.
La activación del 5 de mayo de 2026 marca un paso técnico en la hoja de ruta de Kaspa. Agrega programabilidad estructurada a nivel de protocolo y prepara la red para futuras actualizaciones, incluida DAGKnight y la implementación completa de vProgs.
Fuentes:
- Hard Fork centrado en Kaspa Convenant: Cuenta regresiva en Kas.live
- Hilo Taré X: Próximos hitos y Hard Fork centrado en Covenant
- Investigación de caso: Un modelo troncal formal para el cálculo de vProg $DÍA
