Allow execution of callscript on votes not passing about aragon-apps

[onbjerg]

Maybe something like

1. Send tx that encodes forward(script) to voting app () from staking app ()
2. calls attachMetadata(keccak(script), voteId) on
   • MAY store the attached metadata for further reference
3. ✨ Time passes ✨
4. Iff...
   • Vote fails then MUST call forwardFailed(keccak(script)) on
   • Vote succeeds, then MUST call runScript(script)

In this example, the metadata can be used in the staking app to identify "stake pools" (see the repo in Aragon Labs for a brief explanation of what a stake pool is).

Other possible names for rejectForward

• reject (too vague)
• forwardFailed (may be mistaken for forwarding a failed transaction)
• failedForward

Other possible names for attachMetadata

• attachScriptIdentifier (less vague)
• attachIdentifier (vague)

The reason for attachMetadata (as opposed to just identifying scripts solely by keccak(script)) is that identifying e.g. stake pools using only keccak(script) is impossible, since the script for creating a vote is different from voting in a vote.

Open issues

• What about apps that may not have metadata to attach? These will probably be apps that always only do 1 thing, such as the group app, so it might suffice for these to just attach keccak(script) as metadata.
• What about gas costs?
• How do we guard the attachMetadata function to make sure no outsider calls it?
• If this should work, then how frequently do we call attachMetadata? For example, for this to work, votes must also call back (if the caller is a forwarder contract) with the vote ID, which might be super gas intensive.

[onbjerg]

I think generalizing it with something where forwarders call a standard function (reject? failedForward?) with some standardized data (a unique identifier for the app? or keccak256 of the failed script?) would be beneficial.

[izqui]

This has to be a variable of the voting app, but we cannot set it in every vote, as it would allow to execute anything regardless of vote result.

[onbjerg]

@izqui Can we just put this in the icebox for a moment? We might solve the actual issue another way, the more we've talked about this one the more uneasy I feel adding it

[izqui]

Yes, removing it from the code freeze milestone for the moment

[sohkai]

A thought for the future: would it be possible to do this by standardizing a "failure" case in the forwarders? Right now, only the voting app can "fail" forwards (every other app just automatically approves a forward, given correct discovery mechanisms) but there will likely be more apps in the future that will require user interaction for approvals.

We can handle this via an override in the forwarder's interface:

function forward(bytes _actionEvmCallScript) public
function forward(bytes _actionEvmCallScript, failureEvmCallScript) public

[onbjerg]

@sohkai Yes that was discussed, too, but the issue is that the two callscripts have to produce different outcomes.

Intuitively one would think that just checking if the two callscripts are different would suffice, but they might be different and still produce the same outcome.

Consider for example an attacker that would want to send funds from the Vault to their address. They would create a vote with a callscript that does this on success, but on failure it would transfer to e.g. a simple contract that sends funds it was given to his address.

In this scenario, he would receive funds regardless.

[izqui]

Yes, my idea is that this reject callscript could be a state variable of the voting app that gets executed on failure of all votes. This isnt that useful before we can pass parameters/attributes to callscripts (related aragon/aragonOS#166 and aragon/aragonOS#161)

[luisivan]

I love your notation @onbjerg

[izqui]

I have a feeling that this might work too. Maybe it could even be generalized as a 'forwarding feedback protocol', in which you can expect a callback with some data after performing a fwd.

Is attachMetadata only called back to when the vote is created?

PS: Dat Latex

[onbjerg]

@luisivan thanks man

@izqui Well that's sort of an open issue, as I mentioned in an edit:

If this should work, then how frequently do we call attachMetadata? For example, for this to work, the act of voting must also call back (if the caller is a forwarder contract) with the vote ID, which might be super gas intensive.

PS: ye boi

[sohkai]

Closing; this is not directly in scope for an additional improvement on top of the current Voting app or aragonOS forwarding structures, and is generally difficult to configure or avoid abuse.