Script Based Timelock

Script Based Timelock

Author: Joonmo Yang<jmyang@codechain.io>

Created: 2019-10-30

1. Abstract

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.

2. Motivation

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.

3. Specification

3.1. ABSBLK(0xa0)

  1. Get the block number of the block that the script is executed in(refer to this value as b)
  2. Push b to the stack.

3.2. ABSTIME(0xa1)

  1. Get the timestamp of the block that the script is executed in(refer to this value as t)
  2. Push t to the stack.

3.3. RELBLK(0xa2)

  1. Get the block number of the block that the asset was created in(refer to this value as b1)
  2. Get the block number of the block that the script is executed in(refer to this value as b2)
  3. Push (b2 - b1) to the stack.

3.4. RELTIME(0xa3)

  1. Get the timestamp of the block that the asset was created in(refer to this value as t1)
  2. Get the timestamp of the block that the script is executed in(refer to this value as t2)
  3. Push (t2 - t1) to the stack.

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?

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.

I checked the code. The VM asks the client about the block number that contains the transaction. The same flow can be applied here.