A página de emendas conhecidas do XRPL lista fixCleanup3_1__3 para ativação em 27 de maio e, por design, o evento é uma atualização de manutenção.
A versão 3.1.3 do rippled inclui correções para NFTs, Domínios com Permissão, Vaults e o Protocolo de Empréstimos, e o blog do XRPL definiu o voto padrão como Sim devido à importância dessas correções.
O processo de emenda exige mais de 80% de apoio de validadores confiáveis mantido por duas semanas antes que as novas regras se tornem permanentes.
O que torna o episódio digno de análise além do prazo é o que o co-criador do XRPL David Schwartz disse sobre o que realmente seria necessário para um fork, pois sua resposta revela como a legitimidade do protocolo funciona em qualquer blockchain.
O ponto central de Schwartz é que o número bruto de nodes é um proxy fraco para o poder de consenso. Um sistema onde os nodes votam na proporção de seu número cria uma superfície de ataque onde qualquer um pode iniciar milhares de máquinas com baixo custo.
No modelo XRPL, cada operador de servidor mantém um conjunto curado de validadores que o servidor confia para não coludir, a Unique Node List, e a UNL determina quais votos de validação o servidor considera durante o consenso.
Um servidor recebe mensagens de validação de muitos nodes na rede, e os validadores na sua UNL determinam quais dessas mensagens moldam a visão do servidor sobre o ledger.
Schwartz explicou que a legitimidade do consenso no XRPL flui por meio de listas de confiança e coordenação de validadores, produzindo um sistema no qual o alinhamento da UNL e a adoção econômica determinam qual ledger sobrevive a uma divisão.
Por que um fork real exige uma campanha de coordenação completa
Para a votação do XRPL em 27 de maio, os servidores que se tornarem bloqueados por emenda perdem a capacidade de determinar a validade do ledger, enviar ou processar transações, participar do consenso ou votar em emendas futuras.
Isso torna o prazo operacionalmente importante para qualquer exchange, carteira, Explorador ou operador de infraestrutura ainda executando software pré-3.1.3, pois esses servidores se tornam não participantes do livro-razão canônico até que o operador atualize.
A infraestrutura bloqueada por emenda perde o acesso à cadeia atualizada e não possui a infraestrutura de coordenação para ancorar uma rival funcional.
Para produzir um fork credível, um grupo dissidente precisaria de validadores dispostos a continuar produzindo livros-razão sob as regras antigas, e sem validadores, não há fluxo de livros-razão para seguir.
Eles precisariam então de uma Lista de Nós Únicos concorrente que os servidores possam configurar ou que o software possa usar como padrão, pois, sem uma lista de validadores confiáveis, os nós não têm mecanismo para coordenar em torno das antigas regras.
Além disso, eles precisariam de uma distribuição de código que preserve as regras antigas e venha com padrões apontando para a UNL concorrente, e precisariam de suporte de infraestrutura de carteiras, exchanges, exploradores e aplicativos suficiente para tornar o ledger das regras antigas acessível e negociável.
A documentação do XRPL cita pesquisas que mostram que, no pior caso, UNLs concorrentes podem precisar de 90% de sobreposição para evitar um fork, o que significa que qualquer UNL rival precisaria compartilhar quase todo o conjunto de validadores confiáveis com o conjunto canônico para manter a coerência interna.
Um fork formado em torno de um conjunto de validadores radicalmente diferente corre o risco de produzir um livro-razão que não consegue sustentar seu próprio consenso, muito menos atrair a adopção do mercado.
O que o processo de emenda realmente rastreia é o suporte dos validadores, e o limiar de 80% por duas semanas garante que as entidades que a rede confia alcançaram um acordo duradouro antes que novas regras se tornem permanentes.
Uma grande parte dos nós não validadores não atualizados pode refletir atraso na infraestrutura sem implicar qualquer coisa sobre a trajetória do livro-razão canônico.
A distância entre o atraso na infraestrutura e uma cadeia concorrente
No cenário de baixa, as exchanges, carteiras ou operadores de infraestrutura que atrasarem a ativação em 27 de maio tornam-se bloqueados por emenda e param de funcionar como participantes do livro-razão.
Usuários que passam por esses provedores enfrentam interrupções no serviço, como transações que não podem ser enviadas, exploradores que não conseguem confirmar a validade do livro-razão e aplicativos que não conseguem processar pagamentos.
Esse custo operacional recai sobre os operadores que priorizaram a atualização, e vale a pena monitorar, especialmente para qualquer exchange ou custodiante importante ainda executando nós pré-3.1.3 na ativação.
Um atraso sustentado na infraestrutura em fornecedores suficientes criaria atrito real para os usuários, mesmo enquanto o livro-razão canônico continua sob as novas regras.
No cenário de alta, o fixCleanup3_1_3 é ativado conforme o cronograma com a supermaioria dos validadores intacta, os operadores de infraestrutura atualizam sem incidentes maiores e o episódio se torna uma ativação de alteração rotineira.
As correções para NFTs, Domínios Permitidos, Vaults e o Protocolo de Empréstimo entram em vigor, e a rede avança. O debate de governança suscitado pela atualização sobrevive a qualquer resultado, pois a explicação de Schwartz sobre o que exigiria uma verdadeira divisão aplica-se a qualquer futura emenda.
Manter regras antigas exige um grupo dissidente executando software antigo, recrutando validadores em torno de uma UNL concorrente e convencendo carteiras, exchanges e criadores de market a reconhecerem seu livro-razão como o Ledger XRP canônico, contra uma configuração padrão que direciona todos os demais para a cadeia atualizada.
Cada blockchain possui uma camada de governança
Schwartz fez uma comparação com o Stellar, cuja atualização do Protocolo 24 é, por sua vez, uma correção de estabilidade para um bug de arquivamento de estado no Stellar Core, que foi um evento de manutenção exigindo o mesmo tipo de adoção coordenada dos validadores.
A camada de legitimidade equivalente do bitcoin passa por mineiros, nós econômicos, implementações de clientes e listagens no exchange. A do ethereum passa por validadores, infraestrutura de staking, diversidade de clientes, desenvolvedores principais e adoção na camada de aplicativos.
O que o XRPL torna explícito por meio de UNLs, outras redes incorporam na distribuição de poder de mineração, na economia de staking ou no consenso social em torno do qual os desenvolvedores de software cliente confiam.
Os mecanismos diferem entre bitcoin, ethereum e XRPL, enquanto a dependência de decisões humanas coordenadas para tornar permanentes as alterações nas regras permeia os três.
A ativação de 27 de maio ilustra como a camada de governança do XRPL converte o acordo dos validadores em permanência do livro-razão, com a configuração UNL determinando quais acordos são considerados.
Um operador que discorda do fixCleanup3_1_3 tem a liberdade técnica de executar software antigo e configurar uma UNL rival.
Se alguma exchange lista o token resultante, se alguma carteira o suporta ou se algum criador fornece liquidez é uma pergunta que o protocolo não pode responder por eles.
Essa desconexão de coordenação é a razão pela qual atualizações de protocolo em redes amplamente adotadas raramente produzem forks duradouros: a economia de seguir a cadeia canônica quase sempre supera a economia de construir uma cadeia paralela do zero, e a cadeia canônica é aquela que o mercado decide como real.
A postagem XRPL’s May 27 upgrade shows how validators and markets decide a blockchain split apareceu primeiro em CryptoSlate.