Lisk Research – Quick Overview of LIP 9

Here is another article about Lisk Research. This time we will deal with LIP 9, which aims at reducing transaction replay on different chains.

The LIP 9 has been formulated by Manu Nelamane Siddalingegowda and Iker Alustiza, together with Oliver Beddows, Andreas Kendziorra and Jan Hackfeld. The proposal contains the introduction of a network identifier, implemented as an organic component of the signature of the transactions, in order to decrease transaction replay on different chains.

The problem of the current system is that transactions can be reproduced on other chains, as has been reported in this issue. Developers explained that, for example, transactions transmitted to Testnet can be repeated on Mainnet. Moreover, the problem is accentuated by the introduction of sidechains in the system.

Currently, the problem is tackled in two ways; 1) dissuading users from setting the same passphrase in different blockchain; 2) suggesting registration of different second passphrases on different blockchains in case the first solution is not applicable. However, this methods are in contrast with one of the advertised strengths of the Lisk platform:  the possibility to reuse passphrases on multiple blockchains, including the mainchain and sidechains.

For the above reasons, developers suggest a network identifier as an integrated component of the signature of a transaction. Specifically, the network identifier consists of three components: a hash of the concatenation of the blockchain’s nethash, a community identifier and a version relating to that community identifier. The combination of this three elements must be exclusive and an imperative requirement for honest actors. In this way, transaction replay attacks from any existing blockchain to Lisk Mainnet or Testnet are avoided and the signature will be valid for the specific network.

Furthermore, in a sidechain-implemented ecosystem, each sidechain will have a unique network identifier to reduce transaction replays across different chains. However, developers explained that in this case a dishonest sidechain developer could copy the unique identifier from Mainnet or from another sidechain and try to replicate a transaction from its own sidechain on that original chain. For this reason, the sidechain user should verify what will be signed in the transaction object, as well as the network identifier.

Due to this situation, developers recommend that, in relation to sidechains, the functions implemented in Lisk Elements must be used, in order to avoid the possibility that a sidechain developer provides a malicious signature function.

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.