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.