Crash-Fairness

​

Was passiert on-chain während einer Crash-Runde?

1. Commit: Bevor die Wetten öffnen, erzeugt das Backend ein zufälliges 32-Byte-Geheimnis und veröffentlicht dessen SHA-256-Hash on-chain (die Instruktion start_new_round). Das ist der Commit: Ab diesem Moment kann nur noch genau dieses Geheimnis die Runde abrechnen. Der Commit ist im CrashRoundPrepared-Event der Transaktion öffentlich einsehbar.
2. Wetten: Die Spieler platzieren ihre Wetten. Das Geheimnis bleibt verborgen; der Commit garantiert, dass es nicht ausgetauscht werden kann.
3. Rundenstart / Erfassung der Entropie: Wenn die Runde beginnt (die Instruktion start_game), liest das Programm den aktuellsten Slot-Hash aus Solanas SlotHashes-Sysvar und speichert ihn in der Runde. Die App nennt diesen Wert den Block-Hash der Runde. Der Crash-Punkt steht jetzt vollständig fest (er ist eine reine Funktion aus dem gespeicherten Slot-Hash und dem festgelegten Geheimnis), aber wer das Geheimnis nicht kennt, kann ihn noch nicht berechnen. Der Wert ist im CrashGameStarted-Event öffentlich einsehbar.
4. Die Runde läuft: Der Multiplikator steigt, und die Spieler cashen aus.
5. Reveal: Das Backend übermittelt das Geheimnis (die Instruktion crash). Das Programm prüft on-chain, ob sha256(secret) dem Commit entspricht (bei Abweichung schlägt die Transaktion fehl), berechnet dann selbst den Crash-Punkt und schließt die Runde ab. Das CrashRoundFinalized-Event veröffentlicht das Geheimnis, den Slot-Hash und den endgültigen Crash-Punkt.

​

Wie lautet die exakte Formel für den Crash-Punkt?

Eingaben
  blockhash   32 Bytes   der beim Rundenstart gespeicherte Solana-Slot-Hash
  secret      32 Bytes   das am Ende enthüllte Geheimnis des Betreibers (festgelegt als sha256(secret))
  edge_bps    Ganzzahl   Hausvorteil in Basispunkten (siehe Gebühren und Limits; 150 = 1.5%)

Ableitung
  hash  = sha256( blockhash ‖ secret )        // 64-Byte-Eingabe: zuerst blockhash, dann secret
  X     = u32_be( hash[0..4] )                // erste 4 Bytes des Hashs, Big-Endian, vorzeichenlos 32 Bit
  X'    = min( X, 2^32 − 1000 )               // Sicherheitsgrenze: der Nenner unten ist nie kleiner als 1000

  crash_bps = max( 10000, floor( (10000 − edge_bps) × 2^32 / (2^32 − X') ) )

Ergebnis
  Crash-Multiplikator = crash_bps / 10000     // z. B. 29948 → 2.9948x

• Die Verkettungsreihenfolge ist zuerst blockhash, dann secret.
• X wird Big-Endian aus den ersten 4 Bytes der SHA-256-Ausgabe gelesen.
• Divisionen sind abgerundete Ganzzahldivisionen (floor).
• Die Untergrenze max(10000, …) bedeutet, dass der Multiplikator nie unter 1.00x liegt, und die Begrenzung von X verhindert astronomisch kleine Nenner.

​

Rechenbeispiel

Nenner      = 2^32 − 2882343476 = 1412623820
crash_bps   = floor( 9850 × 2^32 / 1412623820 ) = 29948
crash       = 2.9948x

​

Wie die Verteilung aussieht

P(crash ≥ m) ≈ (1 − edge) / m

​

Was garantiert ist, und was nicht

• Sobald der Commit on-chain ist, kann der Betreiber das Geheimnis der Runde nicht mehr ändern: Die Reveal-Transaktion schlägt bei jedem Geheimnis fehl, dessen Hash nicht passt.
• Sobald die Runde gestartet ist (Slot-Hash gespeichert), steht der Crash-Punkt fest. Ob früh, spät oder massenhaft ausgecasht wird, ändert nichts: Das Ergebnis stand fest, bevor der Multiplikator zu steigen begann.
• Der Crash-Punkt wird vom Programm berechnet, nicht vom Backend gemeldet. Ein falscher Wert kann nicht on-chain geschrieben werden.
• Alles, was zur Überprüfung nötig ist (Commit, Slot-Hash, Geheimnis, endgültiger Crash-Punkt), wird dauerhaft in On-Chain-Events veröffentlicht.

• Timing des Starts. Der Betreiber kennt das Geheimnis, bevor die Runde startet, und sein Backend entscheidet, wann die Start-Transaktion übermittelt wird. Da aktuelle Slot-Hashes öffentlich sind, könnte er theoretisch für mögliche Slots den jeweiligen Multiplikator vorab berechnen und den Start so timen, dass er beeinflusst, welcher Slot-Hash erfasst wird. Das Verfahren verhindert das nicht; es macht es beobachtbar: Das Timing der Rundenstarts ist öffentlich, und jede systematische Verzerrung würde sich in der Statistik der veröffentlichten Crash-Punkte zeigen, die jeder in großem Umfang nachrechnen kann.
• Abbrüche. Nach dem Rundenstart kennt der Betreiber das Ergebnis vor den Spielern und könnte eine ungünstige Runde abbrechen, statt das Geheimnis zu enthüllen. Dabei gelten zwei harte Grenzen: Ein Abbruch erstattet jeden Einsatz vollständig (das Programm hat keinen Weg, etwas einzubehalten), und jeder Abbruch erzeugt ein öffentliches Event; die Häufigkeit von Abbrüchen ist das On-Chain-Indiz. Der Abbruch existiert als Wiederherstellungsweg für ein verlorenes Geheimnis (etwa bei einem Backend-Absturz zwischen Commit und Reveal) und soll praktisch nie zum Einsatz kommen.

​

Wie überprüfst du eine Crash-Runde?