Lisk Research – Quick Overview of LIPs 7 and 8
Continuing the overview of the Lisk Improvement Proposals, today we briefly introduce LIP 7 and 8. The former proposes a new versioning system for Lisk Core while the latter is aimed at the removal of the pre-hashing for block and transaction signatures.
The LIP 7 was developed by Maciej Baj, with the contribution of Oliver Beddows, Andreas Kendziorra and Jan Hackfeld. Their new versioning system for Lisk Core is capable of better reflect the continuous changes to the Lisk software implementation and its inherent blockchain protocol.
The current versioning scheme (semserver) provides Lisk software implementation changes in textual form. For example: “Changes to the public API endpoints, requests and responses”. The drawback of this versioning system is that it does not provide a logical capacity to transmit changes to the Lisk blockchain protocol apart from those relating to changes in implementation. This makes sure that, in the current versioning scheme, there is no distinction between protocol and implementation changes. As a consequence, delegates and node operators are not reliably informed about the changes of the proposed release because its type (software and protocol change) is not clearly communicated.
For this reason, their proposal includes a semantic versioning scheme based on a 3 digit notation (MAJOR.MINOR.PATCH) to indicate major, minor and patch level changes. Moreover, the changes to the Lisk blockchain protocol are expressed using a 2 digit notation (H.S) in order to specify chain and network compatibility, and the nature of the release’s fork (hard of soft).
In this way, delegates and node operators always receive the correct information in order to evaluate the changes made by each new release.
The LIP 8 was set up by Andreas Kendziorra, together with Oliver Beddows and Jan Hackfeld, and it is aimed at removing the hash-then-sign model for block and transaction signatures in the Lisk protocol. In fact, they believe that this system provides more disadvantages than advantages.
In the current hash-then-sign model, data are first hashed and then signed. This system has benefits for some some signature schemes (for example RSA) such as better performance or higher security. On the contrary, these advantages do not occur in the signature scheme used in Lisk, called Ed25519-SHA-512. In fact, as they explain, even the hash-then-paradigm applied to this scheme significantly lowers the level of security, in addition to reducing the performance for certain inputs. For these reasons they suggest not to apply anymore the hash-then-sign model.
In the LIP they show why that system can work well only for some signature schemes and why these improvements do not occur in combination with Ed25519-SHA-512 or can have a negative impact. However, they clarify that none of the problems encountered are critical and that therefore the current protocol is safe and there are no serious performance issues. In any case, they suggest to remove the hash-then-sign model in order to avoid the small drawbacks as regards security and performance, in addition to unnecessary complexity to the protocol.
For more detailed information, you can read the full description of each LIP on the specific page on GitHub.
———————————————-
Lisk Magazine is a project supported by Lisk Italian Group and EliteX.
Support our work, vote for Lisk Magazine.
