Proposal Template Schema Updates

[alexyoung23j]

A limitation with our proposal template schema has been identified.

Current Status:

• Proposal template can be created to handle simple transactions such as a token transfer. This has been tested and works correctly.

Issue:

The problem arises when we have arguments within the method on the transaction template that depend on other parameters in the method, or on the contract itself.

An example here is the propose method on the OpenZeppelin governor alpha contract. It expects an argument called calldatas. As can be seen in this test example, the value of calldatas can be the result of a function called encodeParameters, which takes an acct as an argument. Since the acct would be one of the pieces of form state (i.e., a "field_ref" in the proposal blob), we cannot simply pass its output as a string at template creation time. It needs to resolve dynamically based on user inputs in the parser page.

So we need to rethink the schema slightly to address two problems:

1. The tx_template has no way of accessing details of the specific contract it is attached to.
2. The tx_template has no way of defining input thats are functions that take field_refs as parameters.

@jnaviask @MuonShot @zakhap , something to think about before we decide to ship bet1. Seems to me that most of the value the bet provides is related to templates for actions like propose.

Possible solution sketch:

1. define registry of allowed functions- things like encodeParameters, others that we identify (can just be added ad hoc for new templates I suppose).
2. define a new "special" ref- something like '$CONTRACT_ADDRESS' that the parser will just always replace with the contract address.
3. define a function ref- something like '&myWhitelistedFn($abitrary-ref, $CONTRACT_ADDRESS, 'simple-value', ...)'. The parser check if the function is in the registry and then call it with those inputs before formatting the tx. It can then be used in the tx_template just like the simple state refs are already.

Also could allow them to pass an endpoint for a lambda that runs the specified function- have to think about the UX in that case.

[CowMuon]

Updated label as this appears to be a blocker, not blocked. @alexyoung23j

[CowMuon]

Here is the example template we have been using (this is not the template that is blocked, obviously.)

  form_fields: [
    {
      text: {
        field_name: 'subtitle',
        field_type: 'h2',
        field_value: 'Transfer Tokens',
      },
    },
    {
      input: {
        field_name: 'address',
        field_label: "Who's the recipient?",
        field_ref: 'address-ref',
        formatter: 'address',
      },
    },
    {
      input: {
        field_name: 'amount',
        field_label: 'How much should we transfer to them (decimal 18)?',
        field_ref: 'amount-ref',
        formatter: 'token',
      },
    },
  ],
  tx_template: {
    method: 'transfer',
    args: {
      to: '$address-ref',
      amount: '$amount-ref',
    },
  },
};```

[CowMuon]

Here's the template that is supposed to work but results in this issue:

  "form_fields": [
    {
      "text": {
        "field_name": "title",
        "field_type": "h1",
        "field_value": "Create a New Proposal"
      }
    },
    {
      "input": {
        "field_name": "name",
        "field_label": "Enter proposal title",
                "field_placeholder": "example title",
        "field_ref": "name-ref",
        "formatter": "string"
      }
    },
    {
      "divider": {
        "field_name": "divider"
      }
    },
    {
      "text": {
        "field_name": "subtitle",
        "field_type": "h2",
        "field_value": "Parameter Change: Set Tax"
      }
    },
    {
      "input": {
        "field_name": "tax man tax man",
        "field_label": "Set the tax man",
        "field_ref": "tax-ref",
        "formatter": "number"
      }
    }
  ],
  "tx_template": {
    "method": "propose",
    "args": {
      "target": [
        "0xProtocolAddress"
      ],
      "calldata": [
        "setTax"
      ],
      "values": [
        "$tax-ref"
      ],
      "description": "$name-ref"
    }
  }
}```

[ianrowan]

At first look here the issue as I understand it is that we need to be able nest a tx formatter within a proposal(or other) tx template where calldata(or signatures, etc) bytes are requested.

An initial thought is that the creator of a template will not typically know all of the functions they may want to nest in the future, so I think its valuable to abstract that out to our own mapping/data. To achieve this we should store(db or FE) a mapping of solidity param types to default input field producers.

(ie uint256 => Numerical input, string/bytes => any string input, address => string input w/ addr validation)

If we do this, we can follow a flow like the following for a proposal builder: for a governor bravo proposal propose(address[] targets, uint256[] values, bytes[] calldatas, string description)

1. User may set up a template as follows:

   form_fields: [
   {
     text: {
       field_name: 'subtitle',
       field_type: 'h2',
       field_value: 'Transfer Tokens',
     },
   },
   {
     input: {
       field_name: 'address',
       field_label: "List of target Contract addresses",
       field_ref: 'address-ref',
       formatter: 'address-list',
     },
   },
   {
     input: {
       field_name: 'values',
       field_label: 'Value in ETH to send to each address',
       field_ref: 'value-ref',
       formatter: 'value',
     },
     FunctionBuilderSelection: {
       field_name: 'Calldata',
       field_label: 'The Calldata to send to each Contract address',
       field_ref: 'calldata-ref',
       contract_link: 'address-ref'
       formatter: 'function-data',
     },
   },
   ],
   tx_template: {
   method: 'propose',
   args: {
     address[]: '$address-ref',
     uint256[]: '$value-ref',
     bytes[]: '$calldata-ref',
     string: '$description-ref'
   },
   },
   };`

   I'm probably doing some things wrong here based on our current implementation but here's the parts I meant to include:

   • args are the solidity types and the param names can be set in the form fields. This is b/c we will create our tx by encoding these
   • FunctionBuilderSelector Input type. includes a 'contract_link' key which points to the associated contract object the calldata will be sent to. This is important so we know which contract to use for Abi lookup

2. Our FE parses this form as usual. Upon a FunctionBuilderSelector field

   1. Check 'contract_link'
   2. Get current value(contract address) from contract_link field on FE
   3. Check DB for abi for contract from that field. Alternatively get contract ABI from etherscan ABI
   4. parse abi for all available functions and populate a dropdown for the CallData field with functions available
   5. When a function is selected lookup input field types for each param in abi and populate UI with those.
   6. Click encode and run web3.abi.encodeParameters()
   7. Add this to the array of call data

3. Encode all parameters including built call data and send tx.

This is just a rough sketch and I know we'll need to think through how to add each item of call data(maybe a + button to add to array up to the length of the address/target array)

[ianrowan]

"tx_template": { "method": "propose", "args": { "target": [ "0xProtocolAddress" ], "calldata": [ "setTax" ], "values": [ "$tax-ref" ],

In this case and in most governance contracts, 'value' refers to the ETH value to be sent with a tx. So here, we're setting the param for SetTax as value where as we should be encoding the calldata to support the function selector 'SetTax(uint256') the encoded parameter of 'tax-ref'

Relating to my above comment(I was thinking about general implementations there, not hard coding options for proposals) We would want to think about building out a nested form for the calldata section that included the proposed input fields, titles, etc. From there just support logic to support step vi-vii from my above comment

Maybe in this case we give the option to bypass the contract link and add a tx_form

      FunctionBuilderSelection: {
        field_name: 'Calldata',
        field_label: 'The Calldata to send to each Contract address',
        field_ref: 'calldata-ref',
        tx_forms: [
          { functionSelector: 'SetTax(uint256),
            paramRefs: ['tax-ref']
             form: [  {
                         "text": {
                         "field_name": "subtitle",
                         "field_type": "h2",
                         "field_value": "Parameter Change: Set Tax"
                        }
                       },
                       {
                         "input": {
                         "field_name": "tax man tax man",
                         "field_label": "Set the tax man",
                         "field_ref": "tax-ref",
                         "formatter": "number"
                     }
                   }              
           ]
      },

The idea here is that instead of having a dynamic contract_link to look up any ABI we can hard code and add formatting for a typical template like setTax. each object in 'form' will get hashed in to calldata and added to the call data list while the FE can use the form data to populate the CallData FunctionBuilderSelection. A functionBuilderSelector should always have a contract_link(dynamic to address) or a form(static to a typical proposal pattern) but not both.

[ianrowan]

Condensing/TL;DR of my thoughts above:

I think the 'easy win' here and maybe the short term solution is to:

• Include a form_field key for 'FunctionBuilding' that can be referenced by a call data arg
• within a FunctionBuilding element include a list of tx_forms that include a template for the nested function the calldata needs to encode
• When our Component code is building the form and comes upon a 'FunctionBuilder', recursively call the form_builder to build a nested form under the CallData subtitle.
• when full tx is built include logic in FunctionBuilding input to encode the calldata

This allows for templated spend, param, etc proposals

I'd say the first set of ideas I mentioned, where we dynamically pull abis for provided contracts could be a stretch goal but definitely valuable.

Thoughts @jnaviask @zakhap @CowMuon ?

[ianrowan]

https://github.com/hicommonwealth/commonwealth/commit/805d5a96a6b9212059647d7c310df4b5a6ba4515 prototype(logic only, not UI yet) of how we could handle the proposed schema

[jnaviask]

I think this is a fine solution. We may want to eventually consider exposing the signature of the function we're providing as calldata, because that's a required parameter on compound proposals.

[jnaviask]

What I would like to see is what schema modifications this requires -- we may want to also add a version to the schema in case we need to edit it further later.