dejo-core/dejo-node
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

commit inicial do projeto

Browse Source
This commit is contained in:
Júnior
2025-05-23 10:44:32 -03:00
commit 8f04473c0b
106 changed files with 5673 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

95
docs/api.md Normal file
View File

@ -0,0 +1,95 @@
# 🌐 **Documentação da API - DEJO Node**
## 📌 **Visão Geral**
O **DEJO Node** expõe uma API RPC/WebSockets para permitir **interação com a blockchain**, incluindo envio de transações, consulta de blocos e eventos em tempo real.
---
## **1️⃣ Endpoints REST**
### **1.1 - Consultar um Bloco**
**GET /block/{id}**
- Retorna informações sobre um bloco específico.
📌 **Exemplo de resposta:**
```json
{
"blockHeight": 10234,
"hash": "0xa7b9c...",
"previousHash": "0x9f8a...",
"timestamp": 1712456789,
"transactions": ["0xabc123", "0xdef456"]
}
```
### **1.2 - Enviar uma Transação**
**POST /tx**
- Envia uma nova transação para a rede.
📌 **Exemplo de requisição:**
```json
{
"from": "0x123...",
"to": "0xabc...",
"value": 100,
"gas": 21000,
"signature": "0x9f8a..."
}
```
📌 **Exemplo de resposta:**
```json
{
"status": "pending",
"txHash": "0xdef789..."
}
```
### **1.3 - Consultar Status de uma Transação**
**GET /tx/{hash}**
- Retorna o status de uma transação específica.
📌 **Exemplo de resposta:**
```json
{
"txHash": "0xdef789...",
"status": "confirmed",
"blockHeight": 10235
}
```
---
## **2️⃣ WebSockets para Eventos em Tempo Real**
### **2.1 - Subscribing em Novos Blocos**
**WS /events**
- Notifica sempre que um novo bloco é minerado.
📌 **Exemplo de mensagem recebida:**
```json
{
"event": "newBlock",
"blockHeight": 10236,
"hash": "0xbbc345..."
}
```
### **2.2 - Subscribing em Transações Confirmadas**
**WS /events**
- Notifica quando uma transação específica é confirmada.
📌 **Exemplo de mensagem recebida:**
```json
{
"event": "txConfirmed",
"txHash": "0xdef789...",
"blockHeight": 10235
}
```
---
📌 **Este documento será atualizado conforme novos endpoints forem adicionados.**
🚀 **DEJO Node: API eficiente para interação com a blockchain!** 🔥

37
docs/architecture.md Normal file
View File

@ -0,0 +1,37 @@
# 🏗️ **Arquitetura do DEJO Node**
## 📌 **Visão Geral**
O **DEJO Node** é o componente central da blockchain DEJO, responsável por **processar transações, validar blocos, manter consenso, armazenar dados e fornecer uma API para interação externa**. Sua arquitetura modular foi projetada para garantir **segurança, escalabilidade e interoperabilidade**.
---
## **1️⃣ Componentes Principais**
### **1.1 - Camada de Consenso**
- Implementa **Proof-of-Stake (PoS)** ou **Byzantine Fault Tolerance (BFT)** para validar blocos e garantir a integridade da rede.
- Gerencia **eleição de validadores** e mecanismo de **staking**.
- Inclui penalização (slashing) para validadores maliciosos.
### **1.2 - Camada de Execução de Transações**
- Responsável por **verificar, validar e executar transações**.
- Garante que apenas transações assinadas e válidas sejam incluídas nos blocos.
- Mantém um **mempool** para armazenar transações pendentes.
### **1.3 - Armazenamento e Estado**
- **LevelDB/BadgerDB** para armazenamento persistente de blocos e estados de conta.
- Suporte a **indexação rápida** para consultas eficientes.
- Implementação de **snapshots periódicos** para recuperação rápida da blockchain.
### **1.4 - Comunicação P2P**
- Usa **libp2p** para **sincronização de blocos e transações** entre nós.
- Implementa **descoberta dinâmica de peers** e mecanismos de propagação segura.
### **1.5 - API RPC/WebSockets**
- Disponibiliza **endpoints para consulta e envio de transações**.
- Implementa **WebSockets** para notificações em tempo real.
- Garante **autenticação e controle de acesso** para maior segurança.
---
📌 **Este documento será atualizado conforme novos módulos forem implementados.**
🚀 **DEJO Node: Arquitetura robusta e preparada para o futuro!** 🔥

61
docs/consensus.md Normal file
View File

@ -0,0 +1,61 @@
# ⚖️ Mecanismo de Consenso no DEJO Node
## 📌 Visão Geral
O **DEJO Node** utiliza um mecanismo de consenso híbrido, suportando **Proof-of-Stake (PoS)** e **Byzantine Fault Tolerance (BFT)**. O objetivo é garantir **segurança, escalabilidade e eficiência** na validação dos blocos e transações.
---
## 🔹 Modelos de Consenso Suportados
### **1. Proof-of-Stake (PoS)**
- Validadores são escolhidos com base na **quantidade de tokens em staking**.
- Mais stake = maior chance de ser escolhido para validar blocos.
- Implementação de **mecanismo de penalização (slashing)** para validadores maliciosos.
- Finalização de blocos sem necessidade de mineração intensiva.
### **2. Byzantine Fault Tolerance (BFT)**
- Algoritmo que permite consenso mesmo com **até 1/3 dos nós maliciosos**.
- Comunicação direta entre validadores para garantir consenso.
- Tempo de confirmação de bloco reduzido.
- Melhor aplicabilidade para redes permissionadas.
---
## 🔄 Processo de Validação de Blocos
1. Novas transações são propagadas via **rede P2P**.
2. Nós validadores selecionam um conjunto de transações e montam um bloco.
3. O bloco é proposto e enviado para os outros validadores.
4. Dependendo do modelo de consenso:
- **PoS** → O validador líder assina e propaga o bloco.
- **BFT** → Todos os validadores participam da decisão.
5. Após o consenso, o bloco é **finalizado e registrado no banco de dados**.
6. A blockchain se mantém sincronizada via comunicação P2P.
---
## ⚠️ Segurança e Penalizações (Slashing)
Para evitar ataques e validar a integridade da rede, aplicamos penalizações:
- **Slashing parcial**: Redução de stake caso um validador tente validar blocos conflitantes.
- **Slashing total**: Remoção completa do validador em casos de fraude comprovada.
- **Lista negra**: Impedimento de participação futura de validadores maliciosos.
---
## 📂 Estrutura de Diretórios Relacionada
```
dejo-node/
│── internal/
│ ├── consensus/ # Implementação do consenso (PoS/BFT)
│ ├── transactions/ # Processamento de transações
│ ├── storage/ # Persistência dos blocos
│── tests/
│ ├── consensus/ # Testes unitários e de integração do consenso
```
---
## 📖 Referências
- [Whitepaper Técnico da DEJO](../Whitepaper_Tecnico.pdf)
- [Plano de Negócios - DEJO Digital Assets](../Plano_de_Negocios.pdf)
- [Arquitetura do DEJO Node](architecture.md)
🚀 **DEJO Node: Segurança e Consenso para a Blockchain!** 🔥

108
docs/healthchecks.md Normal file
View File

@ -0,0 +1,108 @@
# 🔍 **Healthchecks - DEJO Node**
## 📌 **Visão Geral**
Os healthchecks do **DEJO Node** garantem que a aplicação está rodando corretamente e que seus componentes essenciais estão operacionais. Eles são divididos em três categorias principais:
1️⃣ **Liveness Probe** → Verifica se o processo ainda está ativo.
2️⃣ **Readiness Probe** → Indica se o serviço pode receber tráfego.
3️⃣ **Startup Probe** → Confirma se a aplicação inicializou corretamente.
---
## **1️⃣ Endpoints de Healthcheck**
### **1.1 - Liveness Probe**
📌 **Endpoint:** `GET /health/liveness`
- Retorna se o processo do nó está ativo e não travou.
- Se falhar, o Kubernetes pode reiniciar o pod.
📌 **Exemplo de resposta:**
```json
{
"status": "ok",
"message": "Node is alive",
"timestamp": 1712456789
}
```
---
### **1.2 - Readiness Probe**
📌 **Endpoint:** `GET /health/readiness`
- Verifica se o nó está pronto para receber tráfego.
- Avalia conexões com banco de dados, consenso e rede P2P.
📌 **Exemplo de resposta (sucesso):**
```json
{
"status": "ready",
"dependencies": {
"database": "ok",
"consensus": "ok",
"p2p": "ok"
},
"timestamp": 1712456789
}
```
📌 **Exemplo de resposta (falha):**
```json
{
"status": "not_ready",
"dependencies": {
"database": "error",
"consensus": "ok",
"p2p": "ok"
},
"timestamp": 1712456789
}
```
---
### **1.3 - Startup Probe**
📌 **Endpoint:** `GET /health/startup`
- Indica se o nó foi iniciado corretamente.
- Útil para evitar que o Kubernetes mate o pod prematuramente.
📌 **Exemplo de resposta:**
```json
{
"status": "initialized",
"message": "Node startup completed",
"timestamp": 1712456789
}
```
---
## **2️⃣ Configuração no Kubernetes**
📌 **Exemplo de configuração no `deployment.yaml`**:
```yaml
livenessProbe:
httpGet:
path: /health/liveness
port: 8080
initialDelaySeconds: 3
periodSeconds: 5
readinessProbe:
httpGet:
path: /health/readiness
port: 8080
initialDelaySeconds: 10
periodSeconds: 10
startupProbe:
httpGet:
path: /health/startup
port: 8080
failureThreshold: 30
periodSeconds: 10
```
---
📌 **Este documento será atualizado conforme a evolução do serviço.**
🚀 **DEJO Node: Garantindo disponibilidade com healthchecks inteligentes!** 🔥

131
docs/kubernetes.md Normal file
View File

@ -0,0 +1,131 @@
# ☁️ **Deploy no Kubernetes - DEJO Node**
## 📌 **Visão Geral**
Este documento descreve como implantar e gerenciar o **DEJO Node** em um ambiente Kubernetes, garantindo **alta disponibilidade, escalabilidade e monitoramento eficiente**.
---
## **1️⃣ Estrutura de Deploy**
### **1.1 - Componentes no Kubernetes**
- **Deployment**: Gerencia os pods do DEJO Node.
- **Service**: Exposição dos serviços via ClusterIP, NodePort ou LoadBalancer.
- **ConfigMap**: Armazena configurações como variáveis de ambiente.
- **PersistentVolume (PV) e PersistentVolumeClaim (PVC)**: Garante persistência dos dados da blockchain.
- **Horizontal Pod Autoscaler (HPA)**: Ajusta automaticamente a quantidade de pods com base na carga.
---
## **2️⃣ Configuração do Deployment**
📌 **Exemplo de `deployment.yaml`**:
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: dejo-node
spec:
replicas: 3
selector:
matchLabels:
app: dejo-node
template:
metadata:
labels:
app: dejo-node
spec:
containers:
- name: dejo-node
image: dejo/node:latest
ports:
- containerPort: 8545 # Porta RPC
- containerPort: 30303 # Porta P2P
envFrom:
- configMapRef:
name: dejo-config
volumeMounts:
- name: blockchain-storage
mountPath: /data
volumes:
- name: blockchain-storage
persistentVolumeClaim:
claimName: dejo-pvc
```
---
## **3️⃣ Exposição do Serviço**
📌 **Exemplo de `service.yaml`**:
```yaml
apiVersion: v1
kind: Service
metadata:
name: dejo-service
spec:
type: LoadBalancer
ports:
- port: 8545
targetPort: 8545
protocol: TCP
name: rpc
- port: 30303
targetPort: 30303
protocol: TCP
name: p2p
selector:
app: dejo-node
```
---
## **4️⃣ Escalabilidade com HPA**
📌 **Exemplo de `hpa.yaml`**:
```yaml
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: dejo-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: dejo-node
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
```
---
## **5️⃣ Monitoramento e Logging**
### **5.1 - Monitoramento com Prometheus & Grafana**
📌 **Exemplo de configuração do Prometheus**:
```yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: dejo-monitor
spec:
selector:
matchLabels:
app: dejo-node
endpoints:
- port: metrics
interval: 10s
```
### **5.2 - Logging com Fluentd e Elastic Stack**
- Logs coletados com **Fluentd** e enviados para **Elasticsearch**.
- Dashboards criados no **Kibana** para análise em tempo real.
---
📌 **Este documento será atualizado conforme novas estratégias forem implementadas.**
🚀 **DEJO Node: Kubernetes otimizado para escalabilidade e resiliência!** 🔥

91
docs/logging.md Normal file
View File

@ -0,0 +1,91 @@
# 📜 **Logging - DEJO Node**
## 📌 **Visão Geral**
O **DEJO Node** implementa um sistema de logging estruturado para **monitoramento, auditoria e depuração** do funcionamento da blockchain. Utilizamos **Zap (Uber-go)** para logs de alto desempenho e baixa latência.
---
## **1️⃣ Níveis de Log**
Os logs seguem uma hierarquia de severidade:
- **DEBUG** → Informações detalhadas para desenvolvimento.
- **INFO** → Eventos operacionais normais.
- **WARN** → Eventos que podem exigir atenção.
- **ERROR** → Problemas que impactam a funcionalidade, mas não interrompem o serviço.
- **FATAL** → Falhas críticas que resultam no encerramento do serviço.
---
## **2️⃣ Exemplo de Configuração de Logging**
📌 **Trecho do `config.yaml`**:
```yaml
logging:
level: "info"
output: "stdout" # Pode ser "stdout", "file" ou "json"
filePath: "/var/log/dejo-node.log"
format: "json" # Pode ser "json" ou "console"
```
📌 **Trecho de código usando Zap:**
```go
package logger
import (
"go.uber.org/zap"
)
var log *zap.Logger
func InitLogger(level string) {
var err error
cfg := zap.NewProductionConfig()
cfg.Level = zap.NewAtomicLevelAt(parseLogLevel(level))
log, err = cfg.Build()
if err != nil {
panic("Erro ao inicializar logger: " + err.Error())
}
}
func Info(msg string, fields ...zap.Field) {
log.Info(msg, fields...)
}
func Error(msg string, fields ...zap.Field) {
log.Error(msg, fields...)
}
func Fatal(msg string, fields ...zap.Field) {
log.Fatal(msg, fields...)
}
```
---
## **3️⃣ Exemplo de Saída de Log**
📌 **Formato JSON:**
```json
{
"level": "info",
"timestamp": "2025-03-18T12:00:00Z",
"message": "Novo bloco minerado",
"blockHeight": 10234,
"hash": "0xa7b9c..."
}
```
📌 **Formato Console:**
```
[INFO] 2025-03-18T12:00:00Z Novo bloco minerado | blockHeight=10234 hash=0xa7b9c...
```
---
## **4️⃣ Integração com Monitoramento**
- Logs podem ser enviados para **Elastic Stack (Elasticsearch + Kibana)**.
- Suporte a **Fluentd** para roteamento de logs para múltiplos destinos.
- **Prometheus e Grafana** podem coletar métricas baseadas nos logs.
---
📌 **Este documento será atualizado conforme novas funcionalidades forem adicionadas.**
🚀 **DEJO Node: Logging estruturado para máxima observabilidade!** 🔥

90
docs/openapi.yaml Normal file
View File

@ -0,0 +1,90 @@
openapi: 3.0.3
info:
title: DEJO Node API
description: API REST pública do nó da blockchain DEJO
version: 1.0.0
paths:
/health:
get:
summary: Verifica se o serviço está vivo
responses:
'200':
description: OK
/startup:
get:
summary: Verifica se o serviço foi inicializado
responses:
'200':
description: Serviço iniciado
'503':
description: Inicialização incompleta
/ready:
get:
summary: Verifica se o nó está pronto para receber requisições
responses:
'200':
description: Pronto para uso
'503':
description: Store ou Mempool indisponível
/tx:
post:
summary: Envia uma nova transação para a rede
requestBody:
required: true
content:
application/json:
schema:
type: object
properties:
from:
type: string
to:
type: string
value:
type: number
nonce:
type: integer
gas:
type: integer
signature:
type: string
responses:
'200':
description: Transação enviada
/block/{hash}:
get:
summary: Retorna um bloco pelo hash
parameters:
- name: hash
in: path
required: true
schema:
type: string
responses:
'200':
description: Dados do bloco
/tx/{hash}:
get:
summary: Retorna uma transação pelo hash
parameters:
- name: hash
in: path
required: true
schema:
type: string
responses:
'200':
description: Dados da transação
/mempool:
get:
summary: Retorna as transações pendentes
responses:
'200':
description: Lista de transações pendentes

92
docs/planning.md Normal file
View File

@ -0,0 +1,92 @@
# 🏗️ **Plano de Desenvolvimento - DEJO Node**
## 📌 **Visão Geral**
Este documento define o planejamento das tarefas para o desenvolvimento do **DEJO Node**, garantindo um roadmap estruturado para a implementação dos componentes essenciais.
---
## **1️⃣ Criação da Estrutura do Projeto**
- **1.1 - Definir arquitetura de diretórios e módulos** ✅ **[OK]**
- **1.2 - Criar estrutura base do projeto (pastas e arquivos principais)** ✅ **[OK]**
- **1.3 - Configurar Makefile para build, testes e deploy** ✅ **[OK]**
- **1.4 - Criar Dockerfile otimizado para execução do nó** ✅ **[OK]**
- **1.5 - Configurar variáveis de ambiente e arquivos YAML de configuração** ✅ **[OK]**
- **1.6 - Criar script de inicialização do nó (`cmd/main.go`)** ✅ **[OK]**
---
## **2️⃣ Desenvolvimento do Processamento de Transações**
🔹 **Dependência:** Nenhuma (autocontido, pode ser feito primeiro)
- **2.1 - Criar estrutura de transação (remetente, destinatário, assinatura, gas, etc.)** ✅
- **2.2 - Implementar validação de transações** ✅
- **2.3 - Criar sistema de Mempool para transações pendentes** ✅
- **2.4 - Criar mecanismo de inclusão de transações nos blocos** ✅
---
## **3️⃣ Armazenamento e Persistência de Dados**
🔹 **Dependência:** Processamento de Transações finalizado
- **3.1 - Definir banco de dados e estrutura de armazenamento (LevelDB/BadgerDB)** ✅
- **3.2 - Criar estrutura de indexação de blocos e transações** ✅
- **3.3 - Implementar recuperação rápida de estados da blockchain** ✅
---
## **4️⃣ Comunicação P2P entre Nós da Rede**
🔹 **Dependência:** Armazenamento e Transações finalizados
- **4.1 - Definir protocolo de comunicação (libp2p, WebSockets)** ✅
- **4.2 - Implementar descoberta de peers e inicialização da rede** ✅
- **4.3 - Criar sistema de sincronização de blocos entre nós** ✅
- **4.3.1 - Criar estrutura do módulo SyncManager** ✅
- **4.3.2 - Implementar troca de altura (RequestHeight / ResponseHeight)** ✅
- **4.3.3 - Implementar solicitação de blocos ausentes via stream** ✅
- **4.3.4 - Implementar envio de blocos em resposta a solicitações** ✅
- **4.3.5 - Validar blocos recebidos e aplicar no storage local** ✅
- **4.3.6 - Testes automatizados de sincronização entre dois nós** ✅
---
## **5️⃣ Implementação do Mecanismo de Consenso**
🔹 **Dependência:** Comunicação P2P pronta
- **5.1 - Definir e implementar o algoritmo de consenso (PoS ou BFT)** ✅
- **5.2 - Criar mecanismo de finalização de blocos**
- **5.3 - Implementar auditoria e métricas para análise de consenso**
---
## **6️⃣ Desenvolvimento da API RPC/WebSockets**
🔹 **Dependência:** Processamento de Transações e Consenso implementados
- **6.1 - Criar endpoints para consulta de blocos e transações**
- **6.2 - Implementar envio de novas transações via RPC**
- **6.3 - Criar suporte para eventos via WebSockets**
- **6.4 - Adicionar estrutura de resposta JSON detalhada na documentação**
---
## **7️⃣ Implementação da Governança e Staking**
🔹 **Dependência:** Consenso implementado
- **7.1 - Criar sistema de staking para eleição de validadores**
- **7.2 - Implementar contratos de votação on-chain para governança**
- **7.3 - Criar API para registro e consulta de propostas de governança**
---
## **8️⃣ Implementação dos Oráculos e Integração com Dados Externos**
🔹 **Dependência:** API RPC/WebSockets implementada
- **8.1 - Criar integração com provedores de dados externos (ex.: Chainlink, API3)**
- **8.2 - Implementar mecanismo de consenso para validação de dados oraculares**
- **8.3 - Criar sistema de auditoria para dados recebidos de oráculos**
---
## **9️⃣ Sistema de Segurança e Proteção contra Ataques**
🔹 **Dependência:** Consenso implementado
- **9.1 - Implementar proteção contra ataques Sybil e DDoS**
- **9.2 - Criar auditoria e monitoramento de atividades suspeitas**
- **9.3 - Implementar criptografia pós-quântica para segurança futura**
---
📌 **Este documento será atualizado conforme a evolução do projeto.**
🚀 **DEJO Node: Rumo à construção de uma blockchain robusta e escalável!** 🔥

182
docs/roadmap_v1.0.0.md Normal file
View File

@ -0,0 +1,182 @@
## 🧩 Roadmap DEJO Node v1.0.0 — Documentação Técnica Operacional
---
### 🧠 1. Execução de Transações no Bloco
#### **1.1. Estrutura de Contas**
> Implementar estrutura de dados que armazena contas, com saldo e nonce.
- Criar uma struct `Account`:
```go
type Account struct {
Balance uint64
Nonce uint64
}
```
- Criar um `map[string]*Account` que representa o conjunto de contas (`state.accounts`)
- O acesso será via endereço (`string`) como chave
- Contas devem ser inicializadas com `Balance = 0` caso ainda não existam
---
#### **1.2. Aplicar Transações**
> Criar lógica que modifica o estado de contas ao aplicar uma transação do tipo `Transfer`.
- Criar função:
```go
func (s *State) ApplyTransaction(tx *Transaction) error
```
- Verificar se:
- Conta `from` existe
- `from.Balance >= tx.Value`
- `tx.Nonce == from.Nonce`
- Aplicar mudanças:
- Deduzir `Value` da conta `from`
- Acrescentar `Value` à conta `to`
- Incrementar `Nonce` da conta `from`
- Retornar erro se transação for inválida
---
#### **1.3. Executar lote de transações ao final do bloco**
> Aplicar todas as transações do bloco no commit.
- No final do `StartConsensusLoop`, quando o bloco é finalizado:
```go
for _, tx := range block.Txns {
err := state.ApplyTransaction(tx)
if err != nil {
log.Printf("❌ Erro ao aplicar tx: %+v\n", err)
}
}
```
---
### 📚 2. Módulo de Estado (`internal/state`)
#### **2.1. Estrutura do módulo `state`**
> Centralizar toda lógica de mutação de estado (contas, staking, dao).
- Criar `internal/state/state.go`
- Definir `State`:
```go
type State struct {
Accounts map[string]*Account
Staking *staking.StakingStore
DAO *dao.DAOStore
}
```
- Implementar métodos:
- `ApplyTransaction(tx *Transaction) error`
- `GetBalance(address string) uint64`
- `Mint(address string, value uint64)`
- `SaveToDisk(path string)` / `LoadFromDisk(path string)`
---
#### **2.2. Encapsular staking/DAO dentro de State**
> Injetar dependência de staking e DAO no state para simplificar o acesso global.
- Criar `NewState()` que instancia os campos `Accounts`, `Staking` e `DAO`
- Atualizar consenso e handlers para usar `state.Staking` e `state.DAO` em vez de referências diretas
---
### 💸 3. Recompensas e Penalidades
#### **3.1. Recompensa**
> Premiar validadores que participaram corretamente da rodada.
- No commit do bloco:
- Calcular stake total que participou
- Distribuir `totalReward = 5 tokens` proporcionalmente:
```go
reward := (validatorStake * totalReward) / totalStake
state.Mint(validatorID, reward)
```
- Validadores que não participaram não recebem nada
---
#### **3.2. Slash**
> Penalizar validadores que não participaram da rodada.
- Após o commit:
- Identificar validadores ativos que **não** fizeram `PRECOMMIT`
- Deduzir 50 tokens via:
```go
state.accounts[validator].Balance -= 50
```
---
### 🌐 4. API REST Estendida
#### **4.1. `/accounts/{addr}`**
> Obter saldo e informações de conta.
- GET `/accounts/{addr}`
- Retornar:
```json
{
"address": "node-A",
"balance": 950,
"nonce": 3
}
```
---
#### **4.2. `/validators`**
> Obter todos validadores ativos.
- GET `/validators`
- Retornar lista:
```json
[
{ "address": "node-A", "stake": 1000, "status": "online" },
...
]
```
---
#### **4.3. `/dao/status`**
> Visualizar estado atual da DAO.
- GET `/dao/status`
- Retornar:
- Propostas em aberto
- Número de votos
- % de quorum atingido
- Tempo restante
---
### 🧪 5. Testes
#### **5.1. Testes com múltiplos nós**
> Verificar se transações em node-A aparecem em blocos de node-B.
- Lançar `node-A` e `node-B`
- Enviar `POST /transaction` em A
- Verificar `GET /blocks` em B e encontrar a transação
---
#### **5.2. Validação de saldo**
> Testar aplicação de transações.
- Verificar que saldo de `from` diminui
- Verificar que saldo de `to` aumenta
- Verificar que `Nonce` incrementa
---
#### **5.3. Testes de recompensas e penalidades**
> Validar que rewards/slash funcionam corretamente.
- Propor bloco com `node-A`, verificar +5 tokens
- Omissão de `PRECOMMIT` de `node-B`, verificar -50 tokens

56
docs/tasks_todo.md Normal file
View File

@ -0,0 +1,56 @@
# ✅ Checklist Detalhado de Tarefas Pendentes - DEJO Node
Este arquivo será utilizado para acompanhar o progresso detalhado das pendências restantes até a finalização da primeira versão completa do `dejo_node`.
---
## 🧪 Revisão e Correção de Funcionalidades Existentes
- [ ] Verificar se todos os pacotes possuem `go build` e `go test` funcionando
- [ ] Consolidar estrutura de `Block` em `blockchain/block.go`
- [ ] Validar `finality.go` (consensus/simple)
- [ ] Verificar uso correto de `storage.Storage`
- [ ] Confirmar estrutura correta do bloco (sem campos desconhecidos)
---
## 🔧 Healthcheck
- [ ] Criar pacote `internal/healthcheck`
- [ ] Implementar endpoint `/live`
- [ ] Implementar endpoint `/ready`
- [ ] Implementar endpoint `/startup`
- [ ] Incluir integração com `main.go`
---
## 🧠 Mempool
- [ ] Validar se `mempool` realmente existe ou precisa ser recriado
- [ ] Se necessário, recriar:
- [ ] Estrutura de pool de transações pendentes
- [ ] Métodos para adicionar, validar e expurgar transações
---
## 🔌 RPC/WebSockets
- [ ] Criar pacote `internal/rpc`
- [ ] Endpoint para consulta de bloco por hash
- [ ] Endpoint para envio de nova transação
- [ ] Suporte WebSocket para eventos em tempo real
---
## 🔐 Security
- [ ] Definir escopo inicial de `security`
- [ ] Criar proteção básica contra flood (ex.: IP rate limit)
- [ ] Adicionar logs de requisições suspeitas
---
## 📄 Documentação e Planejamento
- [ ] Atualizar `docs/planning.md` com estado real das fases
- [ ] Atualizar `/docs/tasks_todo.md` a cada entrega