Ich versuche, die beste Lösung zu finden, um Ethereum-basierte Zahlungen in eine Webanwendung zu integrieren, und suche Rat von jemandem, der sich dieser Aufgabe bereits gestellt hat.
Mein Fall: Online-Glücksspiellösung, bei der Benutzer Geld auf ihr Konto einzahlen und Wetten abschließen können.
Anforderungen: Zahlungen sollten Ethereum-basiert sein, dh Benutzer überweisen ETHs und erhalten etwas Spielgeld (Token) oder sehen ihr Guthaben direkt in ETHs.
Lösungen, die ich sehe, und ihre Probleme:
1) Der Benutzer überträgt die ETH an die Adresse des App-Eigentümers und erhält Token (wir fügen dem Benutzer Token in der App-Datenbank hinzu). Dies scheint mir keine gute Lösung zu sein, da es nicht einfach ist, festzustellen, welcher Benutzer die Geldüberweisung vorgenommen hat. Dazu sollten wir die Adressen der Benutzer in der App-Datenbank speichern und die Transaktionen der Adresse des App-Eigentümers analysieren.
2) Erstellen Sie etwas Ähnliches wie den Token-Vertrag. In diesem Fall kann der Benutzer ETHs an eine Adresse übertragen und Token erhalten (in der Blockchain gespeichert).
Problem: Benutzer identifizieren - ist wieder nicht so einfach (dasselbe Problem wie oben beschrieben).
Ich weiß, dass es möglich ist, MetaMask zu verwenden, in diesem Fall ist keine Benutzeridentifikation erforderlich, aber in diesem Fall muss die Spiellogik in Smart-Contract platziert werden. Die Verwendung von MetaMask und einer vollständig dezentralisierten App ist nicht akzeptabel, es wird zu teuer. Erstens, weil die Spiele sehr dynamisch sind und viele Zustandsänderungen aufweisen (Spiel läuft, Geld im Spiel usw.), wird viel Gas benötigt. Zweitens hängen Aktionen vom Status ab, daher müssen Statusänderungen momentan verfügbar sein, es ist nicht akzeptabel zu warten, während die Transaktion abgebaut wird.
3) Erstellen Sie eine neue Ethereum-Adresse für jeden registrierten Benutzer (speichern Sie private Schlüssel in der Datenbank). In diesem Fall ist eine gewisse Synchronisierungslogik im App-Backend (ETH zu interner Währung [Token in App-Datenbank]) erforderlich.
Zum Beispiel überträgt der Benutzer ETHs an die erstellte Adresse, geht dann in die App und klickt auf die Schaltfläche „Synchronisieren“, dann überprüft die App die Menge der ETHs an der für die Benutzeradresse erstellten Adresse, überträgt diese ETHs an die Adresse des App-Eigentümers und fügt dafür Token (interne Währung) hinzu Benutzer in der App-Datenbank.
4) Erstellen Sie einen Smart-Contract, für den Benutzer ETHs mit zusätzlichen Daten (einige eindeutige Kennungen) übertragen können. In diesem Fall ist auch eine komplizierte Synchronisationslogik erforderlich.
Beispiel: Wenn der Benutzer Token (interne Währung) erhalten möchte, stellt ihm die App die Vertragsadresse und die generierte eindeutige Kennung zur Verfügung und speichert diese Kennung in der App-Datenbank (Eins-zu-Viele-Benutzer/Kennungen). Der Benutzer überträgt ETHs an die angegebene Vertragsadresse und fügt zusätzliche Daten hinzu (erzeugte eindeutige Kennung), der Vertrag speichert, wie viele ETHs mit dieser eindeutigen Kennung übertragen wurden, das App-Backend verwendet diese Informationen, um Tokens (interne Währung) in der App-Datenbank hinzuzufügen [Aufruf von Funktionen, die dies nicht tun 't change state sind kostenlos].
Für mich sehen die Optionen 3 und 4 akzeptabler aus, aber ich bin mir nicht sicher, ob meine Gedanken richtig sind, weil ich neu in der Blockchain-Entwicklung bin. Vielleicht gibt es bessere und richtigere Lösungen.
a) Habe ich die beschriebenen Abläufe richtig verstanden?
b) Gibt es bessere oder richtigere Lösungen für meinen Fall?
c) Welche Lösung soll ich wählen?
Bevor Sie fortfahren... Sie müssen verstehen, was eine Hot Wallet ist und was eine Cold Wallet ist und wie man sie benutzt und sicher aufbewahrt. Es ist unglaublich einfach, Websites wie diese zu betreiben und das Geld aller zu verlieren und für lange Zeit ins Gefängnis zu gehen. Wenn Sie sich nicht auf Ihr Wissen über diese Kryptokonzepte verlassen können, hören Sie auf zu lesen, recherchieren Sie weiter und kommen Sie später hierher zurück.
Also ... um Ihre eigentliche Frage zu beantworten ... Hier spielt tatsächlich eine Menge eine Rolle ...
1) Der vorgeschlagene Wert, den Benutzern zu ermöglichen, Ihr Unternehmen kennenzulernen, ist liquide. Sie denken vielleicht, dass die Benutzer sich darum kümmern, aber Kryptowährungsbörsen und andere Bitcoin-Wettseiten gehen normalerweise mit Ihrer vorgeschlagenen Lösung Nr. 1, weil am Ende alles, was die Benutzer wirklich tun wollen, Handel/Glücksspiel ist. #1 reduziert Blockchain-Gebühren, solange Sie Ihre Brieftasche effizient betreiben, was mich zu meinem nächsten Punkt bringt ...
2) Die vorgeschlagenen Kosten für den effizienten Betrieb Ihrer Brieftasche. Wirklich, Sie könnten diese Brieftasche auf jede alte Art und Weise betreiben und es wäre wahrscheinlich in Ordnung, aber die effizienteste Art, diese Brieftasche zu betreiben, wäre die Verwendung von Algorithmen, die die verbleibenden Münzen in jeder Eingabe / Ausgabe effektiv aufnehmen und Staub minimieren. Es ist vielleicht keine schlechte Idee, alle Ihre Coins an ein paar Adressen aufzubewahren (eine Adresse wäre am billigsten, aber mehrere erhöhen die Sicherheit). Die „Kosten“ hier sind die Forschung und/oder Entwicklung, um vorhandene Ethereum-Wallet-Software zu finden, um Transaktionseingaben und -ausgaben korrekt zu handhaben und Gebühren und Staub zu minimieren.
3) Der vorgeschlagene Wert für den anonymen Betrieb Ihrer Brieftasche. Das Hin- und Herschicken von Geld zwischen verschiedenen Ethereum-Adressen kann dazu beitragen, die Anonymität Ihrer Website zu erhöhen. Denken Sie daran, dies im direkten Gegensatz zu Nr. 1. Wenn Sie die Strafverfolgung stören könnte, sollten Sie eine Art CoinJoin oder einen ähnlichen Ethereum-Dienst anbieten.
Ich würde nicht empfehlen, der Gleichung einen Smart Contract hinzuzufügen. Es gibt einige sehr erfolgreiche Seiten wie diese, die keine speziellen Funktionen von Ethereum verwenden. Wenn Sie spezielle Ethereum-Funktionen nutzen möchten, integrieren Sie Ihre Website mit etwas wie Augur oder Gnosis .