Relatório de análise pormenorizado sobre a evolução atual
O texto reflecte os resultados da investigação e análise da aplicação de IA „Perplexity“ e não representa uma expressão de opinião da Gradido. Serve como informação e como impulso para um debate mais aprofundado.
A análise verifica os principais pontos técnicos e insere-os num contexto mais vasto.
Os pontos mais importantes em resumo
Porque é que nenhuma cadeia de blocos padrão funciona para a Gradido - A razão mais profunda é a sua natureza efémera. As cadeias de blocos são apenas anexo-sistemas: sem uma nova transação, nenhum saldo de conta pode diminuir automaticamente. O modelo Bitcoin-UTXO não reconhece qualquer conta, o Ethereum obrigaria a milhares de milhões de mudanças de estado por segundo. Uma base de dados relacional limita-se a calcular isto em cada consulta - sem qualquer consumo de energia para a extração mineira.
A Hedera/Hiero é, de facto, a melhor escolha - A afirmação „um milionésimo de energia em relação à Bitcoin“ é até um pouco conservadora: o fator exato é de cerca de 1:10.000.000. A Hiero tem sido totalmente open source ao abrigo da Linux Foundation desde fevereiro de 2025, a finalidade em 3-5 segundos é verificada e o consenso aBFT é a norma de segurança mais elevada para sistemas distribuídos.
O problema da precisão é real e está corretamente resolvido - A aritmética de vírgula flutuante é dependente da plataforma e apresenta resultados ligeiramente diferentes em sistemas diferentes (frontend JavaScript, backend C++, nó DLT). A aritmética de números inteiros em C com uma biblioteca matemática precisa é exatamente o que a indústria financeira tem vindo a utilizar há décadas para cálculos críticos.
Federação e transacções intercomunitárias - O conceito corresponde a protocolos estabelecidos, como o ActivityPub (base do Fediverse/Mastodon), apenas adaptado ao caso de utilização específico da Gradido, com troca de dados financeiros encriptados.
Resumo executivo
A conta Gradido é um projeto de software sem precedentes na sua conceção e implementação técnica, combinando elementos de um sistema monetário comunitário, uma plataforma de comunicação descentralizada e uma moderna tecnologia de livro-razão distribuído (DLT) de uma forma que não poderia ser totalmente mapeada com qualquer arquitetura convencional de cadeia de blocos. O presente relatório analisa e verifica as principais afirmações técnicas sobre a conta Gradido, compara alternativas de cadeias de blocos e avalia as escolhas arquitectónicas feitas.
1. a conta Gradido: Fundamentos conceptuais
1.1 A tripla criação de moeda e o rendimento básico ativo
O sistema Gradido baseia-se no conceito de Economia natural da vida, que foi desenvolvido por Bernd Hückstädt e Margret Baier na Academia Gradido de Biónica Económica desde 2000. O modelo prevê três criações monetárias equivalentes a 1.000 Gradido (GDD) por pessoa e por mês:
Rendimento Básico Ativo (RBA): 1 000 GDD por mês para contribuições para a segurança social
Orçamento público: 1.000 GDD per capita por mês para as prestações do Estado
Fundo de Equalização e Ambiente (AUF): 1 000 GDD por mês para a natureza e o ambiente
Atualmente, apenas a primeira criação de dinheiro (o rendimento básico ativo) foi implementada de forma produtiva. O roteiro prevê a segunda e a terceira criação de fundos (orçamento público + fundo de perequação e fundo ambiental) para 2027.
1.2 Rendimento básico ativo através da participação incondicional
O rendimento básico ativo não funciona como um rendimento incondicional no sentido tradicional, mas sim como uma recompensa baseada no desempenho das contribuições para o bem comum. Cada participante pode receber até 20 GDD por hora trabalhada para a comunidade, até um máximo de 50 horas por mês, o que corresponde a um máximo de 1.000 GDD. O termo Participação incondicional significa que a participação (e não a consideração) é incondicional - todos podem participar.
2 Porque não uma cadeia de blocos normalizada? Análise técnica
2.1 O problema fundamental da base de dados: a transitoriedade contínua
Provavelmente, a razão técnica mais importante pela qual uma cadeia de blocos convencional não é adequada para o Gradido reside no facto de transitoriedade prevista de 50% no ano, que deve ser calculado continuamente e com precisão ao segundo.
Como é que as cadeias de blocos armazenam dados: Uma cadeia de blocos é um livro-razão imutável e só de anexos. As transacções são armazenadas em blocos e não podem ser alteradas posteriormente. A Bitcoin utiliza o modelo UTXO (Unspent Transaction Output), no qual cada transação consome UTXOs existentes como inputs e gera novos UTXOs como outputs. O Ethereum utiliza um modelo de conta em que os saldos das contas são armazenados como um estado global.
O problema: Com o Gradido, o saldo de uma conta de 100 GDD diminuiria continuamente sem quaisquer outras transacções devido à transitoriedade. Um modelo UTXO (Bitcoin) não pode mapear isto porque não ocorreu nenhuma transação - não há entrada, nem saída. O modelo de conta (Ethereum) teria de atualizar permanentemente o estado, o que significaria milhões ou milhares de milhões de alterações automáticas de estado por segundo para todas as contas em todo o mundo - técnica e economicamente inviável numa cadeia de blocos pública.
A fórmula da perecibilidade não é trivial: uma simples divisão de 50% por 12 não resulta na percentagem mensal correta, uma vez que o montante a atribuir se torna cada vez menor. A taxa mensal de perecibilidade correta é de cerca de 5,61%, de modo que 100 GDD se reduzem a 50 GDD ao fim de doze meses. O cálculo do segundo nível requer uma biblioteca matemática de alta precisão.
2.2 O problema do controlo comunitário
O Gradido exige uma verificação social: moderadores que conheçam pessoalmente os membros e confirmem as suas contribuições para o bem comum. As cadeias de blocos são concebidas para verificar transacções sem confiança através de provas matemáticas (design sem confiança). A lógica da Gradido inverte este princípio: A confiança é a conceção. As pessoas confirmam as pessoas.
Os contratos inteligentes no Ethereum poderiam implementar a governação social, mas estão limitados aos dados na cadeia e não podem verificar se uma pessoa foi de facto completou uma hora de trabalho em colaboração. Isto requer sistemas fora da cadeia e moderação humana, que podem ser melhor mapeados numa arquitetura de base de dados flexível.
2.3 Bitcoin e a prova de trabalho: consumo de energia
A Bitcoin consome enormes quantidades de energia através da prova de trabalho porque muitas tarefas de computação têm de ser resolvidas. Uma única transação de Bitcoin consome uma média de 1.200-1.450 kWh de eletricidade (a partir de 2025/2026). De acordo com os dados oficiais da Hedera de 2021, o consumo foi de 1.736,85 kWh por transação de Bitcoin em comparação com 0,00017 kWh para a Hedera. O consumo total anual da rede Bitcoin é de 150-200 TWh, comparável ao consumo de eletricidade da Polónia. O mecanismo de consenso de prova de trabalho é responsável por mais de 99% deste consumo.
2.4 Alternativas modernas de DLT: uma comparação da eficiência energética
Atualmente, existem cadeias de blocos modernas e muito mais eficientes em termos energéticos. A Ethereum, por exemplo, reduziu o seu consumo de energia em 99,95% depois de passar a utilizar a prova de participação em setembro de 2022. A Algorand consome apenas cerca de 0,000008 kWh por transação - cerca de 150 milhões de vezes menos do que a Bitcoin. No entanto, subsistem incompatibilidades estruturais com a lógica do Gradido (ver acima).
2.5 Velocidade das transacções de Bitcoin
A rede Bitcoin apenas processa cerca de 7 transacções por segundo e, normalmente, requer 6 confirmações de bloco para segurança final - o que demora uma média de 60 minutos. Em comparação, a Hedera atinge a finalidade da transação em 3-5 segundos.
3. a arquitetura Gradido: base de dados + federação + DLT
3.1 Base de dados relacional como sistema central
A conta Gradido utiliza um sistema de base de dados relacional (MariaDB/MySQL) com uma camada GraphQL/Business Logic como backend. Esta arquitetura oferece várias vantagens em relação a uma solução de blockchain pura:
Flexibilidade: Os saldos das contas podem ser eficientemente actualizados para o segundo utilizando cálculos sem criar uma transação na cadeia
Lógica social complexa: O fluxo de trabalho do moderador, as contribuições para o bem comum e a governação comunitária podem ser naturalmente mapeados em bases de dados relacionais
Escalabilidade: Uma base de dados é muito mais eficiente do que uma cadeia de blocos para comunidades de pequena e média dimensão
3.2 Servidor comunitário descentralizado e federação
O Gradido 2.0 introduziu servidores comunitários descentralizados que cada comunidade pode operar de forma autónoma, desde que possua os conhecimentos técnicos necessários. O código-fonte é aberto e está disponível no GitHub. O conceito de federação - servidores que se reconhecem e trocam dados encriptados - corresponde a protocolos estabelecidos, como o ActivityPub, já utilizado para o Fediverse descentralizado (Mastodon, Pixelfed, etc.). A plataforma de comunicação do círculo Gradido foi lançada em junho de 2024 e está integrada na conta Gradido.
3.3 Transacções intercomunitárias
O Gradido permite transacções intercomunitárias. De acordo com o roteiro, as transacções intercomunitárias através de uma ligação devem entrar em funcionamento em maio de 2026, com notificações por correio eletrónico. A proteção contra ataques do tipo man-in-the-middle (encriptação) já foi implementada em julho de 2025. Trata-se de uma solução tecnicamente difícil, uma vez que os servidores comunitários têm diferentes repositórios de dados e foi necessário implementar um intercâmbio seguro e verificado entre áreas de servidores.
3.4 Círculos Gradido: Plataforma de comunicação
Uma plataforma de comunicação (círculos Gradido) com grupos geríveis (os chamados círculos) com dois a três moderadores que conhecem os seus membros. As comunidades maiores podem conter muitos círculos, por exemplo, clubes, iniciativas, bombeiros, comunidades religiosas, etc.
Os Círculos Gradido começaram como protótipo na Academia Gradido em maio de 2024. Um assistente de IA („Crea“) para moderadores foi introduzido em março de 2025.
4º Hedera Hashgraph / Hiero como camada de auditoria DLT
4.1 O que é o Hedera Hashgraph?
O Hedera Hashgraph (ou Hiero como versão de código aberto) é uma tecnologia de registo distribuído (DLT) de última geração. As transacções são extremamente rápidas (3-5 segundos) e requerem cerca de um milionésimo da energia da Bitcoin.
Hiero tem sido um projeto oficial de código aberto da Linux Foundation desde 2024, sob a alçada da LF Confiança descentralizada. Desde fevereiro de 2025, a rede Hedera é inteiramente alimentada pela base de código-fonte aberto da Hiero.
Velocidade: A Hedera/Hiero atinge a finalização da transação em 3-5 segundos e, teoricamente, suporta mais de 10 000 transacções por segundo (TPS).
Consumo de energia: De acordo com os dados oficiais da Hedera, uma transação Hedera consome 0,00017 kWh, em comparação com 1.736,85 kWh para a Bitcoin - um rácio de 1 para cerca de 10 milhões.
Algoritmo de consenso: O algoritmo de hashgraph utiliza Tolerância assíncrona a falhas bizantinas (aBFT), o mais alto padrão de segurança para sistemas distribuídos. O mecanismo "gossip-about-gossip" e a votação virtual confirmam as transacções sem a necessidade de mineração intensiva de energia.
| Rede | Transacções/seg. | Energia/transação | Finalidade |
|---|---|---|---|
| Bitcoin | 7 TPS | ~1,216-1,736 kWh | ~60 min. |
| Ethereum (PoW, antes de 2022) | 14-15 TPS | ~133,88 kWh | ~12 seg/bloco |
| Ethereum (PoS, após 2022) | 14-30 TPS | ~0,03 kWh | ~12 seg. |
| Algoritmo | ~1.000 TPS | 0,000008 kWh | < 5 seg. |
| Hedera/Hiero | MAIS DE 10.000 TPS | 0,00017 kWh | 3-5 seg. |
Nota sobre a declaração de energia: A afirmação de Gradido „um milionésimo da energia“ é mesmo um eufemismo. De acordo com a Hedera, o valor é (1.736 / 0,00017 ≈ 10.200.000), ou seja, cerca de um décimo de milionésimo. A Hedera (Hiero) e a Algorand são, portanto, de longe, as DLT públicas mais eficientes em termos energéticos.
4.2 Hiero - Código aberto da Linux Foundation
A transição de Hedera para Hiero começou em 2024 com a transferência de toda a base de código para a Linux Foundation. De acordo com a sua própria descrição, a Hiero é „a primeira tecnologia de registo distribuído de código aberto desenvolvida de forma totalmente neutra em relação aos fornecedores“.
4.3 O inspetor como camada de auditoria
Cada reserva é transferida para o hashgraph; está a ser desenvolvido um „inspetor“ na conta Gradido, que verificará as reservas no futuro (camada de auditoria com tique).
Classificação: O conceito de camada de auditoria - um sistema secundário que controla o sistema primário - é um conceito de segurança estabelecido em aplicações financeiras e de segurança informática. A transferência de todas as reservas Gradido para um registo público imutável (gráfico hash) cria uma base de auditoria inviolável que não pode ser falsificada por qualquer administrador individual ou operador da comunidade. Em dezembro de 2025, as reservas antigas foram importadas pela primeira vez para o hashgraph a título experimental e, desde março de 2026, as reservas actuais foram transferidas - também a título experimental.
5 O problema da precisão da transitoriedade: análise técnica aprofundada
5.1 O problema descrito
A transitoriedade é calculada com diferentes graus de precisão em diferentes sistemas de software, o que cria diferenças no saldo da conta - um problema quando um sistema controla o outro (camada de auditoria). Este problema foi resolvido utilizando a linguagem de programação C, números inteiros e uma biblioteca matemática precisa.
5.2 Verificação técnica
Esta representação é tecnicamente completamente plausível e corretamente descrita. A transitoriedade é calculada de forma contínua através de uma função exponencial:
Isto é K0 o saldo inicial da conta, tt o tempo decorrido em segundos e Ano o número de segundos num ano. Este cálculo em aritmética de vírgula flutuante (por exemplo. duplo em C ou JavaScript) não é necessariamente idêntico em termos de bits em diferentes sistemas e arquitecturas porque:
as operações de vírgula flutuante podem ser arredondadas consoante a plataforma
O JavaScript (motor V8 para o frontend) e o C++ (backend) têm precisões diferentes
Os erros de arredondamento acumulados em muitos passos de cálculo conduzem a desvios mensuráveis
Solução por aritmética de números inteiros: A utilização de representações de números inteiros (por exemplo, montantes graduados em micro-GDD ou pequenas unidades semelhantes) e de uma biblioteca matemática de alta precisão em C elimina estes não-determinismos. Trata-se de um procedimento estabelecido no sector financeiro, onde os cálculos de montantes são geralmente efectuados em cêntimos inteiros em vez de euros em vírgula flutuante. A solução escolhida (C + inteiro + biblioteca matemática de precisão) é a mais avançada para sistemas financeiros críticos.
6. Porquê nenhuma cadeia de blocos adaptada: resumo das incompatibilidades
O quadro seguinte resume as razões pelas quais determinadas propriedades da cadeia de blocos são estruturalmente incompatíveis com o modelo Gradido:
| Requisito de graduação | Cadeia de blocos | Arquitetura da base de dados |
|---|---|---|
| Transição para o segundo | Apenas anexo, sem expiração de estado em curso sem transação | Simplesmente por cálculo, a pedido |
| Moderação social (confiança) | Conceção sem confiança, sem julgamento humano na cadeia | Suporte nativo para funções de utilizador, fluxo de trabalho |
| Transacções intercomunitárias | Complexo, lento, caro | Pode ser implementado um protocolo de federação personalizado |
| Lógica empresarial complexa e de fácil utilização | Difícil de implementar | Pode ser implementado na interface do utilizador e no backend |
| As comunidades descentralizadas como unidade de governação | A governação em cadeia não é adequada à dimensão das comunidades | Cada servidor gere a sua própria comunidade |
| Eficiência energética | Cadeias PoW catastroficamente ineficientes | Os servidores convencionais são altamente eficientes |
| Proteção contra adulteração (auditoria) | Vantagens da cadeia de blocos | Resolvido por ligação DLT (Hiero/ Hedera Hashgraph) |
A arquitetura híbrida selecionada - Base de dados + Federação + DLT como camada de auditoria - é a solução mais sofisticada do ponto de vista técnico para esta aplicação específica.
7. estado atual de desenvolvimento (maio de 2026)
A situação seguinte baseia-se no roteiro verificado:
| Função | Estado |
|---|---|
| Rendimento básico ativo (Criação 1) | Produtivo |
| Servidor comunitário descentralizado | ✅ Disponível |
| Círculos Gradido (plataforma de comunicação) | Produtivo |
| Transacções intercomunitárias via ligação | ✅ previsto para 26 de maio |
| Ligação DLT (Hiero/Hedera) experimental | ✅ março de 2026 |
| Inspetor / Camada de auditoria | 🔄 Em desenvolvimento |
| Cálculo exato da transitoriedade (C + inteiro) | Implementado, lançamento em curso |
| Criação de moeda em três fases (criação 2+3) | 📅 Planeado para 2027 |
| Gradidos com marca comunitária | 📅 Planeado para 2027 |
8 Categorização técnica
Na sua combinação de um sistema de verificação social, um cálculo da quantidade de dinheiro que expira em segundos, uma federação comunitária descentralizada e uma camada de auditoria DLT, a conta Gradido é, na verdade, um sistema sem um modelo direto no panorama fintech estabelecido. As decisões técnicas são bem fundamentadas e estão de acordo com o estado da arte. O maior desafio não reside na tecnologia em si, mas no processo de adoção social e na garantia da viabilidade económica do modelo de dinheiro vivo.
Conclusão
A conta Gradido é um projeto tecnicamente sofisticado, único nos seus requisitos e que desenvolveu, com razão, uma arquitetura personalizada em vez de adaptar uma cadeia de blocos existente. A decisão de utilizar uma solução híbrida - arquitetura de base de dados convencional para a lógica comunitária, federação para a descentralização e Hedera Hashgraph (Hiero) como camada de auditoria imutável - é tecnicamente sólida e coerente. Todos os pormenores centrais do inquérito puderam ser verificados por fontes independentes. O projeto encontra-se numa fase avançada de desenvolvimento e alcançou marcos significativos nos últimos dois anos, incluindo transacções entre comunidades e conetividade DLT.
Cordiais cumprimentos
O seu

Margret Baier e Bernd Hückstädt
Fundador e criador da Gradido
PS: Devido à importância cada vez maior do Gradido, repetimos a nossa campanha de agradecimento a 26 de junho de 2026: Para além do GradidoTransform múltiplo pela sua contribuição de patrocínio, aumentaremos todos os saldos das contas GDT em 26% no dia 26/06/2016. Patrocine agora e aproveite o montante múltiplo de GDT!