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.
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?
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
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?
How do I ensure that only particular users can execute a contract?
Will the contract have their addresses which we can validate before
Hopefully, these are clear questions and I appreciate the responses
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.
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.
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;
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.