LIP: 0036
Title: Introduce transaction properties moduleID and assetID
Author: Shusetsu Toda <shusetsu@lightcurve.io>
Status: Replaced
Type: Standards Track
Created: 2020-09-16
Updated: 2024-01-04
Requires: 0028
Superseded-By: 0068
This LIP proposes to replace the type property in transaction objects by two new properties: moduleID and assetID. Both properties moduleID and assetID together must correspond to one unique transaction schema, transaction validation and execution logic.
This LIP is licensed under the Creative Commons Zero 1.0 Universal.
A unique way to identify a specific schema and execution logic of any transaction asset is required. For this purpose, the type property of a transaction is currently used to handle the identification in a generic way.
However, the new on-chain architecture implemented in Lisk SDK encapsulates multiple types of transaction assets in a module. Therefore, transaction properties that can identify the module and asset are required.
Also, further development of an application often introduces breaking changes, and a consistent way to handle the implementation is necessary. This facilitates not only future development and code maintenance but also the compatibility with third party services.
With the current on-chain architecture of Lisk SDK, a module contains multiple asset definitions. For example, the DPoS module contains 4 asset types which are delegate registration, delegate vote, token unlock and delegate misbehavior report.
In order to handle the routing of a transaction to a specific module of a specific asset, we define in this proposal two identifiers that will represent two new properties in the transaction object: moduleID and assetID. The property moduleID accounts for which module the transactions belong to and assetID accounts for the specific transaction asset inside the module. In particular, a tuple (<moduleID>, <assetID>) must uniquely correspond to one asset schema, validation and execution logic.
Moreover, moduleID must be greater than or equal to 2 because it is used for the field number of the account schema which is used for the corresponding module, and field number 1 is taken by the address property in the schema defined in LIP 0030. Also, we do not use the value of moduleID 3 in any transaction below because it is associated with the “sequence module”, which doesn't have custom transaction assets.
The second passphrase registration, dapp registration, dapp-in and dapp-out transactions are going to be removed and are therefore not assigned a moduleID and assetID.
The type property of the transaction object is replaced by moduleID and assetID, where both properties are of type uint32. The serialization of transactions with these properties is defined in LIP 0028.
For every module, the value of its moduleID must be unique for one blockchain, and for every asset within the same module the value of assetID must be unique.
A tuple (<moduleID>, <assetID>) must uniquely correspond to one
- transaction schema,
- transaction validation and verification logic,
- transaction execution logic
in one blockchain. This means that for any change with respect to the three aspects above a different tuple (<moduleID>, <assetID>) must be used for the new transaction. Typically, the new transaction is still contained in the same module, i.e., the value of moduleID stays the same, and a new unique value of assetID is used.
The following table specifies the moduleID and assetID values for the current default modules and transactions.
| Transactions | Lisk Core 2.0 Type | moduleID | assetID |
|---|---|---|---|
| Token Transfer | 0 | 2 | 0 |
| Multisignature Group Registration | 4 | 4 | 0 |
| Delegate Registration | 2 | 5 | 0 |
| Delegate Vote | 3 | 5 | 1 |
| Token Unlock | 5 | 2 | |
| Delegate Misbehavior Report | 5 | 3 | |
| LSK Reclaim | 1000 | 0 | |
| Second passphrase | 9 | Removed | |
| Dapp Registration | 5 | Removed | |
| Dapp In | 6 | Removed | |
| Dapp Out | 7 | Removed |
Following points should be considered;
- We will reserve the
moduleIDvalues up to 999 for default modules shipped with SDK.
The LIP introduces a hard fork because the type property of transactions in the current protocol is proposed to be replaced by two new properties, moduleID and assetID. Therefore transactions according to the current protocol would be invalid in the proposed protocol and vice versa.