Lisk Research – Quick Overview of LIP 12

by francescov · Published September 3, 2019 · Updated September 6, 2019

The in-depth series on Lisk Research and LIPs continues on Lisk Magazine. Today we will deal with LIP 12, which recommends the removal of superfluous properties of transaction objects in the current protocol.

LIP 12 has been drafted by Andreas Kendziorra with the contribution of Oliver Beddows. Developers noticed a surplus of properties of transaction objects that increase the size of transactions and the complexity of the protocol with no benefit, therefore they suggest to remove them.

Andreas explained that in the current protocol it is possible to use property-value pairs in transaction objects that are neither necessary nor in use. These property-value pairs are featured both in the JSON objects used to communicate transactions and in the input messages for the transaction signature and the transactionID generation. As a result, the pairs increase the data transmitted between nodes, slowing down the transaction processing. Although, as developers explain, even if the effect might be minimal, confusion may arise when reading the protocol and its implementation becomes unnecessarily big. For these reason they propose to take out all the property-value pairs in excess.

The properties are not all redundant in the same way. For example, the amount and the recipientId properties are only necessary for balance transfer transactions, but not for any other type of transaction. Just to name another example, the requesterPublicKey property is a legacy property that is no longer required for any type of transaction.

In particular, these properties are allowed for transaction JSON objects when transmitted: amount, asset, fee, id (optional), recipientId, recipientPublicKey (optional), requesterPublicKey (optional), senderId (optional), senderPublicKey, signature, signatures (optional), signSignature (optional), timestamp, type.

The properties identified as redundant are: amount, fee, id, recipientId, recipientPublicKey, requesterPublicKey and senderId. The remaining are fundamental, so developers suggest to not remove them.

Superfluous properties are analyzed more in detail by Andreas:

Amount and recipientId: this two properties are required for every transaction object, but they are relevant only for balance transfer transactions. For this reason, developers propose to move them from the transaction objects to the asset property of balance transfer transactions;
Fee: the fee of a transaction can always be deducted from the transaction type due to the fixed fee system, so there is no need for this;
Id: it is always possible to determine the id of a transaction from other properties. Furthermore, it is not convenient to provide the id when sending a transaction because a node that receives a transaction needs to verify all properties, and to verify the id it is necessary to compute the id. So developers propose to remove id property from transaction JSON objects;
RecipientPublicKey: the recipient of a balance transfer should always be determined by its address and all other transaction types do not have a recipient. So developers suggest to remove this property since it is not needed;
RequesterPublicKey: initially this property was designed to be used to request multisignature transactions by non-account holders. However this feature is currently not enabled and so developers suggest to eliminate it;
SenderId: there is no need for this property because the senderPublicKey is a required property for every transaction object and it is always possible to compute the address/id from the public key.