3.0 KiB
3.0 KiB
Potatium Protokoll v0.1 – Entwurf, nicht freigegeben
Bestätigte Produktziele
- Neue eigenständige Blockchain mit nativer Kryptowährung Potatium (PTM).
- Leichte echte PoW-Aufgabe pro Miner/je Runde; pro freigegebener Node-ID maximal ein qualifiziertes Ticket pro Runde.
- Ein verifizierbarer Gewinner wird aus den rechtzeitig qualifizierten Tickets ausgelost; PTM-Emission als konsensgeprüfte Blockregel.
- Kleine Hardware (Ziel: Raspberry Pi 4) muss sinnvoll mitmachen können; mehr physische Geräte dürfen mehr Node-Identitäten haben. Registrierung zunächst manuell.
- Validatoren bestätigen Blöcke unabhängig von Lotteriegewinnern.
- Webbasiertes Wallet mit Basisfunktionen ab erstem funktionalen MVP.
Noch zu entscheiden
| ID | Parameter | Aktueller Stand / Anforderung |
|---|---|---|
| P-01 | Maximale Coin-Menge | OFFEN, keine Annahme 21 Mio. |
| P-02 | Anfangsbestand/Genesis | OFFEN; Starthöhe/Valve der Testcoins festlegen |
| P-03 | Dezimalstellen | OFFEN; alle Werte ganzzahlig in Basis-Einheiten |
| P-04 | PoP-Emissionsplan | OFFEN; nicht automatisch 10 PTM |
| P-05 | Rundenlänge | OFFEN; nicht automatisch 120 s |
| P-06 | Konsens-Blockzeit | OFFEN; getrennt von Mining-Runden |
| P-07 | Proof | SHA-256 als Prototyp-Kandidat, kalibrieren auf Raspberry Pi |
| P-08 | Mining-Difficulty | feste/zeitbasierte Kalibrierung erst nach Benchmarks |
| P-09 | Teilnehmerliste | Höhe/Abschlussprozess und Eligibility-Fenster offen |
| P-10 | Zufallsbeweis | drand als Option; Ausfallverhalten offen |
| P-11 | Schlüssel und Adresse | Signaturalgorithmus, Serialisierung, Recovery offen |
| P-12 | Transaction Fees | zunächst niedrige Gebühren oder Testnet-Fee-Regel offen |
| P-13 | Validator-Modell | CometBFT fester Satz zu Beginn als Architekturpräferenz |
| P-14 | Registry-Administration | Autorisierung, Removal, Transparenz und Verfahren offen |
Vorgesehene Invarianten
- Jeder akzeptierte Zustandsübergang deterministisch und reproduzierbar.
- Keine Wallet darf Coins ohne gültige Protokoll-Ausgabe erzeugen.
- Ein Ticket pro registrierter Node-ID pro Runde; Signatur/Nonce bindet es an Runde, Chain-ID und Challenge.
- Ein Los nur dann, wenn PoW und Frist nach überprüfbaren Regeln erfüllt sind.
- Ziehungsinput wird vor dem entscheidenden späteren Zufallswert festgeschrieben; Gewinnerberechnung vollständig nachprüfbar.
- Wenn keine gültigen Tickets vorliegen, gilt eine ausdrücklich definierte Nicht-Auszahlung/Carryover-Regel (noch zu beschließen).
- Keine Node-ID beweist eine einzigartige Hardware; Kryptografie löst das Sybil-Problem nicht allein.
- Gleiche Chance unter allen qualifizierten Losen; nicht garantierte gleiche Qualifikationschance zwischen CPUs.
Testanforderungen
Property-Tests für Ticket-Limit und Emission, Fuzzing für Parser und Eingaben, Replay/Double-Spend, deterministische Blöcke, RNG-/Commit-Tests, Snapshot/Restart, Pi-Benchmarks und Multi-Validator-Ausfalltests. Jede Definition einer Regel bekommt reproduzierbare Testvektoren.