Da ich immer mehr über die Entwicklung von Dapps lerne, habe ich Probleme zu verstehen, was im Smart Contract gespeichert werden muss (über unsere Datenbank usw.).
Nehmen wir den Fall einer einfachen Wett-Website . Die Art und Weise, wie ich mir das Erstellen einer DApp einer Wett-Website vorstelle, wäre die folgende und bitte korrigieren Sie mich, wenn ich falsch liege.
Verwendete Technologie : Ruby on Rails (Back-End), React (Front-End), Solidity (Smart Contract)
1) Ich würde in meiner Datenbank folgende Informationen speichern:
2) Bei der Erstellung eines Benutzers würde ich eine neue Ethereum-Brieftasche mit demselben Passwort wie seine Anmeldeinformationen erstellen und die öffentliche Adresse seiner Brieftasche in der Datenbank speichern.
3) Ich würde im Smart Contract speichern :
Infolgedessen enthält der Smart Contract nur Informationen zu einer Wetttransaktion (Wettergebnisse, Wettbetrag) und die Datenbank enthält den Rest. Um den Wettverlauf eines Benutzers abzurufen, würde ich die Liste aus der Datenbank abrufen und die Ergebnisse aus dem Smart Contract abrufen (verknüpft durch die ID der Wette und des Benutzers).
Verstehe ich das Dapps/Smart Contract-Konzept völlig falsch? Bitte um Rat, danke !!
Erstens ist es großartig, dass Sie mehr über DApps erfahren. Es ist immer großartig zu sehen, wie die Community wächst. Sie haben jedoch einige Missverständnisse darüber, wie die DApps gestaltet werden sollten, daher werde ich versuchen, Ihnen die hilfreiche Richtung zu weisen.
Verwendete Technologie: Ruby on Rails (Back-End), React (Front-End), Solidity (Smart Contract)
Wie in dieser Antwort gezeigt:
Der Backend-Code einer DApp wird in einem dezentralen Peer-to-Peer-Netzwerk ausgeführt.
DApps haben per Definition kein klassisches Backend, wie es das RoR wäre. Das heißt, damit Ihre Anwendung DApp genannt werden kann, sollten die Smart Contracts Ihre gesamte Backend-Logik enthalten . Das Frontend könnte wirklich ein beliebiges JavaScript sein, zusammen mit der web3-Bibliothek , die Ihnen die APIs für die Kommunikation mit dem Smart-Contract-Backend zur Verfügung stellt.
Das ist ein ganz anderes Paradigma, mit dem ich mich einige Zeit schwer herumschlagen konnte. Es gibt dezentrale Alternativen für einige der klassischen Technologien, wie z. B. IPFS oder Swarm zum Speichern oder Hosten Ihrer DApp-Website, „Benutzer“ sollten an Blockchain-Adressen gebunden sein, Sie könnten PouchDB verwenden usw. Die DApp sollte vollständig Open Source sein und autonom.
Wenn Sie die DApp für Wetten erstellen möchten, müssen Sie wirklich keine Benutzerinformationen in der Datenbank speichern – Sie können das Frontend programmieren und beispielsweise über den Vertrag interagieren, der den Prozentsatz jeder Wette an den Vertrag sendet und in Ihrer Kontrolle hat solides Geschäftsmodell bei gleichzeitig gutem Service für DApp-Benutzer. Aber wenn Sie jede Wette auf Blockchain wollen, würden sich die Transaktionskosten manchmal als zu hoch erweisen. Dies bedeutet jedoch nicht, dass Sie keine Hybrid-App haben können – echte DApps in ihrem aktuellen Zustand haben einige Einschränkungen.
Bei der Arbeit an Lemon Email mussten wir einige der Vorteile der etablierten Technologien (z. B. SMTP-Server) mit den Vorteilen dezentraler Anwendungen abwägen – also haben wir uns entschieden, die DApp zu erstellen, die für jeden geeignet ist. Wir haben die Ethereum Blockchain verwendet, um Metadaten unserer Interaktionen zu speichern, und IPFS als unseren Speicher. Wenn Sie möchten, können Sie hier mehr über unsere Architektur lesen .
Einige zusätzliche Lektüre:
https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide/
https://www.packtpub.com/big-data-and-business-intelligence/mastering-blockchain
Sharif2008