A página de emendas conhecida 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éstimo, e o blog do XRPL definiu a votação padrão como Sim devido à importância dessas correções.
O processo de emenda requer mais de 80% de apoio de validadores confiáveis sustentado 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 exigiria um fork real, pois sua resposta revela como funciona a legitimidade do protocolo em qualquer blockchain.
O ponto central de Schwartz é que a contagem bruta de nós é um mau indicador do poder de consenso. Um sistema onde os nós votam proporcionalmente ao seu número cria uma superfície de ataque onde qualquer pessoa pode criar milhares de máquinas a baixo custo.
No modelo do XRPL, cada operador de servidor mantém um conjunto selecionado de validadores nos quais o servidor confia para não conspirarem, a Lista Única de Nós, e a UNL determina quais votos de validação o servidor conta durante o consenso.
O processo de emenda do XRPL requer apoio de mais de 80% dos validadores confiáveis sustentado por duas semanas antes que as novas regras se tornem permanentes, bloqueando servidores não atualizados.
Um servidor recebe mensagens de validação de muitos nós na rede, e os validadores da sua UNL determinam quais dessas mensagens moldam a visão do servidor sobre o livro-razão.
Schwartz explicou que a legitimidade do consenso no XRPL flui através das listas de confiança e da coordenação dos validadores, produzindo um sistema em que o alinhamento da UNL e a adoção econômica determinam qual livro-razão sobrevive a uma divisão.
Por que um fork real exige uma campanha completa de coordenação
Para a votação do XRPL em 27 de maio, os servidores que ficam bloqueados por emenda perdem a capacidade de determinar a validade do livro-razão, enviar ou processar transações, participar do consenso ou votar em futuras emendas.
A infraestrutura bloqueada por emenda perde acesso à cadeia atualizada e carece da 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 livro-razão para seguir.
Eles então precisariam de uma Lista Única de Nós concorrente que os servidores possam configurar ou que o software possa usar por padrão, porque sem uma lista confiável de validadores, os nós não têm mecanismo para coordenar-se em torno das regras antigas.
Além disso, precisariam de uma distribuição de código que preserve as regras antigas e venha com padrões apontando para a UNL rival, e precisariam de suporte de infraestrutura de carteiras, exchanges, exploradores e aplicativos suficiente para tornar o livro-razão das regras antigas acessível e negociável.
Um fork credível do XRPL requer cinco camadas além dos nós não atualizados: validadores das regras antigas, uma UNL rival, código das regras antigas, suporte de infraestrutura e reconhecimento do mercado.
A documentação do XRPL cita pesquisas mostrando que UNLs concorrentes podem precisar de 90% de sobreposição no pior caso para evitar um fork, o que significa que qualquer UNL rival precisaria compartilhar quase todo o conjunto de validadores confiáveis com a canônica para manter a coerência interna.
Um fork formado em torno de um conjunto radicalmente diferente de validadores corre o risco de produzir um livro-razão que não consiga sustentar seu próprio consenso, muito menos atrair a adoção do mercado.
O que o processo de emenda realmente acompanha é o apoio dos validadores, e o limiar de 80% por duas semanas garante que as entidades nas quais a rede confia tenham chegado a um acordo durável antes que as novas regras se tornem permanentes.
Uma grande parte dos nós não atualizados que não são validadores pode refletir atrasos na infraestrutura sem implicar nada sobre a trajetória do livro-razão canônico.
A distância entre o atraso na infraestrutura e uma cadeia rival
No cenário pessimista, exchanges, carteiras ou operadores de infraestrutura que ficarem para trás da ativação de 27 de maio ficam bloqueados por emenda e deixam de funcionar como participantes do livro-razão.
Os usuários que passam por esses provedores enfrentam interrupções de 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 pouco a atualização, e vale a pena acompanhá-lo, especialmente para qualquer grande exchange ou custodiante que ainda esteja rodando nós pré-3.1.3 na ativação.
Um atraso sustentado na infraestrutura entre suficientes provedores criaria fricção real para os usuários mesmo que o livro-razão canônico continue sob as novas regras.
No cenário otimista, fixCleanup3_1_3 é ativado conforme o programado com a supermajoria de validadores intacta, os operadores de infraestrutura atualizam sem incidentes importantes e o episódio se torna uma ativação rotineira de emenda.
As correções para NFTs, Domínios com Permissão, Vaults e o Protocolo de Empréstimo entram em vigor, e a rede segue em frente. O debate sobre governança surgido com a atualização sobrevive a qualquer resultado, porque a explicação de Schwartz sobre o que exigiria uma divisão real aplica-se a qualquer futura emenda.
Sustentar as regras antigas exige que um grupo dissidente execute o software antigo, recrute validadores em torno de uma UNL concorrente e convença carteiras, exchanges e mercados a reconhecerem seu livro-razão como o Livro-razão canônico de XRP, contra uma configuração padrão que aponta todos os outros para a cadeia atualizada.
Toda blockchain tem uma camada de governança
Schwartz fez uma comparação com o Stellar, cuja atualização do Protocolo 24 é ela mesma 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 de validadores.
A camada de legitimidade equivalente do Bitcoin passa por mineradores, nós econômicos, implementações de clientes e listagens de exchanges. 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 através das UNLs, outras redes incorporam na distribuição do poder de mineração, economia de staking ou no consenso social em torno do qual os desenvolvedores de software de cliente confiam.
Os mecanismos diferem entre Bitcoin, Ethereum e XRPL, enquanto a dependência de decisões humanas coordenadas para tornar as mudanças de regra permanentes atravessa os três.
A ativação de 27 de maio ilustra como a camada de governança do XRPL converte o acordo de validadores em permanência do livro-razão, com a configuração da UNL determinando quais acordos contam.
Um operador que discorda do fixCleanup3_1_3 tem a liberdade técnica de executar o software antigo e configurar uma UNL rival.
Se alguma exchange listará o token resultante, se alguma carteira o suportará ou se algum market maker fornecerá liquidez é uma questão que o protocolo não pode responder por eles.
Essa desconexão de coordenação é o motivo pelo qual as atualizações de protocolo em redes bem adotadas raramente produzem forks duráveis: 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 decidir ser real.
O post A atualização do XRPL em 27 de maio mostra como validadores e mercados decidem uma divisão de blockchain apareceu primeiro em CryptoSlate.