Archiv Diskussionen

Hier möchte ich eine sehr interessante Diskussion zum Thema Coordicide festhalten.

Die folgende bemerkenswerte Diskussion wurde zwischen dem User ShyGuy und SimonF im deutschsprachigen IOTA-Talk Forum geführt, jeder der über den Artikel oder IOTA im Allgemeinen Diskutieren möchte, ist herzlich eingeladen dem Forum beizutreten, ich schau dort auch jeden Tag mal vorbei.

Um es vorweg zu nehmen, um den Coordicide komplett nachvollziehen zu können, fehlen uns noch einige Informationen. Einige IF Mitglieder haben auch schon durchblicken lassen, dass es noch weitere technische Aspekte gibt, die in Kürze veröffentlicht werden. Und nicht vergessen, die vorgeschlagene Lösung zum Coordicide ist modular aufgebaut und daher sehr flexibel.


Zitat ShyGuy

“Ich denke, dass das Folgende nicht immer in einfache Worte gefasst werden kann, aber ich werde mich bemühen. In Kurz ist unmöglich, also muss ich mich nicht dafür entschuldigen.  
Ihr befürchtet es vermutlich schon – meine Meinung zum Coordicide.  

Die IF hat den Coordicide in ein modulares System gepackt. Die Rolle dieser Module, teilweise schon vorhanden und andere vollkommen neu, wurden neu definiert. Ich werde auf dieses Module eingehen und euch dabei 3 Gedanken nahelegen, die ihr zu jeder Zeit bedenken solltet.


1) Es geht beim Konsensus unter den Nodes um Geldwert Tx, nicht um die Daten. Daten können jedoch sekundär über den Geldwert Konsensus sicher sein.


2) IOTA ist permissionless. Jeder kann ein Set von Nodes auf eigene Art betreiben. So könnte ein Netz von Nodes mit schwacher Hardware auch über eine Art “Master Node” am Konsens teilnehmen und somit nur ein Teilset der Konsensregeln einhalten müssen (z.B. der grundlegende Aufbau einer Tx, aber z.B. nicht ein max TPS Limit). Eine “Bestätigung” der untergeordneten Nodes ist über einen Master prinzipiell möglich.


3) In einer dezentralen DLT müssen die Nodes LOKAL ihre Meinung bilden. Es darf keine Entität geben, welche deine Meinung bildet. Das Ziel ist es also demokratisch zu 1 Meinung zu kommen, indem wir uns als ehrliche Teilnehmer einheitlichen Regeln unterwerfen. Was die IF vorgeschlagen hat, müssen wir nicht anwenden, aber nur alle Teilnehmer 1 Regelwerks, werden auch an diesem einem Tangle teilnehmen. Abweichung führt zu einer Abspaltung (“die sagen der Token ist dort und die anderen da -> mein Tangle ist dort”).


Es geht los…5 Module!    


Das Modul “Node”

Nodes bekommen eine ID. Mit der ID kann sich der Node “ausweisen”. In Zukunft haben Nodes nicht alle das gleiche Gewicht. Das Gewicht der Node basiert auf ihrer Reputation im Netzwerk. Reputation hängt vom Alter der Node ab, ihrem Verhalten und der Menge an Token, welche darüber “fließen”. Auch oftmals als Mana bezeichnet, aber ich bevorzuge Reputation. Da jeder Node eine ID besitzt, kann jeder Tokentransfer einem Node zugeordnet werden – der Erste, der die Tx erhält. Mana ist also eine “gespiegelte Ressource” aus dem Token. Wer mehr Token besitzt, hat auch mehr Einfluss auf die Reputation, aber das ist ja nicht der einzige Faktor dafür. Es ist eine abgewandelte Form von Proof of Stake, da Mana keinen Geldwert selbst besitzt, ist die Ressource kein “klauenswertes” Ziel. Jeder mit Token bestimmt “den Node seines Vertrauens” und verschafft ihm Mana. Ihr könntet ein Forumsmitglied dafür wählen. Ein Unternehmen (und deren Services) wird wohl eigene verwenden. Da auch Reputation lokal für andere Nodes entschieden wird, muss jeder Node eine eigene Datenbank über die Konsensteilnehmer Nodes führen! Der positive Nebeneffekt: da nun die Herkunft einer Tx markiert wurde (“erste NodeID”) kann diese auch einen Zeitstempel anbringen. Zuverlässige Zeitstempel sind sehr vorteilhaft, aber jetzt nicht Gegenstand der Thematik.
Fehlverhalten wirft den Node aus dem Konsensus, aber nicht zwangsläufig aus dem Tangle! Kommt auf die verletzten Regeln an.
prinzipiell könnte also eine höhere Skalierung direkt erreicht werden, indem Nodes “spezialisiert” werden. Reine Daten Nodes müssten nicht am Konsensus teilnehmen und könnten auch Cluster bilden, während eine übergeordnete Master Node “Bestätigungen” ähnlich der Meilensteine erschafft, indem dieses Cluster indirekt von einer dem Konsensus unterworfenen, “gewichtigen” Tx der Master Node referenziert wird. Je wertvoller der Token wird und je verteilter er vorliegt, desto mehr Sicherheit bietet das “Mana System”, da Reputation eine Größe im Konsensus ist. Der Konsensmechanismus verlangt jedoch immer eine größere Anzahl von Nodes. Auch bei schlechter Verteilung des Tokens. Der Wert des Tokens ist eine absolut entscheidende Größe für die Sicherheit!


Das Modul “Auto Peering”

Die Nachbarsuche wird automatisiert. Wer am Konsensus teilnehmen möchte, muss sich einem “Regelwerk Nachbarsuche” unterwerfen. Dabei spielt Reputation eine Rolle. Nodes mit ähnlicher Reputation werden sich verstärkt vernetzen. Dabei wird ein Teil aktiv ausgesucht und der andere Teil durch Anfragen abgedeckt. Ausgesucht wird anhand der lokalen Node Liste. Bei Anfragen wird die Reputation überprüft, Node Liste aktualisiert und wenn die Anfrage passend war auch akzeptiert. Das ist für beide Konsensusmodelle (dazu später) wichtig. Einfach formuliert “da wo die Kohle sitzt, bildet sich der vertrauenswürdigste Kern des Tangles”. Die haben am meisten zu verlieren. Aber auch weil diese Nodes lange ehrlich waren. Ehrlichkeit, Geldwert, Alter der Node ist Reputation. Reputation schafft ehrliche Nachbarn. Neue Nodes müssen also erst ansehen gewinnen. Ein wichtiger Baustein gegen Sybil-Attacken (viele Angreifer Nodes wollen den Konsensus verzögern, verhindern oder fälschen) und Eclipse-Attacken (ehrliche Nodes aus dem Konsensus separieren). Neue Nodes benötigen also “Einstieg Nodes” um am Konsensus teilzunehmen. Diesen Einstieg kann prinzipiell jeder Konsensusteilnehmer bieten, muss er aber nicht. Permissionless kann so schön sein.^^
Nebenbei soll das Auto Peering auch ein “small world Netzwerk” anstreben, also mit möglichst wenig Sprüngen jeder Teilnehmer erreicht wird. Ist für einen effizienten Konsensus wichtig, aber die Sicherheit durch Reputation muss Vorrang behalten.


Das Modul “Spam Schutz”

Der Konsensus sollte nicht durch Spam behindert werden. Auch leistungsschwächeren Nodes sollten am Konsensus teilnehmen können. Spam Schutz wird weiterhin auf PoW beruhen, aber der nötige PoW ist abhängig von der Reputation einer Node und den Transaktionen/Zeit (=TPS). Hohe Reputation senkt den PoW. Viele TPS erhöhen den PoW. Zusätzlich wird für “Konsensus Nodes” eine maximale TPS Zahl eingeführt. Sollte ein Service also viele TPS erfordern, dann wären vermutlich schnell mindestens 2 Nodes nötig. Eine könnte z.B. die max TPS ignorieren, aber nicht am Konsensus teilnehmen, die andere hält sich an wirklich alle Regeln, beinhaltet der Reputation wegen die meiste Kohle und nimmt am Konsensus teil.
Der Spam Schutz beschützt den Konsensus, aber er wird nicht durch leistungsfähige Hardware (z.B. durch ASIC Mining Fabriken wie beim BTC üblich) bestimmt! Reputation statt Hashpower ist wichtig, aber der Konsensus wird durch alle Module beeinflusst.


Das Modul “Tip selection Algorithmus”

Manchmal abgekürzt als “TSA” oder “gTTA” (get transactions to approve”) bezeichnet, wurde dieses Modul im neuen Konsensus deutlich abgespeckt. Das kumulierte Gewicht ist ein ressourcenreiches Unterfangen als Konsensus Modell – so schildert es die IF heute. Wohlgemerkt der bisher angestrebte Konsensus, wenn der Tangle eines Tages ausreichend genutzt werden würde. Die gTTA Funktion wurde zuletzt auch stark aus der Community kritisiert. Ein echter Engpass im Protokoll für nicht so leistungsstarke Nodes. Der Abschnitt im Whitepaper enthält nur wenig Informationen zum zukünftigen TSA, aber alles deutet auf weniger Restriktionen hin. Damit könnten mehr “zurückgebliebene Tx” abgeholt werden (=weniger Reattachments/Promotes), gerade wenn diese von Nodes mit hoher Reputation kommen. Konflikt Tx (z.B. 2 Werttransaktionen mit denselben Token auf unterschiedliche Zieladressen) werden erst einer Abstimmung unterworfen (und damit auch final bestätigt plus alle davor referenzierten). Für den TSA könnten solche, durch den Konsensus in der Abstimmung, generierten, finalen Transaktionen wie ein Meilenstein anerkannt werden. Ein dezentral erstellter Meilenstein wohlgemerkt.
Damit hat der “Konsensus Tangle” auch eine Wachstums Richtung.


Das letzte Modul “Abstimmungsschicht” (Konsensus)

Alle vorherigen Module werden hier vereint und nun gilt es eine einheitliche Linie in Konflikten zu finden – der Konsensus. Das Gesamtpaket wurde Shimmer benannt (übersetzt etwa “flackern”). Angestrebt wird ein Konsensus durch das Beobachten von anderen Nodes. Die Idee wurde abgeleitet vom Verhalten eines Honigbienenschwarms zur Abwehr von Wespen. Durch vordefinierte Verhaltensregeln ermitteln sich die Konsensus Nodes. Fehlverhalten sorgt für Ausschluss. Reputation sorgt für Gewicht. Auto Peering für “einen stabilen Kern” ehrlicher Teilnehmer. Spam Schutz für ausreichend Demokratie bei der Auswahl der Nodes. Die endgültige Meinung dieses Moduls ist tatsächlich (erstmal) als final zu betrachten. Eine positiv abgestimmte Tx bestätigt wie ein Meilenstein sich und alles davor. Eine negative Tx wird in diesem Tangle nie bestätigt und alles danach verwaist (wichtig für TSA). Der Konsensus soll organisch im ganzen Netzwerk verbreitet werden.


Es wurden 2 Vorschläge gemacht, welche parallel getestet werden sollen.

a) Zellulärer Konsensus
“die Meinung der Mehrheit zählt”
Hierbei handelt es sich um einen asynchronen Ansatz. Jede Konsensus Node setzt von Zeit zu Zeit einen Herzschlag bei den Nachbarn ab, welcher rundenbasiert abläuft. Dabei wird sehr wahrscheinlich ein Set von Tx inkl. der eigenen Meinung und der Meinung der Nachbar Nodes übermittelt. Um die Datenmenge geringer zu halten, wird nur die Differenz der Meinungen der Nachbarn aus der Vorrunde übermittelt. Ehrliche Nodes werden die Meinung der Mehrheit übernehmen, solange das keinen Konflikt mit dem eigenen Bild des Tangles bedeutet. Gegensätzliche Nodes werden verworfen. Nach ein paar Runden sollte eine von beiden Meinungen vorherrschen (Set an Tx valide oder invalide). Bleibt die Meinung ausreichend Runden gleich, akzeptiert der Node diese Meinung als final. Wer sich dieser Meinung verschließt, ist nicht mehr synchron. Dieser Ansatz ist leider, wegen der mathematischen Komplexität, nur schwer durch wissenschaftliche Beweise zu untermauern, aber kommt dem Bienschwarm sehr nahe. Das Auto Peering und der Wert des Tokens bzw. das Mana spielen eine entscheidende Rolle für die Sicherheit!

b) der schnelle, probalistische Konsensus
Dieses Modell arbeitet nach festen Intervallen, also regelmäßige Abstimmungen (nicht asynchron). Hierfür gibt es jedoch schon mathematische Beweise.
Aus der lokalen Node Liste wird eine Anzahl Referenz Nodes ausgewählt (z.B. 50). Dabei kann jederzeit auch eine ordentliche Anzahl an Nodes mit höherer Reputation gewählt werden. Diese Nodes stimmen über die Tx (vor allem wenn ein Konflikt existiert) wieder in Runden ab. Die Wertung kann positiv, negativ und neutral sein. Eine Node darf ihre Meinung von positiv oder negativ nicht verändern, sonst droht der Ausschluss. Nach einer fixen Anzahl Runden ermitteln die Nodes die positive Resonanz der anderen Nodes zur Tx. Ist ein bestimmter Schwellenwert überstiegen, dann ist die Tx “wahrscheinlich” valide. Ist sie es nun oder nicht? Als Schutz vor Angreifern wird der Schwellenwert der zu erreichenden positiven Resonanz in jeder Abstimmung neu definiert. Er muss nicht immer >50% oder gar Werte von 90%+ entsprechen. Das ist wichtig, damit Angreifer den Konsensus zwar verzögern, aber niemals stoppen können. Eine lokale Node kann diese Tx als “wahrscheinlich valide” betrachten, aber z.B. bei der Tip Auswahl noch mehrheitlich auf sicherere Kandidaten zurückgreifen. Mit jeder weiteren Abstimmung wird die Tx sicherer und kann später als final betrachtet werden. Der Schwellenwert könnte dezentral über Nodes mit hoher Reputation bestimmt werden. Wichtig ist, dass der ehrliche Kern alle die gleichen Regeln verwendet! Bei diesem Ansatz ist Auto Peering nicht der wichtigste Faktor für die Sicherheit, aber gerade beim ermitteln des Schwellenwertes ist Reputation wichtig. Und erneut ist der Wert des Tokens bzw. das Mana eine enorme Größe in Bezug auf Sicherheit!


Mein persönliches Fazit (DYOR!):

Shimmer ist ein schöner Ansatz für den Coordicide, aber ist es der Durchbruch?
Leider nicht direkt. Während vieles im Whitepaper des Coordicide in sich schlüssig ist und die IF gezeigt hat, wie sie sowohl bestehende als auch revolutionäre, neue Ansätze beeindruckend kombinieren kann, benötigt das Vorgestellte weitere Parameter, um ausreichend Sicherheit zu gewährleisten. Das veränderte Protokoll könnte deutlich leistungsstärker agieren, bietet viel Platz für eigene DLT Strukturen und wird das in Testumgebungen hoffentlich auch beweisen. Für den Einsatz im Mainnet benötigt es jedoch mindestens eine wichtige Größe und besser noch eine Kleinigkeit mehr…der Token muss wertvoller werden (Reputation muss teuer sein) und am besten auch “in den richtigen Händen” (erfahrene Anwender die nicht den falschen Nodes Reputation zuweisen). Es ist kein PoS und kein delegated PoS wie manche Kritiker behaupten. Shimmer ist komplex. Die Module sehr durchdacht. Dennoch gibt erst teure Reputation in den richtigen Händen Sicherheit.
Ist es nun ein Henne/Ei Problem? Nun, die meisten hier glauben, dass große Unternehmen den Tangle nutzen werden. Kommt der Token auch zum Einsatz, dann wird Reputation teuer und ist in den richtigen Händen (verdienen ja Geld damit, also kein Interesse an der “Tangle Zerstörung”). Kommen diese Unternehmen auch bevor der Token wertvoll ist? Das ist möglich. Daten Tx sind ja konfliktfrei und damit direkt nutzbar. Kommt mit der Zeit das Geld ins Spiel, dann steigt auch nach und nach die Sicherheit. Bis dahin wäre ohne Coo die Verantwortung bei den tollen Besitzern und der Community in Anbetracht der Zahl der Nodes. Lasst uns auf viele, erfolgreiche NDAs, die auch zur Umsetzung führen, hoffen.  

Hoffe es war halbwegs verständlich.” 


Zitat SimonF

“Hey ShyGuy Respekt das du dir die Mühe machst und das alles so verständlich ausformuliert hast! Allerdings glaube ich nicht, dass der Token teurer werden muss, um die Sicherheit des Systems zu gewährleisten. Der Denkfehler liegt darin, dass Mana nicht mit Reputation gleichzusetzten ist. Mana ist eine Teilmenge der Reputation, durch Mana kann Reputation aus der realen Welt in dem System abgebildet werden. Was aber viele vergessen, ist das Mana eben nur ein Teil der Reputation darstellet, weitere wichtige Bestandteile sind z.B die Dauer, in der ein Node am Netzwerk teilnimmt, und insbesondere das Verhalten während den Abstimmungen. Entscheidend ist dabei, dass Reputation sehr schwierig zu bekommen ist (durch langfristige, ehrliche Teilnahme am Netzwerk) aber sehr schnell verloren gehen kann. Versucht man einmal zu betrügen, so verliert man sofort seine gesamte Reputation! So könnte man selbst in dem unwahrscheinlichen Fall, dass ein Node über 90% des Mana verfügt, das System nicht betrügen. 

Zwei Aspekte des neuen Konsensus-Verfahrens machen es in meinen Augen besonders. Zum einen die Abkehr von der „Longst-Chain-Wins“ Regel. Grundsätzlich funktioniert zum Beispiel Bitcoin ähnlich wie IOTA, möchte man eine neue Transaktion durchführen, so prüfen zunächst alle Nodes, ob diese Transaktion valide ist. Der Unterschied liegt nun aber darin, wie eine Transaktion in den Ledger aufgenommen werden kann. Beim Bitcoin fügen die Miner die Transaktionen in Form von Blöcken an den Ledger, und zwar immer an die Kette mit dem meisten POW (längste Kette). Das große Problem dabei ist, dass man hier „Geschichte umschreiben“ kann, indem man Blöcke zurückhält und dann eine neue längste Kette erstellt. Bei IOTA darf jeder Node eine Transaktion hinzufügen, wenn er zuvor zwei andere Transaktionen bestätigt hat. Kommt es zu einem Konflikt, so wählen die Nodes, welche der Transaktionen behalten wird. Man entscheidet sich also für eine der beiden Transaktionen oder beide werden ignoriert. Dies bedeutet, dass hierbei kein Double Spend mehr möglich ist, da man die Geschichte nicht umschreiben kann. 
Der zweite, mindestens genau so wichtige Aspekt an Shimmer ist es also, dass sich damit (unabhängig von der Anzahl der Nodes) alle Nodes innerhalb von wenigen Sekunden
gemeinsam auf ein Update des Ledgers einigen können. Es ist dabei weniger wichtig, für welche der beiden konfliktären Transaktionen sie sich entscheiden, vielmehr ist es wichtig, dass sie sich so schnell und final! auf eine Trankaktion einigen.”


Zitat ShyGuy

“In dem Abschnitt “das Modul Node” steht doch bei mir auch, dass Reputation durch das Alter, dem Verhalten und dem “Tokenfluss” (Mana) über den Node entsteht?! Nun, da sind wir uns ja einig, also nicht weiter relevant.

“Geschichte umschreiben” beim BTC ist ein teures Unterfangen. Es erfordert sehr viel Hashpower Blöcke zu generieren, aber sie sind einfach zu verteilen, da geringe Größe. Die Wahrscheinlichkeit, dass jemand überhaupt eine längere Kette parallel aufbaut, wird mit steigenden Kosten/Aufwand je Block geringer. Das ist wichtig, schließlich sollten Transaktionen nicht rückgängig gemacht werden (“Ware des Händlers bleibt bezahlt”). Eine “gesunde” Blockchain. Die Hashpower ist also wichtig, da parallele Ketten sowieso kein wünschenswerter Zustand sind.

Bei IOTA gibt es keine “longest Chain wins Regel”, korrekt. Aber ein einheitliches Ledger, wohlgemerkt auf jeder Node lokal, ist das erstrebenswerte Ziel. Die Problematik ist, dass einerseits im TSA am besten Tips, also Transaktionen ohne bisherige Referenzierung, genutzt werden sollten, aber diese Tips lokal nur schwer als verlässlich eingestuft werden können, da nicht jeder Node zu jedem Zeitpunkt alle Transaktionen kennt. Reicht es nun eine Transaktion als verlässlich einzustufen, nur weil der ausgebende Node schon länger kein Fehlverhalten zeigt? Wie definieren wir denn Fehlverhalten? Das Verteilen von in Konflikt stehenden Tx ist kein Fehlverhalten, wenn diese von unterschiedlichen Nodes verteilt werden, da jede für sich keinen Fehler erkennen konnte, wenn nicht beide vorhanden waren und sonst valide. Irgendwann schlagen bei einer Node beide auf. Nun wird der Konflikt gemeldet und proaktiv gelöst. Dazu meldet das Netzwerk an Konsensus Nodes, welche stärker zu gewichten ist und einigt sich (ja, final!). Es ist also durchaus möglich, dass “böswillige Nodes” lange Bestand haben ohne ihre Reputation, aufgebaut durchs Alter, zu verlieren, da diese sich nicht falsch verhalten müssen, aber der konträre Spieler kann diese Nodes nutzen, um mit seinen Transaktionen “Unruhe” ins System zu bringen. Sollten weitere Tx auf einer “nicht bestätigen” Tx aufbauen, dann müssen diese auch (im Netzwerk) weiterbehandelt werden, sonst verwaist der ganze Ast. Ein so wenig gewünschter Zustand wie parallele Ketten bei der BTC Blockchain. Es wäre also gut für den TSA, wenn Transaktionen direkt als sehr zuverlässig eingestuft werden können, damit ein stabiles Konstrukt um diese gebaut werden kann. Ein besserer Ausdruck als “Sicherheit des Netzwerks” ist also eher “Sicherheit der Performance” des Netzwerks. Diese Performance Sicherheit steigt mit zunehmendem Wert des Tokens und der Verteilung in “gute Hände”, da diesen Transaktionen ausreichend Vertrauen zugrunde gelegt werden kann und der TSA hier vernünftige Konstrukte aufbauen kann. Wenn Verhalten und Alter hier nicht die entscheidende Größe spielen, dann muss es das Mana sein. Jedes gute Geschäftsmodell auf den Tangle, erhöht also direkt die “Zuverlässigkeit” des Tangles, da solche Modelle das Mana in die richtigen Hände spielt. Wenn es dann noch viel Geld kostet Mana (also Token “zum Opfern”) einfach einzukaufen, dann erhöht sich die Zuverlässigkeit weiter. Leider wurde die Abhängigkeit der Reputation von Alter, Verhalten und Mana nicht näher erläutert, aber ich persönlich glaube, dass Mana die absolute Größe ist, Alter ein prozentual steigender Faktor (0-100% aufs Mana) und Verhalten lediglich noch ein negierender Faktor (darf/darf nicht abstimmen) wird. Ist jetzt reine Spekulation natürlich.

Wirklich schön, dass ich mit dir darüber diskutieren kann und meine Ausführung sogar weiter konkretisieren musste.”


Zitat SimonF

“Hey ShyGuy du hast natürlich Recht, solange man noch keine konkreten Details zur Implementierung der Reputation kennt, ist das alles nur Spekulation. Spannend daher, deine Einschätzung dazu zu lesen. Ich halte Mana persönlich nicht für den entscheidenden Faktor, selbst wenn jemand 100% der Mana besitzen würde, könnte er nicht betrügen, höchstens evtl den Konsensus verzögern. 
Bezüglich der „Sicherheit der Performance“ mach ich mir weniger Gedanken, in ca zwei Wochen soll es ja ein Testnet geben, dann werden wir das sehen. Ich habe bisher leider noch keine detaillierten Informationen dazu gefunden, wie man in der TSA sicherstellen kann, dass man sich im „Richtigen Teil des Tangle“ befindet, und nicht eine konfliktäre Transaktion bestätigt und sich damit in dem Teil des Tangles zu befinden, der später verworfen wird. Allerdings tritt dieses Problem natürlich nur im Falle eines Double Spend Versuchs auf, was nicht so häufig vorkommen sollte. Zum anderen
könnte ich mir vorstellen, dass Local Modifier eine wichtige Rolle spielen. Da konfliktäre Transaktionen während eines Double Spend Versuchs immer zeitlich verzögert auftreten, und da mit einer großen Wahrscheinlichkeit die erste Transaktion auch behalten wird und die andere verworfen, würde es Sinn machen,sich an die Erste zu halten. Aber natürlich alles nur Spekulation, ich bin wie gesagt sehr gespannt auf das Testnet.”


Zitat ShyGuy

“Ich freue mich gerade, dass ich so eine Diskussion führen kann.  

Testnet wird spannend. Nur den Start in etwa 2 Wochen erwarte ich nicht. Die IF hat ja schon öfter euphorisch Zeitpunkte angekündigt, die dann zu optimistisch waren. Futter für die Trolle, aber ich persönlich habe kein Problem damit. Die IF ist engagiert, das ist mir wichtig.  

Der TSA referenziert ja immer 2 alte Tx. Ich kann mir vorstellen, dass immer 1 ordentlich vertrauenswürdige Tx dabei sein sollte, damit verwaiste Äste (weitestgehend) der Vergangenheit angehören. Also faktisch ein “ordentlich vernetzter, vertrauenswürdiger Kern” und seitlich werden die eher “unbekannten Tx” abgeholt. Wobei mir schon klar ist, dass Tx von Usern kommen und nur valide/invalide sein können, aber von einem vertrauenswürdigen Node, zumindest in ein “vernünftiges Konstrukt” gepackt werden, da der Node für Trunk und Branch verantwortlich ist.
In der IF sitzen klügere Köpfe als ich, die werden auch schon über sinnvolle TSA Modelle philosophiert haben.  

Ach, und falls jemand noch nicht das Video über das Verhalten von Honigbienen zur Wespenabwehr gesehen hat, welches zu Shimmer inspiriert hat, der klickt bitte hier. Der organisch wachsende Konsensus, durch Beobachten der Nachbarn. Sehr beeindruckend.”

Quellen

https://www.iota-talk.com