Signet permite testar software Bitcoin em conjunto. Tem sua própria cadeia e moedas de teste. Além das regras usuais e de Proof of Work, novos blocos precisam cumprir uma condição especial, baseada em assinatura no Signet padrão. Isso facilita os testes, mas implica um modelo de confiança diferente da rede principal.
Ana quer ver o que uma carteira nova mostra depois de enviar um pagamento e após sua confirmação em um bloco. Uma carteira é um aplicativo ou dispositivo para receber e enviar bitcoins. Um bloco reúne transações em um lote acrescentado ao histórico compartilhado. No Signet, Ana pode usar moedas de teste, por exemplo de um faucet, serviço que as distribui para experiências. Não são BTC da mainnet, a rede principal, e o protocolo não as troca por bitcoins reais. Os próprios endereços exigem cuidado: Signet compartilha alguns formatos de endereço de teste com Testnet. A aparência do endereço, sozinha, não identifica a rede certa. [1] [2] [8]
Karl-Johan Alm e Anthony Towns escreveram BIP 325 (o documento técnico que descreve Signet); Bitcoin Core v0.21.0 introduziu suporte ao Signet. O programa oferece uma rede pública padrão, mas uma equipe pode definir sua própria condição para criar blocos e seus participantes. Por isso, dizer “usamos Signet” não basta: ambos os lados precisam usar a mesma rede. O identificador das mensagens de rede deriva dessa condição, não do nome do projeto. [1] [3] [4]
Um Full Node, nó que verifica as regras por conta própria, continua verificando transações e Proof of Work, o resultado do trabalho computacional necessário para criar um bloco. Também verifica a condição adicional do Signet. Na rede padrão, minerar não basta: é necessária a assinatura correspondente. O cabeçalho, resumo compacto do bloco, não substitui essa verificação; os dados necessários ficam dentro do bloco. [1] [9]
Uma assinatura digital permite verificar se uma mensagem foi aprovada por quem possui a chave privada correspondente, um valor numérico secreto, sem revelar essa chave. Quem consegue satisfazer a condição de assinatura influencia a produção de blocos. Pode adiar a assinatura ou restringir as transações incluídas. Isso não lhe dá as chaves privadas de Ana nem o direito de obrigar o nó dela a aceitar qualquer transação inválida. As outras regras continuam valendo. Essa participação controlada é útil para testes e explica por que Signet não reproduz o modelo de segurança da mainnet. [1] [9]
Desenvolver exige mais do que observar um pagamento bem-sucedido. A equipe precisa saber como a aplicação reage quando os blocos param ou ocorre uma reorganização: o nó substitui blocos recentes por outro ramo válido. Um teste coordenado pode preparar essa situação e conferir se a carteira atualiza as confirmações corretamente. Signet não promete serviço ininterrupto; ajuda a testar falhas de maneira mais previsível. [1] [5] [6]
Na Testnet, a criação de blocos é aberta, e suas oscilações podem dificultar uma experiência conjunta. Regtest permite criar blocos facilmente sob demanda, o que serve aos testes automáticos próprios. Também pode conectar vários computadores; não precisa ser um programa isolado. Signet atende a outra necessidade: colaboração prolongada entre participantes independentes com condições combinadas para produzir blocos. Nenhum desses modos substitui todas as outras verificações. [1] [2]
A challenge é um script, um pequeno programa que descreve o que o bloco deve demonstrar. Pode exigir uma assinatura ou Multisig, um número combinado de assinaturas de várias chaves. Um Signet próprio também pode usar OP_TRUE, condição satisfeita sem assinatura. Nesse caso, uma solução vazia basta. Portanto, é preciso falar em condição adicional de script, e não afirmar que todo Signet sempre exige alguém para assinar. [1] [9]
BIP 325 coloca a solução não vazia em dados especiais da Coinbase Transaction, a primeira transação do bloco. Aqui o termo não tem relação com a corretora homônima. Esses dados ampliam o compromisso criptográfico (commitment) do BIP 141, que vincula o bloco aos dados witness, incluindo assinaturas, e usam o marcador 0xecc7daa2. Não são outro pagamento comum ao assinante. Uma condição trivialmente satisfeita permite omitir a solução adicional, não dispensar automaticamente as demais regras do bloco. [1] [9] [10]
Se a mensagem assinada incluísse aquela mesma assinatura, haveria uma dependência circular. Por isso, a verificação usa uma impressão digital modificada das transações, com a solução esvaziada, e duas transações virtuais. Elas servem ao cálculo; não são enviadas como pagamentos extras. A assinatura também exclui o nonce do cabeçalho, o número alterado na busca por Proof of Work. Mudá-lo não exige nova assinatura, mas isso não permite alterar livremente o resto do bloco. [1] [9]
Ana primeiro verifica se carteira, nó e explorador de blocos usam a mesma rede de testes. Um explorador de blocos é um aplicativo para consultar transações e blocos de uma determinada rede. No Bitcoin Core, getblockchaininfo e seu campo signet_challenge ajudam a identificar a condição configurada. Depois observa uma confirmação real, não apenas a mensagem de envio, usando uma carteira de testes separada. O sucesso mostra como a aplicação funciona naquelas condições; não garante a segurança dos fundos nem resistência a um atacante na mainnet. [7] [8]
Para ter uma visão mais completa, leia este verbete junto com Nakamoto Consensus, Block Propagation, Initial Block Download, Block Weight, Bitcoin, Bitcoin Core. Também há referências a este verbete em Testnet, Miniscript, Dead Man’s Switch.