Vous êtes sur la page 1sur 12

Credits Decision Consensus Algorithm

Algoritmo de Consenso de Decisão da Credits


Versão 4.1 / 20-02-2019
(Aguns detalhes podem ser adicionados ou alterados)
Conteúdo
1. Definição geral ................................................................................................................ 3
2. Formação de transações e sua distribuição na rede ....................................................... 3
2.1 Formação de pacotes de transações ................................................................. 3
2.2 Sincronização de pacotes de transações............................................................ 4
2.3 Sincronização de transações em Nodes Confiáveis .......................................... 4
2.4 Formação de listas ordenadas de transações ................................................... 5
3. Alcance de consenso ...................................................................................................... 6
3.1 Estágio 1 ........................................................................................................... 6
3.1.1 Formação de lista de Nodes Confiáveis ............................................... 6
3.1.2 Validação de transação n e formação de função característica ........... 6
3.1.3 Troca de Nodes Confiáveis - Estágio 1 ............................................... 7
3.2 Estágio 2 ........................................................................................................... 9
3.2.1 Troca de vetores de assinaturas entre Nodes Confiáveis - Estágio 2 ... 9
3.2.2 Procedimento de consenso .................................................................10
3.2.3 Formação de lista para a próxima rodada de Nodes Confiáveis..........10
3.2.4 Formação da lista da próxima rodada de transação de pacotes..........11
3.3 Estágio 3 ..........................................................................................................11
3.3.1 Gravação da transação no bloco ........................................................11
3.3.2 Formação do Meta block .....................................................................12
3.3.3 Seleção de um Node de Gravação ....................................................12
3.4 Adicionando um novo bloco na blockchain pelos nodes ....................................12

2
Definição Geral
Um consenso de rede distribuída é um método de nodes independentes atingirem uma
solução comum. O principal objetivo do consenso é uma operação estável da rede de nodes,
onde os círculos se reproduzem com certa frequência ou um algoritmo medindo ciclicamente
a vida contínua das interações ordenadas dos nodes, como um núcleo lógico do sistema
eletrônico. O consenso é capaz de realizar tarefas adicionais, como processar transações,
verificar a execução de contratos inteligentes, servir de base para a operação do sistema
distribuído para o lançamento de aplicativos ou qualquer outra carga útil que exija o consenso.

Formação de transações e sua distribuição na rede


Durante a operação de uma plataforma blockchain, dois processos de rede principais
são executados em paralelo:
• Formação das transações e sua distribuição entre os nodes da rede; • Execução de
rodadas cíclicas onde os Nodes Confiáveis (Trusted Nodes - TN) recebem autoridade para
conduzir o consenso, o que resulta em uma resolução comum em relação à inclusão de
transações em um bloco e sua geração é feita.

Formação de pacotes de transações


O ciclo de vida de uma transação começa a partir de uma carteira onde os campos
necessários para processamento adicional são preenchidos, como:
• Endereço do remetente
• Endereço do destinatário
• Quantidade de transações
• Taxa máxima que o usuário está disposto a pagar pela transação
Quando um usuário preenche todos os campos, a transação é assinada com o
ED25519, um algoritmo de criptografia assimétrica.
O usuário insere sua chave privada para assinar a transação. O armazenamento da
chave privada na carteira não é fornecido por motivos de segurança.

3
Sincronização de pacotes de transações
Um node coleta transações assinadas de carteiras e forma um pacote (Fig. 1).

Figura 1. Formação do pacote de transações

O pacote de transações inclui um número ordenado de transações (até 500) e recebe


um cabeçalho que contém o hash calculado com o algoritmo Blake2s. O pacote formado é
assinado com a chave privada do node gerada pela Ed25519 e, em seguida, enviado para a
rede por meio dos nodes vizinhos.
A rede p2p da plataforma Credits fornece a capacidade de procurar o pacote de
transações pelo seu hash. Quando um node recebe um pacote de transações de seu vizinho,
o node copia o hash do pacote para o buffer local e o envia para a rede.

Sincronização de transações em Nodes Confiáveis (Trusted


Nodes)
Depois que os nodes recebem a lista de pacotes de transações contidos na tabela,
eles começam a verificar a disponibilidade desses pacotes no buffer local. Se alguns pacotes
estiverem faltando, o processo de sincronização é iniciado. Um node solicita pacotes ausentes
de seus nodes vizinhos e, se os pacotes estiverem ausentes nesses nodes também, esses
vizinhos solicitam os pacotes de seus vizinhos e o processo é repetido até que pacotes
perdidos sejam encontrados. A disponibilidade de todos os pacotes de transações contidos
na tabela da rodada em todos os Nodes Confiáveis é a condição para uma rodada começar.

4
Formação listas ordenadas de transações
Após a conclusão da sincronização dos pacotes de transações entre os Nodes
Confiáveis da rodada atual, cada TN possui todos os pacotes de transações e pode formar
uma lista completa de transações da rodada (Fig. 2). A lista de transações da rodada é
armazenada exclusivamente no buffer local de um nodes e não é compartilhada na rede. Por
isso, não é necessário usar medidas de segurança, como hashing e criptografia, para evitar
alterações.
A lista de pacotes de transações é classificada na tabela da rodada, as transações
são classificadas nos pacotes de transações e, conseqüentemente, uma lista final de
transações da rodada também é classificada devido à transitividade. Assim, para que o
consenso seja alcançado, cada TN deve ter a mesma lista ordenada de transações a serem
processadas na rodada com a lista correspondente à lista de hashes da tabela da rodada com
pacotes de transações.

Figura 2. Formação da lista de transações

Após a lista de formação de transações, um node pode iniciar sua validação.

5
Alcance de consenso
Depois que todos os nodes da rede liberaram pacotes de transações e os trocaram
entre si, os nodes responsáveis pela execução do consenso precisam ser selecionados e
esses nodes terão que validar transações e gerar um bloco. No início, o lançamento da rede
começa a partir da formação do bloco Genesis e se expande.
Posteriormente, a rede opera em ciclos devido à rotação de rodadas e seleção
constante de novos nodes confiáveis para execução do consenso.

Estágio I

Formação da lista de Nodes Confiáveis (Trusted Nodes).


O algoritmo de operações de todos os nodes implica que, se um node tiver uma
blockchain atualizada, então, durante a geração do último bloco, ele deve calcular o hash do
bloco e enviá-lo para todos os Nodes Confiáveis da próxima rodada, cujas chaves públicas
estão contidas no meta block.
O node confiável da rodada atual, por sua vez, após receber o hash do último bloco,
forma uma lista preliminar dos candidatos para se tornar um TN na próxima rodada. Então,
com base nesta informação, a lista final de TNs da próxima rodada será determinada e
incluída no novo metablock. Se o hash não estiver correto, o node será marcado como
"incorreto".
Depois que um bloco é gerado e registrado na blockchain, os nodes enviam uma
solicitação para os TNs da próxima rodada para incluí-los na lista de candidatos para se
tornarem um TN.
Para isso, eles formam um pacote contendo a assinatura de hash do último bloco e
a chave pública do nodes, sendo posteriormente o pacote assinado pela assinatura digital do
node.
Cada Node Confiável da rodada atual verifica a validade da assinatura nos pacotes
recebidos e a correspondência do hash recebido com o hash do último bloco da TN. Esta é a
prova de que o node que enviou a assinatura corretamente validada tem a blockchain
atualizada e é capaz de validar transações na próxima rodada. Depois que o Node Confiável
recebeu a primeira quantidade N de hashes corretos do último bloco, ele forma uma lista
ordenada de chaves públicas dos nodes que serão os candidatos a Nodes Confiáveis na
próxima rodada e será incluída no pacote da primeira etapa do consenso.

Validação de transação n e formação de função característica


O Node Confiável valida transações na lista de transações da rodada formada no
node. Deve-se observar que o processo de validação de transações é executado em cada
node para todas as transações, independentemente de outros nodes, e somente após a
conclusão do processo, os nodes podem trocar informações sobre os resultados..

Durante a validação, o seguinte é verificado:


1. Se todos os campos de transação estiverem preenchidos corretamente; (é válido)
2. Se uma transação é única (exclusão de “double spending/gasto duplos”)
3. Se a assinatura da transação estiver correta;
4. Se, após a transação, o saldo for maior que 0.

6
Figura 3. Formação de um indicador (função característica)

O resultado da validação é uma função característica (Indicador) - uma seqüência de


bits, onde 1 significa transação válida e 0 - inválida. A função característica recebe um
cabeçalho que contém um hash calculado com o algoritmo de hash Blake2s e também
assinado por um Node Confiável. Para execução consensual, é formado um pacote curto que
consiste em hash de função característica (hash do indicador), campo "Timestamp" e uma
assinatura digital. O campo "TimeStamp", em cada Node Confiável, é preenchido com sua
hora local. Como resultado da troca de informações, cada Node Confiável terá informações
sobre qual“TimeStamp” cada TN fez depois que o Node de Gravação for conhecido, seu
TimeStamp também será conhecido e será possível montar o bloco a partir do meta block.

Troca de Nodes Confiáveis (Truste Nodes) – Estágio I


 Cada TN forma a seguinte estrutura:
 Número ordinal do nodes na lista de Nodes Confiáveis da rodada atual
 Hash do indicador
 Campo Timestamp
 Uma lista ordenada dos hashes dos pacotes de transações da próxima rodada
 Lista de candidatos para os Nodes Confiáveis da próxima rodada

7
Em seguida, um hash do pacote recebido é calculado usando o algoritmo Blake2s, o
número da rodada atual também é adicionado e tudo isso é assinado pela chave privada do
node usando o ED25519.
A assinatura é então adicionada à estrutura original e o pacote do estágio 1 é enviado
a todos os Nodes Confiáveis da rodada atual.
Deve-se observar que o hash em si e o número da rodada não são compartilhados.
Por isso, para validar a assinatura digital, os nodes que receberam esse pacote precisam
realizar preliminarmente as mesmas operações de forma independente.
A chave pública para validação é extraída da tabela de rodadas disponível no Trusted
Node por índice contido no primeiro campo do pacote do estágio 1.
Durante a validação do pacote recebido do Estágio 1, as seguintes verificações são
realizadas:
1) O remetente está na lista de nodes confiáveis da rodada atual. Em caso de validação
incorreta, o pacote é rejeitado.
2) Restauração do pacote (adição de hash e número da rodada) e validação de
assinatura digital. Em caso de validação incorreta, o pacote é rejeitado.
3) Se todas as verificações forem passadas, o hash do pacote do estágio 1 e assinatura
digital são colocados no Vetor de assinaturas com o número do node que formou e
enviou o pacote. Deve-se notar que os pacotes do Estágio 1 são enviados não através
de nodes intermediários, mas entregues diretamente.

Figura 4. Formação do pacote do Estágio I

8
Figure 5. Exchange of Indicators’ hashes

A Figura 5 ilustra o exemplo em que 5 TNs participam da rodada e 2 deles (Node1 e Node2)
enviaram seus pacotes formados do Estágio 1 para todos os seus vizinhos.

Figure 6

O hash do indicador é assinado por ED25519 e validado por outros nodes após o
recebimento.

Estágio II

Troca de vetores de assinaturas entre Nodes Confiáveis (Trusted Nodes)


- Estágio II
Após o recebimento do Node Confiável dos pacotes do Estágio 2, ele verifica a
assinatura com a Chave Pública do TN que enviou o pacote e, se a validação for positiva,
adiciona o par de “Hash-Signature” aos vetores de Assinaturas.
Após todos os pacotes do Estágio 1, o vetor Assinaturas formado (Fig. 6) é assinado
por ED25519 e o pacote recebido do Estágio 2 é trocado novamente com todos os outros TN.

9
Etapas de validação dos pacotes do Estágio 2 (vetores de assinaturas assinadas):
1) Validação da assinatura do pacote. A chave pública para a validação é extraída do
nível de transporte do campo "remetente".
2) Então, seqüências que diferem da maioria são detectadas no vetor. Caso o hash da
string corresponda à assinatura digital, o Trusted Node com o índice dessa string é
marcado como "incorreto".
3) Caso a assinatura digital seja diferente do restante dos Trusted Nodes e o hash não,
significa que o remetente substituiu a assinatura. Nesse caso, o "remetente" é
marcado como "incorreto".
4) Os mesmos hashes devem ser encontrados na maioria dos Nodes Confiáveis (>51%
do número total de Nodes Confiáveis), caso contrário, a rodada é concluída antes do
tempo.

Após o recebimento do pacote do estágio 2, a assinatura é validada. Então, usando o


algoritmo BFT, o Node Confiável “incorreto” (“mentiroso”) é determinado.
O tempo de troca dos Estágios 1 e 2 é fixo e, assim, os nodes que não conseguirem
trocar os pacotes a tempo são automaticamente marcados como "incorretos" e perdem o
direito de gerar blocos.

Procedimento de consenso
Após o recebimento dos vetores de assinaturas de todos os colegas dos TNs, um TN
avalia as informações recebidas através do seguinte algoritmo:
● ● Etapa 1. O hash do indicador é verificado. Todos os hashes dos indicadores
recebidos do TN são verificados. O hash mais frequente (>51%) é considerado a
solução consensual. Todos os nodes que enviaram um hash diferente são marcados
como nodes confiáveis "incorretos". Caso não haja hash com a frequência >51%, o
consenso é cancelado e a rodada é finalizada.
● ● Etapa 2. É formada uma lista de hashes de pacotes de transações a serem
processados na próxima rodada. Apenas os hashes dos pacotes de transações
armazenados no TN da rodada atual, mas não incluídos no processamento atual, são
considerados. Verifica a exclusividade (o hash do pacote de transações da próxima
rodada dentro de um TN deve aparecer não mais de uma vez), o que permite excluir
a duplicação dos mesmos pacotes de transações. Se o TN não passou no cheque,
ele está marcado como "incorreto".

Formação da lista de Trusted Nodes da próxima rodada


Em seguida, os TNs estão trocando as listas de candidatos para se tornarem TN da
próxima rodada e a freqüência de ocorrência de um candidato na lista criada é analisada.
Caso o candidato tenha uma frequência de 50% (ou seja, incluído na lista de candidatos >50%
de todas as TNs da rodada atual), ele se tornará automaticamente um TN da próxima rodada
e será incluído no vetor “next_round_trusted”.
Todos os outros nodes que têm uma frequência menor que 50% são selecionados por
um algoritmo pseudo-aleatório, pelo qual todos os TNs operando sob o mesmo protocolo da
próxima rodada de Nodes Confiáveis “next_round_trusted” são formados.

10
Formação da lista de pacotes de transações da próxima rodada

Depois que nodes "incorretos" são detectados, uma tabela de resumo dos hashes dos
pacotes de transações da próxima rodada especifica a frequência de cada hash do pacote de
transações na lista geral. Os hashes dos pacotes que estão presentes em mais de 50% de
todos os TNs estão incluídos na lista para serem processados na próxima rodada e são
gravados no vetor "Next_round_hashes". O uso do algoritmo único para formar a lista dos
hashes dos pacotes de transação da próxima rodada em todos os TNs operando sob o
mesmo protocolo deve resultar no mesmo conjunto de hashes. Todo os outros TNs estão
"incorretos".
O resultado desta execução do estágio é uma lista formada de transações a serem
processadas na próxima rodada que é salva em cada TN no vetor “next_round_hashes”.

Estágio III

Gravando transações em um bloco


Vamos designar uma lista geral de transações da rodada como a, e o indicador
(função característica) de um node de escrita como: Uma correspondência unívoca
do indicador e seu hash pode ser apresentada como . Assim, se,
nós nós entendemos que Especificando a lista de
transações como nós temos a seguinte fórmula para determinar a lista de
transações válidas por um indicador:

De acordo com esta fórmula da lista de transações, os nodes “corretos” (da lista
“real_trusted”) formam a lista de transações válidas que estão incluídas no bloco.

Cada Node Confiável que formou um bloco inclui as seguintes informações no meta
block:
1. Indicador (Função característica)
2. Vetor «realTrusted»
3. Vetor «next_round_trusted»
4. Vetor «next_round_hashes»
5. Assinatura separada do node de gravação do bloco (sem o próprio bloco)

Cada node confiável deve gerar um bloco, gerar corretamente um meta block, assiná-
lo e enviá-lo para outros TNs na forma de confirmação de recebimento assinado da conclusão
correta de consenso. Cada TN que recebeu mais de 50% de confirmação de recebimento dos
TNs “corretos” da rodada (do vetor “real_trusted”) pode se tornar um Node de Gravação(WN),
caso WN seja selecionado pelo consenso geral de TNs “corretos” não possa gerar o meta
block por qualquer motivo. Um mecanismo TimeOut é usado para essa finalidade, bem como
um conjunto de pedidos no vetor “real_trusted”. Em outras palavras, inicialmente o WN é um
node “real_trusted [0], se ele não gerar um meta block assinado dentro de um determinado
período de tempo, o node “ real_trusted [1]” se tornará WN e assim por diante.

11
Formação do meta block
Cada node do vetor "real_trusted" gera um bloco com base na função característica
aprovada pelo consenso.
As transações que não estão marcadas no indicador com um sinal diferente de zero,
informações sobre o número do bloco, carimbo de hora do node de gravação, hash do bloco
anterior e vetor "real_trusted" são gravadas no bloco. O bloco é adicionado ao
armazenamento preliminar e seu hash é calculado.

Seleção dos Nodes de Gravação


A lista de nodes “corretos” e “incorretos” é armazenada no vetor “real_trusted”. Este
vetor é formado no Estágio 1 e é preenchido com os valores “0” (node correto) e “1” (node
incorreto). O índice, ou número ordinal, corresponde ao índice (número ordinal) de um node
confiável na lista de TNs da rodada atual.
No momento da seleção de WN, todos os TN que operam sob o protocolo contêm os
mesmos vetores “real_trusted”. O protocolo define uma função pseudo-aleatória que permite
que todos os TNs cheguem a um consenso geral e selecionem de todos os nodes “corretos”
(com “0” no vetor “real_trusted”) o node que se tornará WN.
O número do WN é determinado da seguinte forma: os últimos 4 bytes do hash do
último bloco são interpretados como inteiros sem sinal e o módulo dividido são o número de
nodes “corretos” (número de “0” no vetor “real_trusted”). O resultado da divisão é o número
ordinal do node “correto” que, por consenso geral, é aceito como WN.
Em seguida, todos os nodes "incorretos" são removidos do vetor e uma lista de nodes
"corretos" da rodada atual é formada, com base na qual uma taxa será calculada. Ao mesmo
tempo, o WN é o primeiro [índice 0] na lista e o seguinte, o node “correto” é o segundo [índice
1] e assim por diante.
O resultado desta etapa é um vetor “real_trusted” que é incluído no pacote de dados
da 3ª etapa do consenso e também a adoção do tempo em um “timestamp” do WN por todos
os nodes.

Adicionando um novo bloco na blockchain pelos nodes


Uma vez que os nodes recebam o meta block gerado pelo WN, eles formam a lista de
transações válidas, geram o bloco, calculam o hash e verificam as assinaturas. Caso todas
as verificações sejam passadas, o bloco gerado pelo node é adicionado à blockchain e o
node, desde que ele tenha uma blockchain atualizada, envia o hash do bloco para todos os
TNs da lista “next_round_trusted”.

12