dcrdata: executando o seu próprio explorador de blocos

1. Introdução

O dcrdata fornece uma interface web para analisar o conteúdo de blocos, transações e endereços de carteiras, além de tickets e votos. Para conferir o funcionamento do dcrdata acesse https://dcrdata.decred.org/.

Antes de começar a instalação, faça seu planejamento: veja na seção 3 os pré-requisitos de hardware e software.

1.1. Motivação

É comum, após realizar uma transação, colocar o txid (hash da transação) em um block explorer para ver se a transação já foi propagada e o seu número de confirmações. Com frequência, ao realizar uma transação p2p, a parte responsável por enviar as moedas envia um link de um block explorer apontando para o txid. Aqui começam os problemas do nosso herói.

Privacidade

Ao abrir esse link o usuário está se conectando a um web server, que registrará o seu endereço IP e muitas outras informações divulgadas pelo browser.

Ainda que possa usar uma VPN para mascarar sua origem, seria necessário ter certeza de que o serviço de VPN não armazena seu endereço IP e os destinos acessados e consulta a DNS (no log policy). O site PrivacyTools tem uma lista de provedores de VPN localizados fora dos EUA, com no log policy (apesar de não haver nenhuma garantia), que aceitam Bitcoin e suportam OpenVPN. Dê preferência a provedores localizados em países fora do grupo Fourteen Eyes.

Código malicioso

Além de ter sua informações e até a sua localização expostos, o usuário também se expõe a execução de código malicioso, principalmente via Javascript.

Transação forjada

Se a contraparte na transação detém o controle sobre o block explorer, ela poderá forjar uma transação que parece existir na blockchain mas existe apenas naquele banco de dados. Um cenário é quando uma das partes espera que a outra confirme o envio para proceder com o negócio.

Conclusão

Rodando o seu próprio full node, com o seu próprio block explorer, o usuário não fica exposto a essas ameaças toda vez que verifica uma transação.

1.2. Diferenças entre nodes

É comum perceber diferenças entre nodes, mas todas as transações serão propagadas a todos os nodes, mesmo que leve um pouco mais de tempo até chegar ao seu.

O mempool do seu node provavelmente não será igual ao mempool dos outros nodes. As transações são propagadas entre os nodes que estão diretamente conectados e assim por diante. Além disso, a mempool é zerada toda vez que o dcrd é desligado. Então é normal que após reiniciar o dcrd a sua mempool não terá transações que outros nodes tem.

2. Arquitetura

Cenário 1: dcrd, dcrdata e PostgreSQL e o cliente web no mesmo servidor.

Cenário 2: dcrd, dcrdata e PostgreSQL no mesmo servidor. Cliente web faz acesso remoto.

Cenário 3: dcrd em um servidor, dcrdata e PostgreSQL em outro. Cliente web faz acesso remoto.

Figura 1 - Alguns cenários possíveis para instalação do dcrdata

3. Instalação

Os passos a seguir foram executados em um Ubuntu 18.04 64-bit para a instalação do dcrdata 5.2.0, com dcrd 1.5.1, PostgreSQL 12 e nginx 1.14 (um mix entre os cenários 2 e 4, mais adiante).

Pré-requisitos de hardware

dcrdata apenas (PostgreSQL em outro servidor):

Configuração mínima:

• 1 CPU core
• 2 GB RAM
• HDD com 4 GB de espaço livre

dcrdata e PostgreSQL no mesmo servidor (Cenários 1, 2 e 3):

Configuração mínima (funciona, mas muito lento):

• 2 CPU core
• 6 GB RAM
• HDD com 80 GB de espaço livre

Configuração recomendada:

• 2+ CPU cores
• 8+ GB RAM
• SSD com 80 GB de espaço livre

Deve haver espaço suficiente na partição onde se encontra o diretório de dados do PostgreSQL (default: /var/lib/postgresql). Escolha uma partição ou disco que tenha no mínimo 80 GB livres (para 430.000 blocos) mais um espaço para crescimento.

Pré-requisitos de software

Golang

para executar o dcrdata 5.2.0, a linguagem Go 1.12.12+ or 1.13.3+ deve estar instalada. Para instalar, veja o artigo Instalando o Go (golang).

Verifique que o Go está no PATH.

$ echo $PATH

Se não estiver, adicione através do comando (assumindo o caminho de instalação em Instalando o Go (golang), que mostra como tornar essa configuração permanente):

$ export PATH=$PATH:/usr/local/go/bin

Verifique que o Go correto está usado:

$ which go
$ go version

dcrd

É necessário ter acesso ao dcrd (>=1.5.0) sincronizado com o melhor bloco atual da rede. Para instalar, veja o artigo Instalando o dcrd. Os cenários 1 e 2 assumem que o dcrd e o dcrdata estão no mesmo servidor e essa é a configuração padrão do dcrdata.conf. Para executar conforme o cenário 3, será necessário apontar no dcrdata.conf o endereço IP do servidor dcrd.

O dcrd deve estar configurado com os seguintes parâmetros no dcrd.conf (o artigo Instalando o dcrd já prevê essa configuração):

txindex=1
addrindex=1

Ou ser executado através do comando a seguir no diretório onde se encontra o executável:

$ ./dcrd --txindex --addrindex

Para configurar o dcrd como um serviço ou saber mais sobre o processo, veja mais em dcrd como um serviço Linux.

Node.js

Node.js 12.x ou 13.x é necessário apenas para compilação dos ‘Static Web Assets’, não sendo executado depois. Os comandos serão executados dentro do diretório do source do dcrdata, a seguir.

PostgreSQL

O PostgreSQL 10.5+ é necessário. As versões 11.x e 12.x são recomendadas por questões de performance.

Minha recomendação também é utilizar a versão 12 pois me trouxe melhores resultados. Para isso, removi primeiro a versão 10 que já veio instalada:

$ sudo apt-get remove postgresql-10
$ sudo apt-get install postgresql-12

Nota: Se estiver em um Ubuntu 18 e o apt não encontrar o pacote PostgreSQL 12, pode seguir as instruções do artigo https://www.osradar.com/postgresql-12-ubuntu-18-04/.

Importante! É preciso configurar corretamente o PostgreSQL ANTES de prosseguir. Veja a ferramenta online PGTune que gera os parâmetros que devem ser configurados no arquivo /etc/postgresql/12/main/postgresql.conf

Passos da instalação

A referência $DCRDATA_DIR pode ser interpretada da seguinte forma:

• $HOME/go-work/github.com/decred/dcrdata, como no README do dcrdata.
• /opt/decred/dcrdata, seguinto a estrutura de diretórios porposta no artigo Instalando o dcrd
• Você também pode usar qualquer estrutura de diretórios de sua escolha.

Já a referência $DCRDATA_USER_DIR se refere ao diretório de usuário onde ficará o arquivo de configuração. Um exemplo é /home/dcrduser.

a) Clone o repositório do dcrdata:

$ sudo git clone https://github.com/decred/dcrdata $DCRDATA_DIR

Se não possuir o git instalado, instale com:

$ sudo apt-get install git

b) Entre no diretório que acabou de ser criado e compile o dcrdata:

$ cd $DCRDATA_DIR
$ go build

Compile também o Webpack, módulo empacotador de JavaScript usado para compilar e empacotar os objetos estáticos no diretório public. A ferramenta npm do Node.js será usada para instalar as dependências necessárias e para compilar o módulo.

$ sudo apt-get install npm
$ sudo npm install
$ sudo npm run build

c) Crie o arquivo de configuração a partir do sample:

$ mkdir -p $DCRDATA_USER_DIR
$ cp sample-dcrdata.conf $DCRDATA_USER_DIR/dcrdata.conf

d) Ajuste os parâmetros dcrduser e dcrdpass com as informações do usuário RPC do dcrd. No arquivo dcrd.conf os parâmetros se chamam rpcuser e rpcpass:

e) Se o dcrd está sendo executado em outro host (Cenário 3), altere também os parâmetros dcrdserv e dcrdcert.

f) Se o dcrdata será usado como explorador de blocos para uma rede local (e não apenas para o localhost), será necessário configurar o serviço web para escutar em um endereço IP local, além do localhost, usando o parâmetro apilisten. Essa configuração é fundamental para hosts headless (sem monitor).

apilisten=$LOCAL_IP_ADDRESS

g) Crie no PostgreSQL a credencial de acesso e o banco de dados de acordo com a configuração feita em dcrdata.conf. Aqui, ambos receberam o nome “dcrdata”:

pgdbname=dcrdata
pguser=dcrdata
pgpass=

Para criar a credencial e o banco de dados no PostgreSQL, substitua as váriáveis abaixo pelos nomes escolhidos para os parâmetros acima. Foi concedido privilégio de superuser porque houve problema de criação de indexes (o único role desse servidor é ser dcrdata, não há outro banco de dados e também não há carteira):

$ sudo su - postgres
$ createuser $PGUSER
$ createdb -O $PGUSER $PGDBNAME
$ psql
postgres=# \password $PGUSER
[Digite a senha e confirme]

postgres=# \q

Escreva a senha no parâmetro pgpass no arquivo dcrdata.conf.

h) Inicie o dcrdata.

Recomendação: Para iniciar como um serviço veja a próxima seção.

$ cd $DCRDATA_DIR
$ ./dcrdata

O dcrdata precisará de aproximadamente seis horas para varrer os blocos em busca das transações (para aproximadamente 430.000 blocos).

Quando a aplicação web estiver pronta, o dcrdata indicará no log: ‘DATD: Now serving the explorer and APIs on http://127.0.0.1:7777/’. Acesse o dcrdata pelo browser neste endereço (se possuir um browser local):

Figura 2 - O dcrdata está instalado e pronto para uso

dcrdata como um serviço do Linux

Uma das grandes vantagens em configurar tanto dcrd como dcrdata como serviços do Linux é que os processos não serão interrompidos caso a sua sessão seja desconectada.

Para configurar o dcrd como um serviço ou saber mais sobre o processo, veja mais em dcrd como um serviço Linux.

# dcrdata termination depends on kill signal.
#
# Author: Marcelo Martins (https://stakey.club)
# dcrdata reference doc:
# https://github.com/decred/dcrdata#getting-started
#
[Unit]
Description=The block explorer of Decred network
Documentation=http://decred.org/
After=network.target dcrd.service postgresql.service

[Service]
Type=simple
WorkingDirectory=/opt/decred/dcrdata
ExecStart=/opt/decred/dcrdata/dcrdata
ExecStop=
TimeoutStopSec=5
KillMode=mixed
Restart=on-abnormal
User=dcrduser
Group=users

[Install]
WantedBy=multi-user.target

[Unit] After: As units listadas nessa diretiva são iniciadas antes de iniciar essa unit. Isso não implica em uma relação de dependência. Se for necessária uma relação de dependência a diretiva Requires deve ser usada.

[Service] WorkingDirectory: É necessário informar o caminho de instalação do dcrdata. Se você instalou de acordo com este artigo, digite /opt/decred/dcrdata. Se fez como no README, digite $HOME/go-work/github.com/decred/dcrdata.

ExecStart: Indica o caminho completo e os argumentos do comando que inicia o serviço. Se o caminho for precedido por um “-“, términos com código de saída diferente de zero (falha) serão aceitos sem marcar o término como falha. Indique o caminho da sua instalação do dcrdata.

User: Com qual usuário do sistema o serviço deve ser executado. Esse parâmetro pode ser ocultado.

Group: Com qual grupo do sistema o serviço deve ser executado. Esse parâmetro pode ser ocultado.

3.1. Habilitação do serviço

Mova o arquivo dcrdata.service para a pasta do sistema que contém outros arquivos de configuração de serviços como esse. Esse passo é importante para que o comando seguinte possa localizar o arquivo do serviço e habilitá-lo.

$ sudo mv dcrdata.service /etc/systemd/system/
$ sudo systemctl enable dcrdata.service 
Created symlink /etc/systemd/system/multi-user.target.wants/dcrdata.service → /etc/systemd/system/dcrdata.service.

Sempre que o sistema for reiniciado o serviço do dcrdata será requerido para inicialização pelo modo ‘multi-user’ (WantedBy) após a inicialização do serviços ‘After’, rede e dcrd, caso esteja instalado nesse servidor, e será iniciado (ExecStart) com poderes do usuário (User) e do grupo (Group) se esses parâmetros forem especificados.

Execução

Depois que o serviço é habilitado através do systemctl, já é possível verificar seu status:

$ sudo systemctl status dcrdata.service 
● dcrdata.service - The block explorer of Decred network
   Loaded: loaded (/etc/systemd/system/dcrdata.service; enabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: http://decred.org/

Para iniciar o serviço e verificar sua mudança de status, que aparece na linha ‘Active: active (running)’:

$ sudo systemctl start dcrdata.service 
$ sudo systemctl status dcrdata.service 
● dcrdata.service - The block explorer of Decred network
   Loaded: loaded (/etc/systemd/system/dcrdata.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2020-03-02 00:49:00 UTC; 3s ago
     Docs: http://decred.org/
 Main PID: 2912 (dcrdata)
    Tasks: 14 (limit: 4915)
   CGroup: /system.slice/dcrdata.service
           ├─2912 /opt/decred/dcrdata/dcrdata
           ├─2940 git clone https://github.com/decred-proposals/mainnet.git prop-repo
           ├─2941 /usr/lib/git-core/git-remote-https origin https://github.com/decred-proposals/mainnet.git
           ├─2943 /usr/lib/git-core/git fetch-pack --stateless-rpc --stdin --lock-pack --thin --check-self-contained-and-connected --cloning --no-progress https://github.com/de
           └─2945 /usr/lib/git-core/git index-pack --stdin --fix-thin --keep=fetch-pack 2943 on ip-172-31-9-82 --check-self-contained-and-connected --pack_header=2,118865

Mar 02 00:49:00 ip-172-31-9-82 dcrdata[2912]: 2020-03-02 00:49:00.607 [INF] DATD: Connected to dcrd (JSON-RPC API v6.1.1) on MainNet
Mar 02 00:49:00 ip-172-31-9-82 dcrdata[2912]: 2020-03-02 00:49:00.607 [INF] SKDB: Loading ticket pool DB. This may take a minute...
Mar 02 00:49:00 ip-172-31-9-82 dcrdata[2912]: 2020-03-02 00:49:00.648 [INF] SKDB: badger: All 0 tables opened in 0s
Mar 02 00:49:00 ip-172-31-9-82 dcrdata[2912]: 2020-03-02 00:49:00.660 [INF] SKDB: Loading all ticket pool diffs...
Mar 02 00:49:00 ip-172-31-9-82 dcrdata[2912]: 2020-03-02 00:49:00.660 [INF] SKDB: Successfully loaded 0 ticket pool diffs
Mar 02 00:49:00 ip-172-31-9-82 dcrdata[2912]: 2020-03-02 00:49:00.660 [INF] SKDB: Creating new stake DB.
Mar 02 00:49:00 ip-172-31-9-82 dcrdata[2912]: 2020-03-02 00:49:00.683 [INF] SKDB: Advancing ticket pool DB to tip via diffs...
Mar 02 00:49:00 ip-172-31-9-82 dcrdata[2912]: 2020-03-02 00:49:00.683 [INF] SKDB: Pre-populating live ticket cache and computing pool value...
Mar 02 00:49:00 ip-172-31-9-82 dcrdata[2912]: 2020-03-02 00:49:00.683 [INF] DATD: Loaded StakeDatabase at height 0
Mar 02 00:49:00 ip-172-31-9-82 dcrdata[2912]: 2020-03-02 00:49:00.683 [INF] DATD: Setting up the Politeia's proposals clone repository. Please wait...
lines 1-18/18 (END)

Para monitorar o status dos serviços como poderia ser feito quando a execução é direta no terminal, inicie novos terminais e faça uma conexão SSH em cada um para o servidor (assumindo que dcrd e dcrdata estão sendo executados no mesmo servidor). Em cada um digite os comando abaixo, de acordo com a sua estrutura de diretórios:

$ tail -f /home/dcrduser/.dcrd/logs/mainnet/dcrd.log
$ tail -f /home/dcrduser/.dcrdata/logs/mainnet/dcrdata.log
$ tail -f /var/log/postgresql/postgresql-12-main.log

3.2. Acesso via HTTPS

Agora que tudo está funcionando como esperado, é possível fazer uma última modificação: configurar o acesso HTTPS para o explorador de blocos. O acesso via HTTPS tem o objetivo de evitar que a rede local possa capturar os endereços de transações e carteiras que um usuário pesquisa, o que pode levar a descoberta de suas compras, tickets ou saldo, por inferência ou correlação. Se o dcrdata está sendo acessado via browser a partir do localhost, configurar o acesso HTTPS não trará nenhum benefício.

O README do dcrdata sugere que esse acesso seja feito via proxy reverso nginx conforme a figura a seguir, exceto pela separação em três dispositivos diferentes:

Figura 3 - Cenário 4 para uso do dcrdata, agora via nginx

O arquivo sample-nginx.conf no diretório principal do dcrdata já está pré-configurado com a aplicação que roda em http://127.0.0.1:7777/. O que fica faltando é um ajuste de configuração e o certificado digital para fazer a criptografia entre o nginx e o browser do cliente. As instruções abaixo assumem o cenário da Figura 3, exceto pela separação entre os dispositivos.

O primeiro passo é a instalação do nginx:

$ sudo apt install nginx

Em seguida, copie o arquivo sample-nginx.conf para /etc/nginx/nginx.conf e edite o arquivo para incluir o caminho correto do certificado e da chave privada:

$ sudo mv /etc/nginx/nginx.conf /etc/nginx/nginx.conf.old
$ sudo cp sample-nginx.conf /etc/nginx/nginx.conf

As instruções abaixo mostram como criar um certificado X.509 para usar com o nginx. Tenha em mente que você será importunado pelo Google Chrome, que não aceitará o certificado self-signed da próxima seção sem lutar por isso. Dê preferência ao uso do Let’s Encrypt, seção logo a seguir.

OpenSSL self-signed certificate

Como um certificado self-signed é um certificado como outro qualquer exceto pela relação de confiança, vamos gerar um certificado self-signed no dcrdata para fazer a criptografia da comunicação.

a) Crie o diretório, o certificado e a chave privada e configure as permissões do diretório:

$ sudo mkdir -p /etc/ssl/dcrdata
$ sudo openssl req -new -x509 -days 365 -nodes -out /etc/ssl/dcrdata/dcrdata-cert.pem -keyout /etc/ssl/dcrdata/dcrdata-key.key
$ sudo chmod -R 600 /etc/ssl/dcrdata

b) No arquivo nginx.conf, altere os parâmetros ssl_certificate e ssl_certificate_key para que apontem para o certificado e a chave gerados na primeira etapa:

ssl_certificate       /etc/ssl/dcrdata/dcrdata-cert.pem
ssl_certificate_key   /etc/ssl/dcrdata/dcrdata-key.key

c) Remova as versões anteriores do TLS e deixe apenas a atual, 1.2. Use apenas métodos criptográficos mais seguros, o que vai impedir o acesso a partir de dispositivos desatualizados.

ssl_protocols         TLSv1.2;
ssl_ciphers           ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256;

d) Reinicie o serviço do nginx:

$ sudo service nginx restart

e) Acesse o endereço https://127.0.0.1/. O browser avisará que o certificado não faz parte de uma cadeia de confiança.

Figura 4 - Exceção de segurança no Firefox

f) Crie uma exceção permanente e recarregue a página. O alerta permanecerá sendo mostrado na barra de endereços.

Figura 5 - dcrdata acessado por https

Let’s Encrypt certificate

Para esta distribuição e versão de sistema operacional foram seguidos os passos apresentados aqui.

Em resumo, adicione o repositório do Certbot, atualize a lista de pacotes, instale o certbot:

$ sudo apt-get update
$ sudo apt-get install software-properties-common
$ sudo add-apt-repository universe
$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt-get update

$ sudo apt-get install certbot python-certbot-nginx

3.3. Acesso HTTPS via Tor

Além da criptografia ponta-a-ponta configurada na seção anterior, também podemos encapsular o acesso HTTPS via Tor, pelo menos na ponta do servidor dcrdata.

Figura 6 - dcrdata acessado por https via Tor

Configuração do nginx

Altere o parâmetro listen dentro da seção server:

    server {
        listen       443 default_server;
        server_name  _;

para:

    server {
        listen       127.0.0.1:9070 default_server;
        server_name _;

Configuração do Tor

Para instalar o Onion Service, será necessário editar o arquivo torrc.

a) Procure no diretório Browser/TorBrowser/Data/Tor/torrc no diretório do Tor Browser.

b) Abra o arquivo torrc e procure pela linha: ### This section is just for location-hidden services ###

c) Adicione as seguintes linhas ao torrc:

HiddenServiceDir /var/tor/dcrdata
HiddenServicePort 443 127.0.0.1:9070

d) Recarrege a configuração do Tor:

$ sudo service tor reload

No diretório especificado em HiddenServiceDir serão criados os arquivos hostname e private_key, que contém o hostname .onion e a chave privada respectivamente.

hostname

O arquivo hostname é criado pelo Tor é contém o nome com o qual o serviço se anuncia na rede Tor, que é uma versão curta da chave pública e se parece com duskgytldkxiuqc6.onion. Esse é o nome público do seu serviço e será usado para acessar o dcrdata.

private_key

Outro arquivo criado no mesmo diretório é o private_key. Mantenha-o em segurança. Ele contém a chave privada gerada para esse onion service e se cair em mão erradas permitirá que terceiros se passem pelo serviço na rede do Tor.

e) Reinicie o nginx:

$ sudo service nginx restart

Para saber mais, leia sobre o uso do Decred através da rede Tor.

4. Atualização

Encerre o processo dcrdata através de [Ctrl+C] no terminal onde está sendo executado ou termine o processo através do comando kill:

$ kill `ps ax | grep ./dcrdata | head -1 | cut -d' ' -f2`

Para atualizar o dcrdata:

$ cd $DCRDATA_DIR
$ git pull origin master
$ go build

Execute novamente o dcrdata:

$ ./dcrdata

Ao término acesse novamente o endereço web (se for local será https://127.0.0.1/) e verifique que o dcrdata funciona normalmente.

5. Troubleshooting

Been there, done that.

Problemas comuns

• Falta de memória: Vai interromper a execução do processo e deve causar um ‘crash’ no banco de dados. Geralmente ocorre com menos de 6 GB de RAM.
• Falta de espaço em disco: Quando o espaço em disco acabar, o processo do dcrdata será interrompido e isso deve causar um ‘crash’ no banco de dados. Você pode tentar se recuperar através do rebuilddb2, mas não tenha tantas esperanças.
• dcrdata trava após “[INF] PSQL: DB schema version 1.7.0”

Rebuilddb2

O script rebuilddb2 é o aplicativo que cria e dá manutenção no banco de dados PostgreSQL.

$DCRDATA_DIR será $HOME/go-work/github.com/dcrdata/dcrdata se você seguiu o README ou /opt/decred/dcrdata se seguiu este artigo.

a) Entre no diretório $DCRDATA_DIR/cmd/rebuilddb2/ e crie o arquivo de configuração com base no sample:

$ cd $DCRDATA_DIR/cmd/rebuilddb2
$ cp sample-rebuilddb2.conf rebuilddb2.conf

b) Edite os parâmetros de conexão RPC (dcrduser, dcrdpass, dcrdserv e dcrdcert) e PostgreSQL (dbname, dbuser e dbpass) com os mesmos valores de dcrdata.conf.

c) Altere em rebuilddb2.conf o parâmetro nodaemontls que contém o valor true. O default do rebuilddb2 é iniciar um cliente RPC e tentar se conectar ao dcrd sem criptografia. O dcrd recusará a conexão informando que o cliente não parece estar tentando um handshake TLS. No terminal do rebuilddb2 haverá um erro fatal de resposta HTTP malformada.

nodaemontls=false

d) Compile o rebuilddb2:

$ go build

e) Se o dcrd já estiver com todos os blocos copiados localmente, execute o rebuilddb2, que irá criar as tabelas no PostgreSQL. Se o dcrd ainda estiver sendo atualizado a conexão RPC será recusada.

$ ./rebuilddb2

Do zero

Para recomeçar sem precisar refazer todo o servidor, vamos excluir o banco de dados e os arquivos gerados pelo dcrdata.

a) Interrompa a execução do dcrdata, se for o caso:

$ kill `ps ax | grep ./dcrdata | head -1 | cut -d' ' -f2`

b) Exclua os arquivos do BoltDB:

$ rm -rf /home/dcrduser/data/mainnet/

c) Assumindo que o banco de dados se chame ‘dcrdata’, exclua-o do PostgreSQL:

$ sudo su - postgres
$ dropdb dcrdata
$ createdb -O $pguser $pgdbname
$ exit

6. Backup e Restore

dcrd e dcrdata

a) Faça backup das pastas ~/.dcrd e ~/.dcrdata.

b) Faça backup dos arquivos /etc/systemd/system/dcrd.service e drcdata.service

PostgreSQL

a) Faça backup do arquivo /etc/postgresql/12/main/postgresql.conf depois de acertar a configuração (PGTune).

b) Leia a man page do PostgreSQL na seção SQL Dump para aprender a fazer dump e restore do banco de dados.