Aprende sobre Hydra: o protocolo do razão com múltiplas cabeças
Escalar é o maior desafio para a adoção de blockchain. Ao aplicar uma abordagem com princípios baseada em evidências, chegamos a uma solução para Cardano e redes semelhantes: Hydra. Hydra é a acumulação de extensa investigação e um passo decisivo para capacitar redes descentralizadas para escalar aos requisitos globais.
O que é escalabilidade e como se mede?
Escalar um sistema de razão distribuído refere-se à capacidade de fornecer elevada taxa de transferência de transações, reduzida latência e armazenamento mínimo por nó. Estas propriedades têm sido repetidamente referidas como críticas para a implementação bem sucedida de protocolos de blockchain enquanto parte de um sistema real. Em termos de taxa de transferência, a rede VISA reporta em média conseguir processar 1736 transações por pagamentos por segundo (TPS) com a capacidade de suportar 24 000 TPS e é usado com frequência como base de comparação. A latência de uma transação é claramente desejado que seja o mais baixo quanto possível; latência abaixo de um segundo é um alvo natural para pagamentos. Outras aplicações de razões distribuídos têm um alargado intervalo de diferentes requisitos em termos destas métricas. Ao conceber um razão de propósito geral distribuído, é natural que se procure sobressair nos três pontos.
Implementar um sistema que fornece uma forma de escalar para um determinado caso prático requer uma combinação de dois aspetos independentes: adotar uma conceção algorítmica correta e implementá-la numa infraestrutura de hardware e de rede apropriado.
Ao avaliar uma conceção algorítmica específica, considerando números absolutos em termos de métricas específicas pode ser enganador. A razão é que tais quantidades absolutas têm que se referir a um determinado hardware e configuração de rede que pode manchar as vantagens e desvantagens de determinados algoritmos. De facto, um protocolo mal concebido pode ainda realizar suficientemente bem quando implementado em hardware e rede superior.
Por este motivo, é mais perspicaz avaliar a capacidade do protocolo atingir os limites físicos da infraestrutura de rede e hardware. Isto pode ser alcançado ao comparar os protocolos simplificados gerais nos quais todos os elementos de conceção foram retirados. Por exemplo, se queremos avaliar a sobrecarga de um algoritmo de encriptação podemos comparar o desempenho da comunicação de duas extremidades usando encriptação com o desempenho quando simplesmente trocam mensagens não encriptadas. Em tais experiências a taxa de mensagens por segundo não é importante. A conclusão importante é em relação à sobrecarga que é adicionada pelo algoritmo de encriptação. Mais, no caso da sobrecarga se aproximar de 0 para algumas configurações de experiências, podemos concluir que o algoritmo se aproxima dos limites físicos da capacidade da infraestrutura de rede passar mensagens para uma determinada configuração e daí atingiu a situação ótima.
Hydra - Visto de 10000 metros
Hydra é uma arquitetura fora da blockchain para razões distribuídos que se dirige a todos os três desafios de escalabilidade mencionados acima: elevada taxa de transferência de transações, reduzida latência e armazenamento mínimo por nó. Enquanto que Hydra está a ser concebido em conjunto com o protocolo de Ouroboros e o razão de Cardano, pode também ser empregue sobre vários outros sistemas, desde que partilhem as necessárias características com Cardano.
Apesar de ser um sistema integrado com o objetivo de resolver um problema - escalabilidade - Hydra consiste em vários subprotocolos. Torna-se necessário porque o próprio ecossistema de Cardano é heterogéneo e consiste em múltiplas entidades com diferentes capacidades técnicas: o sistema apoia não só, produtores de blocos com agrupamentos de participação associados, carteiras com elevada taxa de transferência conforme usados pelos câmbios, mas também utilizadores com uma grande variedade de desempenho computacional e características de disponibilidade. É irrealista esperar que um sapato servi para tudo , uma abordagem de um único protocolo ser suficiente para fornecer uma solução de escalabilidade geral para um conjunto diversificado de participantes da rede.
A arquitetura de escalabilidade de Hydra pode ser dividida em quatro componentes: a protocolo da cabeça, o protocolo da cauda e o protocolo de comunicação cruzado entre a cabeça e a cauda além de um conjunto de protocolos de apoio para direcionar, reconfigurar e virtualização. A peça central é o protocolo da cabeça que permite um conjunto de participantes de elevado desempenho e disponibilidade de participação (tais como agrupamentos de participação) processar rapidamente elevados números de transações com requisitos de armazenamento mínimos através de canais de estado de múltiplos participantes - um conceito que generaliza os canais de pagamento com duas partes implementado no contexto da Lightning Network. É complementado com um protocolo de cauda que permite aos participantes de elevado desempenho fornecer escalabilidade para um elevado número de utilizadores finais que podem usar o sistema através de dispositivos de baixa potência, tais como telemóveis e que podem estar offline por extensos períodos de tempo. Enquanto que cabeças e caudas podem desde já comunicar através da rede principal de Cardano, o protocolo de comunicação cruzado entre a cabeça e a cauda fornece uma eficiente variante fora de blockchain dessa funcionalidade. Tudo isto está ligado pela gestão do direcionamento e configuração, enquanto que a virtualização facilita comunicação mais rápida generalizando a comunicação entre cabeça e cauda.
O protocolo da cabeça Hydra
O protocolo da cabeça de Hydra é o primeiro componente da arquitetura de Hydra a ser publicamente lançado. Permite a um conjunto de participantes de criar um canal de estado fora da blockchain (chamada cabeça) em que podem executar contratos inteligentes (ou processar transações mais simples) entre eles sem interação com a infraestrutura da blockchain neste caso otimista em que todos os participantes de cabeça aderem ao protocolo. O canal de estado oferece liquidação rápida e elevada taxa de transferência de transações e ainda requer muito pouco espaço de armazenamento uma vez que o histórico das transações fora da blockchain pode ser apagado logo que o estado resultante foi assegurado na operação de captura instantânea fora da blockchain.
Mesmo no caso pessimista onde qualquer número de participantes se comportam mal, segurança total é rigorosamente garantida. Em qualquer momento, qualquer participante pode iniciar o fecho da cabeça com o efeito de que o estado da cabeça é transferido de volta para a blockchain (menos eficiente). Enfatizámos que a execução de qualquer contrato inteligente pode continuar perfeitamente na blockchain. Nenhuns fundos podem ser gerados fora da blockchain, nem pode um qualquer cabeça que responda perder quaisquer fundos.
Os canais de estado implementados em Hydra são isomórficos no sentido que fazem uso do mesmo formato de transação e código do contrato da própria blockchain subjacente: contratos vão e vêm entre canais e a blockchain. Assim, canais de estado efetivamente providenciam razões irmãos paralelos fora da blockchain. Por outras palavras, o razão torna-se de várias cabeças.
A confirmação de transações na cabeça é alcançado com total concorrência por um processo de certificação fora da blockchain assíncrono utilizando múltiplas assinaturas. Este nível de paralelismo é alcançado pelo uso do modelo UTxO Extenso (EUTxO). Dependências entre transações no modelo UTxO extenso são explícitos que permite atualizações aos estados sem que seja necessárias sequenciação de transações que são independentes um do outro.
Validação experimental do protocolo de cabeça de Hydra.
Como primeiro passo em direção à validação experimental do desempenho do protocolo de cabeça Hydra implementamos uma simulação. A simulação é parametrizada pelo tempo necessário para indivíduos realizarem ações (validação de transações, verificação de assinaturas, etc.) e executa uma simulação realista e corretamente temporizada num conjunto de nós distribuídos formando a cabeça. Isto resulta em tempos de confirmação de transações e cálculos de taxas de transferência.
Observamos que uma única cabeça Hydra atinge cerca de 1000TPS, assim ao correr 1000 cabeças em paralelo (por exemplo um para cada agrupamento de participação do lançamento de Shelley), deveremos atingir cerca de um milhão de transações por segundo. Isto é impressionante e coloca-nos a milhas da concorrência, mas porquê parar por aqui_ 2000 cabeças dar-nos-á 2 milhões de TPS - e se algum dia alguém exigir mil milhões de transações então podemos dizer-lhes para correr um milhão de cabeças. Mais, várias melhorias ao desempenho da implementação podem melhorar a métrica dos 1000 TPS numa única cabeça e por conseguinte atingir ainda melhor desempenho.
Mas, podemos simplesmente atingir qualquer número de TPS que quisermos? Em teoria, a resposta é um sólido, sim e isso aponta para um problema com o uso dominante de TPS como métrica para comparar sistemas. Enquanto que é tentador reduzir a complexidade de avaliar o desempenho do protocolo num único número, na prática isto resulta numa simplificação excessiva. Sem contexto, o número de TPS quase não tem relevância. Para a interpretar corretamente e fazer comparações, deverá ser questionado qual o tamanho do cluster (que influi na sobrecarga de comunicação); distribuição geográfica (que determina quanto tempo demora para a informação transitar pelo sistema); como a qualidade de serviço (tempo de confirmação de transações, fornecer dados a utilizadores) sofre por uma elevada taxa de transferência; o quão grandes e complicadas são as transações são; (que tem impacto nos tempos de validação, tempo de propagação de mensagens, requisitos no sistema de armazenamento local e a composição dos participantes de cabeça); e que tipo de hardware e ligações de rede foram usadas para as experiências. Só alterar a complexidade das transações pode alterar as TPS por um fator de 3 conforme se pode ver nas figuras do artigo (refere-se à secção 7 - Simulações).
Claramente, precisamos de melhores normas. O protocolo da cabeça de Hydra tem uma boa conceção enquanto protocolo? O que precisamos é de perguntar é se atinge os limites físicos da rede e não apenas um mero número de TPS. Assim, para a primeira iteração da avaliação do protocolo de cabeça de Hydra usamos a abordagem seguinte para assegurar que os dados que fornecemos são relevantes:
1- Listamos claramente todos os parâmetros que influenciam a simulação: tamanho da transação, tempo para validar uma única transação, tempo necessário para operações criptográficas, largura de banda atribuída por nó, tamanho do agrupamento e distribuição geográfica e os limites no paralelismo na qual transações podem ser emitidas. Sem um ambiente de controlo seria impossível reproduzir os nossos números.
2- Comparamos o desempenho do protocolo a linhas de base que fornecem limites precisos e absolutos da rede subjacente e a infraestrutura em hardware. O quão próximo nos aproximamos dos limites informa-nos da margem de manobra que temos para melhorias posteriores. Isto segue a metodologia explicada acima usando um exemplo de um algoritmo encriptado.
Usamos dois conjuntos de características base para Hydra. O primeiro, Confiança Total, é universal: aplica-se ao protocolo que distribui as transações entre os nós e insiste que cada nó valide transações uma atrás da outra - sem sequer garantir consenso. Nisto resulta um limite nas TPS ao simplesmente somar os tempos de entrega da mensagem e validação. O quão próximo deste limite informa-nos do preço que pagamos pelo consenso sem requerermos comparações com outros protocolos. Do segundo conjunto de características de base, Hydra Sem Limites, resulta um limite de TPS especificamente para o protocolo da cabeça e também fornece uma latência ideal e armazenamento para qualquer protocolo. Atingimos tal ao assumir que podemos enviar transações suficientes em paralelo para amortizar completamente os tempos de ida e volta e que todas as ações podem ser levadas a cabo quando necessárias, sem contenção de recursos. As características de base ajuda-nos a responder ao que pode ser alcançado em circunstâncias ideais com a conceção geral de Hydra (para um dado conjunto de valores para os parâmetros de input) além de avaliar a confirmação de latência e sobrecarga de armazenamento contra qualquer outro protocolo. Mais detalhes e gráficos para aqueles interessados podem ser encontrados no artigo (de novo, Secção 7 - Simulações).
O que se segue?
Resolver a questão da escalabilidade é o cálice sagrado para todo o espaço blockchain. Chegou o tempo de aplicar uma abordagem com princípios e baseado em evidências na conceção e engenharia de soluções de escalabilidade blockchain. Comparar propostas de escalabilidade com características de base bem definidas pode ser auxílio significativo na conceção destes protocolos. Fornece evidências sólidas para a análise relevância de escolhas de conceção que em última instância resulta na engenharia de protocolos de razões distribuídos efetivos e com desempenho que fornecem as melhores métricas absolutas para o caso prático de interesse. Enquanto que o protocolo de Hydra é implementado e testado iremos em seu tempo lançar o resto dos componentes de Hydra seguindo a mesma abordagem baseado em princípios.
Como última nota, Hydra é um esforço conjunto de vários investigadores dos quais gostaria de agradecer. Estes incluem Manuel Chakravarty, Sandro Coretti, Matthias Fitzi, Peter Gaži, Philipp Kant e Alexander Russel. A investigação teve também o apoio, em parte do projeto EU Nº 780477 PRIVILEDGE, que agradecemos.