A emenda Batch V1.1 do XRP Ledger avançou para a uma votação de validador de iniciar seu processo de ativação de duas semanas depois que os desenvolvedores corrigiram outros 11 problemas de software descobertos durante revisões de segurança.
Resumo
- O Batch V1.1 do XRP Ledger garantiu 27 dos 35 votos de validadores, ficando a um voto do limite de ativação de 80%.
- Os desenvolvedores corrigiram outros 11 problemas envolvendo assinaturas, verificações de autorização e possíveis travamentos de servidor antes da votação mais recente.
- O Batch permitiria aos usuários combinar até oito transações em uma única operação e exigir que pagamentos vinculados fossem concluídos juntos.
- A versão atual substituiu uma proposta anterior do Batch depois que pesquisadores encontraram uma falha grave de autorização antes que ela chegasse à mainnet.
A RippleX disse na segunda-feira que a revisão mais recente do Batch V1.1 identificou problemas envolvendo assinaturas de transações, verificações de autorização e travamentos de servidor, com as correções incorporadas à versão agora em consideração pelos validadores do XRP Ledger.
O apoio estava em 27 dos 35 validadores confiáveis na terça-feira, equivalente a aproximadamente 77%, deixando a proposta logo abaixo do nível de 80% exigido para entrar no período de ativação da rede.
Atualização Batch do XRP Ledger se aproxima de 80% de apoio
O Batch V1.1 permitiria que até oito transações fossem agrupadas em uma única operação, com regras de execução que podem exigir que transações vinculadas sejam bem-sucedidas juntas.
Para uma troca de tokens entre dois usuários, o recurso poderia tornar ambas as transferências dependentes uma da outra. Se um lado da troca falhar, a outra transação não seria concluída independentemente.
Carteiras e marketplaces poderiam usar a mesma estrutura para processar um pagamento de cliente e uma taxa de plataforma juntos. A RippleX disse que projetos comerciais usando o Batch já estão sob contrato ou em desenvolvimento, embora a equipe de desenvolvedores não tenha identificado publicamente as empresas envolvidas.
O apoio dos validadores aumentou rapidamente na última semana. Em 8 de setembro, o Batch V1.1 tinha 24 votos dos 35 validadores na Lista de Nós Únicos padrão, equivalente a 68,57%, informou anteriormente o crypto.news. Mais três validadores desde então apoiaram a emenda.
Sob as regras de governança do XRP Ledger, uma emenda deve manter pelo menos 80% de apoio dos validadores por 14 dias consecutivos antes de poder ser ativada. Com 35 validadores confiáveis atualmente contados, outro voto de apoio levaria o Batch V1.1 acima do limite e iniciaria esse período.
O resultado não estaria garantido assim que a contagem regressiva começar. Os validadores podem mudar suas posições, e o apoio caindo abaixo de 80% durante a janela de 14 dias interromperia o processo de ativação.
Um processo semelhante ocorreu em julho, quando a emenda fixCleanup3_2_0 garantiu 85,71% de apoio e entrou em sua janela de ativação. O pacote subsequentemente foi ativado em 29 de julho após manter apoio suficiente dos validadores pelo período exigido.
Batch V1.1 substitui uma versão anterior com uma falha grave
A votação atual segue a retirada do design original do Batch depois que pesquisadores encontraram uma vulnerabilidade antes que o recurso chegasse à mainnet do XRP Ledger.
Sob certas condições, a falha poderia ter permitido a um atacante colocar transações da conta de outro usuário dentro de um lote sem obter a autorização necessária. Nenhum fundo de usuário foi colocado em risco porque a emenda afetada nunca foi ativada.
Os desenvolvedores reconstruíram o recurso após a descoberta, com o Batch V1.1 posteriormente incluído no xrpld 3.3.0, lançado em 6 de agosto.
O lançamento do xrpld 3.3.0 introduziu a implementação corrigida do Batch junto com vários outros recursos de protocolo propostos. Cada emenda ainda requer aprovação separada dos validadores antes de se tornar ativa na mainnet.
A engenheira de software da RippleX, Mayukha Vadari, disse que o problema original de assinatura foi encontrado em fevereiro antes da implantação na mainnet. O trabalho subsequente incluiu uma correção da causa raiz, revisões por quatro engenheiros seniores, um concurso de segurança Sherlock e auditorias da Halborn e Common Prefix.
“Depois que o bug de assinatura da v1.0 foi detectado em fevereiro (pré-Mainnet, sem fundos em risco), nós o reconstruímos”, escreveu Vadari no X em 14 de setembro.
O processo de revisão não terminou com a vulnerabilidade inicial. A RippleX disse que outros 11 problemas foram encontrados enquanto a implementação substituta estava sendo examinada.
Revisões de segurança encontraram mais 11 problemas no Batch
As descobertas adicionais abrangeram tratamento de assinaturas, verificações de autorização e condições de software capazes de derrubar servidores.
A Common Prefix classificou uma das vulnerabilidades como crítica. De acordo com a revisão da RippleX, o problema poderia ter permitido a um atacante reutilizar uma permissão que um usuário havia assinado e realizar mais transações do que o usuário originalmente pretendia autorizar.
Outras descobertas envolveram a forma como as transações Batch verificavam permissões e processavam assinaturas. Os desenvolvedores resolveram os problemas relatados antes que a emenda chegasse ao seu atual estágio de votação dos validadores.
A RippleX disse que quatro engenheiros seniores revisaram a implementação, enquanto a Halborn e a Common Prefix realizaram auditorias externas. O código passou por testes automatizados e um concurso público de segurança projetado para expor fraquezas antes da ativação.
Testes de segurança têm sido usados em outras propostas recentes do XRP Ledger. Uma revisão de segurança da Common Prefix em junho identificou problemas numéricos e comportamentais em componentes do XRPL, com correções implantadas por meio da versão 3.2.0. A empresa de segurança foi subsequentemente encarregada da verificação formal e análise de outras partes da rede.
Um concurso separado do Sherlock cobrindo recursos propostos do XRP Ledger encontrou dezenas de vulnerabilidades válidas antes que as emendas afetadas chegassem à mainnet, incluindo descobertas críticas e de alta gravidade.
Batch faz parte do conjunto de recursos do xrpld 3.3.0
Batch é uma das várias mudanças de protocolo introduzidas por meio do ciclo de software 3.3.0, enquanto os desenvolvedores do XRP Ledger trabalham em liquidação de transações, privacidade, permissões e recursos institucionais.
Antes do lançamento do software, os desenvolvedores delinearam cinco emendas propostas do XRPL que incluíam transações Batch, Confidential MPT, Sponsor, Dynamic MPT e Permission Delegation.
O Batch foi projetado em torno da liquidação atômica, na qual múltiplas operações relacionadas podem ser tratadas como uma transação coordenada em vez de serem enviadas separadamente.
A Permission Delegation permitiria que uma conta concedesse autoridade restrita a outra conta sem entregar o controle total. O Confidential MPT foi projetado para ocultar saldos e valores de transferência de Multi-Purpose Tokens, mantendo as identidades das contas visíveis no ledger público.
Nenhum dos recursos se torna ativo simplesmente porque seu código está incluído no xrpld. Os validadores decidem separadamente se apoiam as emendas, deixando cada proposta em seu próprio cronograma de votação.
A rede já viu diferentes taxas de adoção entre as propostas do 3.3.0. A Ripple votou em agosto pela emenda PermissionDelegationV1_1 quando ela tinha apoio de sete dos 35 validadores confiáveis.
O Batch desde então se aproximou muito do limiar de ativação. Seus atuais 27 votos deixam a emenda a um validador de apoio de iniciar o período de 14 dias, desde que os votos existentes permaneçam em vigor.
A RippleX não nomeou os projetos comerciais que disse estarem sob contrato ou em desenvolvimento para usar o Batch. A CoinDesk disse que perguntou à equipe de desenvolvedores quais empresas estão se preparando para usar o recurso e se as 11 correções mais recentes receberam revisão independente em relação à versão atualmente sendo considerada pelos validadores.
