Gradido-konto: Teknisk arkitektur, særlige funktioner og aktuel status

Sammenfatning

Gradido-kontoen er et hidtil uset softwareprojekt i sin udformning og tekniske implementering, der kombinerer elementer af et fælles valutasystem, en decentral kommunikationsplatform og moderne distribueret hovedbogsteknologi (DLT) på en måde, der ikke kan kortlægges fuldt ud med nogen konventionel blockchain-arkitektur. Denne rapport analyserer og verificerer de vigtigste tekniske påstande om Gradido-kontoen, sammenligner blockchain-alternativer og evaluerer de arkitektoniske valg, der er truffet.

1. Gradido-kontoen: Grundlæggende begreber

1.1 Den tredobbelte pengeskabelse og den aktive basisindkomst

Gradido-systemet er baseret på konceptet Livets naturlige økonomi, som er blevet udviklet af Bernd Hückstädt og Margret Baier på Gradido Academy for Economic Bionics siden 2000. Modellen giver mulighed for tre tilsvarende pengeskabelser på 1.000 Gradido (GDD) pr. person pr. måned:

1. Aktiv basisindkomst (AGE): 1.000 GDD pr. måned til bidrag til offentlig velfærd

2. Offentligt budget: 1.000 GDD pr. indbygger pr. måned til offentlige ydelser

3. Udlignings- og miljøfonden (AUF): 1.000 GDD pr. måned til natur og miljø

I øjeblikket er kun den første pengeskabelse (den aktive basisindkomst) blevet produktivt implementeret. Køreplanen forudser den anden og tredje pengeskabelse (offentligt budget + udlignings- og miljøfond) i 2027. 

1.2 Aktiv basisindkomst gennem ubetinget deltagelse

Den aktive basisindkomst fungerer ikke som en ubetinget indkomst i traditionel forstand, men snarere som en præstationsbaseret belønning for bidrag til det fælles bedste. Hver deltager kan modtage op til 20 GDD pr. arbejdstime for fællesskabet, op til maksimalt 50 timer om måneden, hvilket svarer til maksimalt 1.000 GDD. Begrebet Ubetinget deltagelse betyder, at deltagelse (ikke hensyntagen) er ubetinget - alle kan deltage.

2 Hvorfor ikke en standard blockchain? Teknisk analyse

2.1 Det grundlæggende databaseproblem: Kontinuerlig foranderlighed

Den vigtigste tekniske grund til, at en konventionel blockchain er uegnet til Gradido, ligger nok i planlagt overgang til 50% i år, som skal beregnes kontinuerligt og præcist på sekundet.

Hvordan blockchains gemmer data: En blockchain er en uforanderlig hovedbog, der kun kan tilføjes. Transaktioner gemmes i blokke og kan ikke ændres efterfølgende. Bitcoin bruger UTXO-modellen (Unspent Transaction Output), hvor hver transaktion bruger eksisterende UTXO'er som input og genererer nye som output. Ethereum bruger en kontomodel, hvor kontosaldi gemmes som en global tilstand.

Det er problemet: Med Gradido vil en kontosaldo på 100 GDD løbende falde uden yderligere transaktioner på grund af forgængelighed. En UTXO-model (Bitcoin) kan ikke kortlægge dette, fordi der ikke har fundet nogen transaktion sted - der er intet input, intet output. Kontomodellen (Ethereum) ville være nødt til at opdatere tilstanden permanent, hvilket ville betyde millioner eller milliarder af automatiske tilstandsændringer pr. sekund for alle konti i hele verden - teknisk og økonomisk uigennemførligt i en offentlig blockchain.

Formlen for letfordærvelighed er ikke triviel: En simpel division af 50% med 12 resulterer ikke i den korrekte månedlige procentdel, da den mængde, der skal fordeles, bliver mindre og mindre. Den korrekte månedlige letfordærvelige sats er ca. 5,61%, så 100 GDD falder til 50 GDD efter tolv måneder. Beregningen på andet niveau kræver et matematisk bibliotek med høj præcision.

2.2 Problemet med samfundsverifikation

Gradido kræver social verifikation: Moderatorer, der kender medlemmerne personligt og bekræfter deres bidrag til det fælles bedste. Blockchains er designet til at verificere transaktioner uden tillid gennem matematisk bevis (trustless design). Gradidos logik vender op og ned på dette princip: Tillid er designet. Mennesker bekræfter mennesker.

Smarte kontrakter på Ethereum kan implementere social styring, men de er begrænset til data på kæden og kan ikke verificere, om en person er blevet faktisk en times fælles arbejde. Det kræver systemer uden for kæden og menneskelig moderation, som bedre kan kortlægges i en fleksibel databasearkitektur.

2.3 Bitcoin og proof-of-work: energiforbrug

Bitcoin bruger enorme mængder energi gennem proof-of-work, fordi mange computeropgaver skal løses. En enkelt Bitcoin-transaktion bruger i gennemsnit 1.200-1.450 kWh elektricitet (fra 2025/2026). Ifølge officielle Hedera-data fra 2021 var forbruget 1.736,85 kWh pr. bitcointransaktion sammenlignet med 0,00017 kWh for Hedera. Det samlede årlige Bitcoin-netværksforbrug er 150-200 TWh, hvilket kan sammenlignes med Polens elforbrug. Proof-of-work-konsensusmekanismen står for mere end 99% af dette forbrug.

2.4 Moderne DLT-alternativer: en sammenligning af energieffektivitet

Der findes nu moderne, meget mere energieffektive blockchains. Ethereum reducerede f.eks. sit energiforbrug med 99,95% efter at have skiftet til proof-of-stake i september 2022. Algorand bruger kun omkring 0,000008 kWh pr. transaktion - omkring 150 millioner gange mindre end Bitcoin. Ikke desto mindre er der stadig strukturelle uoverensstemmelser med Gradido-logikken (se ovenfor).

2.5 Bitcoin-transaktionshastighed

Bitcoin-netværket behandler kun omkring 7 transaktioner i sekundet og kræver typisk 6 blokbekræftelser for endelig sikkerhed - det tager i gennemsnit 60 minutter. Til sammenligning opnår Hedera en endelig transaktion på 3-5 sekunder.

3. Gradido-arkitekturen: database + føderation + DLT

3.1 Relationel database som kernesystem

Gradido-kontoen bruger et relationelt databasesystem (MariaDB/MySQL) med et GraphQL/Business Logic-lag som backend. Denne arkitektur giver flere fordele i forhold til en ren blockchain-løsning:

• Fleksibilitet: Kontosaldoer kan effektivt opdateres til den anden ved hjælp af beregninger uden at generere en on-chain-transaktion

• Kompleks social logik: Moderatorens arbejdsgang, bidrag til det fælles bedste og samfundsstyring kan naturligvis kortlægges i relationsdatabaser

• Skalerbarhed: En database er meget mere effektiv end en blockchain for små og mellemstore samfund

3.2 Decentraliseret community server og føderation

Gradido 2.0 introducerede decentrale community-servere, som hvert community kan drive selvstændigt, forudsat at de har den tekniske viden. Kildekoden er open source og tilgængelig på GitHub. Konceptet med føderation - servere, der genkender hinanden og udveksler krypterede data - svarer til etablerede protokoller som ActivityPub, der allerede bruges til det decentrale Fediverse (Mastodon, Pixelfed osv.). Kommunikationsplatformen Gradido circle blev lanceret i juni 2024 og er integreret i Gradido-kontoen.

3.3 Transaktioner på tværs af samfund

Gradido muliggør transaktioner på tværs af lokalsamfund. Ifølge køreplanen skal transaktioner på tværs af fællesskaber via link gå i luften i maj 2026 med e-mailnotifikationer. Beskyttelse mod man-in-the-middle-angreb (kryptering) blev allerede implementeret i juli 2025. Dette er en teknisk udfordrende løsning, da community-servere har forskellige datalagre, og der skulle implementeres en sikker, verificeret udveksling på tværs af serverområder.

3.4 Gradido-cirkler: Kommunikationsplatform

En kommunikationsplatform (Gradido-cirkler) med overskuelige grupper (såkaldte cirkler) med to til tre moderatorer, der kender deres medlemmer. Større fællesskaber kan indeholde mange cirkler, f.eks. klubber, initiativer, brandvæsener, kirkesamfund osv.

Gradido Circles startede som en prototype i Gradido Academy i maj 2024. En AI-assistent („Crea“) til moderatorer blev introduceret i marts 2025.

4. Hedera Hashgraph / Hiero som DLT-auditlag

4.1 Hvad er Hedera Hashgraph?

Hedera Hashgraph (eller Hiero som open source-version) er en distribueret hovedbogsteknologi (DLT) af den seneste generation. Transaktioner er ekstremt hurtige (3-5 sekunder) og kræver omkring en milliontedel af Bitcoins energi.

• Hiero har været et officielt open source-projekt under Linux Foundation siden 2024 under paraplyen LF Decentraliseret tillid. Siden februar 2025 har Hedera-netværket udelukkende været drevet af Hieros open source-kodebase.

• Hastighed: Hedera/Hiero opnår transaktionsafslutning på 3-5 sekunder og understøtter teoretisk over 10.000 transaktioner pr. sekund (TPS).

• Energiforbrug: Ifølge officielle Hedera-data bruger en Hedera-transaktion 0,00017 kWh sammenlignet med 1.736,85 kWh for Bitcoin - et forhold på 1 til ca. 10 millioner.

• Konsensusalgoritme: Hashgraph-algoritmen bruger Asynkron byzantinsk fejltolerance (aBFT), den højeste sikkerhedsstandard for distribuerede systemer. Gossip-about-gossip-mekanismen og virtuel afstemning bekræfter transaktioner uden energikrævende minedrift.

Bemærk om energiregnskabet: Gradidos udsagn „en milliontedel af energien“ er endda en underdrivelse. Ifølge Hedera er tallet (1.736 / 0,00017 ≈ 10.200.000), dvs. omkring en ti-milliontedel. Hedera (Hiero) og Algorand er derfor langt de mest energieffektive offentlige DLT'er.

4.2 Hiero - Open Source under Linux Foundation

Overgangen fra Hedera til Hiero begyndte i 2024 med overførslen af hele kodebasen til Linux Foundation. Ifølge sin egen beskrivelse er Hiero „den første open source-distribuerede hovedbogsteknologi, der er udviklet på en fuldstændig leverandørneutral måde“. 

4.3 Inspektøren som revisionslag

Hver booking overføres til hashgrafen; en „inspektør“ i Gradido-kontoen er under udvikling og vil kontrollere bookinger i fremtiden (revisionslag med kryds).

Klassificering: Begrebet revisionslag - et sekundært system, der kontrollerer det primære - er et etableret sikkerhedskoncept inden for it-sikkerhed og finansielle applikationer. Overførslen af hver Gradido-booking til en uforanderlig offentlig hovedbog (hashgraf) skaber en manipulationsresistent revisionsbase, der ikke kan forfalskes af nogen individuel administrator eller community-operatør. I december 2025 blev de gamle bookinger første gang importeret til hashgrafen på forsøgsbasis, og siden marts 2026 er de nuværende bookinger blevet overført - også på forsøgsbasis.

5 Præcisionsproblemet med flygtighed: teknisk dybdeanalyse

5.1 Det beskrevne problem

Transiens beregnes med varierende grad af nøjagtighed i forskellige softwaresystemer, hvilket skaber forskelle i kontosaldoen - et problem, når det ene system kontrollerer det andet (revisionslag). Dette blev løst ved hjælp af programmeringssproget C, heltal og et præcist matematisk bibliotek.

5.2 Teknisk verifikation

Denne repræsentation er teknisk set fuldstændig plausibel og korrekt beskrevet. Transiensen beregnes kontinuerligt ved hjælp af en eksponentiel funktion:

Dette er K0​ den oprindelige kontosaldo, $t$ den forløbne tid i sekunder og TYår antallet af sekunder på et år. Denne beregning i flydende punkt-aritmetik (f.eks. dobbelt i C eller JavaScript) er ikke nødvendigvis bit-identisk på forskellige systemer og arkitekturer, fordi:

• operationer med flydende komma kan afrundes afhængigt af platformen

• JavaScript (V8-motor til frontend) og C++ (backend) har forskellig nøjagtighed

• Kumulative afrundingsfejl over mange beregningstrin fører til målbare afvigelser

Løsning ved hjælp af heltalsaritmetik: Brugen af heltalsrepræsentationer (f.eks. gradidobeløb i mikro-GDD eller lignende små enheder) og et matematikbibliotek med høj præcision i C eliminerer disse ikke-determinismer. Dette er en etableret procedure i den finansielle sektor, hvor beløbsberegninger generelt udføres i heltallige cent i stedet for flydende euro. Den valgte løsning (C + heltal + præcist matematikbibliotek) er state of the art for kritiske finansielle systemer.

6. Hvorfor ingen tilpasset blockchain: oversigt over inkompatibiliteter

Følgende tabel opsummerer, hvorfor specifikke blockchain-egenskaber er strukturelt uforenelige med Gradido-modellen:

Den valgte hybridarkitektur Database + føderation + DLT som revisionslag - er den mest sofistikerede løsning til denne specifikke applikation ud fra et teknisk synspunkt.

7. Nuværende udviklingsstatus (maj 2026)

Følgende status er baseret på den verificerede køreplan:

8 Teknisk kategorisering

Med sin kombination af et socialt verifikationssystem, en beregning af pengebeløbet, der udløber inden for få sekunder, en decentraliseret fællesskabsføderation og et DLT-revisionslag er Gradido-kontoen faktisk et system uden en direkte rollemodel i det etablerede fintech-landskab. De tekniske beslutninger er velbegrundede og i tråd med den nyeste teknologi. Den største udfordring ligger ikke i selve teknologien, men i den sociale adoptionsproces og i at sikre den økonomiske levedygtighed af modellen med levende penge.

Konklusion

Gradido-kontoen er et teknisk sofistikeret projekt, der er unikt i sine krav, og som med rette har udviklet en skræddersyet arkitektur i stedet for at tilpasse en eksisterende blockchain. Beslutningen om at bruge en hybridløsning - konventionel databasearkitektur til fællesskabslogikken, føderation til decentralisering og Hedera Hashgraph (Hiero) som et uforanderligt revisionslag - er teknisk sund og konsekvent. Alle centrale detaljer i forespørgslen kunne verificeres af uafhængige kilder. Projektet er på et avanceret udviklingsstadie og har nået betydelige milepæle i løbet af de sidste to år, herunder transaktioner på tværs af fællesskaber og DLT-forbindelse.