O matching verificável por ZK é uma forma de executar um livro de pedidos rápido e privado, mas ainda assim oferece aos usuários uma garantia criptográfica de que o motor de correspondência seguiu as regras. O problema que ele resolve é simples: um CLOB precisa de um operador (ou um pequeno conjunto de operadores) para igualar ordens rapidamente, mas esse operador também pode trapacear (reordenar, pular ou preencher seletivamente). ZK muda o modelo de confiança: o operador pode se manter rápido, mas não pode finalizar uma atualização a menos que prove que foi calculada corretamente. Como funciona (conceitualmente) ➤ Ordens são coletadas e combinadas fora da cadeia (para que você possa obter execução de baixa latência). ➤ Em vez de publicar o fluxo completo de ordens, o sistema publica: - um compromisso com a transição de lote/estado (frequentemente uma raiz de estado) - uma prova zk de que as atualizações de correspondência + verificações de risco + saldo foram feitas de acordo com as regras do protocolo, - disponibilidade suficiente de dados para que os usuários ainda possam sair mesmo que o operador desapareça. Essa "disponibilidade suficiente de dados" é onde a escolha de design da @hibachi_xyz é interessante: A Hibachi está rodando um CLOB de alto desempenho e postando dados criptografados de estado/negociação para @Celestia (então estratégias e posições não são públicas), enquanto ainda publica provas para que as atualizações permaneçam verificáveis, usando o SP1 (zkVM da Succinct) para comprovar o CLOB. Mas o que significa "correspondência correta" em termos de prova? Uma prova zk pode impor os mesmos invariantes que normalmente você confiaria em um operador de troca para seguir, por exemplo: ➤ Os pedidos eram igualados apenas quando os preços se cruzavam (sem preenchimento impossível). ➤ A sequência de preenchimento respeitou a regra de prioridade do local (por exemplo, prioridade preço-tempo, ou o que o local especificar). ➤ Saldos/margens foram atualizados corretamente (sem edições ocultas de saldo). ...