Esmiucei a arquitetura de baixo nível por trás do @grvt_io ; quanto mais fundo, mais percebo que o chamado “exchange híbrida (HEX)” — vendido como “experiência de CEX + segurança de DEX” — tem, na verdade, uma “água” mais funda do que parece.
Ele se baseia no Validium do ZKsync para fazer a correspondência (matching) off-chain e a liquidação on-chain. Parece perfeito: zero Gas e latência em nível de milissegundos. Mas o calcanhar de Aquiles está na disponibilidade de dados (DA). No Validium, o livro-razão fica off-chain; apenas a raiz do estado e as provas ZK são enviadas para a Ethereum. Isso significa que o seu poder de controle de ativos é, em parte, mantido nas mãos de um “comitê de DA” off-chain. Se ocorrer um cenário extremo e unilateral, uma falha do layer de DA ou conluio entre nós pode não “roubar” seus fundos criptograficamente — mas vai “congelá-los”. Em máquinas de trituração com alta alavancagem, como opções e perpétuos, ter os ativos travados por horas sem conseguir recompor margem é tão irritante quanto (ou pior que) ver um hacker drenando tudo.
Depois, examinando melhor o mecanismo de Session Keys. A versão oficial promete “uma assinatura, transações de alta frequência”; no uso, realmente é bem fluido. O perigo é outro: em congestionamento extremo de rede, o canal para revogar permissões fica aberto? Se o motor de matching sofrer DDoS ou se o front-end travar, o comando de cancelar ordens não é enviado — e a Session Key continua, no nível mais baixo, executando a velha estratégia de “consumir” ordens (taker). Assim, você vira um alvo fácil, só apanhando de um lado.
Por isso, meu limite para aportar fundos é este: preciso verificar se o seu Escape Hatch (escapamento de emergência on-chain) consegue contornar o sequencer oficial e ser chamado diretamente. Se não conseguir, “self-custody” tem que ter um grande desconto.
Quanto ao GRVT tentar encarar de frente o mercado de opções da Deribit, o grande obstáculo é o “cold start” de liquidez. Convidar market makers tradicionais (MM) para fornecer profundidade no book é o caminho padrão. Mas o código dos MM é faminto e extremamente sensível. Se, sob algumas dezenas de milissegundos de atraso ampliado em alguns milhares de TPS sob alta pressão, o motor off-chain de matching der uma engasgada, os scripts dos MM vão cancelar ordens instantaneamente em toda a rede. Nesse momento, o “depth” que o varejista enxerga será apenas miragem; ao consumir por preço de mercado (market), a execução escorrega direto até o teto.
O que eu penso é: em vez de deixar que narrativas de “ZK” e “account abstraction” lavem seu cérebro, é melhor esperar o lançamento na mainnet e observar a taxa de indisponibilidade (downtime) quando ele enfrentar um cenário extremo, além do desempenho da DA na cadeia. Antes de um verdadeiro teste de estresse com dinheiro de verdade produzir resultados, até os white papers mais empolgantes ainda são só rascunhos. #grvt
Ele se baseia no Validium do ZKsync para fazer a correspondência (matching) off-chain e a liquidação on-chain. Parece perfeito: zero Gas e latência em nível de milissegundos. Mas o calcanhar de Aquiles está na disponibilidade de dados (DA). No Validium, o livro-razão fica off-chain; apenas a raiz do estado e as provas ZK são enviadas para a Ethereum. Isso significa que o seu poder de controle de ativos é, em parte, mantido nas mãos de um “comitê de DA” off-chain. Se ocorrer um cenário extremo e unilateral, uma falha do layer de DA ou conluio entre nós pode não “roubar” seus fundos criptograficamente — mas vai “congelá-los”. Em máquinas de trituração com alta alavancagem, como opções e perpétuos, ter os ativos travados por horas sem conseguir recompor margem é tão irritante quanto (ou pior que) ver um hacker drenando tudo.
Depois, examinando melhor o mecanismo de Session Keys. A versão oficial promete “uma assinatura, transações de alta frequência”; no uso, realmente é bem fluido. O perigo é outro: em congestionamento extremo de rede, o canal para revogar permissões fica aberto? Se o motor de matching sofrer DDoS ou se o front-end travar, o comando de cancelar ordens não é enviado — e a Session Key continua, no nível mais baixo, executando a velha estratégia de “consumir” ordens (taker). Assim, você vira um alvo fácil, só apanhando de um lado.
Por isso, meu limite para aportar fundos é este: preciso verificar se o seu Escape Hatch (escapamento de emergência on-chain) consegue contornar o sequencer oficial e ser chamado diretamente. Se não conseguir, “self-custody” tem que ter um grande desconto.
Quanto ao GRVT tentar encarar de frente o mercado de opções da Deribit, o grande obstáculo é o “cold start” de liquidez. Convidar market makers tradicionais (MM) para fornecer profundidade no book é o caminho padrão. Mas o código dos MM é faminto e extremamente sensível. Se, sob algumas dezenas de milissegundos de atraso ampliado em alguns milhares de TPS sob alta pressão, o motor off-chain de matching der uma engasgada, os scripts dos MM vão cancelar ordens instantaneamente em toda a rede. Nesse momento, o “depth” que o varejista enxerga será apenas miragem; ao consumir por preço de mercado (market), a execução escorrega direto até o teto.
O que eu penso é: em vez de deixar que narrativas de “ZK” e “account abstraction” lavem seu cérebro, é melhor esperar o lançamento na mainnet e observar a taxa de indisponibilidade (downtime) quando ele enfrentar um cenário extremo, além do desempenho da DA na cadeia. Antes de um verdadeiro teste de estresse com dinheiro de verdade produzir resultados, até os white papers mais empolgantes ainda são só rascunhos. #grvt