Mergulhando na NEAR: Nightshade

Sharding
Escalabilidade provida pela fragmentação da cadeia de operações em um número ilimitado de sub-cadeias de execuções, todas operando em paralelo. Cada sub-cadeia é referenciado como “shard”, ou em português: fragmento.

Cada shard terá uma ordem de validadores rotativos para assumir as atividades, e jamais ficará sem um validador disponível com base na demanda por poder computacional, melhor recompensada pelo comprometimento dos validadores.

Aleatoriedade
Vale ressaltar que todo o processo randômico que ocorre dentro da NEAR possui 5 etapas complexas, desde o comprometimento envolvendo a pseudoaleatoriedade de cada node, com o seu consenso criando tolerância a ações maliciosas e participantes ficando offline, e suas mecânicas permitindo um modelo que melhora o score de nodes honestos para continuar a criação de números randômicos que correspondem ao seu consenso. A paralelidade permite em tempo real a descoberta de novos números aleatórios e o ingresso de novos nodes assim como o desligamentos.

O nome desse modelo de aleatoriedade é chamado de ‘randomness beacon’, implementado de diversas formas, em várias blockchains. O design apresentado pela NEAR mal riscou a superfície da complexidade que podemos nos aprofundar nesse assunto, mas saiba que ela realizou essa tarefa de maneira elegante.

Beacon-Chain
Beacon-chain, é uma sub blockchain que opera em paralelo a uma Mainnet e pode ser encontrada na Polkadot, Cosmos, Ethereum, entre outras, cada qual com suas modificações, mas partilhando seu objetivo intrínseco. Diferente da blockchain “principal”, esta funciona como se fosse em “memória”, o “cache” da blockchain. Ela se responsabiliza pela manutenção dos processos internos, viabilizando as mecânicas de consenso a funcionarem adequadamente; entre outras funções variando de rede para rede.

Esse modelo de operação trás diversas vantagens ao ecossistema da NEAR como, por exemplo, sub-cadeias maliciosas podem gerar toda uma linha histórica de acontecimentos forjados e tentar enganar a beacon chain sobre a alteração em seu estado. Ao reconhecer essa malícia, é possível reverter todas as transações envolvidas em seu processo pela forma como a beacon chain registra os cabeçalhos de cada acontecimento, funcionando como uma contabilidade, um administrador de shards. Também coordena a geração de números aleatórios, decide os validadores de cada shard, mantém o registro dos snapshots e coordena o sistema de recompensas – no caso da NEAR.

Quadratic Sharding
Através de melhorias nos nodes, através de melhorias ou no hardware ou no software, habilitando uma melhoria na taxa de transações, a rede como um todo consegue quadruplicar o output final. Se cada shard dobrar sua capacidade, a beacon chain também dobra, e por consequência, suporta o dobro de shards. Então a cada duas vezes mais poder computacional da beacon, quatro vezes mais shards, logo, quatro vezes mais transações por segundo.

Cross-shard
Existem dois tipos de cross-shard, assíncrona e síncrona:
O modelo síncrono precisa que todos os validadores produzam ao mesmo tempo todos os blocos que contenham partes da transação cross-shard, estes colaboram para executar rapidamente essa demanda.
Enquanto o modelo assíncrono, funciona com um sistema de crédito, quando uma transação cross-shard afeta muitas shards, estas só vão iniciar e executar as atividades referentes ao pagamento desferido, ou seja, quando tiverem certeza de que o débito já foi adicionado.
Existe um grande problema que ocorre somente em redes que operam com shards. Quando algumas shards se integram e participam do consenso, estas não conseguem baixar imediatamente o histórico de outras shards, muito menos escolher onde vai operar, correndo o risco de se envolver na criação de algum cross-shard maligno que será revertido no futuro, desperdiçando seu tempo de processamento e comprometimento com a rede.

Atividades Maliciosas
Podemos ficar tranquilos pois já existem diversas abordagem que aumentam o nível de segurança quanto a essa preocupação. Uma ideia proposta por Vlad Zamfir’s, nos mostrou que é possível arranjar as shards de forma a reconhecerem suas vizinhas e apenas permitir cross-shard entre vizinhos, reduzindo a probabilidade de novas shards se conectarem a chains malignas. Embora corromper apenas uma shard deixa de ser o problema, ainda temos o problema de múltiplas shards serem contaminadas..

Fisherman é um modelo de que valida o consenso através do download de blocos que estão vinculados com a beacon chain, se validadores tentarem adicionar um cabeçalho de bloco maligno ou usado para adicionar uma transação cross-shard, mas nunca tendo distribuído o bloco, não há como um validador abrir uma disputa. Com a técnica do Fisherman, é possível abrir disputas contra blocos ao longo de um determinado tempo; obrigado a verificar essas disputas, as shards vão ter um novo desafio, impedir que disputas maliciosas adentrem o ecossistema, floodando a rede, desperdiçando poder computacional. Ainda há mais uma problemática entre o uso dos cabeçalhos das beacon chain e do histórico individual de cada shard.

A solução para ambos os problemas, flood da rede e blocos não distribuídos, será explorado com essas três abordagens:

1. Prova de custódia
   Atores rotacionam aleatoriamente entre as shards, baixando um único bloco e contestando o fato de que o bloco foi possível de ser baixado. Por não precisarem ver o histórico completo da shard, estes conseguem rotacionar em uma maior quantidade de shards. No entanto esse processo também é falseável, visto que os atores podem escolher informar que conseguiram baixar o bloco sem ao menos testar. Para essa condicional, a solução é o ator prover algum tipo de evidência, ou uma quantidade de tokens em Staking, confirmando que o bloco foi baixado.

2. Rasuras
   Permite recuperar o bloco completo mesmo fornecendo apenas algumas partes do bloco. Esse design também é utilizado por outras blockchains, e se destrincha das funcionalidades da Patricia Merkle Tree.

3. Disponibilidade de dados
   Na rede Polkadot, a solução em shards – chamada de parachains – realiza snapshots de seus blocos para a beacon chain – chamada relay chain. Quando os blocos são computados, recebem esse trecho de código com informações suficientes para caso seja necessário, reconstruir o bloco. Cada parte desse trecho é distribuída entre os validadores da relay chain. Que apenas vão assinar algum bloco se tiverem cada parte do bloco da parachain com seu snapshot referenciado na relay chain.
   Os métodos acima ainda têm um porém, eles consideram que blocos estão sendo criados e estão disponíveis, mas no longo prazo, podem não estar. Sendo uma desvantagem do sistema de shards, o alto custo de validar a todos os blocos. Ainda que longe, é algo a se pensar.

Percebemos que a maioria das mecânicas são somadas na tentativa de sempre estão mitigando a possibilidade de contaminação de todo um conjunto de blocos que possa enganar a blockchain inteira a trabalhar em pró desses atores malignos. E vimos o importante papel que validadores honestos exercem para o ecossistema.

Recapitulando: Validadores em cada shard fazem download de cada bloco nesse shard e validam todas as transações nesse shard, mas outros nodes do sistema, incluindo aqueles que capturam o snapshot dos estado das cadeias das shards na beacon chain, baixe apenas os cabeçalhos.

Mas o que são os snapshots?

Snapshots
O primeiro bloco de cada epoch precisa ser um snapshot block. Cada bloco na cadeia principal do Nightshade pode opcionalmente conter uma Schnorr multisignature no cabeçalho do último bloco que incluiu tal multiassinatura Schnorr.

Em um sistema que opera diversas validações ao mesmo tempo, é complexo garantir que haja uma ordem na execução enquanto cria-se um rastro para reconstrução e, ao mesmo tempo, validar esse trajeto dependem do funcionamento de várias mecânicas conjuntas.

A beacon chain registra uma cadeia dos snapshots registrados pelas shards, mas apenas o seu cabeçalho, assim os validadores desse shard são efetivamente nós completos para esse shard, enquanto outros participantes do sistema, incluindo a cadeia de beacon, operam como nós leves.

Para validar e contextualizar melhor o que a snapshot chain faz, precisamos entender como os validadores e produtores de blocos vão coordenar suas atividades. Um validador precisa publicar um commit de uma mensagem e uma assinatura, naturalmente, a resposta de cada validador será diferente uma da outra, por compartilhar suas características, uma estrutura para agregar essas mensagens e assinaturas para validações futuras, se faz necessária.

Quando um total de mensagens é acumulada, é computada a sua assinatura com a merkle tree, e enviada para os validadores junto a sua mensagem. O produtor do bloco vai publicar estes dados acumulados e vai assinar usando uma assinatura ECDSA, para em caso de disparidade na verificação, abrir disputas contra o cabeçalho e buscar por validar o histórico.

Esse sistema de regressão é altamente custoso e só deve ser utilizado no mínimo de casos possíveis, por isso existe inclusive um estímulo financeiro para nodes que tiverem mais validadores atrelados a eles, dispostos a participar do processo de agregar mensagens e aumentar a segurança e descentralização.

Os blocos que contem em seu cabeçalho um snapshot com as instruções da regressão torna-se a snapshot chain.

O modelo de consenso apresentado pela NEAR, chamado de Nightshade é um modelo de proo-of-stake usando shards paralelas – sub-chains – para decentralizar a agilizar o processo de validação. Ao mesmo tempo registrando a snapshot chain para se ter segurança e confiança entre os validadores, punindo financeiramente as tentativas de atividades maliciosas e estimulando a participação no modelo de consenso.

Conclusão
Parece ser infinito o nível de aprofundamento que se pode atingir ao percorrer os funcionamentos de uma blockchain, a cada nova ramificação, são tantas possibilidades, que até todas serem compreendidas e mapeadas, novas tecnologias já assumiram o lugar e as atuais tornam-se passado e lorota de Twitter.

NEAR é uma blockchain sensacional quando a comparamos com as demais. Embora seu objetivo intrínseco seja o mesmo, criar um ecossistema programável, amigável e portável, permitir smart contracts e interações entre usuários e contratos, falamos aqui das mesmas modalidades e objetivos que são mais alinhados, a maneira como a NEAR executou cada uma das micro atividades, tornou o seu macro modelo de negócios uma poderosa ferramenta independente de outras blockchains, mas que ao mesmo tempo, manteve uma passagem até então imune a atores malignos com a blockchain Ethereum.

Pensando na escalabilidade e segurança ao longo do tempo, e principalmente na usabilidade da sua comunidade, demonstrando uma calorosa recepção para todos os usuários da web3 e sempre se preocupando em passar uma visão clara e elegante quanto a suas atividades e processos internos e externos, transparente e confiável.

Esse documento não é definitivo, por favor ajude a comunidade a mantê-lo.

Part 2 <> Part 3