Zycord: uma rede ponto a ponto de transições de estado autocertificadas

Zycord: uma rede ponto a ponto de transições de estado autocertificadas. Por Simstoshi, v1.0, 2026. Toda transação carrega o estado que leu e o estado que escreveu, de modo que verificá-la é uma função pura de seus bytes — sem disco, sem histórico, sem confiança e sem limite de paralelismo.

Cite este documento. O registro arquivado e versionado de referência é doi:10.5281/zenodo.22167490. Um PDF é servido a partir deste site, com uma assinatura destacada feita pela chave do projeto E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29. O texto abaixo é esse documento, sem cortes.

1. Introdução#

Um nó de blockchain hoje faz três trabalhos que nada têm em comum: ele dissemina dados, verifica computação e muta estado. Dados escalam com largura de banda. A verificação escala com núcleos: é embaraçosamente paralela se as transações puderem ser conferidas de forma independente. A mutação de estado é o único recurso genuinamente sequencial: em algum lugar, precisa existir um único histórico autoritativo de escritas.

Os projetos existentes entrelaçam os três. No modelo dominante, um nó não consegue verificar uma transação sem manter o estado global, de modo que a verificação herda os limites de escala do estado; e como um único mercado de gas precifica os três recursos em conjunto, uma conferência de assinatura concorre no mesmo leilão que uma escrita de armazenamento. Cadeias recentes de alto desempenho paralelizam a execução dentro do nó, mas todo nó ainda reexecuta tudo, e a restrição vinculante passa a ser a E/S de estado. A resposta tem sido máquinas cada vez maiores, ou seja, cada vez menos nós.

Este artigo toma o caminho oposto. Não paralelizamos a execução contra um estado compartilhado; nós removemos o estado do caminho paralelo por completo. Uma transação torna-se um certificado que carrega suas próprias entradas e saídas. Verificá-lo é uma função pura de seus bytes. O trabalho da cadeia encolhe para ordenar certificados e executar um fold determinístico sobre eles — um laço de comparações e adições que toca o estado exatamente uma vez por certificado. Conflitos não invalidam blocos; eles fazem com que certificados individuais sejam omitidos, e cada omissão é cobrada de um avalista caucionado. A concorrência não é descoberta em tempo de execução; ela é declarada, slot a slot, pelo autor do contrato.

As seções a seguir definem o certificado (§2), o fold (§3), o acesso tipado ao estado (§4), a economia de seguro (§5), os sequenciadores de aplicação (§6), a resistência à censura (§7), o mercado duplo de taxas (§8), as provas de fraude e o caminho da amostragem (§9), a máquina virtual (§10), os ativos nativos sem máquina (§11), os pagamentos confidenciais (§12), a rede (§13), o lançamento em três eras e sua tesouraria (§14) e as medições da implementação de referência (§15).

2. Certificados de transição de estado#

Um certificado é o único tipo de transação no Zycord:

Certificate {
    reads:   [(slot, access, operand)]   // declared inputs
    writes:  [(slot, op, value)]         // declared outputs
    program: bytes                       // code or native-op reference
    sigs:    [signature]                 // spending authority
    underwriter: (id, sig, seq)          // who insures it (§5)
    ttl:     height                      // valid if committed by this height
    fee:     (seq_gas_bid, par_gas_bid)  // two markets (§8)
}

Um slot é (address, word). Um certificado é válido se três conferências passarem, nenhuma das quais exige qualquer estado:

1. cada sig autoriza as células que gasta;
2. a assinatura do avalista é bem formada sobre (certificate, ttl);
3. reexecutar program contra os reads declarados produz exatamente os writes declarados. As assinaturas precisam ser canônicas, e isso é uma regra de consenso, não a boa educação de uma biblioteca. O id de um certificado é o hash de seus campos autorizadores — reads, writes, program, underwriter (o avalista), ttl e os lances de taxa. As assinaturas não estão entre eles, e o parágrafo seguinte diz por quê. O conjunto de vistos indexado por esse id é toda a defesa contra replay. A taxa é um campo autorizador e não uma preferência de retransmissão, e a distinção é monetária: um lance é o signatário consentindo com um custo, então um lance fora do id seria um lance que qualquer um em trânsito poderia reescrever — inflado para queimar o saldo do remetente pela taxa-base, ou zerado para manter o certificado fora de todo bloco. O que um certificado paga é parte do que seu signatário autorizou, e o id diz isso. O que a canonicidade compra é mais estreito do que um id e ainda assim é uma regra de consenso: um esquema que admite duas codificações de uma assinatura admite dois exemplares de um certificado, e duas implementações que discordem sobre qual deles verifica bifurcaram sobre um certificado que nenhuma delas pode chamar de inválido. A regra que fecha isso cabe em uma frase: uma codificação de assinatura não canônica é inválida, e uma implementação cujo verificador aceite uma delas não é uma implementação deste protocolo. Esquemas sólidos já rejeitam tais codificações; a razão para escrever isso é que os que não rejeitam também são populares, e uma implementação independente que recorresse a um deles divergiria de um modo que nenhum teste próprio revelaria.

Demonstrações aleatorizadas são a exceção, e a exceção é estrutural, não uma questão de codificação. Uma prova de intervalo (§12) é aleatorizada: para um enunciado, o provador escolhe nonces, de modo que um enunciado tem ilimitadas provas válidas, todas canônicas, e não há codificação não canônica a rejeitar. Duas provas válidas de um enunciado não são duas codificações de uma prova; são duas provas, e o beneficiário — que detém a abertura — sempre pode produzir uma nova. A canonicidade, portanto, não as alcança. Uma assinatura é uma dessas, e isso passa despercebido com facilidade porque ela não é uma das exóticas. Ed25519 é uma prova de conhecimento de Schnorr: o signatário escolhe um nonce, e cada nonce produz uma assinatura diferente sobre a mesma mensagem, cada uma válida e cada uma perfeitamente canônica. A derivação determinística de nonce é uma regra para signatários que nenhum verificador pode conferir e que nenhuma regra de codificação pode impor, porque todo ponto de nonce é um ponto canonicamente codificável como qualquer outro. Assim, uma autorização tem ilimitadas assinaturas, e um id que as cobrisse teria ilimitados valores — cada um produzível por qualquer um dos signatários exigidos pelo certificado, carregando intactas as assinaturas dos demais, e cada um cobrável em um bloco próprio. O modelo de ameaça é mais estreito que o de uma prova e a conclusão é a mesma: uma prova pode ser rearranjada aleatoriamente por um beneficiário que não detém chave alguma, ao passo que uma segunda assinatura exige uma chave que o certificado já requer. O id fecha essa lacuna por construção: ele se compromete com o que um certificado autoriza e nunca com o que ele meramente demonstra, de modo que assinaturas e provas igualmente trafegam fora da pré-imagem do id. Reassinar ou rearranjar aleatoriamente produz o mesmo id, o conjunto de vistos pega a duplicata, e um bloco que carregue as duas é inválido. Isso divide os campos de um certificado em dois tipos — autorização, que o id cobre e as assinaturas assinam, e evidência, que nenhum dos dois cobre. A divisão não é uma preocupação de §12 à espera dos pagamentos confidenciais; ela é estrutural desde o bloco 0, onde a única evidência que um certificado carrega são suas assinaturas. Um verificador confere a evidência a partir dos bytes no estágio paralelo e depois a descarta; apenas a autorização sobrevive até o id, o conjunto de vistos e o fold.

A divisão cria uma obrigação que o id não carrega mais, e ela é nomeada aqui em vez de descoberta em produção. Evidência fora da pré-imagem do id é evidência que qualquer um em trânsito pode substituir: pegue um certificado, troque sua prova por lixo e propague — mesmo id, exemplar agora inválido. Duas regras fecham os dois buracos que isso abre. Primeiro, um bloco se compromete com a evidência que carrega. A lista de certificados do bloco é uma lista de hashes de exemplar — uma folha por certificado, sobre toda a sua codificação, evidência incluída — de modo que "este bloco é válido" permanece uma afirmação sobre bytes que o próprio bloco fixa. O id responde esta autorização já foi cobrada, o hash de exemplar responde estes bytes a comprovam, e as duas perguntas nunca compartilham uma chave. Uma folha basta enquanto a evidência for inseparável da codificação, como é enquanto a evidência forem assinaturas; quando as provas de §12 a tornarem um campo próprio, a folha passa a ser o par (id, hash da evidência), e o compromisso é o mesmo compromisso. O que ela jamais pode se tornar é uma lista de ids: isso não se comprometeria com evidência nenhuma em particular e, como a raiz da lista de certificados é um campo do cabeçalho e o cabeçalho é a pré-imagem do proof of work, trocar a evidência não custaria nada e deixaria o trabalho de pé. Este é o precedente das transações com testemunha comprometida, e ele é seguido pela razão que o fez ser inventado: um id que cobria a evidência era maleável, e um id que ignora evidência não comprometida é cego. Segundo, a retransmissão trata exemplares, não ids: um nó que receba um exemplar cuja evidência falhe na verificação descarta esse exemplar sem prejuízo ao id — o id não é marcado, não é cacheado como inválido, e um exemplar posterior que verifique é retransmitido normalmente. Uma cópia mutilada custa ao seu mutilador a largura de banda de enviá-la e não custa nada ao certificado. A cegueira do proponente permanece intacta: ele inclui exemplares que sua própria conferência sem estado aceitou, de modo que não pode ser induzido a incluir uma prova mutilada mais do que uma assinatura ruim, e a afirmação de §3 mantém o sentido que tinha.

A validade é uma função pura dos bytes do certificado. Qualquer máquina pode conferi-la, em um pool de threads, em outro computador, em uma GPU, sem banco de dados, sem histórico e sem sincronização. As conferências de assinatura agrupam-se entre certificados; certificados do mesmo programa agrupam-se em cargas de instrução única e múltiplas threads (§6); provas de intervalo (§12) agrupam-se com custo marginal logarítmico. Esta é a propriedade sobre a qual todo o resto do artigo é construído.

A validade não é suficiente para a execução. Dois certificados válidos podem declarar o mesmo valor de entrada para o mesmo slot; no máximo um pode surtir efeito. Dividimos, portanto, a noção clássica de validade de transação em duas: válido (sem estado, paralelo, conferível por qualquer um) e aplicável (com estado, sequencial, decidido apenas pela posição no livro-razão). A próxima seção define o segundo predicado.

3. O livro-razão como um fold#

Um bloco contém um cabeçalho, uma lista ordenada de hashes de certificado e os próprios corpos dos certificados. Os corpos são dados de cadeia: um bloco só é válido se seus corpos estiverem disponíveis (§13). O proponente de um bloco não executa nada e não mantém estado de aplicação; ele ordena bytes cuja validade pode conferir a partir dos próprios bytes. Ele não é exatamente sem estado, e a exceção merece ser nomeada em vez de arredondada: ele precisa carregar o conjunto de ids de certificado vistos dentro da janela de TTL, porque incluir um deles duas vezes torna o bloco inválido e ninguém pode ser induzido a isso por acidente. Esse conjunto é limitado pelo TTL e podável, razão pela qual o TTL é um parâmetro de consenso e não uma preferência de retransmissão. A proposição é deliberadamente barata e burra, não deliberadamente cega.

O estado da cadeia é definido como um fold sobre os certificados ordenados:

apply_block(S, B):
    assert bodies_available(B)
    assert ∀c: height ≤ c.ttl ∧ ¬seen(c.id)     // an expired or replayed certificate
                                                 // makes the BLOCK invalid: a signature
                                                 // is billable at most once, and never at
                                                 // a position its signer could not avoid
    C ← sort(B.certs, key = (underwriter.id, underwriter.seq, c.id))
    for c in C:
        if leased(S, c):     bill(c, LEASED); mark_seen(c.id, c.ttl); continue  // §7; Era 1 only
        ok ← true
        for (slot, access, x) in c.reads:
            EXACT:  ok ← ok ∧ (S[slot] = x)
            GUARD:  ok ← ok ∧ pred_x(S[slot])
        if ¬ok:              bill(c, STALE);  mark_seen(c.id, c.ttl); continue
        w ← stage(S, c.writes)   // a target whose address is spent, or a delta that would
                                 // over- or underflow, fails HERE — nothing has landed yet
        if w = ⊥:            bill(c, STALE);  mark_seen(c.id, c.ttl); continue
        commit(S, w); settle_fees(c); mark_seen(c.id, c.ttl)

As escritas são conferidas, e conferidas antes que qualquer uma delas se concretize. Rascunhos anteriores deste esboço aplicavam o conjunto de escritas incondicionalmente, o que se lia como se um crédito pudesse ressuscitar uma célula gasta e como se um delta pudesse dar a volta. Nenhuma das duas coisas é verdade e ambas seriam fatais, então o passo de preparação está no esboço agora, em vez de ser deixado à especificação. A aritmética é conferida em todo lugar em que aparece: um delta que passasse de 2²⁵⁶ ou caísse abaixo de zero omite o certificado em vez de dar a volta, o que também é a razão pela qual os tetos de emissão de §11 se sustentam sob emissões concorrentes ilimitadas. Uma escrita em um endereço cuja autoridade foi queimada falha ruidosamente em vez de desaparecer — é para isso que o registro permanente de gastos serve, e é a origem da única exceção no teorema de atribuição de §5.

**leased é maquinaria da Era 1 e não está presente na gênese.** Ela é mostrada aqui porque esta seção especifica o fold de todo o protocolo, mas a era de lançamento não tem arrendamentos, nem fila forçada, nem cossignatários a defender com eles, de modo que o ramo é inalcançável no binário da gênese — e código de consenso inalcançável é código de consenso não auditável, então ele não é entregue. Uma questão em aberto é sinalizada em vez de encoberta: como está escrito, LEASED cobra um certificado em uma posição que seu signatário não poderia ter previsto, que é exatamente o que a afirmação quatro linhas acima proíbe. Ou esse desfecho não deve cobrar, ou deve invalidar o bloco. A escolha pertence à era que introduz os arrendamentos, e ela é registrada aqui para que essa era não herde a contradição em silêncio.

Propriedades que vale a pena declarar explicitamente:

A omissão é semântica, não falha. Um certificado cujas leituras não valem mais é omitido, sua taxa de omissão é cobrada de seu avalista (§5), e o bloco permanece válido. Inclusão e aplicação são eventos distintos. É isso que permite ao proponente ser cego: ele nunca pode produzir um bloco inválido ao incluir um certificado desatualizado.

Determinismo. Todo nó deriva um estado idêntico de uma sequência idêntica de blocos. A chave de ordenação (underwriter, seq, certificate id) é uma ordem total sobre o conteúdo do bloco, de modo que o fold é insensível a como um proponente intercala certificados de avalistas diferentes — e não deixa ao proponente discricionariedade alguma, nem mesmo entre dois certificados que um avalista assinou no mesmo seq. O pipeline do próprio avalista (seq ascendente) confirma na ordem em que foi assinado, qualquer que seja a ordem em que o proponente o submeteu.

Exatamente um toque de estado por certificado. O fold executa comparações, adições e escritas sobre um conjunto de trabalho chave-valor quente: sem execução de código, sem verificação de assinatura, sem reexecução. Tudo isso já aconteceu, em paralelo, durante a conferência de validade.

E sem aritmética de curva elíptica. Os pagamentos confidenciais (§12) colocam compromissos de Pedersen em valores de slot, e um compromisso é um ponto de curva. O esquema é homomórfico e a soma de dois compromissos é significativa, o que convida o fold a somá-los. O fold recusa. Uma adição de pontos custa centenas de nanossegundos contra o ~1 ns de uma adição u256, e uma operação de curva elíptica no único estágio sequencial gastaria o orçamento que esta arquitetura protege. O fold apenas armazena bytes de compromisso em células novas e os compara por igualdade — ambas operações de memória; toda a aritmética de curva acontece no estágio paralelo ou na carteira do dono (§12). A mesma disciplina governa o hashing, abaixo.

Uma peça de criptografia não é removida, e afirmar o contrário seria conveniente demais: o id de um certificado é um hash de seus campos autorizadores (§2), e o conjunto de vistos é indexado por esse id, então alguém tem de computá-lo. O que importa é onde, e a resposta é que não precisa ser aqui. O id depende dos bytes do certificado e de mais nada — sem estado, sem ordenação, sem posição — de modo que ele é computado ao lado das conferências de assinatura no estágio paralelo e levado ao fold, exatamente como o próprio certificado. Uma implementação que o recompute no laço sequencial encontrará o hashing dominando um estágio que deveria ser sobre memória, o que é um erro que vale nomear porque é fácil de cometer. Queremos ser precisos quanto ao que é e ao que não é removido aqui. O fold ainda realiza acesso aleatório sobre todo o estado, um toque por slot declarado, e um nó que confirma ainda mantém esse estado. O que sai do caminho sequencial é tudo o que cerca o acesso em uma cadeia convencional — interpretação, conferências de assinatura, hashing, autenticação por operação de um armazenamento merkleizado — de modo que o estado pode viver em uma tabela plana e o único estágio sequencial do sistema é um laço apertado sobre a memória. O fold de referência sustenta 883.000 operações de slot por segundo por núcleo em um desktop x86 de dez núcleos (§15), e ele é o único estágio que não paraleliza.

Igualdade de valor, não versões. A aplicabilidade compara os valores de leitura declarados, não contadores de versão. Como a execução é uma função pura do conjunto de leituras, um slot que mudou e voltou ao que era (o caso ABA) continua aplicável: aplicar o certificado agora é semanticamente idêntico a tê-lo executado então. O sistema, portanto, omite estritamente menos vezes que o controle de concorrência baseado em versões. Para slots cujo valor é um compromisso, a comparação é a igualdade byte a byte do compromisso: opaca, exata e igualmente barata, uma vez impostas as condições de canonicidade de §4.

Replay e cobrança única. O id de um certificado é o hash do que ele autoriza e nunca das assinaturas que demonstram a autorização (§2), e tanto os certificados aplicados quanto os omitidos com cobrança são marcados como vistos. A distinção é o que faz da regra uma regra: um signatário que reassine um corpo com um nonce novo produz o mesmo id, de modo que o conjunto de vistos pega a cópia em vez de cobrá-la. Incluir um certificado visto ou expirado invalida o bloco — assim, uma assinatura é cobrável no máximo uma vez, e apenas em uma posição que seu signatário aceitou ao assinar. Sem essa regra, um produtor de blocos poderia reincluir ou atrasar deliberadamente certificados alheios para queimar os fundos de seus avalistas. Os TTLs são limitados por consenso, então o conjunto de vistos permanece podável.

4. Acesso tipado ao estado#

Um fold que suportasse apenas leituras exatas serializaria todo contrato popular: mil certificados tocando um pool de AMM renderiam uma aplicação e 999 omissões. A resposta do Zycord é que a concorrência é declarada pelo autor do contrato, por slot, no próprio formato do certificado. Há três disciplinas de acesso:

Exata. Estilo SLOAD: a leitura devolve o valor do slot para a computação e prende o certificado a ele. Lógica arbitrária; conflitos em slots disputados; o domínio dos sequenciadores de aplicação (§6).

Delta com guarda. O certificado afirma um predicado sobre o slot — balance ≥ 10 — sem ler o valor para dentro da computação, e escreve um delta com sinal — balance += −10. O fold confere o predicado contra o estado atual e aplica o delta. Qualquer número de débitos e créditos com guarda ao mesmo slot comuta: eles se aplicam em qualquer ordem, e uma omissão ocorre apenas quando uma guarda genuinamente falha (um saldo negativo real), não quando o saldo meramente mudou. Essa única disciplina cobre transferências, emissões com teto de oferta, permissões e cotas de cofre, ou seja, a esmagadora maioria das escritas em cadeia.

Delta puro. Um delta com sinal, sem guarda. Ele nunca pode conflitar e nunca sofre omissão. Gorjetas, contadores, acumuladores, somatórios de recompensa.

A regra que mantém o modelo sólido: valores sob guarda não devem fluir para dentro da computação. Uma asserção não devolve nada; um delta não lê nada. A reexecução, portanto, continua sendo uma função pura das leituras declaradas, e a validade sem estado (§2) é preservada. A linhagem dessa ideia é antiga e sólida: transações em escrow em bancos de dados, transactional boosting, CRDTs [9][10][11]. Mas as cadeias existentes, na melhor das hipóteses, exploram a comutatividade dentro do escalonador de um nó; o Zycord a torna o contrato de concorrência entre nós, imposto pelo formato do certificado e precificado pela economia de seguro.

Uma segunda regra do mesmo peso, imposta por §12: nenhum slot que contenha um valor oculto admite guarda de terceiros. Uma guarda cujo desfecho é publicamente observável — aplicado ou omitido — contra um saldo que deveria ser secreto é um oráculo de saldo: submeta balance ≥ x, observe o fold, faça bisseção, e log₂(saldo) tentativas leem o número sem jamais abrir o compromisso. A correção é estrutural, não estatística. Valor oculto vive apenas em células de uso único gastáveis pela assinatura de seu dono; a disciplina do delta com guarda, cujo propósito inteiro é que estranhos possam tocar um slot com segurança, é reservada a slots cujos valores são públicos. Pagamentos por puxada — permissões, assinaturas recorrentes, varreduras de cofre — existem, portanto, apenas no trilho transparente (§12).

Impor essa regra exige que o fold seja capaz de distinguir um slot oculto de um público, e em uma tabela plana ele não consegue por inspeção: um compromisso comprimido e um saldo u256 têm ambos 32 bytes. Uma célula de valor oculto, portanto, não é uma célula comum que por acaso contém um compromisso; ela é um tipo distinto de célula, criada apenas pela operação blindada nativa (§12) e residindo em uma região reservada e derivável do espaço de endereços, de modo que a disciplina de um slot é uma função de seu endereço e conferível a partir dos bytes como tudo o mais. Sem isso, um delta com guarda dirigido — por erro ou malícia — a um slot de compromisso faria o fold somar um u256 à codificação de um ponto de curva: as conferências aritméticas passam, o resultado não é um compromisso, e a célula torna-se ingastável. Valor destruído em silêncio, sem nada falhando no fold, é precisamente o que o passo de preparação de §3 existe para impedir, e o tipo de célula é o que lhe permite impedir também esta instância.

Duas primitivas adicionais completam o modelo:

Células de escrita única. Um endereço que nunca apareceu em cadeia está no estado ∅; uma primeira escrita o move para armazenado; uma assinatura de sua chave o move para gasto, permanentemente. Escrever em uma célula nova é livre de conflito por definição, de modo que pagar a um endereço recém-derivado é o caminho rápido sem disputa. Esta é a herança quimérica da rede [8]: células persistentes ao estilo de contas para contratos, células de uso único ao estilo UTXO para pagamentos, em um só livro-razão. Os valores sob uma célula gasta podem ser compactados quando o bloco que a gastou estiver enterrado mais fundo que o horizonte de reorganização — uma profundidade em confirmações, não um dispositivo de finalidade, já que a era de lançamento não tem finalidade pela qual esperar. A entrada de registro que anota o endereço como gasto nunca é compactada: é ela que impede o endereço de ser ressuscitado, e é o problema em aberto honesto do protocolo, compartilhado com todo projeto de conjunto de nulificadores. As saídas furtivas de §12 trafegam por esse trilho sem alteração e fazem o registro crescer exatamente à taxa em que os pagamentos transparentes já o fazem: uma entrada por gasto, oculto ou não.

Zero é ausência. Um slot que nunca foi escrito e um slot escrito com zero são o mesmo slot: escrever zero apaga a célula, e ler uma célula ausente devolve zero. Isso não é uma conveniência de implementação, mas um requisito de consenso, e é estrutural em dobro. É o que permite a uma guarda ou a uma leitura exata nomear 0 sem perguntar se o slot existe — não há uma terceira resposta a desambiguar. E é o que mantém a raiz de estado uma função do estado, e não do histórico que o produziu: se uma célula esvaziada persistisse como um zero explícito, dois nós que chegassem a saldos idênticos por rotas diferentes se comprometeriam com raízes diferentes, o que é uma divisão de cadeia chegando pela contabilidade.

Isso restringe §12, com uma aresta afiada. Um compromisso de Pedersen vG + rH em geral não é a cadeia de zeros, de modo que um saldo oculto não se torna ausente por aritmética e ninguém além do dono consegue dizer que ele está vazio; slots ocultos persistentes seriam incompactáveis para sempre, o que é mais uma razão pela qual o trilho blindado é feito apenas de células de uso único, que morrem ao serem gastas — uma transição que zero-é-ausência nunca precisou prover. A aresta é que v = 0, r = 0 é o elemento neutro do grupo, e em uma codificação Ristretto o elemento neutro é trinta e dois bytes zero — exatamente a cadeia que significa ausente. Um compromisso jamais pode colidir com a exclusão, então o elemento neutro não é um compromisso válido: a operação blindada o rejeita na entrada, ao lado das conferências de codificação canônica de que um ponto de curva já precisa (elementos de corpo não canônicos, componentes de torção), e o H de referência é um ponto NUMS com derivação publicada. "A igualdade byte a byte é exata" (§3) é uma afirmação sobre pontos apenas uma vez que essas condições valham.

O beacon de época. Programas não devem ler valores ambientes (marca de tempo, altura) diretamente; isso faria a execução ser função de algo além das leituras declaradas. Em vez disso, o protocolo escreve um beacon de época em um slot reservado uma vez por época, e os programas o leem como qualquer outro slot, idealmente com uma guarda de intervalo (epoch ∈ [e, e+2]), o que provê consciência de tempo sem desatualização a cada bloco.

5. Certificados segurados: todo conflito tem um dono#

A omissão não pode ser gratuita, ou o mempool afunda: um atacante poderia publicar milhares de certificados válidos contra a mesma entrada, encher blocos e pagar por um. Mas os certificados omitidos nunca tocaram o saldo do remetente, então não há o que cobrar dele; o slot da taxa é exatamente a entrada desatualizada. A resposta do Zycord: nenhum certificado existe sem um avalista, uma parte cujos fundos caucionados respondem por ele.

Há três formas de ser avalizado, um mecanismo em três feições:

1. Autossegurado. O remetente anexa um pequeno depósito de uma célula desonerada. Nada é arrendado com antecedência: o fold reserva o depósito na posição do certificado dentro do bloco (o esboço em §3 omite esse encanamento), e um certificado que chega à aplicação com seu depósito já consumido é descartado — não cobrado, não marcado como visto, livre para ser ressubmetido contra um novo depósito — de modo que usuários honestos nada perdem em corridas sobre sua própria célula de depósito. Uma omissão com o depósito intacto queima parte dele. Publicar, em contraste, não custa nada, então o mempool é limitado pela política de retransmissão em vez do consenso: os nós limitam o quanto guardarão por avalista, a mesma divisão de trabalho de todo mempool desde o do Bitcoin. Este é o piso sem permissão: qualquer um sempre pode transacionar sem contraparte. É também o único modo na era de lançamento (§14), o que mantém a gênese mínima. A célula de depósito é pública e é do remetente, o que faz do autosseguro um identificador persistente grampeado a cada certificado que ele assina. Para pagamentos transparentes isso não revela nada que o pagamento já não revele; para um pagamento blindado (§12) isso desfaz a saída furtiva pela qual ele paga, e §12 recorre à cossinatura exatamente por essa razão.
2. Cossinado. Um avalista caucionado confere o certificado contra o estado atual, cossina (certificate, ttl, seq) e assume a responsabilidade pela omissão. Em troca, ele pode cobrar do remetente fora da cadeia, e sua cossinatura é um produto: uma pré-confirmação amparada pelo próprio capital do avalista. Nada nesse papel exige ver o que um certificado movimenta: a desatualização é uma propriedade das células — vivas ou gastas — e não dos valores, de modo que um avalista precifica um certificado blindado como precifica um transparente, sem que lhe confiem o valor.

Duas coisas que a promessa não pode ser deixada borrar, porque o artigo já as borrou antes. A resposta do protocolo a uma omissão é queimar a taxa de omissão do depósito do avalista — uma penalidade, paga a ninguém, que é o que impede alguém de lucrar causando omissões. Compensar o remetente é uma transação diferente: é a promessa comercial do avalista, e este projeto ainda não a especifica como mecanismo de consenso. Torná-la um não é questão de redação — ela exige um valor de política declarado na cossinatura, um beneficiário nomeado que não seja o remetente (ou o produto é um convite à fraude de seguro) e a exposição agregada acompanhada em cadeia, para que uma caução não possa ser vendida duas vezes. Enquanto essas coisas não existirem, "minha caução paga" é uma alegação que um avalista faz e um mercado precifica, não uma regra que o fold impõe, e o artigo diz isso em vez de deixar a ambiguidade vender o produto.

1. Forçado. O caminho da resistência à censura (§7), avalizado por um depósito do usuário e, de forma singular, com garantia de aplicação. A economia é assimétrica entre dois tipos de mau comportamento, e a assimetria é o ponto:

Faltas objetivas sofrem slashing. Se um avalista cossina dois certificados cujas leituras exatas conflitam (mesmo slot, mesmo valor declarado, TTLs sobrepostos), as duas assinaturas são uma prova autocontida e em cadeia de equivocação; qualquer um pode submetê-las, e a caução sofre slashing. Do mesmo modo, um avalista que cossine um certificado que falhe na validade sem estado (uma assinatura ruim, uma execução errada) sofre slashing por pura reexecução: o certificado é a prova de fraude (§9).

Faltas subjetivas nunca sofrem slashing. Dois avalistas diferentes disputando o mesmo slot não cometeram falta comprovável; o que vier depois na ordem do fold arca com uma pequena taxa de omissão, nada mais. Avalistas lentos, fora do ar ou pouco confiáveis perdem elegibilidade e reputação, não fundos. Redes morrem quando a latência vira confisco; o Zycord só confisca o que pode ser provado a partir dos bytes.

E a conta recai sobre uma parte que o certificado nomeia. O título desta seção é um teorema, não um slogan, e vale enunciá-lo com suas bordas. Uma omissão cobrada é sempre exatamente uma de três coisas: a leitura ou escrita que falha está sob um endereço cuja chave assinou o certificado; ou é uma emissão disputando com outra emissão do emissor declarado do mesmo ativo, que também assinou; ou é um crédito a um endereço de uso único cujo próprio detentor o aposentou (RETIRE, §11) depois que o certificado foi assinado. Nenhuma parte que o certificado não nomeie pode fazer com que ele seja cobrado. Apenas o terceiro caso separa a conta da causa, e ele é limitado por construção: só células de uso único podem ser aposentadas, de modo que um beneficiário que publique um endereço persistente não apresenta superfície alguma; um certificado pode aposentar no máximo um número fixo de endereços (§13), o que limita quantos pagamentos em trânsito uma rajada de aposentadorias pode atingir; e a taxa de omissão é queimada em vez de paga, de modo que ninguém lucra ao provocá-la.

O dimensionamento da caução segue uma desigualdade: a caução de um avalista precisa exceder a responsabilidade máxima por omissão que ele pode acumular dentro de uma janela de TTL, e a liberação da caução precisa demorar mais que a janela de prova de fraude, para que ninguém possa se comportar mal, sacar e sumir.

6. Sequenciadores de aplicação#

Os deltas com guarda dissolvem a disputa nos pagamentos. O que resta é a lógica de leitura exata sobre estado disputado — um livro de ordens, um pool de AMM — onde dois avalistas honestos em corrida ainda produzirão omissões. A resposta do protocolo é deixar o contrato escolher seu serializador: um contrato pode registrar, em cadeia, a chave de um sequenciador caucionado, após o que apenas certificados cossinados por esse sequenciador podem tomar o caminho de leitura exata do contrato.

O sequenciador é um servidor comum operado pela equipe da aplicação — websockets, filas, autoescalonamento, qualquer maquinaria da web 2 — e nele se confia apenas para vivacidade, jamais para segurança. Ele não pode forjar estado: se mentir sobre as entradas durante a construção, o certificado simplesmente é omitido contra o fold canônico, e a mentira custa a caução dele. O que ele provê:

Serialização. Ele arrenda slots a certificados em trânsito com TTLs curtos e encadeia cada certificado sobre as saídas declaradas do anterior (ele numera suas cossinaturas com seq; a ordem total do fold garante que seu pipeline confirme em ordem, independentemente do embaralhamento do proponente). A disputa por slots quentes torna-se um problema de escalonamento fora da cadeia, invisível para a cadeia.

Certificados em lote. N transações pelo mesmo caminho de código se fundem em um certificado com leituras/escritas agregadas, escritas intermediárias internas cortadas, e N subexecuções que verificam como uma única carga SIMT. É aqui que a tese da GPU se torna concreta: a entidade que serializa é também a entidade que empacota o trabalho no formato que o hardware paralelo quer, e é paga por isso através do mercado de gas paralelo (§8).

Componibilidade atômica. Uma transação que abarca duas aplicações é construída em conjunto fora da cadeia por ambos os sequenciadores (um commit em duas fases sobre arrendamentos de slot) e chega à cadeia como um certificado portando as duas cossinaturas, atômico por construção. A coordenação entre aplicações acontece onde coordenar é barato; a cadeia vê apenas o resultado.

A divulgação honesta: um sequenciador vê primeiro o fluxo de ordens de sua aplicação e é, portanto, o palco natural do MEV dessa aplicação. O Zycord torna o compromisso explícito: a aplicação captura o próprio MEV em vez de vazá-lo para os proponentes de bloco, e §7 limita o poder que isso implica. O mesmo caminho forçado que garante a saída também disciplina a extração: um usuário que não goste do tratamento de um sequenciador pode contorná-lo por completo, pagando apenas em latência.

7. Inclusão forçada com aplicação garantida#

Um contrato cuja única porta é seu sequenciador é uma prisão se o sequenciador censurar. Todo usuário, portanto, tem um caminho lento que não precisa da permissão de ninguém:

Um usuário (ou qualquer retransmissor) reconstrói o estado a partir do fold público, constrói um certificado, anexa um depósito e o submete à fila forçada. Os proponentes precisam incluir os certificados enfileirados dentro de F blocos (§13). Na sua posição de inclusão, o fold confere suas leituras contra o estado atual; se elas valerem, o fold concede um arrendamento determinístico sobre seus slots e agenda a aplicação D blocos adiante. Durante o arrendamento, certificados cossinados que toquem esses slots ordenam-se depois dele. O certificado forçado, portanto, não pode ser omitido: a admissão implica a aplicação.

O período de carência D é para o pipeline em trânsito do sequenciador honesto — a parte dele que não toca os slots arrendados. Tudo o que os toca ordena-se depois do certificado forçado, tanto cossinado quanto autossegurado, e é isso que torna "não pode ser omitido" verdadeiro em vez de aspiracional: um certificado cujas leituras estão protegidas durante todo o período de carência não pode ficar desatualizado nesse intervalo. Como as escritas são declaradas, o estado pós-aplicação é previsível, de modo que um sequenciador encadeia sobre um certificado forçado ainda não aplicado com certeza.

Um arrendamento só pode cobrir slots sobre os quais o certificado tem autoridade. Esta é uma restrição que o mecanismo não dá de graça e sem a qual o resto do projeto não sobreviveria. Declarar uma leitura não exige assinatura — só as escritas derivam autorização — de modo que, sem essa regra, qualquer um poderia enfileirar um certificado forçado declarando leituras sobre os slots alheios e congelá-los por D blocos ao preço de um depósito. A cota por contrato também não limita isso, já que os pagamentos nativos não pertencem a contrato algum. Um arrendamento é, portanto, admissível apenas sobre slots que o certificado tem direito de escrever, que é o mesmo teste de autoridade que o fold já aplica, usado um passo antes.

Outros limites contra assédio: uma cota por contrato e por época; um depósito que cubra o custo imposto; slots arrendados rejeitam novas entradas forçadas até serem liberados.

Duas consequências elevam isso de recurso a mecanismo de sobrevivência. Primeiro, a censura se inverte: ela custa ao censor (taxas perdidas, usuários que o contornam) e não custa nada à rede. Segundo, um contrato cujo sequenciador desaparece — ou uma cadeia cuja classe inteira de avalistas é atacada — degrada para o modo apenas forçado: lento, caro e vivo. Nenhum estado jamais fica órfão, e nenhum operador é estrutural para a segurança. Para uma rede projetada para sobreviver ao seu fundador, esta é a propriedade que importa.

8. Dois mercados: gas sequencial e gas paralelo#

Uma cadeia consome três recursos de classes de escalabilidade diferentes — dados, verificação, mutação — e precificá-los em um só mercado significa que a verificação de uma prova de conhecimento zero concorre em leilão com uma escrita de armazenamento. O Zycord divide a taxa em dois mercados independentes:

O gas sequencial precifica as operações do fold: conferências de leitura, escritas, arrendamentos. Ele é o recurso escasso, o único laço que todo nó executa em ordem, e é precificado de acordo.

O gas paralelo precifica a verificação: conferências de assinatura, unidades de reexecução, bytes e precompilados pesados (verificação de provas, agregação de assinaturas, esquemas pós-quânticos). Ele é abundante, sua oferta cresce a cada núcleo e GPU acrescentados à rede, e seu teto por bloco é fixado alto e barato.

Ambos os mercados têm o formato do EIP-1559 [15], cada um em sua própria unidade: a taxa-base é queimada e a taxa de prioridade paga o produtor do bloco — nos certificados que se aplicam, e apenas nesses. A taxa de um certificado omitido é queimada por inteiro e não paga ninguém, e isso não é um detalhe da tabela de taxas, mas a regra estrutural de todo o modelo econômico. Se uma omissão desse gorjeta, a parte que escolhe o conteúdo de um bloco seria paga por orquestrar o fracasso alheio, e o modo mais barato de ganhar seria cultivar omissões em vez de incluir trabalho. A queima inverte isso: uma omissão consome espaço do teto e não rende nada, de modo que um produtor que maximiza receita está maximizando aplicação, e não é meramente indiferente a causar omissões, mas ativamente contrário a isso. Queimar a taxa-base sequencial torna deflacionário o congestionamento no único laço escasso (§14.2). Queimar a taxa-base paralela mantém o proponente indiferente a quais certificados pesados enchem a faixa barata, de modo que a prioridade na faixa de verificação não pode ser vendida por fora. A divisão segue a direção dos projetos de taxa multidimensional [18], levada até mercados totalmente separados. O que nenhum dos mercados decide é quanto do recurso escasso deve existir; isso é um teto, e §8.1 dá a regra que o move.

A consequência é o objetivo de projeto enunciado como invariante: criptografia pesada não impacta a rede, por construção econômica. Um certificado que verifica uma prova grande mas escreve dois slots paga quase tudo no mercado barato. O Zycord se posiciona assim como a camada de liquidação onde protocolos criptográficos pesados demais para cadeias de mercado único são econômicos. O mesmo mercado paga os sequenciadores por moldar o trabalho: um sequenciador agrega N transações em um certificado em lote, paga um lance paralelo por ele e cobra de seus usuários por N — a margem é a taxa por deixar o trabalho no formato SIMT (§6).

8.1 O teto sequencial elástico#

Um mercado de taxas precifica a escassez; ele não decide quanta escassez deve haver. As duas respostas anteriores a essa pergunta fracassaram, em direções opostas. Um teto fixo transforma a adoção em um leilão que os usuários perdem: quando os blocos do Bitcoin encheram, as taxas passaram de US$ 50 e pagamentos comuns foram simplesmente expulsos da cadeia pelo preço, em benefício exclusivo de quem vendia o espaço. Um teto aberto sem demanda fracassa do outro lado: seus forks de blocos grandes compraram capacidade que ninguém usou e a pagaram em segurança, porque as taxas vêm do volume, não do espaço. O teto do Zycord, portanto, não é fixo nem votado — uma rede cujo autor não estará lá para bifurcá-la não pode tratar o crescimento rotineiro como um evento de governança, e um voto é uma alça: mineradores lucram restringindo a oferta, grandes operadores lucram ampliando-a além do que nós pequenos conseguem acompanhar. O teto é uma função de consenso da demanda medida, presente na gênese desde o bloco 0, movido por ninguém.

A regra tem três partes, uma por escala de tempo. Dentro de um bloco, cada mercado tem um alvo T e um limite elástico rígido de 2T; a taxa-base caminha em direção ao equilíbrio por uma fração limitada a cada bloco, no formato do EIP-1559 de §8 — limitada porque se sabe que o ajuste ilimitado oscila em vez de convergir. Ao longo das épocas, o alvo sequencial acompanha a demanda: T ← clamp(2·median_applied(e), T − T/Δ, T + T/Γ), com piso em seu valor de gênese — onde median_applied conta o gas sequencial apenas nos certificados aplicados. Certificados omitidos queimam suas taxas e nada registram, de modo que a única forma de elevar o teto é vencer pela aplicação: uso sustentado, sem conflito, que queima taxa-base. Forçar o crescimento custa a um atacante exatamente o que a adoção orgânica custa a todos os demais, ou seja, o mecanismo não consegue distingui-los e não precisa. O crescimento é ainda condicionado a um sinal de saúde da época — a taxa observada de cabeçalhos concorrentes permanece abaixo de um limiar (Era 0), os checkpoints finalizam conforme o previsto (a partir da Era 1) — de modo que a capacidade nunca ultrapassa o que a propagação comprovadamente sustenta. Um bloco desatualizado é precisamente o evento que a cadeia não registra, então o sinal é importado do único modo honesto: cabeçalhos podem citar cabeçalhos concorrentes recentes, sem remuneração; citar exige proof of work real, ao passo que suprimir o sinal exige que quase todo proponente omita citações que qualquer um honesto sozinho restaura. A assimetria inclina o portão para a cautela, que é a direção para a qual um portão deve pender. Por bloco, uma válvula de rajada: um proponente pode exceder 2T até 4T, abrindo mão quadraticamente do que o bloco lhe credita — sua fatia do subsídio mais as taxas do bloco, contra o cronograma de §14.2, como uma perda permanente redirecionada a ninguém — com a penalidade calculada sobre o gas sequencial total, aplicado e omitido igualmente, para que o excesso não possa ser recheado com conflito fabricado a preço de desconto. A base é a receita do produtor e não apenas seu subsídio porque os dois não decaem juntos: o subsídio cai para cerca de 1,6 % de seu valor de gênese na curva de §14.2, enquanto a receita de taxas pela qual se compra uma rajada não cai nada, de modo que um dissuasor denominado apenas em subsídio deixa de dissuadir exatamente onde a oportunidade é maior. Uma propriedade permanente precisa ser precificada em algo que acompanhe o benefício, que é o argumento que o EIP-1559 faz para acoplar uma cobrança ao valor que a manipulação rende. Na gênese isso quase nada muda, já que as taxas estão perto de zero. A fatia da tesouraria de §14.1 é retirada do subsídio não reduzido e nunca é perdida, porque a rajada é escolha do produtor e a tesouraria não é parte nela. Picos genuínos compram passagem imediatamente e informam o controlador de época; spam compra uma penalidade. O precedente é o mecanismo de mediana com penalidade do Monero [19], com seu travamento documentado — o crescimento congelando quando a unidade típica de trabalho se aproxima da mediana — evitado por construção, já que os certificados em lote (§6) mantêm a unidade típica pequena diante do alvo, e os limites de taxa seguem a linhagem dos limites adaptativos [20]. O teto paralelo não precisa de nenhum desses cuidados: ele é fixado como um múltiplo alto constante do alvo sequencial e herda o crescimento deste, que é o invariante de §8 reenunciado como capacidade.

Leia o cabo de guerra a partir do mecanismo. A taxa do usuário gravita para o piso, porque o congestionamento sustentado é, por definição, o sinal que eleva o teto e o traz de volta para baixo — o equilíbrio do Bitcoin, de leilão permanente, é inalcançável. O produtor é pago por subsídio enquanto a rede é jovem e por volume na maturidade, nunca por escassez; a queima faz cada episódio de congestionamento reverter em favor da moeda que o produtor detém, e §8 já fez da aplicação, e não da exclusão, a estratégia que maximiza receita. Uma honestidade, em dobro: a elasticidade garante apenas que a capacidade nunca é a razão pela qual a adoção emperra — ela não fabrica demanda alguma, como os forks de blocos grandes provaram — e um teto que cresce deixa o estado crescer, razão pela qual as escritas em slots novos custam mais que os deltas em gas sequencial: a tabela plana em que o fold vive não se expande mais rápido que o teto que a alimenta. Uma regra de calibração decorre disso e é enunciada porque sua violação é silenciosa: a razão de gênese entre alvo sequencial e teto de bytes precisa ficar abaixo da densidade do tráfego para o qual a rede foi construída, de modo que um bloco cheio de pagamentos comuns eleve a taxa-base em vez de reduzi-la. Um mercado que responde ao contrário à sua própria carga de projeto não precifica nada, e a razão é fixada a partir de tráfego medido antes do congelamento.

Capacidade ao longo das eras. Os tetos de contagem de certificados e de bytes escalam junto com o alvo sequencial em vez de permanecerem fixos ao lado dele: na gênese os três se apertam dentro de um fator de dois entre si, de modo que um teto fixo se torna o limite real após uma única duplicação e deixa o elástico decorativo. Atrás deles estão capacidades estáticas: a largura da lista de certificados, que fixa a profundidade merkle de um bloco, e a capacidade em bytes que um bloco pode alcançar, emparelhada com as constantes de transporte sob ela — um bloco viaja em pedaços, então nenhuma mensagem de rede isolada limita um bloco. A largura da lista é dimensionada na gênese para toda a curva (2²⁵ certificados; refixá-la depois colocaria duas larguras merkle em uma cadeia, e o preenchimento virtual torna a folga gratuita). A capacidade em bytes é dimensionada para a rede de lançamento e refixada nas fronteiras entre eras — que já são hard forks (§14) — contra a propagação que o portão de saúde mediu; nunca dentro de uma era, nunca por voto. A curva que essa escada serve decorre de Γ: o alvo se compõe em no máximo 2× por ano de blocos cheios e saudáveis, de modo que o teto de gênese de ~90 certificados aplicados por segundo (um bloco de §15 a cada intervalo de 30 segundos) alcança ~11.000 por segundo em sete anos de demanda sustentada, ~90.000 em dez, e em menos de catorze o ~1,1 milhão por segundo que a largura de lista de 2²⁵ fixa — a única parede que era alguma move, e portanto o fim da escada em vez de um degrau nela. A unidade são certificados, não pagamentos: um certificado carrega um pagamento, ou os N que um sequenciador agrupou nele (§6), de modo que cada número é um piso sobre transações e não uma afirmação a respeito delas. As condições são exatamente três, cada uma já um mecanismo acima: a demanda precisa sustentar blocos cheios, porque o gas aplicado é a única entrada que eleva T; a propagação precisa manter o portão de saúde aberto, porque o crescimento é retido na época em que ele se fecha; e as refixações precisam cair nas eras, porque entre elas a capacidade em bytes é a parede. A computação não é uma condição — o fold vence a ponta distante da curva em um único núcleo medido (§15), e a verificação escala com hardware que a rede não possui (§2). A largura de banda é: os corpos são dados de cadeia (§13) e a amostragem (§9) divide a verificação, nunca os dados, de modo que todo nó carrega todos os bytes, e um produtor no topo da curva é de classe datacenter só pela largura de banda — um estado final aceito para produtores, e para mais ninguém, já que o custo de verificação por nó anda no sentido oposto (§9). Antes de a largura de banda limitar, o estado limita: o registro de gastos (§4) cresce uma entrada por gasto de uso único, na ordem de 10² terabytes por ano a 10⁵ certificados por segundo, o que converte o problema em aberto declarado em §4 de um item pendente em trabalho que a curva agenda.

Constantes (gênese, ilustrativas, como em §13): divisor de crescimento Γ = 512 por época (o teto pode no máximo dobrar por ano de blocos cheios); divisor de decaimento Δ = 1024 (a capacidade ociosa cai pela metade em ~2 anos, nunca abaixo da gênese); limite de rajada 4T, perda da fatia de subsídio do produtor e das taxas do bloco no limite (a fatia da tesouraria de §14.1 é retirada do subsídio não reduzido e nunca é perdida, porque a rajada é escolha do produtor e a tesouraria não é parte nela); portão de saúde: cabeçalhos concorrentes citados ≤ 2% dos blocos por época; capacidade da lista de certificados 2²⁵ (estrutural, conforme acima); teto de bytes de 2,5 MB na gênese, escalando com o alvo até uma capacidade estrutural em bytes de 8 MB (refixada nas eras); teto de assinaturas por bloco de 6.000 na gênese, escalando com o alvo, conferido antes que qualquer assinatura seja verificada — um limite sobre a verificação, mantido separado do preço do gas paralelo porque um parâmetro não pode ao mesmo tempo limitar o trabalho e precificar o mercado.

9. Provas de fraude instantâneas e o caminho da amostragem#

Como a validade é uma função pura dos bytes de um certificado, um certificado inválido é sua própria prova de fraude. Qualquer um que o reexecute pode refutá-lo em uma mensagem, imediatamente, sem estado e sem jogo interativo de bisseção. Na configuração de lançamento o ponto é irrelevante da melhor maneira: todo nó verifica todo certificado antes de aceitar um bloco, então um certificado inválido nunca sobrevive tempo suficiente para precisar de contestação. A janela passa a ter significado uma vez que a verificação seja amostrada, e lá ela é um parâmetro de propagação, não um protocolo de disputa: um punhado de blocos para uma mensagem atravessar a rede, cobrado do avalista que atestou o certificado (§5). Compare as alternativas: rollups otimistas precisam de disputas interativas de uma semana porque disputar exige estado no passo disputado; sistemas baseados em provas evitam disputas, mas pagam por provadores que custam ordens de magnitude mais que a execução. As provas de fraude do Zycord custam o que a verificação custa: ~1× de reexecução.

Isso abre o caminho de escala que as cadeias de reexecução não podem tomar. A rede não precisa, em princípio, que todo nó verifique todo certificado para sempre. Com as cauções dos avalistas em vigor, a verificação pode ser amostrada: um comitê selecionado por VRF por certificado, dimensionado para que a probabilidade de um certificado inválido não verificado seja desprezível, com qualquer nó completo livre para conferir o que quiser e uma mensagem bastando para aplicar o slashing. Na gênese, todos verificam tudo; é barato e paralelo. A amostragem é roteiro, não lançamento. Mas é o roteiro que inverte a curva do setor: o custo por nó cai à medida que a rede cresce, ao passo que no paradigma da reexecução o custo por nó cresce com a vazão até que só restem datacenters.

10. A máquina: cEVM#

O Zycord executa uma máquina virtual: a cEVM, um dialeto da EVM do Ethereum [2] adaptado a certificados. A escolha é deliberada. O orçamento de novidade do projeto é gasto no modelo de estado, de concorrência e econômico; a máquina deve ser a coisa mais familiar do sistema. Solidity, seus compiladores, auditores e ferramental são aproveitados.

Diferenças em relação à EVM padrão:

• SLOAD compila para uma leitura exata (declarada no certificado); SSTORE, para uma escrita SET.
• Os novos opcodes SASSERT(slot, pred) e SDELTA(slot, ±v) expõem os deltas com guarda e puros. Um SASSERT não empilha nada — guardas não retornam valores (§4).
• TIMESTAMP e NUMBER leem o slot do beacon de época; não há outra entrada ambiente.
• A medição de gas é dupla (§8): opcodes de armazenamento medem gas sequencial; computação, calldata e precompilados medem gas paralelo.
• O formato de transação é o certificado. Contratos do Ethereum são portados no nível do código-fonte; compatibilidade bruta de carteira não é alegada, e não fingimos o contrário. Um contrato portado roda em modo totalmente exato: correto no primeiro dia, serializado por um sequenciador se for disputado. O paralelismo é opcional por slot, tipicamente um diff pequeno (o mapa de saldos de um token migra de SLOAD/SSTORE para SASSERT/SDELTA em ~30 linhas). Para que o recurso principal fique visível desde o primeiro bloco da era da VM em vez de esperar pelas portas, a máquina é ativada junto com uma biblioteca padrão nativa — token, pote de gorjetas, escrow, vesting e uma referência híbrida de livro de ordens/AMM — escrita com deltas em primeiro lugar e pré-implantada em endereços conhecidos.

11. Ativos sem uma máquina#

A era de lançamento precisa de uma economia antes de precisar de um computador. O Zycord, portanto, entrega ativos nativos como operações de certificado desde o bloco 0, sem VM envolvida: ISSUE (cria um id de ativo com um teto de oferta em uma célula de escrita única), MINT (com guarda: minted + Δ ≤ cap), TRANSFER (guarda balance ≥ Δ, deltas emparelhados; um crédito dirigido a um delta puro ou a uma célula de uso único nova é a gorjeta, de modo que dar gorjeta não gasta opcode próprio) e RETIRE (queimar um endereço sem gastá-lo: sem leituras, sem valor movido, uma escrita pura que marca a célula como gasta — o gasto propriamente dito é automático dentro de TRANSFER). O RETIRE merece seu lugar em dobro. Ele é a primitiva de compactação e de privacidade, permitindo a um beneficiário apagar um endereço de uso único no momento em que ele cumpriu sua função; e é a operação por trás da única exceção no teorema de atribuição de §5 — o terceiro caso existe porque a aposentadoria existe, razão pela qual o formato de certificado limita os endereços aposentados por certificado (§13) e pela qual o teorema é enunciado com essa borda em vez de contorná-la. O conjunto é fechado: estas quatro são todo o conjunto de instruções da gênese, toda outra operação — inclusive a caução — chega com o conjunto de regras de uma era posterior (§14), e o teorema de atribuição de §5 é provado contra exatamente essa superfície.

Um streamer que recebe dez mil gorjetas em um bloco custa ao fold dez mil adições comutativas: zero conflitos, zero omissões, sem sequenciador, sem máquina. As culturas de gorjeta em cadeias anteriores viviam ao sabor das APIs das plataformas e morreram com elas; aqui a gorjeta é uma primitiva de protocolo. Ela é também, e não por acaso, um teste de estresse contínuo da afirmação central do sistema. Os tetos de oferta da moeda nativa vivem aqui, no trilho transparente, impostos pela aritmética conferida de §3, e §12 os deixa intocados.

12. Pagamentos confidenciais#

As seções anteriores tratam o valor de um pagamento como público. Esta seção acrescenta a opção de ocultá-lo, e de ocultar o destinatário atrás de um endereço de uso único, preservando as propriedades das seções anteriores. O projeto é mais estreito que os sistemas dos quais deriva: cada restrição abaixo fecha um ataque que um projeto mais geral responderia com maquinaria mais pesada.

O que é ocultado e o que não é. Um pagamento blindado oculta seu valor e adia o vínculo com seu destinatário. Seja exato quanto a "adia": uma saída furtiva nova é desvinculável no momento em que é recebida, mas, sem anel, gastá-la depois nomeia a saída sendo gasta, e nomear a saída revela qual pagamento anterior a financiou. A desvinculabilidade vale até o primeiro gasto e termina ali; é um adiamento, não um apagamento. O projeto tampouco oculta a posição do remetente no grafo: os certificados são assinados, avalizados e ordenados em público, de modo que um observador vê que um pagamento aconteceu e quem o avalizou — não o valor, e não, até que um gasto o revele, qual saída entre as de um destinatário foi para onde. A descrição honesta é transações confidenciais com endereços de destinatário de uso único sobre um grafo público, e o grafo desanonimiza retroativamente à medida que as saídas são gastas. A ambiguidade do lado do remetente — assinaturas em anel, provas de pertencimento sobre saídas históricas — está fora do escopo: um anel referencia saídas alheias, o que torna a validade uma função do histórico, e a ausência de estado de §2 é a propriedade que o protocolo não abre mão. O modelo de ameaça do Monero exige um protocolo diferente.

A saída blindada. Um pagamento blindado escreve uma célula de escrita única nova (§4) cujo endereço é um endereço furtivo: o remetente deriva, a partir da chave de visualização publicada do destinatário e de uma chave efêmera própria, um endereço de uso único que só o destinatário consegue reconhecer e por cujo nome só a chave de gasto do destinatário consegue assinar. O valor da célula é um compromisso de Pedersen C = vG + rH; ao lado dele viajam uma prova de intervalo de que v ∈ [0, 2⁶⁴) e o par (v, r) cifrado para a chave de visualização do destinatário, mais uma etiqueta de visualização de um byte que permite a uma carteira em varredura descartar cedo a maioria das saídas alheias. As primitivas são transações confidenciais com endereçamento furtivo: a metade do RingCT que oculta valores, sem o anel, cada uma com implantação estabelecida em produção.

A validade continua sendo uma função dos bytes. A conferência de balanço de um certificado blindado é a equação de compromissos: os compromissos de entrada declarados menos os compromissos de saída declarados igualam fee·G, com a taxa pública (veja o pool abaixo). A equação, as provas de intervalo e as assinaturas são todas conferidas somente a partir dos bytes do certificado, no estágio paralelo, em lote: a verificação de Bulletproofs amortiza logaritmicamente ao longo de um lote, e nada disso toca o estado. Um certificado inflacionário forjado — cujos compromissos não fecham sob uma hipótese quebrada ou um verificador quebrado — ainda é válido ou inválido puramente por seus bytes, e o fold nunca o reconfere; esta é a divisão válido/aplicável de §2 funcionando como projetada, não uma exceção a ela, e a regra do pool abaixo é o que impede que uma quebra de solidez seja ilimitada. É também aqui que o mercado duplo de taxas (§8) deixa de ser um argumento de eficiência e passa a ser um argumento de viabilidade: em uma cadeia de mercado de gas único, as transações confidenciais são caras porque um milissegundo de verificação de prova concorre no mesmo leilão que uma escrita de armazenamento, ao passo que aqui a verificação recai inteiramente em par_gas — barata por projeto — e o mercado sequencial nunca a vê.

O fold armazena bytes. Na aplicação, um pagamento blindado é o certificado mais barato que o fold vê: sua célula de saída é nova, então não pode conflitar (o caminho rápido sem disputa de §4); suas células de entrada estão vivas ou gastas, uma consulta ao registro; e a escrita armazena 32 bytes de compromisso. Nenhuma aritmética de curva entra no estágio sequencial (§3). A alternativa que a regra descarta é um "slot de acumulação" persistente creditado homomorficamente por estranhos, que falha em três frentes: coloca adição de curva elíptica no laço sequencial (§3); cria um identificador público reutilizado, a heurística de propriedade comum que o endereço furtivo pretende evitar; e um saldo persistente oculto convida às guardas de terceiros que §4 proíbe. A acumulação acontece na carteira: um destinatário detém muitas saídas de uso único, todas reconhecíveis por uma única chave de visualização, e as consolida gastando várias de suas próprias células em uma célula nova, um certificado blindado comum, na cadência que quiser, tendo o beacon de época (§4) como relógio. A soma que um slot persistente manteria em cadeia é mantida pelo dono fora da cadeia — e a consolidação não é livre de rastro: declarar várias entradas em um certificado é um evento público de propriedade comum, mais fraco que um identificador reutilizado, mas real, de modo que a política da carteira é minimizá-lo e nunca misturar origens não relacionadas em uma consolidação.

Gastos apenas pelo dono, e o que isso proíbe. Um valor oculto só é gastável pela assinatura de seu dono sobre a própria célula. Não há guardas de terceiros contra saldos ocultos (§4) e, portanto, não há pagamentos por puxada no trilho blindado: sem permissões, sem assinaturas recorrentes, sem cofre varrendo os fundos blindados de um usuário. Esses padrões permanecem no trilho transparente, e a fronteira entre os trilhos tem a largura de um certificado. A restrição elimina o oráculo de saldo: sem que estranho algum possa submeter um palpite contra um saldo e ler a omissão, o oráculo não tem operador.

O pool blindado é um inteiro público que o fold impõe. As taxas são públicas. O coinbase é público. Os pagamentos a slots de contrato são públicos. Toda travessia entre os trilhos transparente e blindado move um v publicamente visível — um certificado de blindagem abre v na entrada, um certificado de desblindagem abre v na saída. O total do pool, portanto, vive em um slot reservado, em texto claro, movido apenas por delta com guarda (§4): blindar o credita, pool += v; desblindar tem a guarda pool ≥ v e o debita, pool += −v; a taxa de um certificado blindado o debita do mesmo modo. O slot é exatamente Σ entradas − Σ saídas, e a disciplina do delta com guarda permite que travessias ilimitadas comutem sem disputa.

Isso faz do pool uma cerca, não um alarme. Ocultar valores troca a aritmética u256 conferida de §3 pela solidez computacional de uma hipótese de logaritmo discreto, e uma quebra — da hipótese, ou muito mais plausivelmente de um verificador — forja compromissos dentro do pool. Mas um compromisso forjado não carrega texto claro, e o valor só sai do pool por desblindagem, que debita o slot público sob sua guarda. O slot só subiu com blindagem real, então uma desblindagem que o levaria abaixo de zero é omitida: valor forjado não pode atravessar a guarda. A inflação não drena o pool; ela não consegue sair dele. O raio de destruição de uma falha criptográfica é limitado, por uma regra do fold e não pela vigilância de um auditor, ao conteúdo real do pool, e o modo de falha não é um dreno silencioso, mas uma corrida visível e em tempo real na qual os últimos detentores honestos a desblindar não conseguem — ruim, limitado e observável, que é a contenção que um sistema sem equipe de resposta a emergências precisa ter por construção. O precedente é concreto: o bug de falsificação do Zcash Sprout foi sobrevivível porque seu pool blindado era uma quantidade limitada e auditável; aqui essa quantidade não é apenas auditável, mas estrutural no fold. Os tetos de oferta nativos de §11 vivem no trilho transparente e continuam impostos por aritmética conferida, intocados.

O pool tem um custo de privacidade, e ele pertence ao registro: as travessias de fronteira expõem valores públicos exatos, e valores distintivos se correlacionam. Um observador que veja v sair do pool pouco depois de v + fee ter entrado aprendeu algo que nenhum compromisso ocultou. Denominações padronizadas na fronteira atenuam isso, e as carteiras as adotam por padrão; o protocolo não as obriga, porque uma regra de consenso não consegue distinguir um valor distintivo de um valor legítimo. A vinculabilidade sob análise de tráfego é declarada, com sua mitigação, em vez de negada.

O avalista é metadado, e privacidade e resistência à censura não coexistem em um mesmo certificado. Um certificado blindado autossegurado nomeia a célula pública de depósito do remetente, o que revincula o que o endereço furtivo desvinculou (§5); o tráfego blindado, portanto, viaja sob aval cossinado, onde o id de um avalista agrega muitos remetentes e a multidão é o disfarce. O avalista precifica a vivacidade das células, não os valores (§5), de modo que ele não descobre o valor — mas descobre todo o resto que o certificado é: o remetente que ele precisa cobrar fora da cadeia e, portanto, identificar, as células sendo gastas, as saídas furtivas sendo criadas e o momento em que isso ocorre. É precisamente o que uma intimação judicial quer, e junto com a desanonimização retroativa acima isso se compõe para a frente através do grafo público. É também um ponto estrutural de KYC, porque o único modo privado tem um operador conhecível. Isso expõe uma limitação que o artigo declara com franqueza em vez de encobrir: os dois modos de aval são o cossinado (privado, mas permissionado — um avalista pode recusá-lo) e o autossegurado ou forçado (sem permissão, mas autoidentificador). O caminho forçado de §7 garante que um usuário censurado sempre possa transacionar; ele não garante que possa transacionar em privado. Um usuário recusado por todos os avalistas mantém o direito de gastar e perde a privacidade no mesmo gesto — e é exatamente esse o usuário para quem a privacidade importava. O trilho blindado herda a resistência à censura de §7 apenas ao custo de sua própria privacidade; as duas propriedades não valem em um único certificado.

Uma era, não a gênese. Dois argumentos independentes fixam o cronograma. Na prática, os certificados blindados usam avalistas cossinados, que existem a partir da Era 1. Pelo princípio de §3, código de consenso inalcançável é código de consenso não auditável e não é entregue: o binário da gênese não contém compromissos, nem verificador de provas de intervalo, nem slot de pool — nada cujo único chamador seja uma era futura. A era blindada não é puramente aditiva, e o artigo diz isso: a tipagem de células ocultas e a proibição de guardas de terceiros de §4 tocam o caminho das guardas do fold, que é superfície crítica da gênese, de modo que a era modifica além de acrescentar, e sua ativação é um hard fork auditado como a mudança crítica de consenso que ele é. Uma era que não prove valer sua complexidade simplesmente nunca é acionada, e a cadeia de gênese nada perdeu por não contê-la.

Custos, declarados com franqueza. Um certificado blindado tem de 3 a 5× o tamanho de um transparente — de um a dois kilobytes, dominados pela prova de intervalo mesmo após a agregação em lote —, o que o bloco dinâmico (§8) absorve economicamente e a disseminação de §13 paga em largura de banda. Os destinatários descobrem pagamentos por varredura: cada nova saída blindada é testada por tentativa contra a chave de visualização da carteira, um custo O(n) no volume da rede que as etiquetas de visualização reduzem por uma rejeição precoce sobre um byte, um fator constante limitado pela derivação do segredo compartilhado que a precede. A varredura é o principal ônus de experiência do trilho blindado; a varredura terceirizada que não entregue a chave de visualização é um problema em aberto que este projeto herda em vez de resolver. A política de retransmissão também precisa mudar neste trilho, e não opcionalmente: publicar um certificado é gratuito (§5, §13), enquanto verificar um Bulletproof não é, de modo que um retransmissor que execute o verificador antes de impor qualquer custo ao publicador é um amplificador de negação de serviço — o trilho blindado exige retransmissão que confere o barato antes do caro (assinatura e vivacidade declarada primeiro, prova por último, cota por avalista), o que converte o "limitado pela política de retransmissão" do mempool de um padrão em um requisito.

Questões em aberto que esta seção deixa para um rascunho posterior, sinalizadas em vez de enterradas. Se o trilho blindado carrega apenas a moeda nativa ou também os ativos de §11: um único gerador H faz vG + rH se comprometer com um escalar, não com um par (ativo, valor), de modo que um trilho blindado multiativo precisa de geradores por ativo (Confidential Assets), o que muda o tamanho da prova e o número de "3 a 5×" acima; até que se decida, o trilho é exclusivo da moeda nativa por regra, não por omissão. Se o RETIRE (§11) atua sobre células blindadas: se atuar, o valor pode sair do pool sem uma desblindagem pública, de modo que o slot do pool passa a ser um limite superior (Σ entradas − Σ saídas ≥ conteúdo) e a direção da detecção de inflação precisa ser reenunciada como uma desigualdade; se não atuar, o trilho blindado perde seu coletor de lixo e as saídas inabríveis (abaixo) se acumulam. Se o (v, r) cifrado vive no corpo do certificado (barato agora, irrecuperável se os corpos forem podados, o que inviabiliza a restauração de carteira só pela semente) ou no valor da célula (custa estado por saída, desaparece quando a célula é gasta e é coerente com o "a acumulação acontece na carteira"). E se um avalista pode caucionar um terceiro cobrando dentro do certificado em valor público, o que removeria a exigência de identidade acima e é a rota mais promissora para superar a limitação privacidade/censura — estas são questões de projeto, não de redação, e são nomeadas aqui para que o próximo rascunho não as herde em silêncio.

13. Rede#

Os corpos são dados de cadeia. Os corpos de certificado de um bloco precisam ser recuperáveis para que o bloco seja válido; o estado, portanto, é sempre reconstruível apenas a partir da cadeia, e nenhum operador — sequenciador incluído — é jamais um custodiante de dados. Os certificados são maiores que as transações clássicas (eles carregam leituras e escritas), e as mitigações são estruturais: os certificados em lote cortam as escritas internas (§6), e as células de uso único gastas são compactadas quando estão enterradas além do horizonte de reorganização (§4).

Uma terceira mitigação é prospectiva e é nomeada como tal em vez de pressuposta: uma leitura poderia referenciar a escrita de um certificado anterior por (cert_id, index) em vez de repetir o valor — o truque do UTXO. Ela não faz parte do protocolo descrito aqui, e não passará a fazer até que uma pergunta tenha resposta, porque a pergunta é de consenso e não de codificação: a que uma referência resolve quando o certificado que ela nomeia foi omitido, ou nunca chegou a ser incluído. Uma referência que silenciosamente resolva para o valor atual não é mais uma leitura declarada, e a validade sem estado morre com ela; uma que falhe derruba certificados cuja própria autorização nunca esteve em dúvida. Compressão que custa a propriedade sobre a qual todo o projeto se apoia não é compressão que valha a pena, então o campo está ausente até que a semântica esteja resolvida.

A retransmissão é orientada a hash. Os certificados circulam por gossip de forma independente e têm sua validade conferida (sem estado, em paralelo) na chegada; os blocos são retransmitidos como cabeçalhos mais listas de hash contra o mempool, ao estilo de blocos compactos [13], de modo que a latência de propagação não escala com o conteúdo do bloco. Um nó de retransmissão não precisa de estado algum para filtrar spam por completo — a validade sem estado mais a assinatura do avalista são conferíveis a partir dos bytes, o que torna quase gratuito operar infraestrutura de retransmissão no trilho transparente. O trilho blindado (§12) é a exceção precificada: sua conferência sem estado inclui uma verificação de prova de intervalo que custa três ordens de magnitude mais que uma assinatura, de modo que ali o padrão de publicação gratuita vira um amplificador, e a retransmissão fica sujeita à disciplina de conferir o barato antes do caro e às cotas por avalista que §12 torna requisito em vez de preferência. A retransmissão de um trilho é quase gratuita; a do outro só é barata porque sua política é obrigatória.

Parâmetros (gênese, ilustrativos). Blocos de 30 segundos; TTL padrão de certificado de 240 blocos (~2 h); endereços aposentados por certificado ≤ 64; época de 2.880 blocos (~1 dia); atraso de aplicação forçada D = 4 blocos; limite de inclusão forçada F = 16 blocos; janela de participação para acionar era K = 14 épocas (~2 semanas); fatia da tesouraria de 300 pontos-base (3%) do subsídio de bloco desde o bloco 0, célula selada até a Era 2, depois 3 de 5 sobre um conjunto de chaves fixado por hard fork, atraso de rotação de chaves R = 20.160 blocos (~7 dias) (§14.1); constantes de emissão em §14.2.

14. Lançamento: três eras, premine zero#

O Zycord é lançado sem premine, sem alocação para fundadores, sem rodada de investidores e sem chaves administrativas. A gênese é reproduzível a partir de fontes publicadas. Uma testnet roda primeiro; só depois que ela estiver estável é que uma data de mainnet é anunciada, abertamente e com antecedência, para que o bloco 0 seja alcançável por qualquer um que o queira. O que se impõe ao autor é a ausência de privilégio, e isso é conferível linha a linha na gênese. As atualizações acontecem por consenso social e hard fork.

Este artigo é o argumento. As regras são a especificação de arquitetura, os vetores de referência são o protocolo, e onde quaisquer dois deles divergirem o mais preciso prevalece e a divergência é um bug. Publicado ao lado deles está o registro deste projeto sendo atacado — leituras adversariais sucessivas, os achados que produziram, os que mudaram as regras e os que foram refutados e por quê. Esse registro é liberado na íntegra e sem edição, incluindo as revisões que encontraram defeitos reais e os instrumentos que reportaram sucesso enquanto nada mediam. Para um projeto cujo autor não o avalizará pessoalmente, um projeto sem histórico visível de ter sido atacado se lê como um projeto que ninguém atacou, e não há como recuperar o que escondê-lo custaria.

"Sem edição" é uma promessa sobre os achados, e vale dizer exatamente o que ela cobre, porque o registro é republicado como arquivos e não como um arquivo vivo. Todo achado, toda medição, todo argumento e toda alternativa rejeitada sobrevivem como foram escritos, inclusive os que estavam errados e os instrumentos que reportaram sucesso enquanto nada mediam; nada é diluído, suavizado, fundido ou descartado. Duas classes de alteração são feitas, e apenas duas. A primeira é a supressão de identidade — nomes, apelidos, endereços, nomes de máquina e caminhos locais, que nada dizem sobre o projeto. A segunda é a autossuficiência: um ponteiro para um rastreador ou um histórico de commits que a árvore publicada não carrega é substituído pelo raciocínio que ele representava, enunciado no próprio texto. Um leitor que tenha apenas esses arquivos pode, portanto, acompanhar cada afirmação, que é para isso que a promessa servia; um ponteiro que não resolve para nada manteria a letra do "sem edição" e perderia todo o seu propósito.

O proof of stake não consegue fazer um lançamento justo — a participação inicial precisa vir de algum lugar, e toda rota clássica (venda, premine, alocação) ou concentra a rede ou identifica seu autor. O proof of work é, portanto, usado como mecanismo de distribuição com data de validade, não como consenso permanente:

Notas de projeto sobre a transição. A Era 0 é deliberadamente minúscula. Sem chaves administrativas não há botão de pausa, de modo que cada linha da gênese é uma linha que pode matar a rede sem remédio; o fold (§3) mais as operações nativas (§11) são toda a superfície crítica de segurança (pequena o bastante para que este artigo contenha sua especificação completa), e elas são entregues auditadas e simuladas de forma adversarial. A mineração em CPU (RandomX) combina com o público: minere no notebook que você já tem. Ela também convida botnets; toda moeda minerável em CPU as combateu, e não esperamos ser a exceção. Aceitamos esse compromisso de olhos abertos: uma distribuição enviesada por botnets ainda é mais ampla que uma decidida em uma venda, e manter hardware honesto de prateleira competitivo é todo o propósito de projeto do RandomX [14]. A cossinatura está em operação desde o momento em que os avalistas podem se registrar; a finalidade por checkpoints não está, até que a participação se sustente, e nomeamos a lacuna em vez de escondê-la: a caução precifica omissões, nunca reorganizações, de modo que nenhuma regra de protocolo impede um avalista de vender pré-confirmações nessa lacuna — o que nenhuma regra pode fazer é tornar a venda honesta. "Aplica-se em segundos ou minha caução paga" só é avalizável quando as reorganizações profundas estão descartadas, de modo que o produto de pré-confirmação segurada segue a finalidade como honestidade de mercado, não como lei de protocolo. Os atestadores são pagos com emissão desde o momento em que a camada é ativada — as duas transições híbridas anteriores fizeram isso (o Decred paga aos votantes de PoS uma fatia de cada recompensa de bloco [17]; os validadores da beacon do Ethereum ganharam emissão por dois anos antes de propor blocos na mainnet) — e a divisão 77/20/3, pesada para o produtor, fica confinada à fase de distribuição, já que o mesmo precedente mostra que uma divisão pesada para o minerador é o estado permanente errado: a rampa a aposenta. A Era 1 divide seu gatilho, e a divisão é estrutural: o conjunto de instruções ativa-se por altura — BOND primeiro, o registro de avalistas e sequenciadores e a cEVM depois, duas alturas que os parâmetros de gênese mantêm distintas e ordenadas — enquanto a camada de finalidade ativa-se apenas quando a participação caucionada ≥ 1% da oferta se sustentar por K épocas, porque a participação não pode ser medida antes que exista a operação que a cria. A Era 2 mantém um gatilho duplo (altura e participação sustentada), de modo que a rede nem transiciona com participação trivial nem deixa mineradores estabelecidos a travarem para sempre; alturas são limiares, não datas, e nenhum calendário é prometido. Uma ressalva que declaramos em vez de enterrar: no piso de ativação de 1%, travar a finalidade exige um terço disso (0,33% da oferta), de modo que a finalidade sobre a qual repousam as primeiras pré-confirmações seguradas é ela mesma jovem. A exigência de sustentação por K épocas eleva a barra com o tempo, o vazamento por inatividade torna caro manter um travamento, e espera-se que os avalistas precifiquem a finalidade jovem em apólices jovens; segurança mais profunda chega com participação mais profunda, não por declaração. A Era 1 é a cadeia sombra: o conjunto de validadores finaliza em produção durante toda a era — cauções reais, slashing real — antes de propor um único bloco, a propriedade que tornou segura a única transição PoW→PoS bem-sucedida em escala. Ela é também um estado de repouso, não um corredor: se a participação nunca sustentar o limiar da Era 2, a rede permanece um híbrido funcional indefinidamente. A rampa de recompensa, em vez de um precipício, nega a um movimento de fork de mineradores o seu momento, e a rampa é abortável: se os checkpoints deixarem de finalizar por duas épocas consecutivas, ela pausa em seu nível atual até que a finalidade retorne. Os mineradores não podem comprar a pausa: travar a finalidade exige um terço da participação caucionada, que o vazamento por inatividade sangra até a finalidade voltar, de modo que o ataque custa mais do que a recompensa pausada paga. Os mineradores da Era 0 que caucionarem seu coinbase recebem prioridade — não moedas extras — nas primeiras rotações de sequenciador, convertendo a comunidade de mineração na comunidade de operadores em vez de descartá-la.

O gatilho da era blindada é deliberadamente moldado de forma diferente dos demais. Alturas e limiares de participação são fatos que um nó mede; a prontidão de um verificador criptográfico não é, de modo que o gatilho é, em vez disso, uma lista de verificação que um hard fork precisa ser capaz de citar: auditorias publicadas, épocas de testnet cumpridas, vetores no artefato. A forma importa mais que os itens. Esta rede não tem equipe de resposta a emergências — o bug de falsificação do Zcash foi sobrevivível em parte porque uma organização com equipe entregou uma correção em dias, e nada aqui pode prometer isso — de modo que a ativação da era é projetada para criar seus mantenedores em vez de pressupô-los: uma comunidade que não consegue produzir duas auditorias independentes e manter uma testnet adversarial é uma comunidade que não consegue manter um verificador de consenso, e a lista de verificação torna a segunda incapacidade visível como uma falha da primeira, antes da ativação em vez de depois de uma quebra. A regra de fold de §12 limita o que um bug sobrevivente pode custar; a lista de verificação limita quão pouco examinado um verificador pode estar no momento em que ele começa a custar algo. Nenhuma substitui a outra, e a era é entregue com as duas ou não é entregue.

A rampa é uma redivisão e não uma redução: seja qual for a fatia de que o proof of work abre mão, os proponentes de proof of stake a assumem, de modo que o cronograma de subsídio de §14.2 não é afetado pelo ponto em que a rede está em sua transição. É isso que permite ao cronograma continuar sendo uma função pura da altura, computável por qualquer nó a partir de quatro constantes, sem consultar o livro-razão.

A transição é tratável por uma razão arquitetural que vale enunciar: o fold é agnóstico quanto a quem ordena. Um minerador de PoW já é o proponente cego que o projeto exige; a Era 2 muda de quem é a assinatura no cabeçalho e não muda uma regra sequer da semântica de estado. Não há motor de execução a carregar através da fronteira.

A fronteira entre eras é também onde a capacidade se move: a capacidade em bytes de §8.1 e as constantes de transporte sob ela são refixadas ali, contra a propagação medida na rede em operação, de modo que o crescimento rotineiro pega carona nas atualizações que este cronograma já contém em vez de se tornar um evento de governança por si só.

14.1 A tesouraria#

Três por cento de cada subsídio de bloco são creditados à célula da tesouraria; noventa e sete por cento pagam o consenso — o produtor do bloco e, a partir da Era 1, os atestadores de checkpoint (§14). A fatia é fixada na gênese, vale desde o bloco 0 e vale de forma idêntica para todo bloco. As taxas nunca são tocadas (a tesouraria não tem direito algum sobre os mercados de §8), de modo que o custo recai sobre a emissão, distribuído entre todos os detentores na proporção do que detêm.

A célula fica selada até a Era 2. Ela acumula desde o bloco 0 e nenhuma chave a abre antes disso: sem quórum na gênese, sem endereço, sem chave do autor, sem caminho de emergência. No bloco 0 não existe uma comunidade madura para deter as chaves. Se nenhuma surgir, a célula nunca abre e as moedas nunca são emitidas. A regra de acumulação está na gênese desde o primeiro bloco para que ela jamais seja uma mudança; nada de novo acontece na Era 2, exceto que uma regra acordada torna-se operante.

Nada disso é um premine, e a diferença é conferível em vez de retórica. Um premine é uma alocação: moedas, um endereço e uma chave que existem na gênese e pertencem a alguém. A gênese aqui não contém nenhum dos três. Nenhuma moeda de tesouraria é gastável, nenhum endereço é designado, nenhuma chave existe e nenhuma parte é nomeada; o que a gênese contém é uma regra, aplicada de forma idêntica a todo bloco jamais minerado, mais uma segunda regra sobre como um quórum poderá um dia ser fixado sobre o resultado acumulado. Se esse dia chegará não é decisão do autor. Como o conjunto de chaves é fixado por hard fork, o mecanismo de seleção é o mesmo que toda mudança de consenso usa: alguém propõe cinco detentores publicamente identificados, os operadores de nó adotam o fork que os fixa ou se recusam a executá-lo, e um quórum candidato que não consiga convencer a rede a rodar seu fork detém chaves para nada. Não há voto a capturar, nem registro de colaboradores a manipular, nem momento algum em que a voz do autor pese mais que a de qualquer outro operador de nó.

A partir da Era 2, a célula só é debitada por um certificado portando três assinaturas de cinco sobre um conjunto de chaves fixado por hard fork. Os gastos são certificados comuns: públicos, finais e contáveis apenas a partir da cadeia. O quórum é formado por colaboradores ativos à época da abertura e publicamente identificados antes de o conjunto entrar em vigor; cada chave fica com uma parte distinta, nenhuma sob controle comum. Um gasto válido de 3 de 5 pode, em vez disso, nomear cinco chaves substitutas, com efeito após R blocos, período durante o qual a rotação é pública e o conjunto antigo ainda vale: a rotação carrega o limiar de um gasto e a visibilidade de um gasto.

As Eras 0 e 1 são financiadas por doação: propostas públicas antes do pagamento, marcos e orçamento declarados de antemão, liberação contra trabalho entregue, valores não usados devolvidos ao fundo. O quórum herda essa disciplina quando a célula abre. É uma norma e não uma regra de consenso; o que a faz valer é que todo desvio fica visível no livro-razão.

A fatia não expira. Ela é uma fração da emissão e não uma quantidade de moedas, de modo que decai junto com o subsídio de §14.2 e persiste na cauda como um fluxo nominal fixo; como fração da oferta, ela tende a zero. Removê-la custa o que qualquer mudança de consenso custa: um hard fork. A partir da Era 2, o 3 de 5 é o único quórum confiável do protocolo.

14.2 Emissão#

O subsídio decai suavemente até uma cauda perpétua. A taxa é constante dentro de uma época e desce um degrau em cada fronteira de época, por aritmética inteira exata sobre quatro constantes:

E(0) = E₀
E(n) = max(tail, E(n−1) − E(n−1)/Q)

onde L é a época em blocos, Q o divisor de decaimento, E₀ o subsídio de gênese e E(n) o subsídio por bloco ao longo da época n. Essas quatro — L, Q, E₀, tail — são as constantes; C, a oferta pré-cauda que o cronograma soma, é derivada delas ao executar a recorrência e não é uma entrada dela. Revisões anteriores escreviam a primeira linha como E(0) = C / (L · Q), o que se lê como se C fosse uma constante da qual o subsídio é dividido; ela é a forma fechada do decaimento geométrico infinito, e o cronograma finito abaixo não soma a isso. Não há números de ponto flutuante nem tabela para errar, e não há precipícios de halving: o degrau é pequeno o bastante para que nenhum bloco isolado o perceba, o mesmo raciocínio que faz da recompensa da Era 2 uma rampa. Uma vez que a fórmula caia abaixo da cauda, o subsídio é uma quantia fixa por bloco, para sempre.

O cronograma é uma função pura da altura. Ele não consulta quanto foi de fato pago, o que significa que um bloco que pague menos que o cronograma — um coinbase devido a um endereço cujo detentor o queimou, digamos — é uma perda permanente contra C e não uma dívida que a curva quite depois. C é, portanto, o número que o cronograma soma, não um teto que ele garanta alcançar.

A cauda existe porque a segurança é uma despesa permanente: ela paga quem quer que garanta a era corrente — mineradores, depois mineradores e atestadores, depois validadores — sem recrutar os mercados de taxas de §8. Ela é dimensionada para que a emissão anual da cauda comece abaixo de 1% da oferta em circulação; como o numerador é fixo e a oferta cresce, essa porcentagem só cai. Contra ela corre a queima da taxa-base sequencial de §8, de modo que a emissão líquida é a cauda menos a queima e pode ser negativa sob carga. A divisão 97/3 de §14.1 vale para todo subsídio, inclusive o da cauda.

Constantes (gênese, ilustrativas, como em §13): época L = 2.880 blocos; divisor de decaimento Q = 1054; subsídio de gênese E₀ = 21/bloco; cauda 0,33/bloco. Com blocos de 30 segundos, isso dá um fator anual de 0,70702, ou seja, a taxa de emissão cai pela metade a cada dois anos — e exatamente, não aproximadamente: E(730) = 10.50230028 contra E₀ = 21. A fórmula cai abaixo da cauda na época 4.376, altura 12.602.880, ≈ ano 12, de modo que o braço decrescente corre pelas épocas 0 a 4.375 e C, a oferta que ele soma, é 62.744.838,47. Desse total, 62.744.817,47 é de fato emitido: a diferença são os 21 do bloco de gênese, que não paga coinbase algum porque não há minerador a pagar e uma gênese reproduzível não pode creditar um endereço. A emissão anual da cauda é então ≈347 mil, ou 0,55% da oferta emitida, caindo a partir daí. **A forma fechada L · E₀ · Q = 63.745.920 é um limite superior de C, não seu valor**, e a diferença não é um erro de arredondamento: esse produto é a soma do decaimento geométrico infinito, ao passo que o cronograma é finito, arredonda para baixo a cada passo e para na cauda. Ele ultrapassa C em 1.001.081,53, ou 1,60%. Cite a soma e nunca a forma fechada. A conformidade é reproduzir a recorrência — nenhum nó jamais computa C, ou qualquer outro número deste parágrafo, em altura alguma.

15. Medições#

Um projeto cuja afirmação central é uma assimetria de vazão deve números ao leitor. Os números abaixo vêm da implementação de referência e podem ser rederivados a partir de seu código-fonte publicado. Hardware: uma CPU de desktop x86 de dez núcleos. Os números são medianas sobre 5 execuções.

• Vazão do fold: 883.000 operações de slot por segundo por núcleo sobre um conjunto de trabalho de 100.000 slots, ou seja, 294.000 certificados aplicados por segundo a 3 slots por certificado.
• Verificação sem estado: 1.470 certificados por segundo por núcleo de CPU, e 5.220 por segundo em 10 núcleos — a razão é a afirmação de paralelismo, medida em vez de asseverada.
• Verificação de assinatura: 1.500 por segundo, individual, com as conferências de ordem pequena e de torção incluídas.
• De ponta a ponta: um bloco de 2.900 certificados valida em 1.963 ms e passa pelo fold em 9,9 ms. Os dois são reportados separadamente porque são as duas metades do argumento: a primeira escala com núcleos que a rede não possui, a segunda é o único laço que ela possui.

A medição do fold é uma subtração, e dizer isso faz parte de reportá-la: confirmar um bloco executa as conferências sem estado e o fold sequencial em conjunto, de modo que o número do fold é o todo menos as conferências cronometradas isoladamente. As duas metades estão no artefato.

Reportamos apenas o que a implementação de referência executa, o que impõe dois limites que vale nomear em vez de deixar para o leitor descobrir. A verificação de assinatura é medida uma assinatura por vez: a verificação em lote é uma técnica real e um encaixe óbvio, mas é criptografia crítica de segurança que este projeto não escreveu, e um número para código que não existe não é uma medição. Os números de GPU e SIMT que §2 e §6 antecipam pertencem aos certificados em lote do sequenciador, que chegam com a Era 1. Ambos são expectativas de projeto. Nenhum é estrutural para os números acima: a afirmação de paralelismo repousa sobre os certificados serem conferíveis de forma independente, o que o agrupamento em lote tornaria mais rápido e não pode tornar verdadeiro.

16. Trabalhos relacionados#

O pipeline do Zycord — executar primeiro, ordenar às cegas, validar na confirmação — tem um ancestral em ambientes permissionados: o execute-order-validate do Hyperledger Fabric [3], cujas fraquezas documentadas são sua taxa de aborto sob disputa e sua dependência de políticas institucionais de endosso. As contribuições do Zycord em relação a essa linhagem são (i) a aplicabilidade por igualdade de valor com a omissão como semântica de primeira classe e tolerante a ABA; (ii) a atribuição econômica do conflito — o aval caucionado, que torna a equivocação objetivamente punível por slashing e a desatualização um serviço precificado e segurável, que é o que faltava ao execute-order-validate para dispensar permissão; e (iii) a inclusão forçada com aplicação garantida, ao passo que as escotilhas de saída dos rollups garantem apenas a inclusão. Os conjuntos determinísticos de leitura/escrita pré-declarados descendem do Calvin [4] e aparecem nas listas de acesso da Solana [16]; os métodos comutativos de escrow datam de O'Neil [9] e vivem hoje dentro de escalonadores de nó único como os agregadores do Aptos sobre o Block-STM [5] — o Zycord move o contrato de comutatividade para entre os nós e o precifica. Os sistemas de EVM paralela [5] e as cadeias de execução diferida ainda reexecutam em toda parte e esbarram na parede da E/S de estado; o Narwhal [6] separa a disseminação de dados da ordenação, como nossos projetos iniciais faziam; os objetos possuídos da Sui são paralelos às nossas células de escrita única; a divisão pending/base do Zether [7] inspirou a disciplina do delta com guarda (e retorna, junto com as raízes de privacidade do livro-razão quimérico [8], nos pagamentos confidenciais de §12 — o primeiro inquilino da faixa de criptografia pesada, com valores ocultos e endereços de uso único precificados em gas paralelo em vez de embutidos na camada base). As camadas de finalidade encadeada seguem o Casper FFG [12].

17. Conclusão#

Propusemos uma rede que ordena certificados em vez de executar transações: validade conferível por qualquer um, em qualquer lugar, em paralelo, apenas a partir dos bytes; estado avançado por um fold simples o bastante para ser especificado em uma página; conflitos omitidos, precificados e com dono; concorrência declarada em vez de descoberta; censura sobrevivível por construção; e um lançamento que distribui a moeda antes de pedir a alguém que confie em um conjunto de validadores. A verificação escala horizontalmente com hardware que a rede não possui. A confirmação permanece sequencial — e quase gratuita.

O Zycord não corre atrás do trabalho. Ele fica parado, e a rede faz o trabalho.

Referências#

[1] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008. [2] V. Buterin. Ethereum: A Next-Generation Smart Contract Platform. 2013. [3] E. Androulaki et al. Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains. EuroSys 2018. [4] A. Thomson et al. Calvin: Fast Distributed Transactions for Partitioned Database Systems. SIGMOD 2012. [5] R. Gelashvili et al. Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing. 2022. [6] G. Danezis et al. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus. EuroSys 2022. [7] B. Bünz, S. Agrawal, M. Zamani, D. Boneh. Zether: Towards Privacy in a Smart Contract World. Financial Cryptography 2020. [8] J. Zahnentferner. Chimeric Ledgers: Translating and Unifying UTXO-based and Account-based Cryptocurrencies. IACR ePrint 2018/262. [9] P. E. O'Neil. The Escrow Transactional Method. ACM TODS, 1986. [10] M. Herlihy, E. Koskinen. Transactional Boosting: A Methodology for Highly-Concurrent Transactional Objects. PPoPP 2008. [11] M. Shapiro et al. Conflict-free Replicated Data Types. SSS 2011. [12] V. Buterin, V. Griffith. Casper the Friendly Finality Gadget. 2017. [13] M. Corallo. BIP 152: Compact Block Relay. 2016. [14] tevador et al. RandomX: Proof-of-Work Algorithm Optimized for General-Purpose CPUs. 2019. [15] EIP-1559: Fee Market Change for the ETH 1.0 Chain. Ethereum Improvement Proposals, 2019. [16] A. Yakovenko. Solana: A New Architecture for a High Performance Blockchain. 2017. [17] Decred Documentation: Issuance. docs.decred.org — divisão da recompensa de bloco entre mineradores de PoW, votantes de PoS e tesouraria. [18] EIP-4844: Shard Blob Transactions. Ethereum Improvement Proposals, 2022. [19] Monero: Dynamic Block Weight and Penalty. Documentação do Monero Research Lab; veja também JollyMort, Monero Dynamic Block Size and Dynamic Minimum Fee, 2017. [20] bitcoincashautist. CHIP-2023-04: Adaptive Blocksize Limit Algorithm for Bitcoin Cash. 2023.