Storj - Potential?

[skunk]

Storj hat jetzt ein IPFS Gateway im Angebot: https://storj.io/blog/2019/10/ipfs-now-on-storj-network/

Die Entwickler in anderen Projekten sind etwas frustriert über den Funktionsumfang von IPFS. Aktuell ist IPFS einfach nur eine andere Art um Amazon Server anzusprechen. Wir hoffen mit dem IPFS Gateway können wir diesen Projekten jetzt eine gute Alternative zum teuren Amazon Speicher anbieten. Einen Wettstreit mit Filecoin haben wir natürlich nicht im Sinn auch wenn das so aussehen mag. Wir betrachten die "Konkurrenz" eher als Mitstreiter. Wir alle haben das gemeinsame Ziel die klassischen zentralen Lösungen abzulösen. Der Markt ist groß genug und es macht keinen Sinn sich gegenseitig die Augen ausstechen zu wollen.

Edit: Falls jemand den Begriff IPFS nicht einordnen kann, einfach fragen. Ich spiele gern den Erklärbär.

Bearbeitet 8. Oktober 2019 von skunk

[skunk]

Jemand aus der Community hat netterweise eine Youtube Tutorial erstellt: 

 

[skunk]

Der SJCX Konverter wird in Kürze abgeschaltet. Wer noch SJCX hat sollte diese jetzt oder nie in STORJ umtauschen. Falls jemand dabei Hilfe braucht einfach melden. Ich habe in der Vergangenheit bereits einige verloren geglaubte SJCX retten können. Dabei fallen keine Transaktionsgebühren an weil ich das als low fee Transaktion mit praktisch 0 BTC hin bekomme. Also überprüft nochmal eure Wallets. Auch Kleinstbeträge sind kein Problem.

https://storj.io/blog/2019/11/final-call-for-sjcx-to-storj-token-conversions/

Edit: Und wenn wir schon dabei sind hier noch ein paar andere News auf dem letzten Monat:

Wir haben jetzt einen Windows Installer am Start: https://storj.io/blog/2019/10/storage-nodes-are-now-supported-on-windows-home/ Siehe auch das YouTube Video. Die Storage Node wird als Service installiert sodass selbst Windows Updates mit anschließendem Neustart kein Problem sind. Die Storage Node wird nach dem Neustart auch ohne angemeldeten User gestartet und läuft dann fröhlich weiter. Storage Node Updates werden automatisch runtergeladen und installiert.

Wir haben ein Backup Tool für Github entwickelt. Im Grunde ist das nur eine Spielerei um das Potential zu demonstrieren. Keiner von uns rechnet ernsthaft mit einem größeren Ausfall bei Github von daher wird diese Backup Tool hoffentlich nie benötigt. Falls doch ist es aber gut ein Backup in der Hinterhand zu haben. https://storj.io/blog/2019/10/architecting-a-decentralized-github-backup/

Bearbeitet 6. November 2019 von skunk

[GhostTyper]

Also. Hab' jetzt Mal eine Node Testweise aufgesetzt. Scheint auf Anhieb funktioniert zu haben:

Storage Node Dashboard ( Node Version: v0.25.1 )
======================
ID           <id>
Last Contact ONLINE
Uptime       4h58m58s

                   Available       Used     Egress     Ingress
     Bandwidth        3.2 PB     3.5 GB     2.2 GB      1.2 GB (since Nov 1)
          Disk        8.0 TB     1.2 GB
Internal 127.0.0.1:7778
External storj.intb.io:28967

Ich habe aber noch ein paar Fragen und Dinge, die mir nicht klar sind:

1. Sind Traffic und Größen-Angaben exakt so, wie sie sein sollten? Also 1 MB = 1000000 Bytes? Oder wird das irgendwo vermischt mit z.B. MiB?
2. Am Anfang nach 4 Minuten (oder so) hat das Dashboard 32.0 MB angezeigt, in echt benutzte die Disk knappe 33 MiB. Klar, da sind ja auch noch andere Dateien als das reine Storage. Ich habe dem System 9 TiB Storage zugewiesen. 9 TiB sind 9586434468 KiB. Mit ext4 und einer Blockgröße von 4096 formatiert sind noch netto 9103100444 KiB übrig, was aber nur 8,5 TiB sind. Die Node wurde mit 8TB als Parameter gestartet. Frage: Ist das ausreichend oder muss ich die Disk noch vergrößern? Die Anleitung ist da nicht sehr deutlich. Nach der Anleitung würde ich sagen: Nein. Denn wenn jemand eine 8 TB Disk hat geht er davon aus, dass er gute 7 TB nutzen kann. (Da 7 TB dann 7000000000000 Bytes wären.)
3. Die Node hat 4 Kerne und 8 GB RAM zugeteilt bekommen. Reicht das aus?
4. Irgendwo habe ich gelesen, dass es technisch eine Zuverlässigkeitsbewertung oder irgend ein Profiling für die einzelnen Nodes gibt. Kann man diese irgendwie einsehen? Das Dashboard zeigt diese leider nicht an. Gibt es hierfür den Traffic-Typ "Audit"?
5. Wenn so eine Zuverlässigkeitsbewertung oder ein Profiling existiert, wird diese(s) auch zum Verteilen von Blöcken auf Storagenodes herangezogen? Z.B. könnten Nodes mit mehr Traffic Blöcke bekommen, die eher abgefragt werden.
6. Gibt es noch einen anderen Exchange als bhex zum Tauschen von STORJ?
7. Das Dashboard kommuniziert wohl auf dem eingestellten Dashboard-Port mit der Node? Gibt es zu dem Protokoll eine Doku, bzw. kann ich dort selbst einfach Abfragen durchführen?
8. Könnte man das Projekt noch wie (also abseits dem Stellen einer Storagenode) unterstützen?

Vielen Dank.

[skunk]

vor 2 Minuten schrieb GhostTyper:

Sind Traffic und Größen-Angaben exakt so, wie sie sein sollten? Also 1 MB = 1000000 Bytes? Oder wird das irgendwo vermischt mit z.B. MiB?

Das sind 10er Potenzen. Man kann darüber streiten ob das die richtigen Angaben sind. In jedem Fall ist es die Beschriftung, die die Anwender von den Festplatten Hersteller gewohnt sind und daher behaupten es wäre die korrekte Beschriftung. Nein ist sie streng genommen nicht aber darüber zu streiten ist reine Zeitverschwendung.

vor einer Stunde schrieb GhostTyper:

Am Anfang nach 4 Minuten (oder so) hat das Dashboard 32.0 MB angezeigt, in echt benutzte die Disk knappe 33 MiB. Klar, da sind ja auch noch andere Dateien als das reine Storage. Ich habe dem System 9 TiB Storage zugewiesen. 9 TiB sind 9586434468 KiB. Mit ext4 und einer Blockgröße von 4096 formatiert sind noch netto 9103100444 KiB übrig, was aber nur 8,5 TiB sind. Die Node wurde mit 8TB als Parameter gestartet. Frage: Ist das ausreichend oder muss ich die Disk noch vergrößern? Die Anleitung ist da nicht sehr deutlich. Nach der Anleitung würde ich sagen: Nein. Denn wenn jemand eine 8 TB Disk hat geht er davon aus, dass er gute 7 TB nutzen kann. (Da 7 TB dann 7000000000000 Bytes wären.)

8TB ist mehr als ausreichend. Das Payout für belegten Speicher ist eher gering. Auf den Traffic kommt es an. Der belegte Speicher ist somit nur Mittel zum Zweck. Sollten die 8TB irgendwann belegt sein und deine Leitung nicht voll ausgelastet sein, kannst du immer noch eine weitere Storage Node mit weiteren 8TB hinzufügen.

vor 1 Stunde schrieb GhostTyper:

Die Node hat 4 Kerne und 8 GB RAM zugeteilt bekommen. Reicht das aus?

Das ist mehr als notwendig. Ich hätte jetzt gesagt 2 Kerne und 2GB RAM wären zu empfehlen.

vor 1 Stunde schrieb GhostTyper:

Irgendwo habe ich gelesen, dass es technisch eine Zuverlässigkeitsbewertung oder irgend ein Profiling für die einzelnen Nodes gibt. Kann man diese irgendwie einsehen? Das Dashboard zeigt diese leider nicht an. Gibt es hierfür den Traffic-Typ "Audit"?

Mach mal deinen Browser auf und schau was du auf Port 14002 bekommst. Wir haben zwei Dashboards. Einmal das CLI Dashboard mit den nötigsten Informationen und dann eine WebUI, die die von dir gewünschten Informationen anzeigt. Zusätzlich gibt es noch eine API für nackte Zahlen.

vor 1 Stunde schrieb GhostTyper:

Wenn so eine Zuverlässigkeitsbewertung oder ein Profiling existiert, wird diese(s) auch zum Verteilen von Blöcken auf Storagenodes herangezogen? Z.B. könnten Nodes mit mehr Traffic Blöcke bekommen, die eher abgefragt werden.

Klares Ja und Nein. Der Uplink baut eine Verbindung zu 95-130 Storage Nodes auf aber nimmt am Ende nur die 80 schnellsten Storage Nodes. Damit bekommen schnelle Nodes mehr Daten als langsame Nodes. Die Reputation einer Storage Node spielt bei der Selektierung der 95-130 Storage Nodes aktuell noch keine Rolle. Natürlich nur solange man nicht zu viele Daten verliert und dadurch disqualifiziert wird.

vor 2 Stunden schrieb GhostTyper:

Gibt es noch einen anderen Exchange als bhex zum Tauschen von STORJ?

Ja einige: https://coinmarketcap.com/currencies/storj/markets/

vor 2 Stunden schrieb GhostTyper:

Das Dashboard kommuniziert wohl auf dem eingestellten Dashboard-Port mit der Node? Gibt es zu dem Protokoll eine Doku, bzw. kann ich dort selbst einfach Abfragen durchführen?

https://forum.storj.io/t/storage-node-dashboard-api/1270

vor 2 Stunden schrieb GhostTyper:

Könnte man das Projekt noch wie (also abseits dem Stellen einer Storagenode) unterstützen?

Auf jeden Fall. Unglücklicherweise gehöre ich zu den weniger kreativen Menschen daher kann ich dir keine konkreten Vorschläge machen sondern nur ein paar Eckdaten geben.

Erwähnenswert in dieser Hinsicht ist das Open Source Revenue Programm. Das Problem von Open Source Projekten ist, dass sie kaum Einnahmen haben aber trotzdem hohe Rechnungen für Server und Speicherplatz bezahlen müssen. Den eigentlichen Gewinn machen am Ende immer die zentralen Dienste wie Amazon S3. Viele Projekte gehen daran zu Grunde. Aus diesem Grund bieten wir den Open Source Projekten einen Nebenverdienst in Höhe von 10% an. Damit kann das Open Source Projekt seine Software kostenlos anbieten, die Anwender legen einen Storj Account an, Storj kümmert sich um die Abrechnungen und am Ende bekommt das Open Source Projekt 10% vom Kuchen ab. Mit einer tollen Idee lässt sich da einiges machen. Vor allem Ideen, die bei Verwendung der klassischen Dienste ein Verlustgeschäft wären.

[GhostTyper]

Hallo Skunk,

ich habe mich schon per HTTP auf Port 14002 zum Dashboard verbunden gehabt. Dort habe ich auch gesehen, dass es den Traffic-Typ "AUDIT" gibt. Zu dieser Traffic-Ansicht habe ich auch glich noch eine Frage - neben ein paar weiteren Fragen:

1. Es gibt die Traffic-Typen USAGE, REPAIR und AUDIT. USAGE und REPAIR werden dabei in eingehend und ausgehend unterschieden. Nun habe ich während regulärem USAGE-Traffic auch REPAIR INGRESS Traffic. Bedeutet dies, dass bei mir etwas repariert werden musste oder aber bedeutet dies, dass eine andere Node irgendwo ausgefallen ist und daher Blöcke zu mir transferiert wurden?
2. Ich habe jetzt herausgefunden, wie ich die Zuverlässigkeitsbewertung abfragen kann. Die von Dir verlinkte API liefert die Werte alpha, beta und score für jeden Satellite. Es sieht so aus, wie wenn bisher nur 2 von 4 Satellites mit mir kommuniziert hätten. Überall habe ich zwar einen Score von 1 (100%?) der Alpha-Wert ist aber nicht so hoch wie bei anderen Nodes im Internet, wenn man den Posts der Besitzer glauben kann. Hast Du mir weitere Informationen, was für eine Metrik alpha und beta besitzen? Gibt es Maximal- und/oder Minimal-Werte?
3. In einer .md-Datei auf Github habe ich irgendwo gelesen: "The existing reputation-like system uses uptime and audit responses. It does not currently consider geographic location, throughput, or latency." Gibt es schon einen Plan, wann sich das ändert?
4. Kann jemand aus seiner Erfahrung heraus sagen, wie sich der Traffic einer Node verhält, wenn es virtuell keine Geschwindigkeitseinschränkungen gibt? Ich habe der Node jetzt eine dedizierte synchrone 10G-Anbindung zugewiesen. Bei jeder Rechnung und bei jedem Nutzungsprofil, dass mir einfällt ist diese Anbindung für "nur" 8 TB Netto-Speicherplatz zu viel und wird vermutlich nie ausgenutzt werden? Alleine aus dieser Perspektive wäre es natürlich interessant für mich, wenn Storagenodes danach bewertet werden welchen Traffic sie stabil liefern können.
5. Siehe (3) und (4): Ist, wenn irgendwann evtl. implementiert wird, dass Latenz direkt und auch Durchsatz mit in die Bewertung einfließt auch geplant, dass die Blöcke von Nodes defragmentiert werden, so dass häufiger angefragte Blöcke auf "schnellere" Nodes verschoben werden?

[skunk]

1. Wenn du Daten verloren hättest, dann würdest du den dazugehörigen Repair Traffic nicht mitbekommen. Der Satellite lädt von den verbleibenden Storage Node die Daten runter, rekonstruiert die verlorenen Teile und lädt diese zu neuen Storage Nodes hoch.
2. Der Score ist alpha / (alpha + beta). Alpha kann maximal den Wert 100 erreichen. Beta sollte nach Möglichkeit nahe 0 bleiben. Ein fehlerhafter Audit wird den alpha Wert leicht verringern und den beta wert leicht erhöhen. Mehrere fehlerhafte Audits in Folge werden diesen Effekt sehr schnell ansteigen lassen. Eine Handvoll Audits genügen um disqualifiziert zu werden. Vereinzelte Audit Fehler bleiben dagegen ohne größere Folgen.
   Die Anzahl der Audits ist abhängig von der Menge an Daten die du speicherst. Am Anfang wirst du nur wenige Audits pro Tag bekommen und der Satellite wird dir auch nur 5% der Uploads anvertrauen. Erst wenn du 100 audits erreicht hast, was einige Wochen dauern wird, vertraut dir der Satellite genug um dir deutlich mehr Daten zukommen zu lassen.
3. Wir haben einen sehr kurzen Release Zyklus von nur 2 Wochen. Das nächste Release ist geplant für Mittwoch. Ich kann aktuell nur sagen, dass in dem Release nichts passendes enthalten sein wird. Was im Release 2 Wochen später enthalten ist, kann ich noch nicht sagen. Von daher ja es gibt Pläne aber Pläne ändern sich auch mal kurzfristig und ich kann nicht sagen wann es kommen wird.
4. Das was du aktuell an Daten und Traffic bekommst, sind großteils Testdaten mit denen wir das Netzwerk testen und bei Laune halten. Klassisches Henne und Ei Problem. Um den Kunden genug Speicherplatz und Performance garantieren zu können, brauchen wir ausreichend Storage Nodes. Um Storage Nodes zu bekommen brauchen wir ausreichend Aktivität im Netzwerk. Mit Hilfe der Testdaten können wir für ein Gleichgewicht sorgen. Der Nachteil ist allerdings, dass es aktuell nicht möglich ist vorher zu sehen wie das Verhältnis von Speicherplatz zu Traffic ist. Es gibt Dienste wie transfer.sh die eine Datei für nur 2 Wochen speichert aber in der Zeit mehrfach runter lädt. Sowas wäre natürlich ideal.
5. Selbe Antwort wie 3. Geplant ist vieles aber ob und wann es umgesetzt wird, steht auf einem anderen Blatt.

[skunk]

Der Linux Installer ist bisher noch in der Design Phase. Mehr zu dem Thema gibt es hier: https://forum.storj.io/t/design-draft-installation-and-auto-update-on-linux/2591

Aktuell bleibt also nur die Variante Docker oder selber kompilieren.

Bearbeitet 18. November 2019 von skunk

[skunk]

Ein weiterer Meilenstein ist erreich. Die News über das Pioneer 2 Release wurde heute veröffentlicht: https://storj.io/blog/2019/11/announcing-pioneer-2-and-tardigrade.io-pricing/

[GhostTyper]

Reicht es den Docker-Container mit anderen Parametern neu zu starten, wenn ich etwas (z.B. Größe) ändern möchte?

Denn ich habe das Gefühl, dass es sich jetzt eher lohnen könnte 3 oder mehr Server-IDs warm laufen zu lassen.

[battlecore]

Mal ne Frage nebenbei.

Wie hoch sollte die Uploadgeschwindigkeit sein um eine Node brauchbar laufen zu lassen? Kommt man da mit etwa 1500-2000Kbit hin oder muss das deutlich mehr?

Ach ne hat sich schon erledigt, habs grad gelesen krasse Anforderungen für jemand mit DSL aufn Dorf.

Bearbeitet 19. November 2019 von battlecore

[GhostTyper]

Für die, die diese Information noch suchen:

Die angegebenen Mindestanforderungen sind 5 Mbps upstream und 25 Mbps downstream.

Nach knappen 60 Stunden Laufzeit hat meine Node 24,2 GB ausgehenden und 16,1 GB eingehenden Traffic gehabt. Das ist umgerechnet ein knappes Mbit upstream und 2/3 Mbit downstream. Wirkt für mich hauptsächlich wie generierter Traffic.

Allerdings bezweifle ich, dass dies so bleiben wird, wenn das System im Januar 2020 live geht.

Noch etwas zu schwachen Leitungen: Den meisten Verdienst bekommt man durch den Traffic und nicht durch das halten von Daten.

[skunk]

vor einer Stunde schrieb GhostTyper:

Reicht es den Docker-Container mit anderen Parametern neu zu starten, wenn ich etwas (z.B. Größe) ändern möchte?

Denn ich habe das Gefühl, dass es sich jetzt eher lohnen könnte 3 oder mehr Server-IDs warm laufen zu lassen.

Ja das sollte reichen. Später mit dem Linux Installer wäre eine Anpassung in der Konfigurationsdatei und ein Neustart notwendig.

[skunk]

vor 39 Minuten schrieb battlecore:

Wie hoch sollte die Uploadgeschwindigkeit sein um eine Node brauchbar laufen zu lassen? Kommt man da mit etwa 1500-2000Kbit hin oder muss das deutlich mehr?

Ach ne hat sich schon erledigt, habs grad gelesen krasse Anforderungen für jemand mit DSL aufn Dorf.

Glaub mal nicht, dass das hier in der Großstadt besser wäre. Ich habe VDSL 25 aber auch das hat nur 10MBit/s im Upload. Deutschland ist was das angeht auf den hinteren Plätzen.

2MBit/s würde durchaus funktionieren. Die Minimalanforderung sind eher dafür da um ein gewisses Payout zu ermöglich damit es für die Storage Node überhaupt wirtschaftlich wird. Mit 2MBit/s kommt man auf höchstens 650 GB an bezahlten Traffic und das auch nur wenn die Leitung nonstop auf voller Last läuft. Realistischer wäre eher eine 50% Auslastung wenn nicht sogar weniger. Wir reden in deinem Fall also von einem Payout von unter 10$. Damit wirst du nicht glücklich, verlässt das Netzwerk und das kostet uns am Ende Geld wegen der Reparatur Kosten. Aus diesem Grund haben wir etwas anspruchsvollere Anforderungen. Wir wollen sicher stellen, dass die Storage Nodes, die diese Anforderungen erfüllen, zumindest theoretisch ein Payout bekommen können mit dem sie überleben können.

Bearbeitet 19. November 2019 von skunk

[battlecore]

vor 37 Minuten schrieb skunk:

Glaub mal nicht, dass das hier in der Großstadt besser wäre. Ich habe VDSL 25 aber auch das hat nur 10MBit/s im Upload. Deutschland ist was das angeht auf den hinteren Plätzen.

2MBit/s würde durchaus funktionieren. Die Minimalanforderung sind eher dafür da um ein gewisses Payout zu ermöglich damit es für die Storage Node überhaupt wirtschaftlich wird. Mit 2MBit/s kommt man auf höchstens 650 GB an bezahlten Traffic und das auch nur wenn die Leitung nonstop auf voller Last läuft. Realistischer wäre eher eine 50% Auslastung wenn nicht sogar weniger. Wir reden in deinem Fall also von einem Payout von unter 10$. Damit wirst du nicht glücklich, verlässt das Netzwerk und das kostet uns am Ende Geld wegen der Reparatur Kosten. Aus diesem Grund haben wir etwas anspruchsvollere Anforderungen. Wir wollen sicher stellen, dass die Storage Nodes, die diese Anforderungen erfüllen, zumindest theoretisch ein Payout bekommen können mit dem sie überleben können.

Das würde bei mir nebenbei neben dem Miner laufen, diese Uploadgeschwindigkeit hätte ich also tatsächlich über da meine Uploadgeschwindigkeit über der üblichen liegt. Aber die Anforderung von 25MBit Download käme bei mir auch nicht hin, ich hatte vor kurzem nochmal einen Speedtest gemacht, da lag ich so bei 11MBit und das ist dann ja bei idealer Servergeschwindigkeit wo ich den Test mit mache. Zudem weiß ich nicht ob die mir meinen billigen Magenta Zuhause S bei 650 GB Traffic einfach kündigen

Naja aber wäre eine nette Geschichte so für nebenbei gewesen, das Rig läuft ja eh fast unterbrechungslos.

[skunk]

vor 21 Minuten schrieb GhostTyper:

Allerdings bezweifle ich, dass dies so bleiben wird, wenn das System im Januar 2020 live geht.

Vergiss mal für einen Moment, dass ich für Storj arbeite. Ich habe selber 3 Storage Nodes am Laufen und stelle mir die Frage ob ich diese langfristig wirtschaftlich betreiben kann. Daher würde mich mal interessieren was deine Vorhersagen so sind.

[skunk]

vor 1 Minute schrieb battlecore:

Das würde bei mir nebenbei neben dem Miner laufen, diese Uploadgeschwindigkeit hätte ich also tatsächlich über da meine Uploadgeschwindigkeit über der üblichen liegt. Aber die Anforderung von 25MBit Download käme bei mir auch nicht hin, ich hatte vor kurzem nochmal einen Speedtest gemacht, da lag ich so bei 11MBit und das ist dann ja bei idealer Servergeschwindigkeit wo ich den Test mit mache. Zudem weiß ich nicht ob die mir meinen billigen Magenta Zuhause S bei 650 GB Traffic einfach kündigen

Naja aber wäre eine nette Geschichte so für nebenbei gewesen, das Rig läuft ja eh fast unterbrechungslos.

Probier es einfach aus. Gib der Storage Nodes erstmal nur 500GB und schau wie sie sich entwickelt. Viel wird sie nicht erwirtschaften können aber wenn die Hardware sowieso läuft, sollte das ja kein Problem sein. Im schlimmsten Fall wirst du irgendwann aus dem Netzwerk geschmissen weil du zu langsam für die Audits wirst. Daher erstmal nur mit 500GB anfangen und das dann als Stellschraube nutzen um den Traffic nahe an das Maximum zu bekommen ohne eine Rausschmiss zu riskieren.

[battlecore]

vor 2 Minuten schrieb skunk:

Probier es einfach aus. Gib der Storage Nodes erstmal nur 500GB und schau wie sie sich entwickelt. Viel wird sie nicht erwirtschaften können aber wenn die Hardware sowieso läuft, sollte das ja kein Problem sein. Im schlimmsten Fall wirst du irgendwann aus dem Netzwerk geschmissen weil du zu langsam für die Audits wirst. Daher erstmal nur mit 500GB anfangen und das dann als Stellschraube nutzen um den Traffic nahe an das Maximum zu bekommen ohne eine Rausschmiss zu riskieren.

Hmm okay wäre eine Möglichkeit. Probier ich mal aus, muss dann mal noch eine größere SSD besorgen. Hab zum minen nur eine 120er.

[skunk]

vor 3 Minuten schrieb battlecore:

Hmm okay wäre eine Möglichkeit. Probier ich mal aus, muss dann mal noch eine größere SSD besorgen. Hab zum minen nur eine 120er.

HDD wäre kostengünstiger. Einen Performance Vorteil hast du mit der SSD kaum.

[battlecore]

vor 4 Minuten schrieb skunk:

HDD wäre kostengünstiger. Einen Performance Vorteil hast du mit der SSD kaum.

Ja das schon. Aber dann muss ich da noch ne große Festplatte ins Rig friemeln, ich hatte die zuletzt zusammen mit dem DVD-Brenner mit Panzertape drangepappt weil alles voll war Daraufhin hatt ich eine M2 SSD besorgt weil die kleinen ja auch supergünstig fürn Zwanni zu haben sind.

Mit einer M2-SSD ist das Platzmässig total schick.

[GhostTyper]

vor einer Stunde schrieb skunk:

Daher würde mich mal interessieren was deine Vorhersagen so sind.

Uff. Da mir die Ressourcen egal sind muss ich kurz darüber nachdenken. An der Stelle würde mich sowieso Mal interessieren, was Du eigentlich genau für STORJ machst.

Zuerst folgendes Vorwort: Ich finde die meisten Coins oder Token, die nicht ausschließlich als Währung dienen sollen haben ein großes Problem: Keine echte Anwendung oder gesponnene Zukunftsvisionen, die später sowieso von einer Regierungs- oder Firmen-Blockchain oder Blockchain-Fremden Technologie übernommen werden. Und wenn man genau hinschaut bräuchte man für die meisten Systeme keine Blockchain-Technologie.

Bei STORJ bräuchte man natürlich auch kein extra Token, denn es ist theoretisch Blockchain-Agnostisch. Aber STORJ hat eine echte Anwendung und vermutlich wollte man auch irgendwie Geld sammeln. :D Eine echte Anwendung zu haben finde ich schon mal eine gute Voraussetzung!

Kommen wir zum Revenue.

Tardigrade muss Konkurrenzfähig sein. Konkurrenzfähig dazu, dass sich jemand ein eigenes Storage kauft. Oder ein Storage in einem Rechenzentrum mietet. Da hat man ja ermittelt, dass man dem Endkunden 45 $ pro TB "download" und 10 $ pro TB "Speicherung" berechnen möchte. Der Node-Betreiber bekommt davon 20 $ pro TB upload zum Client (also download von der Node) und 1,5 $ pro TB Speicherung.

Was muss eine Storagenode dafür "leisten"? Neben der regulären Speicherung und dem Ausliefern von Daten? Ganz klar: Die Reparatur. Erasure Codes haben den Nachteil, dass sie mehr Blöcke für eine Reparatur pro Block benötigen (laden müssen) als einfache Replikation. Und wenn mehr als eine Node, die Blöcke hält kaputt geht steigt die benötigte CPU-Last deutlich. Allerdings werden die meisten Consumer-Internet-Anschlüsse sowieso eher an der Bandbreite scheitern.

Speicherung: 1,5 $ pro TB sind nicht so viel. Eine 16 TB HD macht hier also 24 $ pro Monat und das auch nur, wenn die Disk tatsächlich voll ist. Allerdings wird sich Consumer-Hardware im Optimalfall vermutlich rechnen, bevor sie ausfällt.

Traffic: Ja, hier wird man wohl am meisten verdienen. Aber für Consumer-Internetzugänge, deren Upload meistens sowieso langsam ist? Rechnen wir das. Um 20 $ zu verdienen muss man 1 TB hochladen. 1 TB sind 3 MBit/s. Für diesen Uplink benötigt man mindestens VDSL, was leider immer noch nicht überall Standard ist. Mit 10 MBit Uplink kann man also ungefähr 60 $ pro Monat verdienen. Und das alles auch nur, wenn eine konstante Anforderung herrscht.

So, jetzt haben wir die Opimalfälle berechnet. Werden diese Eintreten?

Das hängt natürlich davon ab, wie sehr das Netzwerk benutzt wird und wie viele Kunden und welches Anforderungsprofil es an den Speicher gibt. Ich bin mir sicherer als die Zuverlässigkeit von Tardigrade, dass dieser Optimalfall für mich nicht eintritt. :D

Bei privaten Internetanschlüssen, die halt den minimum Upstream von 5 Mbit/s haben und eine große Disk verwenden kann es schon sein, dass es sich "lohnt". Wobei "sich lohnen" dann halt "nur" um 50 $ pro Monat handelt, nachdem die Node (vermutlich) schon ein Jahr online ist. Zusammen mit den folgenden Nachteilen: Stromverbrauch, der eigene Upstream wird in dem Fall dann "lahm" werden.

Im Vergleich zu regulärem Mining von irgend einer Crypto-Währung mit Consumer-Hardware klingt 50 $ pro Monat gar nicht so schlecht.

Ich schätze das alles hättest Du auch selbst ausrechnen können.

Ich kenne kaum Anwendungen, die z.B. S3 als BackEnd verwenden. Aber ich vermute Mal, dass aufgrund der Preispolitik primär Offsite-Backups gespeichert werden.

Ich habe ehrlich gesagt keine Ahnung, wie das ausgehen wird. Ich hoffe jedenfalls, dass das System so schlau werden wird, dass es automatisch oft frequentierte Blöcke auf die Nodes verschiebt, die diese auch schnell ausliefern können. Ohne eine solche Funktionalität vermute ich, dass meine (und somit auch jede andere) Node bei unter 20 $ Traffic den Monat hängen bleibt.

[skunk]

vor 6 Stunden schrieb GhostTyper:

An der Stelle würde mich sowieso Mal interessieren, was Du eigentlich genau für STORJ machst.

Mein Job ist aktuell Release Manager und so langsam bekomme ich noch die Rolle des Test Managers übertragen.

vor 6 Stunden schrieb GhostTyper:

Ich schätze das alles hättest Du auch selbst ausrechnen können.

Jetzt kommt der witzige Teil. Ja ich kann mir das selber ausrechnen aber weil ich für Storj arbeite, stufe ich mich selber als befangen ein und glaube davon dann kein Wort  

In dem Sinne vielen Dank für dein Feedback.

vor 6 Stunden schrieb GhostTyper:

Ich habe ehrlich gesagt keine Ahnung, wie das ausgehen wird. Ich hoffe jedenfalls, dass das System so schlau werden wird, dass es automatisch oft frequentierte Blöcke auf die Nodes verschiebt, die diese auch schnell ausliefern können. Ohne eine solche Funktionalität vermute ich, dass meine (und somit auch jede andere) Node bei unter 20 $ Traffic den Monat hängen bleibt.

Lass uns darüber nochmal Anfang nächsten Jahres sprechen. Ich warte eigentlich nur auf den richtigen Augenblick um den Entwicklern zu zeigen was ohne dieses Feature passieren wird. Noch fehlen mir handfeste Zahlen um meinen Standpunkt auch beweisen zu können. Das sollte sich aber in kürze ändern.

Bearbeitet 20. November 2019 von skunk

[GhostTyper]

vor 14 Stunden schrieb skunk:

Jetzt kommt der witzige Teil. Ja ich kann mir das selber ausrechnen aber weil ich für Storj arbeite, stufe ich mich selber als befangen ein und glaube davon dann kein Wort

Komm schon. Ein bisschen mehr Vertrauen in Euer Produkt.

Ich möchte noch ein paar Dinge zu STORJ sagen:

Vertrieb

Es ist ein leidiges Thema. Vor allem ich als Softwareentwickler musste das erst lernen: Aber Vertrieb ist eine sehr wichtige Abteilung einer Firma oder eines Projekts. Und Vertrieb ist das, was STORJ auf jeden Fall benötigt. Ich glaube ohne "professionelle" Kunden wird wahrscheinlich überwiegend das passieren, was ich oben geschrieben habe: Leute benutzen das als Datengrab für Daten, die sie hoffentlich nie wieder laden müssen. Zumindest solange die Preispolitik so bleibt.

Unterschiede zwischen S3 Gateway und S3 von Amazon

Das S3 von Amazon hat ein paar Vorteile gegenüber dem S3 Gateway. Erstmal muss man bei Amazon kein eigenes S3 Gateway aufbauen. Es ist einfach da. Dann ist das S3 von Amazon in der Amazon Cloud selbst natürlich schneller als Tardigrade. Es ist nur langsamer von außerhalb. Da bei Amazon die Traffic-Kosten nach außerhalb auch sehr teuer sind könnte Tardigrade aus AWS heraus sogar teurer sein.

Was ich mir technologisch wünschen würde

Ich finde die Plattform sollte so erweitert werden, dass Leute auch Interfaces wie das S3 Gateway anbieten können. Und zwar über die normale "Abrechnung", die es schon gibt. Dann gäbe es zu den Storage-Nodes halt auch noch Interface-Nodes. Dort wären halt die Preise etwas höher, dafür spart sich der Endkunde das Aufsetzen eines S3-Gateways. Oder eines IPFS-Gateways. Oder vielleicht in der Zukunft eines FTP- oder HTTP-Gateways.

Fragen

1. Hältst Du es für eine bessere Strategie jetzt mehr Nodes aufzusetzen, so dass diese bis zum Januar "mehr Trustworthy" sind?
2. Wenn ich den DNS-Namen der Node ändern möchte, reicht es dazu auch einfach den Docker-Container neu zu starten?
3. Gibt es eine Möglichkeit eine Node komplett platt zu machen und den Key zu reusen?

Bearbeitet 21. November 2019 von GhostTyper
+Fragen

[skunk]

vor 2 Minuten schrieb GhostTyper:

Vertrieb

Es ist ein leidiges Thema. Vor allem ich als Softwareentwickler musste das erst lernen: Aber Vertrieb ist eine sehr wichtige Abteilung einer Firma oder eines Projekts. Und Vertrieb ist das, was STORJ auf jeden Fall benötigt. Ich glaube ohne "professionelle" Kunden wird wahrscheinlich überwiegend das passieren, was ich oben geschrieben habe: Leute benutzen das als Datengrab für Daten, die sie hoffentlich nie wieder laden müssen. Zumindest solange die Preispolitik so bleibt.

Vielleicht hat der Vertrieb bereits einige große Deals in der Tasche nur sind diese bisher nicht öffentliche bekannt gegeben? Wenn dem so wäre, dann dürfte ich dazu natürlich auch keine Aussagen machen. Ich bin selber gespannt was da noch veröffentlicht werden wird.

vor 14 Minuten schrieb GhostTyper:

Unterschiede zwischen S3 Gateway und S3 von Amazon

Das S3 von Amazon hat ein paar Vorteile gegenüber dem S3 Gateway. Erstmal muss man bei Amazon kein eigenes S3 Gateway aufbauen. Es ist einfach da. Dann ist das S3 von Amazon in der Amazon Cloud selbst natürlich schneller als Tardigrade. Es ist nur langsamer von außerhalb. Da bei Amazon die Traffic-Kosten nach außerhalb auch sehr teuer sind könnte Tardigrade aus AWS heraus sogar teurer sein.

Ja das sehe ich genauso. Es gibt genug Kunden, die von Außerhalb Daten hochladen und dann keine Cloud Instance damit arbeiten lassen. Es gibt aber auch einige Kunden, die den Speicher direkt an ihre Cloud Instance anbinden. Für die lohnt sich ein Wechsel überhaupt nicht. Zumindest noch nicht. Interessant würde es werden wenn einer der dezentralen Cloud Computing Netzwerke anfängt auf dieser Front einen Angriff zu starten. Vielleicht rechnet es sich dann für die Kunden.

Ich hatte auf SNM gesetzt aber die haben lieber ihr ICO Geld veruntreut anstatt was ordentliches auf den Markt zu bringen  

vor 7 Minuten schrieb GhostTyper:

Was ich mir technologisch wünschen würde

Ich finde die Plattform sollte so erweitert werden, dass Leute auch Interfaces wie das S3 Gateway anbieten können. Und zwar über die normale "Abrechnung", die es schon gibt. Dann gäbe es zu den Storage-Nodes halt auch noch Interface-Nodes. Dort wären halt die Preise etwas höher, dafür spart sich der Endkunde das Aufsetzen eines S3-Gateways. Oder eines IPFS-Gateways. Oder vielleicht in der Zukunft eines FTP- oder HTTP-Gateways.

Das geht nicht. Das Gateway ist für die Verschlüsselung zuständig. Der Kunde muss selber sein Gateway aufsetzen sonst ist es keine Ende zu Ende Verschlüsselung mehr. Würde das auf einer Storage Node mitlaufen, so könnte die Storage Node alle Daten in Klartext mitlesen.

Ich betrachte das S3 Gateway nur als Mittel zum Zweck. Es ist super um bei den großen Firmen mal kurz an die Tür zu klopfen. Das S3 Gateway macht einen Vergleichstest sehr einfach. Wenn sie auf den Köder anspringen, dann erzählen wir ihnen, dass eine direkte Kommunikation mit dem Netzwerk schneller und sicherer wäre. Der einzige Nachteil ist, dass es Entwicklungszeit kostet. Das S3 Gateway ist einfach nur ein besserer Tür Öffner  

vor 21 Minuten schrieb GhostTyper:

Noch eine Frage

Hältst Du es für eine bessere Strategie jetzt mehr Nodes aufzusetzen, so dass diese bis zum Januar "mehr Trustworthy" sind?

Wenn du die Hardware sowieso am Start hast dann ja. Extra Geld ausgeben würde ich aktuell noch nicht. Erstmal abwarten was da im Januar über die Leitung geht.

[GhostTyper]

vor 5 Minuten schrieb skunk:

Das geht nicht. Das Gateway ist für die Verschlüsselung zuständig. Der Kunde muss selber sein Gateway aufsetzen sonst ist es keine Ende zu Ende Verschlüsselung mehr.

Doch, doch, das geht schon. Nur halt eben ohne Verschlüsselung. Eben wie bei S3. Aber ich sehe schon ein, dass das ein Problem sein könnte, da sich Leute mit so einer Node registrieren nur um dann Daten abzugreifen. 😢

Ich habe noch andere Fragen ergänzt.