Stocker les données dans les transactions plutôt que dans le contrat

rustyx

Stocker les données dans les transactions plutôt que dans le contrat


Je veux stocker l’historique des véhicules dans la blockchain. Chaque « événement » historique contiendrait le VIN , le mileage et la date du véhicule. Il y a beaucoup de véhicules et l’historique par véhicule est assez petit. Le déploiement d’un nouveau contrat pour chaque véhicule semble donc inutile, mais le stockage de tous les véhicules dans un seul contrat n’est pas évolutif.

Je pensais donc à stocker l’histoire simplement dans les événements eux-mêmes générés par le contrat « registraire ».

Quelque chose comme ça:

 pragma solidity ^ 0.4 . 21 ; contract VehRegistry   { address public  owner ; 

     event   Event ( string  vin ,   string  mileage ,   string  date ); 

     function   VehRegistry ()   public   { owner =  msg . sender ; 
     } 

     function  registerEvent ( string  vin ,   string  mileage ,   string  date )   public   { 
         require ( msg . sender ==  owner ); emit Event ( vin ,  mileage ,  date ); 
     } 

 } 

S’agit-il d’une solution sécurisée (en termes d’intégrité des données)?

Et pourrais-je rechercher tous les événements pour une adresse de registre donnée?

Réponses


 Lauri Peltonen

Vous ne savez pas ce que vous voulez dire avec une solution «sécurisée». Si vous voulez dire «quelqu’un d’autre peut-il lire les données», la réponse est définitivement oui. Si vous voulez savoir si quelqu’un peut truquer les données, la réponse est non – écoutez simplement les événements de ce contrat spécifique et tout ira bien.

Je suis également un peu incertain de ce que vous entendez par adresse de registre. Il n’y a qu’une seule adresse utilisée dans votre contrat et c’est le propriétaire du contrat. Si vous avez besoin de plus de données dans votre contrat, vous pouvez simplement ajouter plus de paramètres – par exemple l’adresse de registre (quelle qu’elle soit).

Le stockage des données dans des événements est une solution bon marché mais de cette façon, les contrats ne peuvent pas accéder aux données. Cela pourrait convenir à votre solution. Si vous avez besoin de contrats pour avoir accès aux données, vous devez tout garder dans un seul contrat – mais oui, la consommation de gaz augmentera.


 Rob Hitchens B9lab

« Sécurisé » est un terme surchargé. J’ai tendance à penser que c’est une combinaison de trois préoccupations distinctes:

  1. Confidentialité. Est-il caché aux entités qui ne devraient pas le voir?
  2. Disponibilité. Quelle est l’assurance que nous pourrons le récupérer?
  3. Intégrité. Si nous le récupérons, quelle est l’assurance qu’il est authentique?

La conception sans état ci-dessus:

  1. N’est pas confidentiel. Tout le monde peut voir tous les détails.
  2. Est hautement disponible, mais pas pour les contrats, y compris lui-même – uniquement pour les observateurs hors chaîne.
  3. Ne sera mis à jour que par un utilisateur de confiance et ne sera pas déformé. Il n’y a pas de validation en chaîne des entrées, la responsabilité de l’intégrité des données incombe donc au compte de confiance.

La conception sans état est utile. J’incline à l’idée que les contrats intelligents devraient appliquer l’intégrité des applications afin qu’elles ne puissent en aucun cas être corrompues ou trompeuses. Cela implique généralement un stockage en chaîne pour garantir que les non-sens ne sont pas acceptables (ce VIN existe-t-il?), Même s’il provient d’une source fiable.

J’espère que cela aide.

 

(plutôt, contrat, dans, données), Le, Les, que, stocker, transactions

 

yahoo

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *