2

I am trying to understand SMART contracts and would like some help with my understanding. I think the best way to answer my questions is with example scenarios.

  1. If I have a notary service on the blockchain, I will have a contract called Notary.sol. This will contain details like the owner, recipient, document. Once all parties have signed the document then a confirmation is sent somewhere. My question is that every time a new document needs notarized do I need to submit a new contract to the blockchain again so there is a new “instance” with a new state etc?

  2. Further to the notary example, I would like the smart contract to check extra details of the other parties before they are allowed to sign. For example, checking their permissions or even just grabbing their name. To do this would I call another smart contract as an event to get the result back before continuing with the rest of the contract?

  3. In the health sector, there are doctors and patients. For example, a doctor can have many patients. A patient can have a primary physician. The similar relationship applies to teachers and students (many to many relationships). This might get more complicated with storing student grades. This seems more appropriate to manage this in a relational database but the blockchain used for managing the trust in recording transaction. In the case of the doctor patients example. I might want a contract to move all patients to another doctor if their current one leaves/retires. That requires the blockchain knowing which patients belong to the doctor. How could I control that in the blockchain or contracts?

  4. How do I ensure that only particular users can execute a contract? Will the contract have their addresses which we can validate before execution?

Hopefully, these are clear questions and I appreciate the responses

Thanks

Improve this question

1 Answer 1

Reset to default
1

  1. The easiest (and cheapest) option would probably be to use the same contract for all documents. You would have logic in your contract which enabled a party to create a document (perhaps by using a hash of the document) and specify the parties who need to sign it.

  2. Either solution will work fine. It all depends on your architecture. If you feel like the implementation is simpler if you use a separate contract for permissions management, then do it.

  3. You're right to think that some things are better left off of the blockchain and in a relational database. For one thing, you cannot do complex queries for data cheaply (or sometimes at all). My advice is to keep things as simple as possible. One example data structure you could use for associating doctors with patients is a simple map of patient addresses to doctor addresses:

    // map of patients to doctors
mapping (address => address) patientsDoctors;

  4. Yes, the contract will need to know the user's address, but this doesn't mean you have to know the address at the time of contract creation. For example, your contract can have one admin, assigned at contract creation, which is allowed to mutate a map of agents. Certain functions would then need to fail if msg.sender is not contained in the agents map.

Improve this answer
2
  • Would it be too expensive to destroy and create a new smart contract each time we need a document notarized ? Hmm a map might work but I feel there needs to be a trade off between what is stored on the db and what is stored on the blockchain
    – Decrypter
    Commented Feb 18, 2018 at 1:12
  • @Decrypter It depends on your definitions of "too expensive". I created two contracts today. One cost 923,000 gas to create, and the other cost 1,271,000 gas. This is quite a bit more expensive than a simple transfer, as cheap as 21,000.
    – dalton_c
    Commented Feb 18, 2018 at 4:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.