^Esse artigo foi traduzido por Dimitris Carvalho Calixto e pode ser encontrado originalmente aqui.
TECNOLOGIA
A nuvem operada pela comunidade da NEAR usa um novo algoritmo de consenso e uma arquitetura de fragmentação escalável para atingir seus objetivos de design de alto nível.
Os elementos chave da tecnologia do NEAR são:
A fragmentação: O sistema é concebido para escalar horizontalmente e de forma quase infinita, distribuindo o cálculo por múltiplos fragmentos paralelos.
Consenso: O consenso é alcançado em todos os nós que compõem os operadores de rede através de todos os fragmentos, utilizando o novo algoritmo Nightshade.
Seleção de Staking e Teoria do Jogo: Para participar no processo de validação, os stakers são selecionados utilizando um processo aleatório seguro que distribui de forma otimizada os lugares entre as partes e fornece incentivos para que operem com bom comportamento.
Aleatoriedade: A abordagem da aleatoriedade da NEAR é imparcial, imprevisível e pode tolerar até 1/3 de atores maliciosos antes que a vida seja afetada e 2/3 de atores maliciosos antes que qualquer um possa realmente influenciar a sua produção.
Princípios de design tecnológico
Os princípios gerais de concepção do sistema NEAR são utilizados para informar a sua concepção técnica de acordo com as seguintes interpretações:
1.Usabilidade: Os utilizadores finais devem ser sobrecarregados com as mais baixas obrigações de segurança possíveis para um determinado tipo de interação. Os programadores devem ser capazes de construir, testar e implementar facilmente contratos em línguas familiares e devem ser capazes de fornecer aos seus utilizadores finais experiências próximas da web atual.
2.Escalabilidade: A plataforma deve ser escalada infinitamente à medida que a sua capacidade é utilizada.
3.Simplicidade: A concepção de cada um dos componentes do sistema deve ser tão simples quanto possível, de modo a atingir o seu objetivo principal.
4.Descentralização sustentável: A barreira para a participação na plataforma como nó de validação deve ser colocada o mais baixo possível, a fim de trazer uma vasta gama de participantes. As transações individuais realizadas no futuro devem ser pelo menos tão seguras como as realizadas hoje, a fim de salvaguardar o valor que elas modificam.
Resumo
A NEAR concentra-se em fornecer soluções para os dois problemas centrais das blockchains de hoje - Usabilidade e Escalabilidade.
A usabilidade para os utilizadores finais é conseguida através da oferta de um modelo progressivo de segurança para as interações com a carteira digital e dando aos programadores mais oportunidades de criar experiências que se assemelham muito à web de hoje em dia. Estas são fornecidas por uma gestão de chaves flexível e programável implementada a nível de protocolo como resultado do modelo de conta baseado em contrato da NEAR. Isto permite que coisas como meta-operações, transferências de contas atômicas, contas com fundos bloqueados para uso específico e outras programações de contas e casos de utilização restrita sejam facilmente implementadas.
A usabilidade para os programadores é fornecida através da criação do protocolo que permite a depuração baseada em browser, linguagens de programação familiares (como AssemblyScript e Rust) e descontos de utilização de contratos ("Contract Reward").
A escalabilidade é proporcionada pela divisão da cadeia num número potencialmente ilimitado de sub-cadeia, cada uma das quais opera em paralelo.
Características de performance e tradeoffs
Um trilemma comumente referenciado afirma que um sistema não pode alcançar a escalabilidade, descentralização e segurança ao mesmo tempo. As abordagens de seleção de fragmentação e validação do NEAR proporcionam uma escalabilidade e descentralização significativas ao mesmo tempo que atenuam os tradeoffs em segurança que normalmente ocorreriam com tais melhorias.
Outro trilema clássico é colocado pelo teorema da PAC, que afirma que um sistema só pode alcançar 2 de Consistência, Disponibilidade (aka "vivacidade") e Tolerância de Partição. Dado que a tolerância de partição não pode ser sacrificada neste caso, a troca é realmente entre a consistência e a disponibilidade.
Em sistemas baseados em blockchains, um exemplo ilustrativo é o que acontece se a rede se dividir em duas partes durante uma semana. Um sistema consistente desligará completamente uma (ou ambas) das metades até que a rede seja restaurada de modo a que as duas partes não se tornem inconsistentes. Um sistema disponível (como o Bitcoin) continuará a executar ambas as metades da rede independentemente e, quando forem restauradas à unidade, as operações de uma metade serão eliminadas em favor das operações da outra.
O NEAR favorece atualmente a disponibilidade a nível do sistema, mas os utilizadores individuais podem optar por não aceitar blocos sem limites de assinatura >50%, como forma de exigir também consistência a nível local.
O desempenho do sistema será altamente dependente dos tipos de transações que são processadas e do hardware real que o suporta. No caso de transações financeiras simples, o rendimento por parcela poderá variar entre 400-2000 transações por segundo.
Sharding
As abordagens atuais à escalabilidade dividem-se tipicamente em duas categorias:
1.Escalabilidade Vertical: Conseguido através da melhoria do desempenho do hardware existente de um sistema. No caso de sistemas baseados em blockchains , significa tipicamente executar uma rede contendo menos nós que cada um requer mais hardware. Isto cria uma melhoria inicial no rendimento, ao mesmo tempo que limita as melhorias futuras à taxa de aumento do desempenho do hardware de computação (muitas vezes considerado como a "Lei de Moore"). Isto deixa a rede sem a capacidade de escalar a uma taxa proporcional à sua adoção.
2.Escala Horizontal: Conseguido ao adicionar mais hardware a um sistema. No caso das blockchains, isto é normalmente feito assegurando que um aumento do número de nós participantes na rede melhora o desempenho dessa rede por uma quantidade proporcional, por exemplo, através de um cálculo paralelo através de múltiplos "cacos".
A NEAR utiliza uma abordagem de fragmentação para proporcionar uma escalabilidade horizontal, o que lhe permite escalar a capacidade a par do aumento da procura.
Comunicação Cross-Chain e Cross-Shard
Uma das maiores dificuldades com qualquer forma de comunicação entre cadeias, que ocorra dentro dos cacos de uma única cadeia ou através de múltiplas cadeias, é determinar que uma transação recebida de outra cadeia é válida. Existem 3 abordagens para a validação de transações entre cadeias:
1.Validação em dupla cadeia : Os validadores da cadeia receptora devem também validar na cadeia de envio. Isto é utilizado pelo Quarkchain. Tem a desvantagem de os validadores não terem uma boa escala nesta abordagem.
2.Confie na Transação : Assumir que se uma transação tiver sido recebida, deve ser válida. No Cosmos, por exemplo, uma transação que é copiada para o centro principal é considerada irreversível. Mantêm um registro do número total de tokens em cada economia, pelo que não se pode criar novos tokens, mas teoricamente pode-se criar transferências inválidas entre as partes (por exemplo, roubar tokens de outras partes).
3.Cadeia Beacon com Rollback: Uma cadeia de balizas verifica as transições de estado de todas as outras cadeias usando um pequeno subconjunto de validadores e, se for detectado um problema, todas as cadeias são enroladas para trás. Para alcançar a atomicidade, esta reversão deve acontecer, embora só raramente e deve ser imediatamente detectada.
A NEAR concentra-se na 3ª abordagem. Com o pressuposto de que um adversário adaptável não pode corromper os validadores de um fragmento dentro de um dia, os validadores de cada fragmento podem ser rodados diariamente para ajudar a acrescentar uma camada de segurança. Mas presumivelmente é possível (se muito difícil) que um adversário adaptável corrompa os validadores de um fragmento dentro de um determinado dia.
Para ajudar a compensar isto, outros protocolos utilizam um comité mais pequeno que gira muito mais rapidamente (por exemplo, de poucos em poucos minutos) é válido através de estilhaços. Para que este comité mais pequeno possa realizar as suas validações sem ter de descarregar todo o estado de cada fragmento (o que não pode ser feito neste período de tempo), eles recebem apenas a parte do estado que foi realmente afetada. Mas é difícil enviar o estado com cada alteração - uma única transação pode afetar 100mb de estado de cada vez.
É aqui que entra a abordagem Nightshade sharding.
Nightshade
Nightshade modifica a típica abstração de fragmentos e assume que todos os fragmentos se combinam para produzir um único bloco. Este bloco é produzido com uma cadência regular, independentemente de cada fragmento individual ter produzido o seu " fragmento" para aquela altura específica do bloco. Assim, cada pedaço de cada fragmento estará ou não presente.
Deve haver uma regra de escolha de fork para decidir sobre o fork adequado. Isto ainda está em desenvolvimento, mas muito provavelmente assemelha-se a um Fantasma LMD. Incluirá o peso de quantos atestados de validação foram recebidos para um determinado pedaço e bloco.
Existe um único validador designado para produzir cada bloco. Este validador deve reunir os pedaços que lhe são fornecidos durante o período de tempo desse bloco no bloco do período. A atribuição deste validador irá rodar através do conjunto de validadores existentes (por exemplo, 100 validadores). Este líder não aceita transações, apenas pedaços.
Para cada fragmento e período individual, é atribuído um único validador para produzir o seu pedaço. Se esse validador não estiver presente, a fração irá empatar durante esse período. Cada fragmento tem o seu próprio grupo mais pequeno de validadores que é retirado do grupo principal. A posição do líder da fração gira entre esta reserva mais pequena (por exemplo, 4 validadores) da mesma forma que o líder global do bloco é selecionado. Assim, se um único validador estiver ausente e o fragmento estiver parado durante um período, o validador seguinte estará provavelmente presente para continuar o funcionamento da cadeia no período seguinte.
Saiba mais sobre o desenho do fragmento da NEAR white paper Nightshade.
Validadores Ocultos
A fim de proporcionar segurança adicional, a NEAR utiliza validadores ocultos. Estes são uma comissão menor para cada fragmento (em média 100 validadores) que verificam cada pedaço. Em vez de ter esta tarefa na blockchain e, portanto, visível publicamente a todos os participantes, os próprios validadores definem a sua tarefa individualmente desenhando um conjunto de identificadores de fragmentos de uma Função Aleatória Verificável (VRF).
Desta forma, cada validador individual está ciente dos fragmentos que deve verificar mas, para os corromper, um adversário deve subornar uma grande percentagem do total de validadores em todos os fragmentos para revelar as suas máscaras.
Além disso, o número de validadores ocultos atribuídos a um determinado bloco é também determinado aleatoriamente. Isto impede que um adversário saiba exatamente quantos validadores ocultos precisa mesmo de corromper em primeiro lugar, a fim de conseguir um ataque. Isto impede ataques em que um adversário transmite a sua intenção e espera que os pescadores cheguem até eles (revelando quais os fragmentos que estão a validar).
Devido à natureza da verificação, qualquer único validador oculto pode apresentar uma prova de que o pedaço é inválido, uma chamada "prova de fraude".
A seleção do comitê mais pequeno por parte é feita para cada época (½ dia) a partir do mesmo pool que os produtores do bloco e dos pedaços, que é o conjunto total de nós que apostaram. Por exemplo, se houver 100 lugares por fragmento e 100 fragmentos, há um total de 10.000 lugares. 100 deles serão atribuídos para serem os produtores de blocos e de fragmentos e os restantes serão os validadores ocultos.
Fishermen
Além dos validadores ocultos que são designados para fornecer segurança para cada fragmento, qualquer outro operador de nó pode participar sem autorização como um chamado "pescador" (fisherman). Este nó de terceiros pode fornecer a mesma prova de fraude que um validador oculto e, assim, também eles podem dar início ao processo de corte e retrocesso.
Isto significa que, mesmo que um adversário tenha corrompido com sucesso todo o grupo de validadores ocultos, não têm garantia de que os seus esforços não serão descobertos por um destes pescadores independentes, sendo assim altamente desincentivados.
Prevenir os validadores preguiçosos
Um problema potencial com os validadores é que eles podem ser "preguiçosos". Após cada bloco, um validador deve receber o novo pedaço, descarregar o novo estado e executar a validação nesse bloco. Podem, no entanto, optar por não fazer nada, a menos que vejam outro validador a apresentar uma prova de fraude e só então validam realmente o último bloco e tentam apresentar a sua própria prova. Assim, uma cadeia pode acabar por pagar aos validadores mas não receber trabalho significativo da sua parte.
Isto é mitigado ao fazer com que os validadores se comprometam primeiro com a sua decisão (se uma parte for válida ou inválida) e depois revelem o que cometeram. Isto cria um incentivo para fazer um trabalho adequado porque eles têm valor em jogo e serão cortados se perderem um pedaço inválido.
Prevenir Data Hoarding
Outro problema que pode ocorrer se um pedaço for corrompido ( corrompendo o seu pequeno conjunto de produtores de pedaços) e os produtores de pedaços se recusarem a fornecer dados suficientes aos validadores ocultos para que não possam validar ou fazer uma prova de fraude.
Isto é resolvido exigindo ao produtor de pedaços que envie um pedaço "apagado codificado" para outros produtores de pedaços em outros pedaços. Este código permite a estes outros produtores reconstruir o pedaço a partir de apenas 16% das partes e validadores ocultos que o possam validar. Se o produtor de pedaços (presumivelmente corrupto) não o forneceu para o seu pedaço, então nenhum outro produtor de pedaços irá atestar ou construir no topo da cadeia para a qual não tenham peças. A "regra da escolha do fork" irá selecionar a cadeia que tem pelo menos 50% das partes que têm peças.
Para evitar mau comportamento, uma única parte aleatória deste código rasurado é deliberadamente feita para ser uma "mina terrestre" (inválida). Em qualquer altura, se demonstrar que um validador atestou um bloco que contém a mina terrestre (o que é facilmente comprovado), serão cortados. Assim, para cada período há também uma pequena hipótese de que um mau agente seja cortado de modo a desincentivar altamente o mau comportamento.
Aleatoriedade
A aleatoriedade na blockchain precisa as seguintes propriedades:
Imparcial
Imprevisível
Vivacidade, ou seja, tolera que os atores fiquem offline ou atores maliciosos
Existem algumas abordagens potenciais:
RANDAO - imprevisível mas tendencioso. A vivacidade depende do protocolo de consenso subjacente;
RANDAO+VDF - imprevisível, imparável, tem vivacidade. Mas na prática, é difícil utilizá-lo e ser resistente à ASICS ao mesmo tempo;
Assinaturas de limiar - imprevisível, imparável, tem vivacidade. Mas requer um mecanismo complicado para gerar chaves privadas de uma determinada forma. Neste momento, é uma área ativa de investigação.
RandShare - imprevisível, imparável, tem vivacidade. Mas requer O(n^3) mensagens de comunicação em rede, que é muito, onde n é o número de participantes. E também se torna inviável com mais de 1/3 de participantes maliciosos, o que é um limiar baixo.
A abordagem da NEAR é imprevisível, imparável e tem vivacidade. Ao contrário de Randshare, tolera até 2/3 de participantes maliciosos antes de se tornar tendenciosa. Ao contrário das Assinaturas Threshold, é simples. Ao contrário de RANDAO+VDF, não pode ser atacado com ASICs. Saiba como funciona no whitepaper NEAR Randomness.
Top comments (0)