Lisk-sdk: Block transaction limit - removing hardcoded value
I would propose to remove hardcoded limit of 25tx per block in or before 1.0.0. Such limit should be evaluated by each delegate as soft limit chosen by top delegates allowing each delegate to produce blocks of different size. This will introduce auto regulated mechanism, delegates producing harmful blocks will be judged accordingly by community (too big blocks when it cause network problems, too small when transactions are not being confirmed). Hardcoded limit can cause similar issues as we have in Bitcoin. ex - major community split due huge disinformation/manipulation. In my opinion it's better to remove such hardcoded values sooner than later when it may not become possible by reaching point when every situation can be used to profit, like when we have margin trading.
Same goes for dpos consensus / transactions fees already discussed in other issues.
I know it may sound not important enough considering need to develop SDK as soon as possible, but let's learn on Bitcoin mistakes.
karek314
All 3 comments
Yes, it's already planned, but for sure after 1.0.0. release. That release will finally allow us to scale. I think that we still have enough time to do it properly instead of in hurry.
4miners
on 9 Jun 2017
With 1.0.0 as Mariusz pointed out, we plan to remove the 25tx/block limit. We first might just increase it to a higher number. In order to make it fully dependent on block size alone, we need an updated fee system. The size is already hard-coded in with 1 MB.
I agree with you Karek; we need to learn from Bitcoin. I.e. make this into Lisk as soon as possible. Very likely with Lisk 2.0.0 where we will update the fee mechanism. A variable block size would open up many issues in my opinion, e.g. network problems for a subset of nodes. However, I would also like to see a variable block size. However, we would need to find consensus that means every delegate could chose his block size and we take the median or average as the globally currently accepted block size.
In general I'm all for extending DPoS and giving delegates more power over the network, i.e. making the network parameters more variable for the delegates to come to a conclusion.
maxkordek
on 15 Jun 2017
Closing because this will be addressed with https://github.com/LiskHQ/lips/blob/master/proposals/lip-0002.md
shuse2
on 29 Jul 2019
Related issues
slaweet
路
3Comments
ManuGowda
路
3Comments
slaweet
路
3Comments
willclarktech
路
4Comments
hendrikhofstadt
路
4Comments
Most helpful comment
With 1.0.0 as Mariusz pointed out, we plan to remove the 25tx/block limit. We first might just increase it to a higher number. In order to make it fully dependent on block size alone, we need an updated fee system. The size is already hard-coded in with 1 MB.
I agree with you Karek; we need to learn from Bitcoin. I.e. make this into Lisk as soon as possible. Very likely with Lisk 2.0.0 where we will update the fee mechanism. A variable block size would open up many issues in my opinion, e.g. network problems for a subset of nodes. However, I would also like to see a variable block size. However, we would need to find consensus that means every delegate could chose his block size and we take the median or average as the globally currently accepted block size.
In general I'm all for extending DPoS and giving delegates more power over the network, i.e. making the network parameters more variable for the delegates to come to a conclusion.