O Fórum de Coordenação KCC da Kaspa finalizou três padrões que abrangem interfaces de covenant, autorização e tokens fungíveis, estabelecendo especificações compartilhadas para desenvolvedores que criam aplicações na rede.
Resumo
- O KCC-1 define interfaces compartilhadas para carteiras, compiladores, indexadores e outras ferramentas que trabalham com covenants.
- O KCC-2 especifica cinco esquemas de autorização padrão, incluindo chaves públicas, scripts e identificadores de covenant.
- O KCC-20 estabelece regras de transferência de tokens e oferece suporte ao recebimento de tokens por meio de uma saída compatível existente.
- A finalização estabelece convenções do ecossistema sem alterar as regras de consenso nem exigir que todos os participantes as adotem.
O Fórum de Coordenação KCC informou em um anúncio de 21 de outubro que o KCC-1, o KCC-2 e o KCC-20 estavam finalizados e prontos para adoção em todo o ecossistema. O fórum convidou os desenvolvedores a se juntarem ao seu canal público para tirar dúvidas, discutir implementações e obter suporte.
O repositório de padrões canônicos da Kaspa lista os três documentos como Finalizados. Seu índice identifica o KCC-1 como a especificação de covenant, o KCC-2 como a especificação de autoridade e o KCC-20 como o padrão de aplicação para covenants de tokens fungíveis.
O repositório descreve os KCCs como convenções compartilhadas para implementações independentes. Sua documentação separa essas convenções das mudanças no consenso ou no comportamento do nó principal, que pertencem às Propostas de Melhoria da Kaspa.
Os padrões da Kaspa abrangem diferentes partes do desenvolvimento de aplicações
O KCC-1 define termos comuns, layouts de dados e uma interface binária de aplicação, ou ABI, para covenants. A especificação descreve como o software codifica informações, chama funções de programa e identifica o estado carregado entre transações.
Seus autores, Romain Billot, Michael Sutton e Ori Newman, identificam compiladores, carteiras, indexadores e construtores de transações entre as ferramentas que precisam concordar sobre esses detalhes. O documento afirma que implementações independentes precisam de formatos comuns além de simplesmente produzir scripts que passem nas verificações de consenso.
A especificação KCC-1 deixa os desenvolvedores livres para escolher sua linguagem de programação, compilador e framework. Sua interface compartilhada abrange pontos de entrada de programa, modelos de estado e regras para lidar com transações envolvendo múltiplas entradas.
Dentro do mesmo documento, os autores distinguem regras básicas de interface de recursos que dependem de identificadores de covenant. Programas sem vínculos de covenant podem seguir o KCC-1, mas a especificação afirma que eles não recebem as garantias de linhagem e autorização fornecidas pelo KIP-20.
O KCC-2 define quem pode autorizar uma operação
O KCC-2, escrito por Billot e Sutton, especifica como os programas identificam uma autoridade e as verificações mínimas necessárias para estabelecer sua aprovação. Uma autoridade pode ser uma chave pública, um compromisso com uma chave, um script ou uma linhagem de covenant continuada.
A especificação atribui identificadores padrão a cinco esquemas de autorização. Suas opções de chave pública abrangem assinaturas Schnorr e ECDSA, enquanto suas outras opções permitem que um script ou uma linhagem de covenant participe como autoridade.
Para autorização por hash de chave pública, o KCC-2 exige que a transação revele a chave pública correspondente, compare seu hash com o valor de autoridade armazenado e forneça uma assinatura válida. Especificações de nível superior definem a mensagem assinada e quaisquer condições adicionais.
O registro de autoridades reserva faixas separadas para esquemas padrão e personalizados. O KCC-2 permite que os participantes adotem esquemas personalizados sem esperar pela padronização, desde que suas definições especifiquem o formato, o significado e as verificações de aprovação.
De acordo com seu esquema de identificador de covenant, a aprovação exige uma entrada da linhagem de covenant identificada. O KCC-2 afirma que uma convenção de nível superior pode impor verificações adicionais ao programa e ao estado dessa entrada.
KCC-20 define regras de transferência e recebimento de tokens
O KCC-20 se baseia nos dois primeiros padrões, definindo quantidades de tokens, propriedade e interfaces de transferência. O documento nomeia Sivan Helfer, Sutton, Newman e Billot como seus autores.
Sua especificação exige que cada covenant de token publique informações de programa que o software possa usar para decodificar o estado e construir transferências. As configurações devem divulgar os esquemas de propriedade suportados e os limites de entradas e saídas de tokens.
Um recurso chamado recebimento emprestado permite que um remetente use uma saída de token compatível existente do destinatário como destino. O KCC-20 afirma que a transação recria essa saída com mais tokens, preserva sua propriedade e estado estendido, e não pode reduzir seu valor em KAS.
A seção de segurança adverte que substituir a saída altera sua referência de transação, invalidando transações não confirmadas que gastam a referência anterior. Uma carteira deve descobrir a substituição antes de gastá-la, de acordo com o documento.
O padrão vincula uma implementação de referência Argent com contratos SilverScript gerados e testes de conformidade em Rust.
O status final carrega requisitos de implementação
O KCC-0, o documento que rege o processo de padrões, exige mais do que a conclusão de um período final de revisão. Ele afirma que uma convenção da trilha de padrões precisa de vetores de teste legíveis por humanos e legíveis por máquina, além de pelo menos uma implementação pública que passe nas verificações legíveis por máquina.
As dependências devem ser Final para outros KCCs ou Active para KIPs, de acordo com as mesmas regras. O KCC-0 afirma que as mudanças de status ocorrem por meio de pull requests e o índice do repositório deve ser atualizado com elas.
O KCC-0 descreve os vetores de teste legíveis por máquina como a forma autoritativa para testes automatizados quando acompanham exemplos legíveis por humanos. Suas regras de submissão exigem que as considerações de segurança abordem ameaças, suposições de confiança e possíveis problemas de replay antes que um documento da trilha de padrões possa entrar em Last Call.
O documento regulador declara que a finalização não exige que todos os participantes do ecossistema implementem uma convenção. Mudanças substanciais geralmente exigem um KCC substituto, enquanto correções e esclarecimentos seguem as regras de emenda do documento.
O desenvolvimento de aplicações da Kaspa incluiu anteriormente infraestrutura separada de Camada 2. A Gate anunciou uma integração da Kasplex Layer 2 em abril, permitindo depósitos e saques de KAS através da rede compatível com EVM, conforme relatado pela crypto.news.
Em seu anúncio de integração anterior, a Gate disse que os clientes poderiam transferir KAS da rede base para uma carteira Kasplex. Os materiais do projeto Kasplex descrevem uma ponte bidirecional e afirmam que desenvolvedores familiarizados com ferramentas Ethereum podem implantar contratos alterando seus endpoints de chamada de procedimento remoto.
A Kasplex descreve seu design como um rollup leve que coloca bytecode EVM em transações Kaspa e o executa fora da cadeia. Sua documentação afirma que a Kaspa fornece ordenação de transações e disponibilidade de dados, enquanto o KAS transferido por ponte serve como token de gas da Camada 2.
