Skip to main content
Diese Seiten stellen vier Behauptungen immer wieder auf: dass sich eine Margin-Berechnung isoliert prüfen lässt, dass jeder eine Auto-Deleveraging-Auswahl nachrechnen kann, dass Funding hergeleitet und nicht festgesetzt wird, und dass zwei ehrliche Nodes bytegleiche Ergebnisse erzeugen. Eine Behauptung dieser Form ist nichts wert, solange sie niemand außerhalb des Protokolls ausgeführt hat. Diese Seite zeigt, wie. Jede Prüfung benennt die Eingaben, woher sie stammen und – ebenso wichtig – was sie nicht belegt.
Nur Arithmetik
Öffentliche Daten, jede Node
Eine eigene Full Node
Eine Margin-Anforderung
Ein Liquidationspreis
Eine ADL-Auswahl
Eine Funding-Zahlung
Ein Block, Byte für Byte
Zwei der fünf brauchen überhaupt kein Netz: Es sind reine Funktionen über einen veröffentlichten Stufensatz.

1 · Eine Margin-Anforderung

Was Sie brauchen: einen Datensatz der Hebelstufen und eine Positionsgröße. Sonst nichts. Keine Node, kein Netz, kein Konto. Initial und Maintenance Margin sind reine Funktionen des Nominals und des Stufensatzes; Formeln und exakte Rundung stehen auf Hebel: IM=Nominalwert×im_leverage×10exponent\text{IM} = \text{Nominalwert} \times \text{im\_leverage} \times 10^{\text{exponent}} MM=max⁡ ⁣(Nominalwert×mm_leverage×10exponent−Abzug,  0)\text{MM} = \max\!\left(\text{Nominalwert} \times \text{mm\_leverage} \times 10^{\text{exponent}} - \text{Abzug},\; 0\right) Die Stufensätze sind in der Gruppe DEX Config der API-Referenz veröffentlicht – im_leverage, mm_leverage, der gemeinsame exponent und der deduction je Stufe. Wählen Sie ein Nominal, werten Sie beide Ausdrücke auf Papier aus und vergleichen Sie mit dem, was der Handelsplatz derselben Position berechnet. Was es belegt: Die Anforderung ist eine veröffentlichte Funktion öffentlicher Parameter und kein Urteil pro Konto. Was es nicht belegt: dass der Stufensatz gut gewählt ist. Das ist eine Governance-Frage, keine arithmetische.
Rundung ist Teil der Spezifikation, keine Toleranz. Weicht Ihre ganze Zahl um eine Einheit von der des Handelsplatzes ab, ist eine der beiden falsch – prüfen Sie die Rundungsregeln auf der Seite Clearingstelle, bevor Sie entscheiden, welche.

2 · Ein Liquidationspreis

Was Sie brauchen: derselbe Stufensatz sowie Ihr Guthaben und Ihre Position. Die Schwelle ist ein Verhältnis, definiert auf Liquidationen: Auslastung=Maintenance MarginNettosicherheiten\text{Auslastung} = \frac{\text{Maintenance Margin}}{\text{Nettosicherheiten}} Die Nettosicherheiten sind das Guthaben plus unrealisiertes P&L, abzüglich dessen, was liegende Orders reserviert haben. Lösen Sie nach dem Mark-Preis auf, bei dem das Verhältnis seinen Auslöser erreicht, und Sie haben den Preis, zu dem das Protokoll handeln wird – bevor es handelt. Was es belegt: Der Auslöser lässt sich im Voraus aus Ihren eigenen Zahlen herleiten. Was es nicht belegt: zu welchem Preis Sie tatsächlich glattgestellt werden. Das hängt vom Buch in diesem Moment ab und ist durch den Bankrottpreis begrenzt.

3 · Eine Auto-Deleveraging-Auswahl

Was Sie brauchen: offene Positionen und Mark-Preise eines Marktes, von einer beliebigen Full Node. Die Auswahl ist ein Score, definiert auf Auto-Deleveraging: Score=unrealisierter Gewinn in %×effektiver Hebel\text{Score} = \text{unrealisierter Gewinn in \%} \times \text{effektiver Hebel} Holen Sie die Positionen eines Marktes aus der Gruppe Accounts und den zertifizierten Preis aus der Gruppe Oracle, berechnen Sie den Score für jede Position auf der Gewinnseite und sortieren Sie. Diese Reihenfolge ist die Warteschlange. Vergleichen Sie deren Spitze mit dem ADL-Indikator, den die Oberfläche anzeigt. Was es belegt: Die Warteschlange ist eine Funktion öffentlichen Zustands. Niemand wählt aus, und es steht keine Position darin, die Ihre eigene Arithmetik nicht finden könnte. Was es nicht belegt: dass Deleveraging Sie nicht erreicht. Eine Warteschlange, die Sie berechnen können, ist immer noch eine, in der Sie stehen können.

4 · Eine Funding-Zahlung

Was Sie brauchen: das Orderbuch und den zertifizierten Index der Abrechnungsrunde sowie Ihre Position. Die Rate entsteht auf Funding in drei Schritten – eine tiefengewichtete Prämie, skaliert auf das Intervall des Marktes, dann gekappt: P=max⁡(0,  tiefengew. Bid−Index)  −  max⁡(0,  Index−tiefengew. Ask)IndexP = \frac{\max(0,\; \text{tiefengew. Bid} - \text{Index}) \;-\; \max(0,\; \text{Index} - \text{tiefengew. Ask})}{\text{Index}} F=F8h×Intervall in Sekunden28,800Ffinal=clamp⁡ ⁣(F,  Fmin⁡,  Fmax⁡)F = F_{8h} \times \frac{\text{Intervall in Sekunden}}{28{,}800} \qquad F_{\text{final}} = \operatorname{clamp}\!\left(F,\; F_{\min},\; F_{\max}\right) Dann die Belastung selbst: Funding-Zahlung=Positionsgro¨ße×Mark-Preis×Funding-Rate\text{Funding-Zahlung} = \text{Positionsgröße} \times \text{Mark-Preis} \times \text{Funding-Rate} Das Buch kommt aus der Gruppe Markets, der zertifizierte Index aus Oracle, und die tatsächlich geleistete Zahlung aus dem Funding-Zahlungen-Endpunkt der Gruppe Accounts. Nachrechnen und vergleichen. Was es belegt: Die Rate wurde aus Buch und Index hergeleitet, nicht von einem Betreiber festgesetzt. Was es nicht belegt: dass der Index richtig war. Siehe was das Oracle garantiert und was nicht.

5 · Ein Block, Byte für Byte

Was Sie brauchen: eine eigene Full Node. Jeder kann eine betreiben – siehe Node betreiben.
Dies ist die einzige Prüfung auf dieser Seite, die heute noch nicht möglich ist. Das Netz läuft bis zur Öffnung des öffentlichen Zugangs auf einem privaten Testnet; die ersten vier Prüfungen sind also jetzt möglich, diese wird es dann. Sie steht hier, weil die anderen vier nur so viel wert sind wie diese eine.
Auf dieser Prüfung ruhen die anderen vier. Nehmen Sie einen festgeschriebenen Block und seinen Vorzustand, führen Sie ihn aus und vergleichen Sie Ihr Ergebnis mit dem des Netzes. Determinismus wird hier erzwungen, nicht erhofft: Der Ausführungspfad liest keine Uhr, keine Laufzeit-Entropie, kein Gleitkomma und keine hash-randomisierte Iterationsreihenfolge – eine Abweichung ist also ein Defekt und keine Toleranz. Siehe Warum das Ergebnis reproduzierbar ist. Zwei Eigenschaften machen daraus einen echten Test statt einer Zeremonie. Die Reihenfolge ist ein vom Konsens festgeschriebenes Objekt: Die Sequenz, die Sie wiederholen, ist die, die ein Quorum signiert hat, nicht die, die Ihre Node erschlossen hat. Und die Preise sind durch dieselben Signaturen festgeschrieben, sodass es kein Fenster gibt, in dem Sie gegen einen vom Netz nicht zertifizierten Preis wiederholen könnten. Was es belegt: dass der Zustand, der Ihnen ausgeliefert wird, nach den veröffentlichten Regeln auf Eingaben entstanden ist, die das Netz festgeschrieben hat. Was es nicht belegt: dass die Regeln fehlerfrei sind. Einen Bug exakt zu reproduzieren heißt immer noch, einen Bug zu reproduzieren – deshalb gibt es daneben Audits und das Bug-Bounty.

Was nichts davon abdeckt

Verifikation begrenzt, was auf Treu und Glauben genommen werden muss; sie beseitigt es nicht. Was bleibt – das Validator-Set, das Preis-Quorum, die Reichweite der Governance über Parameter und die Bridge – ist auf Vertrauensannahmen aufgezählt. Lesen Sie diese Seite als Nächstes, wenn Sie wegen der Grenzen und nicht wegen der Garantien gekommen sind.

Wie es weitergeht

Vertrauensannahmen

Was übrig bleibt, wenn alles Prüfbare geprüft ist.

Node betreiben

Hardware, Sync und was ein Validator tatsächlich ausführt.

IntentionKernel

Die vier Schließungen, die dem Replay Bedeutung geben.

API-Referenz

Felddetails zu jeder oben genannten Eingabe.