1

I have a question about how one can deal with complex smart contracts in ethereum. Let's assume i have to deploy and interact with a smart contract that has a lot of functions, and each call to a function has a big cost in terms of gas. We can even imagine that the smart contract deployment, or calling one of its functions exceeds the limit of gas per block, so that we cannot deploy the SC or interact with it.

contract Test {
    type1 public testVar1;
    type2 public testVar2;
    //... other variables ...
    typeN public testVarN;

    function myFunction1(typeVar1 someVar1, typeVar2 someVar2)
    {
        //some computations ;
    }
    function myFunction2(typeVar1 someVar1, typeVar2 someVar2)
    {
        //some computations ;
    }
    //... other functions ...
}

It is possible to use ethereum events instead of the computations that are processed within each function, and make peers do the computations locally.

contract Test {
    //no variables ;

    event myFunctionEvent1(address from, typeVar1 someVar1, typeVar2 someVar2);
    event myFunctionEvent2(address from, typeVar1 someVar1, typeVar2 someVar2);

    function myFunction1(typeVar1 someVar1, typeVar2 someVar2)
    {
        //no computations ;
        myFunctionEvent1(msg.sender, someVar1, someVar2);
    }
    function myFunction2(typeVar1 someVar1, typeVar2 someVar2)
    {
        //no computations ;
        myFunctionEvent2(msg.sender, someVar1, someVar2);
    }
    //... other functions ...
}

Main idea : If all the peers agree on the changes that occur on the SC variables while calling its functions, than, keeping the functions calls in the BC (only the calls, not the effects) is enough for knowing the state of SC variables at each moment. In other words, a smart contract is like a deterministic automaton : by keeping all the "inputs", we can know the whole state of the SC (values of all of its variables...). Also, a smart contract that would keep only events could potentialy have an almost infinite complexity, since events don't cost that much gas.

What would be the limits or the inconveniants of such way of implementing smart contracts?

Thanks in advance for replies.

0

One issue is that if there's no way to access the current state from the chain, it would be difficult for other contracts to interact with it. If there is some way for all participants to agree on what the state is and prove this (by all signing a hash of said state, for example) then computation could be done offchain and submitted when finished. This essentially creates a state channel, a known technique.

-1

I'll venture a two-part answer based on my current understanding and opinion.

First, complex and expensive ops often include elements of iteration and/or recursion. In most cases, the simple resolution is to transfer control to a trusted client (or cluster of trusted clients for redundancy - implementation detail outside the the contract).

So ...

function loopy() {}

and

function recursive() {}

can be re-conceived as

function singleStep() onlyTrusted {}

Second, a more interesting structure could involve outsourcing expensive computations more generally. Given a set of inputs and deterministic algos, clients would be able to correctly calculate outcomes and then act on their own conclusions.

It's possible to consider outsourcing policing.

Have a look here for some ideas like

function computeState() {}

function reportLiar() {}

General idea is the crowd is incentivized to pounce on an actor who has attempted to act on an incorrectly computed state. Being deterministic, state can be confirmed by everyone else.

https://gist.github.com/MaiaVictor/441e32a3ddf2acbe8abe46dfecdf5345

Not an endorsement. It seems to rhyme with your thoughts.

Hope it helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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