Kettenübergreifende Interaktion und kontinuierliche Stabilität basierend auf SimpleChain Beta


Bitcoin ist das erste Szenario, in dem die Blockchain-Technologie angewendet wird, und die bislang vertrauenswürdigste öffentliche Kette. Die Skalierbarkeit stand bei der Entwicklung dieser Blockkette immer im Mittelpunkt. Tatsächlich gab es für die Bitcoin-Blockchain zwischen dem 4. Januar 2009 (dem Startdatum von Bitcoin) und dem 1. Oktober 2010 keine spezifische Größenbeschränkung. Während dieses Zeitraums betrug die Blockgröße der Bitcoin-Blockchain bis zu 32 MB. Allerdings hat Satoshi Nakamoto die Blockgröße im Code, der am 1. Oktober 2010 festgeschrieben wurde, explizit auf 1 MB beschränkt. Am 3. Oktober veröffentlichte Jeff Garzik einen Patch, der die Blockgröße auf 7 MB erweiterte, den ersten Versuch, eine Hard Fork zu implementieren. Dieser Patch war jedoch nicht weit verbreitet. Zu diesem Zeitpunkt betrug die durchschnittliche Blockgröße nur einige zehn KB. Satoshi Nakamoto empfahl auch, den von Jeff Garzik veröffentlichten Patch nicht zu verwenden, um die Sicherheit und Stabilität des Bitcoin-Systems zu gewährleisten.

Mit zunehmender Größe des Bitcoin-Netzwerks werden Transaktionen in der Blockchain häufiger und das Datenvolumen in der Blockchain steigt ebenfalls allmählich an. Es wird ein offensichtlicher Leistungsengpass, dass nur sieben Transaktionen pro Sekunde verarbeitet werden.

Abbildung 1: Entwicklungsverlauf der Bitcoin-Blockgröße (von BitinfoCharts.com)

Ab 2015 schlug Jeff Garzik die Aufhebung der Blockgrößenbeschränkung von 1 MB durch BIP100 vor und änderte die Größenbeschränkung wieder auf die ursprüngliche Größenbeschränkung von 32 MB. Die Rechenkapazität von Bitcoin lag jedoch seit langem über 1 PB, und die Mehrheit der interessierten Parteien waren Bitcoin-Miner anstelle von normalen Zahlungsnutzern. Für Bergleute bedeutet das Verpacken von mehr Transaktionen jedoch einen höheren Ressourcenverbrauch. Daher wurde noch nie ein wirklicher Konsens bei der Blockskalierung in der Bitcoin-Blockchain erzielt. Dies führt zu Gabeln wie BCH und BSV. Offensichtlich ist es nur eine Zweckmäßigkeit, das Problem der Transaktionsverarbeitungseffizienz durch stufenloses Erhöhen der Blockgröße zu lösen.

Ethereum hat auch ein ähnliches Problem. Im Gegensatz zur Bitcoin-Blockchain ist die Ethereum-Blockgröße keine Konstante. Der Kompromiss zwischen dem Gaslimit und dem Interesse der Bergleute begrenzt jedoch auch die Transaktionsverarbeitungsgeschwindigkeit in der Ethereum-Blockchain, und nur etwa 15 Transaktionen können pro Sekunde verarbeitet werden. Aus diesem Grund wurde das gesamte Ethereum-Netzwerk im Jahr 2017 durch die Anhäufung großer Transaktionsmengen lahmgelegt, als sich ICOs und Spiele wie CryptoKitties durchsetzten.

In der herausfordernden Situation der Hauptkettenerweiterung werden Datenvalidierung und -berechnung in Hauptketten an eine kleine Gruppe von Hochleistungsknoten übergeben. Beispielsweise wird der DPoS-Mechanismus von Bitshares und EOS auf diese Weise implementiert. Lösungen dieser Art wählen Hochleistungsknoten aus, indem sie ein parlamentarisches System in der realen Welt simulieren, was unvermeidlich zu Konflikten zwischen interessierten Parteien und dem Trend zur Zentralisierung führt. Darüber hinaus haben einige versucht, diese Art von Problem durch Transaktionen außerhalb der Kette zu lösen. Zwei typische Lösungen sind das Bitcoin Lightning Network und das Ethereum Raiden Network.

Die Unterschiede zwischen dem UTXO-Bitcoin-Blockchain-Modell und dem Account-Balance-basierten Modell in Ethereum führen zu unterschiedlichen Protokolllösungen für die Off-Chain-Transaktionskanäle: dem Lightning-Netzwerk und dem Raiden-Netzwerk. Die beiden unterschiedlichen Netzwerke haben jedoch dieselbe gemeinsame Grundlogik, dh, sie erstellen Transaktionskanäle für bestimmte Transaktionsobjekte außerhalb der Hauptketten. Das heißt, eine Einzahlung wird gemeinsam über bestimmte Transaktionsobjekte hinweg für die Transaktionsabrechnung in einem bestimmten Zeitintervall gesperrt. Es ist nicht erforderlich, bilaterale oder multilaterale Transaktionen im gesamten Netzwerk zur Bestätigung zu senden und eine Formalitätsgebühr an das Hauptblockchain-Netzwerk zu zahlen, wenn der bilaterale oder multilaterale Transaktionsbetrag den Einzahlungsbetrag nicht überschreitet, kein Timeout auftritt oder keine oder keine von beiden Die Parteien entscheiden, die Transaktionskanäle zu beenden. Dies macht häufige und kleine Transaktionen nicht länger von der Blockgröße und der Geschwindigkeit der Blockerzeugung abhängig.

Um so viele Anforderungen wie möglich für häufige Transaktionen zu erfüllen, stellt das Lightning-Netzwerk mehrere Vermittlungsknoten bereit, um die Anforderungen einzelner Transaktionsparteien zu erfüllen. Im Lightning-Netzwerk müssen Zahlungen während des Transaktionsprozesses signiert werden. Daher müssen Transaktionsparteien in Echtzeit online sein. Aus dieser Perspektive eignet sich eine zentrale Vermittlungsstelle am besten als Vermittlungsknoten. Die Community ist jedoch besorgt darüber, ob dadurch häufige und kleine Transaktionen zunehmend zentralisiert werden und die Sicherheit gefährdet wird.

Wie auch immer, das Lightning-Netzwerk und das Raiden-Netzwerk haben die Lösung für die Skalierbarkeit auf die zweite Ebene außerhalb der Hauptkette umgeleitet. Die Schichtung zwischen Netzwerken für unterschiedliche Anforderungen und dem Hauptkettennetz wird zu einem Haupttrend zur Lösung des Skalierbarkeitsproblems.

Sharding ist ein aus dem Datenbankfeld abgeleitetes Konzept. In Datenbanken kann Sharding durch klassifizierte Sicherung und Redundanz die Effizienz und Fehlertoleranz verbessern. In verteilten Datenbanken werden verschiedene Sharding-Mechanismen eingerichtet, um den unterschiedlichen Anforderungen des Geschäftssystems gerecht zu werden. Die vorgeschlagene Layer-2-Lösung zur Lösung des Problems der Blockchain-Skalierbarkeit basiert auf dem Sharding-Konzept, mit dem die Leistungsengpässe der gesamten Kette durch Klassifizierung der verschiedenen Blockchain-Anforderungen verschiedener Dienste und Zuweisung von Anforderungen zu verschiedenen Unterketten behoben werden.

Blockchains und verteilte Datenbanken haben jedoch einen großen Unterschied: Das Hinzufügen, Löschen, Ändern, Abfragen und Berechnen in verteilten Datenbanken erfolgt über das Dienstsystem oder zentralisierte Datenverwaltungssysteme, und einzelne Knoten in verteilten Datenbanken sind nur für die Reaktion auf Datenbankadministratoren (DBAs) verantwortlich ). Die Geschäftslogik auf Blockchains stammt auch von einzelnen Knoten, die für die Geschäftslogik und -berechnungen sowie die Verwaltung von Daten zumindest auf Ledger-Ebene verantwortlich sind. Das heißt, jeder Knoten in einer Blockchain kann als DBA betrachtet werden oder es gibt überhaupt keine DBAs in einer Blockchain. Daher ist das Blockchain-Design komplexer.

Da die Transaktionslogik in verteilten Datenbanken zentralisiert ist, kann ein Shard als einfacher Speichershard betrachtet werden. Shards in Blockchain umfassen hauptsächlich relativ einfache Transaktions-Shards und schwierigere State-Shards. Der frühere Shard-Typ stellt sicher, dass die Daten auf allen Knoten im Netzwerk noch vollständig synchronisiert sind und dass nur Shards verwendet werden, um unterschiedliche Geschäftslogiken auf verschiedenen Knoten auszuführen. Die letztere Art von Shards umfasst sowohl Transaktions-Shards als auch Storage-Shards. Im engeren Sinne sind die typischsten staatlichen Scherben Gabeln. Jede Gabelkette verarbeitet ihre eigenen Transaktionen und speichert ihre eigenen Hauptbuchdaten. Wenn wir die Gültigkeit historischer Blöcke überprüfen möchten, können wir zu Blöcken zurückkehren, bevor das Forking stattgefunden hat, und historische Transaktionen durch Snapshots bestätigen. Da jedoch für Shards dieses Typs keine Kreuz-Shard-Interaktionsmechanismen verfügbar sind, verbessert dieser Shard-Typ nicht viel praktische Bedeutung.

Für shardübergreifende Transaktionen müssen staatliche Shards eine Lösung finden, um die Gültigkeit von Transaktionen in verschiedenen Shards zu überprüfen. Die Gültigkeit von Transaktionen in Shards wird durch Knoten in Shards über den Konsensmechanismus sichergestellt. Daher ist der Operationsmechanismus in SimpleChain auch in verschiedenen Shards vorhanden. Das Transaktionsproblem zwischen Shards wird in SimpleChain als kettenübergreifende Transaktion betrachtet, und Shards werden als Unterketten definiert.

Da kettenübergreifende Transaktionen zwischen zwei Blockchain-Benutzern mit inkonsistenten Ledger-Daten stattfinden, können wir ein „Objekt“ erstellen, das im Ledger gespeichert wird, und nicht als Zustand, um einen Mechanismus ähnlich SPV (Simplified Payment Verification) zu implementieren, mit dem die Gültigkeit überprüft werden kann des erstellten "Objekts" durch einen Merkle-Baum unter Verwendung gegenseitig synchronisierter Blocküberschriften. Wir können dieses Objekt als Quittung bezeichnen.

Abbildung 2: Bestätigung von belegbasierten kettenübergreifenden Transaktionen (aus dem Ethereum-Wiki)

In der vorherigen Abbildung sendet Benutzer A in Blockchain X 100 Einheiten von Assets an Benutzer C in Blockchain Y.

(1) Eine Transaktion und eine Quittung mit der Nummer 154016 werden zuerst generiert und 100 Asset-Einheiten werden vom Hauptbuch von Benutzer A in Blockchain X abgezogen.

(2) Nachdem die Quittung an Blockchain Y gesendet wurde, wird anhand eines Merkle-Baums überprüft, ob die in dieser Quittung enthaltenen Informationen korrekt sind (d. H. Ob die erste Transaktion in Blockchain X bestätigt wurde und ob 100 Asset Units abgezogen wurden) von Benutzer A).

(3) Nach der Bestätigung sendet Benutzer C eine Transaktion, die Informationen über die Merkle-Überprüfung auf dem Beleg 154016 enthält, und 100 Aktiva-Einheiten werden dem Hauptbuch von Benutzer C hinzugefügt. Diese Transaktion kann als Empfangsbestätigung angesehen werden.

(4) Nachdem Blockchain X die Empfangsbestätigung erhalten hat, wird die vorherige Quittung zerstört und der Beleg 154016 wird auch in nachfolgenden Blöcken in Blockchain Y zerstört. Die kettenübergreifende Transaktion ist abgeschlossen. Natürlich können Blockchain X und Blockchain Y auch die Empfangsbestätigung aufbewahren, um die Kontinuität nachfolgender kettenübergreifender Transaktionen zu überprüfen.

Um die kontinuierliche Wirksamkeit des oben genannten Mechanismus sicherzustellen, müssen wir auch die Endgültigkeit von Transaktionen über mehrere Ketten hinweg (oder einen Gabelauswahlmechanismus) berücksichtigen. Die Transaktion von Blockchain X, die von Blockchain Y verifiziert wurde, muss aus einem Block in einer gültigen Kette von Blockchain X stammen und nicht aus einem isolierten Block oder einer isolierten Kette. Vlad Zamfir schlug einmal das Konzept der Blockzusammenführung vor: Zwei Blöcke in zwei verschiedenen Ketten werden zu einem Block zusammengeführt, wenn eine Transaktion über die beiden Ketten initiiert wird, und jede Kette erweitert nachfolgende Blockdaten basierend auf diesem zusammengeführten Block. In der Tat bedeutet das Zusammenführen von Blöcken die Hauptbuchsynchronisation zwischen den beiden Ketten. Daher wird das Zusammenführen von Blöcken als nicht in der Lage angesehen, das Problem der gegenseitigen Unabhängigkeit zwischen zwei Shards oder Ketten zu lösen. Bei einer kettenübergreifenden Transaktion können wir jedoch nach Vlads Vorstellungen immer noch eine Antwort auf die Frage finden, wie man den richtigen Block für eine der Ketten findet und dann die Merkle-Überprüfung auf einer Quittung abschließt.

Nach Vlad werden Ketten, für die kettenübergreifende Transaktionen erforderlich sind, nach Ebenen in Hauptketten und Unterketten unterteilt. Zum Zusammenführen eines Blocks in einer Unterkette mit einem Block in einer Hauptkette muss die Unterkette dieselbe oder eine höhere Ebene als die Hauptkette haben. In unserem Szenario müssen wir eine kettenübergreifende Überprüfung für eine Hauptkette durchführen. Dies stellt konsistente Daten im überlappenden Kettenabschnitt sicher, selbst wenn eine der Ketten anschließend verlängert wird.

Abbildung 3: Blockzusammenführung (Vlad Zamfir)

Die vorstehende Lösung erfordert jedoch die Voraussetzung einer synchronen Blockerzeugung. Die Gültigkeit von Transaktionen in der Unterkette Y wird beeinträchtigt, wenn einer der folgenden Fälle eintritt: Die Transaktion in der Hauptkette X wird nicht rechtzeitig bestätigt. die Kette ist nicht verlängert; Unterkette Y hat nicht rechtzeitig Informationen über die Erweiterung von X erhalten; oder eine intermittierende Synchronisation tritt zwischen der Hauptkette und der Unterkette auf.

Abbildung 4: Mögliche Situationen beim Verzweigen bei nicht synchronen Cross-Chain (Cross-Shard) -Transaktionen (Alexander Skidanov)

In der vorhergehenden Abbildung können wir sehen, dass, wenn zwei Scherben oder Ketten Gabeln haben, AB in Scherbe 1 und V'-X'-Y'-Z 'in Scherbe 2 als Hauptketten bzw. als Kreuzketten oder identifiziert werden Cross-Shard-Transaktion wird erfolgreich sein. Wenn A, B, C, D und V, X die Hauptketten werden, wird eine Cross-Shard-Transaktion ungültig. In den beiden anderen Situationen tritt ein Atomitätsfehler auf, dh, eine Transaktion ist in einem Shard gültig, in einem anderen Shard jedoch ungültig. Aufgrund der Asynchronisation zwischen zwei Shards oder Ketten können Hauptketten in den beiden Shards bzw. Ketten nicht bestimmt werden, wenn eine kettenübergreifende Transaktion initiiert wird, was schließlich zu diesem Problem führt. Daher ist bei kettenübergreifenden Transaktionen zwischen Shards oder Subketten ein zwischengeschalteter Konsensmechanismus für die Koordinierung erforderlich.

Dies ist, was die Beacon-Kette in Ethereum 2.0 tut. Die Leuchtfeuerkette gilt als Hauptkette aller Scherben in Ethereum 2.0. Diese Hauptkette verwendet den Casper-Konsensus-Mechanismus für die Wahl und generiert in jeder Runde nach dem Zufallsprinzip einen Splitterprüfer, um die Richtigkeit der Transaktionen zwischen den Splittern sicherzustellen. Da es im Casper POS-Konsensusprotokoll jedoch keine Schwierigkeitsanforderungen, Nonce- und Block-Hashes gibt, die in PoW verfügbar sind, um zustandslose SPV durchzuführen, müssen wir den Status zurückverfolgen, um die Gültigkeit von Shards und Ketten zu überprüfen und zu vertrauenswürdigen Blöcken zurückzukehren von Blöcken nach den vertrauenswürdigen Blöcken und synchronisieren mit aktuellen Blöcken. Dies erhöht die Arbeit der Prüfer. Um die Arbeit der Prüfer zu reduzieren, werden in SimpleChain Rollen wie die Beacon-Kette mithilfe von PoW über die Hauptkette implementiert.

Die Ankerminenrolle ist in der Hauptkette vorhanden, die für drei Dinge verantwortlich ist. 1. Überprüfen Sie die Statusgültigkeit einer Unterkette, wenn eine kettenübergreifende Transaktion von dieser Unterkette initiiert wird. 2. Schreiben Sie die Transaktion aus der Unterkette in die Hauptkette und senden Sie sie zur Bestätigung. 3. Schreiben Sie das in der Hauptkette bereits bestätigte kettenübergreifende Transaktionsergebnis in Blöcke in der Unterkette, die die Transaktion gestartet hat, und in der Unterkette, die die Transaktion erhalten hat.

Der Ankerminer fungiert sowohl in der Unterkette als auch in der Hauptkette als Miner, wenn er kettenübergreifende Transaktionen überprüft, sendet und überträgt. Die Hauptkette hat mehr Bergleute als die Unterkette. Daher sind das Schmieden und Übertragen von Transaktionen in der Unterkette an die Hauptkette wesentlich kostengünstiger als das Schmieden und Schreiben von Transaktionen von der Hauptkette an die Unterkette. Wir brauchen einen vernünftigeren Ankerminenwahlmechanismus.

Abbildung 5: Höhere Wahrscheinlichkeit eines bösen Bergmanns in einer Unterkette als in einer Hauptkette (Alexander Skidanov)

Ein Ankerminer existiert für eine Unterkette für eine lange Zeit, muss jedoch für eine lange Zeit als Bergmann in der Hauptkette fungieren. Da Hauptketten, die PoW verwenden, das zustandslose SPV ermöglichen, wird die Ankerminer-Wahl in SimpleChain auf zufällige Weise implementiert.

Die maximale Anzahl von Anker-Minern, die in einer kettenübergreifenden Transaktion überprüft werden können, beträgt Min[(number of miners throughout the network/number of sub-chains)×3, number of miners throughout the network].

Weil Ankerminenarbeiter mit PoW von Hauptketten kommen. Daher können wir die Ergebnisse der Arbeitslastüberprüfung, die von Hauptketten berechnet wurden, in aufsteigender Reihenfolge sortieren und Ankerminer filtern. Je kleiner der Workload-Wert ist, desto geringer ist die Wahrscheinlichkeit, die Berechnungsergebnisse zu erhalten, und desto höher ist der Rang in der Vorauswahlliste der Ankerminenarbeiter. Ein Bergarbeiter, der einen Rang außerhalb der maximalen Anzahl von Ankerbergarbeitern hat, unterschreibt in der aktuellen Runde der Transaktionsüberprüfung nicht. Die PoW-Sortierung während der Ankerminenwahl und die PoW-Sortierung der verlängerten Hauptkette werden synchron durchgeführt. Das heißt, Bergleute in einer Hauptkette verwenden die Ergebnisse der Workload-Überprüfung, um sowohl SIPC-Belohnungen in der Hauptkette als auch Belohnungen für den Ankerbergmann zu erhalten. Die Belohnungen für die Verankerung von Minern stammen aus den Gebühren für die SIPC-Miner-Formalität, die von einem Initiator einer kettenübergreifenden Transaktion gezahlt werden.

Der N-Konformationsmechanismus wird verwendet, um die Konsistenz zwischen Hauptketten und Unterketten sicherzustellen. Wenn eine kettenübergreifende Transaktion initiiert wird, muss ein Block in einer Unterkette eine Bestätigung von N Blockhöhen erhalten, bevor die Verifizierung des Ankerminers erfolgreich ist und die Transaktion an die Hauptkette gesendet wird. Nachdem die Bestätigung von N Blockhöhen in der Hauptkette empfangen wurde, wird der bestätigte Transaktionsstatus in die beiden Unterketten in diesen kettenübergreifenden Transaktionen geschrieben.

Der Wert von N ist direkt proportional zum Betrag der Quertransaktion und dem Datenvolumen. Dies bedeutet, dass eine Transaktion mit höherem Wert mehr Bestätigungen für die Unterketten und die Hauptkette erfordert. Gegenwärtig ist die Anzahl der Bestätigungen in der Hauptkette ebenso konstant wie in Bitcoin. Da die Hauptkette im Durchschnitt alle 12 Sekunden einen Block erzeugt, liegt die Sicherheitsstufe nahe an der von 6 Bestätigungen in der Bitcoin-Blockkette, wenn N in der Hauptkette auf 15 gesetzt ist. Die Anzahl der Bestätigungen von Unterketten wird dynamisch angepasst, basierend auf den 15 Bestätigungen von der Hauptkette sowie der Anzahl der kettenübergreifenden Transaktionen und dem Datenvolumen.

Abbildung 6: SIPC-Modell (Simplechain Foundation)

In SimpleChain Whitepaper 1.0 wurde ein Mikroinflationsmechanismus für die digitale Ressource SIPC auf Hauptketten vorgeschlagen: Mit der Zunahme der Anzahl von Unterketten, der Aktivität der Unterketten und den Anforderungen für kettenübergreifende Transaktionen sind die Block-SIPC-Belohnungen in Ordnung -abgestimmt auf der Basis der ursprünglichen Abklingkurve (in der vorhergehenden Abbildung wird die grün gepunktete Linie in die schwarze durchgezogene Linie geändert). Das Ergebnis der Feinabstimmung ist, dass sich die Blockbelohnungen in der Hauptkette entsprechend erhöhen, wenn die Hauptkette SIPC als Ressource betrachtet wird und Unterketten mehr Ressourcen dieser Art benötigen. Nehmen wir den aktuellen Status, zum Beispiel, die Blockbelohnung in der Hauptkette kann von 20SIPC auf 21SIPC steigen.

Dieses Design zielt darauf ab, eine stabilere Beziehung zwischen Rollen in Hauptketten und Unterketten herzustellen. Unterketten benötigen Hauptketten, um kettenübergreifende Transaktionen zu koordinieren. Eine kettenübergreifende Transaktion wird in den folgenden Schritten abgeschlossen:

(1) Ein Benutzer in einer Unterkette initiiert eine kettenübergreifende Transaktion und zahlt Formalitätsgebühren einschließlich Token (T) der Unterkette und SIPC (S) der Hauptkette.

(2) Bergleute oder Validierungsknoten in der Unterkette vervollständigen die Konsensüberprüfung und beanspruchen das Token (T1) als Formalitätsgebühr.

(3) Gewählte Cross-Chain-Miner fordern das verbleibende Token (T2), alle SIPC (S) in der Hauptkette und einen Teil von SIPC (S2) im Operationspool als Formalitätsgebühren für die Vervollständigung des Cross-Chain-Ankers und Rundfunk.

(4) Normale Bergleute in der Hauptkette erheben eine Gebühr für die Hauptkette-SIPC (S ’), um die kettenübergreifende Transaktion zu verpacken.

(5) Das Ankern von Bergleuten in der anderen Unterkette liest die kettenübergreifende Transaktion in der Hauptkette und sendet sie an die Zielunterkette.

In den vorhergehenden Schritten enthält T T1 und T2. Die von gewöhnlichen Bergarbeitern der Hauptkette erhobene Formalitätsgebühr ist die Summe von R und K, wobei R die ursprüngliche Blockbelohnung (20SIPC) und K die Belohnung für die Anpassung der Mikroinflation ist.

Der Operationspool besteht aus Startressourcen, die von den erstellten Knoten in Unterketten eingefügt werden, indem SIPC bei der Erstellung von Unterketten belastet wird. SIPC im Betriebspool wird als Teilbelohnung (S) in kettenübergreifenden Transaktionen verwendet und an Ankerminenarbeiter gesendet.

Angenommen, die Kapazität eines Startvorgangs-Pools für ein Material beträgt 10 SIPC. In jeder kettenübergreifenden Transaktion wird 0.1SIPC den kettenübergreifenden Bergleuten als Teil ihrer Belohnung zugewiesen. Nach einer kettenübergreifenden Transaktion wird die Kapazität des Operationspools auf 9,9 SIPC reduziert. In diesem Fall erhalten die Bergleute in der Hauptkette im Allgemeinen die Transaktionsformalitätsgebühr S '(20 + 0,01), wobei 0,01 die Belohnung für die Mikroinflationsanpassung ist.

Jeder SimpleChain-Benutzer kann festlegen, dass SIPC erneut in den Pool eingefügt wird. Benutzer können auch die Untergrenze des Aktivitätsgrades auslösen, indem sie einen Subkettenkonsens verwenden und die Belohnungen für Cross-Chain-Miner ändern, sodass S2 für Cross-Chain-Miner ein negativer Wert ist, dh einige der Gebühren für Cross-Chain-Transaktionsformalitäten sind im Operation Tool für Unterketten gespeichert. Zu diesem Zeitpunkt beträgt die Mikroinflationsprämie K für die von gewöhnlichen Bergarbeitern in der Hauptkette erhobenen Formalitätsgebühren 0 oder einen negativen Wert. Dies weist darauf hin, dass sich Unterketten in einer Rezession befinden oder dass sich Unterketten und Hauptketten durch Verringern des gegenseitigen Reizes trennen.

Zu den potenziellen Risiken im oben genannten Modus gehören die Obergrenze für kettenübergreifende Transaktionen in Blöcken auf Hauptketten und Überlastungen auf Hauptketten.

In Bezug auf das Wirtschaftsmodell sind „Lose-Lose“ -Angriffe möglich: Das Interesse sowohl der Bergleute an Hauptketten als auch der Benutzer kann durch das Erstellen von Dämpfungsunterketten beeinträchtigt werden.

[1]. BitInforCharts (2019) Historisches Diagramm zur Bitcoin-Blockgröße, verfügbar unter: https://bitinfocharts.com/comparison/bitcoin-size.html [Accessed on 02/04/2019]
[2]. Buterin. V (2015) Über langsame und schnelle Blockzeiten, verfügbar unter: https://blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times/ [Accessed on 04/04/2019]
[3]. Buterin. V (2019) Zusammenführen von Blöcken und synchrone Ausführung des Cross-Shard-Status. Verfügbar unter: https://ethresear.ch/t/merge-blocks-and-synchronous-cross-shard-state-execution/1240 [Accessed on 03/04/2019]
[4]. Buterin. V (2019) Wie können wir Cross-Shard-Kommunikation erleichtern ?, Verfügbar unter: https://github.com/ethereum/wiki/wiki/Sharding-FAQ#was-ist-das-train-und-hotelproblem [Accessed on 03/04/2019]
[5]. Prestwich. J (2019) Was zu erwarten ist, wenn eths erwartet, Chinesische Version Übersetzt von EthFans, Verfügbar unter https://ethfans.org/posts/what-to-expect-when-eths-expecting [Accessed on 02/04/2019]
[6]. Skidanov. A (2019) Der maßgebliche Leitfaden zum Blockchain-Sharding, Teil 1, Chinesische Version Übersetzt von EthFans, erhältlich unter: https://ethfans.org/posts/the-authoritative-guide-to-blockchain-sharding-part-1 [Accessed on 02/04/2019]
[7]. Skidanov. A (2019) Die maßgebliche Anleitung zum Blockchain-Sharding Teil 2: Ungelöste Probleme beim Blockchain-Sharding, Chinesische Version Übersetzt von EthFans, https://ethfans.org/posts/unsolved-problems-in-blockchain-sharding [Accessed on 02/04/2019]
[8]. Zamir. V (2018) Casper, Ethereum Community Conference vom 8. bis 10. März 2018, erhältlich unter: https://www.youtube.com/watch?v=GNGbd_RbrzE[Accessed on 03/04/2019]

Coins Kaufen: Bitcoin.deAnycoinDirektCoinbaseCoinMama (mit Kreditkarte)Paxfull

Handelsplätze / Börsen: Bitcoin.de | KuCoinBinanceBitMexBitpandaeToro

Lending / Zinsen erhalten: Celsius NetworkCoinlend (Bot)

Cloud Mining: HashflareGenesis MiningIQ Mining

Werbung: Immobilienmakler HeidelbergMakler Heidelberg

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close