Volatile Tokenscript attribute

Tokenscript Design
1

While designing the cryptokitties tokenscript we realised that a 'volatile' function attribute is required.

For example, there may be a function call to determine if a kitty is ready to give birth. The result of this call is dependent on block time since kitty was bred. Since there is no event published between the result being false and the result bring true, the function return should never be cached since there's no event or transaction update that heralds a value change.

1 Like
2

Taken in, thanks loads!

3

It could be added to functions like this, from the cBAT script:

    <ts:attribute-type id="supplyInterestRate" syntax="1.3.6.1.4.1.1466.115.121.1.36" tags="volatile">
        <ts:name>
            <ts:string xml:lang="en">Supply Interest Rate</ts:string>
        </ts:name>
        <ts:origins>
            <ts:ethereum as="uint" contract="cBAT" function="supplyRatePerBlock">
            </ts:ethereum>
        </ts:origins>
    </ts:attribute-type>

Notice that the supply rate is a dynamic; it must be updated from a transaction but could be updated in a contract other than the cBAT itself. Labelling this as volatile ensures the wallet will always fetch the transaction and not rely on the cache.

4

Recap what was the status of discussion:

  1. value is triggered by an event (maybe a different contract than the token contract, e.g. a contract that monitor's voting result)

  2. an event is updated every block or almost every block (e.g. a contract that reports Ethereum price).

In the No.2 case, the re-fetch (tick) doesn't have to be more frequent than block production and since the ENGINE knows block production it doesn't have to require more frequently. In the 1) case, the attribute has 'origins' that links it to the ethereum event it triggers.

There is a 3rd condition that the value changes but there are no event, e.g. in compound the system emits no useful event at all, partly because the team wasn't looking to integrate anything. That's the place where a frequency might be needed, but in that meeting, we weren't too keen on that and subconsciously think it's the same of 2). Maybe we should have taken care of it with a special case 3 - in the coming TS meetings.

5

Block times are at least in the order of seconds, some in minutes and has a certain amount of predictability. Perhaps side chains are different? Is this a valid observation?

Can we make use of that to simplify and optimize the design for handling volatility? Or maybe we can't, for interoperability to non-blockchain systems?

6

Oh yes we should use that to simply and optimise the engine! And what blockchain is at work is known to the engine anyway since it's the property of the chain not the property of the token hence not requiring any non-generalisable attribute anyway. I hope there is an IPC call provided by node like geth where an engine can simply get notified of a new block's creation. @JamesB?