Coins für den Bullrun 2024/2025

[skunk]

vor 7 Minuten schrieb mahatma:

Für das Laufenlassen einer Cassandra Node im Rahmen des Cassandra Testnetzes und für den geplanten Throughput-Weltrekordversuch empfiehlt Radix 5Mbit upstream:

Im Testnet ist das auch kein Problem. Lass den Spaß aber mal einige Jahre im Mainnet laufen dann steigt die notwendige Bandbreite mit der Zeit recht schnell an.

Auch lustig wird es wenn Personen wie ich eine Node betreiben dürfen. Was passiert wenn ein Shard auf nur 3 Nodes gespeichert ist und diese 3 Nodes den Upload verweigern? Was ist wenn die 3 Nodes eine ungültige Transaktion für gültig erklären? Wer prüft das nach? Und wie soll das überhaupt überprüft werden? Die Parallelisierung sorgt dafür, dass ein 51% Angriff auf einen Shard mit erstaunlich wenig Resourcen möglich wird.

vor 24 Minuten schrieb mahatma:

Hast du ne Quelle dafür? Auf wie weit wird dieser Zeitraum deiner Ansicht nach bei Radix verkürzt?

Ich habe im Discord danach gesucht. Hintergrund meiner Suche war die Frage ob Radix die Historie speichert und dann zwangsläufig auch einiges mehr an Bandbreite aufwendet oder ob so ein Shard nicht vielleicht ausschließlich den aktuellen Kontostand enthält so wie eine Ethereum Node mit agressivem Pruning. Ich habe das hier gefunden:
 

Zitat

Thanks for your reply, I am researching Radix node for a personal use case. Could you please help me another question: if I write a Scrypto component and have a method that receive a parameter of a tranaction_id (type string), in the scrypto could I query if the transaction is succeeded or failed, and query its epoch and state version of that transaction?


You cannot. This information isn't available on ledger.

Technically if someone knows the epoch and intent, the ledger does store the transaction result for a short while in the transaction tracker (at least until the transaction intent expires) but we don't expose any methods to read this information, because it's really an internal detail of the engine, and how long it's stored for is an implementation detail.

If there's a solid use case, it might be something we can think about, but there are also other angles to get this information trustlessly (e.g. using the transaction tree / root hash; and some oracle on recent root hashes or something)

Thanks, do you mean that within the scrypto component we can get transaction details by "using the transaction tree / root hash" ? Could you please explain more on this and if there is any example on implementing this? Thanks in advance.


It's not something that can be done right now, it would require some oracle of the transaction root hash, and it would require a client to pass a proof of the commit of a certain transaction. (Basically a merkle proof against our transaction tree). We don't have good docs on it at the moment I'm afraid. 

 

[mahatma]

 

vor 59 Minuten schrieb skunk:

Im Testnet ist das auch kein Problem. Lass den Spaß aber mal einige Jahre im Mainnet laufen dann steigt die notwendige Bandbreite mit der Zeit recht schnell an.

Ich denke nicht. Dein Bandbreitenbedarf hängt von der Anzahl der von deiner Node (mit-)bearbeiteten Transaktionen ab. Jedem Validator wird ein Stück des Shard-Spaces zugeteilt, welches seinen Kapazitäten entspricht. Daran ändern auch viele Jahre im Mainnet nichts. Je mehr Validatoren mit ins Netz gehen, umso kleiner wird der Anteil am gesamten Shardspace; die absolute Anzahl an substates, für die man als Validator verantwortlich ist, bliebe in diesem Fall auch über viele Jahre in etwa gleich, wenn man davon ausgeht das die Anzahl an Nodes mit dem Bedarf mit ansteigt.

 

vor 59 Minuten schrieb skunk:

Auch lustig wird es wenn Personen wie ich eine Node betreiben dürfen. Was passiert wenn ein Shard auf nur 3 Nodes gespeichert ist und diese 3 Nodes den Upload verweigern? Was ist wenn die 3 Nodes eine ungültige Transaktion für gültig erklären? Wer prüft das nach? Und wie soll das überhaupt überprüft werden? Die Parallelisierung sorgt dafür, dass ein 51% Angriff auf einen Shard mit erstaunlich wenig Resourcen möglich wird.

Eine Validatorengruppe hat zwischen zwischen 100 und 3000 Validatoren. Übersteigt die Last der einzelnen Nodes eine gewisse Schwelle, wird die Anzahl der shardgruppen erhöht und die Anzahl der Validatoren pro Shardgruppe verringert, allerdings soll sie nie kleiner als 100 sein.

Die Anpassung passiert dynamisch im Rahmen der "Epochen", nach denen die Validatoren neu über den Shardspace geshuffelt verteilt werden.

Um eine shardgruppe zu übernehmen, braucht es sowohl die Mehrheit an Computingpower (die probabilistische erste Phase des Konsenus), als auch mehr als zwei drittel Stake. Mit mehr als einem drittel Stake wird finalisierung blockiert, aber es können keine falschen Transaktionen abgesegnet werden. Da die allermeisten Transaktionen cross-shard sein werden, reicht es für versenden "falscher" Transaktionen auch nicht, nur eine Shardgruppe zu übernehmen. Da die Validatorengruppen ständig durchgeshuffelt werden und in gleiche Gruppen nur Validatoren mit ähnlichem Stake kommen, können mehr als 33% "böse Nodes" pro Gruppe eigentlich nur passieren wenn mehr als 33% des gesamten Netzwerkes bösartig ist.

Und dies ist Vorraussetzung für die Sicherheit des Netzwerkes, so wie jedes Konzept Bedingungen für die garantierte Sicherheit hat. Es benötigt 2f+1 ehrliche Nodes, wenn f die Anzahl der "böswilligen" Nodes ist, wobei die f böswilligen Nodes auch nur maximal ein Drittel des Stakes auf sich vereinigt haben dürfen damit das Netzwerk läuft. Ab 1/3 böswilliger Nodes/Stake gibts liveness-issues, ab 2/3 böswilliger Nodes/Stake im gesamten Netz gehen ungültige Transaktionen durch.

Auf der oben verlinkten Seite vom Cassandra Netz wird das genauer und tiefergehend erklärt.

vor 59 Minuten schrieb skunk:

Ich habe im Discord danach gesucht. Hintergrund meiner Suche war die Frage ob Radix die Historie speichert und dann zwangsläufig auch einiges mehr an Bandbreite aufwendet oder ob so ein Shard nicht vielleicht ausschließlich den aktuellen Kontostand enthält so wie eine Ethereum Node mit agressivem Pruning. Ich habe das hier gefunden:

So wie ich die Antwort verstehe, gehts da darum ob das Fehlschlagen einer Transaktion dauerhaft auf dem Ledger gespeichert wird. Dies passiert nicht, was dauerhaft gespeichert wird ist jeder Transaktions-output, jeder neue substate, der nach einer erfolgreichen Transaktion im Ledger abgelegt wird (also einen Platz im shardspace bekommt, deterministisch über nen Hash adressiert). Also jede erfolgreiche Transaktion. Damit kann ich die "Geschichte" des Ledgers vollständig zurückverfolgen. Nur kann ich nur die durchgeführten Transaktionen sehen, nicht die fehlgeschlagenen.

Auch kann man keine Epochen o.ä. durchsuchen, aber man kann jede Transaktion zurückverfolgen, sich quasi rückwärts durch den Ledger hangeln.

Allerdings ne gute Frage ob zur Transaktion die Daten zu Epoche u.ä. angefügt sind. Im der Transaktion beigefügten "Certificate" ist der Nachweis über die Abstimmung aller beteiligten Nodes bzgl. gültigkeit und Abgeschlossenheit enthalten, ob da Epoche etc auftauchen weis ich nicht.

Jedenfalls werden keine "substates" gepruned, also keine Daten, TRansaktionen, "Historie".

 

 

Bearbeitet 25. April von mahatma

[skunk]

vor 7 Stunden schrieb mahatma:

Ich denke nicht. Dein Bandbreitenbedarf hängt von der Anzahl der von deiner Node (mit-)bearbeiteten Transaktionen ab. Jedem Validator wird ein Stück des Shard-Spaces zugeteilt, welches seinen Kapazitäten entspricht. Daran ändern auch viele Jahre im Mainnet nichts. Je mehr Validatoren mit ins Netz gehen, umso kleiner wird der Anteil am gesamten Shardspace; die absolute Anzahl an substates, für die man als Validator verantwortlich ist, bliebe in diesem Fall auch über viele Jahre in etwa gleich, wenn man davon ausgeht das die Anzahl an Nodes mit dem Bedarf mit ansteigt.

Du vergisst, dass die Validatoren durch rotiert werden sollen. Das ist das was teuer wird. Ich bin nicht besorgt um die neuen Transaktionen die mit jedem neuen Block bestätigt werden. Ich bin besorgt um den Transfer der Altlasten von einem Validator zum Nächsten jedesmal wenn durch rotiert werden soll. Das wird mit den Jahren immer größer werden und damit auch immer teurer werden.

vor 7 Stunden schrieb mahatma:

Eine Validatorengruppe hat zwischen zwischen 100 und 3000 Validatoren. Übersteigt die Last der einzelnen Nodes eine gewisse Schwelle, wird die Anzahl der shardgruppen erhöht und die Anzahl der Validatoren pro Shardgruppe verringert, allerdings soll sie nie kleiner als 100 sein.

Das klingt schon mal deutlich realistischer als das was da im Testnet getrieben wurde. Das meinte ich mit absurden Marketing.

vor 7 Stunden schrieb mahatma:

Da die Validatorengruppen ständig durchgeshuffelt werden und in gleiche Gruppen nur Validatoren mit ähnlichem Stake kommen, können mehr als 33% "böse Nodes" pro Gruppe eigentlich nur passieren wenn mehr als 33% des gesamten Netzwerkes bösartig ist.

Nicht ganz. Betrachte das ganze wie ein Lotto Spiel. Du mietest 300 Validatoren in einem Rechenzentrum an. Die Chance, dass sie zufällig alle den gleichen Shard zugeteilt bekommen mag gering sein. Hier ist aber die ständige Rotation ein Vorteil. Nach Millionen von Ziehungen hat man irgendwann doch einen Treffer. Ich hab die Formel für die Berechnung hier. Gib mir einen Moment dann rechne ich es durch. Wenn wir von nur 100 Rotationen ausgehen reicht eine Chance von nur 1% damit der Fall durch Zufall einmal eintritt.

Sollte der Angriff gelingen, würde ich mit Gewinnen von deutlich mehr als 33% rechnen....

vor 7 Stunden schrieb mahatma:

Jedenfalls werden keine "substates" gepruned, also keine Daten, TRansaktionen, "Historie".

Dann wird es teuer. Eine Ethereum Full Archive Node ohne Pruning hat eine beeindruckende größe. Und diese Datenmenge wird jetzt einfach nur auf kleine Shards aufgeteilt aber es bleibt dennoch eine beeindruckende Datenmenge. Und dann kommt die nächste Rotation bei der diese komplette Datenmenge von einem Validator zum nächsten übertragen werden muss. Wenn die Blockchain für den Zeitraum der Rotation nicht gerade für Minuten offline gehen soll, muss diese Datenmenge in Sekunden transferiert werden...

Ethereum hat aktuell um die 500K Validatoren. Bei 100 Validatoren pro Shardspace sind das 5000 Gruppen. Eine Full Archive Node braucht mehr als 10 TB. Das macht dann 2 GB pro Shardspace. Quizfrage. Wie lange dauert der Transfer von 2 GB bei 10 MBit/s?

Bearbeitet 25. April von skunk

[mahatma]

vor 42 Minuten schrieb skunk:

Du vergisst, dass die Validatoren durch rotiert werden sollen. Das ist das was teuer wird. Ich bin nicht besorgt um die neuen Transaktionen die mit jedem neuen Block bestätigt werden. Ich bin besorgt um den Transfer der Altlasten von einem Validator zum Nächsten jedesmal wenn durch rotiert werden soll. Das wird mit den Jahren immer größer werden und damit auch immer teurer werden.

...

Und dann kommt die nächste Rotation bei der diese komplette Datenmenge von einem Validator zum nächsten übertragen werden muss. Wenn die Blockchain für den Zeitraum der Rotation nicht gerade für Minuten offline gehen soll, muss diese Datenmenge in Sekunden transferiert werden...

Hast du dir das Video mit Dan angeschaut? Da erklärt er sauber und ausführlich genau das... 

Pro Epoche wird nur ein kleiner Teil pro Shardgruppe rotiert, sagen wir mal 10%. Die müssen nicht sofort synchronisieren, da ja 90% der Shardgruppe alle substates besitzt und normal arbeiten kann.

Jetzt können sie sich erstmal die kritischen substates synchronisieren, also zB alle "offenen" substates bzw. UTXO. Sobald das abgeschlossen ist können sie am Validieren teilnehmen und die Anzahl der UTXO pro Shardgruppe wird über die Dauer in etwa konstant sein. Also kein Prozess der mit Alter des Netzwerkes zunimmt.

Die ganzen geschlossenen Shards, also die Infos über spent-outputs, sind zeitlich nicht kritisch und können langsam über die Dauer der Epoche hinweg nachsynchronisiert werden.

Aber wie gesagt, Dan erklärt das viel besser als ich, seine Videos machen Sinn zu sehen!

vor 42 Minuten schrieb skunk:

Nicht ganz. Betrachte das ganze wie ein Lotto Spiel. Du mietest 300 Validatoren in einem Rechenzentrum an. Die Chance, dass sie zufällig alle den gleichen Shard zugeteilt bekommen mag gering sein. Hier ist aber die ständige Rotation ein Vorteil. Nach Millionen von Ziehungen hat man irgendwann doch einen Treffer. Ich hab die Formel für die Berechnung hier. Gib mir einen Moment dann rechne ich es durch. Wenn wir von nur 100 Rotationen ausgehen reicht eine Chance von nur 1% damit der Fall durch Zufall einmal eintritt.

Ja, das ist schon klar, das ist halt das Sybil-Problem.

Ich kann nur sagen, das wurde ausführlich bedacht und berücksichtigt, auch wenn meine ad-hoc Erklärfähigkeiten vielleicht ans Limit kommen.

Auch hier, Dan kann das viel besser erklären, im folgenden Link geht er genau darauf ein. Vielleicht haste Zeit und schaust es dir an, dann muss ich hier kein Video-Transkskript machen.

https://www.youtube.com/watch?v=MaPkxM9MS_0&t=1900s

 

 

 

Bearbeitet 25. April von mahatma