Como funciona a zkVM

Leia esta página para entender a máquina por trás de cada prova na Rand: o que ela prova, como a execução de um programa se transforma em algo que um validador consegue verificar em milissegundos e de onde vem a privacidade. Para saber o que uma prova custa e como a carteira a produz, veja Provas. Para os parâmetros e as construções de hash, veja Criptografia. Para o conjunto de instruções contra o qual um programa é escrito, veja A ISA RISC-V.

A única afirmação que toda prova faz

A zkVM prova um único tipo de afirmação, para todo programa que a cadeia executa:

Um programa cujo digest é hc, iniciado em base_pc, executado sobre uma entrada privada comprometida por H_IN e um segmento de entrada pública comprometido por H_PUB, terminou em até 2ᵗ − 1 ciclos, gastou no máximo GAS_LIMIT de gas e escreveu estas oito palavras de saída.

Uma transferência blindada é essa afirmação sobre um único programa fixo, o guest do pacote de ativos ocultos, cujo hc está fixado no arquivo de gênese como hc_bundle. Desde a chain 17, ela é feita duas vezes por transferência: uma segunda prova, pequena, sobre o guest de autenticação (hc_auth no arquivo de gênese) mostra que o remetente possui a chave de gasto (Provas). Uma chamada confidencial é a mesma afirmação sobre um programa implantado. Há uma só máquina, um só verificador e um só conjunto de restrições para todos eles. Implantar um programa é, portanto, uma operação de dados (armazenar suas palavras e seu hc), não uma operação criptográfica: não existe circuito por programa nem trusted setup.

O sistema de provas é um STARK construído com Plonky3. Ele precisa apenas de uma função de hash: não há cerimônia de configuração nem curvas elípticas, de modo que não há nada que o algoritmo de Shor possa quebrar.

O pipeline

 secret input ──► run the program ──► execution trace ──► polynomials ──► commit ──► FRI ──► proof
 (keys,           (RV32IM emulator)   (nine tables,      (one per       (8× code,   (80 queries,
  notes, paths)                        one row per step)  column)        Merkle)     20-bit grinding)

 every validator:  recompute the challenges from the Merkle roots, open 80 random positions,
                   check the rules there  →  ≈ 16 ms

A linha superior roda uma vez, na máquina do remetente, em cerca de 100 segundos para um pacote e cerca de 7 segundos para a prova de autorização que o acompanha. A linha inferior roda em cada validador, a partir apenas dos campos públicos e da prova.

1. Execute o programa e registre tudo

A máquina é um processador RISC-V de 32 bits: RV32IM menos FENCE, as instruções CSR e EBREAK (A ISA RISC-V). O provador primeiro executa o programa em um emulador e registra uma linha por ciclo de clock. Esse registro é o rastro de execução. Quem o tivesse em mãos poderia reproduzir a execução passo a passo; o restante do esquema existe para que um verificador possa se convencer de que o rastro está correto sem possuí-lo.

Um programa se comunica com o exterior por meio de oito chamadas de sistema e nada mais:

Compromissos de nota, nulificadores e caminhos de Merkle não estão embutidos na máquina. São código guest comum, que monta na memória uma mensagem marcada por domínio e chama POSEIDON2. Essa chamada não faz padding, portanto [a] e [a, 0] geram o mesmo hash. Os guests distribuídos a chamam apenas com mensagens de comprimento fixo. Um programa novo que calcula o hash de dados de comprimento variável usa POSEIDON2_LEN (A ISA RISC-V).

Não existe abortar

O processador não tem nenhuma instrução que se recuse a terminar, então um programa não pode parar quando uma verificação falha. O guest do pacote registra a falha em vez disso: cada verificação que falha aplica um OR com 1 a um registrador chamado bad, e bad é a última palavra incluída no hash do digest de saída:

D = H(64; anchor, nf₀..₃, cm₀..₃, fee, burn_a, burn_r, burn_asset, time, c, bad)

c é o compromisso de autorização que a prova de autenticação também publica (desde a chain 17; o digest das chains 14 a 16 não tinha c).

A cadeia nunca recebe do remetente a pré-imagem de D. Ela reconstrói a pré-imagem a partir dos campos públicos da transação, define bad = 0 por conta própria, calcula o hash e compara. Um trapaceiro pode produzir uma prova perfeitamente válida de uma execução em que uma verificação falhou, mas essa execução imprimiu H(…, 1), e a cadeia procura H(…, 0). Fazê-los coincidir exigiria uma colisão de hash.

2. Divida o rastro em nove tabelas

Uma única tabela descrevendo um processador inteiro seria desnecessariamente larga, então o rastro é dividido em tabelas especializadas, provadas juntas como um único lote:

Mais duas tabelas, keccak e sha256, estão presentes apenas em uma prova cujo programa as chamou, cada uma com no mínimo 2⁷ linhas quando presente; o guest do pacote não usa nenhuma das duas. O piso de 2⁷ linhas em toda tabela declarada veio com o conjunto de restrições 7 (seção 9).

O nível t é um entre 10, 12, 14, 16, 18 ou 20 e dimensiona as tabelas. Todo pacote é provado no nível 14: uma tabela de CPU de 16.384 linhas, das quais o guest usa cerca de 12.400. O guest de autenticação executa 250 ciclos no nível 10. O restante é padding, de modo que uma prova revela de qual nível um programa precisou, nunca quantos passos ele executou dentro dele (Níveis).

A tabela de memória é o que torna a RAM verificável. Como ela é ordenada por endereço e depois por tempo, “uma leitura retorna o último valor escrito naquele endereço” passa a ser uma regra entre duas linhas adjacentes.

3. Conecte as tabelas com barramentos

Como o verificador sabe que a soma usada pela CPU é a soma calculada pela ALU? Por meio de barramentos. Quando a CPU precisa de uma adição, ela envia uma mensagem (op, a, b, c); a ALU recebe uma mensagem para cada linha que calcula. A máquina tem dezessete barramentos:

Os barramentos são verificados com um argumento de derivada logarítmica (LogUp). Depois que as tabelas são comprometidas, sorteia-se um valor aleatório α, e cada tabela mantém uma soma acumulada de ±1/(α − m) sobre as mensagens que envia ou recebe. As somas se cancelam exatamente se, e somente se, toda mensagem enviada foi recebida, o mesmo multiconjunto nos dois lados. Uma única mensagem forjada deixa um resíduo que um α aleatório expõe com probabilidade esmagadora. O barramento de memória usa um parente próximo, uma verificação de permutação de multiconjuntos.

Cada tabela publica o valor final de sua soma acumulada, seu terminal, e o verificador confere que os terminais somam zero. Até o conjunto de restrições 6, um terminal era uma função verificável do conteúdo de sua tabela. Desde o conjunto de restrições 7, toda tabela carrega cinco colunas extras e, em sua primeira linha, envia um valor aleatório e recebe o de sua vizinha no barramento BLIND. Cada terminal se desloca por um elemento uniforme do corpo de desafios, e a soma continua sendo zero.

Os barramentos de digest e de leitura são deliberadamente pares separados. O LogUp equilibra por mensagem, não por consumidor, de modo que um barramento compartilhado permitiria a um provador omitir uma palavra do digest enquanto uma leitura dessa palavra ainda tivesse sucesso.

4. Ancore o rastro ao mundo exterior

Trinta e cinco valores públicos saem do rastro, todos na tabela da CPU:

Como hc é calculado no circuito, uma prova sobre um programa diferente não pode passar por uma prova sobre o guest do bundle. O verificador nunca vê uma palavra de instrução; ele compara hc com o digest que espera. Como H_IN tem salt, ele vincula a entrada privada sem revelá-la, mesmo a quem pudesse adivinhá-la. Como H_PUB não tem salt, o verificador pode recalculá-lo a partir de palavras que já tem. Para um bundle, essas palavras são o vínculo da transação (transaction binding), blake3("rand-tx-bind-1" ‖ chain_id ‖ tx) sobre a transação com os bytes da prova zerados, de modo que uma prova copiada para uma transação com outro destino, memo, envelope ou chain id não é verificada. Na chain 20 (genesis binding_domain: 1) ele é blake3("rand-tx-bind-2" ‖ genesis_hash ‖ chain_id ‖ tx), de modo que uma prova não é verificada em outra chain, mesmo sob o mesmo chain id; as palavras são uma entrada pública, então isso não mudou nada no circuito. A prova de autorização é feita sobre as mesmas oito palavras. Uma prova de chamada na chain 20 é vinculada da mesma forma: seu segmento são as palavras públicas do programa definidas na implantação, seguidas de oito palavras de um vínculo de chamada (rand-call-bind-2, rand-call-bind-1 antes da chain 20), de modo que uma prova de chamada copiada para outro bundle de taxas não é verificada.

O gas é a medida que a máquina faz do peso de uma execução, presente no circuito desde o conjunto de restrições 8. A tabela da CPU tem uma coluna GAS que começa em 1 e soma 1 a cada linha, 3 em uma linha de absorção do Poseidon2, 64 em uma linha SHA256 e 192 em uma linha KECCAK. Na linha HALT, o circuito prova GAS ≤ GAS_LIMIT por meio de quatro limbs da diferença com verificação de intervalo, que nunca são abertos: o limite é público e o gas que uma execução gastou não é. O verificador recusa, antes de construir uma chave, um limite acima do que o próprio cabeçalho da prova poderia exigir:

gas_max(t, k, s) = (2ᵗ − 1) + 2ᵗ⁻² + 191·(2ᵏ / 32) + 63·(2ˢ / 64)

com k e s as alturas logarítmicas declaradas das tabelas keccak e sha256, cada termo igual a zero para uma tabela ausente. O teto de um cabeçalho do tier 10 sem hashes é 1.279, e o de um do tier 14 é 20.479. A chain cobra uma chamada pelo limite que ela declara (Taxas).

5. Transformar as regras em identidades polinomiais

Cada coluna é uma lista de números no corpo Goldilocks, inteiros módulo p = 2⁶⁴ − 2³² + 1. Uma lista de n números é o mesmo que um polinômio de grau menor que n: aquele que passa por eles quando estão dispostos em um subgrupo {1, ω, ω², …} do corpo. O Goldilocks tem subgrupos assim de todo tamanho que seja potência de dois até 2³², de modo que a conversão é uma transformada rápida de Fourier.

Uma regra da máquina passa então a ser uma equação entre polinômios de coluna. “O contador de programa avança quatro, a menos que a instrução salte” torna-se, esquematicamente:

is_jump(x)·(pc(ωx) − target(x)) + (1 − is_jump(x))·(pc(ωx) − pc(x) − 4) = 0

para todo x no subgrupo, em que pc(ωx) significa “a próxima linha”. O conjunto completo dessas regras de uma tabela é sua AIR (representação algébrica intermediária). As regras da CPU e da ALU chegam ao grau 8; as demais ficam entre 2 e 4.

Um polinômio que é zero em todos os pontos do subgrupo é divisível por Z(x) = xⁿ − 1. O provador combina todas as regras, com pesos aleatórios, em um único polinômio C(x) e divide por Z(x). Se todas as regras valem em todas as linhas, o quociente é um genuíno polinômio de grau baixo. Se uma regra falha em uma linha, ele não é. “Todos os passos de uma execução de 16.000 ciclos estavam corretos?” tornou-se “esta função está próxima de um polinômio de grau baixo?”, e essa pergunta pode ser respondida olhando alguns valores escolhidos ao acaso.

6. Comprometer-se antes de conhecer as perguntas

O provador deve fixar seus polinômios antes de ver as perguntas aleatórias do verificador, ou poderia adaptar suas respostas. Ele avalia cada coluna em um domínio oito vezes maior que a tabela (blow-up 8, taxa de código 1/8) e publica uma raiz de Merkle sobre as avaliações. Essa redundância é um código de Reed–Solomon: um polinômio de grau baixo é determinado por qualquer oitava parte de seus valores, de modo que um trapaceiro que altere até uma única linha do trace precisa alterar a maior parte da palavra de código estendida para continuar consistente, e as verificações pontuais aleatórias vão cair sobre o dano.

As árvores de Merkle usam Poseidon2 sobre Goldilocks: largura 8, S-box x⁷, 4 rodadas completas, 22 rodadas parciais e 4 rodadas completas, com digests de quatro elementos do corpo (cerca de 256 bits). Cada folha é calculada com quatro elementos de aleatoriedade nova, de modo que uma raiz não revela nada sobre os valores abaixo dela. A mesma permutação é o compromisso de nota e o hash do nullifier dentro da máquina. Suas 86 constantes de rodada são uma tabela literal no código-fonte do nó (poseidon2_constants.rs), de modo que nenhuma atualização de biblioteca pode alterá-las.

7. Verificação pontual com FRI

O verificador agora tem raízes de Merkle. Primeiro ele amarra o quociente ao trace: escolhe um ponto aleatório z fora do domínio da tabela, pede o valor de cada coluna e o do quociente ali, e verifica C(z) = Q(z)·Z(z) diretamente. Resta confirmar que as funções comprometidas são de fato polinômios de grau baixo, e é isso que o FRI testa.

O FRI funciona por dobragem (folding). Divide-se um polinômio em partes par e ímpar, f(x) = fₑ(x²) + x·fₒ(x²). Para um β aleatório vindo do verificador, f′(y) = fₑ(y) + β·fₒ(y) tem metade do grau em um domínio de metade do tamanho. O provador se compromete com f′, recebe um novo β e dobra de novo (o Rand dobra em até oito por rodada) até restar uma constante, que ele envia às claras. Uma consulta (query) escolhe então uma posição aleatória na primeira camada e a acompanha até o fim, verificando em cada camada que os valores abertos acima se dobram no valor abaixo. Uma função que estava longe de ter grau baixo não consegue manter todas essas promessas consistentes.

O Rand executa 80 consultas. Sob o teorema de lacunas de proximidade (proximity gaps) demonstrado, cada consulta deixa ao trapaceiro no máximo 9/16 de chance, de modo que 80 consultas dão (9/16)⁸⁰ ≈ 2⁻⁶⁶·⁴. Sob a conjectura ethSTARK, na qual se apoiam os STARKs em produção, cada consulta deixa 1/8, o que é muito menor.

8. Remover a conversa

Tudo o que foi dito acima foi descrito como um diálogo, mas uma transação precisa ser uma única mensagem que qualquer validador possa verificar sozinho. A transformação Fiat–Shamir elimina o verificador: o provador calcula cada desafio “aleatório” como um hash de tudo o que foi comprometido até então, com uma esponja duplex Poseidon2. Alterar qualquer compromisso altera todos os desafios seguintes, de modo que o provador não pode escolher compromissos que sirvam aos desafios.

Duas medidas adicionais fecham as brechas que isso deixa:

• Corpo de extensão. Um corpo de 2⁶⁴ elementos é pequeno demais para sortear desafios: um trapaceiro precisa que um desafio caia em um dos poucos valores ruins de um polinômio, e tem sucesso com probabilidade de cerca de N/2⁶⁴, por mais consultas que se façam. Assim, o trace permanece em Goldilocks, mas cada desafio é sorteado em sua extensão quadrática, com cerca de 2¹²⁸ elementos.
• Grinding. Antes de derivar as posições das consultas, o provador deve encontrar um nonce cujo hash com a transcrição comece com 20 bits zero, cerca de um milhão de hashes. Um provador honesto paga isso uma vez. Um trapaceiro que sorteia de novo as posições das consultas até que errem sua falsificação paga isso a cada tentativa. Esta é a única prova de trabalho em todo o Rand, e não tem nada a ver com o consenso.

Somando: 66,4 bits das consultas mais 20 do grinding dão 86 bits demonstrados, e cerca de 100 bits sob a conjectura, em que o termo do corpo de extensão é o limite.

9. De onde vem o conhecimento zero

Um STARK não é de conhecimento zero por si só: os valores abertos nas posições das consultas são valores dos polinômios do trace e, sem cuidado, vazam informação. A configuração do Rand acrescenta quatro camadas:

1. cada polinômio comprometido é randomizado (o FRI com ocultação do Plonky3 mistura quatro palavras de código aleatórias), de modo que os 80 valores abertos podem ser reproduzidos, em distribuição, por alguém que nunca viu o trace;
2. cada folha de Merkle recebe salt, de modo que raízes e caminhos de autenticação não revelam nada;
3. a aleatoriedade do provador é sorteada do zero no sistema operacional para cada prova, de modo que duas provas do mesmo pagamento parecem não ter relação;
4. toda tabela declarada tem pelo menos 2⁷ linhas e todo terminal LogUp é cegado (conjunto de restrições 7). Uma prova abre cada tabela em 80 pontos de consulta e dois pontos fora do domínio, e o compromisso com ocultação mistura tantas linhas aleatórias quantas a tabela tem, de modo que uma tabela só fica oculta enquanto tiver pelo menos 82 linhas. 128 é a menor potência de dois que satisfaz isso.

A Camada 4 é uma correção. A revisão de 2026-09-27 recuperou, a partir de provas de produção, as entradas privadas de chamadas com 31 palavras de entrada ou menos, leu as contagens de busca de um programa em sua tabela de programa curta e distinguiu os slots de entrada reais de um bundle de seus slots fictícios pelos terminais não ofuscados. Essas provas são as geradas na chain 15 e anteriores. A chain 16 (conjunto de restrições 7, com o guest de bundle sem ramificações) corrigiu os três problemas, e as chains 18 a 20 mantêm as correções.

A garantia é conhecimento zero estatístico no modelo de oráculo aleatório. O que uma prova não oculta é exato: seu tier, as alturas de tabela declaradas e seus valores públicos, entre eles o limite de gás. Uma altura declarada de keccak ou sha256 igual a 0 significa que a execução nunca usou esse hash; assim, o cabeçalho da prova de uma chamada mostra se a chamada fez hash e, acima do piso, quantas vezes, com precisão de um fator de dois. Para um bundle, os valores e campos públicos são a âncora, quatro anuladores, quatro compromissos, a taxa, as queimas, o ativo queimado, o tempo, o compromisso de autorização e o vínculo da transação. O ativo que uma transferência move é uma entrada privada, de modo que um pagamento em zUSD e um pagamento em RAND têm a mesma aparência na chain. hc é determinístico, portanto qualquer pessoa pode saber que uma prova diz respeito ao guest de bundle (toda prova que move valor diz) ou, no caso de uma chamada, qual programa implantado ela executou.

10. O que um validador verifica

Machine::verify_public(hc, words, proof) executa, do mais barato ao mais caro:

1. o tier declarado pela prova e as alturas de tabela declaradas estão dentro dos limites (check_declared_heights) antes que qualquer coisa seja dimensionada a partir deles, de modo que um cabeçalho malformado custa algumas comparações, e não uma construção de chave de vários segundos; um bundle deve declarar o tier 14 sem nenhuma das tabelas de hash, e uma prova de autorização, o tier 10;
2. há 35 valores públicos, cada um um elemento de campo canônico, com pv[HC] = hc, pv[TIER] igual ao tier da prova, toda palavra de saída abaixo de 2³² e GAS_LIMIT no máximo igual ao gas_max do cabeçalho;
3. o STARK em lote é verificado com uma chave de verificador em cache por formato (tier, program, input, keccak, sha256, public heights), e não por programa;
4. H_PUB é igual ao resumo de words, que, para um bundle, é o vínculo da transação que o próprio nó calculou.

Antes de tudo isso, o nó examina toda prova submetida ou propagada por gossip quanto a uma codificação canônica: seu cronograma de dobramento FRI deve ser o que um provador honesto produz para os graus que o cabeçalho declara. Desde o fullnode v0.6.8 (audit v6, ZKV-4), o exame recusa primeiro qualquer grau declarado acima de 25 bits (MAX_HONEST_DEGREE_BITS, o teto de 2²⁴ da tabela de memória mais a duplicação de conhecimento zero, o máximo que uma prova aceita carrega). Antes desse limite, um cabeçalho que declarasse um grau enorme fazia o nó rederivar um cronograma de dobramento gigantesco em seu loop de eventos, mantendo-o ocupado pelo tempo que o remetente quisesse; o verificador recusaria a prova de qualquer maneira, de modo que o limite muda apenas o custo de dizer não. Um pânico dentro do exame agora recusa essa única transação, em vez de parar o nó.

Em seguida, o ledger recalcula o resumo do bundle D com bad = 0 e o compara com as oito palavras de saída da prova. Na chain 20, ele também exige que o GAS_LIMIT de uma prova de bundle seja exatamente o bundle_gas_limit do genesis, 20.479, e o de uma prova de autorização, 1.279, de modo que toda transferência declare os mesmos valores. Com a chave já em cache, a verificação completa leva cerca de 16 ms.

Os parâmetros e por que foram escolhidos

Todo número abaixo é consenso: o verificador o confere, uma prova feita com qualquer outro valor não é verificada, e alterar um deles é um novo conjunto de restrições e um hard fork (Conjuntos de restrições). O perfil FRI é fixado pelo arquivo genesis (fri_profile: production na chain 20), nunca pela prova.

O que esses números somam: 86 bits de segurança provados, cerca de 100 sob a conjectura ethSTARK (em que o limite é o corpo de extensão, não as consultas) e cerca de 85 bits contra um adversário quântico, definidos pelo hash de transcrição de 256 bits. O whitepaper mantém as duas cifras de segurança lado a lado de propósito: todo FRI-STARK implantado depende da conjectura para os seus últimos bits, e quem dimensiona uma implantação deve saber qual hipótese sustenta quais bits.

Provas sobre provas

Com cerca de 1,50 MB, uma prova de bundle é pesada, a prova de autorização de 1,37 MB viaja ao lado dela, e todo nó armazena todas elas. O remédio que está construído é a recursão: uma prova cujo enunciado é “verifiquei estas provas”. O fullnode traz uma segunda máquina, menor, para isso, a recursion VM, cuja palavra nativa é um elemento de Goldilocks e cujas instruções são as próprias operações do verifier (aritmética de corpo, Poseidon2, passos de Merkle e de FRI). O seu programa de agregação reexecuta a verificação completa de N provas de bundle e publica um digest sobre os valores públicas delas, vinculado à chain, ao aggregator e a um nonce. Verificar uma prova de bundle dentro dela custou 1.968.619 linhas sob o conjunto de restrições 6 e 2.044.506 sob o conjunto de restrições 7; não foi medido de novo sob o conjunto 8. Está implementada e desligada pelo genesis em todas as chains até agora, inclusive a chain 20. O programa de agregação verifica apenas provas de bundle, de modo que, numa chain de autorização dividida, a prova de autorização permaneceria. Suas provas de produção também exigem mais memória do que o planejado: medidas sob o conjunto de restrições 7, 133 GB ou mais (Em breve: agregação de blocos).

O que o esquema não afirma

• A margem quântica é de cerca de 85 bits, não 128. A busca quântica de colisões sobre um hash de n bits custa cerca de 2ⁿ/³. O desenho do whitepaper prevê um hash de transcrição de 384 bits; a cadeia em operação usa o digest Poseidon2 de 256 bits. Ampliá-lo exige um novo conjunto de restrições e um hard fork.
• 100 bits é uma conjectura; 86 é provado. Elevar o valor provado para 100 custaria 97 consultas, cerca de um quinto a mais de dados de consulta por prova.
• As constantes do Poseidon2 são um sorteio com semente, não uma instanciação publicada. Não se conhece nenhum ataque a isso; adotar um conjunto padrão alteraria todos os hashes da cadeia.
• Algumas afirmações são verificadas ao lado da prova, não dentro dela. O valor público TIER é comparado com a forma da prova pelo verifier, mas não é restringido pelo circuito (auditoria ZL1), e a disciplina de taint do bundle guest se apoia em argumento estrutural, em um harness de guest enfraquecido e em mutation fuzzing, e não em verificação mecanizada.
• O cabeçalho de uma prova não é ocultado. O tier e as alturas das duas tabelas de hash ficam às claras, de modo que uma prova de chamada mostra se a chamada usou KECCAK ou SHA256. Existe uma opção do prover que preenche as duas tabelas, e nenhuma carteira a ativa: ela leva uma prova de tier 10 de cerca de 1,3 MB para cerca de 3,6 MB.
• A syscall POSEIDON2 não é injetiva sobre entradas de comprimento variável. Ela é mantida como está porque todo compromisso, nullifier, raiz e digest de programa depende dela. Nenhum guest distribuído usa ainda POSEIDON2_LEN.
• A geração de provas é lenta e feita pelo remetente, ou por um prover com quem o remetente se associa: cerca de 100 s e 5,7 GB em uma CPU de notebook para um bundle. Os kernels de GPU rodaram pela primeira vez em uma GPU (uma NVIDIA H100) em 2026-09-28 e coincidiram com a referência em CPU; a carteira ainda gera provas na CPU.

Onde ler mais

• A seção “The Zero-Knowledge Scheme: How a Rand Proof Works” do whitepaper (randprotocol.tex) percorre os mesmos sete ingredientes com os teoremas de solidez.
• O paper de implementação (randprotocol_implementation.tex) especifica o conjunto de instruções e as syscalls, o bundle guest, a esponja e os digests, cada tabela e barramento, a configuração da máquina e a VM de recursão.
• O código: crates/randprotocol-zkvm/src/ no fullnode — emulator.rs, tables/, machine.rs, gas.rs, guests.rs, hash.rs, poseidon2_constants.rs.