Proof-of-Stake: Einblick

Es gibt viele philisterhafte Artikel und Diskussionen im Internet, aber nicht genügend Informationen über die Verdienste. Irgendwann stellte der Autor fest, dass die Mechanik und viele damit verbundene Sicherheitsnuancen selbst von vielen Kryptowährungsentwicklern nicht vollständig verstanden werden. Dies zeigte sich in einem realen Fall der Portierung der PoS-Implementierung für eine der Kryptowährungen und in der weiteren Veröffentlichung von Informationen zu den von Experten von Drittanbietern festgestellten Sicherheitslücken.

Dieser Artikel ist nützlich für alle Entwickler, die bereits auf PoS-Schwachstellen gestoßen sind oder noch kommen werden.

Entsetzt unter dem Schnitt.

Ein Körnchen Geschichte

Im Internet wird die Entstehung von Proof-of-Stake (PoS) in Peercoin nach einer Diskussion in einem der Foren im Jahr 2011, seiner späteren Verwendung in Novaoin und seiner weiteren Verbreitung in PIVX und anderen Bitcoin-Gabeln verfolgt. Eine ziemlich primitive PoS-Logik wurde in das kernel.cpp kernel.h / kernel.cpp , das in Form verschiedener Frankenstein-Module durch die kernel.cpp wandert.

Der PoS-Algorithmus hat mehrere Entwicklungsstufen durchlaufen, jemand gibt ihnen Versionen. Jetzt sind PoS-Optionen aus natürlichen Gründen geteilt, DPoS ist erschienen. Eine der fortschrittlichsten Lösungen ist das Casper-Protokoll in Ethereum.

Jede Blockchain erfordert die Generierung von Blöcken und jemand sollte das Recht haben, einen neuen Block zu erstellen. Wenn der Autor dies in einer Blockchain wie dem Git-Versionskontrollsystem ohne große Konkurrenz tut, gibt es in Kryptowährungen einen heftigen Kampf um die Belohnung des Blocks im Rahmen von Proof-of-Work (PoW) - das Finden einer solchen Kombination variabler Eingabeparameter durch Auswahl eines entsprechenden Ergebnisses bestimmt durch ein bestimmtes Ziel (Bergbau, Bergbau).

PoS ersetzt Proof-of-Work (PoW), um Ressourcenverschwendung beim Mining zu vermeiden. Stattdessen werden alle Eingabeparameter streng mit einem konstanten Merkmal definiert, das auf den vorhandenen Einsparungen der Münzhalter basiert. Daher ist PoW als Ausgangspunkt für PoS erforderlich, wenn Sie nicht auf verschiedene Optionen für die anfängliche hypothekarische Bereicherung der Schöpfer der Münze zurückgreifen.

Warum?

Das Einsparen von Energie ist für Entwickler und Münzhalter ungefähr so ​​wichtig wie die Begrenzung der Treibhausgasemissionen für Produzenten und Verbraucher. Die grausame Wahrheit ist anders:

1. PoW-basierte Projekte unterliegen sogenannten „51-Prozent-Angriffe“: Angreifer können große Kräfte einsetzen, eine parallele Kette bilden und diese dann plötzlich mit einer anderen Münzbewegung veröffentlichen (dh doppelte Verschwendung).
2. PoW-Bergleute müssen ihre Kosten decken und in den Kapazitätsaufbau investieren - dies ist ein direkter Kapitalabfluss aus Projekten.
3. Sparbesitzer möchten ihre Kaufkraft durch Eigenkapitalbeschaffung erhalten, anstatt die natürliche Inflation zu betrachten.

An einem lebenden Beispiel: Von November bis Dezember 2018 gab es Angriffsversuche; dann gab es von Dezember bis Februar Aufsehen als die rentabelste Münze für den Bergbau auf Grafikkarten; der Kurs fiel von 2+ auf 0,5 USD; Nach der Umstellung auf PoS stieg der Zinssatz innerhalb einer Woche auf 1 USD und der Zufluss von Investitionen nahm zu.

Technische Punkte

Achtung: In diesem Abschnitt sprechen wir über den "traditionellen" PoS in der Form wie in Peercoin, PIVX und ihren Gabeln.

Sie müssen verstehen, dass es keine Zentralisierung und Berücksichtigung von „Punkten“ gibt. In dieser Version funktioniert das gleiche Glücksprinzip wie in PoW.

1. Terminologie

Die Terminologie ist relativ allgemein, aber in verschiedenen Implementierungen sind ihre Nuancen:

• PoW-Ziel - Ziel = Basisziel, normalerweise 2 ^ 240 (0x0000ffff ...) geteilt durch die Komplexität des Blocks (erhöht die Anzahl der vorangestellten Nullen).
• Blockschwierigkeit - Die Komplexität des Blocks im Verhältnis zum Basisziel, die anhand der aktuellen Kettenwachstumsrate bestimmt werden kann.
• UTXO - Unspent Transaction Output, ein Paar aus einem Transaktions-Hash und einer Exit-Nummer.
• CoinBase ist eine spezielle Transaktion mit dem Index 0 in dem Block, der die Belohnung enthält.
• Stake oder CoinStake ist eine spezielle Transaktion mit Index 1 in einem Block.
• Stake Input - UTXO, das die Anforderungen für eine Wette nach Größe und Alter erfüllt.
• Stake Modifier - ein spezieller deterministisch berechneter Parameter für jeden Stake Input .
• Stake Hash ist ein Hash-Ergebnis, das arithmetisch unter dem Stake-Ziel liegen sollte .
• Einsatzziel - das gleiche wie das PoW-Ziel, jedoch proportional um den Betrag des Einsatzes im Verhältnis zum Mindestgebot erhöht.
• Block Signature - Block Signature .
• Gabel - eine verzweigte Kette.
• Split - Netzwerkfreigabe.
• Verwaiste - verworfene Blöcke aufgrund der Wahl einer anderen Alternative.

2. Anatomie

Generierungsprozess:

1. Wir finden alle UTXO, die die Anforderungen von Stake Input erfüllen
2. Suchen Sie den Einsatzmodifikator.
3. Multiplizieren Sie das PoW-Ziel mit dem Einsatz
   
   • in Millionstel in der Tat - deshalb entspricht 1 MH PoW-Hashrate experimentell einer Münze.
4. Wir Stake Hash = H(Stake Modifier, Stake Block Time, UTXO output index, UTXO txid, Current Block Time) .
   
   • nur variabler Parameter Aktuelle Sperrzeit
5. Wenn Stake Hash >= Stake Target , versuchen Sie, die Current Block Time im akzeptablen Bereich zu finden.
   
   • Abhängig von der Implementierung müssen Sie die Möglichkeit von Überläufen des Einsatzziels in Betracht ziehen, wenn diese mit der Menge des Einsatzes multipliziert werden.
6. Wir setzen Coinbase in tx [0] und CoinStake in tx [1].
   
   • Der Begünstigte von Coinbase ist das gleiche Skript (Adresse) wie Stake Input.
7. Wir unterschreiben den Block.

2.1. Blockzeit:

Es ist leicht zu erkennen, dass ein Betrug im Laufe der Zeit einige Vorteile bringen kann. Standardkonsens begrenzt die unteren und oberen Grenzen.

Die unteren setzen immer die durchschnittliche Zeit der Blöcke über die letzten N Blöcke, normalerweise über 11. Dies ist die Toleranz für die Ungenauigkeit der Zeit beim Erzeugen von Knoten.

Die historische Obergrenze wurde für PoW mit einem Finger zum Himmel um 2 Uhr festgelegt. Das Erhöhen der Intervalle verringert die Komplexität und macht den Zweig weniger attraktiv - daher macht es keinen Sinn. Aber für PoS macht es Sinn.

PIVX und andere begrenzen die zukünftige Zeit auf maximal 3 Minuten. Einige legen eine strengere Einschränkung fest, dies führt jedoch zu Problemen für die Benutzer. Einige PoS-Implementierungen haben beschlossen, die minimalen Zeitintervalle für die aktuelle Blockierung von einer Sekunde auf 15 bis 16 Sekunden zu ändern.

2.2. Einsatzmodifikator:

Der Stake Modifier wurde konzipiert, um die Vorhersage zu erschweren und die Kette voranzutreiben, aber etwas ist schief gelaufen ...

Es gibt verschiedene Möglichkeiten, dies zu berechnen: Die letzten Bits von Block-Hashes am Ende progressiv festgelegter Zeitintervalle, [nicht sehr] schlecht vorhergesagte Werte aus vorherigen Blöcken usw. An einigen Stellen sieht es eher nach Verschleierung von Code als nach etwas Vernünftigem aus.

Das Original benötigt eine Pause von 64 Intervallen. Diese Lücke wird schrittweise in 64 ungleiche Teile unterteilt. Ränder werden auf Minuten gerundet. An den Rändern werden vorhandene Blöcke ausgewählt und ein letztes Bit daraus entnommen. Es stellt sich also eine 64-Bit-Zahl heraus, ähnlich wie bei Nonce.

Das Intervall bei Peercon beträgt 20 Minuten, aber die Mitarbeiter von PIVX haben entschieden, dass das auf die Minute gerundete Intervall von 1 Minute das ist, was der Arzt angeordnet hat.

Im Allgemeinen ist in einigen Implementierungen wie Blackcoin V2 + alles festgelegt und der Einsatzmodifikator wird vom Kopf aus gezählt, während in Peercoin V03, PIVX, Blackcoin V1 und anderen vom Einsatz-Eingabeblock. Letzteres zerstört die Bedeutung fast vollständig. Es besteht die Annahme, dass die Verwirrung auf das banale Problem der Benennung von Variablen, weiterer Metamorphosen und des gedankenlosen Kopierens und Einfügens zurückzuführen ist. Und der Autor selbst entdeckte das Problem ziemlich spät, während seine ganze Aufmerksamkeit auf den Schutz vor DoS gerichtet war. Lass dich nicht erwischen!

2.3. Blockieren Sie die Signatur

Da der Hash des Blocks nicht mehr als Arbeitsnachweis dient und jeder die signierte CoinStake-Transaktion von einem anderen Block übernehmen kann, müssen Sie überprüfen, ob der Block vom Eigentümer von Stake erstellt wurde. Daher wird der Header mit demselben privaten Schlüssel wie CoinStake signiert.

2.4. CoinBase- und CoinStake-Exit-Skript

Dieselben Exit-Skripte oder das Aufrufen von Brieftaschenadressen sind erforderlich, um die Privatsphäre zu schützen und zu vermeiden, dass einzelne Adressen in einer Brieftasche verknüpft werden.

2.5 Was und wo?

Es gibt verschiedene Variationen im Umgang mit Beträgen in CoinBase und CoinStake. Logik und Motivation im Einzelfall:

1. Beträge müssen getrennt gehalten werden, um selbst den geringstmöglichen Verlust von Benutzermitteln aufgrund von Verarbeitungsfehlern zu vermeiden.
2. CoinBase behält seine 100 Bestätigungen bei, aber CoinStake kann sofort ausgegeben werden, was natürlich das Risiko doppelter Ausgaben birgt.
   
   • Das Einrasten in die Tiefe der Blöcke widerspricht auch der Altersqualifikation für die Verwendung als Einsatz.
3. CoinBase und CoinStake sollten niemals in den Mempool gelangen, und alle darauf basierenden Transaktionen sollten während der Kettenwiederherstellung gelöscht werden.

3. Vervollständigen Sie die Blöcke gegen die Überschriften

Der Eintritt eines vollwertigen Knotens in das Netzwerk beginnt mit der Synchronisation. In Bitcoin basiert die Synchronisation hauptsächlich auf Blockheadern, as Sie enthalten ausreichende Informationen zur vorläufigen Überprüfung des Konsenses. Zunächst werden relativ kleine Header herausgezogen und in Chargen von bis zu 2000 Teilen von einem Seitenknoten geprüft. Wenn die Erstprüfung erfolgreich war, werden alle Blöcke von allen verbundenen Knoten parallel gezogen.

Der Hochwasserschutz basiert auf der Tatsache, dass der lokale Knoten den bekanntesten Header mit dem vergleicht, was er hat, und die gesamte Header-Kette anfordert. Beim Herunterladen wird alles durch die geringen Kosten für Speicherplatz und Computer überprüft. Das Gewicht der Ketten wird anhand eines Merkmals wie Kettenarbeit verglichen, bei dem es sich um die Summe der Komplexität jedes einzelnen Blocks handelt. Um eine so starke alternative Kette aufzubauen, sind extrem hohe Ressourceninvestitionen erforderlich, was Angriffe vielversprechend macht.

Mit PoS funktioniert dieser Ansatz nicht, weil Um die Blöcke zu überprüfen, müssen Sie die vollständigen vorherigen Blöcke mindestens bis zum Mindestalter des Einsatzes verarbeiten. Die vom Autor betrachteten Implementierungen wurden nicht pervers, sondern weigerten sich einfach, mit Headern zu arbeiten.

Daher implementierte der Autor einen parallelen opportunistischen Download von Blöcken nach den Headern, was die Synchronisationsgeschwindigkeit aufgrund der Verwendung aller Verbindungen erheblich erhöht. Kleinere Verzögerungen treten nur auf, wenn sich die Peers in verschiedenen Ketten befinden - dann wird die Verbindung nach einer geringfügigen Zeitüberschreitung wie im Standardschema unterbrochen. Als Minus die Tendenz, zum Zeitpunkt der Synchronisation eine falsche Kette zu wählen.

Übrigens haben der Standard-Bitcoin-Client und seine Gabeln die Mindeststandardanzahl ausgehender Verbindungen 8 lange genug erfasst, wenn einige von ihnen aus verschiedenen Gründen fehlschlagen. Dies wurde durch asynchrone ausgehende Verbindungen behoben.

4. Gabeln, Splits und Waisen

Beim Blockbauwettbewerb sind alternative Ketten mit 1-2 Gliedern relativ häufig. Längere Gabeln in entwickelten Netzwerken treten natürlich nur bei epischen Konsensfehlern aufgrund eines Programmierfehlers oder einer globalen Internetunterbrechung auf.

Selbst bei einer Trennung besteht normalerweise keine Gefahr für die Integrität der Transaktionsverarbeitung Beim Trennen von Blöcken gehen alle Transaktionen zurück in mempool und sind bereits in anderen Blöcken enthalten. Mempool ist ein temporäres Repository für Transaktionen, nachdem diese erstellt wurden. Mempool selbst wird in neueren Versionen auf der Festplatte gespeichert. Die Belohnung für den Block wird zerstört. Aus diesem Grund wird die Mindestanzahl von Bestätigungen (Tiefe) für Auszeichnungen festgelegt.

Es kommt vor, dass lokale Netzwerksegmente ihre Verbindung zur Außenwelt verlieren und weiterhin abbauen, vorausgesetzt, es besteht eine Verbindung zum Hauptnetzwerk. Solche Zweige stellen aufgrund ihrer natürlichen Schwäche normalerweise keine Bedrohung dar.

Der Hauptangriff von 51% für PoW wurde bereits oben beschrieben - er ist extrem ressourcenintensiv, aber für PoS wird er relativ erschwinglich. Aus diesem Grund wird es technisch möglich, viele Zweige aus verschiedenen Gliedern der Kette herzustellen. Eine der klassischen Lösungen besteht darin, Gabeln unterhalb einer bestimmten Tiefe zu verbieten.

Das Hauptproblem eines solchen Schutzes ist die Unfähigkeit von Knoten aus Einsiedlersegmenten, nach einem Neustart unabhängig zur Hauptschaltung zurückzukehren.

Daher wurde ein Ansatz zum Verbot von Gabeln, die älter als ein bestimmter Zeitraum sind, nur dann implementiert, wenn die Spitze der Kette noch recht jung ist.

Bei einem Zielintervall von Blöcken von 1 Minute wurde das Kriterium der alten Gabel nach 1 Stunde gewählt, was ungefähr 60% der CoinBase-Bestätigungen entspricht, und das Kriterium der Jugend der Krone nach 15 Minuten ist dreimal höher als die maximale statistische Verzögerung des Blocks.

5. Blockieren und teilen Sie den Hash

In PoW deckt ein Block-Hash alle Daten vollständig ab. Es wird auch verwendet, um das Ziel zu überprüfen. In PoS ist Stake Hash ein separater Wert, weil es ist notwendig, die Möglichkeit seiner Auswahl auszuschließen. Dies eröffnet die Hauptbedrohung - die Möglichkeit, eine unbegrenzte Anzahl verschiedener Versionen des Blocks auf der Grundlage desselben zusammenfallenden Einsatzes zu erstellen, der leicht überflutet und das Netzwerk oder seine einzelnen Knoten platziert werden kann.

Naive Verteidigungsansätze führen zu noch schwerwiegenderen Split-Schwachstellen. Ein solcher Ansatz in verschiedenen Varianten besteht darin, die Verwendung von Stake Input nur einmal zuzulassen. Ein einfacher Angriff besteht darin, verschiedene Blöcke an verschiedene Knoten zu senden, wodurch sofort ein weicher Split entsteht.

Noch fataler ist es, dies durch ein DoS-Verbot zu verschärfen, das nicht nur die Ketten, sondern auch das Netzwerk selbst in verschiedene Segmente unterteilt.

Andere Probleme treten auf - die Unfähigkeit, Stake aus einem abgelegten Block zu verwenden.

Daher wurde die Drosselmethode als sicherste Lösung gewählt - der gleiche Einsatz kann nicht mehr als einmal pro Minute verwendet werden. Die Logik ist einfach: Ein Angriff kann nur im Intervall von 1 Stunde dauern (siehe die alte Gabelung oben), für die es möglich ist, nicht mehr als 60 Blöcke zu überfluten. Im besten Fall wird das Netzwerk im nächsten Block bereits auf einen einzelnen Stromkreis umgestellt. Im schlimmsten Fall geschieht dies bei einem kontinuierlichen Angriff in einer Stunde. Die Wahrscheinlichkeit, dass im schlimmsten Fall mehrere Blöcke hintereinander gefunden werden, schmilzt exponentiell.

Trotzdem bleiben einige Punkte bestehen, an denen die Knoten bis zum Zeitpunkt der vollständigen Synchronisierung für mäßige Überschwemmungen anfällig sind .

6. Mindestalter

Für einige ist diese Einschränkung verwirrend, aber für die Netzwerkstabilität äußerst wichtig Dieser Parameter steht in direktem Zusammenhang mit der maximalen Länge des alternativen Netzwerks, die der lokale Knoten ohne ernsthafte technische Verzerrungen überprüfen kann.

Wie bereits erwähnt, muss der lokale Knoten alle Blöcke bis zum Alterslimit verarbeiten, um überprüfen zu können, ob der Stake Input a) einen Platz hat, an dem b) wirklich UTXO ist und nicht ausgegeben wurde.

Überprüfen Sie, ob dies nur durch die Funktionalität des sogenannten möglich ist. CoinView, der den Bewegungszustand von Münzen zum Zeitpunkt eines bestimmten Blocks darstellt - die Spitze der Hauptkette im Verständnis des lokalen Knotens.

Die Implementierung eines vollwertigen Tests alternativer Schaltkreise in Zeitintervallen oder sogar auf besondere Weise, die von CoinView gespeichert werden, erscheint nicht vielversprechend, weil Die Anzahl dieser alternativen Ketten ist unendlich groß.

Ein zu großer Balken für die Altersgrenze von UTXO wirkt sich negativ auf Benutzer aus, die einen Teil ihrer Münzen ausgeben oder kombinieren möchten.

Wenn Sie diesen Rand in der Tiefe der Blöcke angeben, ist eine hypothetische Pattsituation eines vollständigen Kettenstopps aufgrund der Tatsache, dass kein geeignetes UTXO vorhanden ist, möglich. Bei Zeiteinheiten tritt zumindest eine gewisse Bewegung auf.

Daher wird in anderen Netzwerken eine ausgeglichene Auswahl von 1 Stunde in absoluten Zeiteinheiten anstelle der Tiefe der Blöcke verwendet.

7. Was ist besser als N UTXO für den Mindestbetrag oder ein UTXO mit N insgesamt?

Hier spricht sich die Analogie aus: Es ist besser, eine Waffe mit einer Genauigkeit von 0,9 oder drei Waffen mit einer Genauigkeit von 0,3 zu haben, aber mit Wahrscheinlichkeiten in der Größenordnung von 1/2 ^ 20 scheinen die Ergebnisse solcher Berechnungen ausgeglichen zu sein. Eine kleine Karte verwirrt die Qualifikationsreife.

Die derzeitige Annahme, dass viele kleine Transaktionen mehr Blöcke finden, stammt wahrscheinlich aus der Zeit, als das Alter des Einsatzes bei der Bestimmung des Gewichts ebenfalls berücksichtigt wurde. Damals machten alte kleine Transaktionen wirklich viel Sinn.

Im Moment bringen die in großen UTXO gruppierten Gruppen basierend auf praktischen Experimenten und theoretischen Berechnungen mehr Blöcke. Darüber hinaus erfordert weniger UTXO weniger CPU-Arbeit. Jemand behauptet das Gegenteil.

Denken Sie also selbst.

8. Blöcke vorwärts laufen lassen

PoS-Bergleute übertreffen Blockzeiten natürlich ein wenig. Dies wirkt sich negativ auf die Komplexität des Netzwerks aus. Der Standard-Bitcoin-Code wählt den ersten empfangenen Block unabhängig von der darin angegebenen Zeit aus. Die meisten PoS-Implementierungen machen dasselbe.

Daher wurde die Logik des PoS-Miners geändert, um die Auswahl ab der durchschnittlichen Zeit der Blöcke zu starten, wenn die Zeit des aktuellen Blocks vorwärts ging. Gleichzeitig vergleichen die Knoten vor dem Vergleich der Reihenfolge die angegebene Zeit der Blöcke. Der PoS-Miner sendet den gefundenen Block an das Netzwerk, auch wenn er sieht, dass er eine Verzweigung generiert.

Auf diese Weise wird das Netzwerk auch vor hypothetischen vorzeitig gesendeten Blöcken geschützt, deren Stake-Eingang aufgrund des DoS-Schutzes in den nächsten 60 Sekunden nicht mit demselben Stake-Modifikator verwendet werden kann. Wie eine doppelte Strafe für Betrug im Laufe der Zeit.

9. Eine kleine Checkliste

1. Stake Input muss vor dem Gabelpunkt UTXO gültig sein:
   
   • bei der Hauptkette ist der Gabelpunkt die Spitze,
   • im Falle einer alternativen Schaltung - UTXO nach dem Gabelpunkt kann beim Schalten zu Self-DoS führen,
   • UTXO sollte nicht alleine in mempool sein.
2. Akzeptieren Sie CoinStake in mempool nicht, wenn Sie den Hauptstromkreis neu erstellen:
   
   • das gleiche passiert mit CoinBase,
   • Dies kann die Transaktionskette zerstören (unwahrscheinlich).
3. Akzeptieren Sie keine Gabeln aus alten Blöcken, wenn die Oberseite ziemlich lebendig ist.
4. Die Altersgrenze in absoluten Zeiteinheiten für den Einsatz von Pfählen ist für Stabilität und Sicherheit erforderlich.
5. Stake Hash sollte sich nur ab Blockzeit ändern.
6. Der Stake-Modifikator sollte nicht an den Stake-Eingabeblock gebunden sein.
7. Das Arbeiten mit Blockheadern erfordert eine spezielle Verarbeitung im Netzwerk und während der Neuindizierung.
8. CoinStake werden in der lokalen Brieftasche aufgezeichnet und erfordern einige Änderungen für die korrekte Anzeige von Orfans.
9. PoS-Miner haben höchstwahrscheinlich genug Pfosten und müssen mit einer Datei finalisiert werden.
10. Re-Index muss verbessert werden, weil Es funktioniert analog zu Headern - zuerst wird nur der Index der Blöcke geladen und überprüft, und dann wird nur versucht, die Blöcke zu verarbeiten.
11. Wenn der Übergang zu PoS nicht fest codiert ist, sondern über Spork, müssen Sie ihn beim Booten abfangen, weil Sporks werden nicht gespeichert.
12. Checkpoints in Dash und Bitcoin sind fast eine Täuschung und erfordern eine sehr ernsthafte Überarbeitung.
13. Wenn die Dash-Gabel bis Version 0.13 ist, gibt es Probleme bei der Verarbeitung von Masterknotendaten im einfachen Benutzermodus.
    
    • Bei häufigem Neustart des Clients wird die Netzwerkansicht verzerrt.
    • Es ist besser, den Cache einfach zu ignorieren, wenn er im grafischen Modus ausgeführt wird.
14. Ändern Sie die Auswahl des besten Blocks unter Berücksichtigung der Blockzeit.
15. Bitcoin .
16. mempool CoinStake .

. mainnet PoW , , PoS, . PoS Ethereum Casper'.

GPU - — ethminer'. 150-200 GH (ethash). - PoS .

PoS PIVX 2.x " ". - PIVX , , . , PIVX 2.x . Dash 0.12 Bitcoin'.

, PoS . , , .

Die Dokumentation

. . whitepaper -.

PoS PIVX Bitcoin/Dash. CoinStake . PoS .

, Stake Modifier Stake Hash , Stake Input . - , - PIVX .

— . :

1. .
2. .
3. — .. , .
4. , - , .

. spork' , .

, . spork' .

PoS

, - . spork, , .

, .. . , .

testnet, .

testnet 3 1 mainnet, .

PoW , PoS - , 1e6 PoW.

. mainnet Stake Input.

.

PoS

X spork PoS . - , .

. , . .

, , .

Stake Modifier . . PIVX - … , , Ethereum, .

Fazit

- , . , PoS , . .

: - .

GitHub