Nota histórica sobre a experiência Alpha 5 anterior à reconstrução: eventos assinados, âncoras apenas com hashes e ligação Railgun. Não descreve a versão atual.
Nesta página
O que mudou
Os eventos operacionais são representados por hashes de JSON canónico e assinaturas Ed25519 antes de se considerar qualquer âncora pública opcional.
As âncoras conservam hashes em vez de dados privados, enquanto os registos de ligação de pagamentos contêm hashes de aceitação, nullifiers e compromissos.
O mesmo rasto liga aprovações, contratos, marcos, alterações contratuais, faturas, pedidos de pagamento e recibos sem fazer da cadeia o armazenamento principal.
Os registos locais mantêm a autoridade
Contratos, marcos, aprovações, alterações contratuais, faturas, pedidos de pagamento e recibos continuam a ser registos da aplicação. A camada de prova deriva representações canónicas de eventos desse estado; não transfere a base operacional para uma cadeia pública.
Cada evento pode ser serializado de forma determinística, convertido em hash e assinado antes de se considerar uma âncora externa. Esta ordem dá ao processo local um histórico verificável sem tornar a operação corrente dependente de uma infraestrutura pública de liquidação.
A divulgação é separada por camada
Dados privados, assinaturas, âncoras de hashes e ligações de pagamentos são tratados como objetos distintos. Uma âncora pública pode conservar um hash sem publicar o contrato, o registo do imóvel, o ficheiro de evidência ou a identidade do agregado familiar subjacente.
O registo do pagamento liga a aceitação do marco à liquidação através de compromissos e nullifiers. Estabelece assim continuidade entre uma unidade de trabalho aprovada e uma transferência privada, sem criar um histórico de pagamentos em texto simples.
A verificação acompanha o processo
A afirmação útil não é apenas que um evento foi assinado. O rasto tem de preservar a ordem entre relação, contrato, evidência do marco, aceitação, pedido de pagamento, ligação à liquidação e recibo.
Assim, os pontos de falha ficam visíveis: um evento sem assinatura, um hash de aceitação divergente ou uma ligação em falta não podem ser apresentados como um pagamento verificado e concluído. A interface pode continuar utilizável, mostrando exatamente a etapa de prova que falta.
Nota de engenharia
Esta arquitetura pertence à branch arquivada anterior à reconstrução. A aplicação atual usa uma interface Next.js, API Go, PostgreSQL, anexos privados e convites limitados para prestadores; a integração operacional de um prestador de pagamentos continua por concluir.
Proveniência
Esta nota baseia-se no código verificado da branch arquivada anterior à reconstrução, no commit fafa17d. É conservada como histórico técnico e não descreve o produto atual.