es wäre dann aber doch interessant zu wissen wie bei dem dargelegten System von IOTA genau diese Sybil Attack aussehen soll, d.h. wie genau müsste ein Angreifer vorgehen? Im Whitepaper ist schließlich ein kompletter Absatz zur Sybil Protection
Ich hatte mir zwar eigentlich vorgenommen, das nicht zu tun, aber wenn's denn sein muss, zerlegen wir das Whitepaper eben Wort für Wort.
3.2 Sybil protection
One very common way to make such a Sybil attack harder is the so-called resource testing, where each identity has to prove the ownership of certain difficult-to-obtain resources. Since in the cryptocurrency world users own a certain amount of tokens, we propose a Sybil protection mechanism based on the ownership of such tokens.
Bis hierhin ist das nichts neues, das ist der Ansatz, der schon Proof of Stake zugrunde liegt.
Witzigerweise nutzt man das dann aber (weiter unten) gar nicht.
Obfuscation Strike 1.
However, instead of requiring the identity to proof the ownership itself, we allow each user of the network issuing transactions to assign tokens to any node of his choosing. We call these tokens mana;
Man benutzt also seinen "Stake", um anderen Usern "Reputation" zu geben, hier "mana" genannt.
Hier von "Tokens" namens "Mana" zu sprechen, wo in der Literatur der Begriff "Reputation" gängig sein dürfte, werte ich als:
Obfuscation Strike 2.
they serve as a hard to obtain resource as well as some form of “reputation” which can be assigned to trustworthy nodes.
Hier wird es ein wenig "unübersichtlich", man muss schon sehr genau lesen, um zu merken, dass hier das "Mana" die "hard to obtain resource" sein soll, die auf der Grundlage der "hard to obtain resource" "ownership" (von MIOTA?) "obtained" wird.
Warum das nun "hard to obtain" sein soll, erschließt sich nicht, und wird auch nicht erklärt.
Ich sag mal:
Obfuscation Strike 3.
An dieser Stelle könnte der Baseball-affine Leser schon sagen "three strikes - you're out", und weiterziehen.
Ich kämpfe mich trotzdem weiter durch den Dschungel, verzichte fortan aber auf die Strikes
The fundamentals of the actual mechanism are described below:
• When a transaction is issued, it generates a double flow: It (i) transfers data or tokens from one address to another, and (ii) adds virtual tokens (called mana) to some nodes. The amount of mana corresponds to the tokens transferred.
Mana wird also bei jeder Transaktion erzeugt, in einer Menge, die vom Transaktionsvolumen abhängt.
Da Transaktionen aber in Iota nichts kosten sollen, ist Mana also keine "hard to obtain resource", sondern lässt sich durch Transaktionen aus dem Nichts schöpfen.
• The node ID that should receive the mana must be specified in the signed part of the transaction. The node gets credited with the mana after a certain time. This is necessary to prevent nodes from generating a new ID for every message they issue.
Hier werden nun Node IDs eingeführt, die weiter unten als "reale Personen" im Web of Trust im Gegensatz zu den "Sybils" Verwendung finden sollen.
Nochmal zur Verdeutlichung: jede Sybil kann ebenso Mana erhalten und erzeugen, und sich damit eine Identität verschaffen.
Dies kostet lediglich eine Transaktion.
• As soon as the actual tokens are transferred again, the corresponding mana is deducted from the previously referenced node, and can potentially be reassigned to a new node.
Jetzt hat man gemerkt, dass endlose Erzeugung von Mana keine gute Idee wäre, also "nimmt man den Nodes das Mana wieder weg", wenn
sie eine Transaktion senden die "korrespondierenden" Coins wieder geschickt werden.
Inwiefern jetzt also das Mana überhaupt eine andere Bedeutung haben soll, als die MIOTA-Tokens selbst, wird nicht erklärt, das ist obfuscation.
Deutlich wäre das geworden, wenn man darauf hingewiesen hätte, dass das Mana an eine andere Stelle gesendet werden kann als die MIOTA-Tokens.
Ja, man kann das lesen, wenn man sich bemüht, aber es ist sehr sehr anstrengend (für einen alten Mann wie mich).
Dennoch bleibt das Problem, dass Mana hier im Endergebnis eine 1:1 Korrelation zu MIOTA aufweist, und damit nichts anderes ist als ein "delegated Stake".
We stress here that this process does not influence the actual balances in any way, but it is only used to give higher weight to “trusted” nodes.
Jetzt wird also "betont", dass das dem Zweck dienen soll, "vertrauenswürdigen" Nodes mehr Gewicht zu verleihen.
Das ist in gewisser Weise wahr, allerdings muss man hier das Wort "vertrauenswürdig" tatsächlich durch "reich", oder genauer: "mit reichen Freunden" ersetzen
The amount of mana people can delegate is determined by how many tokens they own,
Hat jemand DPOS gesagt?
which means that people who own more tokens will have a larger influence in this process.
Das ist die korrekte Schlussfolgerung.
In particular, nodes could accumulate large amounts of mana without having much stake in the network of their own.
Das ist wiederum zutreffend.
In a traditional proof-of-ownership Sybil protection mechanism, each node has to prove that it owns a certain amount of collateral.
Die Wortwahl "Sybil protection mechanism" ist hier unzutreffend gewählt, da proof-of-ownership im konkreten Fall "Mana" keine Sybil-protection bietet, sondern lediglich (schwache) Sybil mitigation. Das wird allerdings erst weiter unten deutlich.
Conversely, delegating mana brings several key advantages: As mana is credited as part of regular transactions, nodes do not have to constantly use their account’s private keys to sign, which would pose a severe security risk;
Das ist zutreffend, allerdings auch irrelevant, schließlich gibt es auch keinen Sicherheitsgewinn
furthermore, this approach does not need incentives for node operators to own or declare a high amount of tokens;
Das ist zutreffend.
Zutreffend ist allerdings, dass Node-Operatoren einen Anreiz haben können, Mana zu "verdienen", um sich einen größeren Stake zu verschaffen.
Das Problem hierbei ist, dass ein "ehrlicher" Node keinen solchen Anreiz haben kann, schließlich verdient er dabei nichts, "unehrliche" Nodes zu Angriffszwecken aber einen hohen Anreiz.
Spieltheoretisch führt das zwangsläufig zu einem Überhang an "unehrlichen" Nodes.
finally, users can issue additional mana to nodes providing good service to the community.
Es gibt allerdings keinen Anreiz für User, "gute Nodes" besonders zu belohnen, während es für den Angreifer einen "unendlichen" Anreiz gibt, seine eigenen Sybil-Nodes zu belohnen, bzw. dafür zu werben.
Since we have now established reliable node identities, we can use these identities to discover and connect to other nodes in the network.
Da wir eben gerade
keine reliable node identities erzeugt haben, ist der Rest des Papers geistige Masturbation.
Kurz gesagt: der geschilderte Mechanismus belohnt einen Angreifer, bietet aber keinerlei Anreize für Betreiber von ehrlichen Nodes.
Ein Angreifer hat in einem ansonsten als web of trust ausgelegten Kontext ein Interesse daran, lieber zahlreiche kleine "geringfügig" vertrauenswürdige Nodes zu schaffen, als wenige große.
Damit sind die Voraussetzungen geschaffen, dass quasi zwangsläufig "Fake-Node-Farmen" entstehen werden (vermutlich als lediglich virtuelle Nodes ohne eigene Hardware), mit dem bloßen Zweck, zahlreiche Einfallstore für spätere Angriffe zu bauen.
Ich würde sagen, das Whitepaper selbst stellt einen Angriff auf das IOTA-Netzwerk dar
Das bemerkte der Autor wohl selbst, weshalb er dann an anderer Stelle im Paper "neighbours" einführt, was ihn aber auch nicht weiter bringt, und er schließlich über "entry nodes" bootstrapped, also eine zentral verwaltete Liste (nennen wir sie einfach mal "Coordinator"?)