Disscussion on BlockGeneration consensus change request.

[trustfarm-dev]

Klaytn [Forum Topic #790]((https://forum.klaytn.com/t/topic/790)

제가 제안하는 스펙은 (KIP) 클레이 개선 제안.

1초 (블록타임) 안에 TX가 한개라도 있으면 블록을 생성한다.
만약 없으면, deadline 을 30초로 하고 이게 (default blocktime) 으로 하고,
그 안에 1개의 TX라도 있으면 블록을 생성한다.
30초가 0개의 TX라면 그냥 블록을 생성한다.
이렇게 하면 동기화 시간이 빨라질것 같아요.
블록 오버헤드가 없어서요.
또한, 노드도 불필요한 로드가 발생하지 않아서, 안정적으로 운영이 될거 같아요.

PullRequest on this issue is PR55.
Please review and discuss on this core consensus changes.

In the view of technical, network stability, and Validator Economic model.

Especially, It will give a motivation on transaction mining to Validator.
Validator will promote ECO for get more transaction fees and Block Rewards.

I call it TX Mining. To Validators Do action , Get more.
No action, Little Staking Rewards.

It means this KIP , or Alternated KIP will drive validator more active.

[kjhman21]

@trustfarm-dev
Thanks for the proposal! First of all, this is the first proposal from outside of Klaytn core developers!

However, we have to discuss the benefit of this proposal.

1. Recent blocks on Cypress have at least 1 transaction. If we applied this proposal early days, it could be helpful. It seems that it could not be that helpful these days.
2. Already generated blocks cannot be removed or reorganized due to the chain of hashes of the blocks.
3. How can we distinguish: the block proposer is malfunctioning and there is no TX?
4. How can we guarantee that the design of the protocol is sound?
5. Do you have the full implementation of the consensus protocol so that we can figure out the feasibility of the consensus protocol?

[trustfarm-dev]

@kjhman21
Answers

1. I also found many recent blocks has at least 1Tx. So, it is considered with validator economy models latest updates on KIP55.

   • it is alternative version of KIP55 , also considering. it will describe more condition at least 3Tx, 4Tx blah blah..
   • go and testing then another issues are come out, and then modify model, it is developing and progressing.

2. core consensus change means no revert old things, changes to future. it is blockchain.

   • if you consider fast syncing old blocks, then study eth fast or warp sync, snapshot sync model, I can suggest.

3. need to debug, when proposal has approved and start to implementation. so, many QA process will figure out.

4. it depends on you. this KIP is draft, there's many things will be modified , improved. base on this deadline idea.

5. I'm not a inhouse person, so I don't have full implementation to Klaytn, but, Psedo Code which described in KIP,
   middle level of engineer does coding for feasibility of new consensus.
   It also depends on your side.

I think more important things are validator economy model , not technical implementation, as you also developer, you experienced many development change little or more things than what started plan.

[KimKyungup]

@trustfarm-dev
Thanks for your suggestion.

As I understood, you suggested this idea to resolve the time for syncing Cypress.
In shorterm, syncing time of 30 second block time chain is faster than 1 second block time chain.
However, In longterm, both ways takes O(N) time to sync N blocks.

So we need to consider other approach is not related with N block count.
In geth, there is a fast sync to download the latest state trie. It takes O(M), M is the number of state trie node.

Also, recent geth released snap sync that just downloads all useful state data (leaf trie nodes) and reconstructs the Merkle trie locally. It can decreased the download time to O(K) from O(M), K is the number of leaf trie node, K << M.
Of course, it takes the time to reconstruct the merkle trie. But it is faster than download all parent trie nodes.

Therefore, I expect fast sync and snap sync approaches can reduce syncing time dramatically.
If possible, I will implement the features soon.

[aidan-kwon]

@trustfarm-dev I think this approach is more suitable for Service Chain or Baobab Network than MainNet. In a private network, there may be no transaction for a while if its service time is limited. In that case, this approach could save storage wasted by the empty block.

However, it is hard to apply the idea to the network using Istanbul Consensus with weight-random proposer selection (used in Cypress Network). As @kjhman21 remarked, CNs should have the ability to distinguish whether the block generation halt is originated from "Malfunction of the proposer" or "No transactions". It means that the consensus algorithm also should be revised to support your idea. Indeed, we should consider token economy also. In the CN's perspective, generating a block with a garbage transaction created by the node is more profitable than halting block generation because the mining reward is greater than the transaction fee. We should handle the problem also.

Fortunately, your idea is suitable for other consensus mechanisms that don't support fault-tolerance for the block proposer or have the proposer change timeout logger than "default blocktime" you suggested. For those mechanisms, your approach can be applied without the change of the consensus algorithm.

I would be grateful if you can develop your idea considering my comments. Thank you!