BigchainDB

BigchainDB
Versão estável	0.5.0 (4 de julho de 2016)
Sistema operacional	Multiplataforma
Gênero(s)	NoSQL
Licença	Licença Apache 2.0
Página oficial	[15]

• Commons
• Wikilivros

BigchainDB é um banco de dados descentralizado open-source com a proposta de adicionar características da estrutura de dados blockchain às arquiteturas de bancos de dados distribuídos NoSQL já existentes. Características como a escalabilidade, velocidade de escrita e leitura e capacidade de extração de dados através de linguagens de query como o SQL são elementos que contrastam com a natureza de blockchains tradicionais.

Características

O BigchainDB herda 3 características principais do blockchain :

• Controle descentralizado: nenhum indivíduo possui ou controla a rede.
• Imutabilidade: onde dados persistidos não podem ser modificados.
• Criar e transferir bens digitais: manipulação independente de entidade

O controle descentralizado é baseado no sistema de votação tradicional por federação de nós, onde outros nós podem se conectar para receber e sugerir novas transações, de modo a funcionar como uma rede peer-to-peer (P2P). A votação ocorre em uma camada acima da camada de consenso própria do banco de dados. Por motivos de performance os nós são persistidos mesmo antes que haja a validação e a ligação do novo bloco ao blockchain acontece uma vez feita a validação da votação. Todo bloco tem um identificador igual a hash da sua transação, timestamp, lista de eleitores e chave pública do seu nó criador. Um bloco não inclui a hash (id) do bloco anterior, quando escrito inicialmente, mas votos contendo um atributo representando o “nó anterior“ são inseridos gradativamente ao bloco afim de dar suporte ao quórum de validação de votos. A imutabilidade é garantida através de mecanismos como replicação de shards, reversão de atualizações desabilitadas ou deleções, backups regulares do banco de dados e assinaturas criptografadas em todas as transações, blocos e votos.

Arquitetura

O BigchainDB expõe seus serviços para clientes via API como uma instância monolítica de blockchain. A arquitetura é construída através de dois bancos de dados distribuídos: S (conjunto de transação ou “backlog”) e C (block chain). Estes são conectados via o Algoritmo de Consenso BigchainDB (BCA, do inglês BigchainDB Consensus Algorithm) que opera em cada nó de assinatura. Cada banco de dados opera com seu algoritmo de consenso Paxos para manter a consistência entre os discos. O primeiro banco de dados armazena o “backlog” de transações - um conjunto de transações S. A validação de uma transação recém inserida é dada pelo nó que a recebe e, caso válida (de acordo com aquele nó), é armazenada em S. Transações subsequentes idênticas serão rejeitadas. O nó que recebe uma transação também é responsável por delegar esta transação para outro nó escolhido randomicamente. Um nó devidamente credenciado pode votar se considera um bloco válido ou inválido. Para decidir, o nó checa a validade de todas as transações no bloco e caso encontre uma transação inválida vota no bloco como inválido. Caso não haja nenhuma transação inválida, o bloco é votado como válido. Cada bloco começa como “indecidido”, como nenhum voto associado. Assim que há uma maioria de votos, para positivo ou para negativo, o bloco é registrado como “decidido e válido” ou “decidido e inválido”, respectivamente.

Detalhes de Implementação

O BigchainDB utiliza bancos de dados já existentes, sem alterar sua estrutura, para alcançar seus objetivos. Foram alvo de consideração bancos NoSQL Cassandra, HBase, Redis, Riak, MongoDB, RethinkDB e Elasticsearch. Dentre estes o BigchainDB utiliza o RethinkDB . Dois atributos prioritários na escolha:

• Consistência: . Bancos de dados distribuídos devem ter um equilíbrio entre performance e consistência, como exposto no teorema CAP (que leva em conta consistência, disponibilidade e tolerância à falhas em partições neste tipo de bancos de dados). Para um blockchain, consistência se traduz em ordenação válida nas transações, o que faz este ponto de suma importância.
• Notificações automáticas de mudanças: Esta propriedade garante eficiência no que diz respeito a notificações de alteração no banco, evitando que nós sejam obrigados a técnicas menos efetivas, como polling , para checar novas mudanças. Este ponto também auxilia na imutabilidade, uma vez que caso haja tentativa de fraude em um registro, as hashs (identificadores) mudarão, dada a natureza do blockchain. O banco então imediatamente notificará todos os nós que podem reverter tal mudança e recuperar a integridade da hash.

O RethinkDB é um banco de dados NoSQL orientado a documentos otimizado para feeds em tempo real que armazena registros no formato JSON. O BigchainDB herda características como a escalabilidade linear de armazenamento, onde a capacidade de cada nó em um cluster é adicionada a capacidade do cluster como um todo, dentre outras características dos bancos NoSQL.

Modelo de Dados

Três modelos estão presentes no BigchainDB, Transação, Bloco e Voto, com dois tipos básicos de transação armazenados: transações de criação e transações de transferência. Estes são os registros mais básicos do BigchainDB. Uma transação de criação inicializa os registros de um ativo digital, incluindo descritores como o que este pode significar, a lista de donos inicialmente e condições a serem satisfeitas por eventuais futuros atores em uma transação.

Representação do modelo de Transação

{
    " id " : " < hash of transaction , excluding signatures > " ,
    " version " : " < version number of the transaction model > " ,
    " transaction " : {
        " fulfillments " : [ " < list of fulfillments > " ] ,
        " conditions " : [ " < list of conditions > " ] ,
        " operation " : " < string > " ,
        " timestamp " : " < timestamp from client > " ,
        " data " : {
            " hash " : " < hash of payload > " ,
            " payload " : " < any JSON document > "
        }
    }
}

Representação do modelo de Bloco

{
    " id " : " < hash of block > " ,
    " block " : {
        " timestamp " : " < block - creation timestamp > " ,
        " transactions " : [ " < list of transactions > " ] ,
        " node_pubkey " : " < public key of the node creating the block > " ,
        " voters " : [ " < list of federation nodes public keys > " ]
    },
    " signature " : " < signature of block > " ,
    " votes " : [ " < list of votes > " ]
}

Representação do modelo de Voto

{
    " node_pubkey " : " < the public key of the voting node > " ,
    " vote " : {
        " voting_for_block " : " < id of the block the node is voting for > " ,
        " previous_block " : " < id of the block previous to this one > " ,
        " is_block_valid " : " < true | false > " ,
        " invalid_reason " : " < None | DOUBLE_SPEND | TRANSACTIONS_HASH_MISMATCH |
        NODES_PUBKEYS_MISMATCH"> ,
        " timestamp " : " < timestamp of the voting action > "
    },
    " signature " : " < signature of vote > "
}

Algoritmo de Consenso do BigchainDB (BCA)

O Algoritmo de Consenso do BigchainDB é uma máquina de estados que, dada a criação e inicialização dos bancos S e C, consiste em um laço principal que roda para todo nó servidor. O pseudo-código Python abaixo ilustra a implementação do BCA.

def mainLoop() : # Pseudocode para nó k
# Assumindo S e C existentes e inicializados,
# onde C contém um bloco de criação.
    global S, C
    while True :
        S = assignTransactions(S, k)
        Sk, C = addBlock(Sk, C, k)
        C = voteOnBlocks(C, k)

BigchainDB Publico e Privado

O Bigchain comporta uma camada acima da sua infraestrutura fundamental, baseada em permissões, identidades e papeis (roles). Permissões são regras que especificam o que um usuário pode fazer com os dados. Sistemas de permissões existentes serviram de inspiração para o design das permissões do BigchainDB, como o do Linux, onde há três papeis (usuário ao qual pertence, grupo ao qual pertence e outros) e três tipos de permissões (leitura, escrita e execução), em um total de nove valores de permissão para um diretório ou arquivo. As tabelas 1 e 2 ilustram as permissões em instâncias privadas e públicas do BigchainDB, respectivamente.

Action	Requires Vote	Voting Node	Sys Admin	Issuer	Trader	Broker	Authenticator	Auditor	Core vs Overlay
Vote on Admin & Asset Actions		Y							Core
Update Role or Permissions	Y	Y	Y						Core
Add/Remove Voting Node	Y	Y	Y						Core
Update software	Y	Y	Y						Core
Issue Asset	Y			Y					Core
Transfer Asset	Y			O	O	P			Core
Receive Asset	Y			Y	Y				Core
Grant Read Access on Asset	Y			O	O	P	P		Core
Consign Asset	Y			O	O				Overlay
Receive Asset Consignment	Y			Y	Y	Y			Overlay
Add Asset Information	Y			O	O	P			Overlay
Add Authentication Information	Y			O	O		P		Overlay
Create Certificate of Authenticity	N			O	O	P			Overlay
Read Asset Information	N	Y	Y	O	Y	P	P	P	Overlay
Read Certificate of Authenticity	N	Y	Y	O	Y	P	P	P	Overlay

Tabela 1 - Exemplos de permissões / papeis em um BigchainDB privado.

Action	Requires Vote	Voting Node	Sys Admin	Issuer	User	Authenticator
Vote on Admin & Asset Actions		Y				Core
Update Role or Permissions	Y	Y	Y			Core
Add/Remove Voting Node	Y	Y	Y			Core
Update software	Y	Y	Y			Core
Issue Asset	Y			Y		Core
Transfer Asset	Y			O		Core
Receive Asset	Y			Y		Core
Grant Read Access on Asset	Y			N/A	N/A	Core
Consign Asset	Y			O		Overlay
Receive Asset Consignment	Y			Y		Overlay
Add Asset Information	Y			O		Overlay
Add Authentication Information	Y			O	P	Overlay
Create Certificate of Authenticity	N			O		Overlay
Read Asset Information	N	Y	Y	O	P	Overlay
Read Certificate of Authenticity	N	Y	Y	O	P	Overlay

Tabela 2 - Exemplos de permissões / papeis em um BigchainDB público.

Uma identidade, significando o detentor de uma chave privada única, pode ser garantido com a permissão para cada tipo de transação. Permissões, como as presentes nas tabelas podem ser: Y que significa que esta identidade pode executar uma transação; O, que significa que a identidade pode executar uma ação se for o dono do ativo em questão (indicado pela detenção da chave privada deste ativo); P que significa que a identidade pode executar uma transação, contanto que o dono do ativo garanta permissão. A maioria das transações devem ser aprovadas ou negadas via voto por nós eleitores, com exceção das operações de leitura.

Um BigchainDB privado pode ser instanciado dentre um grupo de partes interessadas afim de facilitar ou verificar transações em uma variedade de contextos, como trocas de segurança, melhoramento da transparência em cadeias de fornecimento ou o gerenciamento do pagamento de royalties. Um consórcio de partes interessadas operando um BigchainDB compreende uma Enterprise Trust Network (ETN).

Casos de Uso

Alguns casos de uso típicos do BigchainDB são:

• Criação e movimentação de ativos digitais e transferências controlados pelo dono do ativo.
• Acompanhamento de logística em cadeias de produção afim de detectar e prevenir fraude.
• Geração de certificados de autenticação (COAs) de ativos.