Können Ethereum-Token, die reale Vermögenswerte darstellen, variable Daten (Zustand, Einheiten, Typ usw.) tragen?

Ich versuche besser zu verstehen, wie man intelligente Verträge mit Token implementiert, die auf Ethereum aufbauen. Bevor ich zu tief in die Implementierungsdetails mit Solidity eintauche, möchte ich mögliche Hindernisse verstehen.

Ich würde gerne besser verstehen, wie Daten in Smart Contracts übertragen werden und wie so etwas wie „farbige Münzen“ aus dem Bitcoin-Jargon funktionieren könnte.

Also, ich habe mir ein Beispiel ausgedacht, wie ich denke, dass Smart Contracts verwendet werden könnten, basierend auf dem, was ich gelesen habe: Beervesting .

Für mein Beispiel habe ich mir einen neuen Token ausgedacht: BeerCoins

Nehmen wir an, diese BeerCoins werden durch Mining erstellt, und Brauereien möchten sie möglicherweise kaufen oder abbauen, um einen Terminmarkt für Bier zu schaffen ... vielleicht möchten sie ihr Bier mit einem Rabatt verkaufen, bevor sie mit dem Brauen beginnen.

Brauerei mit BeerCoins

Hier sind einige Arten von Transaktionen, die meiner Meinung nach mit diesen BeerCoins durchgeführt werden könnten:

Transaktion 1 – Alice kauft BeerCoins

Nehmen wir also an, Alice ist eine versierte Biertrinkerin und sie möchte ihr Bier im Voraus für einen Rabatt mit Ethereum kaufen. Sie kann ihr Bier einlösen, sobald es gebraut ist (in 2 Monaten).

Alice tauscht Ethereum gegen BeerCoins, und die BeerCoins ändern jetzt ihren Status: Sie können jeweils für 1 Pint Bier eingelöst werden .

Transaktion 2 – Alice verkauft einige BeerCoins an Bob

Jetzt vergeht vielleicht etwas Zeit und Bob möchte an dieser BeerCoin-Aktion teilnehmen. Er will nicht auf die nächste Charge warten; Er möchte etwas aus der aktuellen Charge kaufen. Er hat in den nächsten Wochen eine Party, und gutes Bier braucht ein paar Monate, um zu brauen. Alice beschließt, Bob einige (volle) BeerCoins im Austausch gegen einige Bitcoins zu geben.

Transaktion 3 – Bob tauscht BeerCoins gegen Bier ein

Jetzt ist Bob bereit, seine Party zu veranstalten, also schickt er einige seiner BeerCoins zurück zur Brauerei, und sie liefern ihm Bier. Die Brauerei fügt der Transaktion eine Tracking-Nummer hinzu, und die BeerCoins werden übertragen und geleert , sobald das Bier geliefert wird (wie von einem Orakel , der Reederei, gemeldet).

Beervesting!

Also meine Frage ist:

Ist diese intelligente Vertragsimplementierung möglich? Können Ethereum-Token auf diese Weise einen Zustand tragen?

Gibt es gute Beispiele für diese Art der Umsetzung?

Ich denke, es gibt ein paar Dinge zu beachten:

  • Wie werden Zustandsdaten in einem Token gespeichert/geändert? Gibt es Best Practices?
  • Wie viele Daten lassen sich praktisch in einem Token speichern?

Vielen Dank im Voraus für die Hilfe.

Antworten (2)

Es ist nicht wirklich machbar, jedem Token einen Zustand zu geben. Die Speicherkosten wären einfach zu groß -> Sie müssten jedem einzelnen Token einen Besitzer geben. Es könnte funktionieren, wenn Sie nicht so viele Token haben. (jeweils 1000l Bier) Aber trotzdem wäre eine mögliche Umsetzung etwa so:

contract beer{
   struct beerToken{
      uint deliveryDate;
      uint256 quantity;
      ...
   }
   mapping(address=>beer) beers;
}

Eine bessere Implementierung für das von Ihnen vorgeschlagene Szenario wäre etwa so:

contract beer{
   //the first uint could be a timestamp when the beer gets delivered
   //everyone now owns token of a delivery of beer
   //you could also add more variables to this
   mapping(uint=>mapping(address=>uint256)) balances;

   //which = timestamp
   function transfer(uint which,address _to, uint256 _value){
      if(balances[which][msg.sender]-value>0){
         balances[which][msg.sender]-=value;
         balances[which][_to]+=value;
      }
   }
}

Fragen Sie einfach, wenn Sie weitere Informationen benötigen. Ich bin froh, dass ich helfen kann.

Danke für die Hilfe. Würde sich die vorgeschlagene Umsetzung ändern, wenn es sich bei der Ware beispielsweise um ein Edelmetall und nicht um Bier handeln würde? Oder wenn es ein unbefristetes Lieferdatum gab (dh wann immer der Token-Inhaber es eintauschen wollte).
Ich hatte den Eindruck, dass Token ewig leben. Wenn sie bei der Kontaktinitiierung erstellt und beim Einlösen zerstört werden könnten ... wäre die Speicherung vielleicht nicht so schlimm?

Meiner Meinung nach ist es total im Ethereum-Kontext und kann sicher gemacht werden.

Anstatt einen "Zustand" zu haben, würde Bob bei der Lieferung einfach auf den, sagen wir, letzten Bierchargenvertrag oder die x-Adresse umbuchen! Dann werden diese Token verbrannt/zerstört, sobald alle Batch-Token zurück sind oder die x-Zeit erreicht ist.

Sehr schöne Idee!

Entschuldigung für Tippfehler, ich bin auf dem Handy und auf Französisch :)

Hinweis: Soweit ich weiß, verbraucht Orakel die Methode.