45 lines
3.0 KiB
Markdown
45 lines
3.0 KiB
Markdown
# 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
|
||
|
||
1. Jeder akzeptierte Zustandsübergang deterministisch und reproduzierbar.
|
||
2. Keine Wallet darf Coins ohne gültige Protokoll-Ausgabe erzeugen.
|
||
3. Ein Ticket pro registrierter Node-ID pro Runde; Signatur/Nonce bindet es an Runde, Chain-ID und Challenge.
|
||
4. Ein Los nur dann, wenn PoW und Frist nach überprüfbaren Regeln erfüllt sind.
|
||
5. Ziehungsinput wird **vor** dem entscheidenden späteren Zufallswert festgeschrieben; Gewinnerberechnung vollständig nachprüfbar.
|
||
6. Wenn keine gültigen Tickets vorliegen, gilt eine ausdrücklich definierte Nicht-Auszahlung/Carryover-Regel (noch zu beschließen).
|
||
7. Keine Node-ID beweist eine einzigartige Hardware; Kryptografie löst das Sybil-Problem nicht allein.
|
||
8. 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.
|