Arquitetura do protocolo

Um mergulho profundo no modelo de segurança do Parallax: assinaturas para autoria, PVM para semântica, Prova de Trabalho para tempo e consenso Nakamoto para história canônica.

Como as peças se encaixam
O Parallax entrelaça criptografia, execução determinística, marcação de tempo por prova de trabalho e escolha de fork neutra em um único pipeline verificável.
Criptografia

O ECDSA decide quem pode agir (autoria válida).

Execução (PVM)

Define o que as ações fazem (transições de estado).

Servidor de timestamp

Estabelece quando as ações ocorrem (ordenadas por PoW).

Nakamoto

Seleciona qual história prevalece (cadeia mais pesada).

Assinaturas digitais
Quem pode agir: o ECDSA sobre secp256k1 autentica transições de estado.
  • ECDSA sobre secp256k1 idêntico ao do Bitcoin, por segurança e ferramental testados em batalha.
  • As transações incluem (r, s, v); o remetente é recuperado via chave pública → derivação de endereço.
  • A validação ocorre no pipeline de execução, garantindo regras uniformes entre os nós.
  • Não repúdio: as assinaturas vinculam intenções a chaves; proteção contra replay via chain id e nonce.
Verificação de assinatura (conceitual)
pseudocódigo
// Pseudocode: PVM-side validation sketch
verify(tx):
  msg = keccak256(encodeTxForSig(tx))
  pub = ecrecover(msg, tx.v, tx.r, tx.s)
  require(address(pub) == tx.from)
  require(tx.nonce == account.nonce)
  // gas accounting & state updates proceed
Scripting Turing-completo (PVM)
O que as ações significam: execução determinística compatível com EVM sob regras monetárias semelhantes às do Bitcoin.
  • Paridade de opcodes com a EVM (CALL/SSTORE/etc.), execução determinística medida em gas.
  • Estado armazenado em Merkle Patricia Trie; o cabeçalho do bloco se compromete com stateRoot e receiptsRoot.
  • Programabilidade dentro da escassez: teto de 21M, halving ⇒ a execução herda dinheiro sólido.
  • Amigável para clientes leves, via provas de inclusão e replay determinístico de blocos.
Bloco → Execução → Raízes
pseudocódigo
// Conceptual block processing
for (tx of block.txs):
  result = PVM.execute(tx, state)
commit:
  stateRoot    = MPT(state)
  receiptsRoot = MPT(receipts)
  header.stateRoot = stateRoot
  header.receiptsRoot = receiptsRoot
Servidor de timestamp
Quando as ações ocorrem: o PoW transforma o tempo em um recurso criptográfico e ordena eventos.
  • Cada bloco se compromete com o hash do cabeçalho anterior ⇒ cadeia temporal verificável.
  • A Prova de Trabalho (XHash) vincula custo ao tempo; a recomputação impõe a seta do tempo.
  • Ordenação objetiva sem relógios confiáveis; o median-time-past impede o abuso de timestamps.
  • A segurança cresce com a dificuldade acumulada; retroceder datas torna-se economicamente inviável.
Encadeamento do cabeçalho
pseudocódigo
// Block header sketch
header = {
  parentHash,
  stateRoot,
  txRoot,
  time,
  nonce,
  difficulty,
  mixHash,      // XHash result
}
assert(block.parent.hash == parentHash)
assert(XHash(header) < target(difficulty))
Consenso Nakamoto
Qual história prevalece: a cadeia válida mais pesada por trabalho acumulado é a canônica.
  • A regra da cadeia mais pesada seleciona a história canônica via PoW acumulada (soma de dificuldade).
  • Finalidade probabilística: o risco de reorg decai exponencialmente com a profundidade (k-confirmações).
  • O reajuste de dificuldade (XHash) visa blocos de cerca de 10 minutos usando median-time-past.
  • Economicamente neutro: sem staking nem validadores privilegiados — apenas PoW aberta.
Escolha de fork (conceitual)
pseudocódigo
// Choose chain with max cumulative work
best = argmax(chains, sum(block.work for block in chain))
Pipeline

Fluxo de ponta a ponta

Uma transação assinada entra no mempool → o minerador propõe um bloco → a PVM executa de forma determinística → o cabeçalho se compromete com estado/recibos → o XHash prova o trabalho → a rede adota a cadeia válida mais pesada. A escassez (21M, halvings) sustenta toda a execução.

1
Assinar
2
Executar
3
Comprometer
4
Provar
5
Selecionar