A Eq. 6.1 apresenta o cálculo da probabilidade de ocorrência de um evento S1, onde
S1 é o sorteio bem sucedido de um nó, isto é, S1 é o evento de um nó conseguir atingir o objetivo por meio do hash de prova. Neste caso está sendo adotada uma penalização P nula, já que se está considerando a criação no ramo principal da blockchain.
p[S1] = 2
256≠D≠P
2256 (6.1)
Usando o resultado da Eq. 6.1 podemos encontrar número esperado de rodadas até ocorrer sucesso no sorteio em um nó (Eq. 6.2).
N rS1 = G 1 p[S1] H (6.2) Para obter o valor esperado para múltiplos nós, temos que obter probabilidade de sucesso Sn, onde Sn é o sorteio bem sucedido em pelo menos um dos n nós (Eq. 6.3).
p[Sn] = 1 ≠ n
Ÿ
i=1(1 ≠ p[S1]) = 1 ≠ (1 ≠ p[S1])
n (6.3)
De forma idêntica pode-se encontrar o número esperado de rodadas para se ter algum sorteio (hash) bem sucedido quando se tem mais de um nó (Eq. 6.4).
N rSn = G 1 p[Sn] H (6.4) Deve ser notado que, devido ao fato de estarmos trabalhando com tempos discretos, onde a menor unidade é o tempo de uma rodada, os valores produzidos pelas Eqs. 6.3 e 6.4 fornecem o número inteiro de rodadas imediatamente superior ao valor teórico (e muitas vezes fracionário) calculado a partir das probabilidades.
Na prática é bem provável que se encontre valores de rodadas menores que o limite superior aqui calculado. Entretanto, espera-se que estas diferenças entre valores estimados e medidos sejam cada vez menores à medida que se aumenta o número de rodadas necessárias para se conseguir um sucesso em sorteios. Para sorteios bem sucedidos em poucas rodadas, é
natural que o erro relativo entre os valores estimados e medidos seja maior. Mas isso não deve trazer nenhum tipo de dificuldade, pois sendo um erro de no máximo uma rodada, pouco efeito prático ele terá.
Com base nestas expressões foram calculados vários parâmetros para avaliar, de forma teórica, o comportamento de uma blockchain controlada pelo novo consenso PoS simplificado aqui proposto. As figuras a seguir apresentam os principais resultados teóricos com suas respectivas análises.
Na seção seguinte são apresentados resultados práticos e são feitas as devidas compa- rações com os resultados teóricos.
Figura 22 – Probabilidade de sucesso no sorteio em função do número de nós
Como pode ser visto nas Figs. 22, 23 e 24, a probabilidade de sucesso em uma de- terminada rodada aumenta com o número de nós participantes na blockchain, mas diminui muito rapidamente quando cresce o nível de dificuldade.
Na prática, os níveis de dificuldade devem ser ajustados de maneira a não permitir que seja muito provável qualquer nó ter sucesso no sorteio (aumentaria o número de forks), mas também não pode tornar esta probabilidade muito pequena, pois isso resultaria em atrasos muito grandes no processo de mineração, como mostram as Figs. de 25 a 30.
É possível notar (Fig. 23) que, mesmo para uma rede similar em tamanho à rede do Bitcoin (cerca de 10.000 nós), os níveis de dificuldade 16 e 32 parecem ser muito fortes, pois não permitem que a probabilidade de sucesso no sorteio de algum nó atinja 15%. Pode parecer pouco, mas 15% de 10.000 são 1.500 nós tendo sucesso no sorteio, o que pode resultar
Figura 23 – Probabilidade de sucesso no sorteio em função do número de nós para 8, 16 e 32 nós
Figura 24 – Probabilidade de sucesso no sorteio em função da dificuldade
em 1.500 forks a serem resolvidos. É por este motivo que se faz necessário um controle bem rigoroso do nível de dificuldade a fim de evitar que o número de forks aumente.
Assim como ocorre em algumas blockchains (como a do Bitcoin , por exemplo), neste protocolo também deve ser adotado um esquema automático de ajuste de nível de dificuldade, de maneira a preservar o tempo médio de criação de blocos dentro de um intervalo pré- definido.
Figura 25 – Número esperado de rodadas até um sucesso em sorteio em função do número de nós para dificuldades de 1 a 4 bits
Figura 26 – Número esperado de rodadas até um sucesso em sorteio em função do número de nós para uma dificuldade de 8 bits
Como o tempo necessário para a rede de nós participantes criar pelo menos um bloco é diretamente proporcional ao timeout e ao número esperado de rodadas, os gráficos de tempo necessário para criação de um bloco são praticamente idênticos aos de número de rodadas, mudando apenas por um fator de escala igual a timeout.
Figura 27 – Número esperado de rodadas até um sucesso em sorteio em função do número de nós para uma dificuldade de 16 bits
Figura 28 – Número esperado de rodadas até um sucesso em sorteio em função do número de nós para uma dificuldade de 8 e 16 bits
Figura 29 – Número esperado de rodadas até um sucesso em sorteio em função do número de nós para uma dificuldade de 32 bits
Figura 30 – Número esperado de rodadas até um sucesso em sorteio em função do nível de dificuldade
consenso proposto, passaremos à análise dos aspectos práticos, com base na implementação e execução de um protótipo.
6.2 Resultados práticos
Uma prova de conceito foi desenvolvida em Python e a primeira versão do meca- nismo proposto foi disponibilizada em (https://github.com/regras/bc_pos). A escolha do Python se deu por sua sintaxe simples e a ampla disponibilidade de bibliotecas para funções hash, criptografia, entre outras. Com base nesta implementação, foram feitos vários testes e colhidos parâmetros de desempenho que estão sendo úteis para melhor avaliar e aprimorar o mecanismo de consenso proposto.
A seguir são apresentados os resultados práticos obtidos até o momento. Os testes foram executados em um servidor de 16 GB de memória RAM e processador Intel Xeon de 2,4 GHz com um core. Os nós mineradores foram criados no simulador de redes Mininet em sua versão 2.3.0. Na simulação, todos os nós foram criados no mesmo servidor, não sendo utilizado link externo para comunicação com nós remotos.
Devido ao tempo necessário para cada teste e à dificuldade de gerenciar um número grande de nós que formam a blockchain, optamos por limitar o tamanho da rede em 10 nós e o timeout em 8 segundos nesta avaliação inicial. Avaliações com outras configurações também estão sendo efetuadas e os resultados continuam mostrando-se coerentes com o esperado.
Para um primeiro teste foram medidos os tempos de criação de 100 blocos em cinco execuções por meio de um script. A partir dos valores obtidos foi calculado o tempo médio de cada execução. A Tab. 5 detalha este tempo médio para criação de 100 blocos para timeout variando de 1 a 8 segundos e redes com 1 a 10 nós.
Nestes testes, foi adotado um nível de dificuldade de dois bits (D = 2) e penalidade nula (P = 0). O gráfico da Fig. 31 permite avaliar melhor estes tempos e notar que há um crescimento praticamente linear com o aumento do timeout, como já era esperado.
Tabela 5 – Tempo médio (s) para criação de 100 blocos após 5 execuções do protocolo para dificuldade D = 2 e penalidade P = 0. Timeout (s) 1 2 4 Número de nós6 8 10 100 200 0,5 149,98 111,23 78,17 57,71 41,83 31,24 65,94 55,04 1 413,34 218,73 120,49 78,74 63,79 54,34 115,72 84,98 2 817,71 384,14 211,99 126,48 104,07 76,04 330,93 158,36 4 1579,97 771,71 441,96 254,98 182,10 121,82 543,17 379,37 6 2417,94 1193,73 548,07 368,17 274,78 223,82 967,92 623,44 8 3265,38 1614,75 698,32 530,30 391,19 302,12 1309,08 835,62
Figura 31 – Tempo médio de criação de 100 blocos em função do timeout para D = 2 e
P = 0.
Já a Fig. 32 mostra os mesmos dados de outro ângulo, deixando claro como vai ficando mais fácil (mais rápido) criar 100 blocos à medida que se aumenta o número de nós. A diminuição do tempo de criação não é totalmente vantajosa, já que é preciso estar atento para o aumento da probabilidade de forks com o aumento do número de nós.
Porém, como é possível observar nas Figs. 31 e 33 para uma quantidade alta de nós, o tempo de criação é comparável ao de casos com uma quantidade pequena de nós. Isto é devido a que, quando muitos nós estão envolvidos na criação de blocos, o sistema utiliza um tempo adicional com sincronizações.
Na Fig. 33 fazemos uma comparação entre os tempos estimados e a média dos medidos para a criação de 100 blocos. É possível perceber uma diferença maior entre os valores à
Figura 32 – Tempo médio de criação de 100 blocos em função do número de nós para difi- culdade 2 e P=0
Figura 33 – Comparação entre os tempos estimados e medidos para criação de 100 blocos com dificuldade 2 e timeout = 1
medida que aumenta o número de nós e esta diferença se deve principalmente ao fato de que o valor estimado pela Eq. 6.4 para o número de rodadas está arrendondado para o primeiro inteiro acima.
Por um lado, isto nos traz um erro maior quanto menos rodadas forem necessárias para se ter sucesso em um sorteio. Por outro lado, quanto mais nós estiverem participando
dos sorteios, maior é a chance de que algum deles consiga obter sucesso antes do tempo estimado, já que se trata de uma estimativa baseada em probabilidades.
Apesar de que para uma quantidade de 100 e 200 nós o tempo é mais alto do que era esperado, este ainda recai dentro da faixa de valores teóricos.
Portanto, o aumento do número de nós tem um duplo efeito na diferença entre os valores teórico e prático:
• mais nós æ mais chance de algum deles conseguir sucesso no sorteio mais rapidamente que o valor esperado teórico;
• mais nós æ menos rodadas são necessárias para se obter sucesso, o que proporcio- nalmente destaca mais as diferenças causadas pelo arredondamento para a próxima rodada.
A Tab. 6 detalha o tempo médio em segundos de cinco execuções do mecanismo de consenso para criação de 100 blocos para timeout variando de 1 a 8 segundos e redes com 1 a 10 nós. Nestes testes, foi adotado um nível de dificuldade D = 4 bits e penalidade nula (P = 0).
Tabela 6 – Tempo médio (s) para criação de 100 blocos após 5 execuções do protocolo para
D= 4 e P = 0 Timeout (s) 1 2 4 Número de nós6 8 10 100 200 0,5 801,78 298,46 189,46 113,12 110,71 137,53 98,62 48,63 1 1582,94 827,96 454,30 259,23 191,93 169,15 188,26 168,88 2 3193,26 1653,83 782,75 549,99 426,12 341,60 329,80 199,70 4 6510,48 3217,43 1561,14 1127,00 775,53 491,90 814,98 354,15 6 9719,18 4760,56 2769,50 1503,04 1238,66 916,83 1281,20 591,01 8 12815,12 6510,16 3148,68 2339,98 1747,60 1588,29 1540,52 745,15 Os dados desta tabela também podem ser melhor entendidos e avaliados por meio dos gráficos nas Figs. 34 e 35, as quais mostram a variação do tempo médio para criação de 100 blocos em função do timeout e do número de nós, respectivamente. Como a dificuldade foi dobrada, tornou-se mais difícil a ocorrência de um evento de sucesso no sorteio para mineração de um bloco.
Portanto, mais rodadas e mais tempo se fizeram necessários até que tal evento ocor- resse, o que modificou apenas a escala, mas não o formato dos gráficos em relação aos ante- riores (dificuldade 2).
Figura 34 – Tempo médio de criação de 100 blocos em função do timeout para D = 4 e
P = 0
Figura 35 – Tempo médio de criação de 100 blocos em função do número de nós para D = 4 e P = 0
É interessante notar as mudanças que este aumento de dificuldade trouxe ao com- parativo entre tempos estimados e medidos para a criação de 100 blocos. Devido à maior dificuldade no presente caso, o número de rodadas foi aumentado significativamente, o que resultou em um erro proporcional menor entre os valores, como pode ser visto na Fig. 36.
valores teóricos e práticos à medida que o tempo (e o número de rodadas necessárias) diminui, como já discutido anteriormente.
Figura 36 – Comparação entre os tempos estimados e medidos para criação de 100 blocos com dificuldade 4 e timeout = 1
As Figs. 37 e 38 permitem uma comparação melhor dos efeitos práticos da mudança de dificuldade de 2 para 4, ao reunir todos os dados medidos em um só local. Foram realizados outros testes práticos, entre eles, um de sincronização de 100 blocos a partir de um nó com todos os outros nós da rede. Os resultados são mostrados na Tab. 7 e na Fig. 39.
Tabela 7 – Tempo médio de sincronização de 100 blocos entre todos os nós da blockchain Núm. de nós Tempo de sincronização (s)
2 22,16
4 57,18
6 66,37
8 91,48
Nota-se que à medida que a quantidade de nós participantes da rede aumenta, o tempo para que todos estejam sincronizados (com a mesma visão da blockchain) também aumenta. Este é um resultado esperado. Porém, na prática é pouco provável que se tenha a entrada simultânea de muitos nós na rede e, portanto, o processo de sincronização dos blocos que formam a blockchain deverá ocorrer de forma distribuída no tempo, já que são distribuídos os eventos de chegadas de novos nós participantes.
Figura 37 – Tempo médio de criação de 100 blocos em função da dificuldade com timeout = 1
Figura 38 – Tempo médio de criação de 100 blocos em função do número de nós com
timeout= 1
6.3 Conclusões
A análise teórica e os resultados práticos se mostraram bem consistentes com o que era previsto durante o projeto deste novo mecanismo de consenso. Foi possível mostrar a influência do controle de dificuldade no desempenho do sistema, bem como o impacto que o número de nós traz á velocidade de criação de novos blocos. Deve ser destacado também o
Figura 39 – Tempo médio sincronização de 100 blocos em função do número de nós fato de haver uma razoável concordância entre os valores teóricos (estimados) e práticos de tempo de criação de um conjunto de blocos.
7 Conclusões
Os mecanismos de consenso são uma parte importante para o funcionamento de uma
blockchain já que é o processo que permite o acordo entre usuários (possivelmente adversá-
rios) para determinar o criador do bloco e prover as demais características que garantem a continuidade e a confiabilidade da blockchain. Cada um dos mecanismos avaliados propõe alguma forma de lidar com o problema do consenso.
Como são muitos mecanismos e muitas características distintas, iniciamos uma com- paração detalhada entre eles, registrando cada características em uma tabela de consolidação. Assim foi possível destacar melhor os pontos fortes e fracos de cada mecanismo, o que nos trouxe algumas premissas que deveriam ser atendidas em um novo mecanismo de consenso, como o que foi proposto neste trabalho.
Apresenta-se assim um novo mecanismo de consenso baseado em PoS, onde a escolha dos nós é realizada de forma equiprovável durante intervalos de tempo chamados de rodada. Isso permite uma criação controlada de blocos, sem privilegiar os nós que porventura tenham um grande poder de processamento.
Cada nó tenta atingir o objetivo utilizando um hash de prova, criado a partir de três informações de entrada que não podem ser alteradas com facilidade, o que dificulta fraudes para passar o desafio.
O protocolo propõe um mecanismo de punição para controlar os forks, o qual incentiva a criação de blocos na cadeia principal (com uma maior probabilidade), mas não proíbe a criação em uma outra cadeia que o nó vê como secundária, num determinado momento. Como as visões da blockchain e seus forks podem ser diferentes em diferentes momentos e em diferentes pontos da rede, é possível que um ramo visto como um fork por um determinado nó seja na verdade o ramo principal da blockchain. Assim, ao permitir que os nós possam criar blocos para um ramo secundário (ainda que com uma menor probabilidade de sucesso no sorteio), o mecanismo proposto poderá ajudar na melhoria de desempenho de todo o sistema, caso o ramo secundário seja na verdade o principal quando visto por toda a rede.
Foi feito um estudo detalhado do futuro mecanismo PoS do Ethereum (Casper) e uma comparação dele com o mecanismo proposto. Apesar dos resultados ainda serem preliminares, podemos perceber que o mecanismo proposto é mais simples e poderá trazer vantagens de desempenho e de segurança no futuro.
github) e vários testes de desempenho foram feitos com a mesma. Observamos uma boa con-
cordância entre os valores teóricos e práticos de alguns dos parâmetros utilizados para avaliar a implementação e acreditamos estar no caminho certo para alcançar um novo mecanismo de consenso que permita a criação de uma blockchain que tenha requisitos mais simples para a inclusão de novos nós na mesma. Isso viabilizará a participação de um número muito maior de interessados no processo de mineração e criação de novos blocos, aumentando a segurança e a tolerância a falhas e a ataques de todo o sistema.
Acreditamos que o principal potencial deste novo mecanismo está na capacidade do mesmo de minimizar a concentração de poder de mineração que se percebe claramente hoje em grandes blockchains baseadas em mecanismos PoW (Proof-of-Work).
Trabalhos Futuros
Um importante ponto é o desenvolvimento de um esquema automático de ajuste de nível de dificuldade para poder preservar o tempo de criação de blocos dentro de um intervalo previsível. Em um ambiente aberto como as blockchains públicas, nota-se a necessidade de um controle automatizado da dificuldade, pois a quantidade de participantes pode variar com o tempo, mudando assim o tempo de criação.
O sistema de controle de forks, poderá implementar um sistema de punição adaptativo, onde esta punição dependeria basicamente do tamanho da diferença entre a cadeia principal e a cadeia secundária em questão. Em uma rede globalmente distribuída os atrasos são de difícil previsão e, com isso, punir sempre da mesma forma uma determinada cadeia secundária pode trazer consequências desfavoráveis para uma evolução mais eficiente da blockchain.
A construção de um sistema para formação de comitês para controlar a inserção de blocos na blockchain poderia trazer benefícios para a rede, como já proposto em vários outros trabalhos relacionados. Entretanto, seguindo os princípios adotados no mecanismo de consenso aqui proposto, a escolha dos membros do grupo deveria ser equiprovável e deveria haver uma certa rotatividade entre tais participantes, o que poderia facilitar o aumento da taxa de criação de blocos sem aumento dos forks, já que um nó só teria que verificar as assinaturas dos membros do comitê para verificar a validade de um bloco.
Acreditamos que também poderiam ser avaliadas possibilidades de utilização de al- guma variante de PoS dinâmico, mas de tal forma que o uso do valor de stake não afetasse de forma significativa as chances de escolha de um nó participante. Isto poderia trazer al- guns benefícios ao sistema, por não privilegiar demais aqueles nós que não estão efetivamente comprometidos com o sucesso do mesmo, mas sem contudo prejudicar a premissa básica de
facilitar a participação de todos os que estejam interessados em contribuir com a construção e manutenção da blockchain baseada no PoS simplificado com rodadas aqui proposto. Outro benefício seria a minimização de ocorrências de blocos incorretos, já que um nó que atuasse de forma errada seria penalizado com a perdas de suas moedas.
Referências
AGNER, M. Bitcoin para Programadores. 1. ed. [S.l.]: Instituto de Tecnologia & Sociedade de Rio, 2016. Citado na página 65.
AKKOYUNLU, E. A.; EKANADHAM, K.; HUBER, R. V. Some constraints and tradeoffs in the design of network communications. SOSP ’75 Proceedings of the fifth ACM symposium
on Operating systems principles, p. 67–74, November 1975. Citado na página 92.
ANTONOPOULOS, A. M. Mastering Bitcoin: Programming the Open Blockchain. 2. ed. [S.l.]: O’Reilly Media, Inc., 2017. Citado na página 65.
ARKCREW. ARK Whitepaper - A Platform for Consumer Adoption. 2018. [Online]. <https://ark.io/Whitepaper.pdf>. Whitepaper. Citado na página 33.
BACK, A. HashCash. 1997. <http://www.cypherspace.org/hashcash/>. (acessado em 14/03/2018). Citado na página 25.
BANO, S.; SONNINO, A.; AL-BASSAM, M.; AZOUVI, S.; MCCORRY, P.; MEIKLEJOHN, S.; DANEZIS, G. Sok: Consensus in the age of blockchains. ArXiv e-prints, 2017. Citado 3 vezes nas páginas 16, 28 e 31.
BASHIR, I. Mastering Blockchain. 1. ed. [S.l.]: Packt Publishing Ltd., 2017. Citado 2 vezes nas páginas 16 e 23.
BENTOV, I.; LEE, C.; MIZRAHI, A.; ROSENFELD, M. Proof of activity: Extending bitcoin’s proof of work via proof of stake. SIGMETRICS Perform. Eval. Rev., v. 42, n. 3, p. 34–37, December 2014. Citado na página 35.
BITSHARE. Delegated Proof-of-Stake Consensus A robust and flexible consensus protocol. 2016. <https://bitshares.org/technology/delegated-proof-of-stake-consensus/>. (acessado em 10/09/2017). Citado na página 32.
BITSHARETEAM. Delegated Proof Of Stake. 2016. <http://docs.bitshares.org/bitshares/ dpos.html>. (acessado em 26/03/2018). Citado na página 33.
BLOCKGEEKS. What is Ethereum Casper Protocol? Crash Course. 2018. <https: //blockgeeks.com/guides/ethereum-casper/>. (acessado em 08/01/2019). Citado 2 vezes nas páginas 10 e 27.
BLOCK.ONE. EOS.IO Technical White Paper v2. 2018. [Online]. <https://github.com/ EOSIO/Documentation/blob/master/TechnicalWhitePaper.md>. Whitepaper. Citado na página 33.
BROWN, D. R. L. SEC 2: Recommended Elliptic Curve Domain Parameters. 2010. [Online]. <http://www.secg.org/sec2-v2.pdf>. Citado na página 65.
BRYSON, D.; PENNY, D.; GOLDENBERG, D. C.; SERRAO, G. Blockchain Technology
for Government. 2017. Citado na página 20.
BUCHMANN, J.; DAHMEN, E.; SZYDLO, M. Hash-based digital signature schemes. First
International Workshop on Post-Quantum Cryptography, 2008. Citado na página 50.
BUTERIN, V. A Next-Generation Smart Contract and Decentralized Application Platform. 2013. [Online]. <https://github.com/ethereum/wiki/wiki/White-Paper>. Whitepaper. Citado na página 28.
BUTERIN, V. Slasher: A Punitive Proof-of-Stake Algorithm. 2014. <https://blog.ethereum. org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/>. (acessado em 27/09/2018). Citado 3 vezes nas páginas 32, 43 e 50.
BUTERIN, V.; GRIFFITH, V. Casper the friendly finality gadget. ArXiv e-prints, 2017. Citado 3 vezes nas páginas 32, 43 e 55.
CACHIN, C.; VUKOLIÊ, M. Blockchain consensus protocols in the wild. 31st International
Symposium on Distributed Computing (DISC 2017), v. 91, p. 1–16, 2017. Citado na página
49.
CASTRO, M.; LISKOV, B. Practical byzantine fault tolerance. OSDI ’99 Proceedings of
the third symposium on Operating systems design and implementation, p. 173–186, 1999.
Citado na página 96.
CHEN, J.; MICALI, S. Algorand. ArXiv e-prints, 2017. Citado na página 37. COBLEE. Litecoin - a lite version of Bitcoin. Launched! 2011. [Online]. <https: //bitcointalk.org/index.php?topic=47417.0>. Whitepaper. Citado na página 28.