How much time for a full Delegate Round?

Consensus
1

I was reading the whitepaper of Lisk and comparing some information from lisk.io. After reading it I decided to create this topic. For example on lisk.io, it’s described that takes 10 seconds to generate a block with transactions, while on whitepaper its described that takes overall 16 minutes to generate 101 blocks, the same quantity of delegates. My question is:
If a block can be created in 10 seconds knowing that only delegates nodes can create blocks, transactions are picked up from transaction pool by each delegate, each delegate picks differents transactions from transaction pool and its necessary at least 5 rounds to confirm the transactions inside of blocks. So, it seems from the whitepaper that 1 delegate creates a block in ten seconds and send it to the network to be validated. After it, another delegate creates another block in another 10 seconds and so on, timeslots of creation and the full round would take around 16 minutes. My question is it possible to allow delegates generates blocks in parallel and let a time slot for the blocks been validated and ordered based on timestamp, ids? The broadhash consensus would guarantee the safety property.

2

Hi David,

this is a non-official reply from a stranger from the internet.

  1. It does not “take 10 seconds” to create a block in the sense that block creation is hard. In Lisk, a block is created in fractions of a second. But there is a simple constant in the protocol that says, every 10 seconds a new block should be generated. This number could be anything else, but 10 seconds seems to be a nice tradeof to ensure (a) every delegate has enough time to recive block number n before generating block number n+1 and (b) produce blocks quickly enough to make a smooth system. However, it would be a valid debate to question the choice of 10 seconds. Other DPoS ecosystems choose other values for their own reasons.
  2. The transaction pool is decentralized as well, i.e. every node has their own transaction pool. There is no guarantee a new transaction is seen my all delegates immediately. So the entire idea that multiple delegates pick from that pool at the same time is problematic as their individual versions of that pool are not perfectly synced.
  3. In all major general purpose blockchain ecosystems, block number n must be known before being able to create block number n+1. In fact, a hash of the previous block is an ingrediant of the block. This ensures that no merging of transaction execution is necessary. Imagine two blocks are created in parallel and Alice who own 5 LSK sends 3 LSK to Bob in the one block and 3 LSK to Carl in the other block. This situation is very hard to resolve, if at all possible. However, the idea of transaction merging and parallel block creation exists for very specific use cases like casting of votes (see section “Merging” in http://www.liquid-democracy-journal.org/issue/6/The_Liquid_Democracy_Journal-Issue006-04-The_LiquidFeedback_Blockchain.html).

I hope this gives you a little bit of context. Stay hungry!

Cheers, Simon

3

Hi, thanks for your answer Simon_Warta. 10 seconds is a good debate, in fact, it was one of the reasons for the creation of this topic. Also, I already thought about why exists 101 delegates, why not less delegates like 51?

Regarding point 2 and point 3 I didn’t talk about allow transactions been picked without any rule of exclusivity from blocks and I am not talking about a critical region. The situation, actually, is that generated blocks have the previous block info on it but I was thinking what would happen if they do not have it immediately? What about in a possibility to think in a time slot that allows sort of the generated blocks in parallel based on timestamps and ids, then verify each transaction inside of them to guarantee exclusivity and then include the previous block info on each generated block? The validation of these new blocks by the delegates would continue to respect the broadhash consensus. I didn’t say that would be easy.

4

Hi @davinet,

thanks for your interest in Lisk. Note that Lisk Chat is a better place to ask such technical
questions. The purpose of this forum is the discussion of well-founded improvements of the Lisk protocol (see the forum guidelines).

Note that “generating blocks in parallel”, as you propose, leads to quite a few complications, which @Simon_Warta already pointed out. However, the are different technologies that go into this direction such as Sharding or having an acyclic graph (Tangle, Hashgraph) instead of a blockchain.

Cheers,
Jan

5