ParitrDocs

Was ist Paritr?

Paritr ist eine eigenständige Kryptowährung nach Bitcoin-Vorbild. Das Netzwerk besteht aus zwei Teilen:

• Full Nodes – unabhängige Server, die die gesamte Blockchain speichern, alle Regeln prüfen, Transaktionen weiterleiten und per Proof of Work neue Blöcke erzeugen. Jeder kann eine Node betreiben.
• Web-Plattform – dein Wallet im Browser. Der private Schlüssel wird lokal erzeugt und verlässt deinen Browser nie. Die Plattform ist im Hintergrund mit einer Node verbunden, um Guthaben zu lesen und signierte Transaktionen einzureichen.

Funktionsweise der Blockchain

Blöcke und Proof of Work

Jeder Block trägt einen 80 Byte großen Header aus Version, Hash des Vorgängers, Merkle-Wurzel aller Transaktionen, Zeitstempel, Schwierigkeit (nBits) und einem Zähler (Nonce). Die Kennung eines Blocks ist SHA256(SHA256(header)). Der Arbeitsnachweis nutzt dagegen scrypt mit 2 MiB Arbeitsspeicher je Hash (N = 2048, r = 8, p = 1). Gültig ist ein Block, wenn dieser scrypt-Hash kleiner oder gleich der Zielmarke ist. Miner variieren den Nonce so lange, bis das zutrifft.

Die Speicherbindung ist Absicht: Reines SHA256d lässt sich mit fertiger Spezialhardware (ASICs) millionenfach beschleunigen, die für Bitcoin ohnehin existiert. Ein Bruchteil davon würde die Schwierigkeit hier so weit anheben, dass normale Rechner chancenlos wären. scrypt macht die Speicherlatenz zum Flaschenhals statt der Rechenwerke – genau der Ansatz, der ASICs jahrelang von CryptoNight ferngehalten hat.

Kontenmodell

Statt UTXO nutzt Paritr ein Konto-/Nonce-Modell: Jede Adresse hat einen Kontostand und einen fortlaufenden Zähler. Jede Transaktion trägt die nächste Nonce des Absenders – doppelte oder übersprungene Nonces werden abgelehnt. Das schützt vor Wiedereinreichung (Replay) und erlaubt sehr schlanke Wallets.

Über das Netzwerk treffen Transaktionen desselben Absenders aber nicht zwangsläufig in Reihenfolge ein. Kommt Nonce n+1 vor n an, wird sie deshalb nicht verworfen, sondern kurzzeitig zwischengespeichert und automatisch nachgerückt, sobald die Lücke geschlossen ist.

Signaturen und Adressen

Signiert wird mit ECDSA auf der Kurve secp256k1. Die Adresse ist Base58Check(0x37 ‖ RIPEMD160(SHA256(pubkey))) und beginnt daher immer mit P. Die Node prüft, dass die Absenderadresse zum mitgelieferten öffentlichen Schlüssel passt.

Konsens und Reorganisation

Nodes vergleichen nicht die Länge einer Kette, sondern die insgesamt hineingesteckte Arbeit. Eine fremde Kette wird nur übernommen, wenn sie mehr Arbeit enthält und jeder einzelne Block alle Regeln erfüllt. Bei einer Reorganisation wandern Transaktionen verwaister Blöcke zurück in die Warteschlange (Mempool), Shares zurück in den Share-Speicher.

Umgestellt wird dabei nur der abweichende Teil: Die Blöcke ab dem Verzweigungspunkt werden rückabgewickelt, danach wird ausschließlich der neue Ast geprüft und angewendet. Der Aufwand hängt so von der Tiefe der Reorganisation ab – nicht von der Länge der gesamten Kette.

Ein zugestellter Block, der nicht direkt an die eigene Spitze passt, wird nicht verworfen, sondern als Seitenast zwischengespeichert. Sobald genug Folgeblöcke eintreffen und der Ast mehr Arbeit enthält, wird umgeschwenkt. Ohne diesen Schritt könnte eine Node, die selbst keine ausgehenden Verbindungen aufbauen kann, dauerhaft auf ihrer eigenen Gabelung verharren – die Blöcke und Belohnungen der Gegenseite gingen dann verloren.

State-Wurzeln und Snapshots

Die gesamte Historie nachzurechnen ist bei einer jungen Kette unproblematisch und bei einer alten mühsam. Paritr verankert deshalb alle 720 Blöcke (etwa zwölf Stunden) eine State-Wurzel im Block – eine Merkle-Wurzel über alle Kontostände und Nonces. Weil die Wurzel Teil des Blocks ist, kann eine neue Node einen heruntergeladenen Snapshot gegen die Kette prüfen, statt Millionen Blöcke abzuspielen.

Jede Node hält die zwei jüngsten Snapshots vor und bietet sie unter /state/snapshot an. Da die Wurzel nur alle 720 Blöcke berechnet wird, kostet sie in den übrigen 719 Blöcken exakt nichts.

Wie sich Nodes finden

1. Fest hinterlegte Seed-Nodes im Programmcode.
2. DNS-Seeds: aufgelöste Adressen werden als Kandidaten genutzt – aber nur für Hosts, die nicht ohnehin schon als Seed-URL hinterlegt sind. Sonst entstehen tote Einträge, weil die A-Records hinter einem Reverse-Proxy oder CDN auf dessen Edge-Adressen zeigen, unter denen der RPC-Port gar nicht offen ist.
3. Gossip: Beim Handshake tauschen Nodes ihre Peer-Listen aus.
4. Rückweg: Meldet eine Gegenstelle keine öffentliche Adresse, wird ein Kandidat aus ihrer Absender-IP und dem gemeldeten RPC-Port gebildet und geprüft.
5. Entdopplung: Ist dieselbe Node über mehrere Adressen bekannt (Seed-URL, Port-Variante, aufgelöste IP), wird für Relay und Sync nur die beste davon verwendet und weitergegeben.
6. Headers-First-Sync: Erst alle Header prüfen, dann die Blöcke laden.
7. Der Genesis-Block wird auf jeder Node deterministisch identisch berechnet.

Über dieselben Verbindungen laufen drei Arten von Nachrichten: Blöcke, Transaktionen und Shares. Alle ausgehenden Aufrufe werden von einer festen Zahl Hintergrund-Worker abgearbeitet. Eine langsame oder bösartige Gegenstelle kann den Node dadurch weder ausbremsen noch über unbegrenzt viele Verbindungen überlasten.

Übertragungsformat

Shares und Blöcke werden zusätzlich in einem kompakten Binärformat unter /p2p/share/bin und /p2p/block/bin angeboten (Magic PSH1 / PBK1, Obergrenze 4 MiB je Nachricht). Das halbiert den Relay-Verkehr gegenüber JSON ungefähr. Nodes handeln das Format automatisch aus und fallen auf JSON zurück, wenn eine Gegenstelle es nicht unterstützt.

Emission und Tail-Emission

Jeder neue Block erzeugt frische Coins – die Subvention. Sie startet bei 10 PAR und halbiert sich alle 1.600.000 Blöcke, also etwa alle drei Jahre.

Warum ohne Obergrenze?

Ein Netzwerk mit harter Obergrenze finanziert seine Sicherheit irgendwann ausschließlich über Transaktionsgebühren. Bleiben die aus, sinkt die Rechenleistung – und mit ihr der Schutz vor Angriffen. Die Tail-Emission löst das: Sie garantiert eine planbare Mindestbelohnung, ohne dass die Geldmenge aus dem Ruder läuft.

Entscheidend ist nämlich nicht die absolute Menge, sondern die jährliche Inflationsrate. Weil die Umlaufmenge wächst, die Neuemission je Jahr aber konstant bleibt, fällt diese Rate dauerhaft gegen null – ohne sie jemals ganz zu erreichen. Den aktuellen Wert zeigt der Endpunkt /supply.

Shares: Bezahlung nach Leistung

Das Problem kleiner Nodes

Bei klassischem Mining bekommt nur die Node etwas, die den Block findet. Eine kleine Node mit 1 % der Rechenleistung findet im Schnitt jeden hundertsten Block – und geht dazwischen leer aus. Genau deshalb schließen sich Miner überall zu zentralen Pools zusammen.

Die Lösung: Shares direkt im Protokoll

Paritr baut den Pool in die Blockchain selbst ein. Beim Schürfen entstehen neben dem seltenen Blocktreffer laufend Shares: gültige Arbeitsnachweise, die ein Hundertstel der Blockschwierigkeit erfüllen. Sie kosten keine zusätzliche Rechenzeit, denn es ist derselbe Hash-Durchlauf – nur mit einer zweiten, leichteren Zielmarke.

1. Die Node findet einen Share und verteilt ihn per Gossip an ihre Peers.
2. Jede Node prüft ihn sofort: Arbeitsnachweis, Elternblock, Dublette.
3. Die nächste Node, die einen Block findet, bindet bis zu 32 gesammelte Shares in ihren Block ein.
4. Alle Shares der letzten 120 Blöcke bilden das Messfenster, nach dem die Belohnung verteilt wird.

Warum niemand fremde Shares unterschlagen kann

Ein Finder könnte versucht sein, fremde Shares einfach wegzulassen, um mehr für sich zu behalten. Das lohnt sich nicht: Liegen keine fremden Shares vor, fällt der gesamte 95 %-Pool ohnehin an den Finder – er hat also keinen Nachteil davon, sie aufzunehmen, wohl aber die garantierten 5 % Inklusions-Anreiz plus alle Gebühren sicher. Gleichzeitig ist die Verteilung für jede Node exakt nachrechenbar: Ein Block mit falscher Coinbase wird schlicht abgelehnt.

Und Shares lassen sich nicht stehlen: Die Auszahlungsadresse steckt über einen Merkle-Nachweis im gehashten Header. Wer sie austauscht, zerstört den Arbeitsnachweis. Bereits bestätigte Shares können zudem kein zweites Mal eingebunden werden.

Mining und Belohnungen

Ablauf

1. Eingereichte Transaktionen sammeln sich im Mempool, eingehende Shares im Share-Speicher der Node.
2. Die Node baut einen Kandidaten-Block: zuerst die zu bestätigenden Shares, daraus der Verteilschlüssel und die Coinbase-Ausgänge, danach die Transaktionen mit der höchsten Gebühr.
3. Der Nonce wird variiert, bis der Header-Hash unter der Zielmarke liegt. Zwischentreffer unter der leichteren Share-Marke werden als Shares veröffentlicht.
4. Der Finder hängt den Block an und verteilt ihn an alle bekannten Peers.

Liegt keine Transaktion vor, entsteht ein leerer Block mit nur den Coinbase-Ausgängen. Das Netzwerk rechnet dadurch ununterbrochen weiter.

Wer bekommt wie viel?

Je Block gibt es höchstens 32 Empfänger; Kleinstbeträge unter 0,00001 PAR sowie Rundungsreste gehen an den Finder. Dadurch entspricht die Summe aller Ausgänge exakt Subvention plus Gebühren – jede Node rechnet das mit reiner Ganzzahlarithmetik nach. Die aggregierten Kennzahlen zeigt der Bereich Mining › Netzwerk sowie der Endpunkt /mining/distribution.

Reifezeit

Frisch geschürfte Coins sind zunächst gesperrt und erst nach 10 weiteren Blöcken ausgebbar. In der Übersicht steht bis dahin Ausstehend, danach Bestätigt. Das schützt vor Umkehrungen, falls sich die Kette kurzfristig reorganisiert.

Konsens-Parameter

Diese Werte sind fest im Protokoll verankert und auf jeder Node identisch. Sie lassen sich weder über die Konfiguration noch über die Weboberfläche ändern.

Node installieren

Eine Paritr-Node läuft überall dort, wo Python 3.9 oder neuer verfügbar ist. Getestete Plattformen:

Mindestanforderungen

• Python 3.9 oder neuer
• 2 GB RAM, 2 GB freier Speicher (wächst mit der Kette)
• Dauerhafte Internetverbindung
• Erreichbarer TCP-Port (Standard 5050) – empfohlen, aber nicht zwingend

Alle Dateien im Überblick

Die Installationsskripte laden alles Weitere selbst nach – einzeln brauchst du die Dateien nur für eine manuelle Einrichtung.

Linux: Ubuntu, Debian und ARM

Das Skript funktioniert identisch auf x86_64-Servern und auf ARM-Geräten (Raspberry Pi 4/5, Oracle Ampere, AWS Graviton, …). Die Architektur wird automatisch erkannt.

Windows

Unter Windows übernimmt install.ps1 die Einrichtung. Als Serverprozess kommt waitress zum Einsatz; der Autostart läuft über eine geplante Aufgabe.

Manuelle Installation (macOS, andere Systeme)

Hardware-Auslastung steuern

Wie viel Leistung deine Node fürs Mining einsetzt, ist frei einstellbar – bequem über die Regler im Bereich Mining der Web-Plattform oder direkt auf dem Server.

Über die Web-Plattform

Mining › Meine Nodes › Einstellungen › Leistung: Die beiden Regler zeigen live die zu erwartende Gesamtlast an. Änderungen greifen sofort nach dem Speichern – ein Neustart ist nicht nötig. Voraussetzung ist ein hinterlegter Admin Secret Key.

Auf dem Server

Erreichbarkeit herstellen

Deine Node findet das Netzwerk auch hinter einem Router von allein. Damit andere Nodes sie erreichen und die Web-Plattform sie direkt ansprechen kann, sollte der Port erreichbar sein.

1. Dem Server im Router eine feste lokale IP-Adresse zuweisen.
2. Portweiterleitung einrichten: 5050/TCP auf diese IP.
3. Bei wechselnder öffentlicher IP einen DynDNS-Namen einrichten und ihn beim Installieren als --public-url angeben.
4. Erreichbarkeit prüfen: curl http://DEINE-ADRESSE:5050/status

Der Installer erkennt deine öffentliche Adresse automatisch und trägt sie in config.json ein. Korrigieren kannst du sie später mit ./manage.sh publicurl https://…; was die Gegenstellen sehen, meldet die Node unter /p2p/whoami.

Node mit dem Wallet verbinden

Erst durch das Verbinden kannst du deine Node in der Web-Plattform überwachen und steuern. Die Verbindung gilt nur für dein Konto.

Betrieb und Wartung

Linux

Windows

Konfigurationsdatei

Nach Handänderungen an config.json den Dienst neu starten. Änderungen über die Web-Plattform oder manage greifen dagegen sofort.

Datensicherung

Sichern musst du nur config.json (enthält den Admin Secret Key). Die Blockchain selbst lädt eine neue Node automatisch aus dem Netzwerk. Dein Guthaben liegt in der Blockchain – nicht auf der Node.

Sicherheit

• Privater Schlüssel: Wird im Browser erzeugt und nur mit deinem Passwort verschlüsselt (AES-256-GCM) gespeichert. Ohne Schlüssel und Passwort gibt es keinen Zugriff auf dein Guthaben – und keine Wiederherstellung durch Dritte. Sichere ihn unter Konto › Schlüssel sichern.
• Admin Secret Key: Gehört zur Node, nicht zum Wallet. Er erlaubt keine Überweisungen, sondern nur das Steuern der Node.
• Node-Rechte: Der systemd-Dienst läuft ohne erweiterte Rechte und darf nur in sein eigenes Verzeichnis schreiben.
• CORS: Über rpc_cors_origins lässt sich der Zugriff auf die eigene Plattform begrenzen, statt * zu erlauben.
• Server-Proxy: Die Plattform ruft nur freigegebene Endpunkte auf und verweigert Anfragen in private Netze (SSRF-Schutz).

Häufige Probleme

Schnittstellenreferenz

Jede Node bietet eine offene JSON/REST-Schnittstelle. Admin-Endpunkte erwarten den Header X-Admin-Secret.

Beispiel