So wird man zum Avalanche (AVA)-Validator
Avalanche (AVA)-Validator - Worum geht es da?
Avalanche (Ava) ist eine Open-Source Plattform für hochdezentralisierte Applikationen, so genannten "Financial Primitives" und unterstützt auch Blockchains mit der Fähigkeit zur Interoperabilität. Viel interessanter - und unter anderem auch der Grund, warum Avalanche derzeit sehr viel Aufmerksamkeit zukommt - ist die unter dem Namen "Snow-Avalanche" bekannte neuartige Consensus-Protokollfamilie, die vor kurzem von Ava-Labs, dem Team hinter Avalanche, vorgestellt wurde. Wer mehr darüber wissen möchte dem empfehle ich folgendes Video mit Prof. Emin Gün Sirer, einem der Gründerväter von Ava Labs.
In diesem Artikel beschäftigen wir uns nicht damit, welch großes Potenzial hinter Ava steckt (dazu gibt es bereits sehr viele Artikel, z.B. hier auf hackernoon) sondern damit, wie ihr euch selbst in nur 10 Minuten einen eigenen AVA-Valdiator aufsetzen und am Testnet teilnehmen könnt.
Voraussetzungen für die Installation
Der nun folgende Guide stammt direkt von AVA-Labs und ist im englischen Original hier zu finden
Für die folgenden Installationsschritte braucht ihr unbedingt:
- Ein System mit Ubuntu 18.04 oder Mac OS >= Catalina. Für die Windows-Enthusiasten unter euch empfehle ich die Installation einer VirtualBox mit Ubuntu, dazu einfach die LTS-Version hier herunterladen und über die VirtualBox starten. Achtung: Ihr solltet der virtuellen Maschine auf alle Fälle 2 Cores und mindestens 4 GB RAM zuweisen, sonst wird die Installation unter Umständen nicht funktionieren.
- Git für das Clonen der Repositories (sudo apt-get install git auf der Konsole reicht dazu)
- und golang in einer 1.13er Version. Da die Ubuntu-Repos bereits 1.14er-Versionen listen ladet ihr euch eine 1.3er am besten selbst herunter, entpackt diese und installiert die Version selbst. Wie das funktioniert seht ihr hier.
Soweit wären wir fertig, wir können nun also mit dem Setup unseres Validators starten.
Wir starten unseren Node
Im ersten Schritt installieren wir uns Gecko, der Go-Implementation eines Ava-Nodes, und verbinden uns mit dem Ava-Testnet. Dazu benötigen wir noch folgende Libraries:
sudo apt-get install libssl-dev libuv1-dev cmake make curl g++
Anschließend laden wir uns den Gecko-Sourcecode herunter ...
cd $GOPATH
mkdir -p src/github.com/ava-labs
cd src/github.com/ava-labs
git clone https://github.com/ava-labs/gecko.git
cd gecko
(Die Variable GOPATH wurde in dem von mir verlinkten Artikel zur Installation von Go 1.13 gesetzt, ist im Prinzip nichts Anderes als das Working-Directory von GO)
... und bauen abschließend noch das Executable
./scripts/build.sh
Im build Ordner findet ihr nun das fertige Binary mit dem Namen ava
Erstellen eines Key und eines Zertifikates für unseren Node
Um sich gegenüber anderen Nodes im Netzwerk authentifizieren zu können nutzt ein Node ein TLS-Zertifikat. Um dieses für unseren Node zu erstellen lassen wir einfach das folgende Script laufen:
sh keys/genStaker.sh
Wichtig: staker.key, staker.crt sowie staker.csr in keys dürfen unter keinen Umständen verändert oder gelöscht werden, ansonsten wäre die Identifizierung unseres Nodes gegenüber anderen Nodes im Netzwerk nicht mehr möglich.
Eine erneute Durchführung des Scripts hat keine Auswirkung, ihr seht lediglich eine Logmessage, dass der Key bzw. das Zertifikat nicht erstellt wurden.
Verbindung mit dem Public Testnet
Das AVA Public Testnet ist eine Sandbox in der die AVA Tokens frei verfügbar sind. Diese dienen dazu um das Netzwerk uneingeschränkt ausprobieren und testen zu können.
Um unseren Knoten zu starten und diesen mit dem AVA Testnet zu verbinden benötigen wir folgenden Befehl:
./build/ava
ASCII-Art weist uns nun darauf hin, dass der Node gestartet wird. Solltet ihr Warnings sehen diese bitte einfach ignorieren.
Solltet ihr den Node stoppen wollen so geht das einfach mit der Tastenkombination STRG+C
Abschließend findet ihr hier noch einen Guide, wie ihr euch ein lokales Testnet aufsetzen könnt.
Testen der Verbindung
Um zu überprüfen, ob unser Node mit anderen Nodes im Netzwerk verbunden ist, rufen wir admin.peers per curl auf (dazu bitte unbedingt eine zweites Terminalfenster starten und den vorhin gestarteten Node laufen lassen!):
curl -X POST --data '{
"jsonrpc": "2.0",
"method": "admin.peers",
"params":{},
"id": 1
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/admin
Im Response solltet ihr nun eine handvoll IP-Adressen sehen. Wenn nicht, so ist euer Knoten nicht mit den Netzwerk verbunden. Ein Grund dafür könnten fehlende oder restriktive Port-Forwarding-Einstellungen in eurem Router sein. Sollten die Probleme weiter bestehen wird euch sicher im Discord-Channel von Avalanche weitergeholfen.
Erstellen eines Keystore Users
AVA Nodes besitzen out-of-the-Box einen Keystore, welcher ein simples Usermanagement ermöglicht. Ein User ist eine Passwort geschützte Identität welche ein bestimmter Client benutzen kann um mit verschiedenen Blockchains zu interagieren. Dabei handelt es sich um eine m:n-Verbindung, ein User kann also für mehrere Blockchains verwendet werden, ein Client unterstützt gleichzeitig auch mehrere User.
Um einen User anzulegen rufen wir keystore.createUser auf:
curl -X POST --data '{
"jsonrpc": "2.0",
"id": 1,
"method": "keystore.createUser",
"params": {
"username": "YOUR USERNAME HERE",
"password": "YOUR PASSWORD HERE"
}
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/keystore
Achtung: Username und Password bitte mit dementsprechenden Werten versehen
Der Response sieht hier folgendermaßen aus:
{
"jsonrpc":"2.0",
"result":{"success":true},
"id":1
}
Im Falle eines positiven Response haben wir uns also erfolgreich einen User angelegt. Die Keystore-Daten existieren auf Node-Ebene, das bedeutet gleichzeitig auch, dass die Daten nur auf diesem Node existieren. Diese können aber auf anderen Knoten importiert/exportiert werden. Details dazu findet ihr in der Keystore API.
Erstellen einer Adresse
AVA ist ein Netzwerk von heterogenen Blockchains. Eine dieser heterogenen Chains ist die so genannte X-Chain, welche als dezentralisierte Plattform für die Erstellung und dem Trading von digitalen Assets dient (das X steht dabei für "eXchanging Assets")
Der native Token auf der X-Chain heißt AVA, dieser wird auch dazu benutzt um die Transaction-Fees im AVA Netzwerk zu bezahlen.
Im nächsten Schritt besorgen wir uns AVA-Tokens. Dazu brauchen wir erstmal eine Adresse um diese sicher zu verwahren. Für die Erstellung dieser Adresse rufen wir avm.createAddress auf, eine Methode der X-Chain-API:
curl -X POST --data '{
"jsonrpc":"2.0",
"id" :2,
"method" :"avm.createAddress",
"params" :{
"username":"YOUR USERNAME HERE",
"password":"YOUR PASSWORD HERE"
}
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/bc/X
Achtung: Hier müssen wir wieder den Usernamen und das Passwort unseres Keystore-Users angeben.
Diesen Request setzen wir gegen 127.0.0.1:9650/ext/bc/X ab. Der Teil bc/X des Calls zeigt an, dass wir den Request gegen die Chain mit der ID (or dem Alias) X absetzen, also gegen die X-Chain.
Der Response sollte folgendermaßen aussehen:
{
"jsonrpc":"2.0",
"id":2,
"result" :{
"address":"X-5TQr5hSAZ8ZKuSaYLg5sr4VwvcvwKZ1Mg"
}
}
Unser User verfügt also hier über die Adresse X-5TQr5hSAZ8ZKuSaYLg5sr4VwvcvwKZ1Mg auf der X-Chain. Um Adressen auf den unterschiedlichen Chains unterscheiden zu können existiert bei AVA die Konvention, dass die Adresse die ID der Chain beinhaltet. Unsere Adresse startet mit X und zeigt dementsprechend an, dass es sich um eine X-Chain-Adresse handelt.
Erwerben von AVA-Tokens
Wir verwenden nun das AVA Testnet Faucet um eine handvoll AVA-Token an diese Adresse zu senden. Das Faucet verschickt 20000 nanoAVA (nAVA) an jene Adresse, die wir hier angeben.
Wir befinden uns hier nach wie vor im Testnet, die so versendeten AVA-Token haben also keinen Gegenwert, die Token können beliebig oft und von jedermann generiert und versendet werden.
Um die AVA-Token zu bekommen einfach die Faucet-Seite aufrufen und die generierte Adresse eingeben um die 20000 nAVA zu erhalten. Nach dem Versenden der Token können wir mit einem Call gegen avm.getBalance - einer weiteren Methode der X-Chain API - kontrollieren, ob die Token bereits angekommen sind:
curl -X POST --data '{
"jsonrpc":"2.0",
"id" :3,
"method" :"avm.getBalance",
"params" :{
"address":"X-5TQr5hSAZ8ZKuSaYLg5sr4VwvcvwKZ1Mg",
"assetID" :"AVA"
}
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/bc/X
Wichtig ist hier die spezielle AVA-ID. Die ID eines Assets ist typischerweise ein alphanumerischer String.
Der Response sollte folgendermaßen aussehen:
{
"jsonrpc":"2.0",
"id" :3,
"result" :{
"balance":20000
}
}
AVA versenden
Wir versenden nun ein paar unserer AVA:
curl -X POST --data '{
"jsonrpc":"2.0",
"id" :5,
"method" :"avm.send",
"params" :{
"username" :"YOUR USERNAME HERE",
"password" :"YOUR PASSWORD HERE",
"assetID" :"AVA",
"amount" :1000,
"to" :"X-FxgGhoAwg3dPTPhHEmjgi27ZPmvc8jQmj"
}
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/bc/X
amount spezifiziert, wie viele nAVA wir versenden wollen. Ein nAVA (nanoAVA) ist der kleinste Bestandteil eines AVA-Tokens: 1.000.000.000 nAVA == 1 AVA.
Sobald wir diesen Request absetzen authentifiziert uns der Node mit dem mitgesendeten Usernamen und dem Passwort. Der Node durchsucht nun alle Private Keys des Users bis es genug nAVA findet um den Request durchführen zu können.
Der Response sollte folgendermaßen aussehen:
{
"jsonrpc":"2.0",
"id" :5,
"result" :{
"txID":"2QouvFWUbjuySRxeX5xMbNCuAaKWfbk5FeEa2JmoF85RKLk2dD"
}
}
txID ist die ID der send-Transaktion welche wir gerade gegen das Netzwerk abgesetzt haben. Die ID ist für jeden send-Vorgang eindeutig.
Überprüfen des Status unserer Transaktion
Die send-Transaktion wird nun ein paar Sekunden benötigen. Wir können den Status der Transaktion mit einem Call gegen avm.getTxStatus jederzeit überprüfen:
curl -X POST --data '{
"jsonrpc":"2.0",
"id" :6,
"method" :"avm.getTxStatus",
"params" :{
"txID":"2QouvFWUbjuySRxeX5xMbNCuAaKWfbk5FeEa2JmoF85RKLk2dD"
}
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/bc/X
Der Response sollte folgendermaßen aussehen:
{
"jsonrpc":"2.0",
"id" :6,
"result" :{
"status":"Accepted"
}
}
Anstatt "Accepted" könnte hier im Feld status auch Pending stehen. Dies würde anzeigen, dass die Transaktion noch nicht abgeschlossen wurde.
Sobald die Transaktion abgeschlossen (Status Accepted) wurde können wir die Zieladresse überprüfen um zu sehen, ob die nAVA tatsächlich angekommen sind:
curl -X POST --data '{
"jsonrpc":"2.0",
"id" :7,
"method" :"avm.getBalance",
"params" :{
"address":"X-FxgGhoAwg3dPTPhHEmjgi27ZPmvc8jQmj",
"assetID" :"AVA"
}
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/bc/X
Der Response sollte folgendermaßen aussehen:
{
"jsonrpc":"2.0",
"id" :7,
"result" :{
"balance":1000
}
}
Wir könnten hier natürlich auch die Balance unserer eigenen Adresse X-5TQr5hSAZ8ZKuSaYLg5sr4VwvcvwKZ1Mg kontrollieren um zu sehen, ob die nAVA dementsprechend abgezogen wurden.
Valdierung des Default Subnets (Staking)
Subnets sind ein mächtiges Feature des AVA Netzwerks. Ein Subnetz ist nichts anderes als eine Reihe von Validatoren die zusammenarbeiten um einen Consensus in einer Reihe von Blockchains erzielen zu können.
Das Default Subnet ist bereits im AVA Netzwerk integriert und validiert die AVA-interne Blockchain. AVA verwendet Proof-of-Stake, man muss also einen Teil seiner AVA-Tokens staken (oder bonden) um ein Validator werden zu können.
Im nächsten Schritt fügen wir nun unseren Node zum Default Subnet hinzu.
P-Chain Account erstellen
Die P-Chain (Platform Chain) verwaltet Metadaten des AVA-Netzwerks, unter anderem auch, welche Nodes zu welchem Subnet gehören. Die P-Chain verwendet dazu Accounts, man muss sich also im ersten Schritt einen Account erstellen um das Default Subnet validieren zu können. Für die Erstellung des Accounts rufen wir platform.createAccount auf:
curl -X POST --data '{
"jsonrpc": "2.0",
"method": "platform.createAccount",
"params": {
"username":"YOUR USERNAME HERE",
"password":"YOUR PASSWORD HERE"
},
"id": 1
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/P
Wir sehen hier, dass dieser API Call, entgegen unserer vorherigen Calls , gegen die P-Chain (127.0.0.1:9650/ext/P) und nicht gegen die X-Chain (127.0.0.1:9650/ext/X) abgesetzt wird.
Der Response beinhaltet die Adresse unseres neuen Accounts:
{
"jsonrpc": "2.0",
"result": {
"address": "Bg6e45gxCUTLXcfUuoy3go2U6V3bRZ5jH"
},
"id": 1
}
Auf den P-Chain Account einzahlen
Wie bereits angemerkt müssen wir unsere AVA Token staken um im Default Subnet validieren zu können. Aktuell verfügt unser P-Chain Account noch über keinerlei AVA. AVA Token sind aber zwischen der X-Chain (dort, wo wir durch das Faucet AVA-Token erhalten haben) und der P-Chain transferierbar. Wir senden uns nun also von der X-Chain einige AVA auf unseren P-Chain Account. Der Mindestbetrag an AVA um Staken zu können sind 10.000 nAVA, wir benötigen also zumindest so viele Token in unseren X-Chain Adressen (sollte man mehr brauchen können diese über das Faucet auch mehrmals hintereinander geclaimed werden).
Im ersten Schritt transferieren wir nun AVA von der X-Chain auf die P-Chain, dazu rufen wir avm.exportAVA auf:
curl -X POST --data '{
"jsonrpc":"2.0",
"id" :1,
"method" :"avm.exportAVA",
"params" :{
"to":"Bg6e45gxCUTLXcfUuoy3go2U6V3bRZ5jH",
"amount": 10000,
"username":"YOUR USERNAME HERE",
"password":"YOUR PASSWORD HERE"
}
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/bc/X
Der Response beinhaltet die ID der Transaktions. Wir können den Status der Transaktion genauso wie vorher abfragen indem wir avm.getTxStatus aufrufen.
Der zweite und finale Schritt ist nun der Aufruf von platform.importAVA:
curl -X POST --data '{
"jsonrpc": "2.0",
"method": "platform.importAVA",
"params": {
"username":"YOUR USERNAME HERE",
"password":"YOUR PASSWORD HERE",
"to":"Bg6e45gxCUTLXcfUuoy3go2U6V3bRZ5jH",
"payerNonce":1
},
"id": 1
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/bc/P
payerNonce ist der nächste freie Nonce unseres P-Chain Accounts, dieser ist 1 da wir mit unserem P-Chain Account noch keine Transaktionen durchgeführt haben.
Der Response beinhaltet die Transaktion:
{
"jsonrpc": "2.0",
"result": {
"tx": "1117xBwcr5fo1Ch4umyzjYgnuoFhSwBHdMCam2wRe8SxcJJvQRKSmufXM8aSqKaDmX4TjvzPaUbSn33TAQsbZDhzcHEGviuthncY5VQfUJogyMoFGXUtu3M8NbwNhrYtmSRkFdmN4w933janKvJYKNnsDMvMkmasxrFj8fQxE6Ej8eyU2Jqj2gnTxU2WD3NusFNKmPfgJs8DRCWgYyJVodnGvT43hovggVaWHHD8yYi9WJ64pLCvtCcEYkQeEeA5NE8eTxPtWJrwSMTciHHVdHMpxdVAY6Ptr2rMcYSacr8TZzw59XJfbQT4R6DCsHYQAPJAUfDNeX2JuiBk9xonfKmGcJcGXwdJZ3QrvHHHfHCeuxqS13AfU"
},
"id": 1
}
Diese können wir nun an die P-Chain kommunizieren indem wir platform.issueTx aufrufen:
curl -X POST --data '{
"jsonrpc": "2.0",
"method": "platform.issueTx",
"params": {
"tx":"1117xBwcr5fo1Ch4umyzjYgnuoFhSwBHdMCam2wRe8SxcJJvQRKSmufXM8aSqKaDmX4TjvzPaUbSn33TAQsbZDhzcHEGviuthncY5VQfUJogyMoFGXUtu3M8NbwNhrYtmSRkFdmN4w933janKvJYKNnsDMvMkmasxrFj8fQxE6Ej8eyU2Jqj2gnTxU2WD3NusFNKmPfgJs8DRCWgYyJVodnGvT43hovggVaWHHD8yYi9WJ64pLCvtCcEYkQeEeA5NE8eTxPtWJrwSMTciHHVdHMpxdVAY6Ptr2rMcYSacr8TZzw59XJfbQT4R6DCsHYQAPJAUfDNeX2JuiBk9xonfKmGcJcGXwdJZ3QrvHHHfHCeuxqS13AfU"
},
"id": 1
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/bc/P
Wir kontrollieren nun, ob die Token am P-Chain Account vorhanden sind indem wir platform.getAccount aufrufen:
curl -X POST --data '{
"jsonrpc": "2.0",
"method": "platform.getAccount",
"params":{
"address":"Bg6e45gxCUTLXcfUuoy3go2U6V3bRZ5jH"
},
"id": 1
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/bc/P
Der Response sollte folgendermaßen aussehen:
{
"jsonrpc": "2.0",
"result": {
"address": "Bg6e45gxCUTLXcfUuoy3go2U6V3bRZ5jH",
"nonce": "1",
"balance": "10000"
},
"id": 1
}
Perfekt! Unser P-Chain Account verfügt nun über genügend Token um staken zu können.
Ermitteln der Node-ID
Unser Node ist durch das zuvor per genStaker.sh generierte TLS-Zertifikat eindeutig identifizierbar. Um die ID des Nodes auslesen zu können rufen wir admin.getNodeID auf:
curl -X POST --data '{
"jsonrpc": "2.0",
"method": "admin.getNodeID",
"params":{},
"id": 1
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/admin
Der Response beinhaltet die ID unseres Nodes:
{
"jsonrpc": "2.0",
"result": {
"nodeID": "ARCLrphAHZ28xZEBfUL7SVAmzkTZNe1LK"
},
"id": 1
}
Erstellen einer nicht-signierten Transaktion
Um unseren Node zum Default Subnet hinzuzufügen müssen wir eine Transaktion gegen die P-Chain absetzen. Wenn wir den Knoten zum Default Subnet hinzufügen müssen wir folgende Parameter angeben:
- id: Die ID des Nodes, der hinzugefügt werden soll
- payerNonce: Der nächste freie Nonce des Accounts, welcher die Transaktionsgebühr (die Gebühr ist derzeit 0) und die gestakten AVA Token stellt
- destination: Die Adresse, auf welche die AVA (gemeinsam mit den Validator Rewards) zurücküberwiesen werden sobald der Node nicht mehr validiert
- startTime: Der Unix Timestamp der angibt, wann der Node mit der Validierung des Default Subnets beginnt.
- endTime: Der Unix Timestamp der angibt, wann der Node mit der Validierung im Default Subnet stoppt.
startTime und endTime sind dabei jene Werte, wo es am ehesten zu Problemen kommen kann.
startTime muss in der Zukunft liegen, relativ zu dem Zeitpunkt, wo die Transaktion ausgestellt wurde. Die aktuelle Unix Zeit kann man hier ablesen. Im folgenden Script verwenden wir das Shell Command date um den Unix Timestamp 5 Minuten in der Zukunft zu erhalten.
endTime muss zwischen 1 Tag (der minimalen Staking-Periode) und 365 Tagen (die maximale Staking-Periode) nach startTime liegen. Im folgenden Script verwenden wir das Shell Command date um den Unix Timestamp 2 Tage in der Zukunft zu erhalten.
Nun erstellen wir die noch unsignierte Transaktion:
curl -X POST --data '{
"jsonrpc": "2.0",
"method": "platform.addDefaultSubnetValidator",
"params": {
"id":"ARCLrphAHZ28xZEBfUL7SVAmzkTZNe1LK",
"payerNonce":2,
"destination":"Bg6e45gxCUTLXcfUuoy3go2U6V3bRZ5jH",
"startTime":'$(date --date="5 minutes" +%s)',
"endTime":'$(date --date="2 days" +%s)',
"stakeAmount":10000
},
"id": 1
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/P
Im Response erhalten wir die unsignierte Transaktion:
{
"jsonrpc": "2.0",
"result": {
"unsignedTx": "111fRKBNoBhBfeGvBzvz6r9dZUKbEnUypM6tjiSyYrWM4ojSTuL2Syxv8cFLphtYaxdM1EA3Aj4yej8ABSfmjb9NMrtxQac9cnWwCER7GHSzFULB25hAtzGtJ8XhsrKcvtpAM8FwjRzg3Bg1q6V8GTKGMC219bYMETS48GMFGh4nts1Jsf246rjZ26r1Vyok8MdnoaxjQWR6cKq"
},
"id": 1
}
Signieren der Transaktion
Wir müssen nun die Transaktion mit dem Key jenes Accounts, welcher die Transaktionsgebühren und die Tokens für das Staking stellt. Dazu rufen wir platform.Sign auf
curl -X POST --data '{
"jsonrpc": "2.0",
"method": "platform.sign",
"params": {
"tx":"111fRKBNoBhBfeGvBzvz6r9dZUKbEnUypM6tjiSyYrWM4ojSTuL2Syxv8cFLphtYaxdM1EA3Aj4yej8ABSfmjb9NMrtxQac9cnWwCER7GHSzFULB25hAtzGtJ8XhsrKcvtpAM8FwjRzg3Bg1q6V8GTKGMC219bYMETS48GMFGh4nts1Jsf246rjZ26r1Vyok8MdnoaxjQWR6cKq",
"signer":"Bg6e45gxCUTLXcfUuoy3go2U6V3bRZ5jH",
"username":"YOUR USERNAME HERE",
"password":"YOUR PASSWORD HERE"
},
"id": 2
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/P
So erhalten wir die signierte Transaktion:
{
"jsonrpc": "2.0",
"result": {
"Tx": "111fRKBNoBhBfeGvBzvz6r9dZUKbEnUypM6tjiSyYrWM4ojSTuL2Syxv8cFLphtYaxdM1EA3Aj4yej8ABSfmjb9NMrtxQac9cnWwCER7GHSzFULB4RoAjStfe26qQxhS91KvCCX3WBLmpyvNXHzgWk3uJP45cPv15RHGymFboPUcxNTwGij1NgQpKPcL4YxcDnKvNjrcQzKiXAz"
},
"id": 2
}
Absetzen der Transaktion
Abschließend setzen wir die Transaktion gegen das Netzwerk ab indem wir platform.issueTx aufrufen:
curl -X POST --data '{
"jsonrpc": "2.0",
"method": "platform.issueTx",
"params": {
"tx":"111fRKBNoBhBfeGvBzvz6r9dZUKbEnUypM6tjiSyYrWM4ojSTuL2Syxv8cFLphtYaxdM1EA3Aj4yej8ABSfmjb9NMrtxQac9cnWwCER7GHSzFULB4RoAjStfe26qQxhS91KvCCX3WBLmpyvNXHzgWk3uJP45cPv15RHGymFboPUcxNTwGij1NgQpKPcL4YxcDnKvNjrcQzKiXAz"
},
"id": 3
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/P
Hier könnten nun Fehlermeldungen durch den Node ausgegeben werden, die darauf hindeuten, dass startTime in der Vergangenheit liegt. Falls dem so ist muss die Transaktion nochmal mit den korrekten Parametern ausgestellt werden.
Waren wir erfolgreich?
Nun rufen wir platform.getPendingValidators auf um zu sehen, ob unser Node zu den hinzuzufügenden Validatoren des Default Subnets gehört. In der Response befinden sich alle Knoten, die zukünftig im Default Subnet zu validieren beginnen werden.
Wenn wir keine Argumente mitgeben gibt uns die Methode eine komplette Übersicht über alle zum Default Subnet hinzuzufügenden Validatoren zurück:
curl -X POST --data '{
"jsonrpc": "2.0",
"method": "platform.getPendingValidators",
"params": {},
"id": 4
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/P
Der Response sollte uns nun anzeigen, dass unser Node mit der ID ARCLrphAHZ28xZEBfUL7SVAmzkTZNe1LK bald mit der Validierung des Default Subnets beginnen wird.
{
"jsonrpc": "2.0",
"result": {
"validators": [
{
"id": "ARCLrphAHZ28xZEBfUL7SVAmzkTZNe1LK",
"startTime": "1584021450",
"endtime": "1584121156",
"stakeAmount": "10000",
}
]
},
"id": 4
}
Perfekt! Nun warten wir bis startTime beginnt. Sobald es soweit ist wird unser Knoten mit der Validierung im Default Subnet beginnen. Wir können dies auch mit einem Aufruf von platform.getCurrentValidators kontrollieren.
Sobald endTime erreicht ist wird unser P-Chain Account, welchen wir vorher in der destination angegeben haben, die gestakten AVA und den Reward für die Validierung erhalten. Anschließend kann man den Knoten wieder als Validator im Default Subnet hinzufügen, wenn man das möchte.
Nun da dein Node das Default Subnet validiert sollte dieser bitte bis zum Erreichen von endTime laufen gelassen werden. Wir möchten so viele Teilnehmer am Consensus wie möglich erreichen um das AVA Netzwerk stresstesten zu können und eine echte Dezentralisierung erreichen zu können. Wichtig ist hier noch, dass man in Zukunft nur dann einen Reward für die Validierung erhält wenn der Knoten erreichbar (also online) ist während der Validierung.