declaring ethereum transactions / function calls

An Ethereum transaction consists of

  • nonce - transaction sequence number fr the sending account
  • gasprice - price you are offering to pay
  • startgas - maximum amount of gas allowed for the transaction
  • to - destination address (account or contract address)
  • value - eth to transfer to the destination, if any
  • data - all of the interesting stuff goes here

The latter 3 are interesting for declaration - what do you want to see happen; while the former 3 are interesting for execution - to make it happen. We say that TokenScript's approach to transactions are declarative - it is up to the user-agent to assemble the transaction, so only the latter 3 are interesting to a transaction declaration. Let's consider a basic framework to declare a transaction:

<ethereum>
  <to>{address}</to>
  <value>...</value>                                                              
  <data>...</data>                                                                
</ethereum>

The same syntax would work for both smart contract function calls and native transactions. In the case of smart contract function calls, it can be:

<ethereum>
  <to>{contract address}</to>
  <value>...</value>
  <data function="xxx">...</data>
</ethereum>

The same syntax would work within a <transaction> element or within an <origins> element.

In <transaction>:

<transaction>
  <ethereum as="uint">
    <to>{contract address}</to>
    <value>1000000000000000000</value>
    <data function="gainFruit">...</data>
    <mapping>
        <option key="1">Apple</option>
        <option key="2">Orange</option>
    </mapping>
  </ethereum>
</transaction>

In <origins>:

<origins>
  <ethereum as="uint">
    <to>{contract address}</to>
    <data function="getCurrentFruit">...</data>
    <mapping>
        <option key="1">Apple</option>
        <option key="2">Orange</option>
    </mapping>
  </ethereum>
</transaction>

Apparently, you wouldn't put <value> when inside <origins>. Similarly, there might be a need for a <variable> element that makes sense only inside <origins> to access public variables†.

In the following posts, I will examine if we can continue on this with a design that can pass complex data structure (like tuple) while remaining compatible with attestation data types and explore if we give up that compatibility what's the best we can get.


† Since there are automatically created getters for every publically accessible variable (including those defined as mapping or array), <data> should suffice if an attribute's origin is a public variable or a member of a public array or a public mapping.

Unless a getter is not automatically created to access elements from a public variable defined as a mapping of mappings or an array of arrays, in which case we might need a special element <variable> to access the individual elements.

Also: chainId.