ūüáĶūüáĻ Entra o Hydra: escalar raz√Ķes distribu√≠dos da forma baseada em evid√™ncia

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.

1 Like