[Ethereum] the best practice to store and retreive large data in solidity smart contracts

contract-designcontract-developmentdapp-designdapp-developmentsolidity

Assume, I have an event creation page with some form fields in UI. And I have a smart contract to store the event in events mapping or the public array in some struct format.

struct event{
      bytes32 name;
      uint time;
}

event[] public events;

or

mapping(uint=>event) public events;

I'm submitting the UI and data is stored in the contract.

I have a list events page, which will display all the events created in the contract.

After searching many forums, I got some info, can someone validate this.

Approach 1:

For every submits or save in contract, an event is called and UI is having the watcher and stored in the local storage and displays in the UI. The events data can be a mapping or array here.

I don't want to have any intermediate storage for the application, so whenever the UI refresh the event watcher will receive all the state data and again update the local storage and display in the UI.

Approach 2:

For event submit new event object is created and pushed into the events array.

And writing the get events method, to iterate the events array and returns the list of string elements for each key in the object and then again concatenating and destructure the strings in an array of objects in UI to bind with the UI.

I think the computation for the second approach will be high because of the iteration. Since we are developing the Dapp I don't want to have any intermediate database again which become as a centralised system.

Can someone explain the various possibilities of storing and retrieving data from the smart contract which is a preferable way so far.

It will help me a lot. Thanks in advance.

Best Answer

event is a keyword in solidity that allows you to easily retrieve data that a contract generated in a Javascript frontend. It is cheaper in terms of gas to write an event than to write into a storage variable (like your struct array). You can then .watch for these events and pull them into your UI. This is the recommended way to go. For performance reasons you might want to cache these event data somehow because parsing through all blocks on every reload is fairly inefficient.

Also, do not try to fit all your data into your smart contract. The job of a well-designed Dapp is to contain nothing more than the absolutely required elements and pointers to external structures but keep your storage-layer separated from the blockchain. A storage layer could be implemented via IPFS or Swarm.

Related Solutions

Solidity – Query Multiple Smart Contracts’ Public Data

This is a hub & spoke pattern adapted to roughly map to your code. The Hub deploys Person contracts and keeps track of them. You can iterate over the unordered list from web3 and delete an item from the list if needed. You can add or remove person and hub privileges at the person level. For example, if you want, you can have a selfDestruct function in the Person contract and make it onlyOwner (only Hub can destroy it) or onlyPerson for self-delete. Presented without warranty. Very little testing. ;-)

pragma solidity ^0.4.6;

contract Hub {

  // two-way interable index with delete
  mapping(address => uint) personMap;
  address[] public personIndex;

  address public owner;

  function Hub() {
    owner = msg.sender;
  }

  modifier onlyOwner() {
    if(msg.sender != owner) throw;
    _;
  }

  function createPerson() 
    public
    returns(address newPerson)
  {
    Person p = new Person(msg.sender);              // whoever called this will "own" the Person contract created
    personMap[p] = personIndex.length;              // remember where it lives in the unordered list
    personIndex.push(p);                            // append to the end of the list
    return p;
  }

  function deletePerson(address person) 
    onlyOwner
    returns(bool success)
  {
    // step by step for clarity
    uint location = personMap[person];              // location on the list
    address personAddress = personIndex[location];  // should match the person
    // as one line
    if(personIndex[personMap[person]] != person) throw; // non-existent person
    // move the last item in the index to the location where the unperson was
    personIndex[personMap[person]] = personIndex[personIndex.length-1];
    // also have to update the personMap because the last item changed position in the list
    // whoever was in the last row is now in the row where we are removing a record
    personMap[personIndex[personIndex.length-1]] = personMap[person]; 
    // now the list is shorter
    personIndex.length--;
    // person is removed from the list
    return true;
  }

  // the next two functions make the unordered list of contracts iterable

  function getPersonCount() 
    public
    constant
    returns(uint count)
  {
    return personIndex.length;
  }

  function getPersonAtIndex(uint index)
    public
    constant
    returns(address person)
  {
    return personIndex[index];
  }
}

contract Person {

  // address public owner;
  address public personOwner;

  struct PersonStruct {
    bytes32 encrypted1;
    bytes32 encrypted2;
  }

  PersonStruct p;

  modifier onlyPerson {                       // add this to functions only the "person" passed in should be able to do
    if(msg.sender != personOwner) throw;
    _;
  }

  function Person(address person) {
    personOwner = person;                   // passed in by the creating Hub
    // owner = msg.sender                   // this would enable the Hub to have certain privileges if needed
  }

  function getPerson()
    onlyPerson
    constant
    returns(bytes32, bytes32)
  {
    return(p.encrypted1, p.encrypted2);
  }

  function setPerson(bytes32 part1, bytes32 part2)
    onlyPerson
    returns(bool success)
  {
    p.encrypted1 = part1;
    p.encrypted2 = part2;
    return true;
  }
}

Solidity – Efficiently Accessing Mappings in Solidity

It is a bit hard to know in advance which method is optimal. In your scenario, gasEstimate states that the second method is less expensive.

To test your implementation I stripped everything from the contract except for the assign of the value (also I have a fake structure):

CONTRACT

// contracts/Box.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;



contract Optim {
    struct Session {
        uint256 raised;
    }

    mapping(uint256 => Session) sessions; 
    
    
    constructor() {        
        sessions[1] = Session(1);
    }

    function direct(uint256 _id) public payable {            
        // update state
        sessions[_id].raised = sessions[_id].raised + 999;        
    }   

    function tmpvar(uint256 _id) public payable {            
        // update state
        Session storage sesh = sessions[_id];
        sesh.raised = sesh.raised + 999;        
    }   
}

creating a simple test with truffle allows us to have some information:

gasEstimate.js

const Optim = artifacts.require("Optim");

contract("Optim", () => {
    it("should have different gas", async() => {
        const O1 = await Optim.new();

        const method1 = await O1.direct.estimateGas(11);
        const method2 = await O1.tmpvar.estimateGas(11);

        console.log("method1 cost: " + method1, "method2 cost: " + method2);
        assert(method1 < method2, "method 1 < method2");
    });
});

the console output is

method1 cost: 42762 method2 cost: 42675

therefore the second method is less expensive

Best Answer

Related Solutions

Solidity – Query Multiple Smart Contracts’ Public Data

Solidity – Efficiently Accessing Mappings in Solidity

Related Topic