Gas saving measure when using loops

Support
1

I would like to validate with the community that my gas saving measure make sense and are actually saving gas when using loops in a smart contract.

After some research I found out that;

  • setting the state to a first value cost more gas than updating a value that was already there.
  • Dealing with Storage is the most expensive operation.
  • Using loops is dangerous.

With this in mind I came up with this.

contract {

struct _DATA{
uint256 _id;
address _user;
string _attr;
} 

function addStorage(some attrib){
  // this is an expensive function to add a new entry to the struct
 // we would add a ne entry and change the state for the first time for all attribute
}


function updateAttrib(some attrib){
  // this function will update the storage saving gas because data was already written there.
 // will cost less gas to update a few value. Would also help regulate the size of the _DATA
}

To perform multiple task on storage with loops and try to reduce gas.

function step1(uint256[] _id) public {
  // require()
  // first step verifications
  // make sure we have an exit point to the loop before starting it
  step2(_id)
}

function _step2isFirstLoop(_id) internal {
  uint256 i;

  for(i==0;i<_id.length;i++){
        // The step 2 perform verification to process transactions
        // Using memory to save on gas and evaluate the data
       _DATA memory data = data[i];

       require(thing to be true);
      // should revert here in memory rather than in storage loop
   }
   // all verification passed
_step3(_id)
}

function _step3(_ip) internal {
   //the last loop
   for(...){
    _DATA storage data = data[]
    // this is where we actually update the storage data
  }

}

Is there a way i could save even more gas?

1 Like
2

Hi @madeindreams,

Taking a step back:

  • Can you reduce what you store onchain?
    e.g. Do you need an ID?
    e.g. Do you need to store a string? Can this data be offchain and you only store a hash to it onchain?
  • Can you remove the loops?
    When loops get too big we eventually run out of gas. Can you do this offchain?
    Is there another way to validate the data?
    How are you storing the data, e.g. in a mapping?
1 Like
3

Well thats the thing. maybe there is a way to avoid loops. But here is my context.

Uniswap is working from a pool with prices base on the pair supply constant.
On the other hand a DEX works with orders

I want to mix both process which mostly rely on the front end. But the front end will send me an array of orders to fill. So the user that want to buy 500 tokens feel like he is using Uniswap, it’s a single click deal. But the price and amount are from best value orders at this time, Not from a pool. Then the user can also look at the orders and pick and choose what he feel is a best deal,

Orders come in array, Can be multiple pairs, Balance are held on DEX to prevent transfer cost.
I was also wondering if i was gona save a lot by reusing slots in the struct. Most developer just add to it, What if I was reusing it with a recurrent order process where you only update what you need on a previous order that is no longer active.

So this is already a way of reducing what I store on chain. I could recall an order I had before and renew it by only setting a bool to true kinda deal.

Now I’m not sure if there is a way I can avoid that loop to fill order[12,33,42,67]
Adjust balance in Dex contract for each order pair. that can be mixed and match.

I mean ppl are willing to pay 30$ to swap a single pair. I think that loop might cost me less for 4 pair trade. Not yet transferred however. But my loop would technically only loop based on the array length,

A first time order would have

id
makerAsset
makerAmount
takerAsset
takerAmount
filledAmount
active
timstamp

If i push a new order in it’s gota be more expensive than just updating the active value to true and that same order comes back up.

I will run test and see what I get. I’m just trying to think ahead.

Any ideas are welcome!

.

1 Like
4

So I did some test and even wrote an article about it cause I think it’s worth sharing.

1 Like
5

Hi @madeindreams,

Thanks for sharing :pray:

1 Like