Esta página registra a justificativa de cada decisão de projeto relevante na Rand: a propriedade que um componente deve fornecer, a hipótese sob a qual a fornece e o custo aceito em troca. Foi compilada em 29 de setembro de 2026 a partir deste site, do resumo do whitepaper e do full node de referência (github.com/randprotocol/fullnode: seu README, docs/ e docs/superpowers/specs/). Cada resposta cita o documento em que a justificativa é enunciada; os caminhos referem-se ao repositório fullnode, salvo quando começam por randprotocol.org.
Situação. A Rand opera em uma testnet mantida pela equipe fundadora, e o protocolo não foi auditado de forma independente. Várias das decisões abaixo são implementadas em etapas, ao longo dos cortes de chain. Todos os valores são medições do nó em execução no momento da compilação; é esperado que mudem e devem ser medidos novamente antes de serem citados.
Primitivas criptográficas
1. Por que ML-KEM-768 (Kyber) para a criptografia das notas?
O texto claro de uma nota é cifrado para o destinatário em um envelope que permanece indefinidamente no ledger público. Sua confidencialidade é, portanto, uma propriedade irrevogável (pergunta 8): um adversário que obtenha, em qualquer momento posterior, um computador quântico criptograficamente relevante poderia decifrar todos os envelopes históricos selados sob um KEM de curva elíptica, uma vez que o algoritmo de Shor resolve o logaritmo discreto em tempo polinomial. O ML-KEM é padronizado no NIST FIPS 203 e sua segurança se reduz ao Module-LWE, para o qual não se conhece nenhum algoritmo quântico eficiente. O conjunto de parâmetros 768 (categoria 3 do NIST) foi escolhido como o equilíbrio entre margem de segurança e a chave de encapsulamento de 1.184 bytes que todo endereço precisa carregar. O envelope é ML-KEM-768 combinado com ChaCha20-Poly1305: 1.348 bytes, ou 1.860 bytes com o campo de memo fixo.
Fonte: randprotocol.org (seção pós-quântica); README do fullnode; docs/shielded.md §2
2. Por que compromissos Poseidon2 em vez de Pedersen?
Os compromissos de Pedersen são perfeitamente ocultantes, mas apenas computacionalmente vinculantes, e sua vinculação se reduz à hipótese do logaritmo discreto, que um adversário quântico quebra; um adversário capaz de calcular logaritmos discretos pode abrir um compromisso para um valor diferente. Como um compromisso publicado hoje deve permanecer sólido e ocultante durante toda a vida do ledger, o esquema precisa se apoiar em hipóteses que se acredita valerem contra adversários quânticos, o que na prática significa uma função de hash. O Poseidon2 é um hash orientado à aritmetização, definido sobre o corpo Goldilocks, de modo que avaliá-lo dentro da STARK custa poucas restrições. O mesmo hash instancia o compromisso da nota, a árvore de Merkle de profundidade 32 e o anulador.
Fonte: randprotocol.org (seção pós-quântica); docs/shielded.md §1–2
3. Por que duas funções de hash — BLAKE3 e Poseidon2?
As duas funções são otimizadas para modelos de custo diferentes. O Poseidon2 é usado sempre que um hash deve ser avaliado dentro de uma prova — notas, árvore de compromissos, anuladores e tabelas internas da zkVM — porque seu custo é medido em restrições. O BLAKE3 é usado sempre que não há prova envolvida e a vazão nativa predomina: hashes de blocos, a raiz de estado sobre a árvore, o conjunto de anuladores, o registro de validadores e a tabela de programas, e os endereços de validadores (o digest BLAKE3 da chave pública). O Poseidon2 é comparativamente lento em uma CPU; o BLAKE3 é comparativamente caro de aritmetizar. Cada um é usado apenas onde seu modelo de custo se aplica.
Fonte: README do fullnode (linha de assinaturas / hashes); docs/architecture.md
4. Por que Dilithium2 (ML-DSA) para as assinaturas dos validadores?
As assinaturas de consenso fornecem uma propriedade renovável (pergunta 8): uma quebra posterior do esquema permite forjar mensagens futuras, mas não invalida retroativamente blocos já finalizados, de modo que o esquema poderia, em princípio, ser substituído antes que exista um adversário quântico. Ainda assim, adotou-se um esquema baseado em reticulados desde o gênese, para que os votos de consenso, as cossignaturas dos guardiões da ponte e o registro de validadores compartilhem um único tipo de chave pós-quântica. O nó implementa o conjunto de parâmetros Dilithium2 da rodada 3 (o crate crystals-dilithium), que difere do ML-DSA-44 final do FIPS 204; as chaves públicas têm 1.312 bytes e as assinaturas, 2.420 bytes.
Fonte: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §2; randprotocol.org
5. Por que uma STARK transparente (FRI sobre Goldilocks) em vez de uma SNARK?
A escolha decorre de três requisitos. Primeiro, ausência de configuração confiável: a solidez se apoia apenas na resistência a colisões de uma função de hash, e não em uma cadeia de referência estruturada ou em uma curva compatível com emparelhamentos. Segundo, solidez pós-quântica plausível: o argumento não faz nenhuma hipótese de logaritmo discreto nem de emparelhamento. Terceiro, compatibilidade com o esquema de compromisso baseado em hash da pergunta 2. O custo é o tamanho da prova: a prova de um bundle tem aproximadamente 1,3 MB, de 300 a 600 vezes o tamanho de uma transação blindada da Zcash ou da Monero. Esse custo foi aceito e é tratado separadamente pela agregação em nível de bloco (perguntas 31 e 34).
Fonte: randprotocol.org; docs/block-space.md §1; docs/zkvm.md
6. Por que o perfil FRI de 80 consultas em vez de 27?
O perfil de produção (80 consultas, fator de expansão 8, 20 bits de proof-of-work de grinding) fornece aproximadamente 86 bits de solidez demonstrável, contra aproximadamente 42 bits do perfil de 27 consultas, com 2,75 vezes o tamanho da prova. O tempo de verificação quase não muda: 809 ms passando a 838 ms a frio, e aproximadamente 16 ms a quente. Deu-se prioridade à solidez demonstrável sobre o tamanho da prova, e o custo de tamanho foi transferido para o projeto de espaço de bloco e de agregação.
Fonte: docs/block-space.md §1, §3
7. Por que a afirmação pós-quântica é feita por primitiva, e não como ‘128 bits em todo o protocolo’?
Rascunhos anteriores afirmavam segurança pós-quântica de 128 bits para o protocolo como um todo. Essa afirmação é incompatível com o limite de Brassard–Høyer–Tapp, segundo o qual um adversário quântico encontra colisões em um hash de 256 bits em cerca de 2^85 consultas; por isso foi retirada, em vez de qualificada. O artigo agora enuncia a segurança por primitiva e por papel — um hash de transcrição de 384 bits, hashes de 256 bits usados apenas onde se exige resistência a pré-imagem, Dilithium2, ML-KEM-768 e FRI sobre um corpo de extensão — sob as hipóteses Module-LWE e Module-SIS, com as funções de hash modeladas como oráculos aleatórios quânticos. O hash de transcrição do nó é atualmente o Poseidon2; a documentação lista isso como uma lacuna de configuração em aberto.
Fonte: randprotocol.org (seção pós-quântica)
8. O que é a classificação ‘irrevogável versus renovável’ e por que ela orienta as escolhas?
Uma propriedade de segurança é irrevogável se um adversário que adquira uma nova capacidade em qualquer momento futuro pode violá-la retroativamente para dados já publicados; a confidencialidade das notas e o caráter ocultante dos compromissos são dessa espécie, de modo que devem ser resistentes a ataques quânticos no momento da publicação. Uma propriedade é renovável se é restabelecida a cada uso, de modo que o esquema pode ser substituído antes que a ameaça se concretize; as assinaturas e a solidez das provas são dessa espécie. Cada escolha de primitiva nesta seção decorre da classificação da propriedade que ela protege.
Fonte: randprotocol.org (seção pós-quântica)
O pool blindado
9. Por que um modelo de notas/UTXO, sem contas nem saldos?
Um ledger baseado em contas publica saldos por construção; ocultá-los exige cifrar o estado e provar afirmações sobre os textos cifrados, o que é substancialmente mais caro. Um pool de notas armazena apenas compromissos e anuladores, nenhum dos quais revela um proprietário ou um valor, de modo que o estado público não contém informação de saldo. A única exceção é o registro de validadores, cujos pesos de stake precisam ser públicos para que as réplicas concordem sobre a composição do quórum (pergunta 29).
Fonte: docs/shielded.md §1–2; docs/staking.md §1
10. Por que o endereço tem ~1,6 KB?
Um endereço blindado consiste no campo de proprietário pk, de 32 bytes, e na chave de encapsulamento ML-KEM-768 de 1.184 bytes de que o remetente precisa para selar o envelope; codificado em base58, isso dá aproximadamente 1.667 caracteres. O comprimento é consequência direta do KEM pós-quântico. Um projeto aprovado (endereços blindados curtos, 2026-09-17) substitui o endereço por um identificador de destinatário de cerca de 256 bits, que resolve para um registro atualizável, assinado com a chave de gasto e servido pelo explorador, de modo que a chave de encapsulamento seja obtida em vez de transcrita.
Fonte: docs/shielded.md §1; docs/superpowers/specs/2026-09-17-short-shielded-address.md
11. Por que toda chave é derivada de uma única chave de gasto de 256 bits?
Todo o restante do material de chaves é função determinística de um único segredo sk: a chave de visualização nk = H(NK, sk), o campo de proprietário pk = H(PK, nk), o anulador H(NF, nk, cm), a chave de visualização de saída e a chave de decapsulamento ML-KEM, cada uma sob seu próprio separador de domínio. O arquivo de chave armazena, portanto, apenas sk, um backup é um único valor, e reescanear a árvore a partir da folha 0 recupera todas as notas. Como não há uma segunda cópia da qual recuperar, a carteira se recusa a sobrescrever um arquivo de chave existente.
Fonte: docs/shielded.md §1
12. Por que um formato fixo de bundle 4-in-4-out?
Um formato fixo faz com que todo bundle tenha o mesmo tamanho e a mesma estrutura, independentemente do que movimenta. Cada bundle publica exatamente quatro anuladores e quatro compromissos; os espaços não usados são notas fictícias de valor zero, e a saída de troco é publicada mesmo quando seu valor é zero, pois a ausência dessa saída distinguiria a transação. A especificação original era 2-in-2-out, seguindo o Sapling. Foi ampliada para 4-in-4-out com o bundle de ativo oculto, de modo que os espaços 0–1 carreguem um ativo privado e os espaços 2–3 carreguem RAND para a taxa; quatro espaços em vez de três permitem que uma transferência de token financie sua taxa com até duas notas RAND.
Fonte: docs/shielded.md §2; docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §3
13. Por que uma única prova movimenta qualquer ativo (RAND, zUSD, tokens RPL)?
Antes da chain 14, uma transferência de token carregava dois bundles, um para a taxa em RAND e outro para o ativo. Isso exigia duas provas e revelava a qualquer observador qual token havia sido movimentado. O guest de ativo oculto recebe o identificador do ativo como entrada privada, de modo que uma transferência de zUSD é indistinguível de um pagamento em RAND. O guest cabe no tier 14 (aproximadamente 100 s e 5,7 GB de memória) apenas porque lê suas entradas em um laço e funde a verificação de pertinência na árvore de Merkle. Uma implementação totalmente desenrolada exige o tier 16 (aproximadamente 400 s e 21 GB), o que excede a memória de uma máquina de 16 GB.
Fonte: docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §1–3
14. Por que a taxa é pública e paga ao proponente?
Uma taxa pública é coerente com o registro público de stake e torna a admissão barata: um nó pode verificar o piso da taxa antes de realizar qualquer verificação. A prova do bundle impõe a equação de balanço Σ entradas = Σ saídas + taxa + queima, de modo que a taxa é paga a partir de notas ocultas sem revelar quais notas. O custo aceito é que o valor da taxa pode revelar a classe da transação (transferência ou chamada de programa).
Fonte: docs/superpowers/specs/2026-09-11-shielded-pool-design.md (tabela de decisões); docs/fees.md §1
15. Por que os depósitos (mint, bridge attest) têm um valor público?
O valor que entra no pool deve ser contabilizado publicamente, e a atestação da bridge é a evidência pública de que ocorreu um bloqueio correspondente na chain de origem. A visibilidade resultante se limita à etapa de entrada, análoga a uma transação transparente-para-protegida (t-to-z) no Zcash. Os gastos subsequentes da nota depositada permanecem ocultos.
Fonte: docs/superpowers/specs/2026-09-11-shielded-pool-design.md; docs/shielded.md (tabela do que é público)
16. Por que o memo é um campo fixo de 512 bytes?
Um campo de comprimento fixo garante que o ledger não revele se há um memo nem qual é o seu tamanho: em uma chain com memo habilitado, todo envelope que cria uma nota, incluindo dummies e troco, tem exatamente 1.860 bytes. O memo é carregado somente dentro do envelope cifrado, nunca na nota, no compromisso ou na prova, e é legível exatamente pelas partes que já conseguem decifrar a nota. Um memo malformado é decodificado como um memo vazio, para que não possa tornar a própria nota irrecuperável.
Fonte: docs/shielded.md §2; docs/superpowers/specs/2026-09-26-address-sharing-and-memo-design.md
17. Por que a geração de provas é local, e como o provador delegado não quebra isso?
A própria prova é a autorização de gasto: um bundle não carrega assinatura nem campo de remetente, de modo que a chave de gasto nunca precisa sair da carteira. Uma prova de bundle no tier 14 exige aproximadamente 5,7 GB de memória, o que excede o que telefones e navegadores conseguem oferecer; daí o provador delegado. A autorização dividida (bundle guest v3, parâmetro de genesis hc_auth) separa os dois papéis: o provador recebe apenas a chave de visualização nk e produz a prova do bundle, enquanto a carteira produz uma pequena prova de autorização no tier 10 usando sk. Um provador, portanto, consegue construir uma prova de bundle, mas não consegue autorizar um gasto (pergunta 36).
Fonte: docs/prover.md §1; docs/shielded.md (autorização dividida); docs/superpowers/specs/2026-09-28-delegated-proving-design.md
18. Por que uma janela de âncora de 256 blocos?
Uma prova é construída contra uma raiz específica da árvore de compromissos (sua âncora), e construir uma prova de bundle no tier 14 leva aproximadamente 100 s. O ledger precisa, portanto, aceitar âncoras que tenham vários minutos de idade no momento do envio. A janela era de 64 blocos na especificação original e foi ampliada para 256 blocos à medida que o intervalo entre blocos diminuiu, mantendo sua duração em tempo real acima do tempo de geração da prova.
Fonte: docs/shielded.md; docs/superpowers/specs/2026-09-11-shielded-pool-design.md
O zkVM e a computação confidencial
19. Por que RV32I como ISA do guest (e não RV64)?
Uma palavra de 32 bits se decompõe em exatamente quatro limbs de byte, e o primo Goldilocks p = 2^64 − 2^32 + 1 é grande o bastante para que o produto de dois valores de 32 bits nunca estoure o corpo. O RV64 dobraria o número de colunas de limbs nas tabelas da ALU e da memória. O RISC-V é também um alvo existente dos compiladores mais usados, de modo que os programas guest são binários compilados comuns, e não programas escritos em uma linguagem criada para esse fim.
Fonte: docs/zkvm.md §2; research/docs/01-isa.md (‘Why RV32, not RV64’)
20. Por que Goldilocks e não um corpo de 256 bits?
Goldilocks é um primo de 64 bits cuja aritmética se mapeia de forma eficiente em instruções nativas de CPU de 64 bits, e cujo grupo multiplicativo possui um grande subgrupo de ordem potência de dois, como o FRI exige. Em conjunto com palavras de 32 bits, isso mantém estreita cada linha do trace, o que torna viável a geração de provas no perfil de produção em um laptop. A solidez perdida ao trabalhar sobre um corpo pequeno é recuperada sorteando os desafios do FRI em um corpo de extensão.
Fonte: docs/zkvm.md §2; randprotocol.org (seção de desempenho)
21. Por que tiers de gas em vez de medição de gas por opcode?
O gas por opcode existe no Ethereum porque todo nó reexecuta toda transação e a duração da execução não é limitada de antemão. Na Rand nenhum nó executa um programa: o remetente o executa uma única vez, fora da chain, e os nós verificam um único STARK cujo custo de verificação depende apenas do tier, e não da computação realizada. A terminação é imposta pelo tier, já que uma execução que não termina em 2^t ciclos não admite prova no tier t. O preço é um piso fixo mais uma estimativa de gas limitada pelo cabeçalho, e a capacidade do bloco é um orçamento em bytes. O gas aparece apenas dentro dos guests interpretadores de EVM e sBPF, como estado privado, onde é necessário para reproduzir a semântica da chain de origem.
Fonte: docs/fees.md §3–4; docs/superpowers/specs/2026-09-28-gas-model-design.md
22. Por que o trace é dividido em nove tabelas unidas por barramentos LogUp?
Uma única tabela monolítica preencheria cada linha até a largura da operação mais larga. Separar o trace em nove tabelas (CPU, memória, ALU, range, nibble, Poseidon2, programa, entrada e pública), cada uma preenchida apenas até a sua própria altura, mantém o trace total pequeno. Os argumentos LogUp estabelecem as relações de multiconjunto entre as tabelas. As tabelas de Keccak e SHA-256 são opcionais e só são incluídas quando o guest invoca a chamada de sistema correspondente.
Fonte: docs/zkvm.md §5
23. Por que uma chamada de programa publica apenas oito palavras de saída?
Uma chamada de programa é uma prova de que um código público foi executado corretamente sobre entradas privadas; o ledger registra apenas o recibo. Oito palavras de 32 bits bastam para vincular um resultado, um compromisso ou uma decisão, e um tamanho de saída fixo garante que a forma do recibo nada revele sobre o programa. No momento, as saídas são somente dados: um programa não consegue, por si só, transferir valor.
Fonte: randprotocol.org/usecases (nota sobre a plataforma); docs/confidential.md
24. Por que existe um envelope de entrada de chamada?
Quem faz a chamada e conserva as entradas privadas pode demonstrar, mais tarde, sobre o que a chamada foi computada. O envelope de entrada de chamada torna isso durável ao armazenar as entradas, cifradas, junto com a chamada, onde um auditor designado pode decifrá-las com uma chave. Isso estende a divulgação seletiva (confidencial para o mercado, aberta a um regulador designado) dos pagamentos para a execução de programas.
Fonte: docs/confidential.md (‘Call input envelopes’)
25. Por que uma mudança no conjunto de restrições é um hard fork?
Todo nó reverifica toda prova durante a sincronização, e uma prova só é válida com relação ao conjunto de restrições (AIR) sob o qual foi produzida. Uma mudança na AIR altera, portanto, o conjunto de chains válidas, e é introduzida em um corte de genesis, e não adotada nó a nó.
Fonte: docs/architecture.md (‘Why a constraint-set change is a hard fork’)
26. Por que o emulador é a referência, e não a AIR?
O emulador é a especificação legível da máquina, e a AIR é uma codificação dessa especificação como restrições polinomiais. Onde os dois divergem, a AIR é, por definição, a que está em erro. Isso coloca a definição normativa no artefato mais prático para auditoria por pessoas.
Fonte: docs/zkvm.md §5
Consenso e o nó
27. Por que HotStuff BFT encadeado?
O HotStuff encadeado oferece finalidade determinística: com quóruns ponderados por stake de mais de dois terços, um bloco é final quando três certificados de quórum consecutivos foram formados sobre ele, e um bloco final nunca é reorganizado. O intervalo medido entre blocos é de 1,2 s e o tempo até a finalidade, de aproximadamente 3,6 s. Os usuários institucionais visados exigem uma finalidade de liquidação sobre a qual possam registrar lançamentos contábeis, o que uma chain com finalidade probabilística não oferece.
Fonte: README do fullnode; randprotocol.org (seção de desempenho); docs/architecture.md §6
28. Por que a verificação de provas fica fora do laço de consenso?
Um nó verifica cada STARK quando admite a transação (aproximadamente 32 ms com cache aquecido), antes de retransmiti-la, de modo que a verificação nunca fica no caminho crítico da proposta de blocos. O intervalo entre blocos é, portanto, determinado pela latência do consenso, e não pelo tamanho da prova. As verificações são ordenadas por custo, com o STARK verificado por último, para que uma transação malformada seja rejeitada antes da etapa mais cara.
Fonte: randprotocol.org; docs/architecture.md (‘How it works’)
29. Por que o registro de validadores é público se todo o resto é protegido?
Todas as réplicas devem concordar sobre quais validadores podem propor e quais votos constituem um quórum, o que exige que os pesos de stake sejam públicos. O registro mantém, portanto, os valores de stake em claro. O vínculo com a titularidade permanece oculto: um bond é financiado a partir de uma nota protegida e um saque é pago a uma, e nenhuma das operações revela de quem é a nota.
Fonte: docs/staking.md §1
30. Por que um nó em sincronização reexecuta cada bloco em vez de confiar nos certificados?
Um nó que entra tardiamente verifica cada certificado de quórum, reverifica cada bundle e cada prova de chamada, e compara os recibos resultantes antes de aceitar a cadeia. Como a validade é estabelecida pelas provas, e não apenas por assinaturas, este procedimento não está exposto aos ataques de longo alcance (long-range) que afetam cadeias protegidas somente por assinaturas. Podar as provas do histórico foi rejeitado, pois eliminaria essa garantia.
Fonte: docs/architecture.md; docs/aggregation.md (introdução)
31. Por que manter o limite de bloco em 4 MiB quando uma prova ultrapassa 1 MB?
Com um limite fixo, o tamanho do bloco não pode crescer; quando a demanda excede a capacidade, o que se limita é a vazão (a três transferências blindadas por bloco no perfil de 80 consultas). Considerou-se que um limite de vazão é um modo de falha mais seguro do que o crescimento ilimitado do bloco. O remédio escolhido é a agregação em nível de bloco, uma prova recursiva por bloco, em vez de elevar o limite ou reduzir o nível de solidez.
Fonte: docs/block-space.md §1, §6
32. Por que a testnet poda o histórico para um dia?
Um certificado de quórum com 18 assinaturas Dilithium2 ocupa aproximadamente 44 KB e é armazenado duas vezes por bloco. Com blocos majoritariamente vazios a cada 1,4 s, isso resultava em aproximadamente 6,6 GB por nó por dia; os discos dos nós se encheram e a cadeia perdeu o quórum na altura 248.953. Os full nodes da testnet agora retêm um dia de histórico, um único nó de arquivo retém todo ele, e os nós da mainnet o reterão por completo. O estado do ledger — a árvore, o conjunto de nullifiers, o registro e os programas — nunca é podado.
Fonte: docs/superpowers/specs/2026-09-24-history-pruning-design.md
33. Por que libp2p?
O nó usa TCP com Noise e Yamux, gossipsub para transações e votos, Kademlia com uma lista de bootstrap para descoberta de pares, mDNS em redes locais e request-response para a sincronização de blocos. São componentes padronizados e amplamente implantados, de modo que o nó herda pontuação de pares, reconexão e atualizações de transporte, em vez de manter implementações próprias.
Fonte: README do fullnode (linha de rede)
Mercado de provas e agregação
34. Por que agregação de provas em nível de bloco?
O espaço em bloco cresce linearmente com o número de bundles se cada um carrega sua própria prova de aproximadamente 1,3 MB. Um único STARK recursivo por bloco, que verifica todas as N provas de bundle, mantém o custo da prova on-chain constante em N. Os validadores então verificam uma única prova agregada (aproximadamente 16 ms a quente) em uma CPU, de modo que hardware comum ainda pode validar, enquanto agregadores com GPUs competem em um mercado separado e sem permissão pela parcela de provas das taxas e por um subsídio de bloco.
Fonte: docs/aggregation.md §1
35. Por que três papéis — validador, agregador, provador delegado?
Os três papéis têm requisitos de hardware distintos e são remunerados por partes diferentes. Um validador ordena e verifica transações em uma CPU e é pago com a parcela de verificação das taxas. Um agregador produz a prova recursiva do bloco em uma GPU e é pago com a parcela de provas e com o subsídio. Um provador delegado produz uma única prova de bundle para um remetente cujo dispositivo não consegue fazê-lo (um telefone ou navegador) e é pago de forma privada por esse remetente. Separar os papéis mantém a validação barata e torna a geração de provas competitiva.
Fonte: docs/prover.md §1
36. Por que um provador delegado não pode roubar fundos?
Sob autorização dividida, o provador recebe a chave de visualização nk, mas não a chave de gasto sk. A prova do bundle se compromete com c = H(AUTH, nk || salt), e a prova de autorização separada da carteira demonstra o conhecimento de sk para o mesmo c. Sem sk, o provador consegue calcular a prova do bundle, mas não consegue produzir uma autorização válida, e a carteira verifica a prova devolvida antes de submetê-la.
Fonte: docs/shielded.md (autorização dividida); docs/prover.md §8
A bridge e o zUSD
37. Por que bloquear USDT/USDC em suas cadeias de origem em vez de emitir uma nova stablecoin?
A emissão nativa na Rand tornaria a capacidade de reservas dependente das decisões de implantação dos emissores, que estão fora do controle do projeto. Bloquear USDT e USDC em Ethereum, BSC, Tron e Solana obtém reservas das cadeias em que esses ativos já circulam e não introduz nenhum novo emissor: cada unidade de zUSD é um direito sobre USDT ou USDC mantidos em um contrato de custódia legível publicamente.
Fonte: randprotocol.org (seção de reservas)
38. Por que um conjunto de guardiões t-de-n, e por que dizê-lo abertamente?
A atestação é a única evidência de que a Rand dispõe de que um bloqueio ocorreu em outra cadeia; por isso, ela deve ser assinada por um grupo com limiar (threshold); uma atestação válida exige assinaturas de mais de dois terços dos guardiões. A suposição de confiança resultante é declarada explicitamente. A garantia efetiva é a menor entre a solvência das reservas e a integridade da bridge; uma coalizão de t guardiões pode autorizar a cunhagem sem o bloqueio correspondente; e a exposição é limitada pela custódia mantida em cada cadeia. Essa suposição foi, originalmente, o argumento contra a construção de uma bridge. Ela não é retirada, mas aceita em troca de capacidade de reservas.
Fonte: randprotocol.org (seção de reservas, ‘O que isso custa’)
39. Por que uma coassinatura Dilithium2 ao lado da atestação ECDSA?
As cadeias de origem não oferecem verificador de assinaturas baseadas em reticulados, de modo que as liberações nessas cadeias permanecem protegidas por ECDSA clássico, com exposição limitada pela custódia e por tetos. Toda mensagem que o ledger da Rand aceita dos guardiões — depósitos e rotações do conjunto de guardiões — deve, adicionalmente, trazer um quórum de assinaturas Dilithium2 dos mesmos guardiões. O caminho de cunhagem é, portanto, pós-quântico, ainda que os pontos de extremidade externos não o sejam. As coassinaturas são transmitidas junto com a atestação e não exigem alteração nos contratos implantados.
Fonte: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §1
40. Por que o blinding da nota de depósito é derivado, e não escolhido?
Anteriormente, o compromisso da nota de depósito não era determinado até que um relayer submetesse a atestação, de modo que dois relayers podiam submeter a mesma atestação com notas diferentes. Derivar o fator de blinding r de forma determinística a partir da atestação fixa o compromisso; assim, submissões concorrentes colidem em um único compromisso e o depósito não pode ser cunhado duas vezes.
Fonte: docs/bridge.md (F1, chain 14)
41. Por que USDT bloqueado na Tron pode sair como USDT na Ethereum?
O zUSD é fungível: cada unidade é um direito sobre a reserva agregada, não sobre a cadeia por onde entrou. Desacoplar a entrada da saída permite que a liquidez se desloque para onde é demandada, desde que a cadeia de destino detenha reservas suficientes. O artigo sobre a stablecoin demonstra que o invariante S ≤ Σ_c R_c, o suprimento total limitado pela soma das reservas por cadeia, é preservado por toda transição de estado.
Fonte: randprotocol.org (seção de reservas)
42. Por que o blindado oculta a distribuição, mas não a quantidade?
O suprimento total de zUSD é público no registro de tokens e a reserva de cada cadeia é um saldo público, de modo que qualquer pessoa pode verificar a solvência; o que fica oculto é a distribuição das posições entre os titulares. Aplica-se uma limitação: os quatro saldos de reserva não podem ser observados atomicamente em um único instante, de modo que, para essas cadeias, a verificação detecta a insolvência a posteriori, em vez de preveni-la.
Fonte: randprotocol.org (seção de reservas)
43. Por que a queima é a única transação que nomeia seu ativo?
Uma queima libera um ativo específico em uma cadeia específica, portanto o contrato de custódia precisa saber qual ativo e qual cadeia. Toda outra transação transfere um ativo não identificado. A queima também carrega a taxa da bridge, por ser a única transação da bridge cujo remetente é o beneficiário.
Fonte: docs/architecture.md; docs/shielded.md §2
Conformidade e divulgação
44. Por que chaves de visualização em vez de ‘privado para todos’?
Os reguladores não aceitaram sistemas de privacidade em que a divulgação depende da cooperação da parte investigada, como ilustra o caso da Tornado Cash. A Rand, por isso, trata a divulgação como um objeto do protocolo. O titular, ou um intermediário regulado, retém uma chave de visualização; um auditor pode decifrar as transações indicadas em uma solicitação legal; e a meta do projeto são chaves com escopo definido, que revelam contraparte e valor sem revelar a estratégia de negociação. Para aplicações como folha de pagamento, essa auditabilidade é um requisito, e não uma limitação.
Fonte: randprotocol.org/usecases (seção de regulação; caso de folha de pagamento)
45. Por que a chave de visualização de saída é separada da de entrada?
A separação permite que um remetente comprove o que pagou sem obter acesso ao histórico do destinatário, e vice-versa. A chave de visualização de saída ovk decifra os envelopes que a carteira enviou; a chave de decapsulação ML-KEM decifra os envelopes enviados a ela; e uma chave por transação divulga exatamente uma saída a um terceiro.
Fonte: docs/shielded.md §1–2
Limitações conhecidas
46. O que as provas vazam hoje, e por que isso está documentado?
A revisão de 2026-09-27 constatou que, sob o guest v1 (chains 14–15), cada prova de bundle revela quais slots de entrada contêm notas reais e o peso de Hamming do índice de cada folha gasta. A causa é dupla: os totais LogUp por tabela são publicados sem blinding, e o fluxo de controle do guest se ramifica conforme uma entrada seja fictícia (dummy). O remédio é um guest sem ramificações (v2), a ser selecionado no próximo genesis. A constatação é publicada porque a rede é uma testnet e a documentação serve como seu registro de auditoria.
Fonte: docs/shielded.md (‘O que as provas vazam hoje’)
47. Por que o crescimento do estado tem preço subestimado?
Ethereum precifica as escritas em armazenamento porque o estado armazenado impõe um custo permanente a cada nó. Atualmente, a Rand precifica o crescimento da árvore de compromissos, do conjunto de nullifiers e do armazenamento de programas apenas por meio da taxa de implantação por palavra e da taxa fixa por bundle. Isso é adequado para uma testnet, mas está registrado como uma questão de precificação em aberto, a ser resolvida antes da mainnet; sua resolução não exige medição por opcode.
Fonte: docs/fees.md §3 (caveats)
48. Por que ainda não foi concluída nenhuma auditoria independente?
O protocolo está em desenvolvimento ativo em uma testnet operada pela equipe, e são esperados novos conjuntos de restrições e novos cortes de cadeia antes que o design se estabilize. O site informa isso em todas as páginas. As rodadas de auditoria interna (v3–v5) estão publicadas em docs/consensus.md e nas especificações do design, para que a eventual auditoria externa disponha de um registro completo sobre o qual trabalhar.
Fonte: randprotocol.org (rodapé); docs/consensus.md