Documentacao observer

.gitignore

@@ -0,0 +1,22 @@
+.gradle
+build/
+!gradle/wrapper/gradle-wrapper.jar
+!**/src/main/**
+!**/src/test/**
+
+.factorypath
+.project
+.settings
+
+
+### IntelliJ IDEA ###
+.idea
+**/.idea
+*.iws
+*.iml
+*.ipr
+out/
+
+
+### VS Code ###
+.vscode/

Como_atualizar_Besu.md

@@ -0,0 +1,83 @@
+
+
+
+# 1.Pré-requisitos 
+Para este guia, assumimos que você tem o ansible instalado na sua máquina.
+Documentação de instalação ansible: https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html
+
+# 2.Update
+
+Nós vamos sugerir duas formas diferentes de fazer o update do  besu: a primeira forma, é usando os scripts ansible; e a segunda forma é usando diretamente os binários 
+
+# Update através do ansible 
+
+2.0.1) Para fazer o update, é necessário acessar a sua máquina que está rodando o nó.
+
+2.0.2) Parar o besu.
+
+2.0.3.1) Caso você use o HTTP PROXY, verifique se as variáveis HTTP_PROXY e http_proxy estão definidas em /etc/environment (ou no .profile). Caso não esteja, defina tais variáveis. Exemplo:
+
+http_proxy=http://example.proxy.com:8080
+HTTP_PROXY=http://example.proxy.com:8080
+
+2.0.3.2) Caso você use o HTTPS PROXY, verifique se as variáveis HTTPS_PROXY e https_proxy estão definidas em /etc/environment(ou no .profile). Caso não esteja, defina tais variáveis. Exemplo: 
+
+https_proxy=https://example.proxy.com:8080
+HTTPS_PROXY=https://example.proxy.com:8080
+
+2.0.4) Agora retorne para a máquina que tem o ansible instalado e os scripts ansible (https://github.com/RBBNet/rbb/tree/master/instalacao-rbb-node).
+
+2.0.5) Configure o arquivo inventory definindo com o exemplo:
+
+"your node address"  node_ip=<besu_public_ip>  besu_release_version=<besu_version>
+
+no local do tipo do seu nó.
+
+2.0.6) Para terminar basta executar o comando:
+
+ansible-playbook -i inventory --private-key=~/.ssh/id_ecdsa -u remote_user site-lacchain-update-<TipoDoNó>.yml 
+
+# Update através dos binários 
+
+2.1.1) Parar o serviço Pantheon.
+
+2.1.2) Fazer um backup do usr/local/besu e descompactar o binário criando um  novo usr/local/besu.
+
+2.1.3) Reiniciar o Pantheon.
+
+2.1.4) Seguir os passos que estão na documentação:
+
+https://besu.hyperledger.org/en/stable/HowTo/Get-Started/Installation-Options/Install-Binaries/
+
+
+# Obs: alguns comando que podem ajudar a verificar se a atualização, terminou corretamente 
+
+Retorna a versão do besu:
+
+$ pantheon --version
+
+Ainda no shell com o curl consegue testar se está funcionando:
+
+$ curl -X POST --data '{"jsonrpc":"2.0","method":"admin_nodeInfo","params":[],"id":1}' http://localhost:4545
+
+Verificar se conectou com os outros nós:
+
+$ curl -X POST --data '{"jsonrpc":"2.0","method":"admin_peers","params":[],"id":1}' http://localhost:4545
+
+Verificar se já está sincronizado (deve retornar false quando sincronizar):
+
+$ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' http://localhost:4545
+
+
+# Atualizar o protocolo ethereum
+Para atualizar o protocolo, basta você adicionar uma linha no arquivo genesis file dizendo para qual protocolo a sua rede vai e
+em qual bloco isso vai começar a valer. Exemplo estamos usando o protocolo berlin e ele vai iniciar no bloco 974000:
+
+"config": {
+     ...
+    "constantinopleFixBlock": 0,
+    "berlinBlock": 17974000
+    ...
+}
+
+E, para finalizar, dê um restart no besu.

Como_criar_nós.md

@@ -2,9 +2,9 @@ A RBB implementada em Hyperledeger Besu é uma rede público-permissionada. Foi
 
 
 # Passo 1 - Ambiente Físico
-O procedimento da Lacchain contém configuração mínima de hardware: https://github.com/lacchain/bndes-network/blob/master/DEPLOY_NODE.md
+A configuração mínima de hardware pode ser vista [aqui](instalacao-rbb-node/DEPLOY_NODE.md).
 
-A recomendação do BID é uma VM por nó, sem docker, e que seja um SO **Ubuntu 18.4** ou **CentOS7**. 
+A recomendação do BID é uma VM por nó, sem docker, e que seja um SO **Ubuntu 18.4** ou **CentOS7**.
 
 O BNDES instalou com **RedHat 7**, por similaridade com CentOS7. Embora não fosse uma plataforma oficialmente homologada pela Lacchain, nenhum problema foi encontrado.
 
@@ -14,20 +14,20 @@ Verifique se o relógio do seu servidor está com a hora correta. É recomendáv
 
 Há quatro tipos de nós: Boot, Validator, Writer e Observer. Cada instituição participante pode ter zero, um ou mais nós de um mesmo tipo.
 
-As VMs precisam ter IPs públicos para serem acessíveis na Internet. Além disso, precisam ter o mesmo IP outbound e inbound. 
+As VMs precisam ter IPs públicos para serem acessíveis na Internet. Além disso, precisam ter o mesmo IP outbound e inbound.
 
-Para instalar os nós, seguir o procedimento da Lacchain: https://github.com/lacchain/bndes-network/blob/master/DEPLOY_NODE.md, até a parte "Checking your connection". Orion será instalado, mas não inicializado. Não será possível verificar a conexão ainda. 
+Para instalar os nós, seguir [este procedimento](instalacao-rbb-node/DEPLOY_NODE.md), até a parte "Checking your connection". Orion será instalado, mas não inicializado. Não será possível verificar a conexão ainda.
 
 Ao fim da instalação, veja como conferir o resultado com este [procedimento](detalhamento_comandos_Besu.md).
 
-É possível configurar mais de um nó ao mesmo tempo utilizando o script do Ansible descrito pela Lacchain. O ChainID da RBB já está configurado nos scripts para 648629. 
+É possível configurar mais de um nó ao mesmo tempo utilizando o script do Ansible descrito pela Lacchain. O ChainID da RBB já está configurado nos scripts para 648629.
 
 Todas as VMS do BNDES estão DMZ de blockchain do BNDES, uma vez que todos os nós podem receber conexões externas.
 
 
 # Passo 3 - Filtros de Rede
 
-A figura abaixo reflete a topologia da rede quando só havia BNDES e BID como nós. As conexões peer-to-peer são na porta 60606 TCP/UDP. A topologia da rede será análoga a da Lacchain: https://github.com/lacchain/bndes-network/blob/master/TOPOLOGY_AND_ARCHITECTURE.md
+A figura abaixo reflete a topologia da rede quando só havia BNDES e BID como nós. As conexões peer-to-peer são na porta 60606 TCP/UDP. A [topologia da rede será análoga a da Lacchain](instalacao-rbb-node/TOPOLOGY_AND_ARCHITECTURE.md).
 
 ![GitHub Logo](./network_diagram_rbb.png)
 
@@ -54,16 +54,22 @@ Para a porta 123 (udp):
 
 Para obter os detalhes de IPs de máquinas -> favor entrar em contato com blockchaingov@bndes.gov.br.
 
+Algumas boas práticas para este passo:
+- Sugere-se aumentar a resilência dos nós da rede criando conexões interna entre os nós da mesma instituição.
+- Sugere-se aumentar a resilência dos nós conectando diferentes nós da rede por diferentes provedores de rede.
+- Sugere-se fortemente alocar aos nós internos máquinas com IPs públicos que não será modificado no futuro. Uma mudança de IP implica em reconfigurações de regras de firewall e reconexão dos nós com novos e-nodes.
+
+
 # Passo 4 - Gestão de chaves
 
 O processo de instalação de cada nó gera a chave privada em ``/root/lacchain/data/key``. Essa chave privada está associada a chave pública do nó, que compõe o seu enode. A chave pode ser regerada posteriormente, se necessário, mas isso impactará o enode do nó. Perceba que a chave privada é salva sem criptografia.
-É possível conferir a chave pública do seu nó no log (nível INFO) ou executando o comando ``admin_nodeInfo``. 
+É possível conferir a chave pública do seu nó no log (nível INFO) ou executando o comando ``admin_nodeInfo``.
 
 A conta blockchain associada ao nó está salva em ``/root/lacchain/data/nodeAddress``. Ela será necessária no momento do permissionamento (Passos 5 e 6).
 
 Além das chaves dos nós, no futuro podem ser criadas chaves privadas para permissionamento (ver passo 5) ou para o uso de smart contracts específicos.
 
-É necessário ter um mecanismo interno para gerir essas chaves privadas: onde armazenar a chave, quem tem acesso, mecanismo de recuperação etc. 
+É necessário ter um mecanismo interno para gerir essas chaves privadas: onde armazenar a chave, quem tem acesso, mecanismo de recuperação etc.
 
 # Passo 5 - Permissionamento dos novos nós
 
@@ -84,36 +90,41 @@ Adicionar manualmente os novos nós em nós já sincronizados da rede pela API r
 
 # Passo 7 - Verificar Conexão na Rede
 
-Siga o procedimento de **"Checking your connection"** da Lacchain: https://github.com/lacchain/bndes-network/blob/master/DEPLOY_NODE.md. 
+Siga o [procedimento de **"Checking your connection"**](instalacao-rbb-node/DEPLOY_NODE.md#checking-your-connection).
+
+O comando a seguir permite verificar que o nó está sincronizado com os outros nós da rede: ``curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":51}' http://localhost:4545``
+
+Atualmente, um bloco é gerado a cada 2segundos, então o número retornado pelo comando anterior deve mudar a cada execução do comando.
 
 Opcionalmente, esse link também pode ajudar: https://github.com/lacchain/besu-network/issues/33
 
 
 # Passo 8 - Inclusão de nós Validadores no Algoritmo de Consenso  (apenas para novo nós do tipo validador)
 
-Se novos validadores forem adicionados é necessário disparar uma votação de forma a incluí-los no algoritmo de consenso. Para isso, deve-se seguir o procedimento https://besu.hyperledger.org/en/stable/HowTo/Configure/Consensus-Protocols/IBFT/#adding-and-removing-validators-by-voting.
+Se novos validadores forem adicionados é necessário disparar uma votação de forma a incluí-los no algoritmo de consenso. Para isso, deve-se seguir o procedimento https://besu.hyperledger.org/en/stable/HowTo/Configure/Consensus-Protocols/Add-Validators/ (ver seção de IBFT2.0 com votação).
 Algumas observações importantes:
-* Os comandos devem ser disparados usando os consoles dos validadores que atualmente participam do algoritmo de consenso da rede. 
-* Será necessário informar as contas blockchain dos novos validadores, que podem ser encontradas em: ``/root/lacchain/data/nodeAddress``. Caso esse arquivo esteja inválido por algum motivo, é possível regerá-lo usando ``pantheon --data-path=/root/lacchain/data public-key export-address --to=/root/lacchain/data/nodeAddress!``.
-* A votação precisa ocorrer dentro de um período de uma mesma "época", e o tamanho da época é definida no arquivo genesis. Considerando as configurações atuais da rede, cada época dura cerca de 16h. 
+* É uma boa prática utilizar ``ibft_getSignerMetrics`` para verificar se existem validadores não-ativos antes de iniciar a votação (https://besu.hyperledger.org/en/stable/Reference/API-Methods/#ibft_getsignermetrics).
+* Os comandos devem ser disparados usando os consoles dos validadores que atualmente participam do algoritmo de consenso da rede.
+* Será necessário informar as contas blockchain (nodeAddress) dos novos validadores, que podem ser encontradas em: ``/root/lacchain/data/nodeAddress``. Caso esse arquivo esteja inválido por algum motivo, é possível regerá-lo usando ``pantheon --data-path=/root/lacchain/data public-key export-address --to=/root/lacchain/data/nodeAddress!``.
+* A votação precisa ocorrer dentro de um período de uma mesma "época", e o tamanho da época é definida no arquivo genesis. Considerando as configurações atuais da rede, cada época dura cerca de 16h.
+* A forma como essa atividade é realizada usualmente é enviando um email a todos os participantes da RBB combinando um horário para votação de todas as instituições que possuam nós validadores.
+* Se a votação for bem sucedida, será possível ver no block explorer que o(s) novo(s) validador(es) está(ão) gerando e assinando nós na rede.
 
 
 # Passo 9 (opcional) - Instalação de Dapp de permissionamento
 
-O Dapp de permissionamento é um frontend que permite visualizar quem são as contas Administradoras da rede, visualizar as regras de permissionamento para contas e para nós. 
+O Dapp de permissionamento é um frontend que permite visualizar quem são as contas Administradoras da rede, visualizar as regras de permissionamento para contas e para nós.
 
-A Lacchain fez pequenas mehorias no Dapp de permissionamento da plataforma Besu. Para instalar o Dapp siga o seguinte procedimento: https://github.com/lacchain/permissioning-smart-contracts
+A Lacchain fez pequenas melhorias no Dapp de permissionamento da plataforma Besu. Para instalar o Dapp siga o seguinte procedimento: https://github.com/lacchain/permissioning-smart-contracts
 
 Atenção: é necessário implantar o branch beta1.
 
 Observação: O dapp apresenta as informações truncadas, mas é possível copiar e colar para ver a informação completa. Além disso, atenção porque o dapp exibe a informação de Public_key com um string "0x" no metade do valor. Ex.: a public key
-0xd2c9170ace6301fe416b636c0f91816b7a9184c29562b55dfbcbbb48305d6717322c07a1e0d0432b89c1bef468f93963cd94a4ec2d90cd5d53f6e16b3767c390 é exibida como 
+0xd2c9170ace6301fe416b636c0f91816b7a9184c29562b55dfbcbbb48305d6717322c07a1e0d0432b89c1bef468f93963cd94a4ec2d90cd5d53f6e16b3767c390 é exibida como
 0xd2c9170ace6301fe416b636c0f91816b7a9184c29562b55dfbcbbb48305d67170x322c07a1e0d0432b89c1bef468f93963cd94a4ec2d90cd5d53f6e16b3767c390.
 
-O Dapp está instalado internamente no BNDES na url https://rbb-permissioning.dsv.bndes.net/
-
-Para criar novas regras de permissionamento, é necessário ter uma conta blockchain autorizada. 
-É possível utilizar qualquer forma de geração de conta Ethereum, como via Metamask. 
+Para criar novas regras de permissionamento, é necessário ter uma conta blockchain autorizada.
+É possível utilizar qualquer forma de geração de conta Ethereum, como via Metamask.
 
 Endereço do contrato de permissionamento de nós: 0x0000000000000000000000000000000000009999
 
@@ -124,14 +135,15 @@ Embora exista, o contrato de permissionamento de contas ainda não está sendo u
 
 # Passo 10 - Verificar Boot Nodes em Uso
 
-Para cada um dos nós, verifique no arquivo `/root/lacchain/config.toml`, o valor atribuído a variável `bootnodes`.
+Para cada um dos nós, verifique no arquivo `/root/lacchain/config.toml`, o valor atribuído à variável `bootnodes`.
 
-Por exemplo, 
+Por exemplo,
 
-``
+```
 bootnodes=[  "enode://c1c9170ace6301fe416b636c0f91816b7a9184c29562b55dfbcbbb48305d6717322c07a1e0d0432b89c1bef468f93963cd94a4ec2d90cd5d53f6e16b3767c328@200.225.100.107:60606",
 "enode://91ca844776cc9bf69cd4eadaeefdf105815b61ec7ba0fef0ab3fc0c954a8af3bfbbdbc9975ca8cd6d1bd366bcd69df2066f2ed17bed4d1c53164d46e94afa03b@35.188.197.198:60606"
-]``
+]
+```
 
 Essa variável indica quais Bootnodes podem ser utilizados quando o nó iniciar. Idealmente quanto mais bootnodes você listar mais resiliente seus nós estarão. Assim, idealmente você deve incluir o máximo de bootnodes possíveis considerando a lista total de bootnodes da RBB. Para obter a lista de todos os boot nodes da rede você pode perguntar a alguma outra instituição ou instalar o dapp de permissionamento referenciado no passo anterior.
 
@@ -160,9 +172,9 @@ Em caso de dúvidas ou comentários, por favor, enviem e-mail para blockchaingov
 
 # Comentário adicionais
 
-BNDES e BID conversaram sobre algumas possibilidades de aumentar a resilência dos nós. Infelizmente, não é possível configurar mais de um IP para o mesmo nó (dado que o IP é usado para o enode) ou fazer um DNS para deixar os nós independentes de IP. Uma possibilidade natural é configurar vários nós de um mesmo tipo e usar um Load Balancer de forma a deixar os vários IPs transparente para o usuário. 
+BNDES e BID conversaram sobre algumas possibilidades de aumentar a resilência dos nós. Infelizmente, não é possível configurar mais de um IP para o mesmo nó (dado que o IP é usado para o enode) ou fazer um DNS para deixar os nós independentes de IP. Uma possibilidade natural é configurar vários nós de um mesmo tipo e usar um Load Balancer de forma a deixar os vários IPs transparente para o usuário.
 
 
 Caso tenha erros durante a instalação e precise aumentar o nível de log do Besu, basta acrescentar `--logging DEBUG` no `start-pantheon.sh` e restartar o Besu. Depois de resolvido, remova essa mudança de forma a minimizar o tamanho de log gerado. Veja mais em: https://besu.hyperledger.org/en/stable/HowTo/Monitor/Logging/.
 
-
+Algumas vezes o Besu pode parar de sincronizar sem razão aparente. Um motivo pode ser falta de espaço de armazenamento no servidor.