Arweave 2.6: Potencialmente se 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 via CPU - ainda não foi totalmente realizada. Os mecanismos iterativos da Arweave podem se alinhar de maneira mais fiel com a visão original de Nakamoto, com a versão 2.6 marcando um passo significativo em direção ao cumprimento de suas expectativas.

Introdução

Em cerca de um mês, #Bitcoinestá pronto para iniciar seu próximo halving. No entanto, o autor acredita que a visão de Satoshi Nakamoto - consenso acessível a todos via CPU - ainda não foi realizada. Nesse sentido, os mecanismos iterativos da Arweave podem se alinhar de forma mais fiel com a visão original de Nakamoto, sendo que a versão 2.6 representa um passo significativo para cumprir suas expectativas. Esta versão traz melhorias substanciais em relação aos seus predecessores, com o objetivo de:

  • Restringir a aceleração de hardware, permitindo a manutenção do consenso com uma CPU de uso geral + disco rígido mecânico, reduzindo assim os custos de armazenamento;
  • Direcione os custos de consenso direto para o armazenamento eficiente de dados em vez da competição de hash intensiva em energia;
  • Incentivar os mineradores a estabelecerem cópias completas de seus conjuntos de dados Arweave, possibilitando um roteamento de dados mais rápido 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 Cadeia de Hash, que é o algoritmo de criptografia mencionado anteriormente e gera um hash de mineração SHA-256 a cada segundo.
  • O minerador seleciona o índice de uma partição nos dados que armazena e o utiliza juntamente com o hash de mineração e o endereço de mineração como as informações de entrada de mineração para iniciar a mineração.
  • Gerar uma faixa de recall 1 na partição escolhida e outra faixa de recall 2 em uma posição aleatória na rede de entrelaçamento.
  • Use os blocos de dados de recall (Chunks) dentro da faixa 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, prossiga para calcular o próximo bloco de recall na faixa.
  • Lembrar que os blocos de dados no intervalo 2 também podem ser calculados e verificados, mas suas soluções requerem o hash do intervalo 1.

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

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

Dados Arweave: Também conhecido como a “Rede Weave.” Todos os dados na rede são divididos em blocos de dados individuais, chamados de Chunks (os blocos se assemelham a um “muro de tijolos” no diagrama). Esses blocos são distribuídos uniformemente por toda a rede Arweave e são endereçados usando 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 hash os blocos de dados correspondentes para ganhar o direito de minerar, provando que eles armazenam cópias dos dados durante o processo de mineração do SPoRA.

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

Intervalo de Recuperação: Intervalo de Recuperação é outro novo conceito na versão 2.6. Ele representa uma série de blocos de dados contíguos (Chunks) na Rede Weave, começando de um deslocamento específico e tendo um comprimento de 100MB. Com cada bloco de dados sendo de 256 KB, um Intervalo de Recuperação inclui 400 blocos de dados. Neste mecanismo, existem dois Intervalos de Recuperação, conforme explicado detalhadamente abaixo.

Soluções Potenciais: Cada bloco de dados de 256KB dentro da Faixa de Recordaçã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 bem-sucedido, o minerador ganha o direito de minerar e recebe recompensas de mineração. Se não tiver sucesso, o minerador continua tentando o próximo bloco de 256KB dentro da Faixa de Recordação.

Cadeia de Hash: A Cadeia de Hash é uma atualização chave na versão 2.6, adicionando um relógio criptografado ao anterior SPoRA, limitando a taxa máxima de hash. A Cadeia de Hash gera uma sequência de hashes ao hashear consecutivamente um pedaço de dados usando a função SHA-256. Esse processo não pode ser paralelizado (facilmente alcançável com CPUs de nível de consumidor), 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 observar que o hash de mineração é consistente entre todos os mineradores, e todos os mineradores podem verificá-lo.

Agora que introduzimos todos os termos necessários, podemos entender 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 introduzido várias vezes antes, que é maximizar o número de réplicas de dados armazenadas na rede. Mas o que armazenar? Como armazenar? Há 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: Replicas 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 eu entender o mecanismo. Para facilitar a compreensão, prefiro traduzir Replicas como "副本" (replicas) 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 unicidade. A rede Arweave incentiva o armazenamento de réplicas em vez de simples backups.

Nota: Na versão 2.7, o mecanismo de consenso mudou para SPoRes, que significa Provas Sucintas de Replicações, baseadas no armazenamento de réplicas. Eu fornecerei mais interpretação no futuro.

Empacotando Réplicas Únicas

Réplicas únicas são cruciais no mecanismo Arweave. Os mineradores 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 você deseja executar um novo nó e pensar em copiar diretamente os dados que outros mineradores já empacotaram, não funcionará. Primeiro, você precisa baixar e sincronizar os dados originais da Rede Weave Arweave (é claro, você não quer baixar tudo, baixar apenas uma parte também é viável, e você pode definir suas próprias políticas de dados para filtrar dados arriscados). Em seguida, use a função RandomX para empacotar cada bloco de dados dos dados originais, transformando-os em soluções potenciais de mineração.

O processo de embalagem envolve fornecer uma Chave de Embalagem para a função RandomX, permitindo que ela gere resultados por meio 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 usando os resultados gerados por meio 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 minerada venha de uma réplica única de blocos de dados dentro de um bloco específico. Se um bloco de dados tiver múltiplos backups em diferentes locais na rede quebrada, cada backup precisa 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 endereço do minerador (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 mineradores 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 seguintes imagens.

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

Cenário 1:

  • O minerador Bob achou o download de dados muito demorado, então ele baixou dados apenas das primeiras 4 partições da rede quebrada.
  • Para maximizar as réplicas de mineração nessas 4 partições, Bob teve uma ideia inteligente. Ele fez 4 cópias dos dados dessas 4 partições e agrupou-os em 4 recursos de réplicas únicas usando diferentes endereços de mineração. Agora, Bob tem 16 partições em seu espaço de armazenamento. Isso está bem e está em conformidade com as regras de réplicas únicas.
  • Em seguida, Bob pode realizar testes de infraçã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 astúcia de Bob tem um custo, pois ele tem que renunciar a uma oportunidade de mineração para cada faixa de recall. Veja aqueles "pontos de interrogação"? Eles representam a segunda faixa de recall que Bob não consegue encontrar em seu disco rígido, pois marcam 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.
  • Portanto, essa estratégia permite que 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. Isso é ilustrado na Figura 3.

  • A mineradora Alice, ao contrário da abordagem “inteligente” de Bob, baixa diligentemente os dados da partição para todas as 16 partições e usa apenas um endereço de mineração para formar uma réplica única com 16 backups.
  • Uma vez que Alice também tem 16 partições, as soluções potenciais totais para a primeira faixa de recall são iguais às de Bob, que também são 6400.
  • No entanto, neste cenário, Alice obtém todas as soluções potenciais para a segunda faixa de recall. Isso representa mais 6400.
  • Portanto, a estratégia de Alice lhe dá 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 Recuperação

Você pode se perguntar 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 mineradores procurassem e fornecessem provas de armazenamento, enquanto na versão 2.6, ele hashava uma faixa de recall em vez disso.

A razão é bastante simples: uma gama de recall é composta 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 seja comparável aos mais caros discos de estado sólido (SSDs). É como amarrar uma mão e um pé de um SSD; é claro, ainda pode ter uma ligeira vantagem de velocidade sendo capaz de transferir quatro gamas de recall por segundo. No entanto, comparado aos HDDs mais baratos, sua contagem será a métrica chave que impulsiona 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 seu hash de mineração gerado para verificar o hash de mineração do novo bloco.

Se um validador não estiver na cabeça atual da cadeia de hash, cada hash de mineração inclui 25 checkpoints de 40 milissegundos. Esses checkpoints são os resultados consecutivos da hash por 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 concluirão rapidamente a verificação dos primeiros 25 checkpoints em 40 milissegundos. Se a verificação for bem-sucedida, isso desencadeia a propagação do bloco e continua a validar os checkpoints restantes.

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

Embora a cadeia de hash deva 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 minerador ou grupo de mineração tiver capacidades de hash SHA256 mais rápidas, sua cadeia de hash pode avançar à frente de outros nós na rede. Com o tempo, essa vantagem de velocidade de bloco pode se acumular em um deslocamento de cadeia de hash significativo, fazendo com que os hashes minerados fiquem fora de sincronia com o restante dos validadores. Isso poderia levar a uma série de forks e reorganizações incontroláveis.

Para reduzir a probabilidade de tais deslocamentos da 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 mineradores com um bloco validado.

O intervalo para sementes de 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 autorais pertencem ao autor original [Arweave Oasis]. Se você tiver alguma objeção à reprodução, entre em contato Portão Aprenderequipe, a equipe lidará com isso o mais rápido possível.

  2. Aviso Legal: As visões e opiniões expressas neste artigo representam apenas as visõ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 Gate Learn. Salvo indicação em contrário, é proibida a cópia, distribuição ou plágio dos artigos traduzidos.

Arweave 2.6: Potencialmente se 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 via CPU - ainda não foi totalmente realizada. Os mecanismos iterativos da Arweave podem se alinhar de maneira mais fiel com a visão original de Nakamoto, com a versão 2.6 marcando um passo significativo em direção ao cumprimento de suas expectativas.

Introdução

Em cerca de um mês, #Bitcoinestá pronto para iniciar seu próximo halving. No entanto, o autor acredita que a visão de Satoshi Nakamoto - consenso acessível a todos via CPU - ainda não foi realizada. Nesse sentido, os mecanismos iterativos da Arweave podem se alinhar de forma mais fiel com a visão original de Nakamoto, sendo que a versão 2.6 representa um passo significativo para cumprir suas expectativas. Esta versão traz melhorias substanciais em relação aos seus predecessores, com o objetivo de:

  • Restringir a aceleração de hardware, permitindo a manutenção do consenso com uma CPU de uso geral + disco rígido mecânico, reduzindo assim os custos de armazenamento;
  • Direcione os custos de consenso direto para o armazenamento eficiente de dados em vez da competição de hash intensiva em energia;
  • Incentivar os mineradores a estabelecerem cópias completas de seus conjuntos de dados Arweave, possibilitando um roteamento de dados mais rápido 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 Cadeia de Hash, que é o algoritmo de criptografia mencionado anteriormente e gera um hash de mineração SHA-256 a cada segundo.
  • O minerador seleciona o índice de uma partição nos dados que armazena e o utiliza juntamente com o hash de mineração e o endereço de mineração como as informações de entrada de mineração para iniciar a mineração.
  • Gerar uma faixa de recall 1 na partição escolhida e outra faixa de recall 2 em uma posição aleatória na rede de entrelaçamento.
  • Use os blocos de dados de recall (Chunks) dentro da faixa 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, prossiga para calcular o próximo bloco de recall na faixa.
  • Lembrar que os blocos de dados no intervalo 2 também podem ser calculados e verificados, mas suas soluções requerem o hash do intervalo 1.

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

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

Dados Arweave: Também conhecido como a “Rede Weave.” Todos os dados na rede são divididos em blocos de dados individuais, chamados de Chunks (os blocos se assemelham a um “muro de tijolos” no diagrama). Esses blocos são distribuídos uniformemente por toda a rede Arweave e são endereçados usando 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 hash os blocos de dados correspondentes para ganhar o direito de minerar, provando que eles armazenam cópias dos dados durante o processo de mineração do SPoRA.

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

Intervalo de Recuperação: Intervalo de Recuperação é outro novo conceito na versão 2.6. Ele representa uma série de blocos de dados contíguos (Chunks) na Rede Weave, começando de um deslocamento específico e tendo um comprimento de 100MB. Com cada bloco de dados sendo de 256 KB, um Intervalo de Recuperação inclui 400 blocos de dados. Neste mecanismo, existem dois Intervalos de Recuperação, conforme explicado detalhadamente abaixo.

Soluções Potenciais: Cada bloco de dados de 256KB dentro da Faixa de Recordaçã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 bem-sucedido, o minerador ganha o direito de minerar e recebe recompensas de mineração. Se não tiver sucesso, o minerador continua tentando o próximo bloco de 256KB dentro da Faixa de Recordação.

Cadeia de Hash: A Cadeia de Hash é uma atualização chave na versão 2.6, adicionando um relógio criptografado ao anterior SPoRA, limitando a taxa máxima de hash. A Cadeia de Hash gera uma sequência de hashes ao hashear consecutivamente um pedaço de dados usando a função SHA-256. Esse processo não pode ser paralelizado (facilmente alcançável com CPUs de nível de consumidor), 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 observar que o hash de mineração é consistente entre todos os mineradores, e todos os mineradores podem verificá-lo.

Agora que introduzimos todos os termos necessários, podemos entender 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 introduzido várias vezes antes, que é maximizar o número de réplicas de dados armazenadas na rede. Mas o que armazenar? Como armazenar? Há 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: Replicas 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 eu entender o mecanismo. Para facilitar a compreensão, prefiro traduzir Replicas como "副本" (replicas) 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 unicidade. A rede Arweave incentiva o armazenamento de réplicas em vez de simples backups.

Nota: Na versão 2.7, o mecanismo de consenso mudou para SPoRes, que significa Provas Sucintas de Replicações, baseadas no armazenamento de réplicas. Eu fornecerei mais interpretação no futuro.

Empacotando Réplicas Únicas

Réplicas únicas são cruciais no mecanismo Arweave. Os mineradores 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 você deseja executar um novo nó e pensar em copiar diretamente os dados que outros mineradores já empacotaram, não funcionará. Primeiro, você precisa baixar e sincronizar os dados originais da Rede Weave Arweave (é claro, você não quer baixar tudo, baixar apenas uma parte também é viável, e você pode definir suas próprias políticas de dados para filtrar dados arriscados). Em seguida, use a função RandomX para empacotar cada bloco de dados dos dados originais, transformando-os em soluções potenciais de mineração.

O processo de embalagem envolve fornecer uma Chave de Embalagem para a função RandomX, permitindo que ela gere resultados por meio 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 usando os resultados gerados por meio 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 minerada venha de uma réplica única de blocos de dados dentro de um bloco específico. Se um bloco de dados tiver múltiplos backups em diferentes locais na rede quebrada, cada backup precisa 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 endereço do minerador (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 mineradores 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 seguintes imagens.

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

Cenário 1:

  • O minerador Bob achou o download de dados muito demorado, então ele baixou dados apenas das primeiras 4 partições da rede quebrada.
  • Para maximizar as réplicas de mineração nessas 4 partições, Bob teve uma ideia inteligente. Ele fez 4 cópias dos dados dessas 4 partições e agrupou-os em 4 recursos de réplicas únicas usando diferentes endereços de mineração. Agora, Bob tem 16 partições em seu espaço de armazenamento. Isso está bem e está em conformidade com as regras de réplicas únicas.
  • Em seguida, Bob pode realizar testes de infraçã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 astúcia de Bob tem um custo, pois ele tem que renunciar a uma oportunidade de mineração para cada faixa de recall. Veja aqueles "pontos de interrogação"? Eles representam a segunda faixa de recall que Bob não consegue encontrar em seu disco rígido, pois marcam 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.
  • Portanto, essa estratégia permite que 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. Isso é ilustrado na Figura 3.

  • A mineradora Alice, ao contrário da abordagem “inteligente” de Bob, baixa diligentemente os dados da partição para todas as 16 partições e usa apenas um endereço de mineração para formar uma réplica única com 16 backups.
  • Uma vez que Alice também tem 16 partições, as soluções potenciais totais para a primeira faixa de recall são iguais às de Bob, que também são 6400.
  • No entanto, neste cenário, Alice obtém todas as soluções potenciais para a segunda faixa de recall. Isso representa mais 6400.
  • Portanto, a estratégia de Alice lhe dá 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 Recuperação

Você pode se perguntar 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 mineradores procurassem e fornecessem provas de armazenamento, enquanto na versão 2.6, ele hashava uma faixa de recall em vez disso.

A razão é bastante simples: uma gama de recall é composta 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 seja comparável aos mais caros discos de estado sólido (SSDs). É como amarrar uma mão e um pé de um SSD; é claro, ainda pode ter uma ligeira vantagem de velocidade sendo capaz de transferir quatro gamas de recall por segundo. No entanto, comparado aos HDDs mais baratos, sua contagem será a métrica chave que impulsiona 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 seu hash de mineração gerado para verificar o hash de mineração do novo bloco.

Se um validador não estiver na cabeça atual da cadeia de hash, cada hash de mineração inclui 25 checkpoints de 40 milissegundos. Esses checkpoints são os resultados consecutivos da hash por 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 concluirão rapidamente a verificação dos primeiros 25 checkpoints em 40 milissegundos. Se a verificação for bem-sucedida, isso desencadeia a propagação do bloco e continua a validar os checkpoints restantes.

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

Embora a cadeia de hash deva 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 minerador ou grupo de mineração tiver capacidades de hash SHA256 mais rápidas, sua cadeia de hash pode avançar à frente de outros nós na rede. Com o tempo, essa vantagem de velocidade de bloco pode se acumular em um deslocamento de cadeia de hash significativo, fazendo com que os hashes minerados fiquem fora de sincronia com o restante dos validadores. Isso poderia levar a uma série de forks e reorganizações incontroláveis.

Para reduzir a probabilidade de tais deslocamentos da 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 mineradores com um bloco validado.

O intervalo para sementes de 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 autorais pertencem ao autor original [Arweave Oasis]. Se você tiver alguma objeção à reprodução, entre em contato Portão Aprenderequipe, a equipe lidará com isso o mais rápido possível.

  2. Aviso Legal: As visões e opiniões expressas neste artigo representam apenas as visõ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 Gate Learn. Salvo indicação em contrário, é proibida a cópia, distribuição ou plágio dos artigos traduzidos.

Lancez-vous
Inscrivez-vous et obtenez un bon de
100$
!