docs: update Potatium v0.6 architecture and PoP research
This commit is contained in:
1 parent
75df8a5c0d
commit
862ccf1d03
34 files changed
+3257
-18
No files matched your search
+17
-1
@@ -51,7 +51,7 @@ Die abgelehnte Idee „Gebühr pro aktuellem Wallet-Guthaben“ lässt sich durc
|
||||
|
||||
`Fenster 2 = Basisbetrag2 + Progressive(90-Tage-Ertrag)`; `Fenster 3 = Basisbetrag3 + stärkerer progressiver Anteil`. **Alle exakten Prozentsätze, Stufen, Beträge und Rundungsregeln sind offen**. Bei Erfolg in Fenster 1 oder 2 fallen spätere Gebühren nicht an; Zusatzgebühren im Misserfolgsfall werden nicht erstattet.
|
||||
|
||||
**Zusatzgebühren werden verbrannt**, normale Überweisungsgebühren sollen die Validatoren finanzieren (Aufteilungsregeln noch offen). Mining funktioniert kostenlos mit 0 PTM über Fenster 1. Die Wallet gibt kostenpflichtige Fenster einzeln oder per eng begrenzter, widerrufbarer Autorisierung frei. Der Miner erhält niemals Browser-Wallet-Secrets.
|
||||
**PoP-Fenster-/Workergebühren gehen laut ADR 0007/0008 zu 100 % an den On-chain-Fonds, 0 % Burn dieser Kategorien**; normale Überweisungsgebühren und deren mögliche Validatorfinanzierung sind noch offen. Mining funktioniert kostenlos mit 0 PTM über Fenster 1. Die Wallet gibt kostenpflichtige Fenster einzeln oder per eng begrenzter, widerrufbarer Autorisierung frei. Der Miner erhält niemals Browser-Wallet-Secrets.
|
||||
|
||||
### Wichtige Grenzen
|
||||
|
||||
@@ -93,3 +93,19 @@ Ein sauberes Go-Gerüst und eine HTML-Oberfläche sind **noch keine nutzbare Blo
|
||||
Die im Oktober 2026 ergänzte Vision sieht **nach stabiler Kern-Chain und Web-Wallet** digitale Sammelobjekte (F1), einen in PTM abgewickelten internen Marktplatz (F2), eine Handelsoberfläche für fiktive interne Assets mit Orderbuch, Kursen, Charts und Portfolios (F3) und optional einen strikt getrennten Paper-Trading-Modus (F4) vor. Diese Szenarien sollen PTM einen internen Nutzwert geben. Sie begründen **keinen externen Euro-Kurs**, keine Börsenlistung und keine Anlage- oder Renditeaussage.
|
||||
|
||||
Asset-Kauf, Sammelgegenstände oder Bestandshöhen dürfen die PoP-Lotterie nicht zusätzlich bevorteilen. Die technischen Details (Assetmodell, Emission, Marktdaten, atomare Trades, Ordermatching, Gebühren und Schutz gegen Wash Trading) sind absichtlich offen. Keine Funktionen sind implementiert. Maßgeblich: `docs/ZUKUNFT_OEKOSYSTEM.md`, `docs/ROADMAP.md` und ADR 0004. Die Arbeiten an M1–M6 behalten Vorrang.
|
||||
|
||||
## Architekturergänzung v0.4: Hub, Worker, Cluster
|
||||
|
||||
Potatium Hub ist die autonome Full-Node mit Client-Wallet, eigenem Mining und lokalem Cockpit. Ein Worker ist ein schlanker an den Hub gebundener Miner ohne eigenständiges Coin-Wallet. Eine Betreiber-Identität gruppiert diese Instanzen und deren Kosten/PoP-Gewinne, auch bei mehreren Hubs/Wallets. Es gibt einen kostenfreien Hub-Mining-Platz je Betreiber; zusätzliche genehmigte Mining-IDs zählen wirtschaftlich als Worker. Jeder zugelassene Miner max. ein Ticket je Runde. Worker-Gebühren zusätzlich zu PoP-Fenster-2/3 sind noch Forschungsmodell. Priorität Node-/Cluster-Cockpit, später separate Admin-WebGUI. Für Details sind `docs/HUB_WORKER_CLUSTER.md`, `docs/WORKER_GEBUEHREN_FORSCHUNG.md` und ADR 0005 maßgeblich.
|
||||
|
||||
## Infrastruktur und Cockpits (Ergänzung v0.5)
|
||||
|
||||
Die Betriebsrollen, Datenspeicherung und Deployment-Stufen werden in `docs/INFRASTRUKTUR_UND_DEPLOYMENT.md` vollständig erklärt. Ab dem ersten funktionalen Devnet werden **beide lesenden Ansichten** umgesetzt: lokaler Potatium-Hub mit Wallet- und Node-Status sowie separater **Network Admin read-only** für Blockchain-/Validatorüberblick. Die administrative Schreibverwaltung kommt später. Begründung und Grenzen dokumentiert ADR 0006; UI-/Metrikkriterien stehen in `docs/COCKPITS_UND_MONITORING.md`. Kein zentraler Chain-Datenbankserver und keine Abhängigkeit der Blockchain vom Monitoring.
|
||||
|
||||
## Netzwerkzugang und Betreiberverwaltung (aktueller ADR 0008)
|
||||
|
||||
**Keine zentrale Benutzerplattform oder Pflichtregistrierung für den P2P-Sync.** Authentische Chain-ID, Genesis und CometBFT-Seed-/Persistent-Peers werden pro Node konfiguriert. Nur PoP-Mining erfordert autorisierte On-chain-Registry und operatorbezogene Gebühren-/Gewinnhistorie; Freigabe/Sperre im geschützten Network Admin über gesonderte signierte Aktionen. Der Network Admin ist ab erstem lauffähigem Devnet zunächst lesend mit echter Supply-/Burn-/Fonds-/Gebühren-/Registry-/Validatorübersicht, inaktiv markierten Freigabeaktionen bis zum vollständigen Signatur-Workflow. Optionales Monitoring-Inventar ist nicht konsenskritisch. Hub und Worker sind die beiden Teilnehmerpakete; Auszahlungs-Wallet-Schlüssel bleiben lokal im Browser. **100 % PoP-/Worker-Gebühren fließen in den On-chain-Fonds**, keine Burns dieser Gebühren. `docs/INSTALLATIONSPLAN_HOMELAB.md`, `docs/NETWORK_ZUGANG_UND_IDENTITAETEN.md` und ADR 0008 sind aktueller Stand.
|
||||
|
||||
## Erkenntnisse der Dynamik-/Fonds-Simulation vom 25.10.2026
|
||||
|
||||
36 Forschungsdurchläufe zeigen, dass dynamische Worker-Steuerung mit höheren Gebühren aktive große Cluster bremst, zugleich aber die Fondsbindung stark ansteigen kann: 3× dynamisch 40,59 % des erzeugten Supply, 5× fix 70,20 % bei gehaltenem Fonds. Die hypothetische Rückverteilung ist ohne Sybil-Schutz nicht als Governance-Beschluss geeignet. **Keine Workergebühr, Rundenlänge, Rewardhöhe oder Fonds-Auszahlung beschlossen.** Siehe `docs/POP_DYNAMIK_FONDS_AUSWERTUNG_2026-10-25.md`.
|
||||
Reference in new issue
Block a user