Glossário
Certificado, fold, omissão, depósito, sequenciador, caminho forçado. Vários destes significam aqui algo mais estreito do que em outros lugares, e alguns nomeiam eventos para os quais a maioria das cadeias não tem palavra.
O vocabulário que este protocolo usa, no sentido em que ele o usa. Várias destas palavras significam algo mais estreito aqui do que em outros lugares, e duas delas — omissão e descarte — nomeiam eventos para os quais a maioria das cadeias não tem palavra porque não têm equivalente.
Certificado#
O único tipo de transação no Zycord. Um certificado carrega o estado que leu e o estado que escreveu, mais o programa que os conecta, as assinaturas que o autorizam, um depósito, um TTL, e um lance em cada um dos dois mercados de taxas. Como ele carrega suas próprias entradas e saídas, verificar se é válido não exige estado algum.
Fold#
O laço determinístico que faz o livro-razão avançar. Ele percorre os certificados de um bloco em uma ordem canônica — primeiro os fills, depois todos os certificados comuns, depois os certificados forçados — e para cada um verifica se suas leituras declaradas ainda valem: se valem, ele compromete as escritas, e se não valem, ele faz a omissão. O fold realiza 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, e sem aritmética de curvas elípticas. É o único estágio do sistema que não paraleliza.
Omissão#
O que acontece com um certificado cujas leituras declaradas não valem mais, cujos deltas sairiam da faixa de 256 bits, ou que escreveria sob um endereço gasto. Nada é escrito, uma taxa de omissão fixa de 1.000.000 drops (0,01 ZCD) é queimada do seu depósito e não paga ninguém, o resto do depósito é devolvido, e o bloco continua válido. Paga quem nomeou o depósito: o autor de um certificado comum, que escolheu as leituras, ou o sequenciador de um fill. Um usuário nunca paga a omissão de um fill. A omissão é semântica, não falha: inclusão e aplicação são eventos diferentes, então um produtor de blocos nunca pode produzir um bloco inválido ao incluir um certificado desatualizado.
Descarte#
Um não-evento sem cobrança. Um certificado cujo depósito não pode ser reservado — a célula de depósito já foi gasta, ou contém menos do que o valor que o certificado reserva — sofre descarte: é levado no bloco, sem cobrança, sem ser marcado como visto, e livre para reenvio contra um depósito novo. Usuários honestos, portanto, não perdem nada em disputas sobre sua própria célula de depósito.
Depósito#
A célula que responde por um certificado: uma célula de saldo nativo de um endereço de usuário, o valor reservado dela, e o slot de troco para o qual o restante volta. Nenhum certificado existe sem uma, e a célula de depósito sempre carrega uma assinatura. A omissão não pode ser grátis, ou o mempool se afoga; o depósito é o que dá a todo conflito um dono. Um fill faz o depósito a partir do saldo persistente do seu sequenciador, e é por isso que o sequenciador, e não o usuário, paga quando um fill é omitido, e um certificado forçado é pago, em vez disso, pelo pagamento do seu intent aberto. Os avalistas e os certificados segurados do whitepaper v1.0 deixaram de existir; isto é o que os substituiu.
Célula#
O valor em um slot — um inteiro de 256 bits sem sinal armazenado em big-endian em 32 bytes. Zero é ausência: um slot nunca escrito e um slot escrito com zero são o mesmo slot. Isso é um requisito de consenso, não uma conveniência: mantém a raiz de estado uma função do estado em vez do histórico que a produziu.
Endereço de uso único (0x01)#
Um endereço cuja autoridade de assinatura é queimada permanentemente por seu primeiro débito. Pagar a um endereço de uso único recém-derivado é o caminho rápido sem disputa, e derivar um novo por pagamento é o que torna um pagamento não vinculável ao seguinte. O custo é que “gastar uma parte dele” não é algo que um endereço de uso único possa fazer — veja a regra 1 da carteira.
Endereço persistente (0x02)#
Um endereço reutilizável. Ele nunca pode entrar no registro de gastos, então não tem superfície alguma de dano por queima. Comerciantes, endereços de doação, os depósitos de um sequenciador e os pagamentos de mineração usam um; o zycordd --payout recusa qualquer outro.
Registro de endereços gastos#
O conjunto de consenso permanente de endereços de uso único cuja autoridade foi queimada. Os valores de célula sob um endereço gasto podem ser podados após o horizonte de desfazer, mas a entrada do registro nunca é — é ela que impede que o endereço seja ressuscitado. Cerca de 33 bytes por endereço, para sempre: o problema em aberto que o protocolo assume honestamente, compartilhado estruturalmente com todo design de conjunto de nullifiers.
Válido vs. aplicável#
Dois predicados que uma cadeia convencional confunde. Válido é sem estado, paralelo, e verificável por qualquer um apenas a partir dos bytes do certificado. Aplicável é com estado, sequencial, e decidido apenas pela posição no livro-razão. Dois certificados válidos podem declarar o mesmo valor de entrada para o mesmo slot; no máximo um pode ser aplicável.
Delta com guarda#
Uma disciplina de acesso na qual um certificado afirma um predicado sobre um slot — balance ≥ 10 — sem ler o valor para dentro da computação, e escreve um delta com sinal. Qualquer número de débitos e créditos com guarda ao mesmo slot comuta, então uma omissão ocorre apenas em um saque a descoberto real e não meramente porque o saldo mudou. Esta única disciplina cobre transferências, emissões com teto de oferta, permissões e cotas de cofre, e nunca é controlada por um sequenciador: um token sequenciado continua aceitando toda transferência de qualquer um.
Delta puro#
Um delta com sinal e sem guarda. Ele nunca pode entrar em conflito e nunca sofre omissão. Gorjetas, contadores, acumuladores, contagens de recompensa.
Leitura exata#
A disciplina no estilo SLOAD: a leitura retorna o valor do slot para dentro da computação e prende o certificado a ele. Lógica arbitrária, conflitos em slots quentes, e o domínio dos sequenciadores.
Sequenciador#
Um serviço fora da cadeia que um contrato escolhe para serializar seu tráfego de leitura exata. O registro de todo contrato contém uma chave de sequenciador: enquanto ela não é zero, uma leitura exata, uma guarda de igualdade ou um set sobre as células desse contrato precisa da assinatura dessa chave; enquanto ela é zero, o contrato é aberto, e protegido apenas pelo seu código. O sequenciador executa os intents dos usuários e publica os resultados como fills. Confia-se nele para a vivacidade, nunca para a segurança: ele não pode mudar o que um intent faz, só quando, e um fill construído sobre uma mentira é omitido à custa do sequenciador. Se ele deixar de atender, resta o caminho forçado.
Intent#
O que um usuário assina em vez de um certificado para chamar um contrato sequenciado: o alvo e o calldata, um orçamento paralelo, um nonce, uma janela de no máximo 8 blocos, o endereço persistente do sequenciador, limites sobre o resultado, o pagamento devido a cada sequenciador, os pagadores de uso único que o financiam, e saídas de troco. Um limite é um predicado sobre uma célula que a chamada escreve — final-at-least, final-at-most, delta-at-least ou delta-at-most — e pelo menos um precisa nomear uma célula que a chamada escreveu. O intent é toda a autorização do usuário, e seus pagamentos só são liquidados se o fill for aplicado.
Fill#
O certificado que um sequenciador publica para um intent. Seu programa é o intent, seu depósito vem do próprio saldo persistente do sequenciador, e seu id é o hash do intent, de modo que dois fills de um mesmo intent compartilham um id e só um pode ser cobrado. Os fills vêm primeiro na ordem do fold, cada um assim que todo pipeline em que ele está estiver pronto.
Recibo#
A resposta assinada de um sequenciador a um intent, devolvida em milissegundos, muito antes de existir um bloco: o id do intent, o seq do pipeline e o resultado. É uma pré-confirmação — a promessa do sequenciador, não da cadeia, e final só quando o fill é aplicado. Como os recibos são assinados, dois da mesma chave que dão um mesmo seq a intents diferentes, ou resultados diferentes a um mesmo intent, são uma prova que qualquer um pode conferir a partir dos bytes. O consenso não pune isso; os usuários vão embora.
Pipeline#
A cadeia guarda, para cada par de chave de sequenciador e contrato, o último seq aplicado. Um fill só entra quando esse contador está uma unidade abaixo do seu seq, e o contador só avança quando o fill é aplicado, de modo que os fills de um sequenciador são comprometidos na ordem em que ele os assinou, qualquer que seja a ordem em que um produtor os recebeu. Um fill omitido segura os fills construídos atrás dele até que o sequenciador os reconstrua a partir do mesmo número.
Contador fence#
Um contador no registro de todo contrato. Um fill declara o contador fence dos contratos sobre os quais foi construído, e não pode entrar se algum deles tiver avançado. Ele avança quando um certificado forçado que entra define uma das células do contrato, e quando a célula de sequenciador do contrato é escrita — de modo que o caminho forçado e uma troca de sequenciador invalidam todo fill construído sobre o estado que eles mudaram, sem que ninguém seja cobrado. Uma leitura ou um delta não o move, e um certificado forçado que falhou também não. O sequenciador reconstrói e perde apenas latência.
Cossequenciamento#
Uma chamada que atravessa contratos vinculados a sequenciadores diferentes entra como um único fill que carrega a assinatura de cada sequenciador cujo caminho exato ela toca, até 16, cada um com um seq no seu próprio pipeline e cada um recebendo o que o intent nomeia para ele. Como eles se coordenam é algo fora da cadeia e livre por design; a cadeia vê um certificado, atômico por construção.
Diretório de sequenciadores#
Onde um sequenciador anuncia seu serviço: um certificado de diretório a partir do seu endereço persistente vincula sua chave a uma string de 1 a 256 bytes de ASCII imprimível, tipicamente uma URL. A entrada expira 259.200 blocos (cerca de 90 dias) depois do TTL do certificado que a anunciou, a menos que seja renovada, e uma retirada a remove de imediato. O consenso armazena a string e nunca a interpreta — é descoberta, não autorização. Um nó a responde em /directory.
Caminho forçado#
O caminho lento que não precisa de sequenciador. Um usuário assina um intent aberto e o retransmite para a rede; um produtor de blocos executa os intents abertos que escolher contra o estado do fim do bloco e anexa os resultados como certificados forçados, os últimos certificados do bloco. A inclusão é a aplicação: não há fila, arrendamento, cota nem prazo. Um bloco carrega no máximo 16 certificados forçados, cada um com no máximo 4.000 unidades de derivação de orçamento paralelo (200.000 de gas da máquina), e é por isso que toda saída que um contrato oferece precisa caber nesse orçamento. Um certificado forçado cuja chamada reverte ainda entra, como FORCED_FAILED: seus pagadores pagam, o troco volta ao usuário, e nada mais é escrito.
Intent aberto#
Um intent sem sequenciador nomeado e sem cossequenciadores, financiado pelos próprios pagadores de uso único do usuário. Ele viaja no mempool como um intent, não como um certificado, e seu pagamento cobre as taxas do certificado forçado: a parte da taxa base é queimada e o resto vai para o produtor. zcd wallet open-intent assina um, e zcd wallet intent --fallback assina um quando o sequenciador não atende o original.
cEVM#
A única máquina virtual: um dialeto da máquina virtual do Ethereum adaptado a certificados. O armazenamento é declarado em vez de descoberto, opcodes são acrescentados para guardas, deltas e para definir o sequenciador de um contrato, os opcodes sem referente aqui são removidos, e NUMBER e TIMESTAMP respondem a partir do beacon de época. Ativa a partir da Era 1, com uma biblioteca padrão pensada primeiro em deltas pré-implantada em endereços conhecidos. Solidity e suas ferramentas continuam valendo.
Beacon de época#
Células reservadas que o protocolo escreve uma vez por época: o número da época, a altura do cabeçalho que a abriu, uma palavra de entropia e, a partir da Era 1, o horário desse cabeçalho. Os programas não podem ler valores ambientes como o timestamp ou a altura diretamente — isso tornaria a execução uma função de algo que não as leituras declaradas — então eles leem o beacon como qualquer outro slot, idealmente com uma guarda de faixa. Seus valores são constantes durante uma época inteira. A palavra de entropia é saída de proof of work e é inadequada para loterias de alto valor.
Época#
2.880 blocos — cerca de um dia com blocos de 30 segundos, e, a partir da transição para proof of stake, 17.280 slots de 5 segundos, ainda um dia. A unidade na qual o subsídio decresce por degraus, o alvo de capacidade sequencial se move, e o beacon é renovado.
TTL#
A altura até a qual um certificado precisa ser comprometido para ser válido. Limitado por consenso a 240 blocos (cerca de duas horas), 1.440 blocos a partir da transição para proof of stake, que é o que mantém o conjunto de vistos podável. Incluir um certificado já visto ou expirado torna o bloco inválido — então uma assinatura é cobrável no máximo uma vez, e apenas em uma posição que seu assinante aceitou ao assinar.
Gas sequencial e paralelo#
As taxas se dividem em dois mercados: um para mutação sequencial de estado, que é escassa, e um para verificação paralela, que não é. Uma verificação de assinatura, portanto, não compete no mesmo leilão que uma escrita de armazenamento, e é isso que torna a criptografia pesada barata por design. Nos dois, a taxa base é queimada e a taxa de prioridade paga o produtor pelos certificados aplicados, e somente por eles; a taxa de um certificado omitido é queimada por inteiro.
Era#
Uma etapa do protocolo, liberada por uma altura compilada nas releases públicas e, na Era 2, por stake medido na cadeia dentro de limites de altura — nunca por data de calendário ou por votação. Era 0, ativa desde o bloco 0: mineração, ativos nativos, os dois mercados de taxas, a divisão do subsídio e a tesouraria, acumulando e selada. Era 1 na altura 80.640 na mainnet, por volta de 4 de novembro de 2026, e desde a altura 2.880 na testnet pública: a cEVM, os sequenciadores, intents e fills, o diretório e o caminho forçado. Era 2, proof of stake: o bonding abre na época 182, por volta de 7 de abril de 2027; a rampa começa quando o stake ativo mantém 10% da oferta por 30 épocas, no mais tardar na época 273; a transição para o stake apenas vem quando a rampa se completa. A Era S acrescentaria pagamentos confidenciais, só depois de auditorias independentes, e não faz parte da especificação atual. As Eras 2 e S saem cada uma como uma release própria, por hard fork. O bonding não faz parte da Era 1.
Proof of stake#
O consenso da Era 2, no qual o direito de produzir o próximo bloco é sorteado por stake em vez de vendido por hashes, e o intervalo entre blocos cai de 30 para 5 segundos. Todo o resto permanece: todo nó verifica todo certificado a partir dos seus bytes, o fold e os dois mercados de taxas não mudam, e um certificado inválido dentro de um bloco ainda torna o bloco inválido. A computação que um minerador gastava em hashes, um produtor gasta em verificação. Ele entra por uma rampa e uma transição, e até a transição os blocos são minerados. Especificado no §11 do whitepaper.
Stake#
Moeda nativa caucionada à produção de blocos. BOND move saldo de um endereço persistente para uma célula de stake vinculada a esse endereço, cuja chave é a chave que assina blocos, e UNBOND o devolve após um prazo de saída maior que o horizonte de desfazer. Um stake se torna ativo uma época depois de caucionado, então stakes não podem ser criados e descartados em série. A caução mínima é de 1.000 ZCD; uma chave, um stake. O bonding abre com a Era 2, na época 182.
Pool e delegação#
Uma pool é um stake que aceita delegação. DELEGATE aponta uma caução para a chave de uma pool, a partir de um mínimo menor que o de uma caução de produção, e o saldo nunca sai do delegador, que pode redirecioná-lo ou retirar a caução sob o mesmo prazo de saída. O peso de uma pool no sorteio é a sua própria caução mais o que lhe é delegado, e o fold divide a recompensa dela uma vez por época entre a pool, na margem que ela declarou, e seus delegadores, na proporção do stake. Um delegador nunca sofre slashing: se uma pool comete equivocação, só a caução dela é queimada. Não é uma pool de mineração, que fica fora da cadeia e fora do consenso.
Slot#
Sob proof of stake, um intervalo de 5 segundos no qual um bloco pode ser produzido, pelo produtor sorteado para ele com probabilidade proporcional ao stake, a partir de uma semente fixada na época anterior. Uma época tem 17.280 slots. Um slot sem bloco fica vazio e não paga nada, e, entre as cadeias válidas, vence a que ocupa mais slots. Em outros contextos, um slot é uma posição de armazenamento, (address, word), cujo valor é uma célula.
Rampa#
A entrada da Era 2: 90 épocas nas quais todo bloco continua minerado e também carrega a assinatura do stake sorteado para a sua altura. O staker fica com k/180 da parte do produtor, em que k começa em 1 e sobe um a cada época que passa pelo portão: pelo menos 90% dos blocos da época assinados, e stake ativo de pelo menos 10% da oferta. Um bloco minerado sem a assinatura é válido e não paga ninguém: a parte do produtor e as taxas de prioridade dele são queimadas. A rampa começa quando o stake ativo mantém 10% da oferta por 30 épocas, e na época 273 no mais tardar. Não é a rampa de emissão de 30 dias; veja emissão.
Transição#
O bloco em que o proof of work termina: o primeiro bloco da época seguinte à 90ª época a passar pelo portão da rampa, no mais tardar na época 363, por volta de 5 de outubro de 2027, se o portão nunca pausar. A partir dele, os blocos vêm em slots de 5 segundos, uma época tem 17.280 slots, e cada bloco paga um sexto da taxa da época; os tetos por bloco se dividem por seis e toda contagem de blocos que mede tempo se multiplica por seis, de modo que a capacidade e as durações por dia continuam as mesmas. Um bloco é então final a uma profundidade de 120 blocos, 10 minutos, onde o proof of work pedia 20.
Equivocação#
Dois cabeçalhos assinados por uma chave para um mesmo slot: a única falta punida no consenso sob proof of stake. Como um certificado inválido, é uma prova de uma única mensagem que qualquer um pode verificar a partir dos bytes. Um certificado de denúncia carrega os dois cabeçalhos, e o fold queima a própria caução do signatário, remove sua chave do conjunto ativo e paga uma fração ao denunciante. Nada que um produtor faça alcança a moeda de outra pessoa: as delegações de uma pool voltam aos seus delegadores.
Emissão#
O ZCD existe apenas como subsídio de bloco, e o bloco 0 não paga nenhum. A taxa começa em 21 ZCD por bloco e desce a cada fronteira de época por aritmética inteira exata — E(n) = max(tail, E(n−1) − floor(E(n−1) / 1054)) — caindo pela metade mais ou menos a cada dois anos até chegar à cauda perpétua de 0,33 ZCD por bloco na época 4.376, por volta do ano 12. Os primeiros 86.400 blocos (30 dias) são uma rampa: o bloco h paga h/86.400 da taxa que o bloco 86.400 paga, e o que a rampa retém, cerca de 907.917 ZCD, nunca é pago de volta. A partir da transição para proof of stake, cada bloco paga um sexto da taxa da época, de modo que um dia paga o mesmo. zcd emission --height N imprime o subsídio em qualquer altura.
Divisão do subsídio#
Todo subsídio de bloco, e nunca as taxas, é dividido 94 / 3 / 3 por consenso desde o bloco 0: 94% para o produtor do bloco após uma maturidade de duas horas (240 blocos, 1.440 sob proof of stake), 3% para o endereço persistente do fundador até a época 1.095 (três anos), e 3% para a tesouraria, que a partir daí também recebe os 3% do fundador. Durante a rampa do proof of stake, os 94% do produtor são eles próprios divididos entre o minerador e o staker sorteado. É uma regra aplicada a todo bloco minerado, não uma alocação na gênese: não há premine.
Tesouraria#
O saldo nativo do endereço do protocolo. Nenhuma chave gera um hash igual a ele, nenhum certificado pode debitá-lo, e a gênese não nomeia nenhum quórum. Ele recebe 3% de cada subsídio de bloco desde o bloco 1 e 6% a partir da época 1.095. Não existe caminho de gasto no protocolo: um só pode ser acrescentado por uma atualização posterior, com signatários escolhidos pela comunidade e não pelo fundador, e o compromisso de lançamento é que ele não venha antes da altura 259.200, por volta de 5 de janeiro de 2027.
Proposta de administração#
Uma proposta para revisão da comunidade, não uma regra de consenso. Ela sugere como a tesouraria poderia ser gasta nos seus três primeiros anos: cinco assentos com estatutos públicos — desenvolvedor principal, desenvolvedor revisor, minerador, comunidade, representante público — com 3 de 5 para gastar, e 4 de 5, público por 20.160 blocos antes de entrar em vigor, para substituir um titular, rotacionar chaves, gastar a reserva ou emendar um estatuto. Os orçamentos são parcelas da entrada da tesouraria, nunca somas fixas. Nada nela vincula até que a atualização da tesouraria fixe um conjunto de chaves. O texto está no documento complementar.
RandomX#
A função de proof of work, otimizada para CPUs de uso geral para que hardware comum permaneça competitivo; a mainnet e a testnet pública rodam randomx-v2. Ela é um parâmetro de consenso, não uma configuração: um binário que não consegue computar o pow_engine de uma rede se recusa a iniciar em vez de recorrer a outro.
Raiz de estado#
O compromisso com a totalidade do estado em uma altura. Um nó a recomputa ao iniciar e se recusa a rodar se a armazenada divergir, e ela funciona também como uma guarda diferencial em tempo de produção entre nós: duas implementações que chegam a raízes diferentes a partir de uma mesma sequência de blocos encontraram um bug em uma delas.
Onde cada termo é definido normativamente#
Esta página é um auxílio de leitura. As definições que valem estão na especificação e nos vetores de referência; o raciocínio está no whitepaper, v2.0, e no seu complemento, Launch, Eras and Parameters, que rege a emissão, as eras e todo valor de parâmetro. A seção de vocabulário da própria implementação está em docs/ARCHITECTURE.md.