I Einführung
1: Überblick
Plattformen für Smart Contracts und Kryptowährungen wie Ethereum und Bitcoin haben viel Aufmerksamkeit erregt und sich zu praktikablen Optionen für dezentrale Apps, elektronische Zahlungen und mögliche digitale Wertspeicher entwickelt.
Aber die aktuelle Situation zeigt, dass die angebotenen öffentlichen Blockchain-Entwicklungen erhebliche Einschränkungen haben, insbesondere im Hinblick auf die Skalierbarkeit, wenn man sie mit ihren zentralisierten Äquivalenten in den wichtigen Messgrößen vergleicht. Dies behindert ihre breite Akzeptanz und verzögert die öffentliche Nutzung. Tatsächlich hat es sich als unglaublich schwierig erwiesen, die aktuellen technischen Einschränkungen zu bewältigen, die durch die Kompromisse im Paradigma des Blockchain-Trilemmas entstehen. Obwohl viele Alternativen vorgeschlagen wurden, haben nicht viele zu nennenswerten und praktikablen Ergebnissen geführt.
Daher ist ein gründliches Überdenken öffentlicher Blockchain-Infrastrukturen erforderlich, um das Problem der Skalierbarkeit anzugehen.
2 Die Schwierigkeiten skizzieren
Um ein öffentliches Blockchain-System zu entwickeln, das skalierbar ist, müssen eine Reihe von Problemen angemessen angegangen werden:
- Vollständige Dezentralisierung: Dadurch wird die Möglichkeit einer zentralen Fehlerquelle beseitigt, da keine vertrauenswürdigen Dritten erforderlich sind;
- Starke Sicherheit:
- Hohe Skalierbarkeit: Dadurch kann das Netzwerk ein Leistungsniveau erreichen, das mindestens dem seines zentralisierten Gegenstücks entspricht, gemessen in TPS (Transaktionen pro Sekunde);
- Effizienz: Alle Netzwerkfunktionen werden mit minimalem Energie- und Rechenaufwand ausgeführt;
- Bootstrapping (Finanzierung ohne Fremdkapital) und Speichererweiterung: Dies gewährleistet wettbewerbsfähige Kosten für die Datenspeicherung und -synchronisierung;
- Cross-Chain Kompatibilität: ist durch das System vorgegeben und ermöglicht eine uneingeschränkte Kommunikation mit externen Diensten.
Wir haben Stake.ch als umfassende Neuinterpretation der öffentlichen Blockchain-Infrastruktur entwickelt, mit Schwerpunkt auf Sicherheit, Effizienz, Skalierbarkeit und Kompatibilität, ausgehend von den oben aufgeführten Themen. Der Hauptbeitrag von Stake.ch basiert auf zwei grundlegenden Komponenten:
Eine echte Sharding-Methode, die die Blockchain und den Kontostatus in mehrere Shards (einzelne Ketten im Netzwerk der Blockchain) aufteilt, die gleichzeitig von verschiedenen Prüfern verwaltet werden;
Ein sicherer Proof-of-Stake (Anteilsnachweis) Mechanismus, als eine erweiterte Version eines Anteilsnachweis, welches eine faire Verteilung und langfristige Sicherheit garantiert, ohne energieintensive PoW-Algorithmen (Proof of Work) zu erfordern.<768195bc- e3ea-eccc>
3 Zuverlässiger Nachweis des Staking-Einsatzes
Als Erweiterung des Algorand-Konzepts bezüglich eines zufälligen Auswahlprozesses, stellen wir einen sicheren Proof-of-Stake-Mechanismus vor, der sich aus den unten aufgeführten Gründen auszeichnet:
1) Stake.ch bietet eine Verbesserung, die die Latenzzeit verringert indem es jedem Shard-Node (Teilstücke in einer Netzwerkgruppe) ermöglicht, zu Beginn jeder Runde den Block-Proposer und Validatoren für die Gruppe auszuwählen. Möglich wird dies durch den Zufallsfaktor x, der vom Block-Proposer mithilfe einer BLS-Signatur aus dem vorhergehenden x generiert und in jedem Block gespeichert wird.
2) Der Prüfer der Netzwerkgruppe mit dem kürzesten Hash des öffentlichen Schlüssels und des Zufallsfaktors ist der Proposer des Blocks.
Im Vergleich zur Methode von Algorand, die bis zu 12 Sekunden für die zufällige Auswahl des Ausschusses benötigen kann, benötigt die Methode von Stake.ch viel weniger Zeit – etwa 70 ms, Netzwerklatenz nicht mitgerechnet – für die zufällige Auswahl der Netzwerkgruppe.
3) Stake.ch verbessert seinen Konsens-Mechanismus, indem es zusätzlich zum Staking-Faktor, der normalerweise in PoS-Systemen als einziger Entscheidungsfaktor verwendet wird, ein zusätzliches Gewichtungselement namens Rating einschließt. Die Wahrscheinlichkeit, dass ein Node (Teilstück) für die Aufnahme in die Konsensgruppe ausgewählt wird, basiert sowohl auf der Bewertung als auch auf dem Einsatz. Die Bewertung eines Blockanbieters wird am Ende jeder Epoche aktualisiert, mit Ausnahme von Situationen, in denen Rating-Abschläge erforderlich sind. Dies fördert die Leistungsorientierung und bietet ein zusätzliches Maß an Sicherheit.
II Besitz der cDEXgroup
Die cDEX-Gruppe ist unsere Eigentümerin im Bereich dezentraler Kryptowährungsbörsen (DEXs) und damit verbundener Blockchain-Technologie.
- Es gibt einige Schlüsselaspekte der cDEXgroup-Partnerschaft:
Handelspartnerschaft: cDEX-Plattformen unterstützen typischerweise Handel zwischen verschiedenen Kryptowährungen, sodass Benutzer einen digitalen Vermögenswert gegen einen anderen austauschen können.
Benutzeroberfläche und Erfahrung: Benutzerfreundliche Schnittstellen und ein intuitives Handelserlebnis sind entscheidend für die Gewinnung und Bindung von Benutzern auf dezentralen Börsenplattformen.
Sicherheit: Sicherheit ist im Bereich von Kryptowährungen von größter Bedeutung. Die cDEX-Plattform implementiert robuste Sicherheitsmaßnahmen, um die Geldmittel der Nutzer zu schützen, unbefugten Zugriff zu verhindern und potenzielle Schwachstellen zu mindern.
Token-Angebote: cDEX-Plattformen können die Verwendung verschiedener Token und Vermögenswerte unterstützen, einschließlich gängiger Kryptowährungen sowie neuerer Projekte und Tokens, die in Blockchain-Netzwerken ausgegeben werden.
Community und Verwaltung: cDEXgroup integriert gemeinschaftlich gesteuerte Governance-Mechanismen, die es Benutzern ermöglichen, an Entscheidungsprozessen wie Protokollaktualisierungen, Gebührenstrukturen und der Nutzung von Vermögenswerten teilzunehmen.
III Arbitrage-Umgebung
Arbitrage-Handel mit Smart Contracts (automatisch ausgeführte, digitale Verträge) umfasst die Nutzung der Fähigkeiten von Blockchain-basierten Smart Contracts, um Arbitrage-Strategien in dezentralen Finanzsystemen (DeFi) zu automatisieren und auszuführen. Smart Contracts sind selbstausführende Verträge, bei denen die Bedingungen der Vereinbarung direkt in den Code geschrieben werden. Sie laufen auf Blockchain-Netzwerken und setzen die Regeln und Bedingungen des Vertrags automatisch um.
So funktioniert der Arbitrage-Handel mit Smart Contracts normalerweise im Kontext von DeFi:
- Einbindung in das etablierte Netzwerk:
Die Zusammenarbeit mit einem etablierten Netzwerk, um Smart Contacts für den Arbitrage-Handel in DeFi zu erhalten, umfasst typischerweise mehrere Schritte:
Forschung und Networking: Die Entwickler beginnen mit der Recherche und dem Austausch innerhalb der DeFi-Gemeinschaft, um nach seriösen Einzelpersonen, Teams oder Organisationen zu suchen, die sich auf die Entwicklung intelligenter Verträge (Smart Contracts) für den Arbitrage-Handel spezialisiert haben. Dies kann die Teilnahme an Blockchain-Konferenzen, den Beitritt zu Online-Foren und Communities sowie die Vernetzung mit erfahrenen Fachleuten im DeFi-Bereich umfassen.
Due Diligence/Sorgfältige Prüfung: Bevor man mit einer Partei für Smart Contacts zusammenarbeitet, ist es wichtig eine Due-Diligence-Prüfung durchzuführen, um deren Glaubwürdigkeit, Erfolgsbilanz, Fachwissen und ihren Ruf innerhalb des DeFi-Systems zu bewerten. Dies kann die Überprüfung früherer Projekte, die Untersuchung von Codes und die Suche nach Referenzen oder Empfehlungen von früheren Kundinnen und Kunden beinhalten.
Engagement und Zusammenarbeit:: Sobald ein geeigneter Partner oder ein geeignetes Entwicklungsteam identifiziert ist, können Händler an Besprechungen teilnehmen, um ihre spezifischen Anforderungen, Ziele und Erwartungen an die Smart Contracts darzulegen. Dies könnte die Definition der Arbitrage-Strategien, die Festlegung von Parametern und Bedingungen, sowie technische Überlegungen, wie Sicherheit, Skalierbarkeit und Kompatibilität mit bestehenden DeFi-Protokollen umfassen.
Vertragsverhandlung:: Das Netzwerk und die Entwickler verhandeln die Vertragsbedingungen, einschließlich der Preise, Zahlungsbedingungen, Lieferfristen, Supportleistungen und alle anderen relevanten Vereinbarungen. Es ist wichtig, klare Kommunikationskanäle und Erwartungen festzulegen, um eine reibungslose und erfolgreiche Zusammenarbeit zu gewährleisten.
Vertragsentwicklung und -überprüfung: Das Entwicklerteam erstellt, testet und setzt die Smart Contracts gemäß den vereinbarten Vorgaben um. Entwickler können möglicherweise den Entwicklungsfortschritt überprüfen und Feedback dazu zu geben, Code-Audits durchführen und die Funktionalität und Sicherheit der Smart Contracts überprüfen, bevor sie fertiggestellt werden.
Bereitstellung und Integration: Sobald die Smart Contracts abgeschlossen und gründlich überprüft sind, werden sie auf dem entsprechenden Blockchain-Netzwerk oder der entsprechenden Blockchain-Plattform bereitgestellt. Vermittler arbeiten eng mit dem Entwicklungsteam zusammen, um die Smart Contracts in ihre Arbitrage-Infrastruktur zu integrieren, eine Verbindung zu relevanten DeFi-Protokollen herzustellen und eine nahtlose Ausführung von Arbitrage-Sitzungen mit den Kunden sicherzustellen, die für die Transaktionen vorgebucht sind. Laufende Unterstützung und Optimierung: Nach der Bereitstellung benötigen Händler möglicherweise fortlaufende Unterstützung, Wartung und Optimierungen durch Aktualisierungen oder Verbesserungen, um sich an veränderte Marktbedingungen anzupassen. Durch das Befolgen dieser Schritte und die Zusammenarbeit mit etablierten Netzwerken in der DeFi-Community, können Entwickler hochwertige Smart Contracts für den Arbitrage-Handel erhalten, die ihren Zielen entsprechen und ihnen helfen, dies finanziell zu nutzen. IV Dividenden Arbitrage So funktioniert Dividenden-Arbitrage normalerweise: Unternehmen geben die Dividendenzahlungstermine normalerweise lange im Voraus bekannt. Zu diesen Daten gehören das Ex-Dividenden-Datum (das Datum, nach dem ein Käufer der Aktie die bevorstehende Dividende nicht mehr erhalten würde), der Stichtag (das Datum) an dem die Aktionäre eingetragen sein müssen, um die Dividende zu erhalten) und das Zahlungsdatum (wann die Dividende tatsächlich an die Aktionäre ausgezahlt wird). Dividenden-Arbitrage-Händler suchen nach Diskrepanzen zwischen dem Aktienkurs und dem Preis der damit verbundenen Optionen oder Derivate, insbesondere rund um den Ex-Dividendentag. Sie analysieren die Dividendenrendite, die implizite Volatilität, Optionspreise und andere relevante Faktoren, um potenzielle Arbitrage-Möglichkeiten zu identifizieren.
Wenn eine Arbitrage-Möglichkeit identifiziert wird, können Agenten einen von mehreren Ansätzen wählen: Long/Short-Aktien und Optionen: Sie können die zugrunde liegende Aktie kaufen und gleichzeitig Call-Optionen verkaufen (Covered Call) oder Put-Optionen kaufen (Protective Put), um ihre Position abzusichern. Box Spread (Streuung): Vermittler können gleichzeitig eine Call-Option kaufen und eine Put-Option zu einem Basispreis verkaufen, während sie gleichzeitig eine Call-Option verkaufen und eine Put-Option kaufen zu einem anderen Basispreis, alle mit demselben Ablaufdatum. Dies schafft eine risikofreie Arbitrage-Möglichkeit, wenn die Optionen falsch bewertet sind. Dividendenerfassungsstrategie: Händler können die Aktie kurz vor dem Ex-Dividendendatum kaufen, um die Dividende zu erhalten, und sie dann kurz danach verkaufen. Sie können auch gleichzeitig Put-Optionen kaufen, um sich während der Haltedauer gegen mögliche Verlustrisiken abzusichern. Während Dividendenarbitrage profitabel sein kann, birgt sie auch Risiken, einschließlich Marktvolatilität, Änderungen der Dividendenpolitik und Ausführungsrisiken im Zusammenhang mit dem Optionshandel. Vermittler implementieren Risikomanagementstrategien, um diese Risiken zu mindern, z. B. Durch das Setzen von Stop-Loss-Orders, die Diversifizierung ihres Portfolios und die Absicherung ihrer Positionen. Insgesamt ist Dividendenarbitrage eine komplexe Handelsstrategie, die ein tiefes Verständnis der Optionspreise, der Dividendenpolitik und der Marktdynamik erfordert. Agenten, die Dividenden-Arbitrage-Strategien erfolgreich umsetzen, können möglicherweise von Preisunterschieden zwischen Aktien und den damit verbundenen Optionen profitieren, insbesondere rund um Dividendenzahlungstermine. Der Ex-Dividendentermin einer Aktie (oder kurz Ex-Termin) ist ein entscheidendes Datum um zu bestimmen, welche Aktionäre Anspruch darauf haben und die Dividende ausgezahlt bekommen. Dies ist eine von vier Phasen der Dividendenauszahlung. Datum der Erklärung:Ist das Datum an dem das Unternehmen ankündigt, künftig eine Dividende auszuschütten. Ex-Dividenden Termin:Der Ex-Dividenden Termin wird normalerweise zwei Werktage vor dem Stichtag festgelegt.<3cd7815a-9d50- c75d>
Zahlungsdatum: Die vierte und letzte Stufe ist der Zahlungstermin. Es markiert den Zeitpunkt, an dem die Dividende an berechtigte Aktionäre ausgezahlt wird. Mit anderen Worten: Sie müssen nicht nur am Stichtag, sondern auch schon davor eingetragener Aktionär einer Aktie sein. Nur diejenigen Aktionäre, die ihre Aktien mindestens zwei volle Geschäftstage vor dem Stichtag besaßen, haben Anspruch auf die Dividende. V Kreditvergabe im Defi-Umfeld So funktioniert die Kreditvergabe in DeFi: Besicherung: Kreditnehmer auf DeFi-Kreditplattformen stellen typischerweise Sicherheiten in Form von Kryptowährungsaktiva zur Verfügung, um ihre Kredite abzusichern. Der Wert der Sicherheit muss den Wert der geliehenen Vermögenswerte übersteigen, um das Ausfallrisiko zu mindern. Smart Contracts: Kredit- und Kredittransaktionen werden über Smart Contracts ausgeführt, die in Blockchain-Netzwerken wie Ethereum eingesetzt werden. Diese intelligenten Verträge setzen automatisch die Bedingungen des Darlehens durch, einschließlich Zinssätzen, Rückzahlungsplänen und Sicherheitenanforderungen. Zinssätze: Die Zinssätze für Kreditaufnahmen und Kreditvergaben werden durch die Angebots- und Nachfragedynamik auf der Kreditplattform bestimmt. Sie können aufgrund von Faktoren wie Marktbedingungen, Vermögensliquidität und Benutzernachfrage schwanken. Risikomanagement: Sowohl Kreditgeber als auch Kreditnehmer müssen die mit der DeFi-Kreditvergabe verbundenen Risiken bewerten und verwalten. Kreditgeber sind dem Risiko eines Zahlungsausfalls von Kreditnehmern oder Schwachstellen bei Smart Contracts ausgesetzt, während Kreditnehmer Gefahr laufen, liquidiert zu werden, wenn der Wert ihrer Sicherheiten unter einen bestimmten Schwellenwert fällt. Liquidation: Wenn der Wert der Sicherheiten eines Kreditnehmers erheblich sinkt, kann der Smart Contract die Sicherheiten automatisch liquidieren, um die Sicherheiten an den Kreditgeber zurückzuzahlen und sich vor Verlusten zu schützen. Liquidationsmechanismen variieren je nach Kreditplattform und den spezifischen Bedingungen des Kredits. Integration mit anderen DeFi-Protokollen: Insgesamt bietet die Kreditvergabe in DeFi im Vergleich zu herkömmlichen zentralisierten Kreditsystemen eine Reihe von Vorteilen, darunter Zugänglichkeit, Transparenz und Interoperabilität. Es birgt jedoch auch Risiken, darunter Schwachstellen bei intelligenten Verträgen, Marktvolatilität und regulatorische Unsicherheiten, die Benutzer sorgfältig berücksichtigen und bewerten müssen, wenn sie an DeFi-Kreditaktivitäten teilnehmen. VI Die Umgebung im Überblick. 1.Instanzen Stake.ch besteht aus drei Haupteinheiten: das Netzwerk, Nutzer und Geräte (Nodes). Das Stake.ch-Netzwerk ermöglicht es Benutzern mit einer begrenzten Anzahl öffentlicher/privater Schlüsselpaare signierte Transaktionen für Wertübertragungen oder die Ausführung intelligenter Verträge einzusetzen. Kontoadressen (abgeleitet aus öffentlichen Schlüsseln) können zur Identifizierung der Nutzer verwendet werden. Die Geräte im Stake.ch-Netzwerk, sogenannte Nodes, können bei Verarbeitungsaktivitäten entweder passiv oder aktiv sein. Um berechtigt zu sein, müssen Validatoren aktiv am Stake.ch-Netzwerk teilnehmen. Sie sind dafür verantwortlich, einen Grundkonsens herbeizuführen, Blöcke hinzuzufügen, den Zustand aufrechtzuerhalten und erhalten Belohnungen für ihre Bemühungen. Zur eindeutigen Identifizierung jedes Prüfers wird ein öffentlicher Schlüssel verwendet, eine Ableitung der eingesetzten Adresse und Geräte-ID.
Darüber hinaus ist das Netzwerk in kleinere Teile, sogenannte Shards, unterteilt. Ein Algorithmus weist jedem Shard basierend auf der Baumebene einen geeigneten Validator zu und sorgt so für eine gerechte Verteilung der Geräte. Jeder Shard hat eine zufällig bestimmte Gruppe. Blockanbieter sind dafür verantwortlich, Transaktionen in neuen Blöcken zusammenzufassen. Validatoren prüfen vorgeschlagene Blöcke und übergeben sie an die Blockchain. Sie können sie ablehnen oder genehmigen. 2. Chronologie Das Stake.ch-Netzwerk unterteilt die Zeitlinie in Epochen und Runden. Epochen haben einen definierten Zeitraum von einer Woche, der angepasst werden kann, wenn sich die Architektur weiterentwickelt. Am Ende werden die Shards neu geordnet und gekürzt. Epochen sind in Runden organisiert, jede mit einem bestimmten Zeitrahmen. In jeder Runde wird für jeden Shard eine neue Gruppe zufällig ausgewählt, mit der Möglichkeit, bis zu einen Block in das Shard-Konto einzutragen. 1: Warum Aufteilung (Sharding)? Sharding ist eine Möglichkeit, Daten aus Datenbanken auf zahlreiche Geräte zu verteilen. Diese Skalierungsstrategie kann in Blockchains verwendet werden, um Zustände und Transaktionsverarbeitung aufzuteilen, sodass jeder Netzknoten (Node) nur einen Prozentsatz der Transaktionen gleichzeitig mit anderen verarbeiten kann. Die Aufteilung einer Blockchain in Shards kann den Transaktionsmenge und die Effizienz verbessern, indem mehrere Transaktionen parallel verarbeitet werden – vorausgesetzt, es gibt genügend Knotenpunkte, die jede Transaktion verifizieren, um eine hohe Zuverlässigkeit und Sicherheit zu gewährleisten. Sharding, auch als horizontale Skalierbarkeit bekannt, erhöht die Leistung, wenn das Validatorennetzwerk erweitert wird.
Diese umfassende Einführung behandelt drei Arten von Sharding: Netzwerk-, Transaktions- und Status-Sharding. Netzwerk-Sharding gruppiert Geräte in Shards, um die Kommunikation zu verbessern. Nachrichten können innerhalb eines Shards schneller verbreitet werden als im gesamten Netzwerk. Das erste Problem beim Sharding besteht darin sicherzustellen, dass das System, das einzelne Knotenpunkte Shards zuordnet, potenzielle Bedrohungen berücksichtigt, sollte ein Angreifer die Kontrolle über einen bestimmten Shard erlangen. Transaktions-Sharding ordnet Transaktionen den entsprechenden Shards zur Verarbeitung zu. In einem kontobasierten System können Transaktionen je nach der Absenderadresse bestimmten Shards zugewiesen werden.
Um die Widerstandsfähigkeit gegenüber böswilligen Angriffen zu erhöhen, werden die Knotenpunkte in Shards regelmäßig neu geordnet. Das Verschieben von Knoten zwischen den Shards verursacht einen Synchronisierungsaufwand, zu dem auch die Zeit gehört, die neu verbundene Nodes benötigen, um den neuesten Status zu erhalten. Um Ausfallzeiten während der Synchronisierung zu vermeiden, sollte nur eine Teilmenge der Nodes pro Epoche neu verteilt werden.
Der Ansatz von Stake.ch im Bereich Netzwerk-, Transaktions- und State-Sharding zielt darauf ab, die folgenden Ziele zu erreichen: 1) Skalierbarkeit ohne Beeinträchtigung der Verfügbarkeit: Das Erhöhen oder Verringern der Anzahl der Shards sollte minimale Auswirkungen auf die Knotenpunkte haben. 2) Versand und sofortige Rückverfolgbarkeit: Das Finden des Ziel-Shards einer Transaktion sollte deterministisch und trivial zu berechnen sein, sodass keine Kommunikationsrunden erforderlich sind. 3) Effizienz und Anpassung: Shards sollten so ausgewogen wie möglich sein. Technische Spezifikationen: Um die optimale Anzahl von Shards in der Epoche ei+1 (Nsh,i+1) zu bestimmen, legen wir einen Schwellenkoeffizienten für die Anzahl der Transaktionen in einem Block fest, θTX. Die Variable optN bestimmt die ideale Anzahl von Knoten in einem Shard, während ϵsh eine positive Zahl ist, die die Anzahl der Knoten angibt, die variieren können. In Epoche ei bezieht sich „totalNi“ auf die Gesamtzahl der Knoten auf allen Shards, einschließlich berechtigter Validatoren, Wartelisten und neu hinzugefügter Knoten im Knotenpool. NTXB,i ist die durchschnittliche Anzahl von Transaktionen in einem Block über alle Shards in dieser Epoche. Nsh,0 wird als eins behandelt. Die Gesamtzahl der Shards (Nsh,i+1) ändert sich basierend auf der Gesamtzahl der Knoten (Ni), wenn sich das Netzwerk ändert und der Blockchain-Verbrauch dies erfordert: Wenn die Anzahl der Knoten einen Schwellenwert zwischen Epochen (nSplit) und die durchschnittliche Anzahl von Transaktionen pro Block überschreitet. Die Funktion ComputeShardsN ermittelt, ob die Anzahl der Transaktionen pro Block (NTXB,i) mehr als θTX beträgt oder ob die Anzahl der Knoten unter einen bestimmten Schwellenwert fällt (nMerge). Die Anzahl der aktiven Knoten kann zwischen den Epochen variieren. Um die Anzahl der Shards zu erhalten, berechnen Sie die Masken m1 und m2, die für die Transaktionsverteilung verwendet werden. Der Sharding-Ansatz verwendet eine binäre Baumstruktur, um Kontoadressen zu verteilen, die Skalierbarkeit zu optimieren und Zustandsübergänge zu verarbeiten. Die angegebene Baumstruktur stellt die Kontoadressen für deterministische Zuordnungen dar, z. B. zur Shard-Zuweisung und Berechnugnsverfahren. Die Blätter des Binärbaums stellen anhand ihrer ID-Nummern Shards dar. Wenn es nur einen Shard/Blatt (a) beginnend an der Wurzel (Node/Shard 0) gibt, werden ihm alle Kontoadressen zugeordnet und alle Transaktionen werden dort verarbeitet. 1: Funktion COMPUTESHARD(Nsh, addr, m1, m2) 2: Shard ← (addr und m1) 3: if shard > Nsh
dann 4: Shard ← (addr und m2) 5: Shard zurückgeben Root Shard   sp; 
; /
\ nbsp ; Shard
A Shard B /
\ /
\ Shard AA Shard AB Shard BA Shard BB Der Baum kann instabil werden (c), wenn Nsh keine Potenz von 2 ist. Diese Instanz wirkt sich nur auf Blätter auf der letzten Ebene aus. Die Struktur wird das Gleichgewicht wiedererlangen, wenn die Anzahl der Shards eine Potenz von 2 erreicht. Der unausgeglichene Binärbaum führt dazu, dass Shards auf der untersten Ebene nur halb so viel Adressraum haben wie Shards auf höheren Ebenen. Dies kann zu geringeren Gebühreneinnahmen für aktive Nodes (Knotenpunkte) führen, die diesen Shards zugewiesen sind, die Blockbelohnungen bleiben jedoch davon unberührt. Um dieses Problem zu beheben, wird ein Drittel der Shard-Knoten in jeder Epoche zufällig neu zugewiesen (siehe Abschnitt „Chronologie“) und eine ausgewogene Verteilung der Knoten dadurch beibehalten. Die Kenntnis von Nsh ermöglicht es jedem Knoten, den Umverteilungsprozess ohne Kontakt zu verfolgen. Die Zuweisung von IDs für die neuen Shards erfolgt inkrementell und die Reduzierung der Anzahl der Shards erfordert, dass die Shards mit höheren Nummern entfernt werden. Beim Zusammenführen von zwei Shards wird der Shard mit der höchsten Nummer (shmerge=Nsh-1) gelöscht. Es ist einfach, die Shard-Nummer zu finden, mit der shmerge zusammengeführt wird. Die Baumstruktur weist dem resultierenden Shard die Nummer seines Gegenstücks zu. Um Redundanz, Nachverfolgbarkeit von Zustandsübergängen und eine schnelle Skalierung sicherzustellen, ist
es wichtig, das gleichgeordnete und übergeordnete Element eines generischen Shards mit der Nummer p: 1: Funktion COMPUTEPARENTSIBLINGS(n, p, Nsh) <4b89a86a-478 5
-a951> Herausfordernde Schwachstellen State Sharding (das Aufteilen des Netzwerks) auf der Blockchain kann aufgrund fehlender Online-Knoten oder einer geografisch begrenzten Verteilung scheitern. Wenn ein Shard ausfällt (z. B. alle Knoten sind offline oder mehr als 13 Knotenpunkte antworten nicht), verlässt sich die Architektur möglicherweise ausschließlich auf Full-Nodes (Knotenpunkte mit einer vollständigen Kopie der Blockchain), um jeden Block von allen Shards herunterzuladen und zu überprüfen. Unser Protokoll erzwingt einen Kompromiss in der Haltestruktur, indem es von Shards auf der letzten Baumebene verlangt, den Status ihrer Geschwister zu halten.
Diese Methode macht ein Bootstrapping-Verfahren beim Kombinieren von Geschwister-Shards überflüssig, da diese bereits über die erforderlichen Daten verfügen . Änderung der Umgebung Kontextwechsel sind entscheidend für die Gewährleistung der Sicherheit in aufgeteilten öffentlichen Blockchains. Es werden zufällige Kriterien verwendet, um aktive Netzwerkknoten in vorgegebenen Intervallen zwischen den Shards neu aufzuteilen. Die Methode von Stake.ch verbessert die Sicherheit durch Kontextwechsel, erhöht jedoch die Komplexität, um die Konsistenz über verschiedene Zustände hinweg sicherzustellen. Shard-Redundanz zwischen den Epochen | Epoche 1 | Epoche 2 | Epoche 3 | Epoche 4 | ——————————————————— ——————- Shard 1 | X | X |
X | X | Shard 2 | X | X |
X | X | Scherbe 3 | X | X |
X | X | Shard 4 | X | X |
X | X | Diese Methode verhindert wirksam die Bildung schädlicher Gruppen. Legalisierung Alle Netzwerk- und globalen Datenaktionen (Knotenbeitritt zum Netzwerk und Verlassen des Netzwerks, Berechnung berechtigter Validatorlisten, Zuweisung von Knoten zu Shard-Wartelisten, Konsensvereinbarung über einen Block in einem bestimmten Shard und Herausforderungen bei ungültigen Blöcken) wird in der Metachain notariell beglaubigt. Der Metachain-Konsens wird von einem separaten Shard verwaltet, der mit anderen Shards kommuniziert und Shard-übergreifende Aktivitäten ermöglicht. In jeder Runde jeder Epoche erhält die Metachain Blockteile von den anderen Shards sowie Nachweise für ungültige Blockaufgaben. Die Informationen werden in Blöcken auf der Metachain gesammelt, um einen Konsens zu ermöglichen. Nach der Blockvalidierung in der Konsensgruppe können Shards sichere segmentübergreifende Transaktionen durchführen, indem sie Informationen über Blöcke, Miniblöcke, Validatoren und wartende Knotenpunkte anfordern. VIII Vereinbarung mit SPoS (Netzwerksicherheit) Bitcoin, Ethereum und andere Blockchain-Plattformen verwenden den ersten Blockchain-Konsensalgorithmus, PoW. Beim Proof of Work (Nachweis der Arbeit) muss jeder Knoten eine mathematische Herausforderung lösen, die schwer zu berechnen, aber trivial zu überprüfen ist. Der erste Knoten, der das Problem löst, erhält den Preis. Proof of Work verhindert doppelte Ausgaben, DDoS- und Sybil-Angriffe, aber erfordert einen erheblichen Energieverbrauch. Proof of Stake (PoS) ist eine effizientere Konsenstechnik im Vergleich zu Proof of Work, das mehr Energie und Rechenressourcen erfordert. Die PoS-Technologie kann in aufstrebenden Systemen wie Cardano [und Algorand sowie in der nächsten Version von Ethereum] vorhanden sein. In PoS schlagen Knoten den nächsten Teilnehmenden Block basierend auf Einsatz, Zufälligkeit und/oder Alter vor. Es befasst sich zwar mit dem PoW-Energieproblem, wirft aber auch Bedenken hinsichtlich des Nothing at Stake-Angriffs und der zunehmenden Zentralisierung auf. Bitshares, Steemit und EOS verwenden Delegated Proof of Stake (DPoS), eine Mischung aus Proof of Authority und Proof of Stake. Dabei wählen Teilnehmer eine kleine Anzahl von Knoten aus, die für die Verteilung neuer Blöcke verantwortlich sind. Trotz seiner großen Leistungsmöglichkeiten ist dieser Ansatz anfällig für soziale Probleme durch Menschen, einschließlich Bestechung und Korruption. Die geringe Anzahl an Delegierten macht das System anfällig für DDoS-Angriffe und Zentralisierung. Zuteilung der Teilnahme bei stake.ch Stake.ch nutzt Kurvenkryptographie für die Zuteilung von Blöcken und nutzt das BLS-Mehrfachsignaturschema über die bilineare bn256-Gruppe und den Optimal at Pairing-Algorithmus über eine 256-Bit-Barreto-Naehrig-Kurve. Die bilineare Kopplung ist definiert als e: g0 × g1 → gt (1), wobei g0, g1 und gt elliptische Kurven der durch bn256 angegebenen Primzahlordnung p sind und e eine Paarfunktion ist. G0 und G1 sind die Generatoren für g0 und g1. Man betrachte H0 als eine Hashing-Funktion, die Punkte auf der Kurve bildet g0: H0: M → g0. M stellt die Menge aller möglichen binären Nachrichten beliebiger Länge dar. Die Signaturstrategie von Stake.ch umfasst eine zweite Hash-Funktion mit gemeinsamen Parametern für alle Teilnehmenden. H1: M → Zp (3) Jeder Unterzeichner I verfügt über eine einzigartige private/öffentliche Schlüsselkombination (ski, P ki), wobei ski zufällig aus Zp ausgewählt wird. Für jedes Schlüsselpaar gilt die Eigenschaft P ki = ski · G1. In Stake.ch stellt X,
In der ersten Runde der praktischen Zuteilung: Der Leiter der Konsensgruppe erstellt, unterzeichnet und sendet einen Block für Transaktionen an seine Mitglieder. In Runde 2 validieren Mitglieder der Konsensgruppe (einschließlich des Leiters) den Block und signieren ihn mit BLS, bevor sie ihn an den Leiter senden. Sigi = Ski × H0(m) Die dritte Runde der praktischen Zuweisung: Der Leiter wartet innerhalb eines definierten Zeitrahmens auf Unterschriften. Die Konsensrunde wird abgebrochen, wenn innerhalb des angegebenen Zeitrahmens nicht mindestens 2·3·n + 1 Unterschriften eingehen. Wenn der Leiter 2·3·n + 1 gültige Signaturen erhält, werden diese zur Erstellung der aggregierten Signatur verwendet. SigAgg = X i H1(P ki) · Sigi · B[i]. Praktische Überprüfung: Der Prüfer berechnet den aggregierten öffentlichen Schlüssel basierend auf der Liste der öffentlichen Schlüssel L, der Unterzeichner-Bitmap B, der aggregierten Signatur SigAgg und der Nachricht m (Block). P kAgg = X i · H1(P ki) · Bi (6). P kAgg repräsentiert einen Punkt auf g1. Der endgültige Nachweis ist e(G1, SigAgg) == e(P kAgg, H0(m)) (7), wobei e die Paarfunktion darstellt. IX Smart Contracts Zukünftige Blockchain-Architekturen werden stark auf der Ausführung intelligenter Verträge (Smart Contracts) basieren. Die aktuell bestehenden Lösungen können Transaktionen und Datenabhängigkeiten oft nicht ausreichend beschreiben. Dieser Kontext führt zu den folgenden zwei Szenarien: Out-of-Order-Planung kann in jeder Systemarchitektur verwendet werden, wenn Smart-Contract-Transaktionen keine direkte Verknüpfung haben. Ein Smart Contract kann jederzeit und auf jedem Shard ohne weitere Einschränkungen ausgeführt werden. Im zweiten Fall handelt es sich um parallele Transaktionen mit zugehörigen Smart Contracts. Dabei ist ein Mechanismus erforderlich, um sicherzustellen, dass Verträge in der richtigen Reihenfolge und im richtigen Shard (den einzelnen Teilen einer Blockchain) ausgeführt werden. Das Stake.ch-Protokoll bietet einen Mechanismus, um Smart Contracts auf denselben Shard wie deren festen Komponenten zu verlagern. Stake.ch verwendet die Stake.ch Virtual Machine, eine EVM-kompatible Umgebung. Das EVM (Ethereum Virtual Machine) ermöglicht die unabhängige Transaktionsverarbeitung für einfache Smart Contracts, die außerhalb der Reihenfolge ausgeführt werden können. Es bietet auch einen Mechanismus für verbundene Smart Contracts, die nacheinander abgeschlossen werden müssen. Angesichts der großen Anzahl intelligenter Verträge auf der Ethereum-Plattform ist die Einhaltung der Abstraktionsschichten für Smart Contracts von entscheidender Bedeutung für die Akzeptanz. Die Stake.ch Virtual Machine (virtuelle Datenverarbeitung) verbirgt die zugrunde liegende Architektur, trennt Smart-Contract-Entwickler von Systeminterna und bietet eine angemessene Abhängigkeit der Abstraktionsschichten. Dadurch wird sichergestellt, dass die meisten SC-Aufrufe Abhängigkeiten innerhalb desselben Shards haben, sodass kein Shard-übergreifendes Sperren und Entsperren erforderlich ist. Die Stake.ch Virtual Machine-Lösung isoliert Smart-Contract-Entwickler von Systeminterna, was zu einer guten Abstraktionsschicht führt. Cosmos hat einen Anpassungsmechanismus bei Stake.ch auf der Ebene der virtuellen Datenverarbeitung vorgeschlagen, um Blockhain-übergreifende Kompatibilität zu ermöglichen.
Diese Technik erfordert spezielle Adapter und ein externes Kommunikationsmedium für jede Kette, um mit Stake.ch zu interagieren. Spezialisierte Smart Contracts fungieren dabei als Vermögensverwalter, halten passende ketteneigene Tokens und geben ketteneigene Stake.ch-Tokens aus, um den Wertaustausch zu erleichtern. Die Infrastruktur virtueller Datenverarbeitung von Stake.ch basiert auf dem „S Framework“, einem ausführbaren semantischen Aufbau, das die Konstruktion von Programmiersprachen, Berechnungen, Systemen und formale Analysewerkzeuge ermöglicht. Die Verwendung des S-Frameworks ermöglicht eine klare Definitionen für intelligente Verträge und verringert so die Möglichkeit undeutlichem Verhalten und schwer zu erkennenden Fehlern. Das S Framework ist ausführbar und ermöglicht semantische Spezifizierungen, um als Dolmetscher für bestimmte Sprachen zu fungieren. Es gibt zwei Möglichkeiten, um die Programme gemäß ihrer Spezifikationen auszuführen: die direkte Verwendung der zentralen S Framework-Implementierung oder die Erstellung eines Übersetzers in mehreren Sprachen. Diese werden auch als „Backends“ bezeichnet. Stake.ch verwendet ein maßgefertigtes S-Framework-Backend für eine schnellere Ausführung und einfachere Zusammenarbeit. Vorgaben für Smart Contacts Das S Framework bietet den Vorteil, Übersetzungen für jede in S definierte Sprache zu generieren, ohne dass eine weitere Programmierung erforderlich ist. Dieser Prozess führt zu „systemgerechten“ Interpretationen. Mehrere Vertragssprachen für Smart Contacts sind entweder bereits im K Framework spezifiziert oder befinden sich in der Entwicklung. Das Stake.ch-Netzwerk unterstützt drei Low-Level-Programmiersprachen: IELE VM, KEVM und WASM. • IELE VM ist eine Blockchain-spezifische Programmiersprache im mittleren Niveau, die nach LLVM gestaltet ist. Die Spezifikationen und Implementierung dieser Funktion gibt es exklusiv für das S-Framework und sind nicht anderswo zu finden. Ziel ist es, die Lesbarkeit und Geschwindigkeit zu verbessern und Einschränkungen von EVMs zu überwinden. Stake.ch unterscheidet sich von IELE vor allem hinsichtlich der Verwaltung von Kontoadressen. Während Smart-Contract-Entwickler direkt in IELE programmieren können, bevorzugen die meisten die Verwendung eines Solidity-zu-IELE Übersetzers der Programmiersprache. • KEVM ist eine in S entwickelte Variante der Ethereum Virtual Machine (EVM). Die S-Version behebt einige EVM-Probleme, während andere vollständig entfernt wurden. • Web Assembly (WASM) ist ein binäres Befehlsformat für Stack-basierte virtuelle Maschinen, die Smart Contracts ausführen können. Mit der WASM-Infrastruktur können Entwickler Smart Contracts in mehreren Sprachen erstellen, darunter C/C++, Rust und C#. Das Erstellen einer Sprachspezifikation und die Entwicklung einer Übersetzung ist nur die halbe Herausforderung. Der verbleibende Teil umfasst die Integration der erstellten Übersetzung in das Stake.ch-Netzwerk. Unsere gemeinsame VM-Schnittstelle ermöglicht das einfache einsetzen jeder VM in einen Stake.ch-Knotenpunkt. Jede VM verfügt über einen Adapter, der die Schnittstelle implementiert. Verträge bleiben als Bytecode für die VM erhalten, für die sie erstellt und auf dieser VM ausgeführt wurden. Intelligente Verträge ermöglichen eine geschichtete Systemarchitektur Intelligente Verträge, die auf geteilten Strukturen basieren, befinden sich noch in der frühen Entwicklungsphase und stehen vor erheblichen Hindernissen. Als Ausgangspunkt dienen Atomix- und S-BAC-Protokolle. Das Verschieben von Smart Contracts auf denselben Shard (Einzelteil der Kette) berücksichtigt keine dynamischen Abhängigkeiten, da nicht alle Abhängigkeiten zum Zeitpunkt der Bereitstellung berechnet werden können. Eine Sperrtechnik ermöglicht die gezielte Ausführung von Smart Contracts über viele Shards hinweg und stellt so sicher, dass alle zugehörigen SCs gleichzeitig ausgeführt werden. Zeit oder gar keine. Dies beinhaltet mehrere Interaktionsnachrichten und die Synchronisierung zwischen einzelnen Shard-Konsensvereinbarungen. Die Idee für die Shard-übergreifende Vertragsausweitung in Ethereum 2.0 besteht darin, Smart-Contract-Codes und -Daten während der Ausführung auf den anfragenden Shard zu verschieben. Eine gleichzeitige Ausführung ist zwar nicht erforderlich, der übertragene SC muss jedoch über einen Sperrmechanismus verfügen, um die Ausführung weiterer Transaktionen zu verhindern. Die Sperrtechnik ist einfach, erfordert jedoch die Übertragung des gesamten internen Zustands des SC. Stake.ch folgt dem Modell von Ethereum und bietet die folgenden Transaktionsarten an: 1) SC-Konstruktion und Bereitstellung: Die Adresse des Transaktionsempfängers ist leer und das Datenfeld enthält den Smart-Contract-Code als Byte-Aufstellung. 2) Die Nutzung der SC-Methode erfordert eine Transaktion mit einer nicht leeren Empfängeradresse und dem dazugehörigen Code. 3) Zahlungsvorgänge erfordern eine nicht leeres Empfängerfeld und eine Adresse ohne Code. Stake.ch verwendet eine asynchrone Cross-Shard-Ausführungsarchitektur für Smart Contracts. Der Benutzer initiiert die Transaktionsausführung von Smart-Contracts. Wenn sich der Smart Contract nicht im aktuellen Shard befindet, wird die Transaktion als Zahlungstransaktion behandelt. Der Wert wird vom Absenderkonto abgezogen und dem Block hinzugefügt, in dem sich der Absender-Shard befindet, wodurch ein Miniblock für das Ziel-Shard erstellt wird, in dem sich das Empfängerkonto befindet.
Die Transaktion wird von der Metachain notariell beglaubigt und vom Ziel-Shard verarbeitet. Der Ziel-Shard behandelt die Transaktion als SC-Methodenaufruf, da die Empfängeradresse ein Smart Contract im Shard ist. Um den Smart Contract zu erstellen, wird ein temporäres Konto mit dem Guthaben des Absenders erstellt und der Transaktionswert zum Aufrufen des Vertrags verwendet. Nach der Ausführung kann der Smart Contract zu Ergebnissen führen, die sich auf viele Konten über verschiedene Shards hinweg auswirken. Alle Ergebnisse, die Konten in der selben Teilgruppe an Shards betreffen, werden in derselben Runde ausgeführt. Transaktionen von Smart Contract Ergebnissen werden für Konten durchgeführt, die sich nicht in dem Shard befinden, in dem der Smart Contract ausgeführt wurde. Diese Transaktionen speichern die Ausführungen für jedes Konto. SCR-Miniblöcke werden für jeden Ziel-Shard generiert. Miniblocks werden ähnlich wie Shard-übergreifende Transaktionen von der Metachain notariell beglaubigt und von den entsprechenden Shards verarbeitet, in denen die Konten gespeichert sind. Wenn ein Smart Contract einen dynamischen Aufruf an einen anderen Shard durchführt, wird der Aufruf als Zwischenergebnis aufgezeichnet und ähnlich wie Konten behandelt. Diese Methode umfasst zahlreiche Phasen und mindestens 5 Runden, um einen Shard-übergreifenden Smart-Contract-Aufruf abzuschließen. Es ist jedoch keine Sperrung oder Verschiebung über Shards hinweg erforderlich. Epochen Das Stake.ch-Protokoll legt für jede Epoche einen festen Zeitraum von 7 Tagen fest, der sich jedoch nach einigen getesteten Bestätigungsphasen ändern könnte. Während dieses Intervalls bleibt die Shard-Konfiguration konstant Das System passt die Anzahl der Shards basierend auf epochenspezifischen Skalierbarkeitsanforderungen an. Um Absprachen zu verhindern, sollte sich die Konfiguration jedes Shards nach jeder Epoche ändern. Obwohl die Umgruppierung aller Knoten über die Shards hinweg die Sicherheit erhöht, führt es aufgrund des Bootstrappings (Initialisierungsprozessen) auch zu zusätzlicher Verzögerung. Am Ende jeder Epoche werden weniger als die Hälfte der qualifizierten Prüfer von einem Shard auf nicht deterministische und konsistente Weise auf die Wartelisten anderer Shards übertragen. Der Umschichtungsprozess der Knoten umfasst mehrere Schritte: Jede Runde dauert 5 Sekunden. Aktualisierungen können nach mehreren Netz-Überprüfungsphasen erfolgen. In jeder Runde erstellen eine zufällig ausgewählte Anzahl an Block-Validatoren (einschließlich eines Antragstellers) in jedem Shard einen neuen Block. Die Liste der berechtigten Knotenpunkte wird verwendet, um die Menge zwischen den Runden zu aktualisieren, wie in Kapitel IV. beschrieben Die Umstrukturierung von Shards innerhalb von Epochen und die willkürliche Auswahl von Validatoren innerhalb von Runden verhindern unfaire Bündnisse, reduzieren DDoS- und Bestechungsversuche und sorgen für mehr Dezentralisierung und einen hohen Transaktionsdurchlauf. Zufallsquelle Stake.ch verwendet zufällige Zahlen für Vorgänge wie die Auswahl von Blockantragstellern und Validatoren für Konsensgruppen sowie das Mischen von Knoten zwischen Shards am Ende einer Epoche. Diese Dinge stärken die Sicherheitsgarantien von stake.ch. Um die Genauigkeit zu gewährleisten, sollte nachgewiesen werden, dass Zufallszahlen unvoreingenommen und unvorhersehbar sind. Die Zufallszahlengenerierung muss für den Einsatz in Blockchain-Architekturen mit hohem Durchlauf effizient und skalierbar sein. Einige asymmetrische Kryptografietechniken, einschließlich des BLS-Signatursystems, bieten diese Merkmale. BLS stellt sicher, dass die Verwendung desselben privaten Schlüssels zum Signieren einer Nachricht zu konsistenten Ergebnissen führt. Dies ist vergleichbar mit den Ergebnissen von ECDSA mit deterministischer k-Generierung, da die Technik keine Zufallsparameter verwendet. Bewertung von Knotenpunkten (Codes) e Bewertung eines berechtigten Validators (Prüfers) beeinflusst neben dem Einsatz auch seine Chancen, für die Konsensgruppe ausgewählt zu werden. Wenn ein Block-Proposer ehrlich ist und sein/ihr Block der Blockchain zugefügt wird, steigt seine/ihre Bewertung. Andernfalls wird sie abnehmen. Dies bestärkt Validatoren, ehrlich zu sein, die neueste Kunden-Software zu verwenden und die Erreichbarkeit zu erhöhen, um sicherzustellen, dass das Netzwerk ordnungsgemäß funktioniert. Redundanz zwischen Shards Nodes (Knoten), die in Geschwister-Shards auf der untersten Ebene der Baumstruktur bereitgestellt werden, kommunizieren miteinander, um Blockchain-Daten und den Anwendungsstatus auszutauschen. Die Implementierung von Shard-Redundanzen ermöglicht die Zusammenführung von Geschwister-Shards, wenn die Knotenzahl des Netzwerks sinkt. Ausgewählt Knoten beginnen sofort mit der Shard-Zusammenführung. X Zentral vs. dezentral Zentrale Systeme haben einen einzigen Kontrollpunkt, während dezentrale Systeme die Kontrolle über ein Netzwerk von Teilnehmenden verteilen. Blockchain wurde entwickelt, um zentralisierte Finanzsysteme zu ersetzen. Während aufgeteilte Systeme Freiheit und Anonymität bieten, muss ihre Leistung global in realen Szenarien bewertet werden. Die wichtigste Einheit zur Messung der Leistung sind Transaktionen pro Sekunde (TPS). Ein Vergleich traditioneller zentralisierter Systeme mit dezentralen Designs, die sich auf breiter Ebene für Vertrauen und Effizienz erwiesen haben, offenbart eine objektive, aber unbequeme Tatsache. Die Skalierbarkeit der Blockchain-Architektur ist ein bedeutendes Problem, das noch angegangen werden muss. Dabei muss die Auswirkungen auf die Datenspeicherung und der Ladungsprozess berücksichtigt werden, wenn bestehende Blockchain-Designs einen Datendurchlauf auf Visa-Ebene erreichen. Diese Beispiele verdeutlichen das Ausmaß mehrerer sekundärer Schwierigkeiten. Rahmenbedingungen der Blockchain Leistung Der Entwurf verteilter Systeme auf der Blockchain weist Probleme auf, u.a. die Aufrechterhaltung der Funktionsfähigkeit unter Belastung. Die Schlüsselfaktoren, die sich auf den Leistungsdruck auswirken, sind: • Komplexität • Systemgröße • Transaktionsvolumen. Leistung eistungstests und Simulationen belegen die Effizienz der Lösung als ein hoch skalierbares verteiltes Verzeichnis. Unsere Sharding-Strategie führt zu einem linearen Anstieg der Verarbeitungsmenge, je mehr Knoten dem Netzwerk beitreten. Die verschiedenen Kommunikationsrunden in diesem Konsensmodells hängen stark von der Netzwerkqualität (Geschwindigkeit, Latenz und Verfügbarkeit) ab. Simulationen in unserem Testnetz unter Verwendung globaler Netzwerkgeschwindigkeitsdurchschnitte zeigen, dass Stake.ch mit nur 2 Shards das durchschnittliche VISA-Niveau übertreffen und mit 16 Shards das höchste VISA-Niveau erreichen kann. Aktuelle und zukünftige Studien und Forschung Stake.ch ist eine öffentliche Blockchain-Architektur, die Skalierbarkeit durch adaptives State-Sharding, Sicherheit und Energieeffizienz durch einen sicheren Proof of Stake-Konsensmechanismus kombiniert. Unser Team evaluiert und verbessert ständig das Design, um es ansprechender zu machen. Zu unseren zukünftigen Verbesserungszielen gehören: 2) KI-Überwachung: Das Erstellen eines KI-Aufsicht, um gefährliche Verhaltensmuster zu erkennen. Es ist unklar, wie diese Funktionalität in das Protokoll implementiert werden kann, ohne die Dezentralisierung zu beeinträchtigen 3) Ergänzung von Zuverlässigkeit als Konsensfaktor: Das aktuelle System priorisiert Einsatz und Bewertung, wir schlagen jedoch vor, Zuverlässigkeit als Metrik einzubeziehen, nachdem ein Konsensverfahren auf zuvor eingereichte Blöcke vor kurzer Zeit angewendet wurde.
4) Förderung der kettenübergreifenden Interoperabilität durch Implementierung und Beitrag zu Standards, die von der Decentralized Identity Foundation und der Blockchain Interoperability Alliance entwickelt wurden. 5) Die Verwendung von Zero-Knowledge Succinct Non-Interactive Argument of Knowledge für datenschutzrechtlich geschützte Transaktionen, was die Identität der Teilnehmer schützt und Prüfmöglichkeiten bietet
Dividendenarbitrage ist eine Handelsstrategie, bei der Preisunterschiede zwischen einer Aktie und den damit verbundenen Optionen oder Derivaten genutzt werden, insbesondere zu dem Zeitpunkt, an dem die zugrunde liegende Aktie Dividenden auszahlt.
Bei Verwendung für ein Wertpapier mit geringer Volatilität (was niedrigere Optionsgebühren verursacht) und einer hohen Dividende kann Dividendenarbitrage dazu führen, dass Anleger Gewinne realisierten während sie ein sehr geringes bis gar kein Risiko eingehen.
Wie Dividenden ausgezahlt werden
Kreditvergabe im dezentralen Finanzwesen (DeFi) bezieht sich auf die Praxis der Bereitstellung oder Ausleihe von Kryptowährungs-Assets über dezentrale Kreditplattformen, oft erleichtert durch Smart Contracts in Blockchain-Netzwerken. DeFi-Kreditplattformen ermöglichen es Einzelpersonen, ihre Krypto-Vermögenswerte gegen Zinsen an andere zu verleihen oder Vermögenswerte durch Bereitstellung von Sicherheiten zu leihen.
DeFi-Kreditplattformen lassen sich oft in andere dezentrale Finanzprotokolle integrieren, wie z. B. dezentrale Börsen (CDEX), um Benutzern zusätzliche Liquidität und Handelsmöglichkeiten zu bieten.
<02755c0f -4978-8a41>
Neue Validatoren können dem Netzwerk beitreten indem Sie ihre Einsätze einbinden. Sie werden dem nicht zugewiesenen Node-Pool in der aktuellen Epoche hinzugefügt und zu Beginn der nächsten Epoche der Warteliste eines Shards zugewiesen.
VII-Skalierbarkeit durch Adaptive Aufteilung (Sharding)
2: Sharding-Klassifizierungen:
3: Stake.ch Sharding-Methode:1: Funktion COMPUTEM1ANDM2(Nsh)
2: n ← math.ceil( log2Nsh )
3: m1 ← (1 << n) − 1
4: m2 ←
(1 << ; (n − 1)) – 1
5: return m1,
m2
<37b55701
-5bfd-9b5e>3: Geschwister zurückgeben<2f69575f-cc6c-1dae >
2: mask1 ← 1 << (n −
1)
<15ea71fa- 57bb-bc7d>3: mask2 ← 1 <<
(n-2)
<8e00a0a8-546a
-4b95>< 9b51de83-8af7-7c0c>6: wenn Geschwister ≥ Nsh,
dann <78 214111
-563b-53c2>7: Geschwister ← (p xor mask2) <
f835b3d7-9fa9-c35b>
<5f63522e-4689-666 5>
< 701702ad-bac4-41c8>9: Elternteil ←
min(p, Geschwister)<8152afd5-c62c-9019
>
<125ac42b-e8da -0e77> 10: Wenn
Geschwister2 ≥ Nsh, dann ▷
14:
15: Eltern, Geschwister,
Geschwister2 zurückgeben<6d3f2ed7-1652 -fa62>
16:
sonst <7520bd4e -63f6-d584> ▷
<0e97be5d-10ba-3E76> <65446A66-578E-23AB> SIBRINGS IS A SHARD
<3BAB7569-92B7-CA19> <1C0M <3bab7569-92B7-CA19>
<1C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0-1C0-1C0-1C0-ABREI.
e9b1>
<79fc6b6 a-c2a2-d7d7 >17:
Eltern, Geschwister zurückgeben, NULL
Die Statusverschiebung hat erhebliche Auswirkungen auf die Leistung, da sie eine Neusynchronisierung des Status, der Blockchain und der Transaktionen von berechtigten Knoten im neuen Shard erfordert. Um die Aktivität zu Beginn jeder Epoche aufrechtzuerhalten, werden weniger als 1/3 der Knoten gleichmäßig auf die Shards verteilt..
L = P k1, P k2, P kn die Sammlung öffentlicher Schlüssel für alle möglichen Teilnehmer während einer einzelnen Runde dar. Dies umfasst alle Knoten in der Konsensgruppe. Die Blockzuweisungsmethode umfasst zwei Phasen: Signatur und Überprüfung.
