-
Notifications
You must be signed in to change notification settings - Fork 0
Script Based Timelock
Script Based Timelock
Author: Joonmo Yang<[email protected]>
Created: 2019-10-30
This CIP describes a new set of opcodes for CodeChain VM that retrieves the current absolute time and the relative time since the asset was created. It includes ABSBLK
, ABSTIME
, RELBLK
, and RELTIME
.
Timelocks in CodeChain is implemented by the specialized field timelock included in the AssetTransferInput
data structure combined with the CHKTIMELOCK
instruction. Although it already serves the purpose for simple cases, it can only represent one timelock condition for a single asset. If there are instructions that retrieves the current time information to the stack, the existing timelock scheme’s behavior can be implemented by comparing the expected time with the retrieved information. Since there are no restrictions on the number of same instructions in a single script, multiple timelock conditions can be specified with these opcodes.
- Get the block number of the block that the script is executed in(refer to this value as b)
- Push b to the stack.
- Get the timestamp of the block that the script is executed in(refer to this value as t)
- Push t to the stack.
- Get the block number of the block that the asset was created in(refer to this value as b1)
- Get the block number of the block that the script is executed in(refer to this value as b2)
- Push (b2 - b1) to the stack.
- Get the timestamp of the block that the asset was created in(refer to this value as t1)
- Get the timestamp of the block that the script is executed in(refer to this value as t2)
- Push (t2 - t1) to the stack.
seulgi.kim ABSBLK and ABSTIME look clear to me. But when do we need RELBLK and RELTIME? And how can we implement them while we don’t have data on the asset creation time on the chain?
jmyang
REL*
would be used when the transaction sender wants to specify condition with the time passed after the transaction was confirmed. It can be useful since we usually don't know when the transaction will be included in the chain when creating it.
I haven't looked the implementation in detail, but CHKTIMELOCK
opcode already handles all the four types of time information. I simply thought that it would be possible since CHKTIMELOCK
is already implemented.
seulgi.kim I checked the code. The VM asks the client about the block number that contains the transaction. The same flow can be applied here.