Skip to main content
Num motor de negociação há três coisas diferentes a que se chama «estado», e confundi-las é a forma como um sistema acaba com respostas que variam consoante a pessoa a quem se pergunta. Esta página separa-as e diz qual delas tem autoridade.

​
Três representações

Estado do motormercados · contas · posições · livros · câmara de compensaçãopersiste entre blocos · uma reconstrução
Conjunto de trabalhomarcações · contas tocadas · execuções · resultadosdura um bloco · um diário
Estado da cadeiachave-valor versionado, autenticação Merklea autoridade
A falha que isto evitaUm motor cuja visão em memória se afastou do que foi confirmado continua a servir respostas, e todas elas estão erradas de uma forma que só aparece na liquidação financeira.
o estado do motor tem de ser derivável do registo confirmado, nunca o contrário
O estado do motor é o que o kernel guarda entre blocos: metadados de mercado, contas, posições, livros de ordens, estado dos instrumentos, estado da câmara de compensação. É a representação de trabalho — disposta para os padrões de acesso que o matching e a compensação realmente têm, não para armazenamento. O conjunto de trabalho do bloco existe apenas enquanto um bloco executa: os preços de marcação fixados no início, que contas e que ordens foram tocadas, as execuções produzidas, os resultados que estão a ser montados. É um diário do que aconteceu durante este bloco. O estado da cadeia é o resultado confirmado: entradas chave-valor versionadas, autenticadas por uma estrutura de Merkle, duráveis e reexecutáveis. É o que um nó sincroniza, aquilo contra o que uma prova é feita e o que um indexador lê. O estado da cadeia é a autoridade. O conjunto de trabalho do bloco é um diário usado para construir um resultado determinista — não uma fonte de verdade. O estado do motor é uma reconstrução do estado da cadeia otimizada para execução; tem de ser derivável do registo confirmado, nunca o contrário. Inverter isto é uma falha específica e reconhecível: um motor cuja visão em memória se afastou do que foi confirmado continua a servir respostas, e todas elas estarão erradas de uma forma que só aparece na liquidação financeira.

​
Chaves

O estado da cadeia é endereçado por chave. O estado de negociação está agrupado em espaços de nomes identificados e explicitamente versionados — por exemplo, a configuração de comissões, o índice de contratos perpétuos, a tabela de escalões de alavancagem, a lista de papéis administrativos. O sufixo de versão não é decoração. Quando a forma de uma configuração muda, ela passa para uma nova versão da sua chave, e a chave anterior é mantida para que o estado escrito sob o esquema antigo continue a poder ser lido durante a migração. Um leitor que fixe uma versão no código e nunca volte a verificar passa a ler, em silêncio, configuração desatualizada depois de uma migração; um leitor que resolva a chave atual não.
É por isto que a configuração deve ser lida da cadeia e não fixada no código do cliente. O serviço de escalões de comissões lê a configuração de comissões em vigor em cada ciclo exatamente por esta razão — uma tabela de escalões embutida num cliente é uma tabela que mais cedo ou mais tarde vai divergir daquela que a rede está a aplicar.

​
Versões

Cada bloco confirmado faz avançar uma versão. Os valores de estado são guardados associados à versão em que foram escritos, o que significa que o armazenamento não é apenas «o estado atual», mas «o estado em qualquer versão». É esta propriedade que torna várias coisas possíveis ao mesmo tempo:
  • As provas podem ser produzidas contra uma versão específica, e não apenas contra o presente.
  • A reexecução pode começar em qualquer versão, não só na génese.
  • As leituras podem ser históricas — um indexador que reconstrói o histórico de uma posição está a pedir versões antigas, não a varrer um registo sequencial.
  • A poda passa a ser uma decisão de política sobre até onde manter o passado, e não uma limitação estrutural.

​
O que acaba confirmado

A execução do kernel produz duas coisas por bloco. Cada transação transporta as suas próprias escritas e eventos, ligados a ela. Os efeitos que não pertencem a nenhuma transação de utilizador — fluxos de funding, movimentos do fundo de seguro, contadores ao nível do bloco — vão para um canal de sistema próprio. Entre os dois, nada se perde. Não existe nenhum efeito de execução dentro do kernel que esteja ausente tanto do resultado de uma transação como do canal de sistema. É esta completude que permite tratar o registo confirmado como a história inteira, e não como um resumo dela, e é a razão pela qual um evento pode ser rastreado até à transação que o causou, mesmo quando o matching correu em lote.

​
Para onde ir a seguir

Armazenamento e provas

Como o estado confirmado é fisicamente guardado, autenticado e podado.

Sincronização de estado

Como um nó que nunca viu a cadeia a alcança.

IntentionKernel

Onde vivem o estado do motor e o conjunto de trabalho do bloco.

Indexador

Transformar o estado confirmado em algo consultável.