O próximo hard fork de Kaspa, focado no Covenant: o que sabemos

O que é o hardfork centrado no Covenant de Kaspa?

De acordo com as O fio de Terah, Kaspa está preparando um hard fork centrado no Covenant, agendado para ativação da rede principal Em 5 de maio de 2026. A atualização expande Camada 1 (L1) programabilidade através da introdução de recursos nativos e funcionalidades de covenant estendidas. Também estabelece as bases para programas verificáveis ​​(vProgs) e integrações de conhecimento zero (ZK).

A Kaspa opera como uma blockchain de prova de trabalho usando uma arquitetura blockDAG. Atualização Crescendo Em maio de 2025, a taxa de transferência aumentou para 10 blocos por segundo (BPS). Portanto, o próximo hard fork se baseia nessa fundação sem alterar os requisitos dos nós ou os fundamentos do consenso.

Os desenvolvedores principais descrevem a versão como uma atualização com escopo definido. Ela se concentra em habilitar a emissão nativa de tokens, regras de gastos programáveis ​​e verificação de ZK na camada 1. 

Qual é o cronograma para o hard fork de 5 de maio de 2026?

Diversos marcos antecedem a ativação da rede principal, de acordo com o tópico de Terah:

• Reiniciar Testnet 12 (TN12): Programado para o início de fevereiro de 2026 para dar suporte aos testes de ativos nativos e de conformidade.
   
• Compromisso do Sequenciador KIP: Previsto para cerca de 12 de fevereiro de 2026. Esta proposta introduz compromissos de carga útil dos mineradores para fortalecer a descentralização em tempo real.
   
• Lançamento do SilverScript: Uma linguagem de programação de alto nível para escrever programas em Kaspa. Desenvolvida por Ori Newman e colaboradores, ela simplifica o desenvolvimento de covenants.
   
• Hardfork da Mainnet: Maio 5, 2026.

As atualizações pós-hardfork incluem o DAGKnight, que visa consenso adaptativo e taxa de transferência acima de 100 BPS, e a implementação completa do vProgs.

Como funcionam os ativos e convênios nativos no Kaspa?

Recursos nativos na camada 1

O hard fork introduz recursos nativos, incluindo suporte para Tokens KRC20Esses ativos existem diretamente na camada 1 e podem ser transferidos atomicamente.

As transferências atômicas se aplicam a:

• Cláusulas regulares em linha
• Execuções de cláusulas ZK e não-ZK
• Transferências de tokens KRC20

Os contratos embutidos geram provas imediatas dentro da carteira. Não há desacoplamento entre os dados da transação e a transição de estado. Esse design suporta atomicidade e execução determinística.

Pactos Estendidos (Pactos++)

O sistema de covenants do Kaspa é inspirado na pesquisa sobre Bitcoin a respeito das condições programáveis ​​de gastos em UTXOs. O Covenants++ estende esse sistema para permitir regras de transação mais expressivas.

Descubra projetos promissores...

Projetos promissores...

(Propaganda)

O artigo continua...

Os casos de uso incluem:

• controles de segurança estilo cofre
• Mecanismos de garantia fiduciária
• Transferências condicionais
• lógica de token estruturada

O sistema mantém um modelo UTXO em vez de contratos inteligentes totalmente baseados em contas.

O que é um DAG computacional (CDAG)?

O hard fork introduz o DAG Computacional (CDAG).). O CDAG registra todas as declarações de leitura e escrita feitas pelos programas.

Esta estrutura:

• Monitora o uso de recursos
• Regula as dependências entre programas
• Garante o cumprimento dos compromissos com o gás.

O design é comparável aos modelos de execução em blockchains como Solana e Sui, mas implementado integralmente no ambiente blockDAG da Kaspa.

A CDAG desempenha um papel central na promoção da soberania dos vProgs.

O que são vProgs e como eles diferem dos contratos inteligentes?

Os vProgs são programas soberanos que executam fora da camada 1, mas resolvem os resultados na camada 1 por meio de provas.

Propriedades-chave:

• Execução soberana: Cada vProg define suas próprias regras de throughput e dependência.
• Controle de dependência baseado em gás: Um vProg não pode ler o estado de outro vProg a menos que pague gás pelo consumo de recursos.
• Transferências não atômicas: Os vProgs não são transparentes para a camada 1 da mesma forma que os ativos nativos. As transferências são assíncronas e não atômicas.
• Requisito KAS encapsulado: Qualquer covenant não inline deve usar KAS encapsulado por meio de uma ponte canônica. KAS nativo de camada 1 não pode ser usado diretamente.

Este projeto separa a computação e o estado da camada L1, preservando o sequenciamento e a resolução compartilhados.

Quem deve desenvolver vProgs?

De acordo com discussões da comunidade, a maioria dos desenvolvedores de aplicativos comuns pode não precisar do vProgs.

No entanto, o vProgs pode interessar a:

• Arquitetos da Appchain
• Equipes avaliando sistemas do tipo rollup
• Projetos que desenvolvem agentes de IA com um grande estado on-chain.
• Projetistas de sistemas comparando contratos L1, rollups L2 e modelos híbridos.

Os vProgs combinam sequenciamento L1 unificado com estado e computação externalizados.

Qual o papel do conhecimento zero (ZK)?

O hard fork integra a verificação ZK na camada 1, ampliando propostas anteriores como KIP-16.

As funcionalidades suportadas incluem:

• Verificação de provas Groth16
• Pontes sem confiança para sistemas de camada 2
• Aplicações potenciais voltadas para a privacidade

Espera-se que as aplicações iniciais funcionem em linha, com as carteiras gerando provas diretamente. Até mesmo as implementações de ZK baseadas em covenants, desenvolvidas por colaboradores como Hans e Maxim, devem funcionar em hardware comum. Nenhuma infraestrutura de prova especializada é necessária para as primeiras implantações.

Um computador portátil padrão consegue gerar provas de acordo com as hipóteses atuais.

Programas focados em privacidade são tecnicamente possíveis após o hard fork. No entanto, a privacidade não consta como um foco principal do roteiro.

Qual a relação entre o Sparkle e o vProgs?

Sparkle é uma arquitetura proposta por Anton para combinar DAGs computacionais e provas ZK. Embora tanto Sparkle quanto vProgs usem componentes CDAG e ZK, eles abordam questões de projeto diferentes.

A característica definidora dos vProgs é a regulação de dependências. Cada programa controla sua própria taxa de transferência e evita dependências externas arbitrárias. Esse modelo suporta a composibilidade, preservando o isolamento.

O hard fork afetará a segurança, o MEV ou os requisitos de nó?

• Orçamento de Segurança: Não se prevê nenhum impacto direto a curto prazo. As melhorias dependem da adoção efetiva do produto, e não de alterações na infraestrutura.
   
• Requisitos do nó: Sem alterações.
   
• Leilões de propina MEV: Considerado prematuro, dada a atual fase de desenvolvimento do ecossistema.
   
• Moagem de PoW para STARKs: As discussões fazem referência ao comportamento histórico no início do Ethereum, onde endereços com zeros à esquerda reduziam os custos de gás, o que, por sua vez, levou a mercados de mineração de prova de trabalho. A menção foi contextual, e não se trata de um recurso atual.

O que o SilverScript adiciona?

SilverScript é uma linguagem de alto nível projetada para programas Kaspa. Seu objetivo é simplificar o desenvolvimento de contratos e programas.

Seus objetivos de projeto incluem:

• Sintaxe legível
• Acessibilidade para novos desenvolvedores
• Compatibilidade com ferramentas automatizadas

Espera-se que o SilverScript reduza as barreiras para o desenvolvimento de aplicativos baseados em covenants assim que os recursos nativos forem lançados.

Conclusão

O hard fork centrado em covenants do Kaspa expande a funcionalidade da Camada 1 por meio de ativos nativos, covenants estendidos e verificação ZK. Ele introduz o CDAG para rastreamento estruturado de dependências e estabelece as bases para vProgs soberanos. A atualização preserva os requisitos de nós existentes e o consenso de prova de trabalho, ao mesmo tempo que permite a emissão programável de tokens e transferências atômicas.

A ativação em 5 de maio de 2026 marca um passo técnico no roteiro da Kaspa. Ela adiciona programabilidade estruturada no nível do protocolo e prepara a rede para futuras atualizações, incluindo o DAGKnight e a implementação completa do vProgs.

Fontes:

• Hard Fork centrado no Convenant KaspaContagem regressiva no Kas.live
• Terah X ThreadPróximos marcos e Hard Fork focado no Covenant
• Pesquisa KaspaUm modelo formal de estrutura básica para o DAG de computação vProg