Arweave 2.6: Potencialmente Alinhando Melhor com a Visão de Satoshi Nakamoto

Intermediário3/24/2024, 6:13:29 PM
Este artigo argumenta que a visão de Satoshi Nakamoto - consenso acessível a todos através da CPU - ainda não foi totalmente realizada. Os mecanismos iterativos do Arweave podem alinhar-se mais fielmente com a visão original de Nakamoto, sendo a versão 2.6 um passo significativo para cumprir as suas expectativas.

Introdução

Em cerca de um mês, #Bitcoinestá prestes a iniciar a sua próxima redução para metade. No entanto, o autor acredita que a visão de Satoshi Nakamoto - consenso acessível a todos via CPU - ainda não foi realizada. Neste sentido, os mecanismos iterativos da Arweave podem estar mais alinhados com a visão original de Nakamoto, sendo que a versão 2.6 representa um passo significativo rumo à concretização das suas expetativas. Esta versão traz melhorias substanciais em relação aos seus antecessores, com o objetivo de:

  • Restringir a aceleração de hardware, permitindo a manutenção de consenso com uma CPU de uso geral + disco rígido mecânico, reduzindo assim os custos de armazenamento;
  • Conduza os custos do consenso direto para um armazenamento de dados eficiente em vez de uma competição intensiva em hash de energia;
  • Incentivar os mineiros a estabelecerem as suas cópias completas dos dados da Arweave, permitindo um encaminhamento mais rápido dos dados e um armazenamento mais distribuído.

Mecanismo de consenso

Com base nos objetivos acima, o mecanismo da versão 2.6 é mais ou menos o seguinte:

  • Um novo componente é adicionado ao mecanismo SPoRA original chamado de Cadeia de Hash, que é o relógio do algoritmo de criptografia mencionado anteriormente e gera um hash de mineração SHA-256 a cada segundo.
  • O mineiro seleciona o índice de uma partição nos dados da partição que armazena e utiliza-o juntamente com o hash de mineração e o endereço de mineração como informações de entrada de mineração para iniciar a mineração.
  • Gerar uma gama de recall 1 na partição escolhida e outra gama de recall 2 numa posição aleatória na rede de entrelaçamento.
  • Use os blocos de dados de recall (Chunks) dentro do intervalo 1 sequencialmente para calcular se é uma solução de bloco. Se o resultado do cálculo exceder a dificuldade atual da rede, o minerador ganha o direito de minerar; se não for bem-sucedido, proceda ao cálculo do próximo bloco de recall no intervalo.
  • Os blocos de dados de recall na faixa 2 também podem ser calculados e verificados, mas suas soluções requerem o hash da faixa 1.

Gráfico 1: Esquema do Mecanismo de Consenso na Versão 2.6

Vamos nos familiarizar com vários termos e conceitos que aparecem neste mecanismo:

Dados da Arweave: Também conhecida como a “Rede Weave.” Todos os dados na rede são divididos em blocos de dados individuais, chamados Chunks (os blocos assemelham-se a um “muro de tijolos” no diagrama). Estes blocos estão distribuídos de forma equitativa por toda a rede Arweave e são endereçados utilizando uma estrutura de árvore de Merkle (também conhecida como Deslocamento Global), permitindo a identificação da posição de qualquer bloco de dados dentro da Rede Weave.

Chunk: Cada bloco de dados geralmente tem um tamanho de 256 KB. Os mineradores devem empacotar e fazer hash dos blocos de dados correspondentes para ganhar o direito de minerar, provando que armazenam cópias dos dados durante o processo de mineração SPoRA.

Partição: “Partição” é um novo conceito introduzido na versão 2.6. Cada partição abrange 3,6TB de dados. As partições são numeradas a partir do início da Rede Weave (índice 0) até ao número total de partições que cobrem toda a Rede Weave.

Intervalo de Recolha: O Intervalo de Recolha é outro novo conceito na versão 2.6. Representa uma série de blocos de dados contíguos (Chunks) na Rede Weave, a partir de um deslocamento específico e com um comprimento de 100MB. Com cada bloco de dados tendo 256 KB, um Intervalo de Recolha inclui 400 blocos de dados. Neste mecanismo, existem dois Intervalos de Recolha, conforme explicado em detalhe abaixo.

Soluções Potenciais: Cada bloco de dados de 256KB dentro da Gama de Recuperação é considerado uma solução potencial para ganhar o direito de minerar. Como parte do processo de mineração, cada bloco de dados é hashado para testar se atende aos requisitos de dificuldade da rede. Se for bem-sucedido, o minerador ganha o direito de minerar e recebe recompensas de mineração. Se não for bem-sucedido, o minerador continua tentando o próximo bloco de 256KB dentro da Gama de Recuperação.

Cadeia de Hash: A Cadeia de Hash é uma atualização chave na versão 2.6, adicionando um relógio encriptado ao anterior SPoRA, limitando a taxa de hash máxima. A Cadeia de Hash gera uma sequência de hashes ao hashear consecutivamente um pedaço de dados usando a função SHA-256. Este processo não pode ser paralelizado (facilmente atingível com CPUs de consumo), alcançando um atraso de 1 segundo ao realizar um certo número de operações de hash consecutivas.

Hash de Mineração: Após um número suficiente de operações de hash consecutivas (ou seja, após um atraso de 1 segundo), a Cadeia de Hash produz um valor de hash considerado válido para mineração. É importante destacar que o hash de mineração é consistente entre todos os mineiros e todos os mineiros podem verificá-lo.

Agora que introduzimos todos os termos necessários, podemos compreender melhor como a Versão 2.6 opera, discutindo as estratégias ideais para obtê-la.

Melhores Estratégias

O objetivo geral da Arweave já foi apresentado várias vezes antes, que é maximizar o número de réplicas de dados armazenadas na rede. Mas o que armazenar? Como armazenar? Existem muitos requisitos e complexidades envolvidos. Aqui, discutiremos como adotar uma estratégia de melhores práticas.

Réplicas vs Cópias

Desde a versão 2.6, tenho encontrado frequentemente dois termos em vários documentos técnicos: Réplicas e Cópias. Ambos os conceitos podem ser traduzidos como "cópias" em chinês, mas na realidade, existem diferenças significativas entre eles, o que também causou alguns obstáculos para mim entender o mecanismo. Para facilitar a compreensão, prefiro traduzir Réplicas como "副本" (réplicas) e Cópias como "备份" (backups).

Cópias referem-se simplesmente à cópia dos dados, onde não há diferença entre os backups dos mesmos dados.

As réplicas, por outro lado, enfatizam a singularidade. Refere-se ao ato de armazenar dados após terem passado por um processo de singularidade. A rede Arweave incentiva o armazenamento de réplicas em vez de meros backups.

Nota: Na versão 2.7, o mecanismo de consenso mudou para SPoRes, que significa Provas Sucintas de Replicação, baseado no armazenamento de réplicas. Vou fornecer mais interpretação no futuro.

Empacotando Réplicas Únicas

Réplicas únicas são cruciais no mecanismo Arweave. Os mineiros devem empacotar todos os dados em um formato específico para formar suas réplicas únicas como um pré-requisito para ganhar o direito de minerar.

Se quiser executar um novo nó e pensar em copiar diretamente os dados que outros mineiros já embalaram, não funcionará. Primeiro, precisa de descarregar e sincronizar os dados originais da Rede Weave Arweave (claro, não quer descarregar tudo, descarregar apenas uma parte também é exequível, e pode definir as suas próprias políticas de dados para filtrar dados arriscados). Depois, utilize a função RandomX para embalar cada bloco de dados dos dados originais, transformando-os em soluções potenciais de mineração.

O processo de embalagem envolve a disponibilização de uma Chave de Embalagem à função RandomX, permitindo-lhe gerar resultados através de múltiplos cálculos para embalar os blocos de dados originais. O processo de desembalagem dos blocos de dados já embalados é o mesmo - fornecendo a chave de embalagem e utilizando os resultados gerados através de múltiplos cálculos para desembalar os blocos de dados.

Na versão 2.5, o backup da Chave de Empacotamento é um hash SHA256 associado ao chunk_offset (o deslocamento do bloco de dados, também entendido como o parâmetro de posição do bloco de dados) e tx_root (raiz da transação). Isso garante que cada solução de mineração extraída venha de uma réplica única de blocos de dados dentro de um bloco específico. Se um bloco de dados tiver vários backups em diferentes locais na rede quebrada, cada backup precisará ser feito separadamente como uma réplica única.

Na versão 2.6, esta chave de backup é estendida para um hash SHA256 associado ao chunk_offset, tx_root e miner_address (endereço do minerador). Isso significa que cada réplica também é única para cada endereço de mineração.

Vantagens de armazenar réplicas completas

O algoritmo sugere que os mineiros devem construir uma réplica completa única em vez de parcialmente replicadas, o que garante uma distribuição uniforme de dados em toda a rede.

Como devemos entender isso? Vamos entender através da comparação das duas imagens seguintes.

Primeiro, vamos supor que toda a rede fragmentada da Arweave produziu um total de 16 partições de dados.

Cenário 1:

  • O mineiro Bob achou o download de dados muito demorado, por isso só descarregou dados das primeiras 4 partições da rede danificada.
  • Para maximizar as réplicas de mineração nestas 4 partições, o Bob teve uma ideia inteligente. Ele fez 4 cópias dos dados dessas 4 partições e agrupou-as em 4 recursos de réplicas únicas usando endereços de mineração diferentes. Agora, o Bob tem 16 partições no seu espaço de armazenamento. Isto está bem e está em conformidade com as regras das réplicas únicas.
  • Em seguida, Bob pode realizar testes de violação para cada bloco de material de dados em cada partição a cada segundo ao obter o Mining Hash. Isso permite que Bob tenha 400 * 16 = 6400 soluções potenciais de mineração em um segundo.
  • Mas a inteligência de Bob tem um custo, pois ele tem de renunciar a uma oportunidade de mineração para cada intervalo de recal. Veja aqueles "pontos de interrogação"? Eles representam o segundo intervalo de recal que Bob não consegue encontrar no seu disco rígido, pois assinala as partições de dados que Bob não armazenou. Claro, com sorte, existem indicadores relativamente baixos simbolizando que Bob armazenou apenas 25% das 4 partições, o que significa 1600 soluções potenciais.
  • Assim, esta estratégia permite que o Bob tenha 6400 + 1600 = 8000 soluções potenciais por segundo.

Figura 2: Estratégia "inteligente" de Bob: Primeiro cenário

Segundo Cenário:

Agora, vamos dar uma olhada no segundo cenário. Devido à disposição de dois intervalos de recall, uma estratégia mais ótima é armazenar réplicas únicas dos dados com mais problemas. Isto é ilustrado na Figura 3.

  • A mineiradora Alice, ao contrário da abordagem “inteligente” de Bob, descarrega diligentemente os dados da partição para todas as 16 partições e utiliza apenas um endereço de mineração para formar uma réplica única com 16 backups.
  • Uma vez que a Alice também tem 16 partições, o total de soluções potenciais para o primeiro intervalo de chamada é o mesmo que o do Bob, que também é 6400.
  • No entanto, neste cenário, Alice obtém todas as soluções potenciais para o segundo intervalo de recall. Isso é um adicional de 6400.
  • Assim, a estratégia de Alice dá-lhe 6400 + 6400 = 12800 soluções potenciais por segundo. A vantagem é óbvia.

Figura 3: A estratégia de Alice tem maiores vantagens

O Papel das Faixas de Lembrança

Pode perguntar-se por que, antes da versão 2.5, um único deslocamento de bloco de recall era aleatoriamente hashado por uma função para permitir que os mineiros procurassem e fornecessem provas de armazenamento, enquanto na versão 2.6, ele hashava um intervalo de recall em vez disso.

A razão é bastante simples: um intervalo de recordação é composto por blocos de dados contíguos, e esta estrutura serve um propósito principal - minimizar o movimento da cabeça de leitura dos discos rígidos mecânicos (HDDs). Este método de otimização física permite que o desempenho de leitura dos HDDs esteja ao nível das unidades de estado sólido (SSDs) mais caras. É como amarrar uma mão e um pé de um SSD; claro, ainda pode ter uma ligeira vantagem de velocidade ao ser capaz de transferir quatro intervalos de recordação por segundo. No entanto, em comparação com os HDDs mais baratos, a contagem será a métrica-chave que orientará as escolhas dos mineradores.

Verificação da Cadeia de Hash

Agora vamos discutir a verificação de um novo bloco.

Para aceitar um novo bloco, os validadores precisam validar o novo bloco recebido do produtor de blocos, o que pode ser feito usando o seu hash de mineração gerado para verificar o hash de mineração do novo bloco.

Se um validador não está na cabeça atual da cadeia de hash, cada hash de mineração inclui 25 checkpoints de 40 milissegundos. Estes checkpoints são os resultados consecutivos da hash durante 40 milissegundos, e juntos representam um intervalo de um segundo a partir do hash de mineração anterior.

Antes de propagar o bloco recém-recebido para outros nós, os validadores completarão rapidamente a verificação dos primeiros 25 checkpoints em 40 milissegundos. Se a verificação for bem-sucedida, desencadeia a propagação do bloco e continua a validar os checkpoints restantes.

Os checkpoints completos são concluídos validando todos os checkpoints restantes. Após os primeiros 25 checkpoints, existem 500 checkpoints de verificação, seguidos por mais 500 checkpoints de verificação, com o intervalo dobrando para cada grupo subsequente de 500 checkpoints.

Embora a cadeia de hash tenha que avançar sequencialmente na geração de hashes de mineração, os validadores podem realizar a verificação de hash ao validar checkpoints, o que pode encurtar o tempo para verificar blocos e melhorar a eficiência.

Figura 4: Processo de Verificação da Cadeia de Hash

Semente da Cadeia de Hash

Se um mineiro ou grupo de mineração tiver capacidades de hash SHA256 mais rápidas, a sua cadeia de hash poderá avançar à frente de outros nós na rede. Com o tempo, essa vantagem de velocidade de bloco pode acumular-se num desfasamento significativo da cadeia de hash, fazendo com que os hashes minerados fiquem fora de sincronia com o resto dos validadores. Isso poderia levar a uma série de forks e reorganizações incontroláveis.

Para reduzir a probabilidade de desvios na cadeia de hash, a Arweave sincroniza a cadeia de hash global usando tokens de blocos históricos em intervalos fixos. Isso fornece regularmente novas sementes para a cadeia de hash, garantindo a sincronização das cadeias de hash entre vários mineiros com um bloco validado.

O intervalo para as sementes da cadeia de hash é a cada 50 * 120 hashes minerados (50 representa o número de blocos, e 120 representa o número de hashes minerados dentro de um ciclo de produção de bloco de 2 minutos) para selecionar um novo bloco de semente. Isso significa que os blocos de semente aparecem aproximadamente a cada ~50 blocos de Arweave, mas devido a variações nos tempos de bloco, os blocos de semente podem aparecer ligeiramente mais cedo ou mais tarde do que 50 blocos.

Figura 5: Método de Geração de Sementes de Cadeia de Hash

O conteúdo acima, extraído da especificação da versão 2.6 pelo autor, ilustra que a Arweave implementou mecanismos de baixa potência e mais descentralizados para operar toda a rede a partir da versão 2.6. A visão de Satoshi Nakamoto encontra realização prática na Arweave.

Arweave 2.6: https://2-6-spec.arweave.dev/

Declaração:

  1. Este artigo originalmente intitulado “Arweave 2.6 也许更符合中本聪的愿景” é reproduzido de[PermaDAO]. Todos os direitos de autor pertencem ao autor original [Arweave Oasis]. Se tiver alguma objeção à reimpressão, entre em contato Gate Learnequipa, a equipa tratará disso o mais breve possível.

  2. Aviso Legal: As opiniões expressas neste artigo representam apenas as opiniões pessoais do autor e não constituem qualquer conselho de investimento.

  3. As traduções do artigo para outros idiomas são feitas pela equipe da Gate Learn. Salvo indicação em contrário, a cópia, distribuição ou plágio dos artigos traduzidos é proibida.

Пригласить больше голосов

Содержание

Arweave 2.6: Potencialmente Alinhando Melhor com a Visão de Satoshi Nakamoto

Intermediário3/24/2024, 6:13:29 PM
Este artigo argumenta que a visão de Satoshi Nakamoto - consenso acessível a todos através da CPU - ainda não foi totalmente realizada. Os mecanismos iterativos do Arweave podem alinhar-se mais fielmente com a visão original de Nakamoto, sendo a versão 2.6 um passo significativo para cumprir as suas expectativas.

Introdução

Em cerca de um mês, #Bitcoinestá prestes a iniciar a sua próxima redução para metade. No entanto, o autor acredita que a visão de Satoshi Nakamoto - consenso acessível a todos via CPU - ainda não foi realizada. Neste sentido, os mecanismos iterativos da Arweave podem estar mais alinhados com a visão original de Nakamoto, sendo que a versão 2.6 representa um passo significativo rumo à concretização das suas expetativas. Esta versão traz melhorias substanciais em relação aos seus antecessores, com o objetivo de:

  • Restringir a aceleração de hardware, permitindo a manutenção de consenso com uma CPU de uso geral + disco rígido mecânico, reduzindo assim os custos de armazenamento;
  • Conduza os custos do consenso direto para um armazenamento de dados eficiente em vez de uma competição intensiva em hash de energia;
  • Incentivar os mineiros a estabelecerem as suas cópias completas dos dados da Arweave, permitindo um encaminhamento mais rápido dos dados e um armazenamento mais distribuído.

Mecanismo de consenso

Com base nos objetivos acima, o mecanismo da versão 2.6 é mais ou menos o seguinte:

  • Um novo componente é adicionado ao mecanismo SPoRA original chamado de Cadeia de Hash, que é o relógio do algoritmo de criptografia mencionado anteriormente e gera um hash de mineração SHA-256 a cada segundo.
  • O mineiro seleciona o índice de uma partição nos dados da partição que armazena e utiliza-o juntamente com o hash de mineração e o endereço de mineração como informações de entrada de mineração para iniciar a mineração.
  • Gerar uma gama de recall 1 na partição escolhida e outra gama de recall 2 numa posição aleatória na rede de entrelaçamento.
  • Use os blocos de dados de recall (Chunks) dentro do intervalo 1 sequencialmente para calcular se é uma solução de bloco. Se o resultado do cálculo exceder a dificuldade atual da rede, o minerador ganha o direito de minerar; se não for bem-sucedido, proceda ao cálculo do próximo bloco de recall no intervalo.
  • Os blocos de dados de recall na faixa 2 também podem ser calculados e verificados, mas suas soluções requerem o hash da faixa 1.

Gráfico 1: Esquema do Mecanismo de Consenso na Versão 2.6

Vamos nos familiarizar com vários termos e conceitos que aparecem neste mecanismo:

Dados da Arweave: Também conhecida como a “Rede Weave.” Todos os dados na rede são divididos em blocos de dados individuais, chamados Chunks (os blocos assemelham-se a um “muro de tijolos” no diagrama). Estes blocos estão distribuídos de forma equitativa por toda a rede Arweave e são endereçados utilizando uma estrutura de árvore de Merkle (também conhecida como Deslocamento Global), permitindo a identificação da posição de qualquer bloco de dados dentro da Rede Weave.

Chunk: Cada bloco de dados geralmente tem um tamanho de 256 KB. Os mineradores devem empacotar e fazer hash dos blocos de dados correspondentes para ganhar o direito de minerar, provando que armazenam cópias dos dados durante o processo de mineração SPoRA.

Partição: “Partição” é um novo conceito introduzido na versão 2.6. Cada partição abrange 3,6TB de dados. As partições são numeradas a partir do início da Rede Weave (índice 0) até ao número total de partições que cobrem toda a Rede Weave.

Intervalo de Recolha: O Intervalo de Recolha é outro novo conceito na versão 2.6. Representa uma série de blocos de dados contíguos (Chunks) na Rede Weave, a partir de um deslocamento específico e com um comprimento de 100MB. Com cada bloco de dados tendo 256 KB, um Intervalo de Recolha inclui 400 blocos de dados. Neste mecanismo, existem dois Intervalos de Recolha, conforme explicado em detalhe abaixo.

Soluções Potenciais: Cada bloco de dados de 256KB dentro da Gama de Recuperação é considerado uma solução potencial para ganhar o direito de minerar. Como parte do processo de mineração, cada bloco de dados é hashado para testar se atende aos requisitos de dificuldade da rede. Se for bem-sucedido, o minerador ganha o direito de minerar e recebe recompensas de mineração. Se não for bem-sucedido, o minerador continua tentando o próximo bloco de 256KB dentro da Gama de Recuperação.

Cadeia de Hash: A Cadeia de Hash é uma atualização chave na versão 2.6, adicionando um relógio encriptado ao anterior SPoRA, limitando a taxa de hash máxima. A Cadeia de Hash gera uma sequência de hashes ao hashear consecutivamente um pedaço de dados usando a função SHA-256. Este processo não pode ser paralelizado (facilmente atingível com CPUs de consumo), alcançando um atraso de 1 segundo ao realizar um certo número de operações de hash consecutivas.

Hash de Mineração: Após um número suficiente de operações de hash consecutivas (ou seja, após um atraso de 1 segundo), a Cadeia de Hash produz um valor de hash considerado válido para mineração. É importante destacar que o hash de mineração é consistente entre todos os mineiros e todos os mineiros podem verificá-lo.

Agora que introduzimos todos os termos necessários, podemos compreender melhor como a Versão 2.6 opera, discutindo as estratégias ideais para obtê-la.

Melhores Estratégias

O objetivo geral da Arweave já foi apresentado várias vezes antes, que é maximizar o número de réplicas de dados armazenadas na rede. Mas o que armazenar? Como armazenar? Existem muitos requisitos e complexidades envolvidos. Aqui, discutiremos como adotar uma estratégia de melhores práticas.

Réplicas vs Cópias

Desde a versão 2.6, tenho encontrado frequentemente dois termos em vários documentos técnicos: Réplicas e Cópias. Ambos os conceitos podem ser traduzidos como "cópias" em chinês, mas na realidade, existem diferenças significativas entre eles, o que também causou alguns obstáculos para mim entender o mecanismo. Para facilitar a compreensão, prefiro traduzir Réplicas como "副本" (réplicas) e Cópias como "备份" (backups).

Cópias referem-se simplesmente à cópia dos dados, onde não há diferença entre os backups dos mesmos dados.

As réplicas, por outro lado, enfatizam a singularidade. Refere-se ao ato de armazenar dados após terem passado por um processo de singularidade. A rede Arweave incentiva o armazenamento de réplicas em vez de meros backups.

Nota: Na versão 2.7, o mecanismo de consenso mudou para SPoRes, que significa Provas Sucintas de Replicação, baseado no armazenamento de réplicas. Vou fornecer mais interpretação no futuro.

Empacotando Réplicas Únicas

Réplicas únicas são cruciais no mecanismo Arweave. Os mineiros devem empacotar todos os dados em um formato específico para formar suas réplicas únicas como um pré-requisito para ganhar o direito de minerar.

Se quiser executar um novo nó e pensar em copiar diretamente os dados que outros mineiros já embalaram, não funcionará. Primeiro, precisa de descarregar e sincronizar os dados originais da Rede Weave Arweave (claro, não quer descarregar tudo, descarregar apenas uma parte também é exequível, e pode definir as suas próprias políticas de dados para filtrar dados arriscados). Depois, utilize a função RandomX para embalar cada bloco de dados dos dados originais, transformando-os em soluções potenciais de mineração.

O processo de embalagem envolve a disponibilização de uma Chave de Embalagem à função RandomX, permitindo-lhe gerar resultados através de múltiplos cálculos para embalar os blocos de dados originais. O processo de desembalagem dos blocos de dados já embalados é o mesmo - fornecendo a chave de embalagem e utilizando os resultados gerados através de múltiplos cálculos para desembalar os blocos de dados.

Na versão 2.5, o backup da Chave de Empacotamento é um hash SHA256 associado ao chunk_offset (o deslocamento do bloco de dados, também entendido como o parâmetro de posição do bloco de dados) e tx_root (raiz da transação). Isso garante que cada solução de mineração extraída venha de uma réplica única de blocos de dados dentro de um bloco específico. Se um bloco de dados tiver vários backups em diferentes locais na rede quebrada, cada backup precisará ser feito separadamente como uma réplica única.

Na versão 2.6, esta chave de backup é estendida para um hash SHA256 associado ao chunk_offset, tx_root e miner_address (endereço do minerador). Isso significa que cada réplica também é única para cada endereço de mineração.

Vantagens de armazenar réplicas completas

O algoritmo sugere que os mineiros devem construir uma réplica completa única em vez de parcialmente replicadas, o que garante uma distribuição uniforme de dados em toda a rede.

Como devemos entender isso? Vamos entender através da comparação das duas imagens seguintes.

Primeiro, vamos supor que toda a rede fragmentada da Arweave produziu um total de 16 partições de dados.

Cenário 1:

  • O mineiro Bob achou o download de dados muito demorado, por isso só descarregou dados das primeiras 4 partições da rede danificada.
  • Para maximizar as réplicas de mineração nestas 4 partições, o Bob teve uma ideia inteligente. Ele fez 4 cópias dos dados dessas 4 partições e agrupou-as em 4 recursos de réplicas únicas usando endereços de mineração diferentes. Agora, o Bob tem 16 partições no seu espaço de armazenamento. Isto está bem e está em conformidade com as regras das réplicas únicas.
  • Em seguida, Bob pode realizar testes de violação para cada bloco de material de dados em cada partição a cada segundo ao obter o Mining Hash. Isso permite que Bob tenha 400 * 16 = 6400 soluções potenciais de mineração em um segundo.
  • Mas a inteligência de Bob tem um custo, pois ele tem de renunciar a uma oportunidade de mineração para cada intervalo de recal. Veja aqueles "pontos de interrogação"? Eles representam o segundo intervalo de recal que Bob não consegue encontrar no seu disco rígido, pois assinala as partições de dados que Bob não armazenou. Claro, com sorte, existem indicadores relativamente baixos simbolizando que Bob armazenou apenas 25% das 4 partições, o que significa 1600 soluções potenciais.
  • Assim, esta estratégia permite que o Bob tenha 6400 + 1600 = 8000 soluções potenciais por segundo.

Figura 2: Estratégia "inteligente" de Bob: Primeiro cenário

Segundo Cenário:

Agora, vamos dar uma olhada no segundo cenário. Devido à disposição de dois intervalos de recall, uma estratégia mais ótima é armazenar réplicas únicas dos dados com mais problemas. Isto é ilustrado na Figura 3.

  • A mineiradora Alice, ao contrário da abordagem “inteligente” de Bob, descarrega diligentemente os dados da partição para todas as 16 partições e utiliza apenas um endereço de mineração para formar uma réplica única com 16 backups.
  • Uma vez que a Alice também tem 16 partições, o total de soluções potenciais para o primeiro intervalo de chamada é o mesmo que o do Bob, que também é 6400.
  • No entanto, neste cenário, Alice obtém todas as soluções potenciais para o segundo intervalo de recall. Isso é um adicional de 6400.
  • Assim, a estratégia de Alice dá-lhe 6400 + 6400 = 12800 soluções potenciais por segundo. A vantagem é óbvia.

Figura 3: A estratégia de Alice tem maiores vantagens

O Papel das Faixas de Lembrança

Pode perguntar-se por que, antes da versão 2.5, um único deslocamento de bloco de recall era aleatoriamente hashado por uma função para permitir que os mineiros procurassem e fornecessem provas de armazenamento, enquanto na versão 2.6, ele hashava um intervalo de recall em vez disso.

A razão é bastante simples: um intervalo de recordação é composto por blocos de dados contíguos, e esta estrutura serve um propósito principal - minimizar o movimento da cabeça de leitura dos discos rígidos mecânicos (HDDs). Este método de otimização física permite que o desempenho de leitura dos HDDs esteja ao nível das unidades de estado sólido (SSDs) mais caras. É como amarrar uma mão e um pé de um SSD; claro, ainda pode ter uma ligeira vantagem de velocidade ao ser capaz de transferir quatro intervalos de recordação por segundo. No entanto, em comparação com os HDDs mais baratos, a contagem será a métrica-chave que orientará as escolhas dos mineradores.

Verificação da Cadeia de Hash

Agora vamos discutir a verificação de um novo bloco.

Para aceitar um novo bloco, os validadores precisam validar o novo bloco recebido do produtor de blocos, o que pode ser feito usando o seu hash de mineração gerado para verificar o hash de mineração do novo bloco.

Se um validador não está na cabeça atual da cadeia de hash, cada hash de mineração inclui 25 checkpoints de 40 milissegundos. Estes checkpoints são os resultados consecutivos da hash durante 40 milissegundos, e juntos representam um intervalo de um segundo a partir do hash de mineração anterior.

Antes de propagar o bloco recém-recebido para outros nós, os validadores completarão rapidamente a verificação dos primeiros 25 checkpoints em 40 milissegundos. Se a verificação for bem-sucedida, desencadeia a propagação do bloco e continua a validar os checkpoints restantes.

Os checkpoints completos são concluídos validando todos os checkpoints restantes. Após os primeiros 25 checkpoints, existem 500 checkpoints de verificação, seguidos por mais 500 checkpoints de verificação, com o intervalo dobrando para cada grupo subsequente de 500 checkpoints.

Embora a cadeia de hash tenha que avançar sequencialmente na geração de hashes de mineração, os validadores podem realizar a verificação de hash ao validar checkpoints, o que pode encurtar o tempo para verificar blocos e melhorar a eficiência.

Figura 4: Processo de Verificação da Cadeia de Hash

Semente da Cadeia de Hash

Se um mineiro ou grupo de mineração tiver capacidades de hash SHA256 mais rápidas, a sua cadeia de hash poderá avançar à frente de outros nós na rede. Com o tempo, essa vantagem de velocidade de bloco pode acumular-se num desfasamento significativo da cadeia de hash, fazendo com que os hashes minerados fiquem fora de sincronia com o resto dos validadores. Isso poderia levar a uma série de forks e reorganizações incontroláveis.

Para reduzir a probabilidade de desvios na cadeia de hash, a Arweave sincroniza a cadeia de hash global usando tokens de blocos históricos em intervalos fixos. Isso fornece regularmente novas sementes para a cadeia de hash, garantindo a sincronização das cadeias de hash entre vários mineiros com um bloco validado.

O intervalo para as sementes da cadeia de hash é a cada 50 * 120 hashes minerados (50 representa o número de blocos, e 120 representa o número de hashes minerados dentro de um ciclo de produção de bloco de 2 minutos) para selecionar um novo bloco de semente. Isso significa que os blocos de semente aparecem aproximadamente a cada ~50 blocos de Arweave, mas devido a variações nos tempos de bloco, os blocos de semente podem aparecer ligeiramente mais cedo ou mais tarde do que 50 blocos.

Figura 5: Método de Geração de Sementes de Cadeia de Hash

O conteúdo acima, extraído da especificação da versão 2.6 pelo autor, ilustra que a Arweave implementou mecanismos de baixa potência e mais descentralizados para operar toda a rede a partir da versão 2.6. A visão de Satoshi Nakamoto encontra realização prática na Arweave.

Arweave 2.6: https://2-6-spec.arweave.dev/

Declaração:

  1. Este artigo originalmente intitulado “Arweave 2.6 也许更符合中本聪的愿景” é reproduzido de[PermaDAO]. Todos os direitos de autor pertencem ao autor original [Arweave Oasis]. Se tiver alguma objeção à reimpressão, entre em contato Gate Learnequipa, a equipa tratará disso o mais breve possível.

  2. Aviso Legal: As opiniões expressas neste artigo representam apenas as opiniões pessoais do autor e não constituem qualquer conselho de investimento.

  3. As traduções do artigo para outros idiomas são feitas pela equipe da Gate Learn. Salvo indicação em contrário, a cópia, distribuição ou plágio dos artigos traduzidos é proibida.

Начните торговать сейчас
Зарегистрируйтесь сейчас и получите ваучер на
$100
!