Use esta página para ver quem faz o quê quando uma transferência percorre a Rand. Provar é caro e verificar é barato, por isso o trabalho é dividido ao longo dessa linha. O lado do remetente gera as provas. Os validadores apenas as verificam, ordenam e votam. Um agregador, uma vez ativado, combinaria muitas provas em uma só. A figura acompanha uma transferência da carteira até um bloco final; as seções seguintes tratam de cada papel em separado.
O caminho de uma transferência
- A carteira monta a transferência. Ela escolhe suas notes de entrada, obtém as testemunhas de Merkle delas, monta quatro saídas e sela cada uma em um envelope ML-KEM-768. Em seguida calcula o binding da transação, um hash sobre tudo, exceto as provas (Transactions).
- A carteira prova a autorização por conta própria. É uma prova de tier 10 sobre a chave de gasto e um salt novo, questão de poucos segundos. É a única prova que toca a chave de gasto e é sempre gerada na máquina da própria carteira.
- A prova do bundle é gerada onde há memória para isso. Esta prova de tier 14 demonstra a posse, a pertinência, os nullifiers e o saldo, e chega a cerca de 6 GB de pico. O aplicativo de desktop e um celular com cerca de 8 GB a geram sozinhos. Qualquer dispositivo menor entrega a tarefa a um prover com o qual esteja pareado: um que você mesmo execute, ou o pool dos validadores em
prover.randprotocol.org. Ambos recebem a chave de visualização e o salt, nunca a chave de gasto (Proofs). - Um nó RPC a verifica. O nó ao qual a carteira submete a transação recalcula o digest do bundle, verifica as duas provas contra o binding, confere a taxa e só então propaga a transação aos seus pares (Proofs, Mempool).
- Os validadores a ordenam e a finalizam. O líder da view pega as transações que ainda são aplicáveis, começando pela melhor taxa por KiB, e propõe um bloco. Cada validador reverifica todas as provas nele contidas e vota. O bloco é confirmado quando três quorum certificates se encadeiam sobre ele em views consecutivas, o que exige 18 dos 26 validadores da chain 20 online (Consensus).
- O bloco é final e qualquer pessoa pode verificá-lo. Uma transação é final quando
rand_getTransactionretorna um bloco. Um nó que sincroniza depois reverifica todos os certificados e todas as provas, em vez de confiar nas assinaturas.
Os papéis
| papel | o que faz | prova? | o que vê | executa |
|---|---|---|---|---|
| carteira | monta, autoriza e submete transferências e chamadas; varre a chain com as próprias chaves | sempre a prova de autorização; a prova do bundle quando o dispositivo tem memória | tudo sobre as próprias notes | os aplicativos da página Clients, ou rand; na chain 20, Rand Wallet ou rand v0.6.8 ou posterior |
| prover delegado | gera a prova do bundle para uma carteira pareada com ele; cada resposta é verificada pela carteira antes de qualquer submissão | somente provas de bundle | a chave de visualização da carteira pareada: todo o seu histórico, passado e futuro; não pode gastar | rand-prover run, ou rand-node run --prover |
| pool de provers dos validadores | um prover delegado operado por quatro hosts, dois validadores e duas máquinas que só provam, sob um único nome e uma única chave, para carteiras sem prover próprio; sem taxa | somente provas de bundle | o mesmo que qualquer prover delegado, para toda carteira que o pareie | prover.randprotocol.org, fingerprint RGTF-7HKJ-XZFV-GQ1J |
| nó RPC (observador) | sincroniza, reverifica todas as provas, serve JSON-RPC, propaga transações verificadas; não vota | não | somente campos públicos: commitments, nullifiers, envelopes selados, provas | rand-node run |
| validador | tudo o que um observador faz, além de propor em suas views e votar no HotStuff | não | somente campos públicos | rand-node run --validator |
| agregador | gera uma prova recursiva sobre uma janela de provas de bundle finalizadas e a submete para um bloco de selagem | sim, as maiores provas da rede | somente campos públicos e provas | rand-node aggregate --watch, em uma chain com uma seção aggregation |
Provar e validar são trabalhos distintos, e um validador não precisa de hardware de prover. Dois dos quatro membros do pool são validadores que também executam um prover, como serviço; os outros dois são máquinas dedicadas à prova, que não têm chave de validador. Operar o pool não faz parte de validar. Os requisitos de cada papel e a memória de prova medida por tier estão em Validator and aggregator hardware.
O que cada papel pode aprender
A privacidade de uma transferência depende de quem detém cada chave, não de confiar na rede:
- Validadores, nós RPC e o explorer veem o que todo nó vê: commitments, nullifiers, envelopes selados, a taxa e as provas. Não veem o valor, o ativo, o remetente nem o destinatário.
- Um prover delegado, incluindo o pool, recebe a chave de visualização. Com ela, pode ler todo o histórico da carteira pareada. Nunca pode gastar, porque a prova de autorização sobre a chave de gasto é gerada na máquina da carteira. Parear o pool significa optar por mostrar esse histórico aos seus operadores. Se você quer mantê-lo privado, prove no seu próprio dispositivo ou execute o seu próprio prover.
- Um prover delegado não consegue enganar a carteira. A carteira lê o digest de cada prova recebida, confere o tamanho e a verifica localmente, de modo que uma prova errada nunca chega a um nó.
Agregação: construída, não ativada
Hoje cada bloco carrega todas as provas brutas, cerca de 2,85 MB por transferência, de modo que um bloco de 20 MiB comporta cerca de sete transferências. A agregação de blocos é a resposta do fullnode. Um agregador pega as provas de bundle de uma janela de blocos finalizados (rand_getUnsealed), gera uma prova recursiva que verifica todas elas e a submete. O bloco que a inclui sela a janela. Os validadores passam então a verificar um único agregado em vez de N provas, e os nós podem descartar as provas brutas cobertas. Os agregadores são bonded e sem permissão, executam em máquinas da classe GPU e recebem a parcela de prova dos bundles cobertos, além de um subsídio de bloco em novos RAND.
Está construída e integrada, mas não está ativa. Ela exige uma seção aggregation no genesis, e a chain 20 não tem nenhuma, por isso rand_status informa todos os contadores de agregação como zero. Antes de poder ser ativada, o formato de bundle precisa ser remedido sob o conjunto de restrições atual, e um exercício de agregado forjado precisa ser executado contra o verificador de recursão. Em uma chain com autorização dividida, ela selaria apenas as provas de bundle, não as provas de autorização (Proofs).