Lisk Research – Quick Overview of LIP 10
The dissemination of Lisk Research and LIPs continues on Lisk Magazine. In this article we present a quick overview of the LIP 10, which proposes a new type of blockID for the blocks, in order to enhance the security of the Lisk blockchain.
The LIP 10 has been drawn up by Andreas Kendziorra (with the support of Oliver Beddows) and it suggests to use the SHA3-256 hash of the block header as the blockID of a block, improving the security.
Developers explained that currently, in the Lisk protocol, a blockID consists of 8 bytes of the SHA-256 digest of the block header. This length, that they call “small”, has some advantages (less stored data and better visualisation on small displays), but also drawbacks, such as low resistance to attacks. For example, an attacker could discover another block with the same blockID for a given block in the blockchain. In this case, the corrupt chain might appear to be unaltered to other community members. However, developers specify that this type of attack is limited to delegates and, at the moment, is not attractive in economic terms. Anyway, they suggest to increase the length of the blockID with the purpose of preventing this type of attach in the future.
Let’s compare the two protocols more in detail. In the present Lisk protocol the data block is used as the input text for SHA-256 and then the first 8 bytes of the output are reversed and used as the blockID. In the suggested protocol the data block of the header of the signed block is generated according to the specification (the same as the current protocol). Subsequently, the data block is used as the input for SHA3-256 and its output becomes the blockID, with a length of 256 bit.
In relation to the length of the blockID, they suggest 256 bit because it ensures a high security level, even above the recommendations. In fact, they explained that NIST is suggesting 128 bit as the minimum security level for applications designed to run over 2030 (as you can see in this publication). The suggested length will increase the size of the blockchain by ~50 Mb (~100 Mb if blockIDs are written in hexadecimal representation in the character arrays), a negligible value in comparison to the total size of the chain. Moreover, since blockIDs are managed by users only occasionally, the additional length does not bring any significant disadvantage to users.
Developers also explained that they have chosen the hash function family SHA-3, in particular the KECCAK function, because it was the winner of the public NIST hash function competition, thanks to its security, performance and flexibility aspects. Among the alternative functions they indicate the current SHA-256 and the BLAKE2. However they prefer the KECCAK because SHA-256 has weaknesses due to its construction (as mentioned above) and the latter did not go through the whole SHA-3 review process.
If you want to know more about the topic, 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.
