Skip to main content
O IntentionKernel é onde um bloco confirmado se torna estado de negociação. Não é uma máquina virtual de uso geral que executa programas arbitrários — o seu conjunto de instruções é o conjunto enumerado de operações financeiras de que uma plataforma de derivados precisa, e cada uma delas tem um efeito definido que o protocolo compreende. É essa distinção que permite à rede afirmar seja o que for sobre negociação. Uma cadeia de uso geral consegue dizer que uma transação foi assinada e não abortou. Não consegue dizer que a transação era o cancelamento de uma ordem específica numa posição específica do livro, porque o significado da chamada lhe é opaco. Aqui, o significado é a instrução.

​
Execução em mundo fechado

Fechar o conjunto de instruções é apenas uma instância de um gesto que o kernel faz quatro vezes. De cada vez, o espaço do que pode acontecer é enumerado à cabeça, e o que fica de fora é recusado em vez de tratado.
Operações
Uma carga que não pertence ao conjunto enumerado — recusada na validação, não em tempo de execução
O que foi realmente pedido
Verdade
Tratar o conjunto de trabalho do bloco como autoritativo. É um diário; a fonte é o estado do motor
O que é verdade neste momento
Entradas
Tudo o que pode diferir entre duas máquinas: relógio, entropia, vírgula flutuante, ordem de hash
Se outro nó obtém os mesmos bytes
Causalidade
Uma alteração de estado sem dono. Os efeitos que não pertencem a nenhuma transação passam por um canal de sistema, não por uma exceção
Porque aconteceu esta alteração em concreto
Fechado
Recusado
Assim o ledger consegue responder
Quatro fechos, um só gesto: enumerar o espaço à cabeça e recusar o que fica de fora.
Não são quatro virtudes independentes. Cada uma sustenta a seguinte: fechar as operações é o que torna recuperável o significado de uma instrução; um único estado autoritativo é o que dá sentido à palavra «resultado»; fechar as entradas é o que torna esse resultado reproduzível fora desta máquina; e fechar a causalidade é o que permite recuar de um resultado até ao pedido que o produziu. Retire uma e a cadeia de responsabilização parte-se nesse elo. O que as quatro compram em conjunto merece um nome, porque os locais tradicionais compram a mesma coisa muito mais caro. A trilha de auditoria de uma bolsa é montada ao lado do sistema de negociação e depois reportada a jusante — é por isso que pode divergir do sistema, é por isso que a reconciliação é um trabalho permanente, e é por isso que a sincronização de relógios entre locais é uma exigência regulatória e não um detalhe de implementação. Aqui não há um segundo registo com que reconciliar. A trilha de auditoria é a execução. O resto desta página são esses quatro fechos em detalhe.

​
O conjunto de instruções

Tudo o que um participante ou um validador pode fazer é uma de um conjunto fixo de operações tipadas: Uma transação cujo payload não pertença a este conjunto é rejeitada na validação. O conjunto só muda por atualização do protocolo, nunca por se instalar algo novo.

​
Executar um bloco

A execução é uma sequência fixa de fases. A ordem não é um detalhe de implementação — é o que determina se uma liquidação forçada vê o preço que a ativou e se um cancelamento chega antes de uma ordem agressora que entra.
Preçofixar as marcações do bloco
Cargaingerir as contas e ordens do bloco
Fundingacertar o funding
Riscodesalavancagem de vaults → liquidação → ADL
Matchingpré → matching → pós
Finalizarrecolher saídas, eliminar estado morto
As fases seguintes raciocinam sobre um preço por instrumento, não um em movimento
Acertado sobre as posições como carregadas, não como acabam
O fluxo forçado resolve-se antes de se admitir novo fluxo discricionário
Correr depois do Risco impede o front-running de uma liquidação por uma ordem do mesmo bloco
Posições zeradas e contas esvaziadas não persistem
Um bloco, seis fases
O que a posição determina
As ordens condicionais são varridas dentro desta sequência: uma ativação pelas marcações deste bloco produz efeito neste bloco e não no seguinte.
Preço corre primeiro e fixa as marcações que o resto do bloco vai usar, para que todas as fases seguintes raciocinem sobre um preço por instrumento e não sobre um preço em movimento. Carga ingere as contas e as ordens do bloco. Funding acerta o funding sobre as posições tal como foram carregadas. Risco corre três fases por ordem — desalavancagem de vaults, depois liquidação forçada, depois desalavancagem automática — para que o fluxo forçado fique resolvido antes de se admitir novo fluxo discricionário. Matching corre depois as suas próprias três fases, produzindo execuções. Finalizar recolhe o que mudou e elimina o estado que já não precisa de existir, como posições zeradas e contas esvaziadas. As ordens condicionais são varridas e avançam no seu ciclo de vida dentro desta sequência, pelo que uma ativação despoletada pelas marcações deste bloco produz efeito neste bloco e não no seguinte.
O facto de a liquidação correr antes do matching é a razão pela qual não é possível fazer front-running a uma liquidação com uma ordem do mesmo bloco. O fluxo de liquidação já está resolvido quando as ordens discricionárias são cruzadas.

​
Dois tipos de estado

O kernel mantém uma separação estrita entre o que persiste e o que é rascunho.
enquanto o bloco executa
Estado do motormercados · contas · livros · posições · câmara de compensaçãopersiste entre blocos
Conjunto de trabalhomarcações · contas tocadas · execuções · resultadosdura apenas um bloco
Estado confirmado da cadeiaversionado · autenticadoa autoridade
É fácil confundir o registo de alterações com autoridade. O que mudou num bloco constrói saída determinista — não é onde o estado vive.
autoridade de onde o motor é reconstruído
ler
aplicar
materializar
O estado do motor vive de bloco para bloco: metadados de mercado, contas, livros de ordens, estado dos instrumentos, estado da câmara de compensação. É a resposta a «o que é verdade neste momento». O conjunto de trabalho por bloco existe apenas enquanto um bloco executa: as entradas do bloco, as marcações fixadas no início, as contas e ordens tocadas e as saídas em construção. É um diário, não uma fonte de verdade. A distinção importa porque é fácil confundir o registo de alterações com autoridade. O que mudou durante um bloco serve para construir saída determinista — não é onde o estado vive. Inverter isto produz um sistema em que a resposta depende da forma como a pergunta foi feita.

​
Porque o resultado é reproduzível

Aqui o determinismo é imposto, não esperado. Todos os nós honestos que executem o mesmo bloco sobre o mesmo estado anterior produzem o mesmo resultado byte a byte, porque nada no caminho de execução pode ler o que quer que seja que difira entre nós:
  • Aritmética de vírgula fixa em todo o lado. O cálculo da liquidação financeira corre em vírgula fixa inteira com semântica de arredondamento explícita — por excesso em expoentes negativos na margem, por defeito e por excesso nas comissões. Não há vírgula flutuante no caminho da liquidação financeira, porque uma diferença de arredondamento entre duas máquinas é um fork.
  • Sem relógio de parede. A ordenação dentro de um bloco usa a posição canónica confirmada pelo consenso e a data/hora do bloco, nunca a hora local.
  • Sem aleatoriedade em tempo de execução. Tudo o que precise de aleatoriedade deriva-a de forma determinista do estado da cadeia.
  • Iteração determinista. Qualquer coleção cuja ordem de iteração seja observável na saída é ordenada, não aleatorizada por hash.
Vale a pena nomear uma consequência: como o «tempo» dentro de um bloco é a posição intrabloco confirmada, não existe qualquer vantagem de colocalização ao nível do submilissegundo dentro de um bloco. Combinado com a ordem de prioridades — que corre os cancelamentos antes das colocações agressivas — isto é uma defesa estrutural contra o risco de uma cotação colocada no livro ser apanhada por uma ordem que chegou no mesmo bloco.

​
As fórmulas de risco são puras

As fórmulas que decidem requisitos de margem, preços de liquidação, seleção para desalavancagem, comissões e limites de open interest (posições em aberto) são implementadas como funções puras e sem estado. Recebem valores e devolvem valores; não leem nem alteram o estado do ledger. As alterações de estado são conduzidas exclusivamente pela câmara de compensação, que chama essas funções e aplica os resultados. Os módulos que detêm estado — contas, posições, livros de ordens — armazenam dados e expõem mutadores, mas não conduzem eles próprios o fluxo de negócio. Esta fronteira é deliberada. Significa que um cálculo de margem pode ser verificado isoladamente contra uma tabela de entradas e saídas, e significa que existe exatamente um caminho de código pelo qual o saldo de alguém pode mudar.

​
Saída

A execução produz escritas de estado e eventos, cada um ligado à transação que o causou, mais um canal para efeitos ao nível do sistema que não pertencem a nenhuma transação de utilizador — funding, movimentos do fundo de seguro, contadores de bloco. Estes tornam-se as saídas de transação que a camada de estado confirma e o indexador serve. Nada do que acontece dentro do kernel é invisível a jusante. Se alterou estado, está na saída de alguém ou no canal do sistema.

​
Para onde ir a seguir

Matching

O livro de ordens, a prioridade preço-tempo e como se resolvem a validade da ordem e a prevenção de autonegociação.

Câmara de compensação

O único caminho pelo qual saldos, posições e margem mudam.

Modelo de estado

Em que se torna a saída do kernel depois de confirmada.

IntentionBFT

De onde vieram a ordenação e os preços.