A resposta curta
Eu queria saber o que um banco obtém quando uma cadeia anuncia "finalidade determinística em menos de um segundo" e por qual relógio esse segundo é medido. No caso do consenso Axyl da Rayls, minha análise aponta para uma resposta dividida. O projeto é um protocolo tolerante a falhas bizantinas que pode oferecer finalidade determinística: assim que a camada de consenso confirma uma transação, os nós honestos concordam sobre sua posição, desde que menos de um terço do poder de voto do comitê esteja comprometido. Não encontrei uma definição publicada do momento em que um cliente pode considerar uma transação final. Também não consegui analisar os números de benchmark por trás da alegação de "menos de um segundo", pois eles aparecem em imagens.
A propriedade está documentada como parte do projeto, e a velocidade está documentada como uma afirmação. Nenhuma das duas foi verificada por medições minhas.
Por que a liquidação depende da finalização
Uma liquidação é uma promessa de que um pagamento não pode ser desfeito. Ambas as partes precisam de um momento definido a partir do qual liberam bens, dinheiro ou a etapa seguinte de uma negociação. Em uma cadeia, a questão é o que garante esse momento.
A resposta do Ethereum está explícita na página
ethereum.org
sobre o Gasper (atualizada pela última vez em 3 de abril de 2026). Um bloco é justificado quando dois terços do ether em stake votam nele e é finalizado quando outro bloco justificado é adicionado acima dele. Apenas checkpoints nos limites das épocas se qualificam. Depois disso, reverter o bloco exige que um atacante destrua pelo menos um terço de todo o ether em stake. A página
ethereum.org
sobre a proposta de blocos informa slots de 12 segundos e épocas de 32 slots (6,4 minutos), então duas épocas consecutivas totalizam 12,8 minutos. Esse número é resultado do meu cálculo, e o tempo exato de espera de uma transação depende de onde ela cai dentro de uma época.
Aqui, a finalização é um estado definido, com um preço associado. Um banco pode incorporá-la a uma política.
A Rayls oferece algo diferente. De acordo com a página de arquitetura da Rayls, sua cadeia pública funciona no Axyl desde o lançamento da mainnet, em 30 de abril de 2026, e um comunicado à imprensa de 19 de março de 2026 já havia prometido finalização instantânea na testnet do Axyl. Isso parece melhor do que 12,8 minutos. A pergunta útil é o que cada número mede.
Versões datadas de uma mesma afirmação
Um comunicado da Rayls na GlobeNewswire, datado de 19 de março de 2026, que li no FinTech Futures, diz que a equipe lançou uma testnet pública atualizada com tecnologia Axyl, cujos recursos incluem "tempos de bloco inferiores a um segundo, finalização instantânea, mais de 15 mil TPS".
Um comunicado sobre o lançamento da mainnet em maio de 2026 também apresenta uma afirmação sobre finalização. Só consegui ver um trecho nos resultados de busca, porque a página que o hospedava não carregou; por isso, esta nota não se baseia nele.
A documentação da Rayls repete a manchete em várias páginas. Introducing the Rayls Public Chain (modificada em 25 de agosto de 2026) promete finalização determinística em menos de um segundo para uma "liquidação instantânea e irreversível". Why Rayls? (24 de agosto de 2026) diz que o Axyl oferece finalização forte em menos de um segundo, "sem risco de reorganizações da cadeia". A página de arquitetura (6 de outubro de 2026) informa que o Axyl está na mainnet desde 30 de abril de 2026 e repete o número de mais de 15.000 TPS. Nenhuma delas identifica o evento que inicia ou encerra a contagem do tempo.
As páginas do Axyl não apresentam números de latência, e a página de benchmark (25 de agosto de 2026) registra, em imagens, resultados de protótipos na camada de consenso com quatro nós, transações de 512 bytes, lotes de 500 KB e um atraso de lote de 50 ms.
Duas fontes primárias discordam quanto ao número principal. O comunicado de março diz mais de 15 mil TPS, enquanto o README do repositório Axyl, que consultei em 19 de outubro de 2026, diz que o protocolo tem como meta mais de 10.000 TPS. O mesmo README informa que a Halborn auditou o protocolo de consenso, com três avaliações entre fevereiro e março de 2026 e revisões de correções em abril e maio.
Volto sempre a essa lista. O tempo de bloco é uma duração, TPS é uma taxa e finalização é uma garantia, mas o comunicado os coloca lado a lado como se fossem o mesmo tipo de número. Instantâneo a partir de qual evento? O comunicado não esclarece, e a documentação descreve os mecanismos com detalhes suficientes para permitir uma pergunta precisa.
O que a documentação diz que acontece com uma transação
Conforme documentado. As especificações técnicas do Axyl dizem que as transações só são executadas depois que a camada de consenso as confirma. A página de consenso de outubro apresenta a regra de confirmação: um líder confirma quando os certificados da rodada seguinte, que somam pelo menos f+1 de poder de voto, fazem referência a ele; então, seu histórico é achatado em uma única ordem determinística. Cada lote no sub-DAG confirmado se torna um bloco EVM, executado estritamente um após o outro. Uma transação considerada inválida durante a execução é ignorada, sem recibo nem taxa, e não há mempool público.
Verificado pela leitura do código (nada foi executado). Em
bullshark.rs
na branch main, commit_leader soma o poder de voto dos certificados da rodada seguinte cujos cabeçalhos fazem referência ao líder e confirma quando essa soma atinge o limiar de validade do comitê. O quórum maior é usado em outros pontos, para confirmações de lote, pais de cabeçalho e certificados. O arquivo elege um líder por rodada par e não tem lógica de líder substituto, o que corresponde a uma leitura do Bullshark sob sincronia parcial, embora eu não o tenha comparado linha por linha com o artigo. Uma divergência: a documentação diz que o líder é verificado duas rodadas antes, enquanto o código verifica a rodada imediatamente anterior ao certificado que está sendo inserido. Li o código uma vez, e a equipe da Rayls(
@x10xalex
) deve confirmar qual é o atual.
A finalização no Axyl é, portanto, um evento de consenso, e o recibo é um evento de execução posterior. Uma transação pode ser confirmada e depois ignorada, sem deixar nada para consultar. A documentação orienta os dApps a manterem seus próprios hashes de transação e, após um tempo limite de "algumas épocas", considerar que uma transação sem recibo foi descartada. A mesma página define uma época como 24 horas e lista um endpoint de status como parte do roadmap.
O documento de visão geral do repositório Axyl (doc/index.md) acrescenta dois detalhes verificáveis. O endpoint rayls_latestHeader retorna o topo da cadeia de consenso, e cada cabeçalho de bloco EVM contém o resumo do cabeçalho de consenso que o produziu, com a época e a rodada compactadas no campo nonce. Portanto, um cliente pode relacionar um bloco de execução a uma rodada confirmada. Os arquivos que li não dizem se a tag padrão finalized está vinculada a essa confirmação. A visão geral também mantém separados dois registros de comitê: o contrato on-chain ConsensusRegistry e o EpochRecord assinado com seu EpochCertificate, fornecido pelo rayls_epochRecord e verificado pelos nós em sincronização.
A mesma visão geral contradiz a documentação do site em um ponto. O repositório diz que as taxas básicas permanecem constantes dentro de uma época. A página Technical Specs diz que elas variam a cada bloco segundo a regra EIP-1559, com apenas os parâmetros da regra recalibrados a cada época. Why Rayls? apresenta uma terceira formulação: taxas básicas atreladas ao USDC. Consultar baseFeePerGas em blocos consecutivos resolve a questão.
Minha análise. O sucesso pode ser final em menos de um segundo, enquanto a certeza sobre uma falha pode levar dias. Um sistema de liquidação precisa de um relógio para ambos os resultados.
A segunda condição é o comitê, e aqui a documentação se contradiz. A página do Axyl (6 de outubro de 2026) diz que cada época de 24 horas usa um comitê fixo, que todos os validadores têm poder de voto 1 e que a Rayls Foundation opera o conjunto no lançamento. Why Rayls Built an L1 (25 de agosto de 2026) chama os validadores de instituições financeiras confiáveis e diz que o Axyl funciona "em um ambiente sem permissões", enquanto a página de arquitetura diz que qualquer instituição pode optar por executar validadores da cadeia pública. Considero a página mais recente e específica, a do Axyl, como o retrato de hoje, e as outras como intenção ou roadmap. Nenhuma das páginas informa o tamanho do comitê ou uma penalidade de slashing como a queima de um terço do Gasper. Portanto, a promessa de não haver reorganizações da cadeia significa que não haverá reorganização, a menos que validadores que detenham um terço do poder de voto falhem ou conspirem; e, segundo a página do Axyl, um único operador os administra. A primeira parte está documentada. A segunda é minha interpretação.
A finalização também varia conforme a camada, e a mesma manchete aparece em três pilhas diferentes. A página Rayls Sovereign (17 de setembro de 2026) diz que os ledgers Sovereign migraram para o Axyl em julho de 2026, substituindo o proof of authority do Clique e um único validador Geth, enquanto o Private Network Hub continua executando Besu com proof of authority. A página do Hub (6 de outubro de 2026) é menos específica. Diz que o Hub pode ser qualquer plataforma EVM, recomenda o Besu e afirma alcançar mais de 15.000 TPS com finalização em menos de um segundo para uma Private Network, "dependendo da configuração e dos tipos de transação", ao agrupar milhares de transações em uma única transação do Hub. Nenhuma página da Rayls especifica o modo do Besu.
A documentação do próprio Besu (atualizada em 13 de outubro de 2026) diz que QBFT e IBFT 2.0 têm finalização imediata e que o Besu não oferece mais suporte ao Clique; portanto, o modo determina se a finalização do Hub é sequer imediata. A página do Hub também diz que os ledgers Sovereign publicam seus cabeçalhos de bloco no Hub a cada poucos segundos, e que as provas de transação são verificadas em relação a essas confirmações. Assim, um pagamento entre ledgers é validado em intervalos de segundos, enquanto a inclusão no Hub pode ser mais rápida. Não consegui determinar a latência de ponta a ponta.
Analisando os números
A configuração do benchmark corresponde à referência do artigo Narwhal and Tusk (EuroSys 2022, arXiv 2105.11827 v4): quatro validadores, lotes de 500 KB e transações de 512 bytes. Essa correspondência é uma observação minha. O artigo mediu a latência desde o envio pelo cliente até a confirmação pelo líder, em uma WAN distribuída por cinco regiões da AWS, e relata que o Narwhal-HotStuff supera 130.000 tx/s em menos de dois segundos. O artigo Bullshark (arXiv 2201.05677 v3, setembro de 2022) relata 125.000 tx/s em dois segundos com 50 participantes.
Verificado independentemente (cálculo meu, Python da biblioteca padrão; o script está em Execute você mesmo). Os parâmetros dos lotes limitam um worker a cerca de 19.500 tx/s, então 15.000 TPS de payload de 512 bytes, cerca de 7,7 MB/s, cabem na camada de consenso. O quórum documentado, floor(2N/3)+1, garante que dois quóruns se sobreponham em pelo menos f+1 nós para qualquer poder de voto total N entre 4 e 300 (no lançamento, cada validador tem poder 1, então N é a quantidade de validadores), e equivale a 2f+1 somente quando N = 3f+1. Por exemplo, com N = 8, o quórum é 6, enquanto 2f+1 é 5. O limiar de validade documentado equivale a f+1 para todo N nesse intervalo.
A execução é uma medição separada. Os autores do Narwhal escreveram que uma alta taxa de transferência só ajuda se um mecanismo de execução conseguir acompanhá-la, e adiaram a construção de um para trabalhos futuros. O Axyl executa um lote por bloco EVM, em sequência. Com 21.000 gas por transferência simples, 15.000 TPS significam 315 milhões de gas por segundo, e um lote completo tem 20,5 milhões de gas. As páginas que li não especificam um limite de gas por bloco, portanto, o TPS da camada de consenso e o TPS de ponta a ponta continuam sendo dois números distintos.
Um comitê de laboratório com quatro nós e uma implantação WAN com 50 participantes não podem ser comparados na mesma escala de latência; portanto, os números do artigo não verificam a afirmação do Axyl.
Diferenças entre Ethereum e os artigos sobre DAG
A diferença. O Ethereum finaliza checkpoints ao longo de duas épocas e sustenta o resultado com um stake que pode ser destruído. Os protocolos DAG por trás do Axyl confirmam líderes em rodadas e baseiam a segurança na fração de participantes defeituosos do comitê permanecer abaixo de um terço.
A afirmação da própria Rayls sobre a finalização do Ethereum não se sustenta tal como foi escrita. Why Rayls Built an L1 classifica o Ethereum L1 como desprovido de finalização determinística, enquanto a página Gasper descreve checkpoints finalizados que não podem ser revertidos sem destruir um terço do stake. Ambas as páginas são fontes primárias, e só concordam se a tabela estiver se referindo a algo instantâneo e incondicional, como sugere o texto da própria página sobre finalização determinística em menos de um segundo. Nessa interpretação, a garantia do Axyl também é condicional: depende de menos de um terço do poder de voto estar comprometido.
Por que isso importa. A palavra "final" é respaldada por coisas diferentes. No Ethereum, trata-se de um custo econômico; no Axyl, no lançamento, da integridade dos validadores de um único operador.
A contrapartida. O projeto do Axyl ganha velocidade e abre mão, por enquanto, da descentralização e dos incentivos econômicos de slashing que tornam caro atacar a finalização mais lenta do Ethereum.
O que muda na prática. Quem integra o Ethereum espera pelo estado finalized. Quem integra o Axyl primeiro precisa descobrir qual sinal indica a confirmação e, depois, acompanhar os próprios envios, já que falhas não deixam recibo.
Conclusão
A finalização determinística é uma promessa em duas partes: uma regra que fixa a ordem e uma razão para acreditar que ninguém pode quebrar essa regra. O Axyl documenta a regra em detalhes. A confirmação exige o apoio de f+1, e a execução vem depois da confirmação. Hoje, a razão para acreditar nisso depende do comitê de um único operador, e o número de menos de um segundo se apoia em imagens de benchmarks e em uma versão que lista a finalização ao lado do tempo de bloco e do TPS. Antes de confiar nisso, uma equipe de liquidação deve fazer três perguntas: qual sinal indica a confirmação, o que acontece com uma transação ignorada e quem controla dois terços do poder de voto.