GhostTyper

Schreib' mir einfach eine PN mit Deiner E-Mail-Adresse, dann leite ich Dir die komplette E-Mail weiter.

Dein Job ist Dir also wichtiger als mir eine gute Antwort zu geben? Pah! Die Frage bei 1:01:30 vom letzten Town Hall-Dingsbums ist übrigens von mir. (Oben verlinktes YouTube-Video.) Ich finde die Antwort etwas schade, denn sie suggeriert mir, dass sowieso von einem Endkunden-Zugriffsprofil ausgegangen wird, dass eher weniger Abfragen erzeugt. Und, dass man nicht gerade davon ausgeht, dass das Netzwerk "sehr voll" wird, da man mit dem Verteilen auf mehrere Nodes ja Speicherkapazität im Netzwerk opfert. Ich habe auch noch eine Frage gestellt, die leider nicht beantwortet wurde - war vermutlich zu knapp: Manche Tester beschweren sich über - vor allem - schlechte Upload Performance. Ein Grund könnte sein, dass das S3 Gateway auch das aufteilen der Files übernimmt und für (grob geschätzte Zahlen) 10 TB 36 TB uploaden muss. (Also, man schickt eine 10 GB File an das S3 Gateway und dieses muss das dann an die einzelnen Nodes schicken und zwar in aller Redundanz.) Wäre dieses Problem nicht Lösbar, dass man weniger Redundanz hochlädt und den Reparatur (ggf. durch Aufpreis) die Redundanz sofort herstellen lässt?

Ich habe noch einen Storagenode-Key, den ich nicht benutzt habe. Könnte ich den dem @Heisenberg420 geben, @skunk? @skunk: Die Bezahlung für diese eine Node über die ich kürzlich geschrieben habe waren ungefähr 460 STORJ, also k.A. 50 €. Die Frage nervt sicher, aber: "When Production"? Ich habe jetzt alle Nodes auf verschiedene IP-Adressen, die auch alle weit voneinander weg sind. Leider ist, wie angekündigt die Last auf der Node wieder 'runter gegangen.

Das ist ja sehr Interessant. Wird das nach Klasse C (also die letzte Stelle der IPv4) gefiltert oder wie weit müssen Nodes voneinander weg sein? Glücklicherweise habe ich über 600 IPs in 8 Subnetzen und werde das jetzt Mal etwas besser verteilen. Wann wird die Änderung der IP übernommen? Schon beim nächsten Einloggen der Node?

Ich habe zwei Fragen für 's Townhall-Dingsbums eingereicht. Ich hoffe, die werden beantwortet. Ich nehme Mal an, Du wirst den Link hier posten. Ansonsten hab' ich jetzt 9 Storage-Nodes eingerichtet, alle mit 2 TB Disk netto. Die eine Node von oben hat bis jetzt 5.2 TB egress. Alle anderen Nodes sind eher schlechter in der Statistik, aber auch jünger. Manche der Nodes habe ich mit anderer E-Mail-Adresse registriert und manche anderen lasse ich mit anderer Wallet-Adresse laufen um zu sehen, ob es da Unterschiede in der Auslastung gibt. Meine Strategie ist es jetzt so viele Nodes wie möglich "aufzuwärmen". Und wenn ich dann am Ende sehe, dass dort tatsächlich etwas dabei 'rum kommt bin ich auch bereit die Nodes auf anderen Storage mit mehr Disk-Space umzuziehen und dann die Nodes zu vergrößern.

Eine meiner Nodes hat "relativ viel" (so gefühlt) Egress-Traffic nach der Ansicht der Konsolen-Dashboards: Available Used Egress Ingress Bandwidth 3.2 PB 4.0 TB 3.5 TB 433.0 GB (since Jan 1) Disk 1.3 TB 0.7 TB Diese Angaben sollten den Traffic im Monat Januar darstellen und decken sich auch so ungefähr mit meinem gemessenen Traffic. Heißt das, dass ich mit dieser Node bis jetzt im Januar 3,5 TB * 20 $/TB = 70 $ in STORJ Token verdient habe müsste?

Hallo @skunk, gibt es mittlerweile News zum "release" jetzt am Januar? Werden schon Live-Daten auf die Nodes gespielt? Ich habe bemerkt, dass sich meine Nodes sehr Asynchron verhalten. Also z.B. diese beiden Dashboards: Bandwidth 3.2 PB 2.1 TB 1.7 TB 367.6 GB (since Jan 1) Disk 1.4 TB 637.8 GB vs Bandwidth 3.2 PB 55.5 GB 41.0 GB 14.5 GB (since Jan 1) Disk 2.0 TB 33.9 GB

Ah, jetzt check' ich's der Payout ist also pro Satellite und nicht pro Node. Wenn Satellites nicht vertraut werden muss, können dann auch andere Leute Satellites aufsetzen?

Müsste ich eigentlich für jede Node eine Überweisung bekommen? Oder gibt es ein Minimum unter dem nicht überwiesen wird?

Ich denke, ich werde meine eigene Library zum Abfragen schreiben. 😕 Hab' die JSON-RPC-Methode jetzt gefunden: eth_getUncleByBlockNumberAndIndex Aber ich finde das in Nethereum so aufwändig alles...

Okay. Ich dachte, ich bekomme diese E-Mail nur, weil etwas bei STORJ festgestellt hat, dass meine Node noch auf alter Software läuft.

Ich muss das leider in der Blockchain "sehen", damit ich eine Ahnung habe, um was es dort geht. Hast Du mir vielleicht einen Block, wo so etwas passiert oder eine Adresse mit der so etwas passiert ist? Das Abfragen der Uncles liefert mir übrigens leider einen Block Hash. Ich weiß aber nicht, ob ich diesen noch abfragen kann, da dieser ja leider nicht Teil der Blockchain ist. 😢

Also, ich habe Code geschrieben, der alle ERC20 Transactions/Transfers ausliest und auch alle ETH Transactions, incl. Transactions zum Erstellen von SmartContracts. Das GAS jeder Transaction kann ich ebenfalls auslesen, wie auch das gesamte GAS aus dem Block, den Miner, etc. Ich kann sogar wie schon geschrieben die Balances eines jeden SmartContracts zu jedem Block auslesen. Bevor ich das aber in eine Webseite klatsche muss ich ein gutes Datenbank-Design herausfinden und dazu muss ich alle Möglichkeiten, wie ETH noch bewegt oder Erzeugt werden können wissen. Z.B. soll man ja auch sehen, wieso man jetzt mehr ETH "bekommen" hat. Ich würde also in meine Transfer Tabelle auch Mining-Ergebnisse, etc. mit einem Flag eintragen, so dass ich diese dann später anzeigen kann. Dein 2. Link hat mir vermutlich aber die Antwort beschert: web3.eth.getBlock(<block>).uncles Komisch, dass ich das in Nethereum übersehen habe. Ich hoffe uncles enthält auch deren "Miner" und von welchem Block dieser ein Uncle ist.

Weil die Uptime 2 Wochen war und 27.0 ausgelassen wurde vom watchtower.

Es gibt noch einen weiteren Fall bei Ethereum selbst. Vielleicht hast Du da eine Idee: Wenn jemand einen Block mined bekommt er ETH dafür. Und zwar ohne Transfer-Event: Den Block Reward. Das darin verbrauchte GAS. Zusätzliche ETH für ein einbauen von bis zu 2 Uncles. <- Hier beginnt das Problem. Ich kann an einem Block ablesen, wer ihn gemined hat und dann halt davor und danach getBalance für ETH ausführen. Allerdings: Wenn jemand einen Block mined, der es nicht in die Blockchain schafft (einen Uncle) hat dieser Block die Chance in einem der 6 folgenden Blöcken als einer von zwei Blöcken pro Sieger-Block mit aufgenommen zu werden. In diesem Fall bekommt der nicht erfolgreiche Miner 7/8 der ETHs eines normalen Block-Rewards. Weißt Du vielleicht, wie ich mit web3.js (ich versuche das dann in Nethereum zu übersetzen) abfragen kann, welche Uncles in einem Block mit eingebaut wurden und wer deren Miner gewesen wären?

Watchtower hat aber 27.0 ausgelassen und jetzt sind wir schon bei 27.1. (=Kein Update seit 2 Wochen.) Ich habe jetzt manuell von 26.1 (oder 2?) auf 27.1 upgedated.

Ich habe eine E-Mail bekommen, dass ich meine Node unbedingt updaten muss. Dann ist mir aufgefallen, dass das automatische Update mit wachtower derzeit auf keiner meiner nodes funktioniert - hat es aber Mal. Ist das bekannt oder habe ich da nur etwas bei mir vermurxt?

Naja, die wollen damit ja nicht auf eine Börse *denk*. Das Problem ist halt: Was technisch geht sollte ich auch analysieren können. Aber solche Sachen macht das ganze scheiße aufwändig.

Schon klar. Das bezweifelt auch niemand. Es könnte aber jemand Beispielsweise einen Öko-Coin machen, der pro Überweisung zusätzliche 0,5% von dem was überwiesen wurde vom Konto abzieht. Der Contract-Ersteller verspricht dann pro Überweisung für diese 0,5% Bäume zu pflanzen - oder what ever. Es gibt wohl Beispiele für Token, die Transfers machen, ohne einen Transfer zu callen? Z.B.: Chai.sol?

Also, ich hab' jetzt Mal ein bisschen recherchiert. Die ganze Sache gut zu machen ist leider sehr aufwändig: Die Balance eines ERC20 Token kann durch mehr als einen Transfer beeinflusst werden. Z.B. durch Code im Contract. Das führt dazu, dass ich für einen "ordentlichen Kontoauszug" jedes ERC20 Token für jeden Vertrag und jeden Block "Querien" (ausführen von getBalance()) müsste. Ich muss die Funktionalität also entweder auf Token, die idr. nur durch Transfers geändert werden können beschränken oder ich werde nur wenige zeitgleiche Anfragen bearbeiten können. XD Eine Quick & Dirty-Lösung wäre es nach jedem Transfer das Token zu Querien und die Differenz zu der Balance davor und der Balance danach +- Transfer wäre dann, was der SmartContract halt durch den Transfer wegnimmt oder dazu gibt. Würde aber trotzdem keine Sinde-Chain oder -Channel-Token abdecken können, etc. Maeh...

Ich hab' das jetzt mit .NET nachprogrammiert. Das Ergebnis [343 MB, knappe 1,4 Mio Transaktionen] gibt in Reihenfolge den Block, den Hash des Blocks, die Transaktion, Von-Adresse, Zu-Adresse und die STORJ-Tokens an. Mir sind trotzdem noch einige Dinge unklar. Z.B. wie kann ich ermitteln wo bei der Währung der Dezimal-Punkt ist oder wie die Einheit anfürsich heißt? Oder was das Purpose/der Name einer Adresse ist? Ich vermute letztes ist Community-Arbeit? Also ich könnte natürlich verschiedene Events anzeigen. Allerdings muss man bei manchen Nicht-Standard-Events irgendwie die Event-Signatur (Welche Felder es gibt) herausfinden. Das ist noch etwas unübersichtlich für mich. Muss ich dazu den SmartContract decompilieren? Ich hoffe das oben genannte Buch bringt dort Licht ins Dunkel. Ich kann mir vorstellen, dass ich irgendwann in zwei Monaten oder so Zeit finde einen kleinen Blockchain-Explorer für Ethereum und ERC20 Token zu schreiben. Etwas, dass einem zu einer Adresse einen Kontoauszug über alle ERC20 Token für einen bestimmten Zeitraum macht und auch zu dem entsprechenden Zeitpunkt den historischen Wert in EUR oder USD ermittelt. Die Wert-Berechnung geht dann halt nur mit Token, die auf ein oder zwei Exchanges geführt werden, wo ich historische Daten abfragen kann. Ansonsten bin ich mir nicht sicher, ob das Datenbank-Layout der Archive-Node Super Optimal ist oder ob es sich nicht doch lohnen würde alle interessanten Informationen in eine eigene Datenbank zu schreiben. Konsolidiert mit anderen Informationen, die man mit der web3 API nur durch mehrere Calls bekommt - für schnellere Abfragen. Das Abfragen der 1,4 Mio Transaktionen von skunks Beispiel hat doch gute 4 Minuten gedauert.

Also gut. Ich melde mich wieder, wenn ich was implementiert hab'. Ich werde das aber mit Nethereum (.NET) versuchen. Leider gibt 's dort kein getPastEvents auf dem Contract. Ich muss also erst herausfinden, wie das dort geht.

Weil ich damit testen konnte, ob die Node tatsächlich von außen erreichbar ist. Beim überfliegen der verlinkten Doku (im Prinzip Strg+F "history") hab' ich nichts auf Anhieb gefunden, dass sich schnell mit curl realisieren lässt. Aber Du zeigst mir sicher gleich auf, welcher Endpunkt das kann - korrekt?

Äh, ja, danke. Das war mir schon klar. Der Server ist ziemlich stark und die der Node zugeteilten Ressourcen mit Ausnahme der Internetanbindung sind nicht "geshared". Die VM besteht konkret aus folgendem: 8 Kerne Intel Xeon Gold 6146. Im Schnitt werden 2-4 Kerne voll benutzt. Während dem Synchronisieren 256 GB RAM, jetzt (also während dem normalen Betrieb) noch 128 GB. 4 TB RAID 10 SSD Speicherplatz für die Blockchain. (Werde ich demnächst erhöhen.) 10 GBit/s Internet, geshared mit 6 Storj-Nodes. Traffic In: 675 GB, Traffic Out: 124 GB, incl. das finden anderer Nodes zum Synchronisieren, etc. Am meisten benutzt wurde (und wird) die CPU. Danach Disk I/Os. Aber vielleicht schätze ich das auch falsch ein, denn ich habe im Internet Leute gefunden, die das auch versucht haben aufzusetzen und diese sind an "zu langsamer Disk" (laut deren Analyse) gescheitert. Aber natürlich ist die Node von außen erreichbar. Gibt es eine Stelle, wo man so eine Node "registrieren" oder "erwähnen" kann, so dass andere diese evtl. für Nachforschungen benutzen? Eine Anfrage von außen funktioniert jedenfalls: $ curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0xBE0eB53F46cd790Cd13851d5EFf43D12404d33E8", "latest"],"id":666}' http://eth-archive.intb.io:8545 {"jsonrpc":"2.0","id":666,"result":"0x1e1e83d9813f6f46b1faf"} Wenn ich wirklich einen guten Ethereum Blockchain Explorer machen möchte muss ich Ethereum erst Mal richtig verstehen. Hast Du mir da eine Buch- oder Link-Empfehlung? Oder jemanden, der mir wenigstens sagt mit welchen Features man beginnen sollte?

Um 17:30 CET am 29.11.2019 ist die Node gesynced gewesen. Da die Node zwischendrin ungefähr drei Stunden offline gewesen ist bedeutet dies eine Sync-Zeit von: 7 Tagen und 22 Stunden. Die Blockchain ist jetzt 3.305,32 GB groß. Abfragen sind mittel eth- und web3-Protokoll möglich: eth-archive.intb.io Weiß jemand, wie man das testen kann? Christoph?