CODEWITHSUNDEEP
blockchainethereumsoliditysmartcontracts
Or O.
Or O.

Reputation: 53

How do Smart Contracts handle multiple users and different storage?

I am experimenting with Smart Contracts on the Ethereum Blockchain. Let's say I have a contract, something like SimpleStorage.sol found in the Solidity documentation , that has a storage state accessible by anyone. As the link describes,

anyone could just call set again with a different value and overwrite your number

This would result in problems, and the solution of restricting the accessibility of that function to specific accounts is not appropriate in my use case. In my contract, I want the data each account sets to later be accessible by a different predetermined account (think of a relationship where person A->B so B uses the data exclusively from A, and x->y where y uses the data exclusively from x. No overlap can exist where y can use A's data). From my understanding, there are 2 solutions to the problem:

  1. Map addresses to each other and keep track of all the data within this single smart contract.
  2. Have a smart contract "template" that the initial account would access, and generate a separate smart contract for each new account to simply hold data that interacts with the template.

The problem with 1 occurs when the relationship between accounts becomes more complex (map separate structs?) or a large volume of people try to store their information in the contract.

The problem with 2 is redundancy. Do I really need to produce a separate "contract" for every single person trying to access the main template?

If my question is vague, I can explain more but I am mostly looking for a conceptual answer. Most smart contract examples I have found are either extremely simple or unnecessarily complex and don't provide concrete use-case.

Upvotes: 5

Views: 4529

Answers (1)

q9f
q9f

Reputation: 11824

You can create access lists in your smart contract. The most simple idea would be setting up an owner:

contract example {

    // Define variable owner of the type address
    address owner;

    // this function is executed at initialization and sets the owner of the contract
    function example() {
        owner = msg.sender; 
    }

    function doSomething() {
        if (msg.sender == owner) {
            // only the owner can do something, like storage access
        }
    }
}

This logic can be extended to your needs, you could create structs or arrays holding a list of allowed user accounts, or you could create a logic which allows dynamic addition and removal of privileged users. This is all up to you.

If you only want each user to have access to it's own data, you could either store that data in structs with dedicated owner accounts like you described in 1 or, I would recommend that every user creates it's own contract for the storage which would be the most clean way regarding accessibility.

The main contract just has to maintain a list of references for external contracts, so there is not really redundancy in 2 if you have a main contract which holds the storage logic and dedicated contracts for each user who has to store data.

Upvotes: 2

Related Questions