Desenvolvedores

Rand é de código aberto. O full node, o explorador, a bridge, a pesquisa de provas e os clientes de carteira vivem, cada um, em seu próprio repositório no GitHub. Leia o código, execute os testes, envie patches. Esta página é o mapa: onde cada componente mora, com o que é construído, até onde o sistema de provas avançou e onde ele para hoje.

Repositórios

A pilha

Rust de ponta a ponta. A Rand é uma chain própria: um nó HotStuff BFT com uma camada de gossip libp2p, um pool de notas totalmente blindado como livro-razão, assinaturas e cifragem de notas pós-quânticas, e o zkVM da Rand para computação confidencial, tudo no repositório fullnode. O sistema de provas em si é a parte sob pesquisa ativa, abaixo.

Uma relação para todos os programas

A relação universal de execução do whitepaper, R_exec, existe como código: rand_zkvm, uma máquina RV32IM provada sob um único STARK em lote sobre Plonky3, no corpo Goldilocks. Ela prova que algum traço executou o programa hc até estas saídas públicas, sobre entradas comprometidas por um H_IN com sal, e nada sobre o programa jamais é parâmetro do verificador. Publicar um programa confidencial significa registrar um hash, nunca gerar um circuito sob medida.

O sistema de provas é transparente, sem trusted setup e sem curva de emparelhamento, e sua hipótese é uma função de hash resistente a colisões. Espera-se que todo outro componente que toque provas convirja para este crate, em vez de criar o seu. O crate vive em zkp-circuits/research e é incorporado ao fullnode no conjunto de restrições 8 (circuits aeacf31, fullnode v0.6.7 e v0.6.8). As tabelas e medições abaixo descrevem o conjunto de restrições 5 (marco M4.2), a menos que uma linha cite um conjunto posterior; foram extraídas de docs/zkvm.md, docs/zkvm-milestones.md e docs/confidential.md do fullnode, em 2026-09-13, e as medições são citadas como medidas em um laptop Apple Silicon, não como metas.

Oito tabelas em barramentos nomeados, uma nona sob demanda

Um compromisso, uma abertura FRI. As tabelas nunca chamam umas às outras; elas trocam fatos por barramentos LogUp nomeados (PROGRAM, PROGRAM_WORD, MEMORY, ALU, POSEIDON2, INPUT_DIGEST, INPUT_READ, KECCAK e as consultas de intervalo e de nibble) e o verificador confere que todo barramento fecha globalmente. O grau máximo de restrição de cada tabela é fixado por um teste abaixo do limite de 8 que o blowup do FRI permite.

Três conjuntos de restrições chegaram desde então. O conjunto 6 acrescentou uma tabela public obrigatória para a entrada pública de um programa definida no deploy, ligada ao digest sem sal H_PUB, e uma tabela opcional sha256 ao lado de keccak. O conjunto 7 (chain 16) cega todo terminal LogUp em um novo barramento BLIND e fixa um piso de 2⁷ linhas em toda tabela declarada, e acrescenta a syscall POSEIDON2_LEN, limitada por comprimento. O conjunto 8 (chain 18) acrescenta uma coluna GAS à tabela cpu e um valor público, o GAS_LIMIT declarado.

O que uma prova revela

Público: o hash de código hc (oito palavras de digest no circuito), o compromisso de entrada com sal H_IN (oito palavras), o tier de gas e oito palavras de saída. Desde o conjunto de restrições 6, também H_PUB, o digest da entrada pública, e desde o conjunto de restrições 8 o limite de gas declarado. O cabeçalho da prova declara as alturas das tabelas Keccak e SHA-256, então mostra se uma chamada fez hashing e, acima do piso de 2⁷, aproximadamente quanto.

Oculto: as entradas privadas (H_IN tem sal, então é ocultante além de vinculante); toda palavra de instrução, porque o verificador confere hc e nunca o programa; todo valor de registrador e de memória; todo desvio tomado; a contagem exata de ciclos e o gas exato usado; e quais syscalls rodaram, exceto pelo que as alturas das duas tabelas de hash mostram.

O tier é público em cada prova porque o tamanho de um STARK já revela a altura do seu traço; ocultar o índice não traria nada. hc é vinculante, não ocultante: veja onde ele para hoje.

Medido, no conjunto de restrições 5

Laptop Apple Silicon, build de release. A divisão em tabelas de bytes do M2.3 foi o que moveu o tempo de prova; o perfil de 80 consultas foi o que fez o tamanho da prova subir de novo. A chave do verificador independe do conteúdo do programa, sendo indexada pelo tier e pelas alturas de programa, entrada e keccak declaradas na prova, de modo que um nó aquece uma chave e a reutiliza.

Esses conjuntos posteriores mudaram os tamanhos. Sob o conjunto de restrições 7, uma prova de tier 10 tem 1.367.688 bytes no perfil de produção, e uma prova de tier 10 que carrega Keccak, 3.283.898 (medido em 2026-09-28). Desde a chain 17, uma transferência carrega duas provas: a prova do bundle de tier 14, de cerca de 1,49 MB, e a prova de autorização de tier 10, de cerca de 1,37 MB e cerca de 7 s para provar. O genesis da chain 20 define um bloco de 20 MiB e um limite de 4 MiB para a prova, e uma chamada não pode exceder o tier 14.

Três alvos, um circuito

Somente RISC-V executa nativamente. Programas Solidity e Solana ou rodam em um guest interpretador dentro da mesma relação, com o seu bytecode como entrada, ou são traduzidos fora da chain em programas RISC-V cujas saídas são idênticas às do interpretador, palavra por palavra. Os opcodes caros pedem tabelas de coprocessador dedicadas, em vez de simulação bit a bit.

Marcos

O marco 1 provou a máquina de uso geral. O marco 3 a transformou em um pool blindado: uma transferência com pertinência dentro do circuito é provada sob R_exec, e o verificador confere hc sem nunca ver uma palavra do programa. O marco 4 é compatibilidade: seu carregador, o compromisso de entrada e a tabela Keccak foram entregues como os conjuntos de restrições 4 e 5, e a tabela SHA-256 com o conjunto 6. Os guests interpretadores de EVM e sBPF, a toolchain rand-guest e os dois tradutores estão construídos. A transferência ERC-20 foi provada, em uma máquina de 128 GB; a prova do SPL Token, no tier 20, não. O marco 5 é a VM de recursão por trás da agregação de blocos, que está construída e desligada em todas as chains. Os conjuntos de restrições 7 e 8 vieram após as revisões de setembro e o modelo de gas.

Fases do pool blindado

O ledger do fullnode chegou em três fases, cada uma um hard fork (docs/shielded.md §7). A S1 substituiu o ledger de contas por um pool de notas; a S3 trouxe a bridge de volta como notas e foi entregue primeiro; a S2 colocou o staking por cima. As três estão na main e na chain atual.

As linhas abaixo de S2 são o trabalho da v0.5. Cada linha é um hard fork. Foram reunidas numa única chain nova, a chain 14, criada em 2026-09-20 a partir do build b3c594c e marcada como v0.5 no mesmo dia, depois de uma viagem de ida e volta de zUSD ao vivo pelos endpoints de origem implantados. A chain 15, ativa desde 2026-09-26 na v0.5.8 e posteriores, levou tudo isso, com as correções das auditorias v4 e v5 condicionadas ao genesis ativadas: um faucet com lista de permissões e orçamento por época, ativação de bond com atraso, um limite para o peso de stake, registros vinculados ao genesis, consensus_domain 1, as regras de bridge v2 e o limite do registro de tokens, taxa de registro queimada e limite de 2⁶³ para notas. A chain 20, ativa desde 2026-10-01 06:17 UTC na v0.6.8 (c9c9bd3c), um hard fork da chain 19, mantém tudo isso e acrescenta o trabalho das versões v0.6, listado abaixo.

Versões desde a v0.5

Toda versão é uma tag do git com uma entrada no CHANGELOG.md do fullnode. Uma versão que altera o consenso, o formato de wire ou uma chave do verifier sai com uma nova chain; as demais entram na chain ativa um nó por vez.

Onde para hoje

Desvios em relação ao whitepaper, declarados em vez de suavizados. Cada um é acompanhado na documentação do próprio crate, com o marco que o encerra.

• hc é vinculante, mas não ocultante: não carrega salt, de modo que um programa adivinhado pode ser confirmado e duas implantações do mesmo programa podem ser associadas. O que o M3.4 eliminou foi o verificador manter o programa inteiro em claro.
• Uma carteira compilada antes de 2026-09-21 pede testemunhas ao seu nó, e o pedido de testemunha nomeia a folha que está prestes a ser gasta. Um rand atual mantém a própria cópia da árvore e nunca pede; o nó ainda atende rand_getWitness para as carteiras mais antigas.
• Os depósitos são públicos na fronteira: uma emissão do faucet, uma nota da gênese e um depósito pela bridge carregam o valor em claro (desde a cadeia 14, uma emissão e uma nota da gênese também carregam a sua abertura, de modo que a chave do proprietário também é pública), a mesma visibilidade de um salto que um depósito de transparente para blindado tem em qualquer lugar.
• O conhecimento zero é estatístico, não perfeito. Essa é a propriedade que o FRI com hiding do Plonky3 0.7 de fato oferece, e o crate o declara.
• O hash da transcrição é Poseidon2 com constantes de rodada de desenvolvimento, não o SHA3-384 / BLAKE3-384 dos papers. Uma troca de configuração, não uma reescrita.
• Com 80 consultas FRI, uma prova de bundle tinha cerca de 1,42 MB nas cadeias 14 e 15 (cerca de 1,3 MB até a cadeia 13). Desde a cadeia 17, uma transferência carrega cerca de 2,85 MB de prova: a prova do bundle, com cerca de 1,49 MB, e a prova de autorização, com cerca de 1,37 MB. Em uma cadeia padrão, com blocos de 4 MiB e um teto de prova de 2 MiB, uma prova que contém Keccak excede o teto de prova de imediato; a gênese da cadeia 20 define blocos de 20 MiB e um teto de prova de 4 MiB (as cadeias 13 a 16 definem 8 MiB).
• O cabeçalho de uma prova de chamada não é ocultado. Ele declara o nível e as alturas das tabelas de Keccak e de SHA-256, e portanto mostra se a chamada fez hash. Chamadas confirmadas na cadeia 15 antes do piso do provador da v0.6 expuseram mais: uma tabela privada com menos de 2⁷ linhas podia ser lida a partir da prova. O piso do provador da v0.6 encerrou isso para as novas chamadas, e o conjunto de restrições 7 com hardening_v6 o tornou uma regra da cadeia a partir da cadeia 16.
• Uma chamada é limitada ao nível 14, com no máximo 2¹² linhas de Keccak (128 permutações) e 2¹³ linhas de SHA-256 (128 compressões), e, sob hardening_v6, um programa com mais de 8.180 palavras não pode ser implantado. Os guests interpretadores de EVM e sBPF e as imagens traduzidas de ERC-20 e SPL Token estão todos acima desse limite.
• Quem detém a testemunha vê tudo. O ZK protege a visão do verificador, não a do provador. Desde a cadeia 17, uma carteira pode entregar a prova do bundle a um rand-prover pareado sem entregar a chave de gasto, mas esse provador ainda detém a chave de visualização e vê as notas. O backend CUDA rodou pela primeira vez em hardware em 2026-09-28 e ainda não tem medição em produção.

Estrutura do repositório

O workspace Cargo do fullnode, como disposto em seu README e em seu diretório crates/.

Especificado, ainda não entregue

Estes componentes são descritos nos papers ou na documentação do fullnode, mas não estão em execução: ou estão ausentes dos repositórios, ou foram construídos e não estão ativados em nenhuma cadeia. Eles são listados para que a distância entre a especificação e o código seja legível, e não inferida.

Compilar e testar

Fluxo de trabalho padrão em Rust em cada repositório. O fullnode é um único workspace do Cargo com uma toolchain fixada e uma suíte de testes de cluster que inicia nós reais sobre TCP. Sua compilação exige o repositório de circuitos (circuits) clonado ao lado, em um diretório chamado circuits, no commit a partir do qual as crates vendorizadas foram sincronizadas (aeacf31 para v0.6.7 e v0.6.8). A zkVM é uma crate independente em zkp-circuits, com sua própria toolchain fixada e uma demonstração que narra o que uma chamada confidencial revela e o que não revela.

O fullnode:

git clone https://github.com/randprotocol/fullnode.git
git clone https://github.com/randprotocol/zkp-circuits.git circuits   # the sibling directory must be named circuits
git -C circuits checkout "$(sed -n 's/^circuits: //p' fullnode/crates/randprotocol-zkvm/guests-compiled/PROVENANCE.md)"
cd fullnode

# Rust 1.98.1 is pinned by rust-toolchain.toml; first build pulls RocksDB and Plonky3, 10 to 20 minutes
cargo build --release        # target/release/rand-node, target/release/rand, target/release/rand-prover

# All crates; release because STARK proving is slow in debug. One to two hours, mostly proving
cargo test --release

# One machine, two validators
scripts/local-testnet.sh
target/release/rand --rpc http://127.0.0.1:8545 status

A zkVM de pesquisa, em zkp-circuits/research:

# Toolchain is pinned by rust-toolchain.toml; the first build pulls Plonky3
cargo build --release

# Narrated demo: thirteen proofs, one at production FRI parameters (~6-7 min)
cargo run --release

# Emulator, per-table constraints, cheating provers, ZK, end-to-end, viewing keys, compiled guests (395 tests, ~17 min)
cargo test

A suíte do fullnode, medida na v0.6.1 em uma máquina de 16 vCPUs: core com 521 testes, node com 373, client com 117, a suíte do prover trapaceiro com 116, as trapaças de bundles ocultos com 21 (75 min), o fluxo da carteira com 6 (53 min), o cluster com 26 (44 min) e o portão de ponta a ponta da zUSD com 2 (51 min). As provas de produção da VM de recursão ficam fora dela e exigem a memória listada acima.

Running a node explica como ingressar na testnet pública com a compilação; o genesis da testnet, os peers de bootstrap e os scripts de execução acompanham o diretório deploy/ do fullnode, e a página de download traz a versão resumida.

Contribute

O fullnode é licenciado sob a GNU General Public License v3.0 (GPL-3.0-only); antes, era Apache-2.0. Abra issues para bugs e propostas de design no repositório que a mudança afeta. Pull requests são bem-vindos: execute cargo fmt && cargo clippy antes de enviar e mantenha as mudanças restritas ao escopo. As issues do fullnode são o lugar para começar.

A arquitetura, o circuito de privacidade, a prova do token de taxa e o compromisso (tradeoff) pós-quântico estão todos documentados no whitepaper, na página de papers. O diretório docs/ do próprio repositório do fullnode é a fonte com a qual todas as páginas desta documentação são conferidas.