In this thread, I want to propose a new LIP “Introduce transaction properties moduleID and assetID”. This proposal defines numbering of the transactions using the new properties moduleID and assetID.
Looking forward to your feedback.
This LIP proposes to replace the
type property in transaction objects by two new properties:
assetID. Both properties
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:
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.
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
type property of the transaction object is replaced by
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.
(<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
assetID values for the current default modules and transactions.
|Transactions||Lisk Core 2.0 Type||moduleID||assetID|
|Multisignature Group Registration||4||4||0|
|Delegate Misbehavior Report||5||3|
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,
assetID. Therefore transactions according to the current protocol would be invalid in the proposed protocol and vice versa.