خوارزمية إجماع بروتوكول ريبل

Abstract

Embora existam vários algoritmos de consenso para o Byzantine Generals Problem, especificamente no que diz respeito a sistemas de pagamento distribuídos, muitos sofrem de alta latência induzida pelo requisito de que todos os nós dentro da rede se comuniquem de forma síncrona. Neste trabalho, apresentamos um algoritmo de consenso inovador que contorna esse requisito ao utilizar sub-redes coletivamente confiáveis dentro da rede maior. Mostramos que a "confiança" necessária para prevenir ataques Sybil não é, de fato, global, mas sim local a cada nó na rede.

O algoritmo de consenso do protocolo Ripple (RPCA) é aplicado a cada poucos segundos por todos os nós, a fim de manter a correção e o acordo da rede. Uma vez alcançado o consenso, o livro-razão atual é considerado "fechado" e se torna o último livro-razão fechado (last-closed ledger). Este algoritmo é único no sentido de que alcança consenso com baixa latência enquanto mantém fortes garantias contra falhas Byzantine, tornando-o adequado para sistemas de liquidação financeira em tempo real.

Introduction

Um sistema de pagamento distribuído deve implementar um algoritmo de consenso para processar pagamentos corretamente e de maneira oportuna, mesmo na presença de atores defeituosos ou maliciosos. O Bitcoin alcança consenso usando prova de trabalho (proof-of-work), que exige que todos os nós gastem recursos computacionais resolvendo quebra-cabeças criptográficos. Embora essa abordagem forneça fortes garantias de segurança, ela sofre de desvantagens significativas, incluindo alto consumo de energia, baixa taxa de transferência de transações e longas latências de confirmação que podem se estender a uma hora ou mais para transações de alto valor.

O algoritmo de consenso do protocolo Ripple fornece uma nova abordagem para o consenso distribuído que não requer prova de trabalho. Em vez disso, os nós na rede concordam coletivamente sobre conjuntos de transações através de um processo de votação que alcança consenso em questão de segundos. Este mecanismo de consenso é projetado especificamente para os requisitos de uma rede de pagamentos global, onde baixa latência e alta taxa de transferência são essenciais para a implantação prática.

A inovação-chave no RPCA é que ele não exige que todos os nós na rede concordem entre si. Em vez disso, cada nó mantém uma Lista de Nós Únicos (Unique Node List, UNL) de outros nós em que confia para não conspirar. Desde que as UNLs escolhidas pelos nós tenham sobreposição suficiente e menos de uma porcentagem limite de nós sejam defeituosos, a rede alcançará consenso. Esta abordagem fornece as garantias de segurança necessárias para um sistema de pagamento enquanto alcança latência de consenso medida em segundos em vez de minutos ou horas.

Definition of Consensus

Em sistemas distribuídos, consenso refere-se ao processo pelo qual uma rede de nós chega a um acordo sobre um estado compartilhado, apesar da presença de participantes defeituosos ou maliciosos. Um algoritmo de consenso deve satisfazer três propriedades fundamentais: correção (nenhum par de nós corretos decide de forma diferente), acordo (todos os nós corretos alcançam a mesma decisão) e terminação (todos os nós corretos eventualmente decidem). Essas propriedades garantem que o sistema distribuído se comporte como se fosse um nó único e confiável.

O desafio em alcançar o consenso decorre da inerente falta de confiabilidade dos sistemas distribuídos. Os nós podem falhar, as mensagens podem ser atrasadas ou perdidas, e os nós Byzantine podem se comportar de forma arbitrária ou maliciosa. O Byzantine Generals Problem, formalizado por Lamport, Shostak e Pease, captura esse desafio: como um grupo de processos pode chegar a um acordo quando alguma fração pode ser defeituosa e quando a comunicação não é confiável?

Os resultados clássicos em computação distribuída estabelecem limites fundamentais sobre o que os algoritmos de consenso podem alcançar. O resultado de impossibilidade FLP mostra que nenhum algoritmo determinístico pode garantir o consenso em um sistema assíncrono se mesmo um único nó puder falhar. Os algoritmos de consenso práticos devem, portanto, fazer compensações entre segurança (nunca alcançar um consenso incorreto) e vivacidade (sempre progredir). A prova de trabalho do Bitcoin prioriza a segurança sobre a vivacidade, enquanto o RPCA alcança um equilíbrio mais adequado para sistemas de pagamento ao completar rodadas de consenso em tempo limitado enquanto mantém fortes garantias de segurança sob suposições realistas de falha.

Existing Consensus Algorithms

Vários algoritmos de consenso foram propostos para resolver o Byzantine Generals Problem em sistemas distribuídos. O algoritmo de Practical Byzantine Fault Tolerance (PBFT), introduzido por Castro e Liskov, pode tolerar até f falhas Byzantine em um sistema de 3f+1 nós. O PBFT alcança consenso através de múltiplas rodadas de troca de mensagens entre todos os nós, com complexidade de comunicação de O(n^2), onde n é o número de nós. Embora o PBFT forneça fortes garantias de segurança e latência relativamente baixa para redes pequenas, ele não escala bem para redes grandes devido à sobrecarga de comunicação quadrática.

O Paxos e suas variantes, desenvolvidos por Lamport, fornecem consenso em sistemas assíncronos, mas assumem falhas por crash em vez de falhas Byzantine. O Paxos alcança consenso através de uma série de rodadas nas quais proponentes sugerem valores e aceitadores votam neles. Embora o Paxos possa tolerar atrasos arbitrários de mensagens e falhas de processos, ele requer engenharia cuidadosa para lidar com falhas Byzantine e pode sofrer de livelock em certos cenários.

O algoritmo de consenso por prova de trabalho do Bitcoin adota uma abordagem fundamentalmente diferente ao tornar os ataques Byzantine economicamente inviáveis. Os nós competem para resolver quebra-cabeças criptográficos, e o vencedor propõe o próximo bloco de transações. Embora essa abordagem escale para tamanhos de rede arbitrários e lide com falhas Byzantine, ela tem graves desvantagens: consumo massivo de energia (estimado em mais de 150 milhões de dólares por ano para a rede Bitcoin), longas latências de confirmação (frequentemente 40-60 minutos para transações de alto valor) e taxa de transferência limitada (aproximadamente 7 transações por segundo). Essas limitações tornam a prova de trabalho inadequada para muitas aplicações de sistemas de pagamento que exigem liquidação rápida e altos volumes de transações.

Ripple Protocol Consensus Algorithm

O Algoritmo de Consenso do Protocolo Ripple (RPCA) começa com cada servidor coletando todas as transações válidas que viu e que ainda não foram aplicadas como transações candidatas. Os servidores então seguem um protocolo de múltiplas rodadas onde trabalham iterativamente em direção a um acordo sobre um conjunto de transações para aplicar ao livro-razão atual. Em cada rodada, os servidores fazem propostas consistindo nas transações que acreditam que devem ser incluídas no próximo livro-razão.

Durante cada rodada de consenso, os servidores comunicam suas propostas a outros servidores em sua Lista de Nós Únicos (UNL). Os servidores então calculam quais transações aparecem em uma porcentagem limite de propostas. Inicialmente, esse limite é definido em 50%, significando que uma transação deve aparecer em propostas de pelo menos metade da UNL de um servidor para ser considerada na próxima rodada. À medida que o consenso progride através de rodadas sucessivas, esse limite aumenta incrementalmente (tipicamente para 60%, 70% e finalmente 80%).

Quando uma transação alcança o limite de supermaioria de 80% de apoio na UNL de um servidor, ela é incluída na proposta desse servidor para a rodada final de consenso. Todas as transações que alcançam esse limite em toda a rede são aplicadas ao livro-razão, que é então criptograficamente hashado e assinado. Este livro-razão recém-validado se torna o último livro-razão fechado, e o processo recomeça com o próximo conjunto de transações candidatas.

O processo de consenso tipicamente se completa em 5 segundos ou menos, com a maioria das transações exigindo apenas uma rodada de consenso para alcançar o limite de supermaioria. As transações que não alcançam consenso em uma rodada permanecem como candidatas para rodadas subsequentes. Este design garante que a rede progrida continuamente enquanto mantém fortes garantias de segurança, já que nenhuma transação pode ser aplicada ao livro-razão sem o apoio de supermaioria dos validadores confiáveis.

Formal Analysis of Convergence

A correção do RPCA depende criticamente da sobreposição entre as UNLs escolhidas por diferentes nós na rede. Seja UNL_i a lista de nós únicos do nó i, e seja UNL_i ∩ UNL_j o conjunto de nós que aparecem tanto em UNL_i quanto em UNL_j. Para que a rede mantenha o consenso, exigimos que para quaisquer dois nós i e j, a interseção de suas UNLs seja suficientemente grande em relação ao tamanho máximo de qualquer uma das UNLs.

Especificamente, o protocolo garante segurança quando |UNL_i ∩ UNL_j| / max(|UNL_i|, |UNL_j|) 1/5 para todos os pares de nós i e j. Esta condição garante que mesmo se os nós Byzantine tentarem fazer com que diferentes partes da rede cheguem a diferentes decisões de consenso, a sobreposição em nós confiáveis previne uma bifurcação. Se esta condição for mantida e menos de 1/5 dos nós em qualquer UNL forem Byzantine, então todos os nós corretos chegarão à mesma decisão de consenso.

A prova formal prossegue mostrando que se dois nós pudessem chegar a diferentes decisões de consenso, deve existir alguma transação T que aparece no livro-razão final de um nó mas não no do outro. Para que isso ocorra, T deve ter alcançado 80% de apoio na UNL do primeiro nó mas menos de 80% de apoio na UNL do segundo nó. No entanto, dado o requisito de sobreposição e a restrição sobre nós Byzantine, pode-se mostrar que este cenário é impossível: se T alcançar 80% de apoio em UNL_i, deve alcançar pelo menos 60% de apoio em qualquer UNL_j que satisfaça a condição de sobreposição, e com rodadas suficientes de consenso, isso convergirá para 80% ou será rejeitado por ambos os nós.

A propriedade de vivacidade -- que o consenso eventualmente será alcançado -- segue da observação de que o limite para inclusão aumenta deterministicamente ao longo das rodadas de consenso. Mesmo na presença de nós Byzantine e atrasos de rede, o protocolo garante que as transações apoiadas por uma supermaioria de nós honestos eventualmente serão incluídas, enquanto as transações que carecem de tal apoio serão excluídas. O tempo limitado para consenso (tipicamente 5 segundos) fornece garantias práticas de vivacidade adequadas para aplicações de sistemas de pagamento.

Unique Node Lists

A Lista de Nós Únicos (UNL) é um componente fundamental do RPCA que o distingue de outros algoritmos de consenso. Cada nó na rede Ripple mantém uma UNL consistindo de outros nós em que confia para não conspirar para fraudar a rede. Criticamente, esta confiança é local em vez de global: diferentes nós podem ter diferentes UNLs, e não há requisito de um conjunto de validadores globalmente acordado. Este design permite que a rede escale organicamente enquanto mantém a descentralização.

A UNL serve como mecanismo de prevenção de ataques Sybil sem exigir prova de trabalho. Em um sistema de votação ingênuo, um atacante poderia criar muitos nós pseudônimos para obter influência desproporcional. Ao exigir que cada nó escolha explicitamente em quais outros nós confia, o RPCA garante que a criação de identidades adicionais não fornece nenhuma vantagem a menos que essas identidades possam convencer os nós existentes a adicioná-las às suas UNLs. Isso desloca o problema da resistência Sybil do gasto computacional para relacionamentos de reputação e confiança.

Para que a rede funcione corretamente, as UNLs devem ser escolhidas de modo que tenham sobreposição suficiente, conforme descrito na análise formal. Na prática, isso significa que embora cada operador de nó tenha autonomia na seleção de sua UNL, deve garantir que sua lista inclua validadores que também são confiados por outras partes da rede. O Ripple fornece uma UNL padrão consistindo de validadores operados por entidades diversas, mas os operadores de nós são livres para modificar esta lista com base em sua própria avaliação de confiança.

O mecanismo UNL também fornece um caminho natural em direção à descentralização progressiva. Nos estágios iniciais da rede, um conjunto mais centralizado de validadores pode ser apropriado para garantir estabilidade e confiabilidade. À medida que a rede amadurece e mais operadores diversos demonstram sua confiabilidade, as UNLs podem evoluir para incluir um conjunto mais amplo de validadores, aumentando a resiliência e descentralização da rede sem comprometer suas propriedades de segurança.

Simulation Code

Para validar a análise teórica do RPCA e avaliar seu desempenho sob várias condições, simulações extensas foram conduzidas usando software de simulação personalizado. O framework de simulação modela uma rede de nós, cada um mantendo sua própria UNL e participando do protocolo de consenso. O código implementa o algoritmo RPCA completo, incluindo proposta de transações, rodadas de votação com limites crescentes e validação do livro-razão.

Os parâmetros-chave variados nas simulações incluem tamanho da rede (variando de 10 a 1.000 nós), a porcentagem de nós Byzantine (de 0% a 20%), tamanho da UNL (tipicamente entre 5 e 50 nós) e configurações de topologia de rede. Para cada configuração de parâmetros, múltiplas execuções de simulação foram conduzidas com diferentes sementes aleatórias para garantir a validade estatística dos resultados. As simulações rastrearam métricas incluindo latência de consenso, probabilidade de bifurcação e taxa de transferência de transações.

Os resultados da simulação confirmam as previsões teóricas sobre convergência e segurança. Em todas as configurações onde a condição de sobreposição de UNL foi satisfeita e os nós Byzantine compreendiam menos de 20% de cada UNL, a rede alcançou consenso com sucesso sem bifurcações. A latência de consenso permaneceu consistentemente baixa (tipicamente completando em 3-5 segundos simulados) independentemente do tamanho da rede, demonstrando a escalabilidade do algoritmo. Mesmo com 15% de nós Byzantine tentando ativamente interromper o consenso, a rede manteve a correção desde que o requisito de sobreposição de UNL fosse atendido.

Simulações adicionais exploraram casos extremos e cenários de falha, incluindo partições de rede, mudanças repentinas na composição da UNL e ataques coordenados por nós Byzantine. Essas simulações forneceram insights sobre a robustez do protocolo e informaram as melhores práticas recomendadas para seleção de UNL e operação de rede. O código de simulação completo foi disponibilizado para permitir verificação independente e pesquisa adicional.

Discussion

Comparado ao consenso por prova de trabalho do Bitcoin, o RPCA oferece várias vantagens significativas para aplicações de sistemas de pagamento. Mais notavelmente, a latência de consenso é reduzida de 40-60 minutos (o tempo tipicamente recomendado para transações Bitcoin de alto valor) para aproximadamente 5 segundos. Esta melhoria torna o RPCA adequado para ponto de venda e outras aplicações onde a liquidação quase instantânea é necessária. Além disso, o RPCA requer recursos computacionais mínimos em comparação com a prova de trabalho, eliminando o consumo massivo de energia associado à mineração de Bitcoin.

No entanto, essas vantagens vêm com diferentes suposições de confiança. Enquanto a segurança do Bitcoin depende apenas da suposição de que nenhum atacante controla mais de 50% do poder computacional da rede, o RPCA exige que os nós escolham UNLs com sobreposição suficiente e que os nós Byzantine não excedam o limite dentro dessas UNLs. Isso transfere alguma responsabilidade para os operadores de nós para tomar decisões de confiança prudentes. Na prática, essa compensação é aceitável para muitos casos de uso de sistemas de pagamento onde as instituições participantes têm relacionamentos de confiança existentes.

A topologia de rede e a estratégia de seleção de UNL impactam significativamente as propriedades do sistema de consenso. Uma topologia altamente centralizada onde todos os nós incluem os mesmos validadores em suas UNLs maximiza a segurança, mas pode reduzir a vivacidade se esses validadores ficarem indisponíveis. Por outro lado, uma topologia altamente descentralizada com sobreposição mínima de UNL pode melhorar a vivacidade, mas poderia arriscar falhas de consenso se a sobreposição se tornar muito esparsa. Encontrar o equilíbrio ideal requer consideração cuidadosa do cenário de implantação específico e da tolerância ao risco.

Trabalhos futuros poderiam explorar algoritmos adaptativos de seleção de UNL que mantenham automaticamente os requisitos de sobreposição enquanto maximizam a descentralização, mecanismos para que os nós ajustem dinamicamente suas UNLs com base no comportamento observado dos validadores, e extensões ao algoritmo de consenso que possam tolerar porcentagens ainda mais altas de nós Byzantine. Essas melhorias poderiam aumentar ainda mais a robustez e aplicabilidade do RPCA para sistemas de pagamento distribuídos em larga escala.

Conclusion

O Algoritmo de Consenso do Protocolo Ripple representa um avanço significativo no consenso distribuído para sistemas de pagamento. Ao utilizar sub-redes coletivamente confiáveis em vez de exigir acordo global entre todos os nós, o RPCA alcança consenso em questão de segundos enquanto mantém fortes garantias contra falhas Byzantine. A análise formal demonstra que desde que as UNLs sejam escolhidas com sobreposição suficiente e os nós Byzantine permaneçam abaixo do limite, a rede alcançará consenso correto sem bifurcações.

As implicações práticas deste trabalho se estendem além da rede de pagamentos Ripple. O RPCA demonstra que a compensação tradicional entre latência de consenso e garantias de segurança pode ser superada através de design cuidadoso do protocolo e do uso de relacionamentos de confiança locais. Esta abordagem pode se mostrar aplicável a outros sistemas distribuídos onde a baixa latência é crítica e os participantes têm relacionamentos de confiança existentes, como sistemas de liquidação interbancária, rastreamento de cadeia de suprimentos e outras aplicações de infraestrutura financeira.

A implantação do RPCA em sistemas de produção validou as características de desempenho e robustez do algoritmo. A rede Ripple processa milhares de transações por segundo com latência de consenso consistente de 3-5 segundos, demonstrando que as propriedades teóricas se traduzem efetivamente para a operação no mundo real. À medida que a rede continua a evoluir e incorporar validadores adicionais de operadores diversos, ela fornece um exemplo prático de como um sistema de consenso descentralizado pode manter tanto a segurança quanto o desempenho em escala.

References

Lamport, L., Shostak, R., and Pease, M. (1982). "The Byzantine Generals Problem." ACM Transactions on Programming Languages and Systems, 4(3):382-401. Este artigo seminal formalizou o problema de alcançar consenso em sistemas distribuídos com componentes defeituosos e estabeleceu a base teórica para sistemas Byzantine fault-tolerant.

Castro, M., and Liskov, B. (1999). "Practical Byzantine Fault Tolerance." Proceedings of the Third Symposium on Operating Systems Design and Implementation (OSDI). Este trabalho introduziu o PBFT, demonstrando que a Byzantine fault tolerance poderia ser alcançada com desempenho prático, embora com complexidade de comunicação O(n^2) limitando a escalabilidade.

Nakamoto, S. (2008). "Bitcoin: A Peer-to-Peer Electronic Cash System." Este whitepaper introduziu o consenso por prova de trabalho como solução para o problema do gasto duplo em moeda digital, permitindo consenso descentralizado sem partes confiáveis ao custo de alta latência e consumo de energia.

Lamport, L. (1998). "The Part-Time Parliament." ACM Transactions on Computer Systems, 16(2):133-169. Este artigo apresentou o algoritmo Paxos, que alcança consenso em sistemas assíncronos sob falhas por crash, influenciando designs subsequentes de protocolos de consenso.

Fischer, M. J., Lynch, N. A., and Paterson, M. S. (1985). "Impossibility of Distributed Consensus with One Faulty Process." Journal of the ACM, 32(2):374-382. O resultado de impossibilidade FLP estabeleceu limites fundamentais sobre o que os algoritmos de consenso podem alcançar em sistemas assíncronos, moldando o espaço de design para protocolos de consenso práticos.