NEAR Teknik Raporu
Statusgültigkeit und Datenverfügbarkeit
Die Kernidee bei Sharded blockchains ist, dass die meisten Teilnehmer, die bzw Durch die Nutzung des Netzwerks können Blöcke in allen Shards nicht validiert werden. Also wann immer Jeder Teilnehmer muss mit einem bestimmten Shard interagieren, was ihm im Allgemeinen nicht möglich ist Laden Sie den gesamten Verlauf des Shards herunter und validieren Sie ihn. Der Partitionierungsaspekt des Shardings birgt jedoch ein erhebliches Potenzial Problem: ohne den gesamten Verlauf einer bestimmten Datei herunterzuladen und zu validieren Shard Der Teilnehmer kann nicht unbedingt sicher sein, dass der Staat mit dem 5Dieser Abschnitt, mit Ausnahme von Unterabschnitt 2.5.3, wurde zuvor unter https://near.ai/ veröffentlicht. shard2. Wenn Sie es schon einmal gelesen haben, fahren Sie mit dem nächsten Abschnitt fort.
Ihre Interaktion ist das Ergebnis einer gültigen Folge von Blöcken und dieser Folge der Blöcke ist tatsächlich die kanonische Kette im Shard. Ein Problem, das nicht der Fall ist existieren in einem nicht fragmentierten blockchain. Wir werden zunächst eine einfache Lösung für dieses vorgeschlagene Problem vorstellen durch viele Protokolle und analysieren Sie dann, wie diese Lösung kaputt gehen kann und was Es wurden Versuche unternommen, das Problem anzugehen. 2.1 Rotation der Validatoren Die naive Lösung zur Staatsgültigkeit ist in Abbildung 5 dargestellt: Nehmen wir an, wir nehmen an dass das gesamte System in der Größenordnung von Tausenden validators hat, davon nicht mehr als 20 % sind böswillig oder werden auf andere Weise scheitern (z. B. indem sie es nicht tun). online, um einen Block zu erstellen). Wenn wir dann 200 validators abtasten, ist die Wahrscheinlichkeit von mehr als 1 3 Aus praktischen Gründen kann davon ausgegangen werden, dass der Wert null ist. Abbildung 5: Probenahme validators 1 3 ist ein wichtiger Schwellenwert. Es gibt eine Familie von Konsensprotokollen, genannt BFT Konsensprotokolle, die dies für weniger als 1 garantieren 3 von Teilnehmer scheitern, entweder durch einen Absturz oder durch ein Verhalten, das gegen die Regeln verstößt Protokoll wird der Konsens erzielt. Mit dieser Annahme ehrlicher validator Prozent, wenn der aktuelle Satz von Die naive Lösung geht davon aus, dass validators in einem Shard uns einen Block geben dass der Block gültig ist und dass er auf dem aufbaut, was die validators glaubten die kanonische Kette für diesen Shard, als sie mit der Validierung begannen. Die validators lernte die kanonische Kette aus dem vorherigen Satz von validators, die von demselben Annahme, die auf dem Block aufgebaut ist, der der Kopf der kanonischen Kette war davor. Durch Induktion ist die gesamte Kette gültig, und da keine Menge von validators An jedem Punkt, an dem Gabeln hergestellt werden, ist die naive Lösung auch sicher, dass der Strom vorhanden ist Kette ist die einzige Kette im Shard. Eine Visualisierung finden Sie in Abbildung 6.
Abbildung 6: Ein blockchain, bei dem jeder Block über einen BFT-Konsens abgeschlossen wird Diese einfache Lösung funktioniert nicht, wenn wir davon ausgehen, dass die validators möglich sind adaptiv korrumpiert, was keine unvernünftige Annahme ist6. Adaptiv Die Beschädigung eines einzelnen Shards in einem System mit 1000 Shards ist deutlich günstiger als das gesamte System zu beschädigen. Daher nimmt die Sicherheit des Protokolls linear mit der Anzahl der Shards ab. Um Gewissheit über die Gültigkeit zu haben Um einen Block zu erstellen, müssen wir wissen, dass es zu keinem Zeitpunkt in der Geschichte einen Shard im System gibt eine Mehrheit der validators konspiriert; Mit adaptiven Gegnern haben wir das nicht mehr solche Gewissheit. Wie wir in Abschnitt 1.5 besprochen haben, können konspirative validators Ausübung ausüben zwei grundlegende böswillige Verhaltensweisen: Forks erstellen und ungültige Blöcke erzeugen. Schädliche Forks können dadurch bekämpft werden, dass Blöcke mit der Beacon-Kette vernetzt werden, die im Allgemeinen für eine deutlich höhere Sicherheit ausgelegt ist die Scherbenketten. Das Erzeugen ungültiger Blöcke ist jedoch ein wesentlich größerer Aufwand herausforderndes Problem, das es zu bewältigen gilt. 2.2 Staatliche Gültigkeit Betrachten Sie Abbildung 7, in der Shard Nr. 1 beschädigt ist und ein böswilliger Akteur produziert ungültiger Block B. Angenommen, in diesem Block B wurden 1000 tokens aus dem Nichts geprägt Luft auf Alices Konto. Der böswillige Akteur erstellt dann einen gültigen Block C (in a (das Gefühl, dass die Transaktionen in C korrekt angewendet werden) auf B, was verschleiert den ungültigen Block B und initiiert eine Shard-übergreifende Transaktion zu Shard Nr. 2 überweist diese 1000 tokens auf Bobs Konto. Von diesem Moment an ist das falsch Die erstellten tokens befinden sich auf einem ansonsten vollständig gültigen blockchain in Shard Nr. 2. Einige einfache Ansätze zur Lösung dieses Problems sind: 6Lesen dies Artikel für Details auf wie adaptiv Korruption kann sein getragen aus: https://medium.com/nearprotocol/d859adb464c8. Für mehr Details auf adaptiv Korruption, lesen https://github.com/ethereum/wiki/wiki/Sharding-FAQ# Was sind die Sicherheitsmodelle, nach denen wir arbeiten?Abbildung 7: Eine Shard-übergreifende Transaktion aus einer Kette, die einen ungültigen Block hat 1. Für validators von Shard Nr. 2, um den Block zu validieren, von dem aus die Transaktion erfolgt wird eingeleitet. Dies wird auch im obigen Beispiel nicht funktionieren, da Block C scheint völlig gültig zu sein. 2. Damit validators in Shard Nr. 2 eine große Anzahl von Blöcken vor dem Block validieren, von dem aus die Transaktion initiiert wird. Natürlich, z Eine beliebige Anzahl von Blöcken N wird vom empfangenden Shard des Böswilligen validiert validators können N+1 gültige Blöcke zusätzlich zu dem ungültigen Block erstellen, den sie verwenden produziert. Eine vielversprechende Idee zur Lösung dieses Problems wäre die Anordnung von Shards in einer ungerichteter Graph, in dem jeder Shard mit mehreren anderen Shards verbunden ist, und Lassen Sie nur Cross-Shard-Transaktionen zwischen benachbarten Shards zu (z. B. so geht's). Das Sharding von Vlad Zamfir funktioniert im Wesentlichen7, und eine ähnliche Idee wird bei Kadena verwendet Chainweb [1]). Wenn eine Shard-übergreifende Transaktion zwischen Shards erforderlich ist keine Nachbarn, eine solche Transaktion wird über mehrere Shards geleitet. In diesem Design Es wird erwartet, dass ein validator in jedem Shard alle Blöcke in seinem Shard validiert sowie alle Blöcke in allen benachbarten Shards. Betrachten Sie die folgende Abbildung mit 10 Shards, von denen jeder vier Nachbarn hat und keine zwei Shards, die mehr erfordern mehr als zwei Hops für eine Shard-übergreifende Kommunikation, wie in Abbildung 8 dargestellt. Shard Nr. 2 validiert nicht nur seine eigene blockchain, sondern auch blockchains von alle Nachbarn, einschließlich Shard #1. Wenn es sich also um einen böswilligen Akteur auf Shard Nr. 1 handelt versucht, einen ungültigen Block B zu erstellen und dann Block C darauf aufzubauen und eine Cross-Shard-Transaktion initiieren, eine solche Cross-Shard-Transaktion wird nicht durchgeführt durch, da Shard Nr. 2 die gesamte Geschichte von Shard Nr. 1 validiert hat führt dazu, dass der ungültige Block B identifiziert wird. 7Lesen Sie hier mehr über das Design: https://medium.com/nearprotocol/37e538177ed9
Abbildung 8: Eine ungültige Cross-Shard-Transaktion in einem Chainweb-ähnlichen System entdeckt werden Während das Korrumpieren eines einzelnen Shards kein brauchbarer Angriff mehr ist, ist das Korrumpieren eines Shards kein brauchbarer Angriff mehr Wenig Scherben bleiben ein Problem. In Abbildung 9 korrumpiert ein Gegner beide Shards
1 und Shard #2 führen erfolgreich eine Cross-Shard-Transaktion zu Shard #3 aus
mit Mitteln aus einem ungültigen Block B: Abbildung 9: Eine ungültige Cross-Shard-Transaktion in einem Chainweb-ähnlichen System nicht erkannt werden Shard Nr. 3 validiert alle Blöcke in Shard Nr. 2, jedoch nicht in Shard Nr. 1, und hat keine Möglichkeit, den bösartigen Block zu erkennen. Es gibt zwei Hauptrichtungen zur ordnungsgemäßen Lösung der Staatsvalidität: Fischer
und kryptografische Rechennachweise. 2.3 Fischer Die Idee hinter dem ersten Ansatz ist die folgende: Immer wenn ein Blockheader angezeigt wird wird zwischen Ketten zu irgendeinem Zweck kommuniziert (z. B. zur Vernetzung mit dem B. einer Beacon-Kette oder einer Cross-Shard-Transaktion), gibt es einen Zeitraum während womit jeder ehrliche validator einen Beweis dafür liefern kann, dass der Block ungültig ist. Da Es gibt verschiedene Konstruktionen, die sehr prägnante Beweise dafür ermöglichen, dass es sich um Blöcke handelt ungültig, sodass der Kommunikationsaufwand für die empfangenden Knoten viel geringer ist als das Erhalten eines vollständigen Blocks. Mit diesem Ansatz, solange es mindestens einen ehrlichen validator in der Shard, das System ist sicher. Abbildung 10: Fischer Dies ist der vorherrschende Ansatz (neben der Behauptung, dass das Problem nicht existiert) unter den heute vorgeschlagenen Protokollen. Dieser Ansatz hat jedoch zwei Hauptnachteile: 1. Der Herausforderungszeitraum muss für den ehrlichen validator ausreichend lang sein Um zu erkennen, dass ein Block erstellt wurde, laden Sie ihn herunter, überprüfen Sie ihn vollständig und bereiten Sie ihn vor die Challenge, wenn der Block ungültig ist. Die Einführung eines solchen Zeitraums würde verlangsamen die Cross-Shard-Transaktionen erheblich. 2. Die Existenz des Challenge-Protokolls schafft einen neuen Angriffsvektor wenn bösartige Knoten mit ungültigen Herausforderungen spammen. Eine naheliegende Lösung Dieses Problem besteht darin, die Herausforderer dazu zu bringen, einen bestimmten Betrag an tokens einzuzahlen werden zurückgegeben, wenn die Challenge gültig ist. Dies ist nur eine Teillösung, wie es heißt könnte für den Angreifer immer noch von Vorteil sein, das System zu spammen (und zu verbrennen). der Einlagen) mit ungültigen Anfechtungen, beispielsweise zur Verhinderung der gültigenHerausforderung von einem ehrlichen validator vom Durchgehen. Diese Angriffe sind sogenannte Trauerattacken. Eine Möglichkeit, den letztgenannten Punkt zu umgehen, finden Sie in Abschnitt 3.7.2. 2.4 Prägnante, nicht interaktive Wissensargumente Die zweite Lösung für die Beschädigung mehrerer Shards besteht darin, kryptografische Konstruktionen zu verwenden, mit denen man beweisen kann, dass eine bestimmte Berechnung (z. B (z. B. die Berechnung eines Blocks aus einer Reihe von Transaktionen) wurde korrekt durchgeführt. Es gibt solche Konstruktionen, z.B. zk-SNARKs, zk-STARKs und einige andere, und einige werden heute aktiv in blockchain-Protokollen für private Zahlungen verwendet, vor allem ZCash. Das Hauptproblem bei solchen Grundelementen besteht darin, dass sie sind notorisch langsam zu berechnen. Z.B. Coda-Protokoll, das zk-SNARKs verwendet Insbesondere um zu beweisen, dass alle Blöcke in blockchain gültig sind, in einem Aus den Interviews geht hervor, dass die Erstellung eines Beweises 30 Sekunden pro Transaktion dauern kann (Diese Zahl ist wahrscheinlich mittlerweile kleiner). Interessanterweise muss ein Beweis nicht von einer vertrauenswürdigen Partei berechnet werden Der Beweis bescheinigt nicht nur die Gültigkeit der Berechnung, für die er erstellt wurde, sondern auch die Gültigkeit des Beweises selbst. Daher kann die Berechnung solcher Beweise aufgeteilt werden unter einer Gruppe von Teilnehmern mit deutlich geringerer Redundanz, als es der Fall wäre notwendig, um eine vertrauenswürdige Berechnung durchzuführen. Es ermöglicht auch Teilnehmern die zk-SNARKs berechnen, um auf spezieller Hardware zu laufen, ohne die zu reduzieren Dezentralisierung des Systems. Die Herausforderungen von zk-SNARKs sind neben der Leistung: 1. Abhängigkeit von weniger erforschten und weniger bewährten kryptografischen Grundelementen; 2. „Giftiger Abfall“ – zk-SNARKs sind auf ein vertrauenswürdiges Setup angewiesen, in dem eine Gruppe vorhanden ist der Leute führt eine Berechnung durch und verwirft dann das Zwischenprodukt Werte dieser Berechnung. Wenn alle Verfahrensbeteiligten Absprachen treffen und die Zwischenwerte beibehalten, können gefälschte Beweise erstellt werden; 3. Zusätzliche Komplexität im Systemdesign; 4. zk-SNARKs funktionieren nur für eine Teilmenge möglicher Berechnungen, also ein Protokoll mit einer Turing-vollständigen smart contract-Sprache wäre dies nicht möglich SNARKs zum Beweis der Gültigkeit der Kette. 2.5 Datenverfügbarkeit Das zweite Problem, das wir ansprechen werden, ist die Datenverfügbarkeit. Im Allgemeinen Knoten Betrieb eines bestimmten blockchain sind in zwei Gruppen unterteilt: Vollständige Knoten, diejenigen, die jeden vollständigen Block herunterladen und jede Transaktion validieren, und Light Knoten, die nur Blockheader herunterladen und Merkle-Proofs für Teile verwenden des Zustands und der Transaktionen, an denen sie interessiert sind, wie in Abbildung 11 dargestellt.
Abbildung 11: Merkle-Baum Wenn nun die Mehrheit der vollständigen Knoten zusammenarbeitet, können sie einen Block erzeugen, gültig oder ungültig, und senden Sie seine hash an die Lichtknoten, geben Sie jedoch niemals den vollständigen Inhalt preis des Blocks. Es gibt verschiedene Möglichkeiten, wie sie davon profitieren können. Zum Beispiel, Betrachten Sie Abbildung 12: Abbildung 12: Problem mit der Datenverfügbarkeit Es gibt drei Blöcke: Der vorherige, A, wird von ehrlichen validators erzeugt; der Strom, B, hat validators, die konspirieren; und das nächste, C, wird ebenfalls produziert von ehrlichen validators (der blockchain ist in der unteren rechten Ecke abgebildet). Sie sind ein Händler. Die validators des aktuellen Blocks (B) empfangenen Blocks Ein aus den vorherigen validators berechneter Block, in dem Sie Geld erhalten,und habe Ihnen einen Header dieses Blocks mit einem Merkle-Beweis für den Zustand geschickt, in dem er sich befindet Sie haben Geld (oder einen Merkle-Nachweis einer gültigen Transaktion, die das Geld sendet). für dich). Im Vertrauen darauf, dass die Transaktion abgeschlossen ist, erbringen Sie den Service. Allerdings verteilen die validators niemals den gesamten Inhalt des Blocks B an irgendjemand. Daher können die ehrlichen validators von Block C den Block nicht abrufen, und sind entweder gezwungen, das System zum Stillstand zu bringen oder auf A aufzubauen, wodurch Sie als a benachteiligt werden Geldhändler. Wenn wir das gleiche Szenario auf Sharding anwenden, ergeben sich die Definitionen von vollständig und Light-Knoten gelten im Allgemeinen pro Shard: validators in jedem Shard-Download alle Blockieren Sie diesen Shard und validieren Sie jede Transaktion in diesem Shard, außer anderen Knoten im System, einschließlich derjenigen, die Snapshot-Shard-Ketten in den Status aufnehmen Beacon-Kette, laden Sie nur die Header herunter. So lauten die validators im Shard effektiv vollständige Knoten für diesen Shard, während andere Teilnehmer im System, einschließlich der Beacon-Kette, fungieren als Lichtknoten. Damit der oben besprochene Fisherman-Ansatz funktioniert, sind ehrliche validators erforderlich Sie müssen in der Lage sein, Blöcke herunterzuladen, die mit der Beacon-Kette vernetzt sind. Wenn böswillige validators einen Header eines ungültigen Blocks vernetzten (oder ihn dazu nutzten). eine Cross-Shard-Transaktion initiieren), aber niemals den Block verteilen, das ehrlich validators haben keine Möglichkeit, eine Herausforderung zu gestalten. Wir werden drei Ansätze zur Lösung dieses Problems behandeln, die sich ergänzen einander. 2.5.1 Sorgerechtsnachweise Das unmittelbarste zu lösende Problem ist, ob ein Block einmal verfügbar ist es wird veröffentlicht. Eine vorgeschlagene Idee besteht darin, so genannte Notare einzusetzen, die rotieren zwischen Shards häufiger als validators, deren einzige Aufgabe darin besteht, a herunterzuladen blockieren und bestätigen, dass sie es herunterladen konnten. Das können sie sein häufiger rotiert, da nicht der gesamte Bundesstaat heruntergeladen werden muss des Shards, im Gegensatz zu den validators, die seitdem nicht häufig rotiert werden können Sie müssen bei jeder Drehung den Status des Shards herunterladen, wie in der Abbildung dargestellt 13. Das Problem bei diesem naiven Ansatz ist, dass es unmöglich ist, ihn später zu beweisen ob der Notar den Block herunterladen konnte oder nicht, also ein Notar können sich dafür entscheiden, immer zu bestätigen, dass sie den Block auch ohne herunterladen konnten sogar versucht, es wiederzubekommen. Eine Lösung hierfür ist die Bereitstellung durch Notare einige Beweise oder eine gewisse Menge an tokens einzusetzen, die belegen, dass der Block vorhanden war heruntergeladen. Eine solche Lösung wird hier diskutiert: https://ethresear.ch/t/ 1-bit-aggregation-freundliche-custody-bonds/2236. 2.5.2 Löschcodes Wenn ein bestimmter Lichtknoten einen hash eines Blocks empfängt, um den Knoten zu erhöhen Wenn Sie sicher sind, dass der Block verfügbar ist, können Sie versuchen, einige zufällige herunterzuladen Stücke des Blocks. Dies ist keine vollständige Lösung, da es sich nicht um die Lichtknoten handelt Laden Sie gemeinsam den gesamten Block herunter, den die böswilligen Blockproduzenten auswählen können
Abbildung 13: Validatoren müssen den Status herunterladen und können daher nicht rotiert werden häufig um die Teile des Blocks zurückzuhalten, die von keinem Lichtknoten heruntergeladen wurden, Dadurch ist der Block immer noch nicht verfügbar. Eine Lösung besteht darin, eine Konstruktion namens Erasure Codes zu verwenden, um dies zu ermöglichen um den gesamten Block wiederherzustellen, auch wenn nur ein Teil des Blocks verfügbar ist, wie gezeigt auf Abbildung 14. Abbildung 14: Merkle tree basiert auf löschcodierten Daten Sowohl Polkadot als auch Ethereum Serenity haben Designs rund um diese Idee Bieten Sie Lichtknoten die Möglichkeit, einigermaßen sicher zu sein, dass die Blöcke verfügbar sind. Eine ausführliche Beschreibung des Ethereum Serenity-Ansatzes finden Sie in [2].2.5.3 Polkadots Ansatz zur Datenverfügbarkeit In Polkadot erstellt, wie in den meisten Shard-Lösungen, jeder Shard (Parachain genannt) einen Snapshot seiner Blöcke in der Beacon-Kette (Relay-Kette genannt). Angenommen, es gibt 2f + 1 validators in der Relaiskette. Die Blockproduzenten der Parachain-Blöcke, genannt Collatoren berechnen nach der Erstellung des Parachain-Blocks eine löschcodierte Version des Blocks, die aus 2f +1 Teilen besteht, sodass alle f-Teile ausreichen um den Block zu rekonstruieren. Anschließend verteilen sie einen Teil an jeden validator auf der Relaiskette. Eine bestimmte Relay-Kette validator würde sich nur an einer Relay-Kette anmelden Block, wenn sie ihren Teil für jeden Parachain-Block haben, auf den ein Snapshot erstellt wird ein solcher Relaiskettenblock. Wenn also ein Relay-Chain-Block Signaturen von 2f + 1 hat validators und solange jeweils nicht mehr als f von ihnen gegen das Protokoll verstoßen haben Der Parachain-Block kann durch Abrufen der Teile aus den validators rekonstruiert werden die dem Protokoll folgen. Siehe Abbildung 15. Abbildung 15: Datenverfügbarkeit von Polkadot 2.5.4 Langfristige Datenverfügbarkeit Beachten Sie, dass alle oben diskutierten Ansätze nur die Tatsache bestätigen, dass ein Block vorliegt wurde überhaupt veröffentlicht und ist jetzt verfügbar. Blöcke können später nicht mehr verfügbar sein Aus verschiedenen Gründen: Knoten gehen offline, Knoten löschen absichtlich historische Daten Daten und andere. Ein erwähnenswertes Whitepaper, das sich mit diesem Problem befasst, ist Polyshard [3], das Löschcodes verwendet, um Blöcke über Shards hinweg verfügbar zu machen, auch wenn es mehrere sind Shards verlieren ihre Daten vollständig. Leider erfordert ihr spezifischer Ansatz Alle Shards, um Blöcke von allen anderen Shards herunterzuladen, was unerschwinglich ist teuer. Die langfristige Verfügbarkeit ist kein so dringendes Problem: da kein Teilnehmer Es wird erwartet, dass das System in der Lage ist, alle Ketten in allen zu validieren
Shards, die Sicherheit des Shard-Protokolls muss so gestaltet sein So ist das System sicher, auch wenn einige alte Blöcke in einigen Shards beschädigt werden völlig nicht verfügbar.
Durum Geçerliliği ve Veri Kullanılabilirliği
Parçalanmış blockchain'lerdeki temel fikir, çoğu katılımcının işletim veya ağı kullanmak tüm parçalardaki blokları doğrulayamaz. Bu nedenle, ne zaman olursa olsun herhangi bir katılımcının genellikle yapamadığı belirli bir parçayla etkileşime girmesi gerekir Parçanın tüm geçmişini indirin ve doğrulayın. Bununla birlikte, parçalamanın bölümleme yönü önemli bir potansiyel ortaya çıkarmaktadır. sorun: belirli bir uygulamanın tüm geçmişini indirmeden ve doğrulamadan katılımcının parçanın bulunduğu durumdan mutlaka emin olması mümkün değildir. 5Bu bölüm, alt bölüm 2.5.3 hariç, daha önce https://near.ai/ adresinde yayınlanmıştır. parça2. Daha önce okuduysanız bir sonraki bölüme geçin.
etkileşime girmeleri bazı geçerli blok dizilerinin sonucudur ve bu dizi Blok sayısı gerçekten de parçadaki kanonik zincirdir. Çözülmeyen bir sorun parçalanmamış bir blockchain içinde mevcut. Öncelikle bu soruna önerilen basit bir çözüm sunacağız. birçok protokole göre analiz edin ve ardından bu çözümün nasıl bozulabileceğini ve ne olacağını analiz edin. giderilmesine yönelik girişimlerde bulunuldu. 2.1 Doğrulayıcıların rotasyonu Durum geçerliliğine yönelik saf çözüm şekil 5'te gösterilmektedir: diyelim ki tüm sistemde binlerce validators var, bunlardan %20'den fazlası kötü niyetli değildir veya başka şekilde başarısız olacaktır (örneğin, Bir blok oluşturmak için çevrimiçi). O zaman 200 validators örnek alırsak olasılık 1'den fazla 3 pratik amaçlar açısından başarısızlığın sıfır olduğu varsayılabilir. Şekil 5: Örnekleme validators 1 3 önemli bir eşik. Bir mutabakat protokolü ailesi var. BFT fikir birliği protokolleri; bu, 1'den az olduğu sürece bunu garanti eder 3'ü Katılımcılar ya kaza yaparak ya da kuralları ihlal eden bir şekilde hareket ederek başarısız olurlar. Protokolde fikir birliğine varılacak. Bu dürüst validator yüzdelik varsayımla, eğer mevcut Saf çözüm, bir parçadaki validators'nin bize bir miktar blok sağladığını varsayar bloğun geçerli olduğunu ve validators olduğuna inanılanlar üzerine inşa edildiğini doğrulamaya başladıklarında söz konusu parçanın standart zinciri. validator'lar kanonik zinciri önceki validators kümesinden öğrendi; Kanonik zincirin başı olan bloğun üzerine inşa edilen varsayım ondan önce. Tümevarımla zincirin tamamı geçerlidir ve validators kümesi olmadığından Çatal üretilen herhangi bir noktada, naif çözüm aynı zamanda mevcut olanın da kesin olduğudur. zincir, parçadaki tek zincirdir. Görselleştirme için şekil 6'ya bakın.
Şekil 6: Her bloğun BFT fikir birliğiyle sonlandırıldığı bir blockchain validators'nin olabileceğini varsayarsak bu basit çözüm işe yaramaz. uyumsal olarak bozulmuştur ki bu mantıksız bir varsayım değildir6. Uyarlanabilir 1000 parçadan oluşan bir sistemde tek bir parçayı bozmak çok daha ucuzdur tüm sistemi bozmak yerine. Bu nedenle protokolün güvenliği, parça sayısı arttıkça doğrusal olarak azalır. Geçerliliğinden emin olmak için bir blok, tarihin herhangi bir noktasında sistemdeki hiçbir parçanın olmadığını bilmeliyiz. validator'ların çoğunluğu gizli anlaşma yapıyor; uyarlanabilir düşmanlarla artık elimizde değil öyle bir kesinlik ki. Bölüm 1.5'te tartıştığımız gibi, validators ile gizli anlaşma yapmak işe yarayabilir iki temel kötü niyetli davranış: çatallar oluşturmak ve geçersiz bloklar üretmek. Kötü niyetli çatallanmalar, blokların genel olarak diğerlerine göre önemli ölçüde daha yüksek güvenliğe sahip olacak şekilde tasarlanan Beacon zincirine çapraz bağlanmasıyla ele alınabilir. kırık zincirler. Geçersiz bloklar üretmek ise önemli ölçüde daha fazla bir sorundur. üstesinden gelinmesi zor bir sorun. 2.2 Durum Geçerliliği 1. Parçanın bozulduğu ve kötü niyetli bir aktörün ürettiği Şekil 7'yi düşünün. geçersiz blok B. Diyelim ki bu B bloğunda 1000 tokens yoktan basıldı Alice'in hesabında yayın. Kötü niyetli aktör daha sonra geçerli C bloğunu üretir (bir C'deki işlemlerin doğru bir şekilde uygulandığını hissetmek) B'nin yanı sıra kafa karıştırıcı geçersiz B bloğunu kullanır ve Parça #2'ye bir çapraz parça işlemi başlatır. bu 1000 tokens'yi Bob'un hesabına aktarır. Bu andan itibaren uygunsuz bir şekilde oluşturulan token'ler, Parça #2'deki tamamen geçerli bir blockchain üzerinde bulunuyor. Bu sorunu çözmeye yönelik bazı basit yaklaşımlar şunlardır: 6Oku bu makale için ayrıntılar üzerinde nasıl uyarlanabilir yolsuzluk yapabilir olmak taşınan dışarı: https://medium.com/nearprotocol/d859adb464c8. için daha fazla ayrıntılar üzerinde uyarlanabilir yolsuzluk, okumak https://github.com/ethereum/wiki/wiki/Sharding-FAQ# altında-çalıştığımız-güvenlik modelleri nelerdirŞekil 7: Geçersiz bloğu olan bir zincirden gelen parçalar arası işlem 1. İşlemin yapıldığı bloğu doğrulamak amacıyla validators Parça #2 için başlatılır. Bu yukarıdaki örnekte bile işe yaramayacaktır çünkü C bloğu tamamen geçerli olduğu görülmektedir. 2. İşlemin başlatıldığı bloktan önceki çok sayıda bloğu doğrulamak için Parça #2'deki validators için. Doğal olarak, kötü niyetli alıcı parça tarafından doğrulanan herhangi bir sayıda blok N validators, geçersiz bloğun üstünde N+1 geçerli blok oluşturabilir üretildi. Bu sorunu çözmek için umut verici bir fikir, parçaları bir düzende düzenlemek olacaktır. her bir parçanın diğer birkaç parçaya bağlandığı yönlendirilmemiş grafik ve yalnızca komşu parçalar arasında çapraz parça işlemlerine izin ver (ör. Vlad Zamfir'in parçalaması esasen işe yarıyor7 ve benzer fikir Kadena'nınkinde de kullanılıyor Chainweb [1]). Parçalar arasında parçalar arası bir işlem gerekiyorsa komşular değil, bu tür işlemler birden fazla parça aracılığıyla yönlendirilir. Bu tasarımda Her bir parçadaki bir validator'nin, kendi parçalarındaki tüm blokları doğrulaması bekleniyor ve ayrıca tüm komşu parçalardaki tüm bloklar. Aşağıdaki şekli düşünün 10 parçadan oluşan, her birinin dört komşusu olan ve daha fazlasını gerektiren iki parçanın olmadığı Şekil 8'de gösterilen çapraz parça iletişimi için ikiden fazla atlama. Parça #2 yalnızca kendi blockchain parçasını değil aynı zamanda blockchain parçasını da doğruluyor 1 numaralı Parça dahil tüm komşular. Yani Parça #1'de kötü niyetli bir aktör varsa geçersiz bir B bloğu oluşturmaya çalışıyor, ardından bunun üzerine C bloğunu inşa ediyor ve parçalar arası bir işlem başlatın, bu tür parçalar arası işlem gerçekleşmeyecek Parça #2'den beri Parça #1'in tüm geçmişi doğrulanmış olacak. geçersiz B bloğunu tanımlamasına neden olacaktır. 7Tasarım hakkında daha fazla bilgiyi burada bulabilirsiniz: https://medium.com/nearprotocol/37e538177ed9
Şekil 8: Chainweb benzeri sistemde geçersiz bir çapraz parça işlemi tespit edilmek Tek bir parçayı bozmak artık geçerli bir saldırı olmasa da, bir parçayı bozmak artık geçerli bir saldırı değildir. birkaç parça sorun olmaya devam ediyor. Şekil 9'da bir düşman her iki Shard'ı da bozuyor
1 ve Parça #2, Parça #3'e yönelik bir çapraz parça işlemini başarıyla yürütür
geçersiz bir B bloğundan gelen fonlarla: Şekil 9: Chainweb benzeri sistemde geçersiz bir çapraz parça işlemi tespit edilmemek Parça #3, Parça #2'deki tüm blokları doğrular ancak Parça #1'deki tüm blokları doğrular ve kötü amaçlı bloğu tespit etmenin bir yolu yoktur. Durum geçerliliğini doğru şekilde çözmenin iki ana yönü vardır: balıkçılar
ve hesaplamanın kriptografik kanıtları. 2.3 Balıkçı İlk yaklaşımın arkasındaki fikir şudur: ne zaman bir blok başlığı Herhangi bir amaç için zincirler arasında iletilir (örneğin çapraz bağlanma gibi). işaret zinciri veya parçalar arası bir işlem), bu sırada belirli bir süre vardır dürüst herhangi bir validator bloğun geçersiz olduğuna dair kanıt sağlayabilir. Orada blokların çok kısa ve öz kanıtlarını sağlayan çeşitli yapılardır. geçersiz olduğundan alıcı düğümlerin iletişim yükü çok daha küçüktür tam bir blok almaktan daha fazla. En az bir dürüst validator olduğu sürece bu yaklaşımla Shard, sistem güvenlidir. Şekil 10: Balıkçı Bu, bugün önerilen protokoller arasında (sorun yokmuş gibi davranmanın yanı sıra) baskın yaklaşımdır. Ancak bu yaklaşımın iki önemli dezavantajlar: 1. Dürüst validator için meydan okuma süresinin yeterince uzun olması gerekir Bir bloğun üretildiğini tanımak, onu indirmek, tamamen doğrulamak ve hazırlamak blok geçersizse meydan okuma. Böyle bir dönemin getirilmesi Parçalar arası işlemleri önemli ölçüde yavaşlatır. 2. Challenge protokolünün varlığı yeni bir saldırı vektörü yaratıyor Kötü niyetli düğümler geçersiz sorgulamalarla spam yaptığında. Açık bir çözüm Bu sorunun çözümü, meydan okuyanların bir miktar tokens yatırmasını sağlamaktır. meydan okuma geçerliyse iade edilir. Bu yalnızca kısmi bir çözümdür, çünkü saldırganın sisteme spam göndermesi (ve yakması) yine de faydalı olabilir. örneğin geçerli işlemleri engellemek için geçersiz sorgulamalarla yapılan para yatırma işlemleri)dürüst bir validator'dan gelen meydan okuma. Bu saldırılar Kederli Saldırılar denir. İkinci noktayı aşmanın bir yolu için bölüm 3.7.2'ye bakın. 2.4 Kısa ve Etkileşimli Olmayan Bilgi Argümanları Çoklu parça bozulmasına karşı ikinci çözüm, belirli bir hesaplamanın (örneğin, bir dizi işlemden bir bloğun hesaplanması gibi) doğru bir şekilde gerçekleştirildi. Bu tür yapılar mevcuttur; zk-SNARK'lar, zk-STARK'lar ve birkaç kişi daha, ve bazıları bugün blockchain protokollerinde özel ödemeler için aktif olarak kullanılıyor, en önemlisi ZCash. Bu tür ilkellerle ilgili temel sorun, onların hesaplamanın oldukça yavaş olduğu biliniyor. Örn. zk-SNARK'ları kullanan Coda Protokolü özellikle blockchain içindeki tüm blokların geçerli olduğunu kanıtlamak için, birinde söylendi Kanıt oluşturmanın işlem başına 30 saniye sürebileceği görüşmelerden (bu sayı muhtemelen şimdiye kadar daha küçüktür). İlginç bir şekilde, bir kanıtın güvenilir bir tarafça hesaplanmasına gerek yoktur, çünkü Kanıt yalnızca oluşturulduğu hesaplamanın geçerliliğini kanıtlamakla kalmaz, aynı zamanda kanıtın kendisinin geçerliliği. Dolayısıyla bu tür kanıtların hesaplanması bölünebilir önemli ölçüde daha az yedekliliğe sahip bir grup katılımcı arasında bazı güvenilir hesaplamalar yapmak için gereklidir. Aynı zamanda katılımcıların zk-SNARK'ları özel donanım üzerinde çalışacak şekilde hesaplayanlar sistemin ademi merkeziyetçiliği. zk-SNARK'ların performansın yanı sıra karşılaştığı zorluklar şunlardır: 1. Daha az araştırılmış ve daha az zaman içinde test edilmiş kriptografik temellere bağımlılık; 2. “Zehirli atık” — zk-SNARK'lar, bir grubun içinde bulunduğu güvenilir bir kuruluma bağlıdır İnsanların oranı bir miktar hesaplama yapıyor ve ardından ara hesaplamayı atıyor bu hesaplamanın değerleri. Prosedürün tüm katılımcıları gizli anlaşma yaparsa ve ara değerleri koruyarak sahte deliller oluşturulabilir; 3. Sistem tasarımına eklenen ekstra karmaşıklık; 4. zk-SNARK'lar yalnızca olası hesaplamaların bir alt kümesi için çalışır, dolayısıyla bir protokol Turing-complete smart contract dilini kullanamazsınız Zincirin geçerliliğini kanıtlamak için SNARK'lar. 2.5 Veri Kullanılabilirliği Değineceğimiz ikinci sorun veri kullanılabilirliğidir. Genellikle düğümler belirli bir blockchain çalıştıran iki gruba ayrılır: Tam Düğümler, her tam bloğu indiren ve her işlemi doğrulayanlar ve Light Yalnızca blok başlıklarını indiren ve parçalar için Merkle kanıtlarını kullanan düğümler Şekil 11'de gösterildiği gibi ilgilendikleri durum ve işlemler.
Şekil 11: Merkle Ağacı Artık tam düğümlerin çoğunluğu gizli anlaşma yaparsa geçerli veya geçerli bir blok üretebilirler. geçersizdir ve hash dosyasını hafif düğümlere gönderin, ancak içeriğin tamamını hiçbir zaman açıklamayın bloğun. Bundan faydalanabilecekleri çeşitli yollar vardır. Örneğin, Şekil 12'yi düşünün: Şekil 12: Veri Kullanılabilirliği sorunu Üç blok vardır: önceki A, dürüst validators tarafından üretilmiştir; mevcut B'nin validators gizli anlaşması var; ve bir sonraki C de üretilecek dürüst validators tarafından (blockchain sağ alt köşede gösterilmektedir). Sen bir tüccarsın. Geçerli bloğun (B) validator'leri alınan blok Önceki validator'lerden A, içinde para aldığınız bir blok hesapladı,ve size o bloğun başlığını, içinde bulunulan durumun Merkle kanıtıyla birlikte gönderdim. paranız var (veya parayı gönderen geçerli bir işlemin Merkle kanıtı) sana). İşlemin tamamlandığından emin olduğunuzda hizmeti sağlarsınız. Ancak validator'ler hiçbir zaman B bloğunun tam içeriğini dağıtmaz. herhangi biri. Bu nedenle, C bloğunun dürüst validator'leri bloğu geri alamaz ve ya sistemi durdurmaya zorlanırlar ya da A'nın üzerine inşa ederek sizi bir sistem olarak mahrum bırakırlar. para tüccarı. Aynı senaryoyu parçalamaya uyguladığımızda tam ve hafif düğüm genellikle parça başına uygulanır: her parça indirmesinde validators o parçada bloke edin ve o parçadaki her işlemi doğrulayın, ancak diğer parça zincirlerinin anlık görüntüsünü alan düğümler de dahil olmak üzere sistemdeki düğümler işaret zinciri, yalnızca başlıkları indirin. Böylece parçadaki validator'ler sistemdeki diğer katılımcılar bu parça için etkili bir şekilde tam düğümler oluştururken, işaret zinciri de dahil olmak üzere ışık düğümleri olarak çalışır. Yukarıda tartıştığımız balıkçı yaklaşımının işe yaraması için dürüst validators işaret zincirine çapraz bağlı blokları indirebilmeniz gerekir. Kötü niyetli validator'ler geçersiz bir bloğun başlığını çapraz bağladıysa (veya bunu kullandıysa) parçalar arası bir işlem başlatır), ancak bloğu asla dağıtmaz, dürüst validator'lerin bir meydan okuma oluşturmanın hiçbir yolu yok. Bu sorunu çözmek için birbirini tamamlayan üç yaklaşımı ele alacağız. Birbirimiz. 2.5.1 Velayet Kanıtları Çözülmesi gereken en acil sorun, bir bloğun bir kez kullanılabilir olup olmadığıdır. yayınlandı. Önerilen fikirlerden biri dönüşümlü Noterlere sahip olmaktır. tek işi bir dosya indirmek olan validator'lerden daha sık parçalar arasında engelleyin ve indirebildiklerini doğrulayın. Onlar olabilir tüm durumu indirmeleri gerekmediği için daha sık dönüşümlü olarak kullanılıyor parçanın aksine, sık sık döndürülemeyen validator'lerin aksine şekilde gösterildiği gibi her döndüklerinde parçanın durumunu indirmeleri gerekir 13. Bu naif yaklaşımın sorunu daha sonra kanıtlamanın imkansız olmasıdır. Noterin bloğu indirip indiremediğine bağlı olarak Noter bloğu indirebildiklerini her zaman onaylamayı seçebilirler. hatta onu geri almaya çalışıyorum. Bunun bir çözümü Noterlerin sağlamasıdır. bloğun olduğunu kanıtlayan bazı kanıtlar veya bir miktar tokens stake etmek indirildi. Böyle bir çözüm burada tartışılmaktadır: https://ethresear.ch/t/ 1 bitlik toplama dostu saklama tahvilleri/2236. 2.5.2 Silme Kodları Belirli bir ışık düğümü bir bloğun hash değerini aldığında, düğümün Bloğun mevcut olduğundan emin olmak için rastgele birkaç tane indirmeyi deneyebilir bloğun parçaları. Bu tam bir çözüm değil çünkü ışık düğümleri Kötü niyetli blok üreticilerinin seçebileceği bloğun tamamını toplu olarak indirin
Şekil 13: Doğrulayıcıların durumu indirmesi gerekir ve bu nedenle döndürülemez sık sık bloğun herhangi bir ışık düğümü tarafından indirilmeyen kısımlarını alıkoymak, böylece bloğu hala kullanılamaz hale getiriyoruz. Çözümlerden biri, bunu mümkün kılmak için Silme Kodları adı verilen bir yapıyı kullanmaktır. gösterildiği gibi bloğun yalnızca bir kısmı mevcut olsa bile tüm bloğu kurtarmak için Şekil 14'te. Şekil 14: Merkle tree silme kodlu veriler üzerine inşa edilmiştir Hem Polkadot hem de Ethereum Serenity'nin tasarımları bu fikir etrafında şekilleniyor: Hafif düğümlerin blokların mevcut olduğundan makul ölçüde emin olmaları için bir yol sağlar. Ethereum Serenity yaklaşımının ayrıntılı açıklaması [2]'da bulunmaktadır.2.5.3 Polkadot'nin veri kullanılabilirliğine yaklaşımı Polkadot'de, çoğu parçalı çözümde olduğu gibi, her parça (parachain olarak adlandırılır) bloklarının anlık görüntüsünü işaret zincirine (aktarma zinciri olarak adlandırılır) alır. Diyelim ki 2f + 1 var Aktarma zincirinde validators. Parachain bloklarının blok üreticileri, harmanlayıcılar, parachain bloğu üretildiğinde, herhangi bir f parçası yeterli olacak şekilde 2f +1 parçadan oluşan bloğun silme kodlu versiyonunu hesaplarlar. bloğu yeniden inşa etmek için. Daha sonra her validator'e bir parça dağıtırlar. röle zinciri. Belirli bir geçiş zinciri validator yalnızca bir geçiş zincirinde imza atar anlık görüntüsü alınan her parachain bloğu için kendi paylarına sahiplerse bloklayın böyle bir röle zinciri bloğu. Dolayısıyla, eğer bir aktarma zinciri bloğu 2f + 1'den imzalara sahipse validators ve bunlardan en fazla f tanesi protokolü ihlal etmediği sürece, her biri parachain bloğu validators'den parçalar alınarak yeniden oluşturulabilir protokolü takip edenler. Bkz. şekil 15. Şekil 15: Polkadot'nin veri kullanılabilirliği 2.5.4 Uzun vadeli veri kullanılabilirliği Yukarıda tartışılan tüm yaklaşımların yalnızca bir bloğun olduğu gerçeğini doğruladığını unutmayın. yayınlandı ve şu anda mevcut. Bloklar daha sonra kullanılamayabilir çeşitli nedenlerden dolayı: düğümlerin devre dışı kalması, düğümlerin kasıtlı olarak geçmişi silmesi veriler ve diğerleri. Bu sorunu ele alan bahsetmeye değer bir teknik inceleme Polyshard [3]'dir, birden fazla parça olsa bile blokların parçalar arasında kullanılabilir olmasını sağlamak için silme kodlarını kullanan Parçalar verilerini tamamen kaybeder. Ne yazık ki onların özel yaklaşımı şunu gerektirir: diğer tüm parçalardan blok indirmek için tüm parçalar, bu da yasaklayıcı bir şekilde pahalı. Uzun vadeli kullanılabilirlik o kadar acil bir sorun değil: hiçbir katılımcı olmadığı için Sistemin tüm zincirlerdeki tüm zincirleri doğrulayabilmesi bekleniyor.
Parçalanmış protokollerin güvenliğinin böyle bir şekilde tasarlanması gerekir. bazı parçalardaki bazı eski bloklar bozulsa bile sistemin güvenli kalmasının bir yolu tamamen kullanılamaz.
Nightshade
3.1 Von Splitterketten bis hin zu Splitterbrocken Das Sharding-Modell mit Shard-Ketten und einer Beacon-Kette ist jedoch sehr leistungsfähig hat gewisse Komplexitäten. Insbesondere muss die Fork-Choice-Regel ausgeführt werden in jeder Kette separat, die Fork-Choice-Regel in den Shard-Ketten und das Beacon Die Kette muss unterschiedlich aufgebaut und separat getestet werden. In Nightshade modellieren wir das System als ein einzelnes blockchain, in dem jedes Der Block enthält logisch alle Transaktionen für alle Shards und ändert die Gesamtzustand aller Scherben. Physisch lädt jedoch kein Teilnehmer das herunter Vollständiger Zustand oder vollständiger logischer Block. Stattdessen nur jeder Teilnehmer des Netzwerks behält den Zustand bei, der den Shards entspricht, für die sie Transaktionen validieren, und die Liste aller Transaktionen im Block wird in physische Transaktionen aufgeteilt Chunks, ein Chunk pro Shard. Unter idealen Bedingungen enthält jeder Block genau einen Chunk pro Shard Block, der in etwa dem Modell mit Shard-Ketten entspricht, in dem die Shard-Ketten produzieren Blöcke mit der gleichen Geschwindigkeit wie die Beacon-Kette. Allerdings Aufgrund von Netzwerkverzögerungen könnten einige Chunks fehlen, also in der Praxis jeder Block enthält entweder einen oder keinen Chunk pro Shard. Einzelheiten dazu finden Sie in Abschnitt 3.3 Blöcke entstehen. Abbildung 16: Ein Modell mit Splitterketten auf der linken Seite und mit einer Kette auf der linken Seite Auf der rechten Seite sind die Blöcke in Stücke aufgeteilt
3.2 Konsens Die beiden vorherrschenden Konsensansätze in den blockchains sind heute die längste (oder schwerste) Kette, in der die Kette die meiste Arbeit oder den größten Anteil hat Es gilt als kanonisch, um es zu erstellen, und BFT, in dem für jeden Block einige Satz von validators erreichen einen BFT Konsens. In den kürzlich vorgeschlagenen Protokollen ist letzterer ein dominanterer Ansatz. da es sofortige Endgültigkeit bietet, während in der längsten Kette mehr Blöcke benötigt werden auf dem Block aufgebaut werden, um die Endgültigkeit zu gewährleisten. Oftmals für eine sinnvolle Sicherheit: Die Zeit, die benötigt wird, um eine ausreichende Anzahl von Blöcken zu erstellen, nimmt auf Reihenfolge der Stunden. Die Verwendung des BFT-Konsenses für jeden Block hat auch Nachteile, wie zum Beispiel: 1. BFT Konsens erfordert einen erheblichen Kommunikationsaufwand. Während Die jüngsten Fortschritte ermöglichen es, den Konsens in linearer Zeit in Zahlen zu erreichen der Teilnehmer (siehe z. B. [4]), ist der Overhead pro Block immer noch spürbar; 2. Es ist nicht möglich, dass alle Netzwerkteilnehmer am BFT teilnehmen. Konsens pro Block, daher erreicht normalerweise nur eine zufällig ausgewählte Teilmenge der Teilnehmer den Konsens. Eine zufällig ausgewählte Menge kann im Prinzip sein: adaptiv korrumpiert, und theoretisch kann eine Abzweigung erstellt werden. Das System Beides muss modelliert werden, um für ein solches Ereignis bereit zu sein, und somit still haben neben dem BFT-Konsens eine Fork-Choice-Regel oder sind so konzipiert, dass sie geschlossen werden in einem solchen Fall niedergeschlagen. Es ist erwähnenswert, dass einige Designs, wie z Algorand [5], reduzieren die Wahrscheinlichkeit einer adaptiven Korruption erheblich. 3. Am wichtigsten ist, dass das System blockiert, wenn 1 3 oder mehr aller Teilnehmer sind offline. Daher kann jeder vorübergehende Netzwerkfehler oder eine Netzwerkaufteilung das System vollständig zum Stillstand bringen. Im Idealfall muss das System weiterhin in der Lage sein funktionieren, solange mindestens die Hälfte der Teilnehmer online ist (am schwersten). Kettenbasierte Protokolle funktionieren auch dann weiter, wenn weniger als die Hälfte der Teilnehmer online ist, aber die Zweckmäßigkeit dieser Eigenschaft ist umstrittener innerhalb der Gemeinschaft). Ein Hybridmodell, bei dem der verwendete Konsens am stärksten ist Kette, aber einige Blöcke werden regelmäßig mit einem BFT Finalitäts-Gadget finalisiert, um die Vorteile beider Modelle beizubehalten. Solche BFT Endgültigkeits-Gadgets sind Casper FFG [6] verwendet in Ethereum 2.0 8, Casper CBC (siehe https://vitalik. ca/general/2018/12/05/cbc_casper.html) und GRANDPA (siehe https:// medium.com/polkadot-network/d08a24a021b5) verwendet in Polkadot. Nightshade verwendet den stärksten Kettenkonsens. Insbesondere wenn ein Block Der Produzent erzeugt einen Block (siehe Abschnitt 3.3), von dem er Signaturen sammeln kann andere Blockproduzenten und validators, die den vorherigen Block bestätigen. Siehe Abschnitt 3.8 für Einzelheiten, wie eine so große Anzahl von Signaturen aggregiert wird. Das Gewicht 8Sehen Sie sich auch die Whiteboard-Sitzung mit Justin Drake an, um einen detaillierten Überblick über Casper zu erhalten FFG und wie es in den GHOST-Konsens über die schwerste Kette integriert ist, finden Sie hier: https://www. youtube.com/watch?v=S262StTwkmoeines Blocks ist dann der kumulative Einsatz aller Unterzeichner, deren Unterschriften vorhanden sind im Block enthalten. Das Gewicht einer Kette ist die Summe der Blockgewichte. Zusätzlich zum schwersten Kettenkonsens verwenden wir ein Finalitäts-Gadget, das verwendet die Bescheinigungen zur Fertigstellung der Blöcke. Um die Komplexität des Systems zu reduzieren, Wir verwenden ein Finalitäts-Gadget, das die Fork-Choice-Regel in keiner Weise beeinflusst. und führt stattdessen nur zusätzliche Slashing-Bedingungen ein, so dass einmal ein Block vorhanden ist Durch das Finalitäts-Gadget finalisiert, ist eine Abzweigung unmöglich, es sei denn, es handelt sich um einen sehr großen Prozentsatz des Gesamteinsatzes wird gekürzt. Casper CBC ist so ein Endgültigkeits-Gadget, und wir derzeit Modell mit Blick auf Casper CBC. Wir arbeiten auch an einem separaten BFT-Protokoll namens TxFlow. Zur Zeit von Beim Schreiben dieses Dokuments ist unklar, ob TxFlow anstelle von Casper verwendet wird CBC. Wir stellen jedoch fest, dass die Wahl des Endgültigkeits-Gadgets weitgehend orthogonal zum Rest des Designs ist. 3.3 Blockproduktion In Nightshade gibt es zwei Rollen: Blockproduzenten und validators. Auf jeden Fall Punkt enthält das System w Blockproduzenten, w = 100 in unseren Modellen und wv validators, in unserem Modell v = 100, wv = 10.000. Das System ist Proof-of-Stake, Dies bedeutet, dass sowohl Blockproduzenten als auch validators über eine gewisse Anzahl interner verfügen Währung (bezeichnet als „tokens“) für einen Zeitraum gesperrt, der weit über den hinausgeht Zeit, die sie mit der Erfüllung ihrer Aufgaben zum Aufbau und zur Validierung der Kette verbringen. Wie bei allen Proof-of-Stake-Systemen sind nicht alle W-Blockproduzenten und nicht Alle wv validators sind unterschiedliche Entitäten, da dies nicht erzwungen werden kann. Jeder der w-Blockproduzenten und die wv validators haben jedoch eine separate Pfahl. Das System enthält n Shards, in unserem Modell ist n = 1000. Wie erwähnt in Abschnitt 3.1: In Nightshade gibt es keine Shard-Ketten, stattdessen erstellen alle Blockproduzenten und validators ein einziges blockchain, das wir als das bezeichnen Hauptkette. Der Zustand der Hauptkette ist in n Shards und jeden Block aufgeteilt Produzent und validator haben zu jedem Zeitpunkt nur eine Teilmenge von lokal heruntergeladen der Zustand, der einer Teilmenge der Shards entspricht, und nur verarbeiten und Validierung von Transaktionen, die diese Teile des Staates betreffen. Um ein Blockproduzent zu werden, sperrt ein Teilnehmer des Netzwerks einige große Blöcke Betrag von tokens (ein Einsatz). Die Wartung des Netzwerks erfolgt in Epochen, wobei eine Epoche ein Zeitraum in der Größenordnung von Tagen ist. Die Teilnehmer mit den w größten Einsätzen zu Beginn einer bestimmten Epoche sind der Block Produzenten für diese Epoche. Jedem Blockproduzenten sind SW-Shards zugewiesen (z. B sw = 40, was sww/n = 4 Blockproduzenten pro Shard ergeben würde. Der Block Der Produzent lädt den Status des Shards herunter, dem er vor der Epoche zugewiesen ist beginnt und sammelt im Laufe der Epoche Transaktionen, die sich auf diesen Shard auswirken. und wendet sie auf den Staat an. Für jeden Block b in der Hauptkette und für jeden Shard s gibt es einen davon s Blockproduzenten zugewiesen, die für die Produktion des Teils von b verantwortlich sind zur Scherbe. Der Teil von b, der sich auf Shard s bezieht, wird als Chunk bezeichnet und enthält die Liste der Transaktionen für den Shard, die in b aufgenommen werden sollen, sowie das MerkleWurzel des resultierenden Zustands. b wird letztendlich nur einen sehr kleinen Header von enthalten der Chunk, nämlich die Merkle-Wurzel aller angewendeten Transaktionen (siehe Abschnitt 3.7.1 für genaue Details) und die Merkle-Wurzel des Endzustands. Im weiteren Verlauf des Dokuments beziehen wir uns häufig auf den Blockproduzenten Das ist dafür verantwortlich, zu einem bestimmten Zeitpunkt einen Chunk für einen bestimmten Shard zu produzieren als Chunk-Produzent. Der Chunk-Produzent ist immer einer der Blockproduzenten. Die Blockproduzenten und die Chunk-Produzenten rotieren jeden Block entsprechend nach einem festen Zeitplan. Die Blockproduzenten haben einen Auftrag und produzieren wiederholt Blöcke in dieser Reihenfolge. Z.B. wenn es 100 Blockproduzenten gibt, der erste Block Der Hersteller ist für die Produktion der Blöcke 1, 101, 201 usw. verantwortlich, der zweite verantwortlich für die Produktion von 2, 102, 202 usw.). Da die Chunk-Produktion im Gegensatz zur Blockproduktion eine Wartung erfordert den Status, und für jeden Shard behalten nur sww/n-Blockproduzenten den Status bei Pro Shard rotieren dementsprechend nur die SWW/N-Blockproduzenten, um sie zu erstellen Brocken. Z.B. mit den oben genannten Konstanten mit vier zugewiesenen Blockproduzenten Jeder Shard und jeder Blockproduzent erstellt alle vier Blöcke einmal Chunks. 3.4 Sicherstellung der Datenverfügbarkeit Um die Datenverfügbarkeit sicherzustellen, verwenden wir einen ähnlichen Ansatz wie Polkadot beschrieben in Abschnitt 2.5.3. Sobald ein Blockproduzent einen Block produziert, erstellt er ihn eine löschcodierte Version davon mit einem optimalen (w, ⌊w/6 + 1⌋) Blockcode des Brocken. Anschließend senden sie einen Teil des löschcodierten Blocks (wir nennen solche Teile). Chunk-Teile oder nur Teile) an jeden Blockproduzenten. Wir berechnen einen Merkle-Baum, der alle Teile wie die Blätter und die enthält Der Header jedes Blocks enthält die Merkle-Wurzel dieses Baums. Die Teile werden über Onepart-Nachrichten an die validators gesendet. Jede solche Nachricht enthält den Chunk-Header, die Ordnungszahl des Teils und den Teilinhalt. Die Die Nachricht enthält auch die Signatur des Blockproduzenten, der sie erstellt hat Chunk und den Merkle-Pfad, um zu beweisen, dass der Teil dem Header entspricht und wird vom richtigen Blockproduzenten produziert. Sobald ein Blockproduzent einen Hauptkettenblock erhält, prüft er zunächst, ob dies der Fall ist Für jeden im Block enthaltenen Block gibt es einteilige Nachrichten. Wenn nicht, die Sperre wird erst verarbeitet, wenn die fehlenden Onepart-Nachrichten abgerufen wurden. Sobald alle einteiligen Nachrichten empfangen wurden, ruft der Blockproduzent die ab Die restlichen Teile werden von den Peers abgezogen und die Chunks rekonstruiert, die sie enthalten der Staat. Der Blockproduzent verarbeitet keinen Hauptkettenblock, wenn es sich um mindestens einen handelt Wenn ein im Block enthaltener Chunk nicht über die entsprechende Onepart-Nachricht verfügt, oder wenn für mindestens einen Shard, für den sie den Status aufrechterhalten, dies nicht der Fall ist den gesamten Block rekonstruieren. Damit ein bestimmter Block verfügbar ist, reicht es aus, dass ⌊w/6⌋+1 des Blocks Produzenten haben ihre Teile und bedienen sie. Also solange die Zahl der böswillige Akteure überschreiten nicht ⌊w/3⌋keine Kette, die mehr als einen halben Block hat Hersteller, die es bauen, können nicht verfügbare Teile haben.Abbildung 17: Jeder Block enthält einen oder keinen Chunk pro Shard und jeden Chunk ist löschcodiert. Jeder Teil des löschcodierten Blocks wird an eine bestimmte Adresse gesendet Blockproduzent über eine spezielle Onepart-Nachricht 3.4.1 Umgang mit faulen Blockproduzenten Wenn ein Blockproduzent einen Block hat, für den eine Onepart-Nachricht fehlt, wird er Vielleicht entscheiden Sie sich trotzdem dafür, ihn zu signieren, denn wenn der Block am Ende in der Kette landet, ist er es maximiert die Belohnung für den Blockproduzenten. Für den Block besteht kein Risiko Der Blockproduzent war nicht der einzige Blockproduzent, da es später unmöglich ist, zu beweisen, dass der Blockproduzent ihn nicht hatte die einteilige Nachricht. Um dies zu beheben, machen wir jeden Chunk zum Produzenten, wenn wir den Chunk erstellen Wählen Sie eine Farbe (Rot oder Blau) für jeden Teil des zukünftigen codierten Blocks und speichern Sie ihn die Bitmaske der zugewiesenen Farbe im Block, bevor er codiert wird. Jeweils ein Teil Die Nachricht enthält dann die dem Teil zugewiesene Farbe, und die Farbe wird verwendet, wenn Berechnen der Merkle-Wurzel der codierten Teile. Wenn der Chunk-Produzent abweicht Aus dem Protokoll lässt sich dies leicht beweisen, da dies bei der Merkle-Wurzel nicht der Fall ist entsprechen einteiligen Nachrichten oder den Farben in den einteiligen Nachrichten die der Merkle-Wurzel entsprechen, stimmt nicht mit der Maske im Block überein. Wenn ein Blockproduzent einen Block anmeldet, fügt er eine Bitmaske aller Blöcke hinzu rote Teile erhielten sie für die im Block enthaltenen Chunks. Veröffentlichung einer Eine falsche Bitmaske ist ein streichbares Verhalten. Wenn ein Blockproduzent keine erhalten hat Bei einer einzelnen Nachricht haben sie keine Möglichkeit, die Farbe der Nachricht zu kennen, und Daher besteht eine Wahrscheinlichkeit von 50 %, dass sie gekürzt werden, wenn sie versuchen, das Dokument blind zu unterschreiben blockieren. 3.5 Antrag auf Staatsübergang Die Chunk-Produzenten wählen lediglich aus, welche Transaktionen in den Chunk aufgenommen werden sollen Wenden Sie den Zustandsübergang nicht an, wenn sie einen Block erzeugen. Dementsprechend
Der Chunk-Header enthält die Merkle-Wurzel des merkelisierten Zustands wie zuvor Die Transaktionen im Block werden angewendet. Die Transaktionen werden nur angewendet, wenn ein vollständiger Block den Block enthält verarbeitet wird. Ein Teilnehmer bearbeitet einen Block nur, wenn 1. Der vorherige Block wurde empfangen und verarbeitet; 2. Für jeden Block behält der Teilnehmer nicht den Status bei, den er hat habe die einteilige Nachricht gesehen; 3. Für jeden Block behält der Teilnehmer den Status bei, den er hat volles Stück. Sobald der Block verarbeitet wird, für jeden Shard, für den der Teilnehmer zuständig ist behält den Zustand bei, wendet die Transaktionen an und berechnet den neuen Zustand ab dem Zeitpunkt, an dem die Transaktionen angewendet wurden, und sind danach zur Produktion bereit die Chunks für den nächsten Block, wenn sie einem Shard zugewiesen sind, da sie dies getan haben die Merkle-Wurzel des neuen merkelisierten Staates. 3.6 Shardübergreifende Transaktionen und Belege Wenn eine Transaktion mehr als einen Shard betreffen muss, muss sie nacheinander erfolgen wird in jedem Shard separat ausgeführt. Die vollständige Transaktion wird an den ersten Shard gesendet betroffen, und sobald die Transaktion im Chunk für diesen Shard enthalten ist, und Wird angewendet, nachdem der Block in einen Block eingefügt wurde, wird eine sogenannte Quittung generiert Transaktion, die an den nächsten Shard weitergeleitet wird, in dem die Transaktion ausgeführt werden muss ausgeführt werden. Wenn weitere Schritte erforderlich sind, erfolgt die Ausführung der Empfangstransaktion generiert eine neue Belegtransaktion und so weiter. 3.6.1 Lebensdauer der Quittungstransaktion Es ist wünschenswert, dass die Empfangstransaktion in dem Block angewendet wird, der unmittelbar auf den Block folgt, in dem sie generiert wurde. Die Quittungstransaktion ist nur generiert, nachdem der vorherige Block empfangen und von Blockproduzenten angewendet wurde die den ursprünglichen Shard verwalten und zum Zeitpunkt des bekannt sein müssen Der Block für den nächsten Block wird von den Blockproduzenten des Ziels erstellt Scherbe. Daher muss der Empfang vom Quell-Shard an den übermittelt werden Ziel-Shard in dem kurzen Zeitrahmen zwischen diesen beiden Ereignissen. Sei A der zuletzt produzierte Block, der eine Transaktion t enthält, die eine Quittung r generiert. Sei B der nächste produzierte Block (d. h. ein Block, der A als hat). sein vorheriger Block), den wir r enthalten wollen. Lass es in der Scherbe a und r sein in der Scherbe b. Die Lebensdauer des Belegs, ebenfalls in Abbildung 18 dargestellt, ist wie folgt: Erstellen und Aufbewahren der Belege. Der Chunk-Produzenten-CPA für Shard a empfängt den Block A, wendet die Transaktion t an und generiert die Quittung r. cpa Anschließend speichert es alle derart erstellten Belege in seinem indizierten internen persistenten Speicher nach der Quell-Shard-ID.Verteilen der Quittungen. Sobald CPA bereit ist, den Chunk zu produzieren Wenn Sie Shard a für Block B verwenden, rufen sie alle Belege ab, die durch die Anwendung der Transaktionen von Block A für Shard a generiert wurden, und fügen sie in den Block für Shrad ein a in Block B. Sobald ein solcher Block generiert ist, erzeugt cpa seinen Löschcode Version und alle zugehörigen Onepart-Nachrichten. cpa weiß, welche Blockproduzenten den vollständigen Status für welche Shards beibehalten. Für einen bestimmten Blockproduzenten bp cpa umfasst die Einnahmen, die aus der Anwendung von Transaktionen in Block A resultierten für Shard a, der einen der Shards hat, die bp als Ziel interessieren in der einteiligen Nachricht, als sie den Block für Shard a in Block B verteilten (siehe Abbildung 17, die die in der Onepart-Nachricht enthaltenen Quittungen zeigt). Erhalt der Quittungen. Denken Sie daran, dass die Teilnehmer (sowohl Blockproduzenten als auch validators) Blöcke erst verarbeiten, wenn sie einteilige Nachrichten haben für jeden im Block enthaltenen Block. Wenn also ein bestimmter Teilnehmer den Block B anwendet, verfügt er über alle entsprechenden Onepart-Nachrichten Chunks in B, und somit verfügen sie über alle eingehenden Belege, die die Shards enthalten Der Teilnehmer behält den Status als Ziel bei. Bei der Anwendung der Beim Zustandsübergang für einen bestimmten Shard wendet der Teilnehmer beide Quittungen an dass sie für den Shard in den Onepart-Nachrichten sowie allen gesammelt haben die im Chunk selbst enthaltenen Transaktionen. Abbildung 18: Die Lebensdauer einer Empfangstransaktion 3.6.2 Umgang mit zu vielen Belegen Es ist möglich, dass die Anzahl der Belege, die auf einen bestimmten Shard in einem abzielen Ein bestimmter Block ist zu groß, um verarbeitet zu werden. Betrachten Sie zum Beispiel Abbildung 19, in wobei jede Transaktion in jedem Shard eine Quittung generiert, die auf Shard 1 abzielt. Bis zum nächsten Block beträgt die Anzahl der Belege, die Shard 1 verarbeiten muss vergleichbar mit der Last, die alle Scherben zusammen während der Handhabung verarbeitet haben den vorherigen Block.
Abbildung 19: Wenn alle Belege auf denselben Shard abzielen, ist dies möglicherweise nicht der Fall die Fähigkeit, sie zu verarbeiten Um dieses Problem anzugehen, verwenden wir eine Technik, die der in QuarkChain 9 verwendeten ähnelt. Konkret gilt für jeden Shard der letzte Block B und der letzte Shard darin Es wird der Block erfasst, aus dem die Belege übernommen wurden. Wenn der neue Shard ist erstellt, die Quittung wird in der Reihenfolge zuerst aus den verbleibenden Shards in B angewendet, und dann in Blöcken, die auf B folgen, bis der neue Block voll ist. Unter normal Bei ausgeglichener Belastung kommt es in der Regel zu allen Einnahmen angewendet wird (und somit wird der letzte Shard des letzten Blocks aufgezeichnet jedes Stück), aber zu Zeiten, in denen die Last nicht ausgeglichen ist, und ein bestimmtes Da Shard überproportional viele Belege erhält, ist dies mit dieser Technik möglich unter Einhaltung der Beschränkungen für die Anzahl der enthaltenen Transaktionen verarbeitet werden. Beachten Sie, dass die Verzögerung abnimmt, wenn eine solche unausgeglichene Belastung über einen längeren Zeitraum anhält Die Belegerstellung bis zur Anwendung kann unbegrenzt weiter wachsen. Eins Eine Möglichkeit, das Problem zu lösen, besteht darin, jede Transaktion zu verwerfen, die eine Quittung für a erstellt Shard, dessen Verarbeitungsverzögerung eine bestimmte Konstante überschreitet (z. B. eine Epoche). Betrachten Sie Abbildung 20. Durch Block B kann der Shard 4 nicht alle Belege verarbeiten. es verarbeitet also nur Quittungsursprünge von bis zu Shard 3 in Block A und zeichnet es auf. In Block C sind die Belege bis Shard 5 in Block B enthalten, und Dann holt der Shard bei Block D auf und verarbeitet alle verbleibenden Belege Block B und alle Belege aus Block C. 3.7 Chunks-Validierung Ein für einen bestimmten Shard erstellter Chunk (oder ein für eine bestimmte Shard-Kette im Modell mit Shard-Ketten erstellter Shard-Block) kann nur von validiert werden 9Sehen Sie sich hier die Whiteboard-Folge mit QuarkChain an: https://www.youtube.com/watch? v=opEtG6NM4x4, in dem unter anderem der Ansatz für Cross-Shard-Transaktionen diskutiert wird DingeAbbildung 20: Verzögerte Belegverarbeitung Teilnehmer, die den Staat aufrechterhalten. Sie können Blockproduzenten sein, validators, oder nur externe Zeugen, die den Status heruntergeladen und den Shard darin validiert haben in dem sie Vermögenswerte speichern. In diesem Dokument gehen wir davon aus, dass die Mehrheit der Teilnehmer nicht speichern kann der Staat für einen großen Teil der Scherben. Es ist jedoch erwähnenswert, dass es Shard-blockchains gibt, die unter der Annahme entworfen wurden, dass Die meisten Teilnehmer verfügen über die Kapazität, den Zustand zu speichern und die meisten davon zu validieren die Shards, wie zum Beispiel QuarkChain. Da nur ein Bruchteil der Teilnehmer den Status hat, den Shard zu validieren Chunks ist es möglich, adaptiv nur die Teilnehmer zu korrumpieren, die das haben Zustand ändern und einen ungültigen Zustandsübergang anwenden. Es wurden mehrere Sharding-Designs vorgeschlagen, die alle paar validators abtasten Tage und innerhalb eines Tages jeder Block in der Shard-Kette, der mehr als 2/3 hat der diesem Shard zugewiesenen Signaturen der validators werden sofort berücksichtigt endgültig. Mit einem solchen Ansatz muss ein adaptiver Gegner nur 2n/3+1 korrumpieren der validators in einer Shard-Kette, um einen ungültigen Zustandsübergang anzuwenden, der, Auch wenn es wahrscheinlich schwer zu bewerkstelligen ist, ist das Sicherheitsniveau für die Öffentlichkeit nicht ausreichend blockchain. Wie in Abschnitt 2.3 besprochen, besteht der übliche Ansatz darin, nach der Erstellung eines Blocks für jeden Teilnehmer, der über den Status (ob) verfügt, ein bestimmtes Zeitfenster einzuräumen es ist ein Blockproduzent, ein validator oder ein externer Beobachter), um seine Gültigkeit in Frage zu stellen. Solche Teilnehmer werden Fischer genannt. Damit ein Fischer es kann Um einen ungültigen Block anzufechten, muss sichergestellt werden, dass ein solcher Block verfügbar ist sie. Die Datenverfügbarkeit in Nightshade wird in Abschnitt 3.4 erläutert. Sobald in Nightshade ein Block erstellt wurde, wurden die Chunks nicht validiert irgendjemand außer dem eigentlichen Chunk-Produzenten. Insbesondere der Blockproduzent schlug vor, dass der Block natürlich nicht den Status für die meisten Shards hatte, undkonnte die Chunks nicht validieren. Wenn der nächste Block produziert wird, enthält er Attestierungen (siehe Abschnitt 3.2) mehrerer Blockproduzenten und validators, aber da die Mehrheit der Blockproduzenten und validators den Status nicht aufrechterhalten Auch bei den meisten Shards sammelt ein Block mit nur einem ungültigen Chunk deutlich mehr als die Hälfte der Attestierungen und bleibt weiterhin am schwersten Kette. Um dieses Problem zu beheben, gestatten wir jedem Teilnehmer, den Status von beizubehalten Ein Shard, um in der Kette eine Herausforderung für jeden darin erzeugten ungültigen Chunk einzureichen Scherbe. 3.7.1 Staatliche Gültigkeitsherausforderung Sobald ein Teilnehmer feststellt, dass ein bestimmter Block ungültig ist, muss er einen Beweis dafür erbringen, dass der Block ungültig ist. Da die Mehrheit der Netzwerkteilnehmer den Zustand für den Shard, in dem sich der ungültige Chunk befindet, nicht aufrechterhalten Wenn der Beweis erstellt wird, muss er über ausreichende Informationen verfügen, um den Block zu bestätigen ungültig, ohne den Staat zu haben. Wir legen einen Grenzwert Ls für die Statusmenge (in Bytes) fest, die eine einzelne Transaktion umfasst kann kumulativ lesen oder schreiben. Jede Transaktion, die mehr als Ls berührt Zustand gilt als ungültig. Erinnern Sie sich aus Abschnitt 3.5 daran, dass der Chunk In einem bestimmten Block enthält B nur die anzuwendenden Transaktionen, jedoch nicht die neue Staatswurzel. Der im Block in Block B enthaltene Statusstamm ist der Status root, bevor Sie solche Transaktionen anwenden, aber nachdem Sie die Transaktionen angewendet haben der letzte Block im selben Shard vor dem Block B. Ein böswilliger Akteur Der Wunsch, einen ungültigen Zustandsübergang anzuwenden, würde einen falschen Zustandsstamm beinhalten in Block B entspricht das nicht der Zustandswurzel, die sich aus der Anwendung ergibt die Transaktionen im vorherigen Block. Wir erweitern die Informationen, die ein Chunk-Produzent in den Chunk einfügt. Anstatt nur den Status einzubeziehen, nachdem alle Transaktionen angewendet wurden, wird dieser stattdessen angezeigt Enthält eine Statuswurzel, nachdem jeder zusammenhängende Satz von Transaktionen angewendet wurde Lesen und schreiben Sie gemeinsam Ls Zustandsbytes. Mit diesen Informationen für die Fischer stellt eine Herausforderung dar, dass ein Zustandsübergang falsch angewendet wird reicht aus, um den ersten solchen ungültigen Zustandsstamm zu finden, und umfasst nur Ls Bytes davon Staaten, die von den Transaktionen zwischen dem letzten Stammstaat (der war) betroffen sind gültig) und die aktuelle Statuswurzel mit den Merkle-Beweisen. Dann jeder Teilnehmer kann die Transaktionen im Segment validieren und bestätigen, dass der Block vorhanden ist ungültig. Das Gleiche gilt, wenn der Blockproduzent versucht hat, lesende Transaktionen einzuschließen und mehr als Ls Statusbytes schreiben, für die Herausforderung reicht es aus, sie einzuschließen Die ersten Ls-Bytes berührt es mit den Merkle-Beweisen, was ausreichen wird Wenden Sie die Transaktionen an und bestätigen Sie, dass es einen Moment gibt, in dem ein Versuch dazu erfolgt Das Lesen oder Schreiben von Inhalten über Ls Bytes hinaus erfolgt.
3.7.2 Fischer und schnelle Cross-Shard-Transaktionen Wie in Abschnitt 2.3 besprochen, nehmen wir einmal an, dass die Shard-Chunks (oder Shard Blöcke im Modell mit Shard-Ketten) können ungültig sein und eine Herausforderung darstellen Dies wirkt sich negativ auf die Endgültigkeit und damit auf die Shard-übergreifende Kommunikation aus. In Insbesondere kann der Ziel-Shard einer Cross-Shard-Transaktion nicht sicher sein Der ursprüngliche Shard-Block oder -Block ist endgültig, bis der Herausforderungszeitraum abgelaufen ist (siehe Abbildung 21). Abbildung 21: Warten Sie den Herausforderungszeitraum ab, bevor Sie eine Quittung beantragen Die Art und Weise, es so anzugehen, dass die Cross-Shard-Transaktionen möglich sind Instantenious bedeutet, dass der Ziel-Shard nicht auf den Herausforderungszeitraum warten muss Nachdem die Quell-Shard-Transaktion veröffentlicht wurde, wenden Sie die Empfangstransaktion an sofort ausführen, aber dann den Ziel-Shard zusammen mit der Quelle zurücksetzen Shard, wenn sich später herausstellt, dass der ursprüngliche Chunk oder Block ungültig ist (siehe Abbildung). 22). Dies gilt ganz natürlich für das Nightshade-Design, in dem die Scherbe enthalten ist Ketten sind nicht unabhängig, stattdessen werden alle Shard-Blöcke veröffentlicht zusammen im selben Hauptkettenblock. Wenn sich herausstellt, dass ein Block ungültig ist, wird der Der gesamte Block mit diesem Block wird als ungültig betrachtet, ebenso alle darauf aufbauenden Blöcke oben drauf. Siehe Abbildung 23. Beide oben genannten Ansätze bieten Atomizität unter der Annahme, dass die Herausforderung besteht Der Zeitraum ist ausreichend lang. Wir verwenden den letzteren Ansatz, da die Bereitstellung schneller Cross-Shard-Transaktionen unter normalen Umständen die Unannehmlichkeiten überwiegt Der Ziel-Shard wird aufgrund eines ungültigen Zustandsübergangs in einem von ihnen zurückgesetzt die Quellsplitter, was ein äußerst seltenes Ereignis ist. 3.7.3 validators werden ausgeblendet Das Vorhandensein der Herausforderungen verringert bereits die Wahrscheinlichkeit erheblich Adaptive Korruption, da ein Block mit einem ungültigen Zustandsübergangsposten abgeschlossen werden mussAbbildung 22: Belege sofort anwenden und das Ziel zurücksetzen Kette, wenn die Quellkette einen ungültigen Block hatte Abbildung 23: Fischer-Herausforderung in Nightshade Der Herausforderungszeitraum, den der adaptive Gegner benötigt, um alle Teilnehmer zu korrumpieren die den Zustand des Shards beibehalten, einschließlich aller validators. Die Wahrscheinlichkeit eines solchen Ereignisses abzuschätzen ist äußerst komplex, da nein sharded blockchain ist schon so lange aktiv, dass ein solcher Angriff versucht werden kann. Wir argumentieren, dass die Wahrscheinlichkeit zwar äußerst gering, aber immer noch ausreichend ist groß für ein System, von dem erwartet wird, dass es mehrere Millionen Transaktionen ausführt Führen Sie ein weltweites Finanzgeschäft. Es gibt zwei Hauptgründe für diesen Glauben: 1. Die meisten validators der Proof-of-Stake-Ketten und Miner der
Der Anreiz für Proof-of-Work-Ketten besteht in erster Linie aus finanziellen Vorteilen. Wenn Ein adaptiver Gegner bietet ihnen mehr Geld als die erwartete Rendite Wenn man ehrlich vorgeht, kann man davon ausgehen, dass es viele validators gibt werde das Angebot annehmen. 2. Viele Unternehmen führen die Validierung von Proof-of-Stake-Ketten professionell durch Es wird erwartet, dass ein großer Prozentsatz der Anteile an jeder Kette liegen wird von solchen Einheiten. Die Anzahl solcher Entitäten ist für eine ausreichend klein adaptiver Gegner, um die meisten von ihnen persönlich kennenzulernen und zu haben gutes Verständnis für ihre Neigung, korrumpiert zu werden. Wir gehen einen Schritt weiter, um die Wahrscheinlichkeit der adaptiven Korruption zu verringern, indem wir verbergen, welche validators welchem Shard zugewiesen sind. Die Idee ist entfernt ähnlich der Art und Weise, wie Algorand [5] validators verbirgt. Es ist wichtig zu beachten, dass selbst wenn die validators verborgen sind, wie in Algorand oder wie unten beschrieben, ist die adaptive Korruption theoretisch immer noch möglich. Während Der adaptive Gegner kennt die Teilnehmer nicht, die erstellen oder validieren Ob ein Block oder ein Brocken, die Teilnehmer wissen selbst, dass sie etwas leisten werden eine solche Aufgabe erfüllen und einen kryptografischen Beweis dafür haben. So kann der Gegner Machen Sie ihre Korruptionsabsicht öffentlich und zahlen Sie an jeden Teilnehmer, der dies bereitstellt so ein kryptografischer Beweis. Wir stellen jedoch fest, dass der Gegner dies nicht tut Sie kennen die validators, die dem Shard zugewiesen sind, den sie beschädigen möchten haben keine andere Wahl, als ihre Absicht, einen bestimmten Shard zu beschädigen, zu verbreiten die gesamte Gemeinschaft. An diesem Punkt ist es für jeden Ehrlichen wirtschaftlich vorteilhaft Der Teilnehmer muss einen vollständigen Knoten hochfahren, der diesen Shard validiert, da ein Hoch vorliegt Wahrscheinlichkeit, dass ein ungültiger Block in diesem Shard erscheint, was eine Gelegenheit dazu darstellt Erstellen Sie eine Herausforderung und sammeln Sie die zugehörige Belohnung. Um die validators, die einem bestimmten Shard zugewiesen sind, nicht preiszugeben, tun wir dies Folgendes (siehe Abbildung 24): Verwenden Sie VRF, um die Zuweisung zu erhalten. Zu Beginn jeder Epoche validator verwendet eine VRF, um eine Bitmaske der Shards abzurufen, denen validator zugewiesen ist. Die Bitmaske jedes validator wird Sw-Bits haben (Definition siehe Abschnitt 3.3). von Sw). Der validator ruft dann den Status der entsprechenden Shards ab und Während der Epoche werden für jeden empfangenen Block die entsprechenden Blöcke validiert zu den Shards, denen validator zugewiesen ist. Melden Sie sich in Blöcken statt in Blöcken an. Da die Shard-Zuweisung verborgen ist, kann validator keine Chunks anmelden. Stattdessen wird immer das Ganze unterschrieben blockieren, sodass nicht verraten wird, welche Shards validiert werden. Insbesondere wenn validator einen Block empfängt und alle Blöcke validiert, erstellt er entweder eine Nachricht Dies bestätigt, dass alle Chunks in allen Shards, denen validator zugewiesen ist, vorhanden sind gültig (ohne in irgendeiner Weise anzugeben, um welche Shards es sich handelt) oder eine Nachricht darüber enthält einen Beweis für einen ungültigen Zustandsübergang, wenn ein Block ungültig ist. Siehe die Einzelheiten zur Aggregation solcher Nachrichten finden Sie in Abschnitt 3.8, in Abschnitt 3.7.4 die Details, wie verhindert werden kann, dass validators Nachrichten von huckepack nehmen andere validators und Abschnitt 3.7.5 für Einzelheiten zur Belohnung und Bestrafung validators, falls tatsächlich eine erfolgreiche ungültige Zustandsübergangsherausforderung stattfindet.Abbildung 24: Die validators in Nightshade verbergen 3.7.4 Commit-Reveal Eines der häufigsten Probleme mit validators besteht darin, dass ein validator das Herunterladen des Status und die tatsächliche Validierung der Chunks und Blöcke überspringen kann und stattdessen Beobachten Sie das Netzwerk, sehen Sie, was die anderen validators einreichen, und wiederholen Sie dies Nachrichten. Ein validator, der einer solchen Strategie folgt, bietet keinen Mehrwert Sicherheit für das Netzwerk, kassiert aber Belohnungen. Eine übliche Lösung für dieses Problem besteht darin, für jeden validator einen Beweis bereitzustellen dass sie den Block tatsächlich validiert haben, beispielsweise durch Bereitstellung einer eindeutigen Ablaufverfolgung Die Anwendung des Zustandsübergangs ist zwar nicht möglich, aber solche Nachweise erhöhen die Kosten erheblich der Validierung. Abbildung 25: Commit-Enthüllung
Stattdessen veranlassen wir, dass die validators zuerst auf das Validierungsergebnis übertragen werden (entweder die Nachricht, die die Gültigkeit der Chunks bestätigt, oder der Beweis einer Ungültigkeit Warten Sie einen bestimmten Zeitraum und zeigen Sie erst dann das tatsächliche Validierungsergebnis an, wie in Abbildung 25 dargestellt. Der Festschreibungszeitraum überschneidet sich nicht mit der Enthüllungszeitraum, und daher kann ein fauler validator keine ehrlichen validators kopieren. Darüber hinaus, wenn ein unehrlicher validator sich zu einer Nachricht verpflichtet hat, die dies bestätigt Gültigkeit der zugewiesenen Chunks, und mindestens ein Chunk war ungültig, sobald dies der Fall ist gezeigt, dass der Block ungültig ist, kann validator den Schrägstrich nicht vermeiden, da Wie wir in Abschnitt 3.7.5 zeigen, ist dies der einzige Weg, in einer solchen Situation nicht aufgeschlitzt zu werden besteht darin, eine Nachricht zu präsentieren, die einen Beweis für den ungültigen Zustandsübergang enthält entspricht dem Commit. 3.7.5 Umgang mit Herausforderungen Wie oben erläutert, sobald ein validator einen Block mit einem ungültigen Block empfängt, Sie bereiten zunächst einen Beweis für den ungültigen Zustandsübergang vor (siehe Abschnitt 3.7.1) und dann verpflichten Sie sich zu einem solchen Beweis (siehe 3.7.4) und offenbaren Sie nach einiger Zeit die Herausforderung. Sobald die aufgedeckte Herausforderung in einen Block aufgenommen wird, passiert Folgendes: 1. Alle Zustandsübergänge, die von dem Block aus stattgefunden haben, der die enthält ungültiger Block, bis der Block, in dem die aufgedeckte Herausforderung enthalten ist, abgerufen wird für nichtig erklärt. Der Zustand vor dem Block, der die offenbarte Herausforderung enthält gilt als derselbe wie der Zustand vor dem enthaltenen Block der ungültige Block. 2. Innerhalb einer bestimmten Zeitspanne muss jeder validator seine Bitmaske offenlegen der Shards, die sie validieren. Da die Bitmaske über ein VRF erstellt wird, wenn Sie wurden dem Shard zugewiesen, der den ungültigen Zustandsübergang „they“ hatte kann nicht umhin, es zu enthüllen. Alle validator, bei denen die Bitmaske nicht angezeigt wird Es wird davon ausgegangen, dass es dem Shard zugewiesen ist. 3. Jeder validator, der nach diesem Zeitraum dem Shard zugeordnet ist, das hat zu einem Validierungsergebnis für den Block geführt, der das enthält ungültiger Block und das ergab keinen Beweis für einen ungültigen Zustandsübergang das ihrem Commit entspricht, wird gestrichen. 4. Jeder validator erhält eine neue Shard-Zuweisung und eine neue Epoche wird geplant um nach einiger Zeit zu beginnen, die ausreicht, damit alle validators das herunterladen können Zustand, wie in Abbildung 26 dargestellt. Beachten Sie, dass die validators ab dem Moment die ihnen zugewiesenen Shards offenlegen Bis zum Beginn der neuen Epoche ist die Sicherheit des Systems verringert, da die Die Shard-Zuordnung wird enthüllt. Die Teilnehmer des Netzwerks müssen es behalten Beachten Sie dies bei der Nutzung des Netzwerks in diesem Zeitraum. 3.8 Signaturaggregation Damit ein System mit Hunderten von Shards sicher funktioniert, möchten wir Folgendes haben: Größenordnung von 10.000 oder mehr validators. Wie in Abschnitt 3.7 besprochen, wollen wir jedesAbbildung 26: Die Herausforderung meistern validator um im Durchschnitt ein Commit für eine bestimmte Nachricht und eine Signatur zu veröffentlichen einmal pro Block. Selbst wenn die Commit-Nachrichten gleich wären, wäre eine solche Aggregation möglich BLS-Signatur und deren Validierung wären unerschwinglich teuer gewesen. Aber Natürlich sind die Commit- und Reveal-Nachrichten bei allen validators nicht gleich. und daher brauchen wir eine Möglichkeit, solche Nachrichten und die Signaturen in einem zusammenzufassen Dies ermöglicht eine spätere schnelle Validierung. Der spezifische Ansatz, den wir verwenden, ist der folgende: Validatoren schließen sich Blockproduzenten an. Die Blockproduzenten sind bekannt einige Zeit vor Beginn der Epoche, da sie einige Zeit zum Herunterladen benötigen Zustand vor Beginn der Epoche, und im Gegensatz zu den validators sind es die Blockproduzenten nicht verborgen. Jeder Blockproduzent verfügt über v validator Slots. Validatoren reichen ein Off-Chain-Vorschläge an die Blockproduzenten, als einer ihrer v validators. Wenn ein Blockproduzent einen validator einschließen möchte, reicht er einen ein Transaktion, die die erste Off-Chain-Anfrage von validator enthält, und die Signatur des Blockproduzenten, die dafür sorgt, dass validator dem Blockproduzenten beitritt. Beachten Sie, dass die den Blockproduzenten zugewiesenen validators dies nicht unbedingt tun Validieren Sie dieselben Shards, für die der Blockproduzent Chunks produziert. Wenn ein validator wird angewendet, um mehrere Blockproduzenten zu verbinden, nur die Transaktion von Der erste Blockproduzent wird erfolgreich sein. Blockproduzenten sammeln Commits. Der Blockproduzent sammelt ständig die Commit- und Reveal-Nachrichten von den validators. Sobald eine bestimmte Anzahl solcher Nachrichten angesammelt ist, berechnet der Blockproduzent ein Merkle Baum dieser Nachrichten und sendet an jeden validator die Merkle-Wurzel und die Merkle Weg zu ihrer Botschaft. Der validator validiert den Pfad und meldet sich an die Merkle-Wurzel. Der Blockproduzent sammelt dann eine BLS-Signatur auf dem Merkle Root aus den validators und veröffentlicht nur die Merkle Root und die gesammelte Unterschrift. Der Blockproduzent unterzeichnet auch die Gültigkeit des Multisignatur mit einer günstigen ECDSA-Signatur. Wenn die Multisignatur dies nicht tut Wenn Sie mit dem übermittelten Merkle-Stamm oder der Bitmaske der teilnehmenden validators übereinstimmen, handelt es sich um ein streichbares Verhalten. Beim Synchronisieren der Kette ein Teilnehmer Sie können wählen, ob alle BLS-Signaturen der validators validiert werden sollen (was extrem teuer ist, da die öffentlichen Schlüssel der validators aggregiert werden müssen) oder nurdie ECDMA-Signaturen von den Blockproduzenten und verlassen sich darauf, dass die Der Blockproduzent wurde nicht angefochten und gekürzt. Verwendung von On-Chain-Transaktionen und Merkle-Beweisen für Herausforderungen. Es Es kann festgestellt werden, dass es keinen Wert hat, Nachrichten von validators preiszugeben, wenn nein Es wurde ein ungültiger Zustandsübergang erkannt. Nur die Nachrichten, die das tatsächliche enthalten Beweise für einen ungültigen Zustandsübergang müssen offengelegt werden, und zwar nur für solche Nachrichten Es muss gezeigt werden, dass sie mit dem vorherigen Commit übereinstimmen. Die Nachricht muss zu zwei Zwecken offengelegt werden: 1. Um den Rollback der Kette tatsächlich auf den Moment vor dem einzuleiten ungültiger Zustandsübergang (siehe Abschnitt 3.7.5). 2. Um zu beweisen, dass der validator nicht versucht hat, die Gültigkeit des zu bestätigen Ungültiger Block. In beiden Fällen müssen wir uns mit zwei Problemen befassen: 1. Der eigentliche Commit war nicht in der Kette enthalten, sondern nur die Merkle-Wurzel des Commit aggregiert mit anderen Nachrichten. Der validator muss das verwenden Merkle-Pfad, der vom Blockproduzenten bereitgestellt wird, und dessen ursprüngliches Commit beweisen, dass sie sich der Herausforderung gestellt haben. 2. Es ist möglich, dass alle dem Shard zugewiesenen validators ungültig sind Zustandsübergänge werden zufällig beschädigten Blockproduzenten zugewiesen zensieren sie. Um dies zu umgehen, erlauben wir ihnen, ihre Enthüllungen einzureichen als reguläre Transaktion in der Kette und umgeht die Aggregation. Letzteres ist nur für die Nachweise eines ungültigen Zustandsübergangs zulässig äußerst selten und sollte daher nicht zum Spam der Blöcke führen. Das letzte Problem, das angegangen werden muss, besteht darin, dass die Blockproduzenten dies können sich dafür entscheiden, nicht an der Nachrichtenaggregation teilzunehmen oder bestimmte validators absichtlich zu zensieren. Wir machen es wirtschaftlich unvorteilhaft, indem wir den Block herstellen Produzentenbelohnung proportional zur Anzahl der ihnen zugewiesenen validators. Wir Beachten Sie auch, dass sich die Blockproduzenten zwischen den Epochen weitgehend überschneiden (seit Es sind immer die Top-W-Teilnehmer mit dem höchsten Einsatz), die validators können Bleiben Sie weitgehend bei der Zusammenarbeit mit denselben Blockproduzenten und reduzieren Sie so das Risiko dass sie einem Blockproduzenten zugewiesen wurden, der sie in der Vergangenheit zensiert hat. 3.9 Snapshots-Kette Da die Blöcke in der Hauptkette sehr häufig produziert werden, ist das Herunterladen erforderlich Die vollständige Historie könnte sehr schnell teuer werden. Darüber hinaus seit jedem Block eine BLS-Signatur einer großen Anzahl von Teilnehmern enthält, allein die Aggregation der öffentlichen Schlüssel zur Überprüfung der Signatur könnte unerschwinglich werden auch teuer. Schließlich wird Ethereum 1.0 in absehbarer Zukunft wahrscheinlich einer bleiben einer der am häufigsten verwendeten blockchains und bietet eine sinnvolle Möglichkeit, Vermögenswerte von dort zu übertragen
In der Nähe von Ethereum ist eine Anforderung, und heute ist die Überprüfung von BLS-Signaturen erforderlich, um dies sicherzustellen Die Gültigkeit naher Blöcke auf der Seite von Ethereum ist nicht möglich. Jeder Block in der Nightshade-Hauptkette kann optional einen Schnorr enthalten Multisignatur im Header des letzten Blocks, der einen solchen Schnorr enthielt Multisignatur. Wir nennen solche Blöcke Snapshot-Blöcke. Der allererste Block von Jede Epoche muss ein Snapshot-Block sein. Während ich an einer solchen Multisignatur arbeitete, Die Blockproduzenten müssen auch die BLS-Signaturen der validators sammeln auf dem letzten Snapshot-Block und aggregieren Sie sie auf die gleiche Weise wie in beschrieben Abschnitt 3.8. Da die Menge der Blockproduzenten während der gesamten Epoche konstant ist, ist eine Validierung erforderlich Nur die ersten Snapshot-Blöcke in jeder Epoche sind ausreichend, vorausgesetzt, dass bei Nr weisen darauf hin, dass ein großer Prozentsatz der Blockproduzenten und validators zusammengearbeitet und erstellt haben eine Gabel. Der erste Block der Epoche muss für die Berechnung ausreichende Informationen enthalten die Blockproduzenten und validators für die Epoche. Wir nennen die Unterkette der Hauptkette, die nur den Snapshot enthält blockiert eine Snapshot-Kette. Das Erstellen einer Schnorr-Multisignatur ist ein interaktiver Prozess, aber da wir Es muss nur selten durchgeführt werden, egal wie ineffizient der Prozess ist wird genügen. Die Schnorr-Multisignaturen können einfach unter Ethereum validiert werden, Dadurch werden entscheidende Grundelemente für eine sichere Durchführung von Cross-blockchain bereitgestellt. Kommunikation. Für die Synchronisierung mit der Near-Kette muss lediglich der gesamte Snapshot heruntergeladen werden blockiert und bestätigt, dass die Schnorr-Signaturen korrekt sind (optional auch Überprüfung der einzelnen BLS-Signaturen der validators) und dann nur die Synchronisierung Hauptkettenblöcke vom letzten Snapshot-Block.
Nightshade
3.1 Parça zincirlerinden parça parçalara Parça zincirleri ve işaret zinciri içeren parçalama modeli çok güçlüdür ancak belirli karmaşıklıklara sahiptir. Özellikle çatal seçim kuralının uygulanması gerekiyor her zincirde ayrı ayrı, parça zincirlerinde ve işaretçide çatal seçim kuralı Zincir farklı şekilde oluşturulmalı ve ayrı olarak test edilmelidir. Nightshade'de sistemi tek bir blockchain olarak modelliyoruz; her biri blok mantıksal olarak tüm parçalar için tüm işlemleri içerir ve tüm parçaların tüm durumu. Ancak fiziksel olarak hiçbir katılımcı dosyayı indirmez. tam durum veya tam mantıksal blok. Bunun yerine, ağın her katılımcısı yalnızca İşlemleri doğruladıkları parçalara karşılık gelen durumu korur ve bloktaki tüm işlemlerin listesi fiziksel olarak bölünmüştür parçalar, parça başına bir parça. İdeal koşullar altında her blok, parça başına tam olarak bir parça içerir. kabaca parça zincirli modele karşılık gelen blok parça zincirleri işaret zinciriyle aynı hızda bloklar üretir. Ancak, ağ gecikmeleri nedeniyle bazı parçalar eksik olabilir; bu nedenle pratikte her blok parça başına bir veya sıfır parça içerir. Nasıl yapılacağına ilişkin ayrıntılar için bölüm 3.3'e bakın. bloklar üretilir. Şekil 16: Solda parça zincirleri ve tek zinciri olan bir model bloklar sağ tarafta parçalara bölünmüş
3.2 Konsensüs Bugün blockchain'lerde fikir birliğine yönelik iki baskın yaklaşım şunlardır: En fazla işe veya hisseye sahip olan zincirin en uzun (veya en ağır) zincir oluşturmak için kullanılan kurallı kabul edilir ve BFT, burada her blok için bazı validator kümesi BFT fikir birliğine ulaştı. Son zamanlarda önerilen protokollerde ikincisi daha baskın bir yaklaşımdır, anında kesinlik sağladığından, en uzun zincirde daha fazla bloğa ihtiyaç duyulurken Kesinliği sağlamak için bloğun üzerine inşa edilecek. Çoğu zaman anlamlı Yeterli sayıda bloğun inşa edilmesi için gereken süre güvenlik gerektirir. saat sırası. Her blokta BFT fikir birliğini kullanmanın aşağıdaki gibi dezavantajları da vardır: 1. BFT fikir birliği önemli miktarda iletişim gerektirir. iken Son gelişmeler sayıca doğrusal zamanda fikir birliğine varılmasına olanak tanıyor katılımcıların sayısı (bkz. örneğin [4]), blok başına hala fark edilebilir bir yüktür; 2. Tüm ağ katılımcılarının BFT'ya katılması mümkün değildir. Blok başına fikir birliğine varılır, dolayısıyla genellikle yalnızca rastgele örneklenmiş bir katılımcı alt kümesi fikir birliğine varır. Rastgele örneklenmiş bir küme prensip olarak şu şekilde olabilir: uyarlanabilir bir şekilde bozulur ve teoride bir çatal oluşturulabilir. sistem her ikisinin de böyle bir olaya hazır olmak için modellenmesi gerekiyor ve bu nedenle hala BFT fikir birliğinin yanı sıra bir çatal seçeneği kuralına sahip olmak veya kapanacak şekilde tasarlanmış olmak böyle bir olayda aşağı. Bazı tasarımların olduğunu belirtmekte fayda var. Algorand [5], uyarlamalı yolsuzluk olasılığını önemli ölçüde azaltır. 3. En önemlisi şu durumlarda sistem durur: Tüm katılımcıların 3 veya daha fazlası çevrimdışı. Bu nedenle, herhangi bir geçici ağ arızası veya ağ bölünmesi, sistemi tamamen durdurabilir. İdeal olarak sistem devam edebilmelidir katılımcıların en az yarısı çevrimiçi olduğu sürece faaliyet göstermektedir (en yoğun Zincir tabanlı protokoller, katılımcıların yarısından azı çevrimiçi olsa bile çalışmaya devam eder, ancak bu özelliğin arzu edilirliği daha tartışmalıdır topluluk içinde). Kullanılan fikir birliğinin bir tür en ağır olduğu hibrit bir model zincir, ancak bazı bloklar BFT sonlandırma aracı kullanılarak periyodik olarak sonlandırılır ve her iki modelin de avantajları korunur. Bu tür BFT nihai gadget'lar Ethereum 2.0 8'de kullanılan Casper FFG [6], Casper CBC (bkz. https://vitalik.) ca/general/2018/12/05/cbc_casper.html) ve GRANDPA (bkz. https:// Medium.com/polkadot-network/d08a24a021b5) Polkadot'de kullanıldı. Nightshade en ağır zincir konsensüsünü kullanır. Özellikle bir blok Üretici bir blok ürettiğinde (bkz. Bölüm 3.3), imza toplayabilirler. diğer blok üreticileri ve önceki bloğu doğrulayan validator'lar. Bölüme bakın Bu kadar çok sayıda imzanın nasıl toplandığıyla ilgili ayrıntılar için 3.8'e bakınız. Ağırlık 8Ayrıca Casper'a derinlemesine bir genel bakış için Justin Drake ile yapılan beyaz tahta oturumuna bakın FFG ve GHOST en ağır zincir konsensüsüne nasıl entegre edildiği burada: https://www. youtube.com/watch?v=S262StTwkmobir bloğun payı, imzaları imzalanan tüm imzalayanların kümülatif hissesidir. bloğa dahil edilmiştir. Bir zincirin ağırlığı blok ağırlıklarının toplamıdır. En ağır zincir mutabakatının yanı sıra, aşağıdakileri kullanan bir nihai gadget kullanıyoruz: blokları sonlandırmak için onaylar. Sistemin karmaşıklığını azaltmak için, Çatal seçim kuralını hiçbir şekilde etkilemeyen bir sonlandırma aracı kullanıyoruz, ve bunun yerine yalnızca ekstra eğik çizgi koşulları getirir, öyle ki bir blok bir kez Nihai gadget tarafından sonlandırıldığında, çok büyük bir yüzde olmadıkça çatallanma imkansızdır. toplam bahis miktarı kesildi. Casper CBC son derece kaliteli bir cihazdır ve biz şu anda Casper CBC'yi göz önünde bulundurarak model oluşturuyorum. Ayrıca TxFlow adı verilen ayrı bir BFT protokolü üzerinde de çalışıyoruz. O sırada Bu belgeyi yazarken Casper yerine TxFlow'un kullanılıp kullanılmayacağı belli değil CBC. Ancak son cihaz seçiminin büyük ölçüde tasarımın geri kalanına dik olduğunu belirtmeliyiz. 3.3 Blok üretimi Nightshade'de iki rol vardır: blok yapımcıları ve validator'ler. herhangi bir zamanda sistemin w blok üreticilerini içerdiği nokta, modellerimizde w = 100 ve wv validators, modelimizde v = 100, wv = 10, 000. Sistem Proof-of-Stake'tir, bu, hem blok üreticilerinin hem de validator'lerin bir takım dahili bağlantılara sahip olduğu anlamına gelir para birimi ("tokens" olarak anılır) belirtilen süreyi aşan bir süre boyunca kilitlendi zinciri oluşturma ve doğrulama görevlerini yerine getirmek için harcadıkları zaman. Tüm Proof of Stake sistemlerinde olduğu gibi, tüm w blok üreticileri ve tüm wv validator'ler farklı varlıklardır, çünkü bu uygulanamaz. Her biri Bununla birlikte, w blok üreticilerinin ve wv validator'lerin ayrı bir hisse. Sistem n parça içeriyor, modelimizde n = 1000. Bahsedildiği gibi bölüm 3.1, Nightshade'de hiçbir parça zinciri yoktur, bunun yerine tüm blok üreticileri ve validator'ler tek bir blockchain inşa ediyor, biz bunu ana zincir. Ana zincirin durumu n parçaya bölünmüştür ve her blok yapımcı ve validator her an yerel olarak yalnızca bir alt kümesini indirdi bazı parçaların alt kümesine karşılık gelen ve yalnızca işlem ve Eyaletin bu kısımlarını etkileyen işlemleri doğrulamak. Bir blok üreticisi olmak için ağın bir katılımcısı bazı büyükleri kilitler tokens miktarı (bir hisse). Ağın bakımı dönemler halinde yapılır, burada bir dönem gün sırasına göre bir zaman dilimidir. Katılımcılar Belirli bir çağın başında en büyük riske sahip olan bloklar O dönemin yapımcıları. Her blok üreticisi yazılım parçalarına atanır (örneğin sw = 40, bu da sww/n = parça başına 4 blok üreticisi anlamına gelir). Blok yapımcı, atandığı parçanın çağdan önceki durumunu indirir başlar ve dönem boyunca söz konusu parçayı etkileyen işlemleri toplar, ve bunları devlete uygular. Ana zincirdeki her b bloğu ve her parça s için aşağıdakilerden biri vardır: blok üreticilerini b ile ilgili kısmı üretmekten sorumlu olanlara atadık parçaya. b'nin parçayla ilgili kısmına yığın denir ve şunları içerir: merkle'nin yanı sıra b'ye dahil edilecek parçaya ilişkin işlemlerin listesiortaya çıkan durumun kökü. b sonuçta yalnızca çok küçük bir başlık içerecektir parça, yani uygulanan tüm işlemlerin merkle kökü (bkz. bölüm Kesin ayrıntılar için 3.7.1) ve son durumun merkle kökü. Belgenin geri kalanında sıklıkla blok üreticisinden bahsediyoruz belirli bir parça için belirli bir zamanda bir parça üretmekten sorumlu olan bir parça üreticisi olarak. Parça üreticisi her zaman blok üreticilerinden biridir. Blok üreticileri ve parça üreticileri her bloğu ona göre döndürür. sabit bir programa göre. Blok üreticilerinin siparişi var ve tekrar tekrar üretim yapıyorlar. bu sırayla bloklar. Örn. 100 blok üreticisi varsa ilk blok üreticiler 1, 101, 201 vb. blokların üretiminden sorumludur, ikincisi ise 2, 102, 202 vb. üretmekten sorumludur. Parça üretimi, blok üretiminden farklı olarak bakım gerektirdiğinden durum ve her parça için yalnızca sww/n blok üreticileri durumu korur parça başına, buna uygun olarak yalnızca sww/n blok üreticileri, oluşturmak için dönüşümlü olarak çalışır. parçalar. Örn. dört blok üreticisinin atandığı yukarıdaki sabitlerle Her parça, her blok üreticisi her dört blokta bir parça oluşturacak. 3.4 Veri kullanılabilirliğinin sağlanması Veri kullanılabilirliğini sağlamak için Polkadot yaklaşımına benzer bir yaklaşım kullanıyoruz bölüm 2.5.3'te açıklanmıştır. Bir blok üreticisi bir parça ürettiğinde, optimal (w, ⌊w/6 + 1⌋) blok koduna sahip silme kodlu versiyonu yığın. Daha sonra silme kodlu parçanın bir parçasını gönderirler (bu tür parçalar diyoruz) her blok üreticisine parça parçaları veya sadece parçalar). Yapraklar gibi tüm parçaları içeren bir merkle ağacı hesaplıyoruz ve Her parçanın başlığı bu ağacın merkle kökünü içerir. Parçalar tek parça mesajları aracılığıyla validators'ye gönderilir. Bu tür mesajların her biri öbek başlığını, parçanın sırasını ve parça içeriğini içerir. mesaj aynı zamanda blok üreticisinin imzasını da içermektedir. parçanın başlığa karşılık geldiğini kanıtlamak için parça ve merkle yolu ve uygun blok üreticisi tarafından üretilmektedir. Bir blok üreticisi bir ana zincir bloğunu aldığında ilk olarak bu bloğun olup olmadığını kontrol eder. blokta yer alan her parça için tek parçalı mesajlar bulunur. Aksi takdirde blok eksik tek parçalı mesajlar alınana kadar işlenmez. Tüm tek parçalı mesajlar alındıktan sonra blok üreticisi, akranlarından kalan parçaları alır ve tuttukları parçaları yeniden yapılandırır devlet. Blok üreticisi en az bir ana zincir bloğunu işlemez. bloğa dahil edilen parçalarda karşılık gelen tek parçalı mesaj yoktur veya durumu korudukları en az bir parça için bunu yapamazlar tüm parçayı yeniden yapılandırın. Belirli bir parçanın mevcut olması için bloğun ⌊w/6⌋+1 olması yeterlidir Üreticiler kendi paylarına sahipler ve onlara hizmet ediyorlar. Böylece sayı kadar Kötü niyetli aktörler, yarım bloktan fazla bloğu olan hiçbir zincirin ⌊w/3⌋ değerini aşmaz bunu inşa eden üreticiler kullanılamayan parçalara sahip olabilir.Şekil 17: Her blok, parça başına bir veya sıfır parça içerir ve her parça silme kodludur. Silme kodlu yığının her bir parçası belirlenmiş bir yere gönderilir. özel bir tek bölümlü mesaj aracılığıyla yapımcıyı bloke etme 3.4.1 Tembel blok üreticileriyle uğraşmak Bir blok üreticisinin tek parçalı mesajın eksik olduğu bir bloğu varsa, yine de imzalamayı seçebilir, çünkü eğer blok zincire bağlanırsa blok üreticisinin ödülünü maksimuma çıkaracak. Blok için risk yok Daha sonra blok üreticisinin sahip olmadığını kanıtlamak imkansız olduğundan üretici tek parça mesajı. Bunu ele almak için, her bir parça üreticisini, parçayı oluştururken yapıyoruz. gelecekteki kodlanmış parçanın her bir parçası için bir renk (kırmızı veya mavi) seçin ve saklayın kodlanmadan önce yığındaki atanan rengin bit maskesi. Her bir parça mesaj parçaya atanan rengi içerir ve renk şu durumlarda kullanılır: kodlanmış parçaların merkle kökünün hesaplanması. Parça üreticisi saparsa protokole göre kolayca kanıtlanabilir, çünkü merkle kökü tek parça mesajlarına veya tek parça mesajlarındaki renklere karşılık gelir merkle köküne karşılık gelen, yığındaki maskeyle eşleşmeyecektir. Bir blok üreticisi bir bloğa imza attığında, tüm blokların bit maskesini ekler. bloğa dahil edilen parçalar için aldıkları kırmızı parçalar. Bir yayınlama yanlış bit maskesi kesilebilir bir davranıştır. Bir blok üreticisi bir sertifika almamışsa tek parçalı mesaj, mesajın rengini bilmelerinin hiçbir yolu yoktur ve dolayısıyla körü körüne imza atmaya kalkışmaları halinde %50 oranında kesintiye uğrama şansları vardır. Blok. 3.5 Durum geçiş başvurusu Parça üreticileri yalnızca parçaya hangi işlemlerin dahil edileceğini seçerler ancak bir yığın ürettiklerinde durum geçişini uygulamayın. Buna bağlı olarak,
yığın başlığı, daha önce olduğu gibi merkelize durumun merkle kökünü içerir yığındaki işlemler uygulanır. İşlemler yalnızca parçayı içeren tam bir blok olduğunda uygulanır işlenir. Bir katılımcı yalnızca şu durumlarda bir bloğu işler: 1. Önceki blok alındı ve işlendi; 2. Her parça için katılımcı sahip olduğu durumu korumaz tek parça mesajını gördüm; 3. Her parça için katılımcı, sahip oldukları durumu korur. tam yığın. Blok işlendikten sonra, katılımcının her bir parça için durumu korur, işlemleri uygular ve yeni durumu hesaplarlar işlemler uygulandıktan sonra üretime hazır hale gelirler herhangi bir parçaya atanmışlarsa bir sonraki bloğun parçaları yeni merkelleşmiş durumun merkle kökü. 3.6 Parçalar arası işlemler ve makbuzlar Bir işlemin birden fazla parçayı etkilemesi gerekiyorsa bunun ardışık olarak yapılması gerekir her parçada ayrı ayrı yürütülür. İşlemin tamamı ilk parçaya gönderilir etkilendiğinde ve işlem söz konusu parçanın öbeğine dahil edildiğinde ve öbek bir bloğa dahil edildikten sonra uygulanır, sözde bir makbuz üretir işlemin yapılması gereken bir sonraki parçaya yönlendirilen işlem idam edilecek. Daha fazla adımın gerekli olması halinde, alındı işleminin yürütülmesi yeni bir giriş hareketi oluşturur ve bu şekilde devam eder. 3.6.1 Makbuz işleminin ömrü Alış işleminin oluşturulduğu bloğun hemen ardından gelen blokta uygulanması arzu edilir. Makbuz işlemi yalnızca Önceki bloğun blok üreticileri tarafından alınıp uygulanmasından sonra oluşturulan kaynak parçayı koruyan ve o zamana kadar bilinmesi gereken Bir sonraki blok için parça, hedefin blok üreticileri tarafından üretilir kırık. Bu nedenle, makbuzun kaynak parçadan alıcıya iletilmesi gerekir. Bu iki olay arasındaki kısa zaman dilimindeki hedef parça. A, r girişini üreten bir t işlemini içeren son üretilen blok olsun. B bir sonraki üretilen blok olsun (yani A'yı içeren bir blok) r'yi içermek istediğimiz önceki bloğu). a ve r parçasında olsun kırıkta b. Şekil 18'de de gösterilen faturanın kullanım ömrü aşağıdaki gibidir: Makbuzların üretilmesi ve saklanması. Parça için parça üreticisi EBM'si a, A bloğunu alır, t işlemini uygular ve r makbuzunu oluşturur. EBM daha sonra üretilen tüm makbuzları dahili kalıcı depolama biriminde indekslenmiş olarak saklar kaynak parça kimliğine göre.Makbuzların dağıtılması. EBM, parçayı üretmeye hazır olduğunda B bloğu için a parçasını, a bloğu için A bloğundaki işlemlerin uygulanmasıyla oluşturulan tüm makbuzları getirir ve bunları parça için parçaya dahil ederler. B bloğunda a. Böyle bir yığın oluşturulduktan sonra, cpa onun silme kodunu üretir sürümü ve karşılık gelen tüm onepart mesajları. EBM, hangi blok üreticilerinin hangi parçalar için tam durumu koruduğunu bilir. Belirli bir blok üreticisi için bp cpa, A bloğundaki işlemlerin uygulanmasından kaynaklanan makbuzları içerir bp'nin hedef olarak önemsediği parçalardan herhangi birine sahip olan parça a için B bloğundaki a parçası için yığını dağıttıklarında tek parçalı mesajda (tek parçalı mesaja dahil edilen makbuzları gösteren şekil 17'ye bakın). Makbuzların alınması. Katılımcıların (hem blok üreticileri hem de validator'ler) tek parçalı mesajları alana kadar blokları işlemediklerini unutmayın. blokta yer alan her parça için. Böylece, herhangi bir katılımcı B bloğunu uyguladığında, B bloğuna karşılık gelen tüm tek parçalı mesajlara sahip olur. B'deki parçalar ve dolayısıyla parçaların bulunduğu tüm gelen makbuzlara sahipler katılımcı, varış yeri olarak durumunu korur. Uygularken belirli bir parça için durum geçişi, katılımcı hem makbuzları uygular tek parçalı mesajlarda parça için topladıklarının yanı sıra tüm yığının kendisinde yer alan işlemler. Şekil 18: Bir makbuz işleminin ömrü 3.6.2 Çok fazla makbuz işlemek Belirli bir parçayı hedefleyen faturaların sayısının belirli blok işlenemeyecek kadar büyük. Örneğin, şekil 19'u düşünün, her bir parçadaki her işlem, parça 1'i hedefleyen bir makbuz oluşturur. Bir sonraki blokta, parça 1'in işlemesi gereken faturaların sayısı şu şekilde olur: taşıma sırasında tüm parçaların bir araya getirdiği yükle karşılaştırılabilir önceki blok.
Şekil 19: Tüm faturalar aynı parçayı hedefliyorsa parçanın bunları işleme kapasitesi Bu sorunu çözmek için QuarkChain 9'da kullanılana benzer bir teknik kullanıyoruz. Spesifik olarak, her bir parça için son B bloğu ve onun içindeki son parça Fişlerin uygulandığı blok kaydedilir. Yeni parça ne zaman Oluşturulduğunda, fiş ilk önce B'de kalan parçalardan başlayarak uygulanır, ve sonra yeni yığın dolana kadar B'yi takip eden bloklar halinde. Normalin altında Dengeli bir yüke sahip koşullar altında, genellikle tüm tahsilatlar sonuçlanacaktır. uygulanıyor (ve böylece son bloğun son parçası kaydedilecek) her parça), ancak yükün dengeli olmadığı zamanlarda ve belirli bir Shard orantısız bir şekilde çok sayıda makbuz alıyor, bu teknik onların dahil edilen işlem sayısındaki sınırlara uyularak işlenecektir. Böyle dengesiz bir yükün uzun süre kalması durumunda gecikmenin Başvuruya kadar fiş oluşturma süresiz olarak büyümeye devam edebilir. Bir Bunu çözmenin yolu, bir hedefi hedefleyen bir makbuz oluşturan herhangi bir işlemi iptal etmektir. Belirli bir sabiti (ör. bir dönem) aşan bir işlem gecikmesine sahip olan parça. Şekil 20'yi düşünün. B bloğuna göre 4 numaralı parça tüm girişleri işleyemez, bu nedenle yalnızca A bloğundaki 3. parçaya kadar olan makbuzları işler ve onu kaydeder. C bloğunda B bloğundaki 5. parçaya kadar olan makbuzlar dahil edilir ve daha sonra D blokta parça yakalanır ve kalan tüm faturalar işlenir. B bloğu ve C bloğundaki tüm faturalar. 3.7 Parça doğrulama Belirli bir parça için üretilen bir parça (veya parça zincirli modelde belirli bir parça zinciri için üretilen bir parça bloğu) yalnızca şu şekilde doğrulanabilir: 9QuarkChain ile beyaz tahta bölümünü buradan izleyin: https://www.youtube.com/watch? v=opEtG6NM4x4, diğerlerinin yanı sıra parçalar arası işlemlere yaklaşımın tartışıldığı şeylerŞekil 20: Gecikmeli makbuz işleme Devleti koruyan katılımcılar. Blok üreticileri olabilirler, validators, veya yalnızca durumu indiren ve parçayı doğrulayan harici tanıklar varlıkları depoluyorlar. Bu belgede katılımcıların çoğunluğunun depolama yapamadığını varsayıyoruz. parçaların büyük bir kısmı için devlet. Ancak şunu belirtmekte yarar var varsayımıyla tasarlanmış parçalanmış blockchain'lerin bulunduğunu çoğu katılımcının durumunu saklama ve çoğu şeyi doğrulama kapasitesi vardır. QuarkChain gibi parçalar. Katılımcıların yalnızca bir kısmı parçayı doğrulama durumuna sahip olduğundan Parçalar halinde, yalnızca aşağıdaki özelliklere sahip olan katılımcıları uyarlanabilir şekilde yozlaştırmak mümkündür. durumu seçin ve geçersiz bir durum geçişi uygulayın. Her birkaç örnekte validators içeren birden fazla parçalama tasarımı önerildi gün ve bir gün içinde parça zincirinde 2/3'ten fazla olan herhangi bir blok söz konusu parçaya atanan validator'lerin imzalarının sayısı hemen dikkate alınır son. Böyle bir yaklaşımla, uyum sağlayabilen bir düşmanın yalnızca 2n/3+1'i yozlaştırması yeterlidir Geçersiz bir durum geçişi uygulamak için bir parça zincirindeki validator'lerin sayısı; Bunu başarmak muhtemelen zor olsa da, kamuya açık bir güvenlik düzeyi yeterli değil blockchain. Bölüm 2.3'te tartışıldığı gibi, ortak yaklaşım, durumu olan herhangi bir katılımcı için bir blok oluşturulduktan sonra belirli bir zaman aralığına izin vermektir (ister geçerliliğine meydan okuyan bir blok üreticisi, bir validator veya harici bir gözlemci). Bu tür katılımcılara Balıkçı denir. Bir balıkçının bunu yapabilmesi için Geçersiz bir bloğa itiraz edilmesi durumunda, böyle bir bloğun erişime açık olduğundan emin olunmalıdır. onlar. Nightshade'deki veri kullanılabilirliği bölüm 3.4'te tartışılmaktadır. Nightshade'de bir blok üretildiğinde parçalar gerçek parça üreticisi dışında herkes. Özellikle blok üreticisi bloğun doğal olarak çoğu parça için duruma sahip olmadığını öne sürdü veparçaları doğrulayamadı. Bir sonraki blok üretildiğinde, birden fazla blok üreticisinin ve validator'lerin onaylarını (bkz. bölüm 3.2) içerir, ancak blok üreticilerinin ve validator'lerin çoğunluğu durumu korumadığından çoğu kırık için de yalnızca bir geçersiz parçaya sahip bir blok, doğrulamaların yarısından önemli ölçüde fazlasını toplayacak ve en ağır blokta yer almaya devam edecek zincir. Bu sorunu çözmek için, durumunu koruyan herhangi bir katılımcıya izin veriyoruz. bu şekilde üretilen herhangi bir geçersiz parça için zincir üzerinde bir meydan okuma gönderecek bir parça kırık. 3.7.1 Devlet geçerliliği sorunu Bir katılımcı belirli bir parçanın geçersiz olduğunu tespit ettiğinde parçanın geçersiz olduğuna dair bir kanıt sunması gerekir. Ağ katılımcılarının çoğunluğu geçersiz parçanın bulunduğu parçanın durumunu korumadığından üretildiğinde, kanıtın bloğun doğrulandığını doğrulamak için yeterli bilgiye sahip olması gerekir. devlet olmadan geçersiz. Tek bir işlemin gerçekleştirebileceği durum miktarının (bayt cinsinden) Ls sınırını belirliyoruz. toplu olarak okuyabilir veya yazabilir. L'den daha fazlasına dokunan herhangi bir işlem durum geçersiz kabul edilir. Bölüm 3.5'ten hatırlayın ki yığın belirli bir B bloğunda yalnızca uygulanacak işlemleri içerir, ancak yeni durum kökü. B bloğundaki yığının içerdiği durum kökü durumdur root, bu tür işlemleri uygulamadan önce, ancak işlemleri uyguladıktan sonra B bloğundan önceki aynı parçadaki son parça. Kötü niyetli bir aktör geçersiz bir durum geçişi uygulamak istemeniz, yanlış bir durum kökü içerecektir uygulamadan kaynaklanan durum köküne karşılık gelmeyen B bloğunda önceki parçadaki işlemler. Bir parça üreticisinin parçaya dahil ettiği bilgiyi genişletiyoruz. Tüm işlemleri uyguladıktan sonra sadece durumu dahil etmek yerine, her bir bitişik işlem kümesi uygulandıktan sonra bir durum kökü içerir. toplu olarak Ls durum baytını okur ve yazar. Bu bilgilerle birlikte balıkçının devlet geçişinin yanlış uygulandığına dair bir zorluk yaratması Bu türden ilk geçersiz durum kökünü bulmak yeterlidir ve yalnızca Ls baytını içerir. son durum kökü arasındaki işlemlerden etkilenen durum (ki bu geçerli) ve merkle kanıtlarıyla birlikte mevcut durum kökü. Daha sonra herhangi bir katılımcı segmentteki işlemleri doğrulayabilir ve parçanın olduğunu doğrulayabilir geçersiz. Benzer şekilde, yığın üreticisi şunu okuyan işlemleri dahil etmeye çalışırsa: ve Ls bayttan daha fazla durum yazın, zorluk için dahil etmek yeterlidir Merkle kanıtlarıyla dokunduğu ilk Ls baytı, bu da yeterli olacaktır. işlemleri uygulayın ve bir girişimde bulunulacağı bir anın olduğunu onaylayın Ls bayt ötesinde içerik okuma veya yazma işlemi yapılır.
3.7.2 Balıkçılar ve hızlı çapraz parça işlemleri Bölüm 2.3'te tartışıldığı gibi, parça parçalarının (veya parçanın) modeldeki parça zincirli bloklar) geçersiz olabilir ve zorluk yaratabilir Bu durum nihailiği ve dolayısıyla parçalar arası iletişimi olumsuz etkiler. içinde özellikle herhangi bir çapraz parça işleminin hedef parçası kesin olamaz kaynak parça parçası veya blok, meydan okuma süresi bitene kadar nihaidir (bkz. şekil 21). Şekil 21: Makbuz uygulamadan önce sorgulama süresinin beklenmesi Bunu, parçalar arası işlemleri gerçekleştirecek şekilde ele almanın yolu hedef parçanın meydan okuma süresini beklememesi anlıktır kaynak parça işlemi yayınlandıktan sonra ve alındı işlemini uygulayın hemen, ancak daha sonra hedef parçayı kaynakla birlikte geri alın daha sonra kaynak parçanın veya bloğun geçersiz olduğu tespit edilirse parça (bkz. şekil 22). Bu, parçanın bulunduğu Nightshade tasarımı için çok doğal olarak geçerlidir. zincirler bağımsız değildir ancak bunun yerine parça parçalarının tümü yayınlanır birlikte aynı ana zincir bloğunda. Herhangi bir parçanın geçersiz olduğu tespit edilirse, bu parçaya sahip bloğun tamamı geçersiz kabul edilir ve üzerine inşa edilen tüm bloklar üstüne. Bkz. şekil 23. Yukarıdaki yaklaşımların her ikisi de, sorunun şu şekilde olduğu varsayılarak atomiklik sağlar: süre yeterince uzundur. Normal koşullar altında hızlı çapraz parça işlemlerinin sağlanması, hedef parça, aşağıdakilerden birinde geçersiz bir durum geçişi nedeniyle geri alınıyor son derece nadir bir olay olan kaynak parçaları. 3.7.3 validators gizleniyor Zorlukların varlığı, halihazırda bu olasılığı önemli ölçüde azaltıyor. uyarlanabilir yolsuzluk, çünkü bir yığını geçersiz bir durum geçiş gönderisiyle sonuçlandırmak içinŞekil 22: Makbuzların anında uygulanması ve varış noktasına geri alınması kaynak zincirinde geçersiz bir blok varsa zincir Şekil 23: Nightshade'de balıkçı mücadelesi Adaptif düşmanın tüm katılımcıları yozlaştırması gereken meydan okuma dönemi tüm validator'ler dahil olmak üzere parçanın durumunu koruyan. Böyle bir olayın olasılığını tahmin etmek son derece karmaşıktır, çünkü hiçbir Sharded blockchain bu tür bir saldırının denenmesine yetecek kadar uzun süredir yayında. Olasılığın son derece düşük olmasına rağmen hala yeterince yüksek olduğunu savunuyoruz. Milyonlarca işlemi yürütmesi beklenen bir sistem için büyük ve dünya çapında finansal operasyonlar yürütmek. Bu inancın iki temel nedeni vardır: 1. Proof-of-Stake zincirlerinin ve madencilerin validator'lerinin çoğu
İş Kanıtı zincirleri öncelikle finansal yükselişle teşvik ediliyor. Eğer Adaptif bir düşman onlara beklenen getiriden daha fazla para teklif eder dürüst bir şekilde faaliyet göstermekten dolayı, birçok validators'nin olmasını beklemek makul olacaktır. teklifi kabul edecek. 2. Birçok kuruluş Proof-of-Stake zincirlerinin doğrulamasını profesyonelce yapar ve Herhangi bir zincirdeki hisselerin büyük bir yüzdesinin bu tür kuruluşlardan. Bu tür varlıkların sayısı bir dönem için yeterince azdır. çoğunu kişisel olarak tanımak ve bozulmaya olan eğilimlerini iyi anlıyorlar. Hangi validator'lerin hangi parçaya atandığını gizleyerek uyarlamalı bozulma olasılığını azaltma konusunda bir adım daha ileri gidiyoruz. Fikir şu Algorand [5]'nin validators'yi gizlemesine uzaktan benzer. validator'ler, Algorand'da olduğu gibi gizlenmiş olsa bile, şunu unutmamak önemlidir: veya aşağıda açıklandığı gibi, uyarlanabilir bozulma teoride hala mümkündür. iken uyarlanabilir rakip, oluşturacak veya doğrulayacak katılımcıları tanımıyor Bir blok ya da yığın halinde, katılımcılar performans sergileyeceklerini kendileri biliyorlar. böyle bir görev ve bunun kriptografik bir kanıtı var. Böylece düşman yolsuzluk yapma niyetlerini yayınlayacak ve bunu sağlayacak herhangi bir katılımcıya ödeme yapacaktır. böyle bir kriptografik kanıt. Ancak şunu da belirtmeliyiz ki, rakip bunu yapmadığından bozmak istedikleri parçaya atanan validator'leri biliyorlarsa, belirli bir parçayı bozma niyetlerini yayınlamaktan başka seçeneği yok tüm topluluk. Bu noktada herhangi bir dürüst için ekonomik olarak faydalıdır. katılımcının bu parçayı doğrulayan tam bir düğümü döndürmesi için yüksek bir söz konusu parçada geçersiz bir bloğun görünme olasılığı; bir meydan okuma yaratın ve ilgili ödülü toplayın. Belirli bir parçaya atanan validator'leri açığa çıkarmamak için şunu yaparız: aşağıdakiler (bkz. şekil 24): Ödevi almak için VRF'yi kullanma. Her çağın başında her validator, validator'nin atandığı parçaların bit maskesini almak için bir VRF kullanır. Her validator'nin bit maskesi Sw bitlerine sahip olacaktır (tanım için bölüm 3.3'e bakın) Sw). validator daha sonra karşılık gelen parçaların durumunu getirir ve Alınan her blok için dönem boyunca karşılık gelen parçaları doğrular validator öğesinin atandığı parçalara. Parçalar yerine bloklar üzerinde oturum açın. Parça ataması gizlendiğinden validator parçalar üzerinde oturum açamaz. Bunun yerine her zaman bütünü imzalar böylece hangi parçaları doğruladığını açığa çıkarmıyor. Özellikle, validator bir blok alıp tüm parçaları doğruladığında ya bir mesaj oluşturur bu, validator öğesinin atandığı tüm parçalardaki tüm parçaların geçerli (bu parçaların ne olduğunu hiçbir şekilde belirtmeden) veya herhangi bir parçanın geçersiz olması durumunda geçersiz durum geçişinin kanıtını içerir. Bkz. Bu tür mesajların nasıl bir araya getirildiğine ilişkin ayrıntılar için bölüm 3.8, aşağıdakiler için bölüm 3.7.4: validators adlı kişinin gelen iletileri arka arkaya almasının nasıl önleneceğine ilişkin ayrıntılar nasıl ödüllendirileceği ve cezalandırılacağıyla ilgili ayrıntılar için diğer validators ve bölüm 3.7.5'e bakın validators başarılı bir geçersiz durum geçiş sorunu gerçekten meydana gelirse.Şekil 24: Nightshade'de validator'leri gizlemek 3.7.4 Taahhüt-Açıklama validators ile ilgili yaygın sorunlardan biri, validator'nin durumu indirmeyi ve aslında parçaları ve blokları doğrulamayı atlayabilmesi ve bunun yerine Ağı gözlemleyin, diğer validator'ların neler gönderdiğini görün ve yaptıklarını tekrarlayın. mesajlar. Böyle bir stratejiyi izleyen bir validator fazladan bir şey sağlamaz ağ için güvenlik sağlar, ancak ödüller toplar. Bu soruna yönelik yaygın bir çözüm, her validator için bir kanıt sağlamaktır örneğin benzersiz bir izleme sağlayarak bloğu gerçekten doğruladıklarını devlet geçişini uygulamak, ancak bu tür kanıtlar maliyeti önemli ölçüde artırıyor doğrulama. Şekil 25: Taahhüt-açıklama
Bunun yerine validators'nin doğrulama sonucuna ilişkin ilk taahhüdünü yaparız (veya parçaların geçerliliğini doğrulayan mesaj veya geçersiz olduğunun kanıtı durum geçişi), belirli bir süre bekleyin ve ancak bundan sonra şekil 25'te gösterildiği gibi gerçek doğrulama sonucunu ortaya çıkarın. ortaya çıkma dönemidir ve bu nedenle tembel bir validator dürüst validator'leri taklit edemez. Ayrıca, dürüst olmayan bir validator şunu doğrulayan bir mesaj gönderirse: atanan parçaların geçerliliği ve en az bir parçanın geçersiz olması durumunda öbeğin geçersiz olduğu gösterildiğinde validator eğik çizgiden kaçınamaz, çünkü, Bölüm 3.7.5'te gösterdiğimiz gibi böyle bir durumda kesilmemenin tek yolu geçersiz durum geçişinin kanıtını içeren bir mesaj sunmaktır. taahhütle eşleşir. 3.7.5 Zorluklarla baş etme Yukarıda tartışıldığı gibi, validator geçersiz parçaya sahip bir blok aldığında, önce geçersiz durum geçişinin kanıtını hazırlarlar (bkz. bölüm 3.7.1), ardından böyle bir kanıtı taahhüt edin (bkz. 3.7.4) ve bir süre sonra zorluğu ortaya çıkarın. Ortaya çıkan zorluk bir bloğa dahil edildiğinde aşağıdakiler gerçekleşir: 1. Bloktan gerçekleşen tüm durum geçişleri Ortaya çıkan zorluğun dahil edildiği bloğa kadar geçersiz parça hükümsüz kılındı. Ortaya çıkan mücadeleyi içeren bloktan önceki durum içeren bloktan önceki durumla aynı olduğu kabul edilir geçersiz yığın. 2. Belirli bir süre içinde her validator kendi bit maskesini göstermelidir doğruladıkları parçalar. Bit maskesi bir VRF aracılığıyla oluşturulduğundan, geçersiz durum geçişine sahip olan parçaya atandılar, ifşa etmekten kaçınamaz. Bit maskesini ortaya çıkaramayan herhangi bir validator parçaya atandığı varsayılmaktadır. 3. Bu süre sonunda parçaya atandığı tespit edilen her validator, içeren blok için bazı doğrulama sonuçları taahhüt etti geçersiz yığın ve bu geçersiz durum geçişinin kanıtını ortaya çıkarmadı bu onların taahhütlerine karşılık gelir. 4. Her validator yeni bir parça ataması alır ve yeni bir dönem planlanır tüm validator'ların indirmesi için yeterli bir süre sonra başlamak üzere Şekil 26'da gösterildiği gibi. validator'lerin kendilerine atanan parçaları ortaya çıkardığı andan itibaren unutmayın yeni dönem başlayana kadar sistemin güvenliği azaltılmıştır. Shard'ın ataması ortaya çıktı. Ağın katılımcılarının bunu saklaması gerekir Bu dönemde ağı kullanırken aklınızda bulundurun. 3.8 İmza Toplama Yüzlerce parçaya sahip bir sistemin güvenli bir şekilde çalışabilmesi için, 10.000 veya daha fazla validators sırası. Bölüm 3.7'de tartışıldığı gibi, her birini istiyoruz.Şekil 26: Mücadeleyi ele almak validator ortalama olarak belirli bir mesaja ve imzaya yönelik bir taahhüt yayınlamak için blok başına bir kez. Taahhüt mesajları aynı olsa bile, böyle bir şeyin toplanması BLS imzası ve bunun doğrulanması son derece pahalı olurdu. Ama doğal olarak taahhüt ve açıklama mesajları validators genelinde aynı değildir, dolayısıyla bu tür mesajları ve imzaları bir araya getirmenin bir yoluna ihtiyacımız var. Daha sonra hızlı doğrulamaya izin veren bir yol. Kullandığımız özel yaklaşım şudur: Doğrulayıcılar blok üreticilerine katılıyor. Blok üreticileri biliniyor çağın başlamasından bir süre önce, çünkü indirmeleri için biraz zamana ihtiyaçları var. çağ başlamadan önceki durum ve validator'lerden farklı olarak blok üreticileri gizlenmedi. Her blok üreticisinin v validator yuvası vardır. Doğrulayıcılar gönderir Blok üreticilerine v'lerinden biri olarak dahil edilmeleri için zincir dışı teklifler validators. Bir blok üreticisi validator eklemek isterse, validator'den gelen ilk zincir dışı talebi içeren işlem ve validator öğesinin blok üreticisine katılmasını sağlayan blok üreticisinin imzası. Blok üreticilerine atanan validator'lerin zorunlu olarak atanmadığını unutmayın. Blok üreticisinin parçalar ürettiği aynı parçaları doğrulayın. eğer bir Birden fazla blok üreticisini birleştirmek için validator uygulandı, yalnızca işlem ilk blok üreticisi başarılı olacaktır. Blok üreticileri taahhütleri toplar. Blok üreticisi sürekli olarak validators'den taahhüt ve açıklama mesajlarını toplar. Bu tür mesajların belirli bir sayısı toplandığında, blok üreticisi bir merkle hesaplar. bu mesajların ağacını oluşturur ve her validator'e merkle kökünü ve mesajlarına giden merkle yolu. validator yolu doğrular ve imzalar merkle kökü. Blok üreticisi daha sonra blok üzerinde bir BLS imzası biriktirir. validators'den merkle kökü ve yalnızca merkle kökü ve birikmiş imza Blok üreticisi aynı zamanda sözleşmenin geçerliliğini de imzalar. Ucuz bir ECDSA imzası kullanarak çoklu imza. Çoklu imza çalışmıyorsa gönderilen merkle köküyle veya katılan validator'ların bit maskesiyle eşleşirse, bu eğik çizgi çizilebilir bir davranıştır. Zinciri senkronize ederken bir katılımcı validator'lerden gelen tüm BLS imzalarını doğrulamayı seçebilir (bu, validator'nin ortak anahtarlarının toplanmasını gerektirdiğinden son derece pahalıdır) veya yalnızcaBlok üreticilerinin ECDMA imzalarına güveniyoruz ve blok üreticisine meydan okunmadı ve kesildi. Zorluklar için zincir içi işlemleri ve merkle kanıtlarını kullanma. o eğer hayırsa validators'den gelen mesajları açığa çıkarmanın hiçbir değeri olmadığı belirtilebilir. geçersiz durum geçişi algılandı. Yalnızca gerçek bilgiyi içeren mesajlar Geçersiz durum geçişinin kanıtlarının açıklanması gerekir ve yalnızca bu tür mesajlar için önceki taahhütle eşleştiklerinin gösterilmesi gerekir. Mesajın ihtiyacı var iki amaçla ortaya çıkar: 1. Zincirin geri dönüşünü fiilen başlatmak için geçersiz durum geçişi (bkz. bölüm 3.7.5). 2. validator belgesinin geçerliliğini kanıtlamaya çalışmadığını kanıtlamak için geçersiz yığın. Her iki durumda da iki konuyu ele almamız gerekiyor: 1. Gerçek taahhüt zincire dahil edilmedi, yalnızca merkle kökü diğer mesajlarla birleştirilmiş taahhüt. validator öğesinin şunu kullanması gerekiyor: Blok üreticisi tarafından sağlanan merkle yolu ve orijinal taahhütleri bu mücadeleye kararlı olduklarını kanıtla. 2. Tüm validator'lerin geçersiz parçaya atanması mümkündür. durum geçişi bozuk blok üreticilerine atanacak bunları sansürlüyorlar. Bunu aşmak için onların açıklamalarını göndermelerine izin veriyoruz Zincir üzerinde düzenli bir işlem olarak ve toplamayı atlayarak. İkincisine yalnızca geçersiz durum geçişinin kanıtları için izin verilir; son derece nadirdir ve bu nedenle blokların spam gönderilmesiyle sonuçlanmamalıdır. Ele alınması gereken son konu, blok üreticilerinin iletilerin toplanmasına katılmamayı veya belirli validators'leri kasıtlı olarak sansürlememeyi tercih edin. Blok haline getirerek ekonomik açıdan dezavantajlı hale getiriyoruz üretici ödülü, kendilerine atanan validators sayısıyla orantılıdır. Biz ayrıca dönemler arasındaki blok üreticilerinin büyük ölçüde kesiştiğinden (çünkü her zaman en yüksek hisseye sahip olan en üstteki katılımcılardır), validator'ler yapabilir Büyük ölçüde aynı blok üreticileriyle çalışmaya devam edin ve böylece riski azaltın Geçmişte onları sansürleyen bir blok üreticisine atanmak. 3.9 Anlık Görüntü Zinciri Ana zincirdeki bloklar çok sık üretildiğinden indirme tarihin tamamı çok hızlı bir şekilde pahalı hale gelebilir. Üstelik her zamandan beri blok çok sayıda katılımcının BLS imzasını içeriyorsa, yalnızca imzayı kontrol etmek için ortak anahtarların toplanması engelleyici hale gelebilir aynı zamanda pahalı. Son olarak, öngörülebilir bir gelecekte Ethereum 1.0 muhtemelen bir tane olarak kalacak en çok kullanılan blockchain'lerden biridir ve varlıkları aktarmanın anlamlı bir yolunu sunar
Ethereum'ye yakın olması bir gerekliliktir ve bugün BLS imzalarının doğrulanması Ethereum tarafında yakın blokların geçerliliği mümkün değildir. Nightshade ana zincirindeki her blok isteğe bağlı olarak bir Schnorr içerebilir böyle bir Schnorr içeren son bloğun başlığındaki çoklu imza çoklu imza. Bu tür bloklara anlık görüntü blokları diyoruz. İlk blok her çağ bir anlık görüntü bloğu olmalıdır. Böyle bir çoklu imza üzerinde çalışırken, blok üreticileri ayrıca validators'nin BLS imzalarını da biriktirmelidir son anlık görüntü bloğuna yerleştirin ve bunları bölümünde açıklandığı şekilde toplayın. bölüm 3.8. Blok üreticilerinin belirlediği dönem boyunca sabit olduğundan doğrulama hiçbir çağda yalnızca ilk anlık görüntü blokları yeterlidir. blok üreticilerinin ve validator'lerin büyük bir yüzdesinin gizli anlaşma yapıp yarattığını gösteriyor bir çatal. Çağın ilk bloğu hesaplamaya yetecek bilgiyi içermelidir dönemin blok üreticileri ve validator'ler. Ana zincirin yalnızca anlık görüntüsünü içeren alt zincirine diyoruz. anlık görüntü zincirini engeller. Schnorr çoklu imzası oluşturmak etkileşimli bir süreçtir, ancak ne kadar verimsiz olursa olsun bunu nadiren gerçekleştirmeniz gerekir; yeterli olacaktır. Schnorr çoklu imzaları Ethereum üzerinde kolayca doğrulanabilir, böylece çapraz-blockchain gerçekleştirmenin güvenli bir yolu için önemli temel öğeler sağlanır iletişim. Yakın zincirle senkronizasyon için yalnızca tüm anlık görüntülerin indirilmesi gerekir bloklar ve Schnorr imzalarının doğru olduğunu onaylar (isteğe bağlı olarak validators'nin bireysel BLS imzalarını da doğrular) ve ardından yalnızca senkronizasyon son anlık görüntü bloğundan ana zincir blokları.
Abschluss
In diesem Dokument haben wir Ansätze zum Erstellen von Shard-blockchains und besprochen deckte mit bestehenden Ansätzen zwei große Herausforderungen ab, nämlich die Zustandsvalidität und Datenverfügbarkeit. Anschließend präsentierten wir Nightshade, ein Sharding-Design Befugnisse NEAR Protokoll. Der Entwurf ist in Arbeit. Wenn Sie Kommentare, Fragen oder Feedback haben Zu diesem Dokument gehen Sie bitte zu https://near.chat.
Çözüm
Bu belgede parçalı blockchains oluşturmaya yönelik yaklaşımları tartıştık ve mevcut yaklaşımlarla iki büyük zorluğu, yani durum geçerliliğini ele aldı ve veri kullanılabilirliği. Daha sonra bir parçalama tasarımı olan Nightshade'i sunduk. NEAR Protokolüne güç verir. Yorumlarınız, sorularınız veya geri bildirimleriniz varsa tasarım üzerinde çalışma devam etmektedir bu belgede lütfen https://near.chat. adresine gidin