Hard Fork Toccata de Kaspa: convênios, códigos de operação ZK e uma nova meta de junho

KaspaA próxima bifurcação Toccata adicionará dois novos caminhos de programabilidade à rede: programação de covenants L1 nativa e infraestrutura de aplicação baseada em conhecimento zero (zk), com a ativação da mainnet agora agendada para 5 a 20 de junho de 2026, adiada da meta original de 5 de maio.

Michael Sutton, da Kaspa Core, publicou um atualização detalhada Este artigo aborda o que o hard fork inclui, por que a data foi alterada e como os próximos meses devem se desenrolar. O fork foi originalmente iniciado por Ori Newman como um esforço para incorporar covenants ao mecanismo de script do Kaspa, em parte como resposta à discussão sobre o OP_CAT nos círculos do Bitcoin. Desde então, ele se tornou algo consideravelmente maior.

O que é o garfo rígido Toccata?

Toccata é um hard fork programado para a rede Kaspa que introduz novas funcionalidades diretamente na camada base. Um hard fork, para quem não está familiarizado, é uma atualização de protocolo que não é compatível com versões anteriores. Todos os nós devem atualizar para continuar participando da rede.

O nome segue a tradição da Kaspa de usar referências musicais para grandes atualizações. Esta, em particular, recebe o nome de uma forma musical clássica, a toccata, uma peça criada para demonstrar a habilidade técnica em um instrumento de teclado.

Em linhas gerais, Toccata acrescenta duas coisas a Kaspa:

• Programação de aliança nativa L1 por meio de um novo compilador chamado Silverscript
• Infraestrutura de aplicação baseada em zk, construído sobre esses mesmos alicerces de aliança

Esses sistemas não são intercambiáveis. Eles atendem a diferentes casos de uso e são direcionados a públicos de desenvolvedores distintos.

O que são Pactos e por que eles são importantes para Kaspa?

Os pactos são condições impostas sobre como os fundos em uma transação podem ser gastos no futuro. Em uma transação padrão de Bitcoin ou Kaspa, uma vez que as moedas são enviadas, o destinatário pode fazer o que quiser com elas. Os pactos mudam isso ao incorporar regras de gastos diretamente no script.

A Kaspa utiliza um modelo UTXO, semelhante ao Bitcoin, onde cada transação consome saídas existentes e cria novas. Os contratos (covenants) em um sistema UTXO permitem que os desenvolvedores criem fluxos multicontratuais com estado surpreendentemente complexos, mesmo que a computação subjacente permaneça local a cada UTXO.

Para tornar o desenvolvimento de covenants mais acessível, o Kaspa Core está finalizando o Silverscript, um compilador idealizado por Ori Newman, Michael Sutton, IzioDev e Manyfest. O Silverscript foi projetado para facilitar e tornar mais seguro escrever e implantar covenants complexos diretamente no Kaspa L1, sem que os desenvolvedores precisem trabalhar diretamente no nível do mecanismo de script.

O que são aplicações baseadas em ZK?

O segundo pilar de programabilidade introduzido no Toccata é baseado em aplicações zk. Este é o mais tecnicamente complexo dos dois e merece ser analisado cuidadosamente.

Descubra projetos promissores...

Projetos promissores...

(Propaganda)

O artigo continua...

ZK significa conhecimento zero, um método criptográfico que permite a uma das partes provar que algo é verdadeiro sem revelar os dados subjacentes. As provas ZK são cada vez mais utilizadas na escalabilidade de blockchains porque permitem que computações fora da cadeia sejam verificadas na cadeia de forma barata e segura.

Neste contexto, "Baseado" significa que o sistema zk segue integralmente a sequência L1. Uma aplicação zk baseada não pode adicionar ou remover transações de forma independente. Ela está ancorada à ordem de transações do próprio Kaspa, o que a torna confiável sem a necessidade de um sequenciador separado.

O Toccata introduz diversos componentes para dar suporte a isso:

• opcodes de verificação ZK, incluindo um verificador Groth16 flexível e um verificador RISC Zero STARK.
• Um opcode de acesso de compromisso de sequenciamento, permitindo que aplicativos baseados em compartilhamento se ancorem à ordenação de camada 1
• KIP-21, uma arquitetura de compromisso de sequenciamento particionada que garante que os custos de comprovação de um aplicativo zk sejam escaláveis ​​com sua própria atividade, e não com a atividade geral do DAG.

O verificador RISC Zero STARK já está implementado e ativado na testnet 12. A sua ativação na mainnet ainda está sendo decidida.

Por que os custos de comprovação são importantes

Para que qualquer aplicação zk seja prática, o custo de geração de provas precisa ser proporcional ao que a própria aplicação faz. Se uma aplicação zk tivesse que provar o trabalho em relação a toda a atividade no DAG mais amplo, os custos se tornariam imprevisíveis e incontroláveis. O KIP-21 resolve isso particionando os compromissos de sequenciamento, mantendo a carga de trabalho de cada aplicação autocontida.

O que já está implementado?

Uma parte significativa do hard fork já foi implementada. Os seguintes recursos já estão disponíveis:

• Suporte estendido a opcodes de mecanismos de script, a espinha dorsal dos covenants principais, sob o KIP-17.
• IDs de aliança para gerenciamento de linhagem como recurso de consenso e mecanismo, sob o KIP-20
• Códigos de operação ZK com um subsistema de pré-compilação zk-verifier, sob KIP-16, de autoria de Alexander Safstrom.
• opcode de acesso de compromisso de sequenciamento
• O KIP-21, de autoria de Sutton e implementado por Maxim Biryukov, está totalmente implementado e aguarda revisão.

Marcos de prova de conceito, incluindo covenants zk inline e covenants zk baseados em uma ponte canônica KAS, também foram concluídos pela Maxim e foram fundamentais para moldar o design final do fork.

Por que a data do hard fork foi adiada para junho?

A meta original para a rede principal era 5 de maio de 2026. Desde então, foi alterada para o período de 5 a 20 de junho de 2026.

A razão é arquitetônica. Uma vez que os circuitos e tempos de execução do ZK se vinculam a uma estrutura de hash de confirmação de sequenciamento, quaisquer alterações estruturais posteriores se tornam alterações incompatíveis. Errar no projeto e corrigi-lo mais tarde seria muito mais disruptivo do que investir tempo extra agora.

O KIP-21 já foi projetado para ser compatível com o esquema de compromisso que será exigido pelo vprogs, o roteiro de longo prazo da Kaspa para programas verificáveis ​​e componíveis de forma síncrona. Definir a estrutura correta antes da ativação da rede principal evita migrações dispendiosas posteriormente.

O congelamento de funcionalidades está previsto para 15 de abril de 2026.

O que acontece entre o congelamento de funcionalidades e a rede principal?

Após o congelamento de funcionalidades em 15 de abril, a Kaspa Core planeja uma reinicialização completa da testnet dedicada, TN12, com o conjunto final de funcionalidades incluído. Isso não é uma simulação da transição para o hard fork. Trata-se de uma rede limpa para testar o conjunto completo de funcionalidades em sua forma final.

A partir daí, a equipe irá incorporar os meses de trabalho acumulados de uma ramificação pendente de longa duração de volta à base de código principal. Esse processo envolve auditoria final, resolução de pendências, aperfeiçoamento da lógica de ativação de hard fork e gerenciamento da capacidade de atualização do banco de dados.

Assim que esse trabalho estiver concluído, um hard fork de teste será executado na TN10, a testnet de longo prazo, para simular uma transição completa no estilo da mainnet. A data da mainnet só será definida oficialmente após esse ensaio ser concluído com sucesso pela equipe.

O que os operadores de nó devem esperar

Para mineradores e operadores de nós, a atualização foi projetada para ser simples. Os nós precisam ser atualizados e as funcionalidades existentes devem continuar funcionando. Espera-se que os requisitos de espaço em disco aumentem em cerca de 20 a 50%. Não são previstas mudanças drásticas na infraestrutura.

O que Toccata realmente oferece para Kaspa

A Toccata adiciona dois sistemas de programabilidade funcionais à camada base do Kaspa: scripts nativos de Covenant L1 por meio do Silverscript e infraestrutura de aplicação baseada em zk por meio dos KIP-16, KIP-20 e KIP-21. Grande parte do trabalho técnico já foi concluída. Resta finalizar as interfaces, integrar a branch pendente à master e realizar um teste completo no TN10 antes da confirmação da data de lançamento na mainnet.

O período de 5 a 20 de junho de 2026 existe porque a equipe optou por acertar a arquitetura de confirmação de sequenciamento desde o início, em vez de corrigi-la posteriormente em condições de produção. Para os operadores de nós, a atualização foi projetada para ser simples, sem grandes alterações na infraestrutura além de um aumento modesto no espaço em disco.

Recursos

1. Kaspa em X: Postagem (abril de 2026)

2. Artigo de blog por Michael Sutton: Kaspa Covenants++ “Toccata” Hard-Fork Outlook