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

Zycord: uma rede ponto a ponto de transições de estado autocertificadas.
The Simstoshi
2026 — v2.0
GPG: E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29

Este artigo é completo e autocontido. Ele substitui a v1.0 [0]; a §15 expõe a relação. Lançamento, emissão, eras e a tabela completa de parâmetros estão no documento complementar, Zycord: lançamento, eras e parâmetros.

Versões. O texto abaixo é a v2.0 do artigo, sem cortes, seguida nesta página por seu documento complementar, também v2.0. Ambos são servidos como PDFs, cada um com uma assinatura destacada feita pela chave do projeto E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29: o artigo (assinatura) e o complemento (assinatura). Cada versão é arquivada sob doi:10.5281/zenodo.22167489, que resolve para a mais recente; a v1.0 substituída é doi:10.5281/zenodo.22167490. O complemento é arquivado sob seu próprio doi:10.5281/zenodo.23383987.

1. Introdução#

Um nó de blockchain 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 e é 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.

O Zycord separa os três. Uma transação torna-se um certificado que carrega suas próprias entradas e saídas, de modo que verificá-la é uma função pura de seus bytes e nunca toca o livro-razão. 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 uma parte que aceitou o risco. A concorrência não é descoberta em tempo de execução; ela é declarada, slot a slot, pelo autor do contrato. A linhagem é execute-order-validate [3], a ordenação determinística [4], a execução paralela otimista [5] e a separação entre disseminação e ordenação [6].

A validade é avaliada uma vez por certificado, em paralelo, antes que qualquer bloco exista. O fold é executado uma vez por bloco, em ordem, e nunca executa.

O projeto se apoia em dois universos que podem compartilhar um executável, mas nunca devem ser confundidos:

As regras de consenso apenas verificam. Seu propósito é que nenhum usuário perca fundos sem autorizar, ninguém debite um saldo que não controla e nenhum atacante consiga drenar, bloquear ou desacelerar a rede. Como um sequenciador opera, como os sequenciadores conversam entre si e quanto cobram estão fora do consenso. O que está na cadeia é a liquidação: o pagamento de um sequenciador viaja dentro do intent que o usuário assinou e só é pago se o certificado for aplicado.

As seções a seguir definem o certificado (§2), o fold (§3), o acesso tipado ao estado (§4), os ativos nativos (§5), a máquina virtual (§6), os sequenciadores (§7), o caminho forçado (§8), os dois mercados de taxas (§9), a rede (§10), o proof of stake (§11), o caminho além da verificação completa (§12), os riscos aceitos (§13), a conformidade (§14) e a relação com a v1.0 (§15).

2. Certificados de transição de estado#

O certificado é o único tipo de transação. Ele é codificado em SSZ, o que dá uma única codificação canônica em bytes; a decodificação impõe a forma canônica, de modo que um certificado decodificado é estruturalmente válido por construção e nenhuma regra posterior reconfere o formato.

Dois digests respondem a duas perguntas. O id do certificado é o hash do certificado com uma lista de assinaturas vazia: ele nomeia o que o certificado autoriza. O hash de exemplar cobre a codificação inteira, assinaturas incluídas: ele nomeia um conjunto de bytes. As assinaturas ficam fora do id porque a assinatura é aleatorizada; cada nonce gera outra assinatura válida sobre o mesmo corpo, e um id que as cobrisse daria a uma única autorização ilimitadas identidades cobráveis. O id indexa o conjunto de vistos, a ordem do fold e toda a deduplicação. Um fill e um certificado forçado tomam como id o hash do seu intent (§7, §8); o lance de um fill é selado pela assinatura do seu sequenciador. O hash de exemplar é aquilo com que a raiz de certificados de um bloco se compromete, de modo que um id de bloco determina os bytes que o bloco carrega. O lance de taxa está dentro do id e é assinado: um lance fora do id é um lance que qualquer um em trânsito poderia reescrever. Cada assinatura assina uma mensagem que vincula o id da cadeia e a raiz de consenso do conjunto de parâmetros, de modo que um certificado não pode ser reproduzido em outra rede.

A validade é sem estado. Um certificado é válido quando, apenas a partir de seus bytes:

1. ele decodifica canonicamente, nomeia esta cadeia, e cada lista está dentro de seu limite;
2. toda assinatura verifica sob Ed25519 estrito (codificações canônicas, chaves livres de torção), e o conjunto de assinaturas é mínimo além de suficiente;
3. reexecutar o programa contra as leituras declaradas produz exatamente as escritas declaradas;
4. toda escrita que precisa de autorização a tem, e a célula de depósito carrega uma assinatura incondicionalmente;
5. o depósito é uma célula de saldo nativo de um endereço de usuário e cobre o pior caso do certificado;
6. o certificado é autoconsistente: nenhuma escrita contradiz uma leitura do mesmo slot, nenhum endereço de uso único debitado deixa de ser marcado como gasto, e nenhum valor é escrito em um endereço gasto;
7. ele não escreve nenhuma célula de protocolo;
8. todo endereço que ele nomeia carrega um byte de versão definido;
9. em um contrato cuja chave de sequenciador é não nula, o caminho de leitura exata carrega a assinatura dessa chave (§7), exceto em um certificado forçado (§8);
10. uma escrita de metadados declara uma leitura exata de toda célula que sobrescreve, no valor que a célula tinha quando o certificado foi construído.

Qualquer máquina confere isso: um pool de threads, outro computador, uma GPU, sem banco de dados e sem sincronização. As conferências de assinatura são independentes umas das outras, de modo que podem ser agrupadas entre certificados. Esta é a propriedade sobre a qual todo o resto é 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. A noção clássica de validade de transação é, portanto, dividida 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). Um certificado inválido nunca entra em um mempool honesto, e um que seja incluído em um bloco torna o bloco inválido.

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

Um bloco é um cabeçalho, uma lista ordenada de hashes de exemplar de certificados 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. O produtor de um bloco não executa nada. Ele ordena certificados que já viu validados, resolve o proof of work [13] (ou, sob proof of stake, assina o slot para o qual foi sorteado, §11) e carrega o conjunto de ids de certificado vistos dentro da janela de TTL, porque incluir um deles duas vezes torna o bloco inválido.

O estado da cadeia é um fold sobre os certificados ordenados. Para cada certificado, em ordem, o fold reserva o depósito, confere cada leitura declarada contra o estado atual, prepara as escritas com aritmética verificada e então consolida ou omite:

• APPLIED — toda leitura declarada vale, então as escritas são efetivadas e a taxa é liquidada pelo custo real.
• SKIPPED — uma leitura não vale mais (STALE), um delta sairia do intervalo [0, 2²⁵⁶) (OVERFLOW), ou uma escrita cai sob um endereço gasto (SPENT). Nada é escrito. Uma taxa de omissão fixa é queimada do depósito e o restante é devolvido.
• FORCED_FAILED — um certificado forçado (§8) cuja chamada reverteu ou violou seus limites. Seus pagadores são debitados e queimados, o troco volta ao usuário, nada mais é escrito, e o id é marcado como visto.
• DROPPED — o certificado não pôde ser cobrado de forma alguma (a célula de depósito está sem fundos ou gasta), então ele é carregado, marcado como visto e não é cobrado. Ele não paga nada ao seu produtor e lhe custa espaço sob o teto. Um fill na mesma condição invalida o bloco em vez disso (abaixo), porque descartá-lo consumiria o intent do usuário sem que ninguém fosse pago.

Ordem canônica. O fold ordena os certificados de um bloco em três classes e não deixa ao produtor nenhuma discricionariedade. Primeiro os fills (§7), cada um tomado assim que todo pipeline em que está estiver pronto, com empates resolvidos por (sequencer key, contract, seq, id). Em seguida, todos os demais certificados, por (deposit address, Seq, id). Por último, os certificados forçados (§8), por id. Todo nó deriva um estado idêntico a partir de uma sequência idêntica de blocos.

As escritas são conferidas antes que qualquer uma delas seja efetivada. Um crédito a um endereço cuja autoridade foi queimada falha ruidosamente em vez de ressuscitar a célula; um delta que transbordaria faz falhar o certificado inteiro. O registro permanente de endereços gastos existe exatamente para isso.

A omissão é semântica, não falha. Inclusão e aplicação são eventos distintos. Um produtor nunca pode produzir um bloco inválido ao incluir um certificado que se revelou desatualizado; o certificado é omitido e o depositante paga. O depositante escolheu as leituras, então o depositante responde por elas.

Uma assinatura, no máximo uma cobrança. Certificados aplicados e omitidos são igualmente marcados como vistos. Incluir um certificado visto ou expirado, ou um que ofereça um lance abaixo da taxa base do bloco em qualquer dos dois mercados, torna o bloco inválido, de modo que nenhum produtor pode reincluir ou atrasar deliberadamente os certificados de outras pessoas para colher seus depósitos. Os TTLs são limitados por consenso, então o conjunto de vistos permanece podável.

Condições sem ninguém a cobrar invalidam o bloco. Algumas falhas não têm culpado: um fill cujo contador de sequenciador está fora de ordem, cujo contador fence (§7) avançou, cujo pagador já está gasto ou cujo depósito não pode ser reservado; um certificado forçado cujas leituras não valem. Incluir um certificado assim torna o bloco inválido e nada é cobrado. O produtor, que construiu o bloco a partir do estado que mantém, é a parte que poderia ter sabido.

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, sem aritmética de curva elíptica. Tudo isso aconteceu em paralelo durante a conferência de validade. O id do certificado também é computado ali e levado para o fold.

Igualdade de valor, não versões. A aplicabilidade compara os valores de leitura declarados, não contadores de versão. Um slot que mudou e voltou ao que era continua aplicável, de modo que o sistema omite estritamente menos vezes que o controle de concorrência baseado em versões.

O prólogo e o epílogo do próprio fold. Antes dos certificados, em uma fronteira de época, o fold escreve as células do beacon (§4). Depois deles, divide o subsídio do bloco e rotaciona o anel de maturidade do coinbase (documento complementar), registra o gas aplicado para o controlador de taxas (§9) e, em uma fronteira de época, computa a raiz de estado da época, que deve ser igual à do cabeçalho. Ele retorna um erro apenas por invalidade do bloco; um problema com um certificado é um desfecho, nunca um erro.

4. Células e acesso tipado ao estado#

Uma célula é o valor em um slot (address, word): um inteiro sem sinal de 256 bits, big-endian em 32 bytes. Células ausentes são lidas como zero. Ao lado das células, o protocolo mantém um registro de endereços gastos, um conjunto permanente de endereços de uso único cuja autoridade de assinatura foi queimada.

Um endereço é version ‖ blake3(tag ‖ version ‖ payload)[:31], exceto o endereço de protocolo, que é o byte de versão 0x00 seguido de zeros:

Uso único versus persistente é uma política de carteira exposta como um bit do endereço, não dois livros-razão [7]. As carteiras usam por padrão um endereço de uso único novo para cada pagamento recebido, de modo que pagar a um endereço recém-derivado é o caminho rápido de contenção zero, e uma célula gasta é compactável assim que o bloco que a gastou estiver enterrado além do horizonte de desfazer. Quem quer uma conta usa a versão persistente. As recompensas de mineração pertencem a um endereço persistente: o consenso aceita qualquer dos dois tipos como endereço de pagamento, mas um endereço de uso único queima toda recompensa que contém no momento em que é gasto, e o nó recusa um por esse motivo.

O acesso tipado é de onde vem o paralelismo. Um fold que suportasse apenas leituras exatas serializaria todo contrato popular: mil certificados tocando um pool renderiam uma aplicação e 999 omissões. Em vez disso, uma leitura declara como restringe uma célula e uma escrita declara o que faz com ela:

Apenas EXACT fica desatualizado. Qualquer número de débitos e créditos com guarda em um slot comutam: eles se aplicam em qualquer ordem, e uma omissão só ocorre quando uma guarda falha genuinamente (um saque a descoberto real), não quando o saldo apenas mudou. Uma disciplina por slot por certificado: um set e um delta não coexistem no mesmo slot. A regra que mantém o modelo correto é que valores com guarda nunca fluem para a computação: um assert não devolve nada e um delta não lê nada, de modo que a reexecução permanece uma função pura das leituras exatas declaradas. Essa única disciplina cobre transferências, emissões com teto de oferta, autorizações de gasto (allowances), gorjetas e cotas de cofre, que são a esmagadora maioria das escritas na cadeia. A linhagem são as transações de escrow, o transactional boosting e os CRDTs [8][9][10]; o Zycord faz da comutatividade o contrato de concorrência entre nós.

Células de uso único. Um endereço que nunca apareceu na cadeia está no estado ∅; uma primeira escrita o leva a armazenado; o certificado que o marca como gasto, assinado por sua chave, o leva a gasto, permanentemente. A entrada do registro que grava o gasto nunca é compactada: é ela que impede o endereço de ser ressuscitado.

Zero é ausência. Um slot nunca escrito e um slot escrito com zero são o mesmo slot: escrever zero apaga a célula. Isso é um requisito de consenso. Permite a uma guarda ou a uma leitura exata nomear 0 sem perguntar se o slot existe, e mantém a raiz de estado uma função do estado, e não do histórico que o produziu.

O beacon de época. Programas não devem ler valores ambientes diretamente. O protocolo escreve a altura do cabeçalho que abriu a época atual e, a partir da era da máquina, o tempo dele em células reservadas, uma vez por época, e os programas as leem como qualquer outro slot. Isso dá consciência de tempo sem desatualização a cada bloco; ambos os valores são constantes ao longo da época, um dia na mainnet: 2.880 blocos sob proof of work, 17.280 sob proof of stake (§11).

5. Ativos sem uma máquina#

A era de lançamento precisa de uma economia antes de precisar de um computador. O Zycord oferece ativos nativos como operações de certificado desde o bloco 0, sem nenhuma máquina virtual envolvida:

• TRANSFER — até 32 movimentações de (asset, from, to, amount) em um certificado, dentro dos limites dele para leituras e escritas, cada uma uma guarda balance ≥ Δ pareada com dois deltas. Um crédito direcionado a um delta puro ou a uma célula de uso único nova é a gorjeta, então dar gorjeta não precisa de um opcode próprio. Um endereço de contrato só pode receber crédito na moeda nativa, e nunca o endereço de um precompilado (§6), do qual nada poderia retirar o valor.
• ISSUE — cria um id de ativo com um teto de oferta em uma célula de escrita única.
• MINT — com guarda: minted + Δ ≤ cap.
• RETIRE — queima até 64 endereços de uso único, cada um autorizado pelo seu dono e dentro dos limites do certificado, sem movimentar valor: sem leituras, uma escrita pura que marca cada célula como gasta. O gasto propriamente dito é automático dentro de uma transferência. A aposentadoria é a primitiva de compactação e privacidade: o recebedor apaga um endereço de uso único depois que ele cumpriu seu papel.

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. O cronograma de oferta da moeda nativa e o teto de cada ativo emitido vivem aqui, impostos pela aritmética verificada de §3.

Um pagamento é liquidado assim. A carteira do remetente escolhe uma célula de uso único que detém, declara uma guarda sobre ela, debita-a, marca-a como gasta, credita o endereço de uso único novo do destinatário e envia o troco a um endereço de uso único novo próprio. Dois certificados correndo para gastar a mesma célula de uso único por meio de dois nós diferentes são ambos válidos; exatamente um se aplica, e o outro é omitido e cobrado do depósito que nomeou.

6. A máquina: cEVM#

O Zycord executa uma máquina virtual, a cEVM, um dialeto da máquina virtual 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, e a máquina deve ser a coisa mais familiar do sistema. Solidity, seus compiladores, auditores e ferramental são aproveitados. Toda a divergência do dialeto é uma lista de remoções, duas religações, seis adições e quatro reprecificações.

O armazenamento é declarado, não descoberto. Um certificado carrega as leituras que sua execução consumiu e as escritas que produziu, e a validade as compara com uma reexecução. Quatro famílias de opcodes alcançam uma célula: SLOAD e SSTORE na disciplina exata, e as famílias de assert e de delta na comutativa. Um frame chamado pode adicionar no máximo 16 entradas ao conjunto declarado, de modo que um chamado não pode gastar os limites de que seu chamador precisa; a entrada que excederia isso aborta esse frame e nenhum outro.

Adicionados, em bytes que nenhum fork da EVM jamais atribuiu: SASSERTGE 0x21, SASSERTLE 0x22, SASSERTEQ 0x23, SDELTAADD 0x24, SDELTASUB 0x25, SETSEQ 0x26. O predicado e o sinal estão no opcode, nunca na pilha. Uma guarda não devolve nada, de modo que nenhum desvio pode depender de ela valer; o líquido de um delta é tomado sobre os inteiros e nunca módulo 2²⁵⁶. SETSEQ(key) define a célula de sequenciador do contrato cujo contexto está em execução e de nenhum outro; uma chave zero ou malformada é uma falha de derivação que invalida o certificado inteiro.

Religados: NUMBER e TIMESTAMP respondem a partir de leituras exatas das células do beacon de época, de modo que ambos são constantes ao longo da época, e um contrato portado que usa block.timestamp para um prazo está decidindo contra um tempo com até 24 horas de atraso.

Removidos (13): BLOCKHASH, COINBASE, PREVRANDAO, GASLIMIT, BLOBHASH [14], BLOBBASEFEE, SLOTNUM não têm referente; GASPRICE e BASEFEE nomeiam células por bloco cuja leitura exata é desatualizada por construção; BALANCE e SELFBALANCE forçariam uma leitura exata de um saldo nativo; ORIGIN não tem remetente a nomear; SELFDESTRUCT permitiria que uma célula de hash de código voltasse a zero.

Reprecificados: SLOAD e SSTORE têm custo fixo no valor do acesso quente; a sobretaxa de acesso frio é eliminada em toda parte; KECCAK256 sobe para 720 de gas mais 144 por palavra, medido contra a própria implementação desta máquina, a única reprecificação que aumenta uma cobrança. Os opcodes de assert e de delta custam o mesmo valor de acesso quente que SLOAD.

Os precompilados são um conjunto fechado de cinco: sha256, identity, modexp, ed25519_verify e blake3.

Dois medidores. O gas sequencial é derivado das contagens declaradas de leituras, escritas e registro, e nunca é medido pela máquina. O medidor paralelo é o que o interpretador conta, contra um orçamento que o certificado declara em unidades de derivação; excedê-lo na profundidade 0 invalida o certificado.

O código viaja no certificado. O código do contrato vive em uma célula de hash de código de escrita única, de modo que não há reimplantação, e uma implantação é uma chamada com alvo zero. A imagem de execução é carregada no certificado e resolvida por uma leitura exata declarada da célula de hash de código, nunca apenas pelo endereço. Um blob tem no máximo 24.576 bytes.

O registro de um contrato são cinco células: o hash de código, o implantador, a chave de sequenciador, o admin e o contador fence (§7). A célula de admin contém um endereço; zero significa que o implantador é o admin, e 32 bytes de 0xff significam que o papel foi renunciado, irreversivelmente. O admin define a chave de sequenciador por meio de um certificado de registro e transfere ou renuncia ao papel por meio de um certificado de definição de admin; ambos declaram leituras exatas das células de implantador e de admin, de modo que um certificado de um admin substituído ou que renunciou é omitido. O código do contrato nunca define um admin; ele move seu próprio sequenciador com SETSEQ, que é também como um contrato criado por uma fábrica obtém um.

A biblioteca padrão. Um token, um pote de gorjetas e um escrow, escritos com deltas em primeiro lugar, são pré-implantados em endereços conhecidos no bloco que ativa a máquina, junto com o wrapper de deltas que eles chamam. Um contrato do Ethereum portado que evite os opcodes e precompilados removidos funciona corretamente desde o primeiro dia em modo todo exato, serializado por um sequenciador se estiver muito disputado; o paralelismo é opcional por slot, tipicamente um pequeno diff que move um mapa de saldos de load/store para assert/delta.

7. Sequenciadores#

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 formador de mercado automatizado, onde dois usuários honestos construindo contra a mesma célula ainda produzirão uma omissão, e onde contratos que leem estado para decidir o que escrever não podem ser aplicados em ordem arbitrária. A resposta do protocolo é deixar o contrato escolher seu serializador.

Vínculo. O registro de todo contrato (§6) contém uma chave de sequenciador. Um contrato cuja chave é não nula é sequenciado: um certificado só pode fazer leitura exata, guarda por igualdade ou set em uma de suas células com a assinatura dessa chave. Um contrato cuja chave é zero é aberto: qualquer um pode tomar seu caminho exato com um certificado próprio, e o contrato é protegido apenas por seu código. A chave é definida na implantação pelo implantador, depois pelo admin, ou pelo próprio código do contrato por meio de SETSEQ, que é como uma governança substitui um sequenciador sem um admin. O vínculo pode nomear qualquer chave; uma chave que ninguém atende não é um erro de consenso, o contrato simplesmente fica inutilizável até que alguém a atenda ou que o caminho forçado (§8) a altere. Deltas com guarda comutam e nunca são bloqueados, de modo que um token sequenciado continua aceitando toda transferência de qualquer um.

O diretório. Um sequenciador anuncia onde seu serviço responde com um certificado de diretório: sua chave e uma string de 1 a 256 bytes de ASCII imprimível, tipicamente uma URL, anunciada a partir de um endereço persistente. A entrada expira 90 dias após o TTL do certificado de anúncio, a menos que seja renovada, e um certificado de retirada a remove imediatamente. O consenso armazena a string e nunca a interpreta. O diretório é descoberta, não autorização: as carteiras o leem para saber a quem perguntar.

Intents. Um usuário não constrói um certificado contra um contrato sequenciado. O usuário assina um intent: o alvo e o calldata, um orçamento paralelo, um nonce, uma janela de NotBefore a TTL com TTL − NotBefore de no máximo 8 blocos, o endereço persistente do sequenciador, um conjunto de limites sobre o resultado, o pagamento devido ao sequenciador, os pagamentos devidos a eventuais cossequenciadores, pagadores de uso único que financiam tudo isso 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 limite deve nomear um slot que a chamada escreveu. O intent é toda a autorização do usuário; o sequenciador não pode mudar o que ele faz, apenas quando.

Fills. O sequenciador executa o intent sobre sua própria visão do estado, a ponta da cadeia mais todo fill que já construiu, e publica o resultado como um fill: um certificado cujo programa é o intent, cujo depósito vem do saldo persistente do próprio sequenciador e cujo id é o hash do intent, de modo que dois fills de um mesmo intent compartilham um id e apenas um pode ser cobrado. O sequenciador é confiável apenas quanto à vivacidade, nunca quanto à segurança: se mentir sobre as entradas, o fill é simplesmente omitido contra o fold canônico, e a mentira custa o depósito do sequenciador, não os fundos do usuário.

Recibos. Um sequenciador responde a um intent assinado em milissegundos, muito antes de existir um bloco: ele executa o intent, assina o fill e devolve à carteira o fill, ou um recibo assinado que nomeia o id do intent, o seq do pipeline e o resultado. Isso é uma pré-confirmação. É a promessa do sequenciador, e não a da cadeia; torna-se final quando o fill se aplica. Como todo recibo é assinado, o mau comportamento é evidência: dois recibos de uma mesma chave que dão um mesmo seq a intents diferentes, ou a um mesmo intent resultados diferentes, são uma prova que qualquer um pode conferir a partir dos bytes. O consenso não o pune. O mercado pune. Formato do recibo, preço, identidade e reputação são fora da cadeia e livres por concepção, de modo que os usuários escolhem entre um sequenciador mais barato, um publicamente identificado ou um anônimo, e abandonam aquele que for pego em equivocação.

Pipelines. A cadeia mantém, para cada par (sequencer key, contract), o último seq aplicado. Um fill declara um seq para cada pipeline em que está e só pode entrar quando o contador estiver em seq − 1; os contadores só avançam quando o fill se aplica. Um fill omitido, portanto, deixa seu contador onde estava: os fills construídos atrás dele não podem entrar, e o sequenciador reconstrói a partir do mesmo número. Dois fills em um mesmo seq: o primeiro na ordem do fold entra, o segundo não pode. O pipeline de um sequenciador é consolidado na ordem em que ele assinou, qualquer que seja a ordem em que um produtor o recebeu, e um produtor que mistura os pipelines de vários sequenciadores não tem escolha sobre o resultado.

O contador fence. Todo contrato mantém um contador, fid, em seu registro. Um fill declara o fid de todo contrato do qual faz leitura exata ou em que faz set; uma divergência significa que o fill não pode entrar. O contador avança em um quando um certificado forçado (§8) que se aplica faz set em uma célula do contrato, e quando a célula de sequenciador do contrato é escrita. Uma leitura ou um delta não o avança: uma leitura não muda nada, e um delta comuta com o que quer que um fill proteja com guarda ou altere por delta. Um fill que faz leitura exata de uma célula que outros movem por delta responde por essa leitura como qualquer certificado, e seu sequenciador paga a omissão se a célula se moveu. É assim que o caminho forçado e uma troca de sequenciador invalidam todo fill construído sobre o estado que contornaram, sem ninguém ser cobrado: o sequenciador vê o fence se mover, reconstrói e republica, perdendo apenas latência.

Cossequenciamento. Uma chamada que atravessa contratos vinculados a sequenciadores diferentes chega à cadeia como um único fill que carrega a assinatura de todo sequenciador cujo caminho exato ela toca, dentro do limite de 16 assinaturas do certificado, cada uma contada contra o teto de assinaturas do bloco e no gas paralelo, cada uma com um seq em seu próprio pipeline, cada sequenciador recebendo o que o intent designa para ele. A coordenação, quem lidera, como as reservas são feitas, quanto cada um cobra, é fora da cadeia e livre por concepção; a cadeia vê um único certificado, atômico por construção. Um fill conjunto que nunca é publicado bloqueia apenas os pipelines em que está; passada sua janela, cada signatário reutiliza o número que assinou.

Quem paga uma omissão. Quando um fill entra e uma leitura está desatualizada ou uma escrita transborda, nada é escrito, ninguém é pago, e quem errou paga a taxa de omissão: a primeira leitura ou escrita que falhou na ordem do certificado decide, e a conta vai para o sequenciador que se declarou para aquele contrato se o contrato estiver no caminho exato do fill e o registro da cadeia concordar; em todos os outros casos, vai para o líder, o sequenciador cujo depósito o fill nomeia. Cada sequenciador listado tem uma reserva tomada na posição do fill exatamente para isso. O usuário nunca paga uma omissão. O pagamento do usuário a cada sequenciador só é liquidado quando o fill se aplica.

O que é um sequenciador. Um servidor comum operado pela equipe da aplicação, com o maquinário que preferir: um único processo, um rollup, uma federação. Ele vê primeiro o fluxo de ordens de sua aplicação e é, portanto, o local natural para o valor extraível dessa aplicação; o projeto torna isso explícito e permite que a aplicação capture esse valor em vez de deixá-lo vazar para os produtores de blocos, enquanto o caminho forçado limita o poder que isso implica. Contratos pesados tornam-se viáveis, criptografia, a lógica inteira de um jogo, um sistema inteiro em um contrato, porque a execução pesada acontece fora da cadeia, na construção, e a cadeia a verifica em paralelo. A construção é um mercado competitivo: um sequenciador mais barato ou mais confiável atrai usuários, e cada nó que oferece construção adiciona capacidade.

8. O caminho forçado: inclusão é aplicação#

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

O usuário assina um intent aberto: um intent exatamente como em §7, sem sequenciador nomeado e sem cossequenciadores, financiado pelos próprios pagadores de uso único do usuário, e o retransmite à rede. Ele viaja no mempool como um intent, não como um certificado. O produtor de blocos, que mantém o estado completo e já liquidou todo certificado comum do bloco, computa o estado de fim de bloco e executa os intents abertos que escolher contra esse estado, na ordem dos ids de intent, anexando os certificados forçados resultantes como os últimos certificados do bloco. O id de um certificado forçado é o hash do seu intent, como o de um fill. Inclusão é aplicação: não há fila, arrendamento, cota nem prazo. Um certificado forçado cujas leituras declaradas não valem contra o estado em que foi colocado não pode entrar no bloco de forma alguma; o produtor o construiu, então o produtor é a parte que poderia ter sabido.

Limitado por construção. Um bloco carrega no máximo 16 certificados forçados, e cada um declara no máximo 4.000 unidades de derivação de orçamento paralelo (200.000 de gas de máquina). Toda saída que um contrato oferece, saque, cancelamento, aposentadoria, transferência, deve caber nesse orçamento; a regra para autores de contratos é que um saque caiba no orçamento forçado. Com ocupação total, o caminho forçado toma um terço do teto paralelo da gênese e o tráfego comum fica com o restante.

Uma chamada que falha ainda entra. Um certificado forçado cuja chamada reverte, viola seus limites ou fica sem gas entra em sua forma falha, FORCED_FAILED: seus pagadores são debitados e queimados, o troco volta ao usuário, o id é marcado como visto e nada mais é escrito. A validade aceita a forma falha apenas quando reexecutar a chamada contra as leituras declaradas de fato falha. É isso que torna o caminho resistente a abuso: um atacante que retransmite intents abertos que não podem ter sucesso paga por cada um, e um usuário cujo intent é correto não pode ser privado de acesso por eles, porque o produtor é pago pelo que inclui e prefere excedente.

O fence. Um certificado forçado que se aplica e faz set em uma célula de um contrato avança o contador fence desse contrato (§7), de modo que nenhum fill construído sobre o estado que ele alterou pode entrar. Um certificado forçado que apenas lê um contrato sequenciado, de forma exata ou por guardas, ou que apenas movimenta deltas nele, deixa o fence intacto, assim como um que entra em sua forma falha; os fills pendentes ainda entram, e só é omitido aquele que fez leitura exata de uma célula que o certificado forçado moveu (§7). O sequenciador perde latência, nada mais, e um usuário que força uma transação por bloco em um contrato disputado paga o preço forçado a cada vez.

Pagamento. O pagamento do intent cobre as taxas do certificado às taxas-base do bloco; a parte da taxa-base é queimada e o restante se junta às gorjetas do produtor. O produtor recebe o que um sequenciador receberia.

Nenhum estado fica órfão. Um contrato cujo sequenciador desapareceu permanece vivo por meio de seus métodos de delta, que não precisam de sequenciador, e por meio do caminho forçado, pelo qual seus usuários sacam e pelo qual seu próprio código, ou o admin, pode chamar SETSEQ ou um registro e vinculá-lo a um novo sequenciador. A censura se inverte: ela custa ao censor, em taxas perdidas e em usuários que o contornam, e não custa nada à rede. Nenhum operador é estrutural para a segurança.

9. Dois mercados: gas sequencial e gas paralelo#

Uma cadeia consome três recursos de classes de escalabilidade diferentes, dados, verificação e mutação, e precificá-los em um só mercado significa que uma conferência de assinatura concorre em leilão com uma escrita de armazenamento. O Zycord divide a taxa em dois mercados independentes, cada um com seu próprio alvo, teto e taxa-base mantidos no estado de consenso:

O gas sequencial precifica a mutação de estado, o recurso escasso, o único laço que todo nó executa em ordem. O gas paralelo precifica a verificação, que cresce com cada núcleo e GPU que entra na rede, e seu teto é definido alto e barato. A consequência é um 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.

Ambos os mercados têm o formato do EIP-1559 [12], cada um em sua própria unidade: a taxa-base é queimada e a taxa de prioridade paga o produtor, nos certificados que se aplicam, e apenas nesses. A taxa de um certificado omitido é queimada por inteiro e não paga ninguém. Esta é a regra estrutural do 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. 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 é ativamente contrário a causar omissões.

Apenas o gas aplicado move as taxas-base. Três quantidades são contadas por bloco: o gas incluído (todo certificado, qualquer que seja seu desfecho) limita os tetos; o gas aplicado (apenas o que se aplicou) move as taxas-base; os bytes do bloco limitam o teto de bytes. Uma omissão é uma tentativa fracassada de usar a cadeia, não evidência de demanda por ela; se o gas incluído movesse a taxa, um sabotador poderia encher blocos com certificados autoconflitantes à taxa de omissão fixa e expulsar todos pelo preço a custo constante.

O teto sequencial é elástico. O alvo sequencial T é estado de consenso desde o bloco 0, não uma constante, e um controlador por época o move:

• Dentro de um bloco, o teto flexível é 2T e o limite rígido é 4T. Um produtor que estoura entre os dois perde uma parcela quadrática de sua própria receita, parte do subsídio mais as taxas do bloco, e nunca a parcela de outra pessoa.
• Entre épocas, T acompanha a demanda: o dobro da mediana inferior do gas aplicado na época, restrito entre T − T/1024 e T + T/512, com piso no valor da gênese e teto na capacidade da gênese (documento complementar). O crescimento é retido quando o portão de saúde diz que a rede não está saudável: cabeçalhos concorrentes citados acima de 2% dos blocos da época.
• A contagem de certificados, a contagem de assinaturas e o limite de bytes escalam com T a partir de seus valores da gênese, até capacidades estáticas (2²⁵ certificados, 8 MB).

Certificados omitidos queimam suas taxas e não registram nada, de modo que a única maneira de elevar o teto é conquistar aplicação: uso sustentado, sem conflitos e 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. O mercado paralelo não precisa de nenhum desses cuidados: seu alvo e seu teto são fixados em um múltiplo constante, 3×, do alvo e do teto sequenciais, portanto 3T e 6T, e herdam o crescimento deles. A linhagem é a mediana de penalidade do Monero [15] e o trabalho sobre limites adaptativos [16].

A margem de construção. O mesmo mercado paralelo paga os sequenciadores pelo trabalho de modelagem: um sequenciador que agrega muitas transações em um certificado paga um único lance paralelo por ele e cobra de seus usuários por transação, dentro do intent.

10. 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, de modo que o estado é 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 porque carregam suas leituras e escritas; as mitigações são estruturais: os fills cortam as escritas internas, as células de uso único gastas são compactadas quando enterradas além do horizonte de desfazer, e um nó pode podar corpos abaixo de um piso que anuncia aos pares.

Transporte. TCP, depois TLS 1.3 com identidades de pares Ed25519 em certificados autoassinados: o canal é vinculado a uma chave, e nada além disso é afirmado. Toda mensagem é um quadro de 5 bytes, comprimento e tipo, e o comprimento é conferido contra o teto próprio do tipo antes de qualquer alocação. Um tipo que uma versão mais nova adicionou é lido e descartado sob um limite pequeno, em vez de a conexão ser fechada.

A retransmissão é por hash primeiro. Os certificados se propagam por gossip de forma independente e têm a validade conferida, sem estado e em paralelo, na chegada. Um nó de retransmissão não precisa de estado para limitar o custo de filtrar spam: a validade sem estado é conferível a partir dos bytes, e um nó que mantém estado também recusa um certificado cujo depósito não pode cobri-lo. A retransmissão trata exemplares, não ids: um certificado cujas assinaturas falham custa aquele exemplar, e nada é registrado contra o id, porque um exemplar posterior da mesma autorização pode ser bom. Os blocos são retransmitidos como cabeçalhos mais listas de hash contra o mempool [11], de modo que a latência de propagação não escala com o conteúdo dos blocos, e o receptor verifica o trabalho do cabeçalho antes de buscar qualquer corpo.

A sincronização escolhe pelo trabalho verificado. Um nó que está alcançando a cadeia prefere o par cujos cabeçalhos de fato comprovaram mais trabalho ao par que alega a maior altura. Os cabeçalhos são validados como cadeia antes que os corpos sejam buscados; um ramo concorrente só é adotado quando se conecta dentro do horizonte de desfazer e carrega mais trabalho que a cadeia que substitui (sob proof of stake, mais slots, §11). Checkpoints fixados, embutidos na versão publicada e aceitos apenas quando um bloco tem pelo menos uma época de idade, recusam uma cadeia contraditória por mais pesada que seja, como defesa da era de lançamento contra a reescrita do histórico; um operador pode adicionar um checkpoint fixado por flag.

Os pares são pontuados, por identidade: uma mensagem inválida custa 20, uma violação de protocolo 50, um corpo não servido 10, uma requisição excessiva 5; uma mensagem útil rende 1; um par é banido em −100. Conferências caras, épocas de chave e avaliações de proof of work, são orçadas por par e reembolsadas quando o bloco se mostra útil, de modo que um atacante não consegue fazer um nó moer trabalho em anúncios que não levam a lugar nenhum.

Citações. Um cabeçalho pode citar até quatro cabeçalhos concorrentes recentes na altura de seu pai, sem remuneração: citar exige proof of work real, enquanto suprimir o sinal exigiria que quase todo produtor o omitisse. A taxa de forks citada é o sinal de saúde que o controlador de taxas (§9) lê.

A interface do nó. As leituras são servidas por HTTP, vinculadas ao localhost por padrão; submeter certificados, intents abertos e cartões de serviço assinados são as únicas escritas. As leituras têm limite de taxa por cliente, com um token de confiança para isentar as ferramentas do próprio operador. Um endpoint Stratum no dialeto que os mineradores de CPU comuns falam permite que um nó minere com software externo.

11. Proof of stake#

Esta seção especifica o consenso da era em que a produção de blocos passa do proof of work para o stake. As regras de §2 a §10 continuam valendo sem alteração, exceto onde esta seção disser o contrário; o cronograma e todos os valores estão no documento complementar. As constantes marcadas como em aberto são fixadas pela release da era.

O que muda. Duas coisas. O direito de produzir o próximo bloco, que o proof of work vende por hashes, é sorteado por stake; e o intervalo entre blocos cai de 30 para 5 segundos. Todo o resto permanece: toda regra de validade da §2 é verificada por todo nó, para todo certificado, a partir dos bytes; o fold é o mesmo; os dois mercados de gas são os mesmos; um certificado inválido dentro de um bloco torna o bloco inválido. A regra de citação da §10 permanece, com a assinatura de slot do cabeçalho citado no lugar do seu trabalho. A superfície que esta era abre é a de um proof of stake, e nenhuma outra.

Para onde vai a computação. Um minerador de proof of work gasta computação em hashes, que compram segurança e nada mais. Um produtor nesta era gasta a mesma computação em verificação: conferir assinaturas, reexecutar programas, derivar certificados, em paralelo, antes de ordená-los. O trabalho pelo qual a rede paga se torna o trabalho de que a rede precisa. Um computador comum verifica milhares de certificados por bloco; um produtor com mais núcleos acompanha o volume à medida que ele cresce. A verificação paralela põe o teto muito acima do que o laço sequencial consome; o que está além dele está na §12.

Stake. Um participante cauciona moeda nativa com uma operação nativa, BOND, que move saldo de um endereço persistente para uma célula de stake vinculada a esse endereço. As células de stake são células de protocolo: o certificado autoriza a movimentação e o fold realiza a escrita, como faz com os contadores de sequenciador. A chave desse endereço é a chave que assina blocos. Um stake se torna ativo uma época depois de caucionado, então stakes não podem ser criados e descartados em série; UNBOND devolve o saldo após um prazo maior que o horizonte de desfazer. O mínimo é definido pelo documento complementar. Uma chave, um stake.

O sorteio. Os blocos ocupam slots de intervalo fixo. Para cada slot, um produtor é sorteado do conjunto de stakes ativos na abertura da época, com probabilidade proporcional ao stake, a partir de uma semente que a cadeia fixou durante a época anterior e escreveu nas células do beacon (§4); a semente não pode ser enviesável pelos produtores dos blocos que a fixam. O cabeçalho carrega o slot e a assinatura do produtor sorteado no lugar do proof of work; um cabeçalho assinado por outra chave, ou fora do seu slot, é inválido. Um slot sem bloco fica vazio, e o próximo produtor sorteado constrói sobre o último bloco que conhece. O sorteio é uma função de estado fixado antes de a época abrir, de modo que todo nó o deriva sozinho, e nenhuma mensagem de consenso é trocada além do próprio bloco. A linhagem é a loteria de líder de slot do Ouroboros [17] e o cronograma de líderes por época da Solana [21]; esconder o líder atrás de uma função aleatória verificável [31], como faz o Praos [18], é a alternativa se a negação de serviço contra produtores conhecidos se tornar um problema.

Escolha da cadeia. Onde a §10 escolhe pelo trabalho verificado, esta era escolhe pelo comprimento: entre as cadeias válidas, a que ocupa mais slots [17]; entre duas de mesmo comprimento, aquela cujo primeiro bloco após o fork está no slot mais cedo. O horizonte de desfazer e os checkpoints fixados da §10 permanecem e são a defesa contra a reescrita com chaves cuja caução já foi retirada: um nó que entra na rede aceita o histórico que sua release fixa, e nenhuma cadeia mais longa o contradiz.

Recompensa. O subsídio de bloco e as taxas de prioridade vão para o produtor sorteado, como iam para o minerador, pelo mesmo anel de maturidade; a parte queimada continua queimada. A receita esperada de um participante é proporcional ao seu stake, e o custo de coletá-la é a verificação dos certificados que ele inclui. Um bloco inválido é rejeitado e não paga nada a quem o assinou.

Equivocação. Uma única falta é punida no consenso: dois cabeçalhos assinados por uma chave para um mesmo slot. Como um certificado inválido, é uma prova de uma única mensagem, verificável por qualquer um a partir dos bytes. Um certificado de denúncia carrega os dois cabeçalhos; o fold queima a própria caução do signatário, remove a chave do conjunto ativo e paga ao denunciante uma fração em aberto. Uma denúncia é aceita até que a saída do stake se complete. Nenhuma outra conduta é punida no consenso, e nenhuma conduta de um produtor alcança a moeda de outra pessoa. O precedente é o slashing de proponente na beacon chain do Ethereum [19].

Pools. Uma pool é um stake que aceita delegação. Qualquer endereço persistente pode caucionar e, por uma operação nativa DELEGATE, apontar sua caução para a chave de uma pool; uma caução que apenas delega tem um mínimo menor que uma que produz. O saldo nunca sai do delegador, que o redireciona ou retira 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. A recompensa dos blocos que uma pool produz é dividida pelo fold uma vez por época, fora do caminho por bloco, entre a pool, a uma margem que ela declara ao se registrar, e seus delegadores, na proporção do stake. Em caso de equivocação, a própria caução da pool é queimada e suas delegações voltam aos seus delegadores. Como a verificação é dividida dentro de uma pool é assunto da pool: cada membro verifica a parte que recebe, um certificado pode ir para mais de um membro, e o operador reúne as respostas, monta o bloco e o assina com a chave sorteada. Tudo isso é construção, fora do consenso e livre por concepção (§1): a cadeia vê uma tabela de delegações, um cabeçalho assinado por uma chave e um bloco cujos certificados todo nó completo verifica de novo. Um nó pequeno contribui com os núcleos que tem; um detentor que só tem moeda contribui com stake. A linhagem são as stake pools do Cardano [20], que também nunca aplicam slashing aos delegadores.

A rampa. A era entra em três etapas, cada uma delas uma regra de consenso.

1. Bonding. BOND, UNBOND e DELEGATE são aceitos. O proof of work continua produzindo todo bloco e recebendo toda a parcela do produtor.
2. Rampa, ao longo de 90 épocas. Todo bloco continua minerado e carrega a assinatura do stake sorteado para a sua altura, no cabeçalho, fora da pré-imagem do proof of work; o id do bloco a cobre, de modo que um bloco assinado e sua cópia não assinada são dois blocos, e, com trabalho igual, vence o assinado. A escolha da cadeia continua sendo por trabalho, e duas assinaturas em uma mesma altura não são equivocação. A parcela do produtor no subsídio é dividida entre minerador e staker: um contador k começa em 1 e sobe um a cada época que passa pelo portão, e o staker fica com k/180, de modo que o trabalho mantém pelo menos metade até a transição. Um bloco carregado sem a assinatura é válido e não paga ninguém: a parcela do produtor no subsídio e as taxas de prioridade dele são queimadas, de modo que um minerador não ganha nada ao deixar o staker de fora, e um staker não ganha nada ao se ausentar. Uma época passa pelo portão quando pelo menos 90% dos seus blocos carregaram a assinatura e o stake ativo, delegações incluídas, manteve pelo menos 10% da oferta. A rampa começa quando o stake ativo atinge 10% da oferta por 30 épocas ou, no mais tardar, na época que o documento complementar fixa, com o stake que existir. Nenhum bloco é produzido só por stake antes que o stake tenha assinado, em produção, nove blocos em cada dez durante 90 épocas. O precedente é o híbrido do Decred, no qual os blocos minerados carregam votos de stake e o subsídio é dividido entre os dois [22], e o Merge, no qual o stake rodou sua própria cadeia por quase dois anos antes de assumir a produção de blocos [23].
3. Transição. O primeiro bloco da época seguinte à 90ª época a passar pelo portão é o slot 0: o proof of work termina, o intervalo passa a 5 segundos e a época passa a 17.280 slots. O que uma época paga em subsídio não muda; cada bloco paga um sexto, e um slot vazio não paga nada. Os tetos por bloco (§9), com seus pisos e limites máximos, e a contagem do caminho forçado (§8) se dividem por seis, arredondando para baixo, de modo que a capacidade por dia é a mesma no instante da transição, e o controlador por época continua a partir daí. Toda constante contada em blocos que mede tempo (maturidade, TTL máximo, janela do intent, horizonte de desfazer, janela do tempo mediano, duração de uma entrada de diretório) se multiplica por seis, e uma maturidade ou um TTL definidos antes da transição são convertidos no bloco da transição.

Finalidade. Um bloco é final por profundidade, como sob proof of work. Serviços financeiros devem esperar 10 minutos: 120 blocos, onde o proof of work pedia 20. Blocos com mais de uma época de idade podem ser fixados como checkpoints.

12. Além da verificação completa#

Nas eras de proof of work e de proof of stake, todo nó verifica todo certificado. A computação não é o limite: a verificação é paralela, e os tetos da §9 são refixados nas fronteiras de era até a largura estrutural da lista de certificados, 2²⁵ por bloco. O que limita antes dessa parede são os dados: a banda para receber todo corpo e o armazenamento para guardar todo corpo e toda entrada do registro de gastos. Esta seção diz o que se sabe do caminho além disso e o deixa para uma era posterior, ativada sob demanda, quando o volume diário se aproximar do que um nó comum verifica. É uma direção, não uma especificação: os problemas têm várias soluções com compromissos diferentes, a rede atende toda demanda que vai encontrar por muito tempo sem nenhuma delas, e preparar em detalhe um futuro distante não vale mais do que deixar o caminho sinalizado para quem o percorrer. Nada do que vem antes muda. A validade como função dos bytes, o fold, o acesso tipado, os dois mercados, os sequenciadores e o caminho forçado permanecem como estão. O que muda é apenas quem verifica cada certificado.

O que o certificado permite. Nas cadeias de reexecução, o Ethereum, a Solana e as que derivam deles, todo validador executa toda transação contra o estado global, verificar herda os limites do estado, e a resposta histórica tem sido máquinas maiores, o que equivale a dizer menos nós. A execução paralela dentro do nó, com listas de acesso declaradas como na Solana [21], torna cada máquina mais rápida e não muda quem precisa de uma. O Cardano chegou mais perto: no modelo UTXO estendido, a validação é determinística e local [24], mas os scripts rodam em todo nó e o estado compartilhado é disputado, o que o modelo resolve empurrando a serialização para batchers fora da cadeia, não reconhecidos pela cadeia. Os rollups, tanto os otimistas quanto os de validade [25][26], tiraram a execução da cadeia base e a deixaram verificando: essa é a divisão certa, paga com uma segunda camada, uma ponte, um sequenciador único cujo caminho forçado espera atrás de um atraso e, conforme o tipo, uma semana de disputa interativa ou um provador que custa ordens de grandeza mais que executar. Um certificado do Zycord é um lote de rollup que a cadeia base confere a partir dos próprios bytes e nunca executa contra o seu estado, e por isso não precisa de segunda camada: não há ponte porque há um único estado; não há disputa porque um certificado inválido é a sua própria prova de fraude, em uma única mensagem; não há provador porque verificar custa o que executar custa; o sequenciador é por contrato, o caminho forçado entra no bloco seguinte, e dois contratos sob sequenciadores diferentes se compõem em um único certificado atômico (§7), onde dois rollups precisam de uma ponte. E onde a resposta ao crescimento é o sharding, a trajetória original do Ethereum, o Near [27], as parachains [28], que particiona o estado e perde a atomicidade entre partições, a partição do Zycord, quando vier, particiona a verificação e não o estado: o estado continua único, o fold continua único e todo certificado continua atômico, porque quem verifica um certificado é uma escolha livre quando a validade é uma função dos bytes.

Verificação amostrada. Com stake caucionado, a responsabilidade de verificar um certificado pode ser sorteada para um subconjunto de stakes em vez de recair sobre todos eles. Um certificado entra em um bloco com as atestações do seu comitê; qualquer nó continua livre para verificar qualquer coisa; um certificado inválido continua sendo a sua própria prova de fraude, uma única mensagem, sem estado e sem jogo interativo [29]; e o que a era acrescenta é o slashing de quem atestou. O tamanho do comitê, a forma da atestação, a janela de contestação e o que acontece com o que foi aplicado sobre um certificado anulado são a especificação dessa era, e permanecem em aberto. O efeito é inverter a curva: a capacidade cresce com cada nó que entra, porque cada um verifica uma parte menor, e o comitê cresce com o conjunto.

O cone de verificação. Quem recebe um certificado não precisa da cadeia inteira para confiar nele. As leituras são declaradas, então o conjunto de certificados de que ele depende é enumerável a partir da cadeia: para cada célula lida, os certificados que a escreveram desde a última raiz de estado de época, e os deles, recursivamente. Esse cone, reverificado a partir dos bytes e ancorado em uma raiz de época com a qual o cabeçalho se compromete (§3), é uma verificação completa do que importa para o receptor, feita em segundos, no tempo da rede, sem circuito e sem prova especial. Uma corretora que recebe um depósito verifica o cone do depósito, não a rede; sob verificação amostrada, o que resta é esperar passarem as reorganizações e a janela de contestação, que é o que ela já faz hoje. Uma prova de que uma célula tinha um dado valor na raiz de época é o único objeto novo que isso requer, e sua forma está em aberto; a linhagem é a verificação simplificada de pagamentos [1].

Armazenamento. O que a rede já faz: as células de uso único gastas são compactadas além do horizonte de desfazer (§4), e um nó poda corpos abaixo de um piso que anuncia (§10). O que fica como caso de estudo: um registro de gastos por época, no qual os endereços de uso único expiram e o registro se fecha; um acumulador no lugar do registro [30]; e a guarda dos corpos antigos por uma fração dos nós, com a raiz de época como garantia de que o que é guardado é o que foi gasto.

Banda. Dois caminhos. O primeiro é a topologia que o design já tem: carteira, sequenciador, produtor. Um fill não precisa inundar a rede; ele vai do sequenciador para os produtores, e todos os demais recebem o hash, como a retransmissão já faz com os blocos (§10). O segundo é separar a cabeça de um certificado do seu corpo. A cabeça é o que o fold toca: id, leituras, escritas, depósito e lance. O corpo é o que a verificação consome: programa, calldata, assinaturas. Sob verificação amostrada, um produtor precisa do corpo apenas dos certificados que foi sorteado para verificar e da cabeça de todos os outros, e sua banda cai em ordens de grandeza. O bloco continua se comprometendo com o hash do exemplar inteiro, e os corpos continuam sendo dados de cadeia, servidos por quem os verificou e por quem os arquiva; como a disponibilidade deles é garantida quando nem todo nó os guarda é a pergunta que a era precisa responder antes de existir [29].

13. Riscos aceitos#

Consequências das regras que são aceitas tal como estão. Cada uma é limitada ou recai sobre uma parte que a escolheu; nenhuma permite a alguém tomar o valor nativo de terceiros.

1. Um contrato cujo sequenciador, admin e código capaz de trocar o sequenciador desapareceram, todos, só pode ser deixado pelo caminho forçado: lento e mais caro, mas vivo.
2. Com blocos vazios, ambas as taxas-base se estabilizam em 7, acima de seu piso de 1: abaixo de 8, o passo de descida arredonda para zero. Mover esse ponto de repouso exige uma mudança de parâmetro em uma fronteira de era.
3. Cerca de um bloco de sabotagem paga por taxas em um contrato disputado: os próprios certificados forçados do produtor colocados em torno do de um usuário, limitados pelos limites do usuário, e um certificado forçado por bloco fazendo o sequenciador reconstruir seu pipeline.
4. Um contrato aberto, com chave de sequenciador zero, é protegido apenas por seu código, e o autor de um certificado contra ele paga suas próprias omissões: o autor escolheu as leituras.
5. Um ativo não nativo creditado a um endereço de uso único por qualquer um que não seja o certificado que o queima fica congelado pela queima, que move apenas o saldo nativo e as células que esse certificado escreve. Conferir os saldos de ativos de um endereço antes de queimá-lo é uma regra de carteira, não uma regra de protocolo.
6. Um certificado que apenas movimenta deltas não avança o fence (§7); um fill construído antes dele que faz leitura exata de uma célula que ele moveu é omitido em um bloco posterior, cobrado do sequenciador. Um sequenciador evita isso não fazendo leitura exata de uma célula que seu contrato deixa qualquer um mover por delta.
7. Sabotagem residual contra o executor do caminho forçado: um atacante com muitos pagadores pode retransmitir intents abertos que nenhum certificado consegue carregar, como um cujo pagador não tem o suficiente para o pagamento. Uma chamada que apenas reverte ou viola seus limites não está entre eles: ela entra em sua forma falha e paga (§8). Cada intent impossível de carregar custa ao executor uma construção; a cópia é então despejada e posta em quarentena, e uma substituta sobre o mesmo pagador deve pagar estritamente mais.
8. Um cossignatário não trava nenhuma célula. Um fill conjunto que ele assinou ocupa um lugar em seu pipeline até que o fill seja carregado ou sua janela passe (§7). Um fill conjunto não carregado a tempo pode encontrar outros fills nessas células; o que entrar em segundo lugar no fold é omitido, cobrado de seu próprio depositante.
9. Em um contrato aberto, o certificado cujo endereço de depósito vem primeiro na ordenação vence uma corrida por leituras exatas, e endereços são baratos de gerar por força bruta; um contrato com estado exato disputado escolhe um sequenciador, cujo pipeline define a ordem.
10. Uma chamada simples no caminho exato de um contrato aberto declara a célula de sequenciador do contrato como zero exato. Se o contrato ganhar uma chave antes que o certificado entre, a leitura fica desatualizada e a chamada é omitida, cobrada de quem chamou; a carteira avisa antes de construir uma chamada assim.
11. A taxa de omissão é fixa, então, quando as taxas-base estão altas, uma omissão custa menos que uma aplicação; tentar várias variantes de um certificado é barato, e todo nó verifica cada uma delas.
12. Largura de banda e armazenamento em alta vazão são um problema em aberto declarado, não resolvido: os corpos são dados de cadeia, todo nó carrega todo byte, uma chamada de máquina carrega o código que executa, e o registro de gastos cresce uma entrada por gasto de uso único. O caminho está na §12.
13. Sob proof of stake (§11), a segurança da cadeia é a de um proof of stake convencional: custa o que custa reunir a maioria do peso do sorteio, delegações incluídas. A rampa começa no seu prazo final com o stake que existir, e o portão é o que impede a transição de se completar sem que um stake presente detenha um décimo da oferta; um décimo do stake, ausente, a pausa. A equivocação de uma pool custa apenas a própria caução dela, seja o que for que lhe esteja delegado; os delegadores escolhem sua pool sabendo disso. A reescrita de longo alcance com chaves cuja caução já foi retirada é impedida apenas pelos checkpoints fixados (§10), que um nó que entra aceita da sua release e não deriva da cadeia.

14. Conformidade#

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. O protocolo vive em um diretório spec/ publicado: os arquivos de parâmetros, o registro de ids de cadeia, os checkpoints fixados, as imagens da biblioteca pré-implantada e três corpora de vetores:

• vetores de fold: (pre-state, block) → (post-state | invalid, outcomes, fees); um vetor inválido registra a única regra que viola;
• vetores de derivação: (program, declared reads and writes, deposit) → (reads, writes, artifact, parallel gas), ou a regra que recusa o certificado antes de a máquina ser alcançada;
• vetores de dificuldade: (parameters, headers) → next target, com um veredito sobre um cabeçalho candidato; sob proof of stake, (stake set, seed, slot) → drawn key.

Os vetores são gerados, nunca editados à mão. A regeneração aciona o fold de referência, reproduz o resultado através dele e então reproduz o JSON consolidado através de um segundo fold, deliberadamente ingênuo, que não compartilha código com o primeiro; uma regeneração com a qual o segundo fold discorda falha. Uma regeneração que altera um vetor existente é uma mudança de consenso e é revisada como tal. Uma implementação está em conformidade quando reproduz o id da gênese e passa nos vetores; ela é então um par, não um fork.

15. Relação com a v1.0#

Este artigo substitui a v1.0 [0] por inteiro. Onde os dois divergem, este artigo é o protocolo e a v1.0 não deve ser lida em conjunto com ele. A tese não mudou: certificados autocertificados, um fold que nunca executa, acesso tipado ao estado e dois mercados de taxas. As mudanças abaixo foram encontradas ao implementar o projeto; cada uma removeu superfície de consenso e classes de erro.

16. Conclusão#

O Zycord 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 que apenas compara e soma; conflitos omitidos, precificados e cobrados da parte que os escolheu; concorrência declarada em vez de descoberta; aplicações confirmadas em milissegundos por sequenciadores confiáveis quanto à vivacidade e nunca quanto à segurança; um caminho forçado que mantém todo contrato alcançável; e um consenso que, uma vez distribuída a moeda, gasta sua computação em verificação em vez de hashes. A verificação escala horizontalmente com hardware que a rede não possui. A consolidação permanece sequencial, e quase gratuita.

Referências#

[0] The Simstoshi. Zycord: A Peer-to-Peer Network of Self-Certifying State Transitions, v1.0. 2026. Substituído por este artigo.
[1] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008.
[2] V. Buterin. Ethereum: A Next-Generation Smart Contract and Decentralized Application 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] J. Zahnentferner. Chimeric Ledgers: Translating and Unifying UTXO-based and Account-based Cryptocurrencies. IACR ePrint 2018/262.
[8] P. E. O'Neil. The Escrow Transactional Method. ACM TODS, 1986.
[9] M. Herlihy, E. Koskinen. Transactional Boosting: A Methodology for Highly-Concurrent Transactional Objects. PPoPP 2008.
[10] M. Shapiro et al. Conflict-free Replicated Data Types. SSS 2011.
[11] M. Corallo. BIP 152: Compact Block Relay. 2016.
[12] EIP-1559: Fee Market Change for the ETH 1.0 Chain. Ethereum Improvement Proposals, 2019.
[13] tevador et al. RandomX: Proof-of-Work Algorithm Optimized for General-Purpose CPUs. 2019.
[14] EIP-4844: Shard Blob Transactions. Ethereum Improvement Proposals, 2022.
[15] Monero: Dynamic Block Weight and Penalty. Documentação do Monero Research Lab.
[16] bitcoincashautist. CHIP-2023-04: Adaptive Blocksize Limit Algorithm for Bitcoin Cash. 2023.
[17] A. Kiayias, A. Russell, B. David, R. Oliynykov. Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol. CRYPTO 2017.
[18] B. David, P. Gaži, A. Kiayias, A. Russell. Ouroboros Praos: An Adaptively-Secure, Semi-Synchronous Proof-of-Stake Blockchain. EUROCRYPT 2018.
[19] Ethereum Foundation. Ethereum Consensus Specifications: The Beacon Chain (slashing de proponente, proposer slashings). 2020.
[20] L. Brünjes, A. Kiayias, E. Koutsoupias, A.-P. Stouka. Reward Sharing Schemes for Stake Pools. IEEE EuroS&P 2020.
[21] A. Yakovenko. Solana: A New Architecture for a High Performance Blockchain. 2017.
[22] Decred Documentation: Proof-of-Stake. docs.decred.org.
[23] Ethereum Foundation. The Merge. ethereum.org, 2022.
[24] M. M. T. Chakravarty, J. Chapman, K. MacKenzie, O. Melkonian, M. Peyton Jones, P. Wadler. The Extended UTXO Model. Financial Cryptography Workshops 2020.
[25] H. Kalodner, S. Goldfeder, X. Chen, S. M. Weinberg, E. W. Felten. Arbitrum: Scalable, Private Smart Contracts. USENIX Security 2018.
[26] V. Buterin. An Incomplete Guide to Rollups. 2021.
[27] A. Skidanov, I. Polosukhin. Nightshade: Near Protocol Sharding Design. 2019.
[28] G. Wood. Polkadot: Vision for a Heterogeneous Multi-Chain Framework. 2016.
[29] M. Al-Bassam, A. Sonnino, V. Buterin. Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities. 2018.
[30] D. Boneh, B. Bünz, B. Fisch. Batching Techniques for Accumulators with Applications to IOPs and Stateless Blockchains. CRYPTO 2019.
[31] S. Micali, M. Rabin, S. Vadhan. Verifiable Random Functions. FOCS 1999.

Zycord: lançamento, eras e parâmetros#

The Simstoshi
2026 — v2.0
GPG: E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29

Este documento é o complemento de Zycord: uma rede ponto a ponto de transições de estado autocertificadas, v2.0 ("o artigo"). O artigo define os mecanismos. Este documento expõe como a mainnet foi lançada, como a moeda é emitida, qual era ativa o quê e o valor de cada parâmetro. Ele substitui por inteiro as §13 e §14 do artigo v1.0; onde divergirem, este documento prevalece.

1. Lançamento#

Gênese da mainnet: 2026-10-07 00:00 UTC (1791331200), id de cadeia 1.

• Blocos a cada 30 segundos sob proof of work; a cada 5 segundos a partir da transição para proof of stake (§6). Proof of work: RandomX v2, minerável por CPU. Dificuldade: LWMA sobre uma janela de 90 blocos.
• O bloco 0 não contém nenhum certificado, nenhum endereço e nenhuma chave. Nenhuma moeda existe antes do bloco 0. A gênese é reproduzível a partir de fontes publicadas.
• Nenhuma rodada de investidores e nenhuma chave de admin. Nenhum caminho de código permite a qualquer chave pausar, atualizar, emitir, censurar ou reorganizar.

O compromisso de lançamento. O conjunto de parâmetros carrega um compromisso com uma mensagem de lançamento secreta. O bloco 1 deve abrir esse compromisso em seu cabeçalho, de modo que apenas o detentor da mensagem pode produzir o bloco 1, e ninguém mais pode acumular trabalho em uma cadeia que comece antes da gênese anunciada; a rampa de emissão faz com que qualquer vantagem inicial valha pouco. A partir do bloco 2, qualquer minerador pode construir.

Os ids de cadeia são registrados em um registro. O registro, com o id da gênese que cada rede ativa carrega, é embutido em todo binário e conferido na inicialização: o nó recusa um id aposentado, e um conjunto de parâmetros que daria a um id registrado uma gênese diferente. Um nó se recusa a iniciar com um motor de trabalho diferente daquele que a rede declara.

2. Emissão#

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

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

com E0 = 21 ZCD por bloco, Q = 1054 e tail = 0,33 ZCD por bloco, no intervalo de proof of work de 30 segundos. A taxa cai pela metade a cada dois anos, aproximadamente. Não há floats nem tabela. O bloco de gênese não paga coinbase. A cauda começa na época 4.376, por volta do ano 12, com 61.836.900,03 ZCD programados: os 62.744.838,47 a que o cronograma soma, menos a rampa de lançamento e o bloco de gênese. Esses números são o que quer que a recorrência produza; nenhum nó jamais computa uma forma fechada. Um ZCD equivale a 100.000.000 drops.

Um início lento. Os primeiros 86.400 blocos (30 dias) são uma rampa: o bloco h paga E(30) · h / 86,400, a taxa da época em que a rampa termina, arredondado para baixo, de modo que a recompensa sobe em linha reta de quase zero até o cronograma. O que a rampa retém, cerca de 907.917 ZCD, nunca é pago de volta.

A mudança de intervalo. A partir da transição para proof of stake (§6), a época tem 17.280 slots e o subsídio por bloco é E(n)/6, arredondado para baixo em drops; a recorrência não muda. O que um dia de slots completos paga é o mesmo sob os dois intervalos: 21 ZCD por bloco na curva da gênese equivalem a 3,5 por bloco de 5 segundos, e a cauda de 0,33 equivale a 0,055. A cauda começa na mesma época, 4.376. O arredondamento retém menos de um milésimo de ZCD por época e nunca é pago de volta.

A cauda paga quem quer que garanta a era corrente sem recrutar os mercados de taxas. Contra ela correm a queima da taxa-base dos dois mercados e a queima de todo certificado omitido (§9 do artigo), de modo que a emissão líquida é a cauda menos a queima e pode ser negativa sob carga. Como fração da oferta, a cauda tende a zero.

3. Divisão do subsídio#

Todo subsídio de bloco é dividido 94 / 3 / 3 por consenso desde o bloco 0. A divisão se aplica apenas ao subsídio, nunca às taxas, e de forma idêntica a todo bloco. Durante a rampa do proof of stake (§6), os 94% do produtor são eles próprios divididos entre o minerador e o staker sorteado, pela fração que a rampa tiver atingido.

Não há premine: a divisão é uma regra aplicada a todo bloco minerado, não uma alocação na gênese. Ao longo de seus três anos, a parcela do fundador soma menos de 2% da oferta anterior à cauda. Um produtor que estoura o teto flexível (§9 do artigo) perde apenas de sua própria parcela; as parcelas da tesouraria e do fundador são tomadas do subsídio não reduzido.

4. Tesouraria#

A célula da tesouraria é o saldo nativo do endereço de protocolo. Nenhuma chave gera um hash igual a ele, nenhum certificado pode debitá-la, e a gênese não nomeia nenhum quórum. Ela acumula desde o bloco 1, e esta versão não traz caminho de gasto algum. Um caminho de gasto é definido por uma atualização, não antes da altura 259.200 (por volta de 5 de janeiro de 2027), com signatários escolhidos pela comunidade e não pelo fundador. Até lá, a célula é um inteiro público que qualquer um pode auditar e ninguém pode tocar.

5. Gestão: os três primeiros anos (proposta)#

Situação. Esta seção é uma direção para revisão pela comunidade. Nada nela é regra de consenso até que a atualização da tesouraria de §4 fixe um conjunto de chaves, e os detalhes só são especificados depois que a direção for aceita.

O que a tesouraria recebe. Cerca de 533.000 ZCD no ano 1, 396.000 no ano 2 e 280.000 no ano 3: cerca de 1,21 milhão no total. A partir do ano 4, ela também recebe os 3% do fundador (§3), para cerca de 396.000 naquele ano ao todo. O que isso compra depende de um preço que ninguém conhece, e um mercado raso não consegue absorver vendas grandes, então o plano precisa funcionar na ponta baixa:

Todo valor abaixo é, portanto, uma parcela da entrada da tesouraria, nunca uma cifra em dólares ou em ZCD.

Cinco assentos. O assento é definido antes de seu ocupante. Cada assento tem um estatuto público: suas atribuições, suas entregas, como presta contas e quanto recebe. Qualquer um pode se candidatar. Quem ocupa o assento serve ao estatuto, como sob um contrato.

Decisões.

• Um gasto exige 3 de 5.
• Substituir um ocupante, rotacionar chaves, gastar a reserva ou emendar um estatuto exige 4 de 5, e fica público por 7 dias antes de entrar em vigor.
• Os mandatos duram um ano e são renováveis. As candidaturas ficam públicas por 30 dias. Os cinco primeiros ocupantes são o conjunto de chaves fixado pela atualização que os operadores de nós adotarem; um hard fork posterior pode fixá-lo novamente.

A remuneração é participação, não salário. A parcela de um assento acumula travada e é liberada a cada seis meses, mediante um relatório publicado e os votos de 3 dos outros 4 ocupantes. Nenhum ocupante vota a liberação de sua própria remuneração. O que não é liberado volta à reserva. A remuneração dos assentos é fixada pelos estatutos e não é definida por uma votação de gasto. Um teto por assento, medido a preço de mercado na data da liberação, envia qualquer excedente à reserva.

Orçamento, como parcelas da entrada.

A infraestrutura tem prioridade: nós, seeds, explorador e servidores de build custam hoje cerca de US$ 500 por mês. O reembolso é convertido ao preço de mercado no dia em que é pago. A parcela cobre esse custo a cerca de US$ 0,06 por ZCD no ano 1, US$ 0,08 no ano 2 e US$ 0,11 no ano 3; abaixo disso, o déficit é transportado adiante sem juros e pago quando a parcela permitir.

O fundador. Os 3% do subsídio do fundador (§3) recompensam o trabalho feito até o lançamento e nele. Eles são separados do assento de desenvolvedor líder, que é remunerado como qualquer outro assento pelo trabalho contínuo. O fundador detém uma chave de cinco e não vota a liberação da remuneração desse assento.

O que o consenso impõe. Uma vez que a atualização entre: o gasto 3 de 5 e a rotação 4 de 5 com seu prazo. Todo o resto desta seção é uma norma. O que impõe uma norma é que todo gasto é um certificado comum, público e contabilizável apenas a partir da cadeia.

Em aberto. O teto por assento. A forma jurídica sob a qual o representante público assina. Se a trava de seis meses será imposta por um contrato de escrow da biblioteca padrão quando a máquina estiver ativa.

6. Eras#

As eras são constantes de altura compiladas nas versões públicas. Um bloco abaixo de um portão que carrega um programa que o portão habilita é inválido, e essa conferência de altura é a única coisa que separa as eras, exceto a rampa e a transição da era 2, que são disparadas por estado dentro de limites de altura. Uma nova era pode adicionar regras e tipos de registro; ela nunca muda o que um bloco existente significa abaixo de sua altura de ativação.

As Eras 2 e S saem cada uma como uma release própria por hard fork, com uma especificação, uma devnet adversarial e revisão. A era 2 abre o bonding por altura, inicia sua rampa por stake com um prazo final, e faz a transição quando a rampa se completa: o mais cedo que a transição pode ocorrer é a época 303 (mês 10), e o prazo final para o início garante que a rampa esteja em andamento até o fim do mês 9. Para o limiar de 10%, o stake é o stake ativo com suas delegações e a oferta é a moeda emitida, ambos na abertura da época. O portão pode pausar a transição para além da época 363; o que ele não pode fazer é impedir que ela comece.

Stake. A caução mínima é de 1.000 ZCD, e um stake participa uma época depois de ser caucionado. Uma caução que apenas delega tem um mínimo menor, fixado pela release da era, e nunca sai da custódia do delegador. O mínimo está em ZCD e não em dólares porque nenhuma regra consegue ler um preço; ele é revisado nas fronteiras de era à medida que o teto de bloco cresce.

A era 0 é deliberadamente minúscula e a era 1 é reduzida ao que o projeto precisa: sem chaves de admin, não há botão de pausa, então toda linha de consenso é uma linha que pode matar a rede sem remédio. Código de consenso inalcançável é código de consenso inauditável e não é lançado. Uma era que não prove valer sua complexidade nunca é acionada.

A transição é tratável porque o fold é agnóstico quanto a quem ordena: a era 2 muda de quem é a assinatura no cabeçalho.

Portão da era 1. O bloco do portão escreve as constantes compiladas da era em células de protocolo, de modo que a raiz de estado se compromete com elas a partir de então. Nos primeiros 240 blocos após o portão, um certificado que executa SETSEQ deve carregar um TTL de pelo menos 240 blocos após o portão e esperar que ele entre no intervalo.

A era 2 e as alturas que medem tempo. Depois da transição, a altura avança seis vezes mais rápido. Toda constante da gênese que na verdade é uma duração (o fim da parcela do fundador, a maturidade do coinbase, o TTL máximo, a janela do intent, a profundidade de desfazer, a janela do tempo mediano, a duração de uma entrada de diretório) é lida pela era 2 na unidade que ela mede: a altura 3.153.600 corresponde a 1.095 épocas de 2.880, e a era encerra a parcela do fundador na época 1.095. A tabela de parâmetros da gênese não muda, porque a raiz de consenso percorre todo parâmetro e mover um deles moveria o id da gênese de toda rede ativa; as constantes da era são compiladas, como as da era 1.

7. Parâmetros#

O conjunto de parâmetros é congelado na gênese, embutido em todo binário em tempo de compilação e mutável apenas por hard fork. Sua raiz de consenso entra em toda assinatura. zcd params imprime os valores compilados de um build; zcd genesis imprime a rede, o id de cadeia, o hash de parâmetros, o id da gênese e a raiz de estado.

As constantes da era 1 são compiladas, não parâmetros, porque a raiz de consenso percorre todo parâmetro e adicionar um moveria o id da gênese de toda rede ativa.

As constantes da era 2 são compiladas pelo mesmo motivo.