TOP Network x NEAR-Protokoll-Whiteboard-Sitzung

Es stellt sich heraus, dass die Leuchtfeuerkette immer noch notwendig ist. In TOP fungiert die Beacon-Kette als globale Uhr, auf die alle Knoten im System verweisen können, und verwaltet auch Abstimmungen, Wahlen und mehr. Warum wird diese globale Uhr benötigt? Ein Grund, auf den Taylor hingewiesen hat, besteht darin, zu verhindern, dass Scherben Blöcke vorzeitig produzieren, sie halten und dann alle auf einmal freigeben, um zu versuchen, eine Gabel zu formen.

Dies wird durch die Verwendung von Zeitblöcken für die Beacon-Kette verhindert. Jeder Knoten im System erhält den neuesten Zeitblock, der alle 10 Sekunden erzeugt wird. Jeder Shard-Block muss einen Verweis auf den neuesten Zeitblock für die Beacon-Kette enthalten. Dies bedeutet, dass Blöcke nicht vorzeitig erstellt werden können, da sie warten müssen, bis der letzte Zeitblock referenziert ist. Cluster-Knoten können Shard-Blöcke einfach prüfen, um festzustellen, ob sie mit der richtigen Zeitblockreferenz erstellt wurden, da alle Knoten bei jedem Zeitblock verteilt werden.

Zonen 29:20

Wie in Teil 1 erwähnt, helfen Zonen dabei, Knoten effizienter zu organisieren. In zufälligen Netzwerken wie Bitcoin können sich Knotenverbindungen zwischen geografisch entfernten Knoten befinden, was die Leistung beeinträchtigen kann. In TOP werden Knoten in Zonen gruppiert, zum Teil basierend auf der Region, in der sie sich befinden. Die Frage, die Illia gestellt hat, ist, wer entscheidet, in welcher Zone ein Knoten landet.

Taylor erklärte, dass die Beacon-Kettenknoten für diesen Prozess verantwortlich sind, indem er einen sogenannten Proof of Bandwidth (PoB) verwendete. Beacon Chain Nodes überprüfen mithilfe dieses PoB-Prozesses die Netzwerkbedingungen eines neuen Knotens, um festzustellen, wo dieser enden soll.

Taylor betonte jedoch, dass die Knotensortierung immer noch zufällig ist. Die Netzwerkeigenschaften eines Knotens bieten nur eine höhere Chance, in einer bestimmten Zone zu landen. Dies hat zur Folge, dass die Leistung verbessert wird, da Knoten in derselben geografischen Region mit höherer Wahrscheinlichkeit in derselben Zone landen, was wiederum die Latenz verringert.

Cluster Audit Subsets 39:19

Eine andere Frage, die Illia aufgeworfen hat, hatte damit zu tun, wie Cluster Transaktionen prüfen. Wenn eine Transaktion von einem Shard bestätigt wird, wird sie an den übergeordneten Cluster gesendet. Hierbei wird eine Untermenge aller Knoten im Cluster zufällig ausgewählt, um ein Komitee zu bilden. Dieses Komitee prüft die Transaktion und sendet dann eine Bestätigungsquittung an den Shard zurück. Illia fragte, was passieren würde, wenn ein Shard zwei Transaktionen für dasselbe Konto gleichzeitig sendet und zwei verschiedene Untergruppen von Clusterknoten diese empfangen würden.

Angenommen, eine Transaktion, die 1000 Token von Konto A-> B sendet, und eine andere Transaktion, die 100 Token von Konto A-> B sendet, wurden gleichzeitig zur Prüfung gesendet. Wenn verschiedene Untergruppen innerhalb des Clusters jede Transaktion empfangen würden, welche Transaktion würde durchlaufen? Das potenzielle Problem besteht darin, dass beide Gruppen von Prüfungsausschüssen die andere Transaktion nicht kennen und sie beide die angegebene Transaktion als gültig ansehen.