Tecnologia
Profundidade técnica suficiente para estabelecer como o sistema funciona, sem publicar detalhes internos que comprometeriam a postura de segurança. Os diagramas de arquitetura e as ligações apontam apenas para repositórios ou documentação intencionalmente públicos.
Topologia do sistema
A visualização é deliberadamente arquitetónica, e não promocional. Cada fronteira corresponde a uma responsabilidade distinta e pode evoluir de forma independente.
01
Banco, processador ou operador de mercado
02
Fronteira externa controlada
03
Restauração canónica determinística
04
Estado de transações local-first e durável
05
Evidência inviolável e observabilidade
Sequência de falha
O sistema é concebido em torno da continuidade através da degradação. A sequência abaixo descreve o fluxo de controlo pretendido, sem expor detalhes de implementação privados.
Os nós partilham estado canónico em condições normais de rede.
Um nó fica isolado mas mantém o seu último estado durável.
As escritas permitidas continuam localmente, preservando dependências causais.
O estado divergente fica disponível para o serviço de reconciliação.
Regras determinísticas restauram um estado partilhado auditável.
01
BuiltUm sistema em camadas: um motor de estado local-first na periferia, um serviço de reconciliação que funde estados de nós num livro-razão canónico, uma fronteira de integração institucional e uma camada de auditoria que observa todas as camadas abaixo dela. As camadas comunicam através de interfaces definidas, e não de estado interno partilhado.
02
BuiltO estado de transações é apenas de acréscimo e endereçado por conteúdo: cada transição de estado referencia as transições de que depende, pelo que a ordem causal dos eventos é recuperável independentemente do tempo de relógio ou da ordem de chegada na rede. É isto que permite que um nó opere corretamente enquanto está desligado.
03
BuiltA liquidação é coordenada pelo Motor de Reconciliação, que sequencia as fusões de forma determinística e regista o resultado de cada decisão de liquidação na camada de auditoria. A lógica de orquestração está separada do motor de estado, para que as regras de liquidação possam evoluir sem alterar a forma como o próprio estado é registado.
04
ResearchA API Institucional está a ser concebida em torno de um pequeno conjunto de primitivas — submeter, consultar, reconciliar, observar — em vez de uma superfície ampla que espelhe cada capacidade interna. Uma camada de SDK sobre essa API está prevista mas ainda não publicada; o contrato da API está primeiro a ser validado face a cenários de integração.
05
BuiltO atraso de reconciliação, as janelas de divergência, a saúde dos nós e a integridade do registo de auditoria são expostos como sinais estruturados, e não derivados a posteriori a partir de registos. A observabilidade é tratada como parte do contrato de infraestrutura, e não como um acrescento operacional.
06
BuiltA falha de um nó, a partição de rede e a reconexão são tratadas como estados de funcionamento esperados, e não como exceções que exigem intervenção manual. Um nó que falha a meio de uma escrita recupera para o seu último estado durável ao reiniciar; um nó particionado continua a operar localmente e reconcilia ao reconectar-se.
07
BuiltA API Institucional é a única fronteira externamente acessível para o sistema; as camadas internas não aceitam entrada externa direta. Cada escrita é assinada no seu ponto de origem, e cada acesso à camada de auditoria é, ele próprio, auditado. A divulgação de segurança segue o processo descrito na página de Contacto.
08
BuiltA correção da reconciliação é testada face a cenários de divergência gerados — nós particionados, entrega fora de ordem, submissão duplicada, escritas concorrentes conflituantes — e não apenas face ao percurso ideal. O comportamento de integridade financeira é tratado como um portão de lançamento, e não como uma verificação a posteriori.
A CubeShackles mantém uma raiz técnica e institucional pública em github.com/CubeShackles. Nem todos os repositórios internos são públicos — a visibilidade dos repositórios reflete o que é apropriado para revisão externa em cada fase, e não o âmbito completo do trabalho de engenharia.
Recursos para programadores