Server<\/a> Es ist eine anspruchsvolle Aufgabe, einen Blockchain-Start mit engagierten, aber unabh\u00e4ngigen Teilnehmern zu erm\u00f6glichen. W\u00e4hrend in einem Unternehmen die Administratoren beim Start v\u00f6lligen Zugriff auf alle Maschinen, Protokolle und das allgemeine Monitoring haben, werden die Validierer niemanden an ihre Server heranlassen. Sie werden wahrscheinlich vorziehen, ihre eigene Infrastruktur aufzubauen, da diese den Zugang zu den wichtigsten Verm\u00f6genswerten der Validierer \u2013 den Stimmenstacks \u2013 kontrolliert. Dieses Verhalten erm\u00f6glicht den Aufbau verteilter, sicherer Netzwerke \u2013 die Unabh\u00e4ngigkeit der verwendeten Cloud-Anbieter, virtuellen und \u201eBaremetal\u201c-Server sowie unterschiedliche Betriebssysteme machen Angriffe auf ein solches Netzwerk sehr ineffektiv, da eine Vielzahl verschiedener Software genutzt wird. Zum Beispiel verwendet Ethereum zwei Hauptimplementierungen der Nodes, eine in Go und eine in Rust; ein Angriff, der f\u00fcr eine Implementierung wirksam ist, funktioniert nicht f\u00fcr die andere.<\/p>\n<\/p>\n
Daher m\u00fcssen alle Prozesse f\u00fcr den Start und Betrieb von Blockchains so organisiert sein, dass jeder Validator oder sogar eine kleine Gruppe von Validatoren jederzeit ihre Computer aus dem Fenster werfen und gehen k\u00f6nnen, ohne dass dadurch etwas kaputtgeht. Die verbleibenden Validatoren sollten in der Lage sein, weiterhin effizient das Netzwerk zu unterst\u00fctzen und neue Validatoren anzuschlie\u00dfen. Beim Start des Netzwerks, wenn ein Validator in Europa, der zweite in S\u00fcdamerika und der dritte in Asien ist, ist es recht schwierig, die koordinierte Zusammenarbeit mehrerer unabh\u00e4ngiger Gruppen zu gew\u00e4hrleisten und ihr Interesse am Ergebnis zu wecken. <\/p>\n
<\/p>\n
Validatoren<\/h2>\n <\/p>\n
Stellen Sie sich den Start eines hypothetischen modernen Blockchain-Projekts vor (der Gro\u00dfteil der beschriebenen Aspekte gilt f\u00fcr Blockchains basierend auf jeder modernen Blockchain-Familie: Ethereum, EOS, Polkadot, Cosmos und andere, die Konsensmechanismen auf Basis von Proof-of-Stake verwenden). Die Hauptakteure solcher Blockchains sind Validatoren-Teams, die eigene unabh\u00e4ngige Server einrichten, um neue Bl\u00f6cke zu validieren und zu erzeugen und daf\u00fcr von der jeweiligen Blockchain Belohnungen erhalten, die f\u00fcr die Teilnahme am Konsens vorgesehen sind. F\u00fcr den Start neuer Netzwerke werden mehrere Dutzend Validatoren ben\u00f6tigt (so viele, dass sie derzeit mehr oder weniger effizient innerhalb von Sekunden Konsens erreichen k\u00f6nnen). Daher k\u00fcndigt das Projekt eine Registrierung an, bei der die Validatoren \u00f6ffentliche Informationen \u00fcber sich mit den Nutzern teilen, um sie davon zu \u00fcberzeugen, dass sie beabsichtigen, das gestartete Netzwerk qualitativ hochwertig zu betreuen.<\/p>\n
<\/p>\n
Validatoren sind Unternehmen, die es erm\u00f6glichen, das potenzielle Einkommen von Validatoren \u00e4u\u00dferst pr\u00e4zise zu bewerten, Ressourcen schnell zwischen Projekten zu transferieren und im Falle des Erfolgs des gew\u00e4hlten Netzwerks kann der Validator als vollwertiges Mitglied des DAO und verantwortliche Person das Projekt weiterentwickeln oder einfach einen hervorragenden technischen Service f\u00fcr transparent verdientes Geld anbieten. Bei der Berechnung der Belohnungen f\u00fcr Validatoren versuchen die Projekte, die Kosten der Validatoren zu ber\u00fccksichtigen und die Blockbelohnung so zu gestalten, dass dieses Gesch\u00e4ft profitabel ist, ohne dass Validatoren die Wirtschaft destabilisieren, indem sie sie mit Geld \u00fcberfluten und anderen Nutzern des Netzwerks schaden.<\/p>\n
<\/p>\n
Das Betreiben von Validatoren erfordert eine hohe Ausfallsicherheit der Dienste, was wiederum ein hohes Niveau an Kenntnissen bei DevOps und Entwicklern sowie kostspielige Rechenressourcen voraussetzt. Selbst ohne die Notwendigkeit, Hashes in Proof-of-Work-Netzwerken zu minen, ist ein Blockchain-Knoten ein gro\u00dfer Dienst, der viel Speicher ben\u00f6tigt, viel Rechenleistung verbraucht, validiert, Daten auf die Festplatte schreibt und gro\u00dfe Datenmengen \u00fcber das Netzwerk \u00fcbertr\u00e4gt. Um die Logdateien von Transaktionen und Blockchains mit mehreren tausend kleinen Transaktionen pro Block zu speichern, wird derzeit ein Speicherplatz von mindestens 50 GB und mehr gefordert, und daf\u00fcr sollte es sich um SSD-Speicher handeln. Die State-Datenbanken von Blockchains, die Smart Contracts unterst\u00fctzen, k\u00f6nnen bereits mehr als 64 GB RAM \u00fcberschreiten. Server mit den erforderlichen Spezifikationen sind recht kostspielig; ein Ethereum- oder EOS-Knoten kann zwischen 100 und 200 $\/Monat kosten. F\u00fcgen Sie dazu die erh\u00f6hten L\u00f6hne f\u00fcr die 24\/7-Arbeit von Entwicklern und DevOps hinzu, die w\u00e4hrend der Startphase auch nachts Probleme l\u00f6sen, da sich einige Validatoren leicht auf der anderen Hemisph\u00e4re befinden k\u00f6nnen. Dennoch kann der Besitz eines Validator-Knotens in den richtigen Momenten signifikante Einnahmen bringen (im Fall von EOS bis zu 10.000 $ pro Tag).<\/p>\n
<\/p>\n
Die Validierung ist nur eine der neuen potenziellen IT-Rollen f\u00fcr Unternehmer und Unternehmen. Mit der Entwicklung immer raffinierterer Algorithmen durch Programmierer, die darauf abzielen, Ehrlichkeit zu belohnen und Betrug sowie Diebstahl zu bestrafen, entstehen Dienste, die wichtige Daten ver\u00f6ffentlichen (Orakel), \u00dcberwachungsfunktionen (Slash von Einlagen und Bestrafung von Betr\u00fcgern durch Ver\u00f6ffentlichung von Betrugsbeweisen), Streitbeilegungs- und Versicherungsgesch\u00e4fte sowie Optionen. Sogar die M\u00fcllabfuhr ist ein potenziell gro\u00dfer Markt in Smart-Contract-Systemen, wo f\u00fcr die Speicherung von Daten gezahlt werden muss. <\/p>\n
<\/p>\n
Herausforderungen beim Start eines Blockchains<\/h2>\n <\/p>\n
Die Offenheit der Blockchain, die eine Teilnahme am Netzwerk von Computern aus verschiedenen L\u00e4ndern erm\u00f6glicht, und die einfache Anbindung f\u00fcr jeden Script-Kiddie \u00fcber Anleitungen auf GitHub sind nicht immer Vorteile. Das Streben nach einem neuen Token zwingt Validierer oft dazu, \"eine neue M\u00fcnze zu minen\", in der Hoffnung auf einen Kursanstieg und die M\u00f6glichkeit, schnell die Gewinne zu realisieren. Au\u00dferdem bedeutet dies, dass Ihr Validierer jeder sein kann, auch anonym, und man kann genauso f\u00fcr ihn stimmen wie f\u00fcr andere Validierer (allerdings wird es f\u00fcr einen Anonymen schwierig sein, Stimmen von Stakeholdern zu sammeln, weshalb wir das gruselige Geschichtenerz\u00e4hlen \u00fcber anonyme Kryptow\u00e4hrungen den Politikern \u00fcberlassen). Dennoch<\/p>\n
<\/p>\n
Das Projektteam hat die Herausforderung, geeignete Personen in sein Netzwerk zu bringen, die in der Lage sind, einen stabilen Betrieb der Knoten zu gew\u00e4hrleisten, sich mit Sicherheitsfragen auszukkennen, Probleme schnell zu l\u00f6sen und mit anderen Validatoren zusammenzuarbeiten. Die Qualit\u00e4t des Tokens, in den die Netzwerkmitglieder investieren m\u00f6chten, h\u00e4ngt stark von diesen Eigenschaften ab. Vern\u00fcnftige Gr\u00fcnder verstehen bei der Bewertung von Risiken gut, dass beim Start einer Software in diesem Umfang unweigerlich Fehler im Code und in der Konfiguration der Knoten auftreten werden und dass die Stabilit\u00e4t des Netzwerks davon abh\u00e4ngt, wie gut Entwickler und Validatoren gemeinsam solche Probleme l\u00f6sen k\u00f6nnen.<\/p>\n
<\/p>\n
Das Team ist bereit, im Mainnet f\u00fcr jede Validatoren zu stimmen, aber es w\u00e4re gut zu wissen, f\u00fcr wen. Wer hat das gr\u00f6\u00dfte Portfolio? Das hat zurzeit fast niemand. Aufgrund der Profile des Teams auf LinkedIn? Erfahrene DevOps- oder Sicherheitsexperten werden keine Profile auf LinkedIn bereitstellen. Anhand von \u00c4u\u00dferungen im Chat, Beitr\u00e4gen und der Unterst\u00fctzung anderer in der Vorbereitungsphase? Gut, aber subjektiv und ungenau.<\/p>\n
<\/p>\n
In solchen Bedingungen bleibt nur eines \u2013 das, was die Probleme aller l\u00f6st \u2013 ein Spiel, in dem man die besten Validatoren ausw\u00e4hlen kann. Doch das Wichtigste ist, die Blockchain auf ihre Belastbarkeit zu testen und einen umfassenden Stresstest der Blockchain unter Bedingungen aktiver Nutzung, \u00c4nderungen im Konsens sowie dem Auftreten und der Behebung von Fehlern durchzuf\u00fchren. Diese Vorgehensweise wurde erstmals von den Leuten aus dem Projekt Cosmos als Spiel vorgestellt, und diese Idee ist zweifellos ein hervorragender Weg, um das Netzwerk auf den Start eines zuverl\u00e4ssigen und ausfallsicheren Mainnets vorzubereiten.<\/p>\n
<\/p>\n
Spiel der Validatoren<\/h2>\n <\/p>\n
Ich werde das Validator-Spiel so beschreiben, wie wir es f\u00fcr die DAO.Casino (DAOBet) Blockchain entworfen haben, basierend auf einem Fork von EOS, der Haya hei\u00dft und \u00fcber einen \u00e4hnlichen Governance-Mechanismus verf\u00fcgt \u2013 die Validatoren werden durch Abstimmungen von jedem Konto gew\u00e4hlt, wobei ein Teil des Guthabens, das zur Abstimmung f\u00fcr einen Validator verwendet wird, eingefroren wird. Jedes Konto, das das Haupt-Token BET im Guthaben hat, kann mit einem beliebigen Teil seines Guthabens f\u00fcr den gew\u00e4hlten Validator abstimmen. Die Stimmen werden summiert, und am Ende wird eine Liste der besten Validatoren erstellt. In verschiedenen Blockchains wird dieser Prozess unterschiedlich organisiert, und normalerweise unterscheidet sich genau hier die neue Blockchain von der parent Blockchain. Man muss sagen, dass in unserem Fall EOS das \u201eOS\u201c in seinem Namen vollst\u00e4ndig gerechtfertigt, denn wir nutzen tats\u00e4chlich EOS als Basis-Betriebssystem zur Bereitstellung einer modifizierten Version der Blockchain f\u00fcr die Aufgaben von DAOBet.<\/p>\n
<\/p>\n
Ich werde spezifische Probleme beschreiben und wie man diese innerhalb des Spiels l\u00f6sen kann. Stellen wir uns ein Netzwerk vor, in dem dein Server offen angegriffen werden kann. Um die Position eines Validierers zu halten, ist es erforderlich, kontinuierlich mit dem Netzwerk zu interagieren, den eigenen Validierer voranzubringen und sicherzustellen, dass er Bl\u00f6cke generiert, die rechtzeitig an die anderen Validierer geliefert werden. Andernfalls wird der Validierer aus der Liste entfernt.<\/p>\n
<\/p>\n
Wie w\u00e4hlt man die besten Gewinner aus?<\/h3>\n <\/p>\n
Das wichtigste technische Kriterium f\u00fcr das Spiel ist, dass die Ergebnisse \u00f6ffentlich \u00fcberpr\u00fcfbar sind. Das bedeutet, dass die Ergebnisse des Spiels: die TOP-Gewinner, ausschlie\u00dflich auf Daten basieren m\u00fcssen, die von jedem Teilnehmer \u00fcberpr\u00fcft werden k\u00f6nnen. In einem zentralisierten System k\u00f6nnten wir die \u201eUptime\u201c jedes Validierers messen und diejenigen belohnen, die am l\u00e4ngsten online waren oder den meisten Datenverkehr verarbeitet haben. Es k\u00f6nnten Daten zu CPU- und Speicherauslastung gesammelt werden, um diejenigen zu belohnen, die gut gearbeitet haben. Aber jede solche Datensammlung w\u00fcrde die Existenz eines zentralen Erfassers bedeuten, und auch die Knoten sind unabh\u00e4ngig und k\u00f6nnen sich verhalten, wie sie wollen, und beliebige Daten senden.<\/p>\n
<\/p>\n
Daher ist die naheliegende L\u00f6sung, dass die Gewinner anhand von Daten aus der Blockchain bestimmt werden, da diese zeigt, welcher Validator welchen Block erstellt hat und welche Transaktionen darin enthalten sind. Wir nennen diese Zahl Validator Points (VP), und deren Erwerb ist das Hauptziel der Validatoren im Spiel. In unserem Fall ist die einfachste, \u00f6ffentlich \u00fcberpr\u00fcfbare und effektive Metrik f\u00fcr die \"N\u00fctzlichkeit\" des Validators VP = Anzahl der vom Validator innerhalb eines bestimmten Zeitraums erzeugten Bl\u00f6cke.<\/p>\n
<\/p>\n
Diese einfache Wahl wird durch die Tatsache bedingt, dass die Governance in EOS bereits viele auftretende Probleme ber\u00fccksichtigt, da EOS der Nachfolger von drei Generationen funktionierender Blockchains mit umfangreicher Erfahrung in der komplexen Netzwerkverwaltung ist. Praktisch f\u00fchren alle Probleme eines Validators mit dem Netzwerk, dem Prozessor oder der Festplatte nur zu einem Problem \u2013 er signiert weniger Bl\u00f6cke und erh\u00e4lt eine geringere Bezahlung f\u00fcr seine Arbeit, was uns wieder einfach zur Anzahl der signierten Bl\u00f6cke f\u00fchrt \u2013 f\u00fcr EOS ist dies eine ausgezeichnete und einfache L\u00f6sung.<\/p>\n
<\/p>\n
Bei anderen Blockchains kann die Berechnung der Validator-Punkte unterschiedlich sein. Zum Beispiel f\u00fcr pBFT-basierte Konsensmechanismen (Tendermint\/Cosmos, Aura-Konsens aus Parity Substrate), wo jeder Block von mehreren Validatoren signiert werden muss, kann es sinnvoll sein, die einzelnen Signaturen der Validatoren zu z\u00e4hlen und nicht die Bl\u00f6cke. M\u00f6glicherweise sollte man auch nicht abgeschlossene Konsensrunden ber\u00fccksichtigen, die die Ressourcen anderer Validatoren verbrauchen. Insgesamt h\u00e4ngt dies stark vom Konsenstyp ab. <\/p>\n
<\/p>\n
Wie man realistische Betriebsbedingungen simuliert<\/h3>\n <\/p>\n
Die Aufgabe der Gr\u00fcnder besteht darin, Validatoren unter realistischen Bedingungen zu \u00fcberpr\u00fcfen, ohne dabei jegliche zentrale Kontrolle zu haben. Dieses Problem kann durch einen Faucet-Vertrag gel\u00f6st werden, der gleiche Mengen des Haupttokens an Validatoren und interessierte Nutzer verteilt. Um Tokens auf das Guthaben zu erhalten, muss eine Transaktion erstellt und die Netzwerk bereitgestellt werden, um sie in einen Block aufzunehmen. So ist es f\u00fcr den Validator erforderlich, regelm\u00e4\u00dfig sein Guthaben mit neuen Tokens aufzuf\u00fcllen und f\u00fcr sich selbst abzustimmen, um sich im Ranking nach oben zu bewegen. Diese Aktivit\u00e4t erzeugt eine st\u00e4ndige Belastung f\u00fcr das Netzwerk, und die Parameter k\u00f6nnen so angepasst werden, dass der Anfragefluss ausreichend hoch ist, um einen umfassenden Netzwerktest zu erm\u00f6glichen. Planen Sie daher den Faucet-Vertrag im Voraus als wichtiges Instrument zur Netzstart und beginnen Sie, seine Parameter rechtzeitig anzupassen.<\/p>\n
<\/p>\n
Die Anforderung von Tokens \u00fcber Faucets und die Abstimmung der Validatoren emuliert nicht vollst\u00e4ndig die Funktionsweise der Blockchain, insbesondere in stark belasteten Modi. Daher wird das Blockchain-Team letztendlich zus\u00e4tzliche Benchmarks erstellen m\u00fcssen, um das Netzwerk zu belasten. Eine besondere Rolle spielen hierbei zuvor speziell erstellte Smart Contracts, die es erm\u00f6glichen, einzelne Teilsysteme zu testen. Zur Testung des Speichers speichert der Vertrag zuf\u00e4llige Daten in der Blockchain, und um die Netzwerkressourcen zu \u00fcberpr\u00fcfen, ben\u00f6tigt der Testvertrag eine gro\u00dfe Menge an Eingabedaten, wodurch das Volumen der Transaktionen aufgebl\u00e4ht wird \u2013 indem solche Transaktionen zu beliebigen Zeitpunkten gestartet werden, testet das Team gleichzeitig die Stabilit\u00e4t des Codes und die Robustheit der Validatoren.<\/p>\n
<\/p>\n
Ein separates Thema ist die Aktualisierung des Node-Codes und die Durchf\u00fchrung von Hardforks. Es ist notwendig, dass die Validatoren einen Aktionsplan haben, der bereits im Validatoren-Spiel erprobt wurde, falls ein Fehler, eine Schwachstelle oder ein Komplott b\u00f6ser Validatoren auftritt. Hier k\u00f6nnten Modelle zur Vergabe von VP f\u00fcr die schnelle Implementierung eines Hardforks entwickelt werden, indem zum Beispiel alle Validatoren bestraft werden, die die neue Version des Node-Codes noch nicht installiert haben, doch das ist schwer umzusetzen und kompliziert die Berechnung. Eine Notfallsituation f\u00fcr die Implementierung eines Hardforks kann k\u00fcnstlich simuliert werden, indem die Blockchain an einem bestimmten Block \u201egebrochen\u201c wird. Die Produktion von Bl\u00f6cken stoppt, und letztendlich profitieren diejenige, die fr\u00fcher aktiv werden und mit dem Signieren von Bl\u00f6cken beginnen, wodurch VP basierend auf der Anzahl der unterschriebenen Bl\u00f6cke hier gut passt.<\/p>\n
<\/p>\n
<\/p>\n
Trotz des Misstrauens zwischen den Validatoren ist es f\u00fcr alle von Vorteil, rechtzeitig aktuelle Informationen \u00fcber den Zustand des Netzwerks zu erhalten, um schneller Entscheidungen treffen zu k\u00f6nnen. Daher initiiert das Projektteam einen Service zur Erfassung und Visualisierung verschiedener Metriken von Validator-Servern. Dieser Service erm\u00f6glicht es, die Situation der gesamten Netzwerk gleichzeitig zu \u00fcberblicken und schnell zu erkennen, was geschieht. Es ist auch im Interesse sowohl der Validatoren als auch des Projekts, dass das Team Fehler schnell behebt, weshalb es sinnvoll ist, zus\u00e4tzlich zur Metrikenerfassung sofort mit dem Sammeln von Log-Daten und Fehlerinformationen von den Validator-Maschinen zu beginnen und diese auf eine Maschine zu \u00fcbertragen, die f\u00fcr die Blockchain-Entwickler zug\u00e4nglich ist. Niemand hat ein Interesse daran, Informationen zu verf\u00e4lschen, weshalb diese Dienste vom Projektteam entwickelt werden und vertrauensw\u00fcrdig sind. Es ist sinnvoll, systematische Metriken von den Validatoren zu sammeln, insbesondere die wichtigsten Metriken der Blockchain selbst \u2014 f\u00fcr DAOBet sind dies die Finalisierungszeit und das R\u00fcckstand des zuletzt finalisierten Blocks. Damit hat das Team die M\u00f6glichkeit, einen Anstieg des Speicherverbrauchs auf den Knoten w\u00e4hrend des Benchmarks zu erkennen sowie Probleme einzelner Validatoren. <\/p>\n
<\/p>\n
Wichtige Punkte zur Durchf\u00fchrung des Validator-Spiels<\/h2>\n <\/p>\n
Wie sich herausstellt, wenn Sie den Validatoren offiziell erlauben m\u00f6chten, sich gegenseitig anzugreifen (inoffiziell k\u00f6nnen sie das ohnehin tun) \u2013 m\u00fcssen Sie dies separat rechtlich als Sicherheitstest formulieren, da in einigen L\u00e4ndern das Gesetz Strafen f\u00fcr DDoS- oder Netzwerkangriffe vorsieht. Eine weitere wichtige Frage ist, wie man die Validatoren belohnt. Naheliegende Preise sind die Token des Projekts, die in das Mainnet \u00fcbertragen werden, aber eine massenhafte Verteilung von Token an jeden, der einen Node starten kann, ist auch keine ideale L\u00f6sung. Wahrscheinlich m\u00fcssen Sie zwischen zwei extremen Optionen abw\u00e4gen:<\/p>\n
<\/p>\n
Verteilen Sie den gesamten Preisfond entsprechend den Verdiensten in VP
<\/p>\n
Verteilen Sie den Preisfond an die Top-N-Validatoren am Ende des Spiels
<\/p>\n
Welcher Option Sie den Vorzug geben, liegt ganz bei Ihnen. <\/p>\n
<\/p>\n
Es gibt noch einen weiteren Punkt \u2014 es ist keineswegs sicher, dass Dutzende von Validatoren auf Ihren Aufruf zur Teilnahme an der Spielrunde reagieren. Und selbst von denen, die es versuchen, werden nicht alle eine Node installieren und starten. In der Regel ist die Dokumentation in dieser Phase der Projekte ziemlich mager, es gibt h\u00e4ufig Fehler, und die Entwickler, die unter Zeitdruck stehen, reagieren nicht immer schnell auf Fragen. Daher sollten Sie vor Spielbeginn auch Ma\u00dfnahmen einplanen, falls die notwendige Anzahl an Validatoren nicht erreicht wird. In diesem Fall werden die fehlenden Validatoren vom Projektteam beim Start des Spiels aktiviert, nehmen am Konsens teil, k\u00f6nnen jedoch nicht gewinnen.<\/p>\n
<\/p>\n
Fazit<\/h2>\n <\/p>\n
Abschlie\u00dfend habe ich versucht, eine Liste der Dinge zusammenzustellen, die f\u00fcr eine effektive Durchf\u00fchrung des Validatorenspiels zu bedenken, zu erstellen und zu starten sind.<\/p>\n
<\/p>\n
Was f\u00fcr den Start eines echten Validatorenspiels zu tun ist:
<\/p>\n
\neine Web-Schnittstelle erstellen und einen CLI zur Abstimmung \u00fcber Validatoren bereitstellen<\/li>\n sicherstellen, dass Metriken von einem laufenden Validator-Knoten an einen zentralisierten Dienst (z. B. Prometheus) gesendet werden k\u00f6nnen<\/li>\n einen Metrik-Sammelserver (Prometheus + Grafana) f\u00fcr das Validatorenspiel aufsetzen<\/li>\n eine Methode zur Berechnung der Validator Points (VP) entwickeln<\/li>\n ein \u00f6ffentliches Skript erstellen, das die VP eines Validators basierend auf Daten aus der Blockchain berechnet<\/li>\n eine Web-Oberfl\u00e4che zur Anzeige der besten Validatoren und des aktuellen Status des Validatorenspiels (wie viel Zeit bis zum Ende, wer wie viele VP hat usw.) entwickeln<\/li>\n den automatisierten Start beliebig vieler eigener Knoten entwickeln und den Prozess der Anbindung von Validatoren an das Spiel gestalten (wann und wie die eigenen Knoten getrennt werden, Stimmen abgeben und zur\u00fcckziehen)<\/li>\n berechnen, wie viele Token ausgegeben werden m\u00fcssen, und einen Faucet-Vertrag entwickeln<\/li>\n ein Benchmark-Skript erstellen (Token-Transfers, massiver Speicherverbrauch, massiver Netzwerkverbrauch) <\/li>\n alle Teilnehmer in einem Chat f\u00fcr schnelle Kommunikation zusammenbringen<\/li>\n die Blockchain etwas vor dem Spielstart starten<\/li>\n auf den Startblock warten, das Spiel beginnen<\/li>\n Testen Sie das Netzwerk mit verschiedenen Transaktionstypen<\/li>\n Einen Hardfork aufspielen<\/li>\n Die Liste der Validierer \u00e4ndern<\/li>\n Punkte 13, 14 und 15 in unterschiedlicher Reihenfolge wiederholen, um die Stabilit\u00e4t des Netzwerks zu gew\u00e4hrleisten<\/li>\n Auf den letzten Block warten, das Spiel beenden und VP z\u00e4hlen<\/li>\n<\/ul>\n<\/p>\n
Es muss gesagt werden, dass das Spiel der Validierer ein neues Konzept ist und erst ein paar Mal durchgef\u00fchrt wurde, weshalb Sie diesen Text nicht als vollst\u00e4ndige Anleitung betrachten sollten. Es gibt keine Entsprechungen im modernen IT-Business \u2013 stellen Sie sich vor, Banken wetteifern darauf, wer vor dem Start des Zahlungssystems die besten Transaktionen f\u00fcr Kunden durchf\u00fchren kann. Traditionelle Ans\u00e4tze werden Ihnen kaum dabei helfen, gro\u00dfe dezentralisierte Netzwerke zu schaffen. Lernen Sie neue Gesch\u00e4ftsmodelle kennen, organisieren Sie Ihre eigenen Spiele, bestimmen Sie die Geeigneten, belohnen Sie sie, und lassen Sie Ihre verteilten Systeme schnell und stabil arbeiten.<\/p>\n
Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0418\u0442\u0430\u043a, \u0432\u0430\u0448\u0430 \u043a\u043e\u043c\u0430\u043d\u0434\u0430 \u0437\u0430\u043a\u043e\u043d\u0447\u0438\u043b\u0430 alpha-\u0432\u0435\u0440\u0441\u0438\u044e \u0432\u0430\u0448\u0435\u0433\u043e \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0430, \u0438 \u043f\u0440\u0438\u0448\u043b\u043e \u0432\u0440\u0435\u043c\u044f \u0437\u0430\u043f\u0443\u0441\u043a\u0430\u0442\u044c testnet, \u0430 \u0437\u0430\u0442\u0435\u043c \u0438 mainnet. \u0423 \u0432\u0430\u0441 \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0438\u0439 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d, \u0441 \u043d\u0435\u0437\u0430\u0432\u0438\u0441\u0438\u043c\u044b\u043c\u0438 \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c\u0438, \u0445\u043e\u0440\u043e\u0448\u0435\u0439 \u044d\u043a\u043e\u043d\u043e\u043c\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u043c\u043e\u0434\u0435\u043b\u044c\u044e, \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c\u044e, \u0432\u044b \u0441\u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043b\u0438 governance \u0438 \u0442\u0435\u043f\u0435\u0440\u044c \u043f\u043e\u0440\u0430 \u0431\u044b \u043f\u043e\u043f\u0440\u043e\u0431\u043e\u0432\u0430\u0442\u044c \u0432\u0441\u0435 \u044d\u0442\u043e \u0432 \u0434\u0435\u043b\u0435. \u0412 \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u043e\u043c \u043a\u0440\u0438\u043f\u0442\u043e\u0430\u043d\u0430\u0440\u0445\u0438\u0447\u0435\u0441\u043a\u043e\u043c \u043c\u0438\u0440\u0435, \u0432\u044b \u0432\u044b\u043a\u043b\u0430\u0434\u044b\u0432\u0430\u0435\u0442\u0435 \u0432 \u0441\u0435\u0442\u044c genesis block, \u043e\u043a\u043e\u043d\u0447\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043a\u043e\u0434 \u043d\u043e\u0434\u044b \u0438 \u0432\u0430\u043b\u0438\u0434\u0430\u0442\u043e\u0440\u044b \u0441\u0430\u043c\u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39478","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t