{"id":38856,"date":"2019-10-31T22:26:22","date_gmt":"2019-10-31T19:26:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/publichnyj-test-reshenie-dlya-privatnosti-i-masshtabiruemosti-v-efiriume\/"},"modified":"2019-10-31T22:26:22","modified_gmt":"2019-10-31T19:26:22","slug":"publichnyj-test-reshenie-dlya-privatnosti-i-masshtabiruemosti-v-efiriume","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/publichnyj-test-reshenie-dlya-privatnosti-i-masshtabiruemosti-v-efiriume","title":{"rendered":"\u00d6ffentlicher Test: L\u00f6sung f\u00fcr Datenschutz und Skalierbarkeit im Ethereum","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b>Blockchain<\/b> \u2014 innovative Technologie, die verspricht, viele Bereiche des menschlichen Lebens zu verbessern. Sie \u00fcbertr\u00e4gt reale Prozesse und Produkte in den digitalen Raum, gew\u00e4hrleistet Geschwindigkeit und Zuverl\u00e4ssigkeit bei finanziellen Transaktionen, senkt deren Kosten und erm\u00f6glicht es zudem, moderne DAPP-Anwendungen unter Verwendung intelligenter Vertr\u00e4ge in dezentralen Netzwerken zu erstellen.<\/p>\n<p>Angesichts der zahlreichen Vorteile und vielf\u00e4ltigen Anwendungsm\u00f6glichkeiten von Blockchain mag es seltsam erscheinen, dass diese vielversprechende Technologie noch nicht in alle Sektoren vorgedrungen ist. Das Problem liegt darin, dass modernen dezentralen Blockchains die Skalierbarkeit fehlt. Ethereum verarbeitet etwa 20 Transaktionen pro Sekunde, was nicht ausreicht, um den Anforderungen eines dynamischen modernen Gesch\u00e4fts gerecht zu werden. Gleichzeitig z\u00f6gern Unternehmen, die Blockchain-Technologie nutzen, einen Wechsel von Ethereum vorzunehmen, aufgrund seines hohen Schutzes vor Hacks und Netzwerkfehlern.<\/p>\n<p>Um Dezentralisierung, Sicherheit und Skalierbarkeit in der Blockchain zu gew\u00e4hrleisten, und somit das Skalierbarkeits-Trilemma zu l\u00f6sen, hat das Entwicklerteam <noindex><a rel=\"nofollow\" href=\"https:\/\/opporty.com\/\">Opporty<\/a><\/noindex> Plasma Cash entwickelt \u2014 eine Sidechain, die aus einem Smart Contract und einem privaten Netzwerk auf Grundlage von Node.js besteht und regelm\u00e4\u00dfig ihren Zustand an die Haupt-Chain (Ethereum) \u00fcbertr\u00e4gt.<\/p>\n<p><img decoding=\"async\" alt=\"\u00d6ffentlicher Test: L\u00f6sung f\u00fcr Datenschutz und Skalierbarkeit im Ethereum\" src=\"\/wp-content\/uploads\/2019\/10\/02cc45df3474179d0936c2a86fb7dee3.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Schl\u00fcsselfunktionen in Plasma Cash<\/h2>\n<p>\n<b>1. <\/b>Der Benutzer ruft die Funktion des Smart Contracts `deposit` auf und \u00fcbertr\u00e4gt den Betrag in ETH, den er im Plasma Cash Token anlegen m\u00f6chte. Die Funktion des Smart Contracts erstellt das Token und generiert ein Ereignis dar\u00fcber.<\/p>\n<p><b>2. <\/b>Die Plasma Cash-Knoten, die auf die Ereignisse des Smart Contracts lauschen, erhalten das Ereignis \u00fcber die Erstellung der Einzahlung und f\u00fcgen die Transaktion zur Erstellung des Tokens in den Pool ein.<\/p>\n<p><b>3. <\/b>Regelm\u00e4\u00dfig nehmen spezielle Plasma Cash-Knoten alle Transaktionen aus dem Pool (bis zu 1 Million) und bilden daraus einen Block, berechnen den Merkle-Baum und entsprechend den Hash. Dieser Block wird anderen Knoten zur Verifikation \u00fcbermittelt. Die Knoten \u00fcberpr\u00fcfen, ob der Merkle-Hash g\u00fcltig ist und ob die Transaktionen g\u00fcltig sind (z. B. ob der Absender des Tokens dessen Eigent\u00fcmer ist). Nach der Validierung des Blocks ruft der Knoten die Funktion `submitBlock` des Smart Contracts auf, die die Blocknummer und den Merkle-Hash in die Haupt-Chain speichert. Der Smart Contract generiert ein Ereignis \u00fcber die erfolgreiche Hinzuf\u00fcgung des Blocks. Transaktionen werden aus dem Pool entfernt. <\/p>\n<p><b>4. <\/b>Knoten, die das Ereignis \u00fcber das Einreichen eines Blocks erhalten haben, beginnen, die im Block hinzugef\u00fcgten Transaktionen anzuwenden.<\/p>\n<p><b>5. <\/b>Zu einem bestimmten Zeitpunkt m\u00f6chte der Eigent\u00fcmer (oder Nichtereigent\u00fcmer) des Tokens ihn aus Plasma Cash abheben. Dazu ruft er die Funktion `startExit` auf und \u00fcbergibt Informationen zu den letzten 2 Transaktionen zum Token, die best\u00e4tigen, dass er der Eigent\u00fcmer des Tokens ist. Der Smart Contract \u00fcberpr\u00fcft mit Hilfe des Merkle-Hashes, ob die Transaktionen in den Bl\u00f6cken enthalten sind, und sendet den Token zur Auszahlung, die in zwei Wochen erfolgen wird.<\/p>\n<p><b>6. <\/b>Wenn die Abhebungsoperation des Tokens gegen die Vorschriften verst\u00f6\u00dft (der Token wurde nach Beginn des Abhebungsverfahrens ausgegeben oder der Token war vor der Abhebung bereits fremd), kann der Eigent\u00fcmer des Tokens die Abhebung innerhalb von zwei Wochen anfechten.<\/p>\n<p><img decoding=\"async\" alt=\"\u00d6ffentlicher Test: L\u00f6sung f\u00fcr Datenschutz und Skalierbarkeit im Ethereum\" src=\"\/wp-content\/uploads\/2019\/10\/0626ca6b010eb847175dbfb0b6d7b357.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Die Privatsph\u00e4re wird auf zwei Arten erreicht.<\/h2>\n<p>\n<b>1. <\/b>Die Hauptkette wei\u00df nichts \u00fcber die Transaktionen, die innerhalb der untergeordneten Kette erstellt und gesendet werden. \u00d6ffentlich bleibt die Information dar\u00fcber, wer ETH in Plasma Cash eingezahlt und abgehoben hat.<\/p>\n<p><b>2. <\/b>Die untergeordnete Kette erm\u00f6glicht die Durchf\u00fchrung anonymer Transaktionen unter Verwendung von zk-SNARKs.<\/p>\n<h2>Technologischer Stack<\/h2>\n<p><\/p>\n<ul>\n<li>NodeJS<\/li>\n<li>Redis<\/li>\n<li>Etherium<\/li>\n<li>Solide<\/li>\n<\/ul>\n<p><\/p>\n<h2>Tests <\/h2>\n<p>\nBei der Entwicklung von Plasma Cash haben wir die Geschwindigkeit des Systems getestet und folgende Ergebnisse erhalten:<\/p>\n<ul>\n<li>bis zu 35.000 Transaktionen pro Sekunde werden in den Pool hinzugef\u00fcgt;<\/li>\n<li>bis zu 1.000.000 Transaktionen k\u00f6nnen in einem Block gespeichert werden.<\/li>\n<\/ul>\n<p>\nDie Tests wurden auf folgenden 3 Servern durchgef\u00fchrt:<\/p>\n<p><i>1. Intel Core i7-6700 Quad-Core Skylake incl. NVMe SSD \u2014 512 GB, 64 GB DDR4 RAM<\/i><br \/>\n Es wurden 3 validierende Plasma Cash Knoten eingerichtet.<\/p>\n<p><i>2. AMD Ryzen 7 1700X Octa-Core \u201eSummit Ridge\u201c (Zen), SATA SSD \u2014 500 GB, 64 GB DDR4 RAM<\/i><br \/>\n Es wurde ein Ropsten-Testnetz-ETH-Knoten eingerichtet.<br \/>\n Es wurden 3 validierende Plasma Cash Knoten eingerichtet.<\/p>\n<p><i>3. Intel Core i9-9900K Octa-Core incl. NVMe SSD \u2014 1 TB, 64 GB DDR4 RAM<\/i><br \/>\n Es wurde 1 Submit Plasma Cash Knoten eingerichtet.<br \/>\n Es wurden 3 validierende Plasma Cash Knoten eingerichtet.<br \/>\n Ein Test f\u00fcr das Hinzuf\u00fcgen von Transaktionen zum Plasma Cash Netzwerk wurde gestartet.<\/p>\n<p><b>Insgesamt: <\/b>10 Plasma Cash Knoten im privaten Netzwerk.<\/p>\n<h3>Test 1<\/h3>\n<p>\nEs gibt ein Limit von 1 Million Transaktionen pro Block. Daher gelangen 1 Million Transaktionen in 2 Bl\u00f6cke (da das System eine Teilmenge der Transaktionen erfassen und einreichen kann, w\u00e4hrend sie gesendet werden).<\/p>\n<p><center><div class=\"youtube-placeholder\" data-id=\"pKwqyGkEgdQ\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/pKwqyGkEgdQ\/hqdefault.jpg\" alt=\"Video abspielen\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><br \/>\nAusgangszustand: letzter Block #7; in der Datenbank sind 1 Million Transaktionen und Tokens gespeichert.<\/p>\n<p>00:00 \u2014 Start des Skripts zur Generierung von Transaktionen<br \/>\n01:37 \u2014 1 Million Transaktionen erstellt und Versendung an den Knoten begonnen<br \/>\n01:46 \u2014 der Submit-Knoten hat 240.000 Transaktionen aus dem Pool \u00fcbernommen und block #8 erstellt. Zudem sehen wir, dass in 10 Sekunden 320.000 Transaktionen zum Pool hinzugef\u00fcgt werden.<br \/>\n01:58 \u2014 block #8 wurde signiert und zur Validierung gesendet.<br \/>\n02:03 \u2014 Block #8 wurde validiert und die Funktion `submitBlock` des Smart Contracts mit dem Merkle-Hash und der Blocknummer aufgerufen.<br \/>\n02:10 \u2014 Das Demo-Skript, das 1 Million Transaktionen in 32 Sekunden gesendet hat, wurde beendet.<br \/>\n02:33 \u2014 Die Nodes begannen Informationen dar\u00fcber zu erhalten, dass Block #8 zur Root-Chain hinzugef\u00fcgt wurde, und begannen 240.000 Transaktionen auszuf\u00fchren.<br \/>\n02:40 \u2014 240.000 Transaktionen wurden aus dem Pool entfernt, die bereits in Block #8 waren.<br \/>\n02:56 \u2014 Der Submit-Node entnahm aus dem Pool die verbleibenden 760.000 Transaktionen und begann, den Merkle-Hash zu berechnen und Block #9 zu signieren.<br \/>\n03:20 \u2014 Alle Nodes enthalten 1.240.000 Transaktionen und Token.<br \/>\n03:35 \u2014 Block #9 wurde signiert und zur Validierung an andere Nodes gesendet. <br \/>\n03:41 \u2014 Ein Netzwerkfehler ist aufgetreten.<br \/>\n04:40 \u2014 Die Wartezeit zur Validierung von Block #9 wurde wegen Timeout beendet.<br \/>\n04:54 \u2014 Der Submit-Node entnahm aus dem Pool die verbleibenden 760.000 Transaktionen und begann, den Merkle-Hash zu berechnen und Block #9 zu signieren.<br \/>\n05:32 \u2014 Block #9 wurde signiert und zur Validierung an andere Nodes gesendet.<br \/>\n05:53 \u2014 Block #9 wurde validiert und in die Root-Chain gesendet.<br \/>\n06:17 \u2014 Die Nodes begannen, Informationen dar\u00fcber zu erhalten, dass Block #9 zur Root-Chain hinzugef\u00fcgt wurde, und begannen 760.000 Transaktionen auszuf\u00fchren.<br \/>\n06:47 \u2014 Der Pool wurde von Transaktionen, die in Block #9 waren, bereinigt.<br \/>\n09:06 \u2014 Alle Nodes enthalten 2 Millionen Transaktionen und Token.<\/p>\n<h3>Test 2<\/h3>\n<p>\nEs gibt ein Limit von 350.000 pro Block. Daraus ergibt sich, dass wir 3 Bl\u00f6cke haben.<\/p>\n<p><center><div class=\"youtube-placeholder\" data-id=\"mpTfTPKYRIc\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/mpTfTPKYRIc\/hqdefault.jpg\" alt=\"Video abspielen\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><br \/>\nAusgangszustand: letzter Block #9; in der Datenbank sind 2 Millionen Transaktionen und Token gespeichert.<\/p>\n<p>00:00 \u2014 Das Skript zur Generierung von Transaktionen wurde bereits gestartet.<br \/>\n00:44 \u2014 Es wurden 1 Million Transaktionen erstellt und die \u00dcbermittlung an den Node begann.<br \/>\n00:56 \u2014 Der Submit-Node entnahm 320.000 Transaktionen aus dem Pool und bildet Block #10. Wir sehen auch, dass 320.000 Transaktionen in 10 Sekunden zum Pool hinzugef\u00fcgt werden.<br \/>\n01:12 \u2014 Block #10 wurde signiert und zur Validierung an andere Nodes gesendet.<br \/>\n01:18 \u2014 Das Demo-Skript, das 1 Million Transaktionen in 34 Sekunden gesendet hat, wurde beendet.<br \/>\n01:20 \u2014 Block #10 wurde validiert und in die Root-Chain gesendet. <br \/>\n01:51 \u2014 Alle Nodes erhielten Informationen aus der Root-Chain, dass Block #10 hinzugef\u00fcgt wurde, und begannen, 320.000 Transaktionen anzuwenden.<br \/>\n02:01 \u2014 Der Pool wurde um 320.000 Transaktionen bereinigt, die in Block #10 hinzugef\u00fcgt wurden.<br \/>\n02:15 \u2014 Der Submit-Node entnahm 350.000 Transaktionen aus dem Pool und bildet Block #11.<br \/>\n02:34 \u2014 Block #11 wurde signiert und an andere Nodes zur Validierung gesendet.<br \/>\n02:51 \u2014 Block #11 wurde validiert und in die Root-Chain gesendet. <br \/>\n02:55 \u2014 Der letzte Node f\u00fchrte die Transaktionen aus Block #10 aus.<br \/>\n10:59 \u2014 sehr lange wurde die Transaktion mit dem Einreichen des Blocks #9 in der Hauptkette ausgef\u00fchrt, aber sie wurde ausgef\u00fchrt und alle Knoten erhielten die Informationen und begannen, 350.000 Transaktionen auszuf\u00fchren<br \/>\n11:05 \u2014 der Pool wurde um 320.000 Transaktionen bereinigt, die in Block #11 hinzugef\u00fcgt wurden<br \/>\n12:10 \u2014 alle Knoten enthalten 1.670.000 Transaktionen und Token<br \/>\n12:17 \u2014 der Einreichungsknoten hat 330.000 Transaktionen aus dem Pool entnommen und bildet Block #12<br \/>\n12:32 \u2014 Block #12 wurde signiert und an die anderen Knoten zur Validierung gesendet<br \/>\n12:39 \u2014 Block #12 wurde validiert und in die Hauptkette gesendet <br \/>\n13:44 \u2014 alle Knoten haben aus der Hauptkette die Information erhalten, dass Block #12 hinzugef\u00fcgt wurde und beginnen, 330.000 Transaktionen anzuwenden<br \/>\n14:50 \u2014 alle Knoten enthalten 2 Millionen Transaktionen und Token<\/p>\n<h3>Test 3<\/h3>\n<p>\nAuf dem ersten und zweiten Server wurde ein validierender Knoten durch einen Einreichungsknoten ersetzt. <\/p>\n<p><center><div class=\"youtube-placeholder\" data-id=\"w5QHab3heIc\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/w5QHab3heIc\/hqdefault.jpg\" alt=\"Video abspielen\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><br \/>\nAusgangszustand: letzter Block #84; in der Datenbank sind 0 Transaktionen und Token gespeichert<\/p>\n<p>00:00 \u2014 3 Skripte wurden gestartet, die jeweils 1 Million Transaktionen generieren und senden<br \/>\n01:38 \u2014 1 Million Transaktionen wurden erstellt und der Versand an den Einreichungsknoten #3 hat begonnen<br \/>\n01:50 \u2014 der Einreichungsknoten #3 hat 330.000 Transaktionen aus dem Pool entnommen und bildet Block #85 (f21). Auch sehen wir, dass in den Pool 350.000 Transaktionen in 10 Sekunden hinzugef\u00fcgt werden<br \/>\n01:53 \u2014 1 Million Transaktionen wurden erstellt und der Versand an den Einreichungsknoten #1 hat begonnen<br \/>\n01:50 \u2014 der Einreichungsknoten #3 hat 330.000 Transaktionen aus dem Pool entnommen und bildet Block #85 (f21). Auch sehen wir, dass in den Pool 350.000 Transaktionen in 10 Sekunden hinzugef\u00fcgt werden<br \/>\n02:01 \u2014 der Einreichungsknoten #1 hat 250.000 Transaktionen aus dem Pool entnommen und bildet Block #85 (65e)<br \/>\n02:06 \u2014 Block #85 (f21) wurde signiert und an die anderen Knoten zur Validierung gesendet<br \/>\n02:08 \u2014 das Demo-Skript des Servers #3 hat seine Arbeit beendet, das 1 Million Transaktionen in 30 Sekunden gesendet hat<br \/>\n02:14 \u2014 Block #85 (f21) wurde validiert und in die Hauptkette gesendet <br \/>\n02:19 \u2014 Block #85 (65e) wurde signiert und an die anderen Knoten zur Validierung gesendet<br \/>\n02:22 \u2014 1 Million Transaktionen wurden erstellt und der Versand an den Einreichungsknoten #2 hat begonnen<br \/>\n02:27 \u2014 Block #85 (65e) wurde validiert und in die Hauptkette gesendet <br \/>\n02:29 \u2014 der Einreichungsknoten #2 hat 111.855 Transaktionen aus dem Pool entnommen und bildet Block #85 (256).<br \/>\n02:36 \u2014 Block #85 (256) wurde signiert und an die anderen Knoten zur Validierung gesendet<br \/>\n02:36 \u2014 das Demo-Skript des Servers #1 hat seine Arbeit beendet, das 1 Million Transaktionen in 42,5 Sekunden gesendet hat<br \/>\n02:38 \u2014 Block #85 (256) wurde validiert und in die Hauptkette gesendet<br \/>\n03:08 \u2014 das Demo-Skript des Servers #2 hat seine Arbeit beendet, das 1 Million Transaktionen in 47 Sekunden gesendet hat <br \/>\n03:38 \u2014 alle Knoten haben aus der Hauptkette die Information erhalten, dass die Bl\u00f6cke #85 (f21), #86(65e), #87(256) hinzugef\u00fcgt wurden und beginnen, 330.000, 250.000, 111.855 Transaktionen anzuwenden<br \/>\n03:49 \u2014 der Pool hat sich auf 330k, 250k, 111855 Transaktionen bereinigt, die in die Bl\u00f6cke #85 (f21), #86(65e), #87(256) hinzugef\u00fcgt wurden<br \/>\n03:59 \u2014 der Submit-Node #1 hat 888145 Transaktionen aus dem Pool genommen und block #88 (214) generiert, der Submit-Node #2 hat 750k Transaktionen aus dem Pool genommen und block #88 (50a) generiert, der Submit-Node #3 hat 670k Transaktionen aus dem Pool genommen und block #88 (d3b) generiert<br \/>\n04:44 \u2014 block #88 (d3b) wurde signiert und an andere Nodes zur Validierung gesendet<br \/>\n04:58 \u2014 block #88 (214) wurde signiert und an andere Nodes zur Validierung gesendet<br \/>\n05:11 \u2014 block #88 (50a) wurde signiert und an andere Nodes zur Validierung gesendet<br \/>\n05:11 \u2014 block #85 (d3b) wurde validiert und in die Hauptkette gesendet <br \/>\n05:36 \u2014 block #85 (214) wurde validiert und in die Hauptkette gesendet <br \/>\n05:43 \u2014 alle Nodes haben Informationen aus der Hauptkette dar\u00fcber erhalten, dass die Bl\u00f6cke #88 (d3b), #89(214) hinzugef\u00fcgt wurden und beginnen, 670k, 750k Transaktionen anzuwenden<br \/>\n06:50 \u2014 aufgrund eines Verbindungsabbruchs wurde block #85 (50a) nicht validiert<br \/>\n06:55 \u2014 der Submit-Node #2 hat 888145 Transaktionen aus dem Pool genommen und block #90 (50a) generiert<br \/>\n08:14 \u2014 block #90 (50a) wurde signiert und an andere Nodes zur Validierung gesendet<br \/>\n09:04 \u2014 block #90 (50a) wurde validiert und in die Hauptkette gesendet <br \/>\n11:23 \u2014 alle Nodes haben Informationen aus der Hauptkette erhalten, dass block #90 (50a) hinzugef\u00fcgt wurde, und beginnen, 888145 Transaktionen anzuwenden. Dabei hat der Server #3 bereits Transaktionen aus den Bl\u00f6cken #88 (d3b), #89(214) angewendet<br \/>\n12:11 \u2014 alle Pools sind leer<br \/>\n13:41 \u2014 alle Nodes des Servers #3 enthalten 3 Millionen Transaktionen und Tokens<br \/>\n14:35 \u2014 alle Nodes des Servers #1 enthalten 3 Millionen Transaktionen und Tokens<br \/>\n19:24 \u2014 alle Nodes des Servers #2 enthalten 3 Millionen Transaktionen und Tokens <\/p>\n<h2>Herausforderungen<\/h2>\n<p>\nW\u00e4hrend der Entwicklung von Plasma Cash stie\u00dfen wir auf folgende Probleme, die wir schrittweise gel\u00f6st haben und weiterhin l\u00f6sen:<\/p>\n<p><b>1.<\/b> Konflikte bei der Interaktion verschiedener Funktionen des Systems. Beispielsweise blockierte die Funktion zum Hinzuf\u00fcgen von Transaktionen zum Pool die Arbeit des Submitters und der Validierung von Bl\u00f6cken und umgekehrt, was zu einer Verringerung der Geschwindigkeit f\u00fchrte.<\/p>\n<p><b>2. <\/b>Es war zun\u00e4chst unklar, wie man eine gro\u00dfe Menge an Transaktionen senden und dabei die \u00dcbertragungskosten minimieren kann.<\/p>\n<p><b>3. <\/b>Es war unklar, wie und wo die Daten gespeichert werden sollten, um hohe Ergebnisse zu erzielen.<\/p>\n<p><b>4. <\/b>Es war unklar, wie das Netzwerk zwischen den Nodes organisiert werden sollte, da die Gr\u00f6\u00dfe eines Blocks mit 1 Million Transaktionen etwa 100 MB betr\u00e4gt.<\/p>\n<p><b>5.<\/b> Die Arbeit im Ein-Thread-Modus unterbricht die Verbindung zwischen den Nodes, wenn lange Berechnungen stattfinden (zum Beispiel beim Aufbau des Merkle-Baums und der Berechnung seines Hashes).<\/p>\n<h2>Wie haben wir all das geschafft?<\/h2>\n<p>\nDie erste Version der Plasma Cash Node stellte eine Art Kombi dar, der alles gleichzeitig erledigen konnte: Transaktionen annehmen, Bl\u00f6cke einreichen und validieren sowie eine API f\u00fcr den Datenzugriff bereitstellen. Da NodeJS urspr\u00fcnglich single-threaded ist, blockierte die rechenintensive Funktion zur Berechnung des Merkle-Baums die Funktion zur Hinzuf\u00fcgung von Transaktionen. Wir sahen zwei M\u00f6glichkeiten zur L\u00f6sung dieses Problems:<\/p>\n<p><b>1. <\/b>Mehrere NodeJS-Prozesse starten, von denen jeder bestimmte Funktionen ausf\u00fchrt.<\/p>\n<p><b>2. <\/b>Worker-Threads verwenden und Teile des Codes in Threads auslagern.<\/p>\n<p>Schlie\u00dflich nutzten wir beide Optionen gleichzeitig: Wir unterteilten eine Node logisch in 3 Teile, die separat, aber gleichzeitig arbeiten k\u00f6nnen.<\/p>\n<p><b>1.<\/b> Die Submit-Node, die Transaktionen in den Pool aufnimmt und Bl\u00f6cke erstellt.<\/p>\n<p><b>2.<\/b> Die validierende Node, die die G\u00fcltigkeit der Nodes \u00fcberpr\u00fcft.<\/p>\n<p><b>3. <\/b>API-Node \u2013 stellt eine API f\u00fcr den Datenzugriff bereit.<\/p>\n<p>Alle Nodes sind \u00fcber einen Unix-Socket mittels CLI erreichbar.<\/p>\n<p>Rechenintensive Operationen, wie die Berechnung des Merkle-Baums, lagerten wir in einen separaten Thread aus.<\/p>\n<p>So erreichten wir eine normale Funktionsweise aller Plasma Cash Funktionen gleichzeitig und ohne Ausf\u00e4lle.<\/p>\n<p>Sobald das System funktional arbeitete, begannen wir mit Tests der Geschwindigkeit und erhielten leider unzureichende Ergebnisse: 5.000 Transaktionen pro Sekunde und bis zu 50.000 Transaktionen im Block. Wir mussten herausfinden, was falsch implementiert wurde.<\/p>\n<p>Zun\u00e4chst testeten wir den Kommunikationsmechanismus mit Plasma Cash, um die maximale Leistungsf\u00e4higkeit des Systems zu ermitteln. Zuvor hatten wir erw\u00e4hnt, dass die Plasma Cash Node eine Unix-Socket-Schnittstelle bereitstellt. Anfangs war diese textbasiert. JSON-Objekte wurden mittels `JSON.parse()` und `JSON.stringify()` \u00fcbertragen. <\/p>\n<pre><code class=\"plaintext\">```json\n{\n  \"action\": \"sendTransaction\",\n  \"payload\":{\n    \"prevHash\": \"0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0\",\n    \"prevBlock\": 41,\n    \"tokenId\": \"57570139642005649136210751546585740989890521125187435281313126554130572876445\",\n    \"newOwner\": \"0x200eabe5b26e547446ae5821622892291632d4f4\",\n    \"type\": \"pay\",\n    \"data\": \"\",\n    \"signature\": \"0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c\"\n  }\n}\n```\n<\/code><\/pre>\n<p>\nWir gemessene die \u00dcbertragungsgeschwindigkeit solcher Objekte und erhielten ~ 130.000 pro Sekunde. Wir versuchten, die Standardfunktionen zur Arbeit mit JSON zu ersetzen, aber die Leistung verbesserte sich nicht. Offensichtlich ist die V8-Engine gut f\u00fcr diese Operationen optimiert.<\/p>\n<p>Die Arbeit mit Transaktionen, Tokens und Bl\u00f6cken erfolgte bei uns \u00fcber Klassen. Bei der Erstellung solcher Klassen fiel die Leistung um das Zweifache, was darauf hindeutet, dass OOP f\u00fcr uns nicht geeignet ist. Wir mussten alles auf einen rein funktionalen Ansatz umschreiben.<\/p>\n<h2>Datenbankeintrag<\/h2>\n<p>\nUrspr\u00fcnglich haben wir Redis als eine der leistungsf\u00e4higsten L\u00f6sungen f\u00fcr die Datenspeicherung gew\u00e4hlt, die unseren Anforderungen entsprechen: ein Key-Value-Speicher, der mit Hash-Tabellen und Mengen arbeitet. Wir haben redis-benchmark gestartet und erhielten etwa 80.000 Operationen pro Sekunde im Modus 1 Pipelining.<\/p>\n<p>F\u00fcr eine hohe Leistung haben wir Redis feiner eingestellt: <\/p>\n<ul>\n<li>Wir haben eine Unix-Socket-Verbindung eingerichtet.<\/li>\n<li>Wir haben die Speicherung des Zustands auf die Festplatte deaktiviert (f\u00fcr die Zuverl\u00e4ssigkeit kann eine Replik eingerichtet werden, die die Speicherung auf der Festplatte durchf\u00fchrt).<\/li>\n<\/ul>\n<p>\nIn Redis ist ein Pool eine Hash-Tabelle, da wir die M\u00f6glichkeit ben\u00f6tigen, alle Transaktionen mit einer Anfrage zu erhalten und Transaktionen einzeln zu l\u00f6schen. Wir haben versucht, eine normale Liste zu verwenden, aber sie arbeitet langsamer beim Laden der gesamten Liste. <\/p>\n<p>Mit der Standard-NodeJS-Bibliothek f\u00fcr Redis haben wir eine Leistung von 18.000 Transaktionen pro Sekunde erhalten. Die Geschwindigkeit fiel um das Neunfache. <\/p>\n<p>Da der Benchmark uns offensichtlich die M\u00f6glichkeit von f\u00fcnfmal mehr zeigte, begannen wir mit der Optimierung. Wir wechselten zur Bibliothek ioredis und erzielten eine Leistung von bereits 25.000 pro Sekunde. Die Transaktionen haben wir einzeln hinzugef\u00fcgt, indem wir den Befehl `hset` verwendet haben. So generierten wir viele Anfragen an Redis. Es kam die Idee auf, Transaktionen in Chargen zusammenzufassen und sie mit einem Befehl `hmset` zu senden. Das Ergebnis waren 32.000 pro Sekunde. <\/p>\n<p>Aus mehreren Gr\u00fcnden, die wir gleich erl\u00e4utern werden, arbeiten wir mit den Daten unter Verwendung von `Buffer`. Es stellte sich heraus, dass man, wenn man es vor dem Schreiben in Text (`buffer.toString('hex')`) umwandelt, eine zus\u00e4tzliche Leistung erzielen kann. Dadurch konnte die Geschwindigkeit auf 35.000 pro Sekunde gesteigert werden. Derzeit haben wir beschlossen, die weitere Optimierung vor\u00fcbergehend auszusetzen.<\/p>\n<p>Wir mussten auf ein bin\u00e4res Protokoll umsteigen, da:<\/p>\n<p><b>1. <\/b>Das System h\u00e4ufig Hashes, Signaturen und \u00c4hnliches berechnet, und daf\u00fcr ben\u00f6tigt es Daten im `Buffer.<\/p>\n<p><b>2.<\/b> Bei der \u00dcbertragung zwischen Diensten wiegen bin\u00e4re Daten weniger als Text. Zum Beispiel k\u00f6nnen beim Versenden eines Blocks mit 1 Million Transaktionen die Daten im Text \u00fcber 300 Megabyte belegen.<\/p>\n<p><b>3.<\/b> Die st\u00e4ndige Umwandlung von Daten wirkt sich auf die Leistung aus.<\/p>\n<p>Deshalb haben wir unser eigenes bin\u00e4res Protokoll zur Speicherung und \u00dcbertragung von Daten als Grundlage genommen, das auf der gro\u00dfartigen Bibliothek `binary-data` basiert.<\/p>\n<p>Infolgedessen haben wir die folgenden Datenstrukturen erhalten:<\/p>\n<h3> \u2014 Transaktion<\/h3>\n<p><\/p>\n<pre><code class=\"plaintext\">  ```json\n  {\n    prevHash: BD.types.buffer(20),\n    prevBlock: BD.types.uint24le,\n    tokenId: BD.types.string(null),\n    type: BD.types.uint8,\n    newOwner: BD.types.buffer(20),\n    dataLength: BD.types.uint24le,\n    data: BD.types.buffer(({current}) =&gt; current.dataLength),\n    signature: BD.types.buffer(65),\n    hash: BD.types.buffer(32),\n    blockNumber: BD.types.uint24le,\n    timestamp: BD.types.uint48le,\n  }\n  ```\n<\/code><\/pre>\n<p><\/p>\n<h3> \u2014 Token<\/h3>\n<p><\/p>\n<pre><code class=\"plaintext\">  ```json\n  {\n    id: BD.types.string(null),\n    owner: BD.types.buffer(20),\n    block: BD.types.uint24le,\n    amount: BD.types.string(null),\n  }\n  ```\n<\/code><\/pre>\n<p><\/p>\n<h3> \u2014 Block<\/h3>\n<p><\/p>\n<pre><code class=\"plaintext\">  ```json\n  {\n    number: BD.types.uint24le,\n    merkleRootHash: BD.types.buffer(32),\n    signature: BD.types.buffer(65),\n    countTx: BD.types.uint24le,\n    transactions: BD.types.array(Transaction.Protocol, ({current}) =&gt; current.countTx),\n    timestamp: BD.types.uint48le,\n  }\n  ```\n<\/code><\/pre>\n<p>\nMit den \u00fcblichen Befehlen `BD.encode(block, Protocol).slice();` und ` BD.decode(buffer, Protocol)` wandeln wir die Daten in einen `Buffer` um, um sie in Redis zu speichern oder an einen anderen Knoten zu \u00fcbertragen und die Daten zur\u00fcckzuerhalten.<\/p>\n<p>Au\u00dferdem haben wir 2 bin\u00e4re Protokolle f\u00fcr die \u00dcbertragung von Daten zwischen Diensten:<\/p>\n<p><i> \u2014 Protokoll zur Interaktion mit Plasma Node \u00fcber einen Unix-Socket<\/i><\/p>\n<pre><code class=\"plaintext\">  ```json\n  {\n    type: BD.types.uint8,\n    messageId: BD.types.uint24le,\n    error: BD.types.uint8,\n    length: BD.types.uint24le,\n    payload: BD.types.buffer(({node}) =&gt; node.length)\n  }\n  ```\n<\/code><\/pre>\n<p>\n {REPOSITORY_ABSOLUTE_PATH}<\/p>\n<ul>\n<li> <b>`type`<\/b> \u2014 Die Aktion, die ausgef\u00fchrt werden soll, z.B. 1 \u2014 sendTransaction, 2 \u2014 getTransaction;<\/li>\n<li> <b>`payload`<\/b> \u2014 Die Daten, die an die entsprechende Funktion \u00fcbergeben werden sollen;<\/li>\n<li> <b>`messageId`<\/b> \u2014 ID der Nachricht, um die Antwort identifizieren zu k\u00f6nnen. <\/li>\n<\/ul>\n<p>\n<i> \u2014 Protokoll zur Interaktion zwischen Knoten<\/i><\/p>\n<pre><code class=\"plaintext\">  ```json\n  {\n    code: BD.types.uint8,\n    versionProtocol: BD.types.uint24le,\n    seq: BD.types.uint8,\n    countChunk: BD.types.uint24le,\n    chunkNumber: BD.types.uint24le,\n    length: BD.types.uint24le,\n    payload: BD.types.buffer(({node}) =&gt; node.length)\n  }\n  ```\n<\/code><\/pre>\n<p>\n {REPOSITORY_ABSOLUTE_PATH}<\/p>\n<ul>\n<li> <b>`code`<\/b> \u2014 Nachrichten-Code, z.B. 6 \u2014 PREPARE_NEW_BLOCK, 7 \u2014 BLOCK_VALID, 8 \u2014 BLOCK_COMMIT;<\/li>\n<li> <b>`versionProtocol`<\/b> \u2014 Version des Protokolls, da im Netzwerk Knoten mit unterschiedlichen Versionen hochgefahren werden k\u00f6nnen und unterschiedlich arbeiten k\u00f6nnen;<\/li>\n<li> <b>`seq`<\/b> \u2014 Nachrichten-Identifikator;<\/li>\n<li> <b>`countChunk`<\/b> und <b>`chunkNumber`<\/b> sind erforderlich, um gro\u00dfe Nachrichten zu fragmentieren;<\/li>\n<li> <b>`length`<\/b> und <b>`payload`<\/b> L\u00e4nge und die Daten selbst.<\/li>\n<\/ul>\n<p>\nDa wir die Daten im Voraus typisiert haben, arbeitet das Endsystem viel schneller als die `rlp`-Bibliothek von Ethereum. Leider ist es uns bisher nicht gelungen, darauf zu verzichten, da der Smart Contract \u00fcberarbeitet werden muss, was wir in Zukunft planen.<\/p>\n<p>Wenn es uns gelungen ist, eine Geschwindigkeit zu erreichen <b>35 000<\/b> Um Transaktionen pro Sekunde zu verarbeiten, m\u00fcssen wir sie auch in optimaler Zeit abwickeln. Da die ungef\u00e4hre Zeit zur Bildung eines Blocks 30 Sekunden betr\u00e4gt, m\u00fcssen wir diese in den Block einf\u00fcgen. <b>1 000 000<\/b> Transaktionen, was bedeutet, dass mehr als <b>100<\/b> MB an Daten \u00fcbertragen werden. <\/p>\n<p>Urspr\u00fcnglich verwendeten wir die Bibliothek `ethereumjs-devp2p` zur Kommunikation zwischen den Knoten, aber sie konnte mit der Menge an Daten nicht umgehen. Daher haben wir die Bibliothek `ws` verwendet und die \u00dcbertragung von Bin\u00e4rdaten \u00fcber WebSockets eingerichtet. Nat\u00fcrlich hatten wir auch Probleme bei der \u00dcbertragung gro\u00dfer Datenpakete, aber wir haben sie in Chunks aufgeteilt, und jetzt haben wir diese Probleme nicht mehr.<\/p>\n<p>Au\u00dferdem ben\u00f6tigt die Bildung des Merkle-Baums und die Berechnung des Hashes <b>1 000 000<\/b> der Transaktionen etwa<b> 10<\/b> Sekunden kontinuierlicher Berechnungen. In dieser Zeit kann die Verbindung zu allen Knoten unterbrochen werden. Es wurde beschlossen, diese Berechnung in einen separaten Thread zu verlagern.<\/p>\n<h2>Fazit:<\/h2>\n<p>\nTats\u00e4chlich sind unsere Erkenntnisse nicht neu, aber aus irgendeinem Grund vergessen viele Spezialisten diese bei der Entwicklung. <\/p>\n<ul>\n<li>Die Verwendung von Functional Programming anstelle von Object-Oriented Programming erh\u00f6ht die Leistung.<\/li>\n<li>Monolithische Architekturen sind schlechter als serviceorientierte Architekturen f\u00fcr leistungsstarke Systeme auf NodeJS.<\/li>\n<li>Die Verwendung von `worker_threads` f\u00fcr rechenintensive Berechnungen verbessert die Reaktionsf\u00e4higkeit des Systems, insbesondere bei I\/O-Operationen.<\/li>\n<li>Unix-Sockets sind stabiler und schneller als HTTP-Anfragen.<\/li>\n<li>Wenn gro\u00dfe Daten schnell \u00fcber das Netzwerk \u00fcbertragen werden m\u00fcssen, ist es besser, WebSockets zu verwenden und Bin\u00e4rdaten in Chunks zu senden, die erneut \u00fcbermittelt werden k\u00f6nnen, wenn sie nicht ankommen, und dann zu einer Nachricht zusammengef\u00fcgt werden k\u00f6nnen.<\/li>\n<\/ul>\n<p>\nWir laden Sie ein, zu besuchen <b>GitHub<\/b> Projekt definiert: <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/opporty-com\/Plasma-Cash\/tree\/new-version\">https:\/\/github.com\/opporty-com\/Plasma-Cash\/tree\/new-version<\/a><\/noindex><\/p>\n<p>Der Artikel wurde in Zusammenarbeit mit <i>Alexander Nashivan<\/i>, leitender Entwickler <noindex><a rel=\"nofollow\" href=\"https:\/\/clever-solution.com\/\">Clever Solution Inc<\/a><\/noindex>.<br \/>\n<br \/>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/471096\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0411\u043b\u043e\u043a\u0447\u0435\u0439\u043d \u2014 \u0438\u043d\u043d\u043e\u0432\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f, \u043e\u0431\u0435\u0449\u0430\u044e\u0449\u0430\u044f \u0443\u043b\u0443\u0447\u0448\u0438\u0442\u044c \u043c\u043d\u043e\u0433\u0438\u0435 \u0441\u0444\u0435\u0440\u044b \u0447\u0435\u043b\u043e\u0432\u0435\u0447\u0435\u0441\u043a\u043e\u0439 \u0436\u0438\u0437\u043d\u0438. \u041e\u043d\u0430 \u043f\u0435\u0440\u0435\u043d\u043e\u0441\u0438\u0442 \u0440\u0435\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u044b \u0438 \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u044b \u0432 \u0446\u0438\u0444\u0440\u043e\u0432\u043e\u0435 \u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0441\u0442\u0432\u043e, \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0432\u0430\u0435\u0442 \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c \u0438 \u043d\u0430\u0434\u0435\u0436\u043d\u043e\u0441\u0442\u044c \u0444\u0438\u043d\u0430\u043d\u0441\u043e\u0432\u044b\u0445 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439, \u0441\u043d\u0438\u0436\u0430\u0435\u0442 \u0438\u0445 \u0441\u0442\u043e\u0438\u043c\u043e\u0441\u0442\u044c, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u0435\u0442 \u0441\u043e\u0437\u0434\u0430\u0432\u0430\u0442\u044c \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0435 DAPP \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0441 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435\u043c \u0438\u043d\u0442\u0435\u043b\u043b\u0435\u043a\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0445 \u043a\u043e\u043d\u0442\u0440\u0430\u043a\u0442\u043e\u0432 \u0432 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0445 \u0441\u0435\u0442\u044f\u0445. \u0423\u0447\u0438\u0442\u044b\u0432\u0430\u044f \u043c\u043d\u043e\u0433\u043e\u0447\u0438\u0441\u043b\u0435\u043d\u043d\u044b\u0435 \u043f\u0440\u0435\u0438\u043c\u0443\u0449\u0435\u0441\u0442\u0432\u0430 \u0438 \u0440\u0430\u0437\u043d\u043e\u043e\u0431\u0440\u0430\u0437\u043d\u044b\u0435 \u0441\u0444\u0435\u0440\u044b \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d, \u043c\u043e\u0436\u0435\u0442 \u043f\u043e\u043a\u0430\u0437\u0430\u0442\u044c\u0441\u044f \u0441\u0442\u0440\u0430\u043d\u043d\u044b\u043c, \u0447\u0442\u043e \u044d\u0442\u0430 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29146,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38856","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0411\u043b\u043e\u043a\u0447\u0435\u0439\u043d \u2014 \u0438\u043d\u043d\u043e\u0432\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f, \u043e\u0431\u0435\u0449\u0430\u044e\u0449\u0430\u044f \u0443\u043b\u0443\u0447\u0448\u0438\u0442\u044c \u043c\u043d\u043e\u0433\u0438\u0435 \u0441\u0444\u0435\u0440\u044b \u0447\u0435\u043b\u043e\u0432\u0435\u0447\u0435\u0441\u043a\u043e\u0439 \u0436\u0438\u0437\u043d\u0438.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/publichnyj-test-reshenie-dlya-privatnosti-i-masshtabiruemosti-v-efiriume\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041f\u0443\u0431\u043b\u0438\u0447\u043d\u044b\u0439 \u0442\u0435\u0441\u0442: \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u043f\u0440\u0438\u0432\u0430\u0442\u043d\u043e\u0441\u0442\u0438 \u0438 \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u0443\u0435\u043c\u043e\u0441\u0442\u0438 \u0432 \u042d\u0444\u0438\u0440\u0438\u0443\u043c\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0411\u043b\u043e\u043a\u0447\u0435\u0439\u043d \u2014 \u0438\u043d\u043d\u043e\u0432\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f, \u043e\u0431\u0435\u0449\u0430\u044e\u0449\u0430\u044f \u0443\u043b\u0443\u0447\u0448\u0438\u0442\u044c \u043c\u043d\u043e\u0433\u0438\u0435 \u0441\u0444\u0435\u0440\u044b \u0447\u0435\u043b\u043e\u0432\u0435\u0447\u0435\u0441\u043a\u043e\u0439 \u0436\u0438\u0437\u043d\u0438.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/publichnyj-test-reshenie-dlya-privatnosti-i-masshtabiruemosti-v-efiriume\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:26:22+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:26:22+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47\u00d6ffentliche Testversion: L\u00f6sung f\u00fcr Privatsph\u00e4re und Skalierbarkeit in Ethereum | ProHoster","description":"Blockchain ist eine innovative Technologie, die verspricht, viele Bereiche des menschlichen Lebens zu verbessern.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/publichnyj-test-reshenie-dlya-privatnosti-i-masshtabiruemosti-v-efiriume","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0443\u0431\u043b\u0438\u0447\u043d\u044b\u0439 \u0442\u0435\u0441\u0442: \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u043f\u0440\u0438\u0432\u0430\u0442\u043d\u043e\u0441\u0442\u0438 \u0438 \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u0443\u0435\u043c\u043e\u0441\u0442\u0438 \u0432 \u042d\u0444\u0438\u0440\u0438\u0443\u043c\u0435 | ProHoster","og:description":"\u0411\u043b\u043e\u043a\u0447\u0435\u0439\u043d \u2014 \u0438\u043d\u043d\u043e\u0432\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f, \u043e\u0431\u0435\u0449\u0430\u044e\u0449\u0430\u044f \u0443\u043b\u0443\u0447\u0448\u0438\u0442\u044c \u043c\u043d\u043e\u0433\u0438\u0435 \u0441\u0444\u0435\u0440\u044b \u0447\u0435\u043b\u043e\u0432\u0435\u0447\u0435\u0441\u043a\u043e\u0439 \u0436\u0438\u0437\u043d\u0438.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/publichnyj-test-reshenie-dlya-privatnosti-i-masshtabiruemosti-v-efiriume","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:26:22+00:00","article:modified_time":"2019-10-31T19:26:22+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38856","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 23:42:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:15:36","updated":"2026-01-23 23:42:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/38856","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=38856"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/38856\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/29146"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=38856"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=38856"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=38856"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}