aragonOS icon indicating copy to clipboard operation
aragonOS copied to clipboard

Make it easier to dynamically generate callscripts in the EVM

Open sohkai opened this issue 6 years ago • 3 comments

@Quazia noted this would be really nice to have in their implementation of range voting, which, at a vote's execution, replaces the last parameter in a saved callscript with a dynamically generated array based on voting percentages.

There's a few options:

  • Include some helpers for manipulating the length and parameters in ScriptHelpers.sol
  • Use the input field in the CallScriptExecutor to have it dynamically generate a new callscript
  • Similar to above, but create a new DynamicCallScriptExecutor with that functionality instead.

So far I think the last one sounds the best (could probably also add helpers to the script helpers as well anyway).

sohkai avatar Jun 07 '18 16:06 sohkai

I agree the last option with additions to the script helpers would be ideal.

Quazia avatar Jun 12 '18 23:06 Quazia

I really like what could be accomplished with this :)

This exact motivation is actually what brought us down the rabbit hole of implementing DelegateScripts to avoid writing a small VM inside the EVM. I still think that using the EVM here is superior to implementing a scripting language ourselves.

DelegateScripts could be securely brought back if we can ensure that the script is not going to self-destruct or modify storage, which could be done by analyzing the bytecode of the script and checking it doesn't have any of the opcodes we want to avoid, in this case sstore and selfdestruct + delegatecall (to ensure that no other code can be run).

izqui avatar Jun 14 '18 09:06 izqui

Just documenting here a conversation I had with @jbaylina today about the opcode checker for contracts, total credits to him :)

He brought up the possibility of 'hiding' some code as part of a PUSH instruction and then try to jump to it. For example: PUSH4 (JUMPDEST PUSH1 00 SELFDESTRUCT) PUSH1 01 JUMP which will attempt to jump to pc 1 which could then selfdestruct, but the opcode checker doesn't check. Good news is that the EVM doesn't allow to jump to a jumpdest inside a push argument (See yellowpaper section 9.1) and this will fail with an 'invalid jump' (see tx debug)

We couldn't figure out any other ways to 'hide' malicious bytecode that the checker wouldn't catch.

izqui avatar Jun 16 '18 20:06 izqui