3

I have a function which negotiates an agreement between two parties using a state channel, to accomplish this I need two signatures bytes32 e, uint8 v, bytes32 r, bytes32 sx2 for the state channel, and I need some variables for each persons agreement that are signed by the state.

This results in a stack too deep error. My workaround is to compress the signatures and variables into a bytes32[] array and type cast where needed. This seems dumb. Anyone have a better way?

Improve this question
3

If you're dealing with repeated data types it's more natural to group them into arrays by type, eg

function myThing(bytes32[] es, uint8[] vs, bytes32[] rs, bytes32[] ss)

This also tends to reduce code duplication inside the function, as you will only need one line doing ecrecover, which you then repeat in a loop.

If you're still short of variables, you may also want to consider breaking part of the functionality out into another function.

Improve this answer
4
  • 1
    Its a public function that runs as one transaction. I had this thought as well but in this case it was more natural for making bytes32[]. Thanks for validating my suspicion that there really is not a much better way
    – OneChillDude
    Oct 9 '17 at 1:43
  • 1
    If the stack-too-deep error is triggered by variables you use inside the function rather than purely by the number of parameters then it may still help to split the functionality up internally.
    – Edmund Edgar
    Oct 9 '17 at 1:53
  • 1
    Is there a good reason for this limit? Technically it seems totally arbitrary. Like, I can have a dynamic length raw byte variable but I can't have 17 uint8s?
    – OneChillDude
    Oct 9 '17 at 1:56
  • 2
    See gory details here: github.com/ethereum/solidity/issues/2693
    – Edmund Edgar
    Oct 9 '17 at 2:22

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.