Ein Deck mischen

Kommutative Verschlüsselung:

Alice und Bob wollen ein Kartenspiel so mischen, dass keiner weiß, was die Hand des anderen enthält, aber die Hände disjunkt sind (dh nur einer darf eine bestimmte Karte haben).

Protokoll:

Alice und Bob entscheiden sich für ein Verschlüsselungsprotokoll mit folgenden Merkmalen

1. E _K (X) ist X -verschlüsselt mit Schlüssel K
2. D _K [ E _K (X) ] = X für alle K und X
3. E. _K. [ E. _J. (X) ] = E. _J. [ E. _K. (X) ]
   • dh E(X) ist kommutativ
4. Bei gegebenen X und E _K (X) ist es rechnerisch unmöglich, K abzuleiten
5. Gegeben X und Y , J und K , so dass E _J (X) = E _K (Y) nicht gefunden werden kann
   • dh E(x) ist stoßfest

Nun, da Alice und Bob ein Verschlüsselungsschema haben:

1. Bob nimmt die zweiundfünfzig Karten ( "2C","3C",...,"AS" ) und verschlüsselt jede mit Schlüssel B
2. Bob mischt die verschlüsselten Karten in zufälliger Reihenfolge und schickt den Stapel an Alice
   • Alice kann die Karten nicht sehen, da sie B nicht kennt
3. Alice wählt fünf Karten aus und schickt sie an Bob zurück
   • Das ist Bobs Hand. Bob kann diese Karten sehen, da er B kennt
4. Alice schickt fünf weitere Karten an Bob zurück, aber zuerst verschlüsselt sie sie mit Schlüssel A
   • Jede Karte wird nun als E _A [ E _B (X) ] verschlüsselt , was E _B [ E _A (X) ] durch Eigenschaft Nr. 4 entspricht.
5. Bob entschlüsselt diese Karten und schickt sie zurück
   • Bob kann die Karten nicht sehen, da er A nicht kennt . Alice hingegen kann sie sehen und das sind ihre Hände.

Weitere Karten können mit einem ähnlichen Verfahren gezogen werden. Nach dem Spiel zeigen Alice und Bob A und B , damit sie überprüfen können, dass keiner der Spieler geschummelt hat.

Tatsächlich existieren Verschlüsselungsverfahren mit den aufgeführten Eigenschaften, darunter auch ein RSA-ähnliches Verfahren. Siehe meine Quelle für weitere Details.

Verwendung in Verträgen:

Verträge können verwendet werden, um die Nachrichten zwischen Spielern zu verwalten und Belohnungen zu verteilen. Der Vertrag muss keine Logik ausführen, es sei denn, die Spieler sind sich über die Ergebnisse nicht einig. Im Falle einer Meinungsverschiedenheit muss der Herausforderer genügend Ether aufbringen, um die Gaskosten für die Verifizierung des Spiels zu decken. Dann muss der andere Spieler den Anruf ausführen, um das Spielergebnis zu überprüfen. Das Gas wird dem wahrheitsgemäßen Spieler zurückerstattet und die Runde wird vom Betrüger abgebrochen oder verwirkt.

Da der Quellcode von Ethereum-Verträgen verifiziert werden kann, sollte dies so einfach sein wie die Verwendung eines RNG, um zufällig Karten aus einem Stapel auszuwählen. Jeder, der überprüfen möchte, ob das Deck angemessen gemischt ist, kann den Vertragsquellcode überprüfen.

Da die Erzeugung einer guten Zufälligkeit an anderer Stelle angesprochen wird , geht diese Antwort davon aus, dass der Kartenmischvertrag Zugriff auf gute Zufallszahlen hat.

Verwenden von On-Demand-Zufälligkeit

Die Herstellung eines gut gemischten Decks kann durch zufälliges Auswählen von Karten aus einem nicht gemischten Deck und das Erstellen eines neuen Decks erfolgen, bis das nicht gemischte Deck aufgebraucht ist.

contract Deck {
   uint8[52] deck;

   function getRandomNumber() returns (uint) {
       ...;
   }

   function shuffle() {
      uint8[52] memory unshuffled;

      for (uint8 i=0; i < 52; i++) {
          unshuffled[i] = i;
      }

      uint cardIndex;

      for (i=0; i < 52; i++) {
          cardIndex = getRandomNumber() % (52 - i);
          deck[i] = unshuffled[cardIndex];
          unshuffled[cardIndex] = unshuffled[52 - i - 1]
      }
   }
}

Dieser Kontrakt repräsentiert jede der 52 Karten als ganze Zahl zwischen 0 und 51 einschließlich. Ein Aufruf der shuffleFunktion füllt die deckSpeichervariable mit einem Kartenspiel mit 52 Karten in zufälliger Reihenfolge.

Reagieren auf zufällige Eingaben.

Dies setzt voraus, dass die Zufälligkeit sicher angefordert werden kann, was nicht unbedingt möglich ist. Wenn dies nicht der Fall ist und stattdessen Zufälligkeit in den Vertrag geschickt werden muss, sollte das folgende allgemeine Konzept genauso gut funktionieren.

contract Deck {
   uint8[52] deck;

   function shuffle(bytes randomBytes) {
      if (randomBytes.length < 52) throw;

      uint8[52] memory unshuffled;

      for (uint8 i=0; i < 52; i++) {
          unshuffled[i] = i;
      }

      uint8 cardIndex;

      for (i=0; i < 52; i++) {
          cardIndex = uint8(randomBytes[i]) % (52 - i);
          deck[i] = unshuffled[cardIndex];
          unshuffled[cardIndex] = unshuffled[52 - i - 1];
      }
   }
}

Diese Version des Vertrags erfordert mindestens 52 Zufallsbytes, die in den Aufruf von aufgenommen werden müssen shuffle.

Wenn Sie wollen, dass sich Karten nicht wiederholen, dann ist das eigentlich ein ziemlich schwieriges Problem. Ein einfacheres Problem ist, wenn es uns egal ist, ob dieselbe Karte mehrmals ausgeteilt wird (z. B. Sie haben ein Pik-Ass und ich ein Pik-Ass).

Betrachten wir ein einfaches Spiel mit 2 Spielern. Jeder Spieler erhält 1 Karte und es ist in Ordnung, dass beide Spieler die gleiche Karte bekommen. Man kann sich das so vorstellen, als würden die beiden Karten von zwei verschiedenen Decks ausgeteilt. Um dies zu implementieren, können wir uns jede Karte als einen Index zwischen 0 und 51 (einschließlich) vorstellen. Hier erfahren Sie, wie Sie die Karte von Spieler 1 fair generieren, sodass nur er weiß, was es ist.

1. Spieler 2 generiert eine Zufallszahl im Bereich 0..51 namens p2_offset. Als nächstes generiert er eine zufällige Zeichenfolge namens p2_secret (zum Beispiel "pcjshjfgn"). Als nächstes übermittelt er sha3(p2_offset, p2_secret) an die Blockchain.
2. Spieler 1 generiert eine Zufallszahl im Bereich 0..51 namens p1_offset und eine zufällige Zeichenfolge p1_secret und übermittelt sha3(p1_offset, p1_secret) an die Blockchain.
3. Spieler 2 gibt p2_offset und p2_secret an den Ethereum-Vertrag weiter, der bestätigt, dass sha3 dieser Werte mit dem übereinstimmt, was er zuvor eingereicht hat.
4. Spieler 1 kann jetzt herausfinden, was seine Karte ist, indem er (p2_offset + p1_offset) mod 52 ausführt. Beachten Sie, dass Spieler 2 nicht weiß, was die Karten sind, weil ihm p1_offset unbekannt ist.
5. Spieler 1 kann seine Karte aufdecken, indem er p1_offset und p1_secret an den Vertrag übermittelt. Auch hier bestätigt der Vertrag, dass sha3 dieser Werte mit dem übereinstimmt, was Spieler 1 zuvor übermittelt hat.

Derselbe Ansatz kann zum Erzeugen der Karte von Spieler 2 verwendet werden.

Sicherzustellen, dass jede Karte nur einmal erscheint, finde ich ziemlich herausfordernd. Das könnten wir einmal sagen