Uma EVM privada é uma cadeia compatível com Ethereum que não é a rede pública do Ethereum: mesmo bytecode, mesmos contratos Solidity, mesmas ferramentas para desenvolvedores, mas operada por uma instituição ou por um pequeno grupo delas, com o público impedido, por padrão, de ler seus dados. Os bancos querem isso especificamente para poder reutilizar uma década de padrões de contratos inteligentes auditados e contratar desenvolvedores sem divulgar cada operação aos concorrentes. Essa parte é simples.
O que me levou a investigar foi um fato específico: o software no qual o próprio Private Network Hub da Rayls é executado, o Hyperledger Besu, já vem com uma forma integrada de fazer exatamente isso. Em vez disso, a Rayls constrói outra coisa. Eu queria saber por quê.
A Besu já tem um recurso de privacidade
A Besu chama isso de transações privadas, e o mecanismo é específico. O nó do remetente passa a transação para um nó Tessera emparelhado, que a criptografa e a distribui ponto a ponto aos nós Tessera de todos os demais participantes do negócio. Apenas uma transação marcadora de privacidade, um hash que aponta para essa troca off-chain, é registrada na blockchain propriamente dita. A documentação da própria Besu descreve o resultado como dois sistemas paralelos: "a transação privada distribuída aos participantes envolvidos e a transação marcadora de privacidade (PMT) incluída na blockchain pública."
Isso é privacidade por segregação: o conteúdo simplesmente nunca chega a ninguém de fora do negócio. É a mesma categoria usada nos próprios materiais de marketing da Rayls, em reportagens anteriores sobre essa plataforma, para descrever produtos concorrentes.
É aqui que os detalhes ficam específicos e datados.
O recurso está sendo descontinuado
A documentação atual da própria Besu afirma isso em termos quase idênticos em cinco páginas diferentes: "A privacidade baseada em Tessera foi descontinuada na versão 24.12.0 da Besu e nas posteriores." É um aviso permanente, não uma nota de roteiro, repetida na visão geral de privacidade, na página de transações privadas, na página de processamento, na página de grupos de privacidade e na página de plugins.
Essa descontinuação remonta a um anúncio específico e nominal. Os mantenedores da Besu publicaram-no em 24 de setembro de 2024, com o título "Encerrando o Tessera e simplificando a Besu", e deram um motivo direto: o Tessera "não tem desempenho suficiente para os casos de uso pretendidos". A mesma publicação apontou o caminho de substituição: soluções de privacidade na camada de aplicação, desenvolvidas fora do cliente base da Besu, eram robustas e eficientes o bastante para que a Besu não precisasse mais manter sua própria versão.
As notas de versão da própria Besu registram a remoção efetiva do recurso na versão 25.6.0, lançada em 4 de junho de 2025, na linha do changelog "Remover o recurso de privacidade do Tessera". Comparando com registros de versões independentes, isso ocorreu cerca de oito meses após o anúncio e quase exatamente oito anos e oito meses depois do primeiro lançamento do Quorum, antecessor conceitual do Tessera. As versões atuais da Besu removeram por completo a privacidade baseada em Tessera: já não se trata apenas de um recurso desaconselhado.
Há uma segunda limitação mais antiga que vale a pena conhecer, pois está diretamente ligada à história da própria Rayls. A documentação da Besu há muito alerta para não executar transações privadas em produção com um mecanismo de consenso em que ocorram bifurcações, citando especificamente proof-of-work e Clique, e classificava essa combinação como um recurso de acesso antecipado já na versão 1.4 da Besu. O próprio livro-razão Sovereign da Rayls usava exatamente esse mecanismo de consenso, Clique, antes de migrar para o Axyl em 2026. Se a Rayls quisesse usar a privacidade nativa da Besu na sua antiga infraestrutura, a documentação da própria Besu teria recomendado que não executasse essa combinação em produção.
Mesmo deixando de lado a descontinuação e o alerta sobre o Clique, a própria arquitetura não se adapta bem a uma rede institucional em crescimento. Os grupos de privacidade da Besu são definidos no momento da criação. A documentação é categórica: "Depois de criado, não é possível alterar os membros de um grupo de privacidade." Adicionar um banco comercial a um grupo existente significa formar um grupo inteiramente novo e migrar qualquer estado mantido pelo grupo antigo.
Por que os bancos queriam esse tipo de produto
Essa necessidade surgiu quase uma década antes da Rayls. O J.P. Morgan apresentou o Quorum em outubro de 2016, um cliente Go Ethereum modificado para ocupar um espaço entre o totalmente privado e o totalmente público, para derivativos e pagamentos, segundo a reportagem da época da Fortune. O projeto substituía os dados privados por hashes criptográficos numa cadeia compartilhada, e um engenheiro do JPMorgan descreveu o resultado, na época, como "uma separação clara entre o privado e o público". Esse é o mesmo problema, resumido em duas palavras, que uma EVM privada sempre existiu para resolver: infraestrutura compartilhada, público excluído.
A ConsenSys adquiriu o Quorum do J.P. Morgan em agosto de 2020 e incorporou seu desenvolvimento ao que se tornou o ConsenSys Quorum, oferecido por meio de dois clientes: GoQuorum e, cada vez mais, a própria Besu. A privacidade baseada em Tessera é descendente direta daquele projeto original de 2016, a primeira resposta amplamente adotada pelo setor à questão de como um banco pode ter privacidade numa cadeia EVM.
O que a Rayls construiu em vez disso
A estrutura Enygma da Rayls não tira os dados privados da cadeia. Ela os mantém no Hub, criptografados e envolvidos em provas de conhecimento zero, verificáveis por qualquer pessoa capaz de ler a cadeia, mas sem que essa pessoa consiga lê-los. Um Operador de Rede Privada recupera as chaves de visualização das instituições, criptografadas para ele durante o registro, e pode ler todas as transferências; os participantes têm chaves de gasto separadas, que podem autorizar movimentações de valor, mas nunca foram concebidas para descriptografar os dados de terceiros. Adicionar uma nova instituição significa registrar uma nova chave de visualização, não reconstruir um grupo.
Verifiquei a documentação da própria Rayls sobre o Hub, o gerenciamento de chaves e o Enygma, especialmente as páginas que descrevem o Hub de Rede Privada baseado na Besu, em busca de qualquer menção ao Tessera, a grupos de privacidade ou a uma transação marcadora de privacidade — o vocabulário do software que o Hub realmente executa. Nenhuma das páginas consultadas usa esses termos. Essa ausência se estende a documentos em que seria natural mencioná-los caso a Rayls estivesse sobrepondo sua privacidade ao recurso nativo da Besu, em vez de substituí-lo. Isso sugere que está construindo algo separado, embora uma ausência como essa não chegue a ser prova conclusiva.
Também foi possível acessar diretamente o repositório público de início rápido para hackathons da Rayls, o que ofereceu mais um lugar para verificar. Ele documenta a camada separada do Nó de Privacidade baseado em Reth, e não o Hub baseado em Besu, portanto não confirma nem descarta o uso do Tessera especificamente no Hub. É uma evidência sobre outra parte da infraestrutura.
Há também um custo mensurável no recurso que a Rayls parece ter deixado de lado. Um teste acadêmico independente de uma implantação ativa de Besu e Tessera, publicado no arXiv em 2025, registrou uma latência média superior a 5 segundos para a implantação de contratos privados, com chamadas individuais a funções privadas variando de cerca de 1 a mais de 6 segundos. O estudo atribuiu isso especificamente à criptografia, à distribuição off-chain de cargas úteis e à coordenação de consenso que o Tessera acrescenta ao processamento normal da Besu. É uma evidência independente e mensurada de que a privacidade baseada em segregação tem seus próprios custos adicionais, separados e além de quaisquer custos que uma abordagem criptográfica possa trazer.
A pergunta e o que as evidências realmente sustentam
Se a Besu já tem uma maneira integrada de tornar as transações privadas, por que alguém que usa a Besu precisaria de uma segunda camada de privacidade separada?
Três fatos distintos, considerados em conjunto, apontam na mesma direção. Os próprios mantenedores da Besu anunciaram a aposentadoria do recurso em setembro de 2024 e concluíram sua remoção em junho de 2025, citando o desempenho com essas palavras. A própria documentação da Besu desaconselhava o mecanismo de consenso Clique, justamente aquele usado pelo próprio livro-razão da Rayls durante a maior parte de sua história. E os grupos de privacidade do recurso, estáticos e que só podem ser recriados, eram estruturalmente incompatíveis com uma rede que, segundo a própria documentação da Rayls, é construída à medida que novas instituições são admitidas, uma de cada vez. Cada um desses três pontos é uma incompatibilidade específica e datada entre o que a ferramenta nativa da Besu oferecia e o que o padrão de crescimento documentado pela própria Rayls exige.
Por que essa distinção importa na prática
Uma instituição que avalia "precisamos da Rayls ou podemos simplesmente executar a Besu com o Tessera?" está, na verdade, fazendo duas perguntas distintas que por acaso envolvem o mesmo fornecedor — e a resposta para a segunda tem prazo de validade. O modelo de segregação da Besu confiava que os operadores dos nós manteriam os dados totalmente fora do registro público e não exigia dos desenvolvedores nada mais complexo do que as ferramentas comuns do Ethereum, exatamente o que o Quorum prometeu aos bancos em 2016. Mas essa implementação específica já não é distribuída nas versões atuais da Besu.
O modelo criptográfico da Rayls confia na matemática, não na disciplina dos operadores; permite que a rede cresça pelo registro de chaves individuais, em vez de exigir a reconstrução de grupos fixos; e funciona com um software cuja remoção foi concluída pelos mantenedores, conforme descrito acima, oito meses após o anúncio.
Esta é uma resposta específica e datada a uma pergunta específica. É a documentação da própria Besu que explica por que uma cadeia que executa Besu precisaria de algo que a Besu já não oferece por completo.