Hab ich das richtig verstanden, das du @Blocktrainer bei IOTA das Problem siehst, das Nodes dadurch, das Nodes kein Geld verdienen, nur noch von großen Anbietern angeboten werden, die nur noch eigene Transaktionen verifizieren bzw. ein kostenpflichtiges Angebot - white-listing, etc. - daraus machen?
Ich denke nämlich, das dies nicht wirklich ein Problem darstellt.
Ich denke, das wird ähnlich wie bei VPN Servern und z.B. kostenlosen Angeboten wie z.B. Tor. Also das es zu kostenpflichtigen Angeboten auch Non-Profit-Nodes geben wird, die sich z.B. über Spenden finanzieren werden - oder eben auch komplett freie Nodes von Unis etc. geben wird. Die werden zwar vielleicht die Transaktionsmenge beschränken, um kommerzielle Nutzungen einzuschränken, aber trotzdem eine nutzbare Geschwindigkeit bieten.
Klar wären die nicht vollständig dusting safe - aber black-listings, Transaktionsbeschränkungen, etc. - ähnlich wie bei DDOS Attacken - und ähnliche Methoden werden da sicher auch entstehen, um das Risiko zu minimieren.
Das Problem haben ja eben andere Webservice und z.B. das Tornetzwerk ja auch.
Und wenn es viele dieser kostenfreien Angebote gibt, wird es auch immer schwerer eine dusting Attacke flächendeckend durchzuführen.
Alles natürlich vorausgesetzt, das Sharding kommt und funktioniert.
Just meine 2Sats - aber vielleicht habe ich das ja auch grundsätzlich falsch verstanden…
Grüssle in die Runde - now discuss!
Hallo @samreciter.
Bin mir nicht sicher, aber ich glaube genau das will der durchschnittliche crypto-enthusiast nicht. Außerdem würde das Verhindern von Dusting-Attacken durch blacklisting die Load auf Nodes sehr erhöhen, weil diese ja die Ursprünge jeder neuen Überweisung überprüfen müssten.
Hier können ja nur die Transaktionen, welche über die JSON-API kommen begrenzt werden. Transaktionen, welche über das Node-zu-Node Protokoll kommen können so nicht begrenzt werden, denn sonst riskiert eine Node, dass sie nur einen Teil-Tangle abbildet. (Selbes übrigens für blacklisting.)
Webservices vielleicht, wenn sie etwas speichern, das TOR-Netzwerk nicht (im Bezug auf Dusting).
Ich habe entweder ein Video diesbezüglich vom Blocktrainer verpasst oder wir verstehen etwas anderes unter dem Begriff Dusting.
Dusting ist ein Angriff, der die Festplattennutzung drastisch erhöht, indem Adressen im Netzwerk belegt werden, die dann von jeder Node abgespeichert werden müssen.
Die Argumentation vom @Blocktrainer ist, dass Nodes nur noch von Instanzen betrieben werden können, die sich den teuren (und schnellen) Speicher leisten können, wenn viele der Adressen benutzt werden.
Dabei ist es unerheblich, welche Restriktionen die Node-APIs haben, da jemand, der diesen Angriff im großen Stil planen würde seine eigenen Nodes aufsetzt und die Transaktionen somit über das Node-zu-Node-Protokoll einspielt.
Warum macht das einen Unterschied? (ist denn schon klar, wie das Sharding genau funktionieren soll, dass man so eine Annahme treffen kann?)
Das Sharding, so wie es von Hans Moog angedacht ist, erlaubt nur einen Teil des IOTA Tangles zu speichern und erlaubt auch die Auswahl von Transaktionen die auf dem Node bearbeitet werden.
Hans Moogs Medium Artikel dazu…
„Nodes should be able to individually decide how much and which data they want to process so that we can have a heterogeneous network with low-powered IoT devices alongside more powerful nodes.“
Das würde black-/whitelisting erlauben und könnte so Dusting Attacken verhindern. Aber wahrscheinlich eben auch Transaktionsbeschränkungen - da es ja eine Möglichkeit zu Identifizierung der Transaktionen geben muss.
Und klar wollen Crypto Enthusiasten einen unbeschränkten Zugang für Alle - das muss aber nicht gut für den Tangle sein und wäre - meiner Meinung - auch nicht nötig, da man frei oder recht freie Nodes weiterhin haben könnte.
Es tut mir leid, @samreciter, aber Deine Frage kann nicht „gut“ beantwortet werden, weil dem Konzept von Hans essentielle Teile fehlen. Sprich: Es funktioniert ohne dass er weitere Teile beschreibt überhaupt nicht.
Bevor ich nun auf Basis dessen, was er beschreibt, eine Einschätzung vornehme: Folgender Disclaimer:
- Sein Konzept ist inkomplett, dadurch können meine Annahmen falsch sein. Um das zu verdeutlichen:
- Sein Sharding-Konzept löst nicht auf, was passiert, wenn alle Nodes die Knoten eines Teilstamms verwaisen lassen, bzw. wie dem entgegengewirkt wird.
- Sein Sharding-Konzept löst (angekündigter weise) nicht auf, wie ich mein Wallet, welches ich in den USA erstellt und aufgeladen habe in meinem Auto in Europa zum tanken nutzen könnte, bzw. wie eine verantwortliche Node gefunden wird.
- Weiter möchte ich noch zu bedenken geben, dass dem Hans seine Vorschläge nicht immer implementiert werden. Siehe: Fast Probabilistic Consensus.
Ich treffe jetzt also Annahmen, unter deren Gesichtspunkte ich Deine Frage „beantworte“ (=die Antwort errate trifft es vielleicht besser).
Das von Hans beschriebene Sharding-Konzept erlaubt es einer Node zu wählen in welcher „Region“ im Tangle (die ja einer Region auf dem Planeten entspricht) ein Knoten in den DAG eingehängt werden soll.
Sprich: Jemand, der einen Dusting-Angriff startet kann diesen sogar noch gezielt gegen eine Region auf dem Planeten richten. Und die lokalen Nodes können nichts dagegen tun, denn sonst würden sie ja einen Teil ihres lokalen Netzwerks ignorieren.
Das (wir erinnern uns: Nicht fertige) Konzept von Hans ließe sich sogar dahingehend missbrauchen, dass jemand gezielt Schneisen zwischen Regionen oder sogar durch Regionen „schlägt“, die extrem viele Transactions enthalten. Dies würde eine natürliche Split-Barriere für kleinere Nodes bedeuten, die extern gezielt steuerbar ist.
Sprich: Sein Konzept erhöht die von Dusting ausgehende Gefahr für Regionen sogar. Und zwar in dem Sinne, dass der Angreifer einen Ort im Tangle (und somit einen Ort auf dem Planeten) für einen gezielten und „permanenten“ Netsplit für schwächere Nodes auswählen kann.
Leider: Nein. Die Shards wären nicht User-Konfiguriert, sondern nach Region konfiguriert und Transaktionen über die API von oder für einen solchen Ort abzulehnen wäre unfreundlich. Transaktionen über das Node-zu-Node Protokoll abzulehnen könnte sogar zu einem dem Sharding orthogonalen Netsplit führen, was dazu führen würde dass die Node nicht mehr Teil des DAGs wäre - also mindestens neue Transaktionen nicht mehr sehen würde.
Würde die IF so denken müssten sie auch nicht weg vom Coordinator.
Ich würde, bis das Sharding-Konzept von Hans öffentlich geprüft werden kann (also alle Teile veröffentlicht sind) nicht weiter darauf bauen. Aus meiner Sicht wirft das Konzept jetzt schon spieltheoretische Fragen auf, die nicht einfach zu klären sind. (Wie stellt man eine 100% Abdeckung des Tangles auf mehreren Nodes sicher, etc.)
Sieh das doch nicht so eng, das ist eine Foundation, die sind ganz schnell gewachsen und das ist doch alles nicht so schlimm
Obwohl ich dir recht gebe, das das Sharding Konzept bis jetzt - zumindest in der öffentlichen Dokumentation - unvollständig und veraltet ist, hoffe ich, das du auch in den zweiten Teil des Medium Artikels rein geschaut hast.
Zwar stellt das „real world“ mapping eine Idee dar - ähnlich wie bei CDNs die Zugriffsgeschwindigkeit zu verbessern - die beschriebene Umsetzung lässt aber auch willkürliche Shards zu - wie z.b. geschlossene Firmen Nodes oder überregionale Community Nodes.
every node and transaction carry a marker that defines to which shard they belong
Every shard has a certain jurisdiction that it is responsible for and a user that tries to spend blue funds in the red shard will simply be ignored. This mechanism is called state sharding .
Das könnten beim automatischen Sharding - z.B. beim „real world“ mapping zwar für Regionen genutzt werden - ist aber vom Zugriffssystem her vollkommen willkürlich - die Marker könnten auch ohne Probleme anderweitig abgetrennte Shards beschreiben.
Ein Dusting Angriff wäre auf jeden Fall erschwert beim Sharding - erstens weil du den Angriff aus dem Zugangsbereich des Shards starten müsstest und nur diesen Shard aufblähen würdest.
Und mit einer redundanten Verknüpfung mit mehreren Shards wird auch das Schneisen schlagen sehr schwer bis unmöglich.
Das stimmt meiner Meinung nach nicht - Zentralisierung ist ein fließendes Konzept - der Coordinator auf der einen Seite und auf der anderen Seite nur freie Nodes. Aber dazwischen eine große Grauzone, die ein Konglomerat aus freien und geschlossenen Nodes darstellt - je mehr desto dezentraler.
Da stimme ich voll zu - bis jetzt ist das alles Zukunftsmusik - aber Lösungskonzepte existieren und das gibt mir die berechtigte Hoffnung, das diese Probleme in der Zukunft gelöst seien werden.
Hey @samreciter,
meine vorherige Antwort basiert natürlich auf beiden Artikeln, die Hans Moog dazu bisher veröffentlicht hat.
Wenn wir die Beschreibung von Hans genau lesen sehen wir, dass es im Dokument eine Evolution gibt und Hans nach und nach sagt, wieso seine vorherigen Gedanken obsolete sind. Das Dokument ist also work in progress mit einem „teil Ergebnis“.
Hans beschreibt, wieso er das world mapping verwendet und wieso gerade keine willkürlichen Shards möglich sind:
Since we want to keep the mechanisms simple and do not want to introduce another consensus mechanism on top of the tangle, we need to find a different approach to deal with this problem.
Willkürliche Shards, wie z.B. ein Shard für eine große Firma benötigen aber zwingend einen zusätzlichen Konsens-Mechanismus der über dem Tangle liegt und die Entscheidung trifft, welche Shards es gibt und welche Nodes welchen Shard verwalten.
Das ist also falsch und geht aus dem Missverständnis von Hans Post hervor.
Es gibt keine Shards, wie in Deiner Vorstellung mit dem Konzept, dass von Hans bisher beschrieben wurde. Zudem gibt es keine solche Zugangsbeschränkung. Ich habe in meinem Post die Möglichkeiten und Folgen einer „vom Node-Betreiber eigenmächtigen“ ausgeführten Zugangsbeschränkung ja bereits beschrieben.
Ich verstehe leider nicht, was Du hier geschrieben hast, wie das funktionieren soll und folglich auch nicht, wie Du zu dem Schluss kommst. Bitte erkläre mir Deinen Gedankengang.
Das war nur auf das automatische Sharding bezogen.
Das sehe ich aus dem, was ich hier lesen und sehen kann, aber nicht:
Sharding ist einfach ein splitting process bei dem ein Teil-Tangle an einem bestimmten Zeitpunkt anfängt nur noch Verknüpfungen mit sich selbst - Transaktionen mit eigenem Marker - zu führen. Der Consensus bleibt der gleiche und geht ganz normal weiter. Der Shard kann auch wieder rückgeführt werden, indem wieder mit Nodes anderer Shards verbunden wird - allerdings mithilfe einer aufwendigeren tip selection - um double spendings zu verhindern.
Wenn ein neuer Shard gebildet wird - automatisch oder von Hand - muss darauf geachtet werden, das Transaktionen von mehreren anderen Shards bei der Validierung/Anhängen neuer Nodes verwendet.
Möglicherweise selten inter-shard Validierungen um die redundante Verknüpfung zu erhalten - welche dann auch mit einer aufwendigeren tip selection stattfinden müssen.
Hey @samreciter.
Du siehst das nicht oder Du willst das nicht sehen?
Das von Hans korrekt erkannte und von Dir ignorierte Problem ist die Auffindbarkeit der Knoten im Tangle für fremde Shards. Eine Node aus einem anderen Shard muss irgendwoher wissen, welche Node sie fragen muss um Informationen über einen bestimmten Knoten zu bekommen. Dafür braucht es einen zusätzlichen Konsensfindungsalgorithmus, der um den Tangle gespannt werden müsste.
Sprich: Es müsste eine zusätzliche Instanz geschaffen werden, die Entscheidet welche Shards existieren, und welcher Shard welchen Marker hat.
Das wäre wie korrekt von Hans erkannt ein Overhead, den es sich lohnt zu vermeiden.
Ich verstehe immer noch nicht, was Du schreibst. Von welcher redundanten Verknüpfung redest Du?
Konsensus ist Wahrheitsgehalt - Knoten bzw. Transaktionen für die Validierung im Tangle finden ist tip selection. Also braucht man in seltenen Fällen einen zusätzlichen langsameren tip selection Algorithmus - für die seltenen inter shard Kommunikationen - aber keinen neuen Konsensus Algorithmus. Welche Nodes/Shards exisiteren - da haben wir mit P2P Konzepten schon alle Lösungen auf der Hand - da braucht es auch keine zusätzliche Instanz dafür.
Welcher andere Node und welche Transaktion dieses Nodes ist prinzipiell egal - könnte aber eben - in der inter shard tip selection - für Konsistenz und gegen Schneisenbildung weiter verfeinert werden.
Die inter shard Kommunikation wird nur dafür benötigt den Tangle über die verschiedenen Shards konsistent zu halten. Das heißt der Overhead durch die langsamere tip selection ist zu vernachlässigen.
Hey @samreciter,
Es gibt hier zwei Möglichkeiten:
- Du möchtest basierend auf dem Inter-Shard-Konzept von Hans Moog argumentieren und diskutieren. Dann ist das, was Du sagst falsch. Warum erklär ich Dir anschließend. Zur Erinnerung: Wir verwenden hier das von Hans bis dato beschriebene Konzept, weil Du das so wolltest.
- Du möchtest auf Basis eines anderen Inter-Shard-Konzepts argumentieren und diskutieren. Dann musst Du dieses vorlegen oder ausreichend erklären. Optimalerweise ist diese Erklärung oder Beschreibung dann auf dem gleichen Niveau wie den Posts von Hans.
Ich lehne die Beschreibung von dem was ich meine an die Begriffe an, die Hans in seinen Dokumenten verwendet um die Verständnisbarriere für Dich nicht unnötig hoch zu machen. Bei Hans sind diese Begriffe also entsprechend ähnlich:
Since we want to keep the mechanisms simple and do not want to introduce another consensus mechanism on top of the tangle, we need to find a different approach to deal with this problem.
An dieser Stelle sei mir die Frage erlaubt, wieso Du glaubst, dass ein Problem oder eine Herausforderung, die von Hans gesehen wird von Dir ignoriert werden kann? Glaubst Du, dass Du die Thematik besser verstehst?
Aber es gibt doch viel mehr, als nur die tip selection. Ich bringe nachher ein paar Beispiele.
Mit Konsensus Algorithmus ist gemeint, dass man einen Konsens finden muss, welche Shards mit welchen Markern und welchen Nodes (wo) existieren. Das hat mit der tip selection überhaupt nichts zu tun. Dort gibt es viele (auch Spieltheoretische) Fragen, z.B.:
- Welchen Marker verwendet ein neuer Shard?
- Wie wird verhindert, dass zwei Shards evtl. den gleichen Marker verwenden?
- Du sagst, dass dies mit der derzeitigen peer to peer Lösung bereits geht: Was passiert, wenn zwei neue Shards in einem Netsplit-Scenario zufällig den gleichen Marker verwenden?
- Und viele weitere Fragen…
Diese Aussage ist einfach falsch. Siehe meine Erklärung oben. Nochmal die Frage: Wieso siehst Du die Problematik nicht, wo sie doch von Hans gesehen wird?
Nein, ist es überhaupt nicht. Wenn ich mein Auto nehme, dass irgendetwas Ortsabhängig von einem Wallet bezahlen soll (vielleicht Maut oder Traffic-Livefeeds oder andere Autos, die ihm Umgebungsdaten über car2car Kommunikation senden um Unfälle zu vermeiden oder was auch immer) weil ich durch das Land oder mehrere Länder fahre, dann muss IOTA meine Wallet mit der Ziel-Wallet in Verbindung bringen können. Dabei handelt es sich dann um Adressen, die in verschiedenen räumlichen oder wenn es nach Dir (das Konzept von Hans verletzend) um dezidierte anders gruppierte Shards geht z.B. einem Maut-Shard bezahlen können.
Der Konsens-Algorithmus, welcher dann über die eigentliche Bezahlung (der Algorithmus, der z.B. Double-Spends abwehrt - das kann nicht der Tip selection-Algorithmus sein) ist z.B. ein Kandidat für viel Inter-Shard-Traffic. Fast alle IOTA Konzepte wie z.B. IOTA Access sind ebenfalls Kandidaten für viel inter-Shard-Kommunikation. (Deswegen möchte der Hans auch verhindern, dass ein übergeordnetes Konstrukt für das Management der Shards entsteht!)
Nein, man!
Das von Dir angehängte Bild entspricht nicht dem Konzept von Hans. Hans verwendet ein fließendes Konzept ohne dezidierte Shards. Deshalb kommt dieses Bild auch am Anfang seines Dokuments, welches den Leser wie gesagt auf eine Reise seiner Schlussfolgerungen mitnimmt. In seinem Dokument beschreibt er also schon, wieso sein Konzept „vom Anfang“ nicht so funktionieren kann.