DApp-Speicher für andere Daten als Transaktionen?

Erstens sollten Sie sich Verträge nicht analog zu Tabellen vorstellen. Jeder Vertrag kann mehrere Zuordnungen von Informationen enthalten. Sie könnten ein einziges ReviewSystem.sol haben, das Zuordnungen für Restaurants und Bewertungen enthält, und in Übereinstimmung mit dem, was Sie zuvor vorgeschlagen haben, könnten Sie Methoden haben addRestaurant(), addReview()die Datensätze zu den im Vertrag gespeicherten Zuordnungen hinzufügen würden.

Allerdings haben Verträge keine sehr guten Mechanismen für normalisierte relationale Daten. Wenn Sie in einer relationalen Datenbank einen „Restaurant“-Datensatz hätten, könnten Sie eine Abfrage für alle Bewertungen zu einem bestimmten Restaurant ausführen, und mit der Leistungsfähigkeit von Indizes und Abfrageplanern erhalten Sie diese Informationen sehr schnell zurück. Bei Ethereum sind Ihre Möglichkeiten eingeschränkter. Wenn Sie keinen Index haben, müssen Sie jede Bewertung in Ihrem System durchsuchen, um festzustellen, ob sie sich auf das betreffende Restaurant bezieht. Wenn Sie einen Index haben, erhöhen Sie die Kosten für das Schreiben von Aufzeichnungen in Ihren Vertrag. Sie können die Daten auch für schnellere Suchen denormalisieren, wiederum auf Kosten einer höheren Vertragsspeicherung.

Eine Möglichkeit besteht darin, einige Ihrer Informationen außerhalb der Kette zu halten. Beispielsweise können Sie Ihre Restaurants und Bewertungen in Ihrem Vertrag mit einem Verweis von Bewertung auf Restaurant behalten. Unabhängig davon haben Sie möglicherweise eine herkömmliche Datenbank, die die Beziehung von Bewertungen zu Restaurants indiziert. Wenn jemand eine Bewertung über Ihre DApp hinzufügt, speichert der Vertrag die kanonischen Informationen und die separate Datenbank bewahrt eine Kopie der Informationen auf. Wenn jemand die Bewertungen zu einem bestimmten Restaurant nachschlagen möchte, kann er eine von der Datenbank unterstützte API abfragen, die die IDs für die Bewertungen schnell zurückgeben kann, und er kann die Bewertungen selbst aus der Blockchain abrufen. In diesem Fall sind alle kritischen Informationen on-chain verfügbar und der Off-Chain-Index kann aus dem Vertragsstatus rekonstruiert werden. Um mehr über die Nachverfolgung von Vertragsereignissen außerhalb der Kette zu erfahren,Ereignisse und Protokolle .

Wie Sie in Ihrer Bearbeitung angemerkt haben, kostet jede Information, die Sie in einem Vertrag speichern, Gas, und dieses Gas wiederum kostet Ether. Einen Dienst wie Yelp mit Hunderttausenden von Unternehmen und Tausend Wortbewertungen zu betreiben, könnte sich als sehr teuer erweisen. Sie könnten einige der Kosten mindern, indem Sie mehr Informationen außerhalb der Kette speichern. Vielleicht besteht eine Bewertung in der Kette aus einer Sternebewertung und dem Hash der schriftlichen Bewertung, dann wird der Bewertungstext aus einer Off-Chain-Quelle wie der zuvor besprochenen Datenbank oder vielleicht einem anderen dezentralen System wie ipfs abgerufen.

Im Allgemeinen sehe ich die Ethereum-Blockchain jedoch als den Ort, an dem Sie Informationen speichern, deren Verwaltung Sie nicht Dritten anvertrauen möchten. Dinge wie ERC20-Token, ENS und verteilte Börsen sind ein großartiger Anwendungsfall, da es sonst schwierig wäre, Vertrauen in eine zentralisierte Einheit aufzubauen. Es wäre zwar nett, so etwas wie einen dezentralisierten Überprüfungsdienst zu haben, aber die Kosten für die Vertragsspeicherung in Kombination mit dem relativ geringen Risiko, einem Dritten die Verwaltung dieser Informationen anzuvertrauen, machen es zu einem weniger attraktiven Anwendungsfall für die Blockchain.

Zunächst zur Beantwortung Ihrer Fragen:

„Ist dieser Ansatz, einen Vertrag wie eine RDBMS-Tabelle zu behandeln, robust? Oder übersehe ich etwas?“

Ja, diese Lösung ist robust , vorausgesetzt, Sie meinen zuverlässig oder "wird es jedes Mal funktionieren". Tatsächlich ist Robustheit eines der attraktivsten Merkmale beim Schreiben von Verträgen, die auf der Ethereum-Blockchain laufen: Sie haben mehr Redundanz, als irgendjemand jemals brauchen würde. Es gibt gerade 25,5xxKnoten [ 1 ]. Jeder dieser Knoten speichert eine Kopie Ihrer Daten, Ihres Codes und führt jede Codezeile in Ihrem Vertrag aus.

„Wie hoch ist die maximale Datenmenge, die bei der Abbildung eines Vertrages gespeichert werden kann?“

Diese Frage wird hier von einer maßgeblichen Persönlichkeit in der Ethereum-Community beantwortet, daher werde ich davon absehen, darauf einzugehen, außer zu sagen, dass Sie entweder wahrscheinlich nicht so viele Daten haben oder es sich sicherlich nicht leisten können, so viel zu speichern, wie es die Blockchain könnte. nehmen". Da jedoch jeder Knoten eine Kopie der Daten der Blockchain speichert, würden Sie, wenn Sie es sich leisten könnten, jeden der Knoten belasten und möglicherweise dazu führen, dass weniger Knoten existieren, da der Betrieb eines Knotens aufgrund der Größe der Daten mehr kosten würde riesig.

„Nach meinem Verständnis würde das Ändern der Zuordnung des Restaurantvertrags Äther kosten. Das heißt, jeder neue Datensatz, der der „Datenbank“ hinzugefügt wird, kostet Geld?“

Ja, das Ändern der Zuordnung ändert den Zustand der Blockchain und kostet Benzin.

Was ist eine wirtschaftlich tragfähige Möglichkeit, eine App auszuführen, ohne dass die Benutzer zahlen müssen?

Sie haben einige Möglichkeiten:

1. ~~Lass deinen Benutzern Gas geben~~
2. Belohnen Sie Ihre Benutzer mit zusätzlichen Einheiten Ihres nativen App-Tokens, wenn Sie über eine flexible Versorgung mit Ihrem Token verfügen
3. In der Organisation, zu der ich beitrage, speichern wir einen Hash, der ein kryptografischer Beweis der Daten außerhalb der Kette ist, und wir speichern nur den IPFS-Hash in der Kette. IPFS-Hashes sind leider mehr als das 32-Byte-EVM-Wort (siehe diese äußerst informative Antwort zum Speichern von IPFS-Hashes in einer Kette in einer Struktur).
   • Das Interessante an dieser Lösung ist, dass Benutzer später unabhängig überprüfen können, ob die Daten, auf die der Hash verweist, tatsächlich in der Kette gespeichert werden sollten, indem sie dieselbe Hash-Funktion für die zurückgegebenen Daten ausführen.

Ethereum/Dapp-Datenspeicherung zum Mitnehmen

• Das Speichern von Daten in der Kette ist im Vergleich zu zentralisierten Lösungen sehr teuer.
• Das Speichern von 1 kB kostet 640,000Benzin
• 640,000Gaskosten $0.08- $0.90unter Verwendung der aktuellen Etherpreise, je nachdem, wie schnell Ihre Transaktion abgebaut/bestätigt werden soll
• Wenn der Preis für Ether weiter steigt, wird der Preis für die Speicherung Ihrer Daten damit steigen, vorausgesetzt, dass es nicht zu einer entsprechenden Senkung des akzeptierten Gaspreises kommt, den die Miner zu akzeptieren bereit sind.

• Jede noch so kleine Änderung an der Blockchain kostet Gas (oder „Geld“ im alten Sprachgebrauch)

  • Zum Beispiel kostet das Versenden von Ether mit der eingebauten send()Methode 21,000Gas
  • Aus dem Gelben Papier 4 : Gtransaction 21000 Paid for every transaction.Also kostet jede Sendung mindestens 21,000– das sind die Mindestkosten

• Das Abrufen von Daten aus der Blockchain ist jedoch kostenlos:

  • Wir können Daten aus der Blockchain auf verschiedene Arten erhalten:
    • Getter-Funktionen , die automatisch für uns für jede publicVariable in unseren Verträgen erstellt werden
      • Zum Beispiel uint public numRestaurants = 42;erstellt die Zeile: eine Funktion, die wir aus unserem Vertrag aufrufen könnenthis.numRestaurants()
      • Im web3Client könnten wir diese Funktion mit aufrufencontractInstance.numRestaurants.call()
    • Vertragsfunktionen , die versprechen, den Zustand nicht zu ändern, können deklariert werden constantoder viewFunktionen
      • function f(uint a, uint b) view returns (uint) { return a * (b + 42) + now; // does math but doesn't change state! }
    • Events sind Daten, die in der Blockchain gespeichert werden
      • LogUpdateRestaurant('mandalay', 8.7, 'restaurant')in der Funktion, die Ihre Restaurantdaten speichert
      • Wir definieren Ereignisse mitevent LogUpdate(indexed string restaurantName, uint8 rating, TypeEnum type);

  Ich werde zu einem späteren Zeitpunkt mehr darüber erzählen, wie wir an die Speicherung unserer Daten in einer nahezu vollständig dezentralisierten Anwendung herangegangen sind. Und danke, dass Sie mir beigebracht haben, was ich durch das Schreiben dieser Antwort gelernt habe (wie viewist jetzt ein Alias ​​für constant)