Na madrugada de quinta-feira, fiquei agachado do lado do tanque de fermentação de uma oficina de cerveja artesanal, ajudando um parceiro de “pagamentos transfronteiriços” a montar a @NewtonProtocol da sua “caixa-forte de conformidade”. Os documentos dizem “pronto para uso”; no entanto, só fazer o Rego funcionar com uma combinação “lista de permissões + limite” me tomou a noite inteira.
O Rego foi criado para escrever políticas de recursos em nuvem voltadas a TI corporativa: sintaxe declarativa, nega por padrão (deny) e depois libera item a item com allow. O #Newt quer trazê-lo para a cadeia como o núcleo da autorização, porque é melhor de escrever que Solidity e mais flexível. Mas quem paga o preço dessa flexibilidade? Tentei escrever uma regra que ao mesmo tempo verifica identidade, limite, risco da contraparte e preço das garantias: quatro condições aninhadas, e o módulo imediatamente virou uma teia de aranha de referências cruzadas. Mudar um limite exige seguir o encadeamento de import por três níveis. Eu nem consigo raciocinar totalmente com as regras que eu mesmo escrevi. Quando saiu uma brecha, fui atrás do operador? Do autor da política? Ou do time Newton que vende promessa?
Outra coisa: o mito de “segundos”. A intenção é empacotar tudo como uma tarefa, jogá-la para os operadores do EigenLayer que fazem restake; cada um roda o Rego, gera a prova e faz a agregação de assinaturas BLS, e por fim devolve tudo na cadeia. Soa sensual, mas se eu reviro a documentação, não encontrei dados de testes de estresse. Quanto mais complexa a política, mais tempo um operador individual leva para avaliar; quanto mais operadores, mais imprevisível fica o atraso para sincronizar e reunir as assinaturas. O “em segundos” do documento é dado de laboratório em pausa artificial, ou é a normalidade em políticas reais e complexas?
A janela de controvérsia também me deixa incomodado. Se um operador julga errado, você tem que esperar o período de desafio acabar e alguém enviar uma prova de fraude para corrigir. Não é isso “executar primeiro, liquidar depois”? Seu dinheiro é transferido antes, e depois as verbas ficam no ar, meio suspensas. Isso é gestão de risco? Isso é fazer o usuário virar voluntário pago.
E privacidade… ainda mais engraçado. O $NEWT fala em TEE + ZK para proteger privacidade, mas a política usa validação de identidade, score de risco e status de KYC que vêm de APIs de terceiros externas. Quanto mais flexível a política, menos o cidadão comum consegue auditar; no fim, ainda precisa confiar na instituição que te dá a nota. Proteção de privacidade, no fim, só preservou o nada — e a confiança saiu da cadeia para virar uma caixa-preta fora dela.
Tranquei o celular. O frio do tanque de fermentação deixou meus dedos dormentes. Mais uma história que transforma complexidade em algo simples — só que, no papel de embrulho, há um logo em dourado de TEE e ZKP. $BTC $ETH
O Rego foi criado para escrever políticas de recursos em nuvem voltadas a TI corporativa: sintaxe declarativa, nega por padrão (deny) e depois libera item a item com allow. O #Newt quer trazê-lo para a cadeia como o núcleo da autorização, porque é melhor de escrever que Solidity e mais flexível. Mas quem paga o preço dessa flexibilidade? Tentei escrever uma regra que ao mesmo tempo verifica identidade, limite, risco da contraparte e preço das garantias: quatro condições aninhadas, e o módulo imediatamente virou uma teia de aranha de referências cruzadas. Mudar um limite exige seguir o encadeamento de import por três níveis. Eu nem consigo raciocinar totalmente com as regras que eu mesmo escrevi. Quando saiu uma brecha, fui atrás do operador? Do autor da política? Ou do time Newton que vende promessa?
Outra coisa: o mito de “segundos”. A intenção é empacotar tudo como uma tarefa, jogá-la para os operadores do EigenLayer que fazem restake; cada um roda o Rego, gera a prova e faz a agregação de assinaturas BLS, e por fim devolve tudo na cadeia. Soa sensual, mas se eu reviro a documentação, não encontrei dados de testes de estresse. Quanto mais complexa a política, mais tempo um operador individual leva para avaliar; quanto mais operadores, mais imprevisível fica o atraso para sincronizar e reunir as assinaturas. O “em segundos” do documento é dado de laboratório em pausa artificial, ou é a normalidade em políticas reais e complexas?
A janela de controvérsia também me deixa incomodado. Se um operador julga errado, você tem que esperar o período de desafio acabar e alguém enviar uma prova de fraude para corrigir. Não é isso “executar primeiro, liquidar depois”? Seu dinheiro é transferido antes, e depois as verbas ficam no ar, meio suspensas. Isso é gestão de risco? Isso é fazer o usuário virar voluntário pago.
E privacidade… ainda mais engraçado. O $NEWT fala em TEE + ZK para proteger privacidade, mas a política usa validação de identidade, score de risco e status de KYC que vêm de APIs de terceiros externas. Quanto mais flexível a política, menos o cidadão comum consegue auditar; no fim, ainda precisa confiar na instituição que te dá a nota. Proteção de privacidade, no fim, só preservou o nada — e a confiança saiu da cadeia para virar uma caixa-preta fora dela.
Tranquei o celular. O frio do tanque de fermentação deixou meus dedos dormentes. Mais uma história que transforma complexidade em algo simples — só que, no papel de embrulho, há um logo em dourado de TEE e ZKP. $BTC $ETH