Block size / count of transactions included shall be determined by delegate node operator and should be soft limit and not consensus breaking. Delegate has incentive not to produce overweight blocks, slightly overweight blocks can force other delegates running with cheap nodes to upgrade them (they could start loosing blocks on weaker machines)
Hey thepool, thanks for your message.
Although theoretically very interesting, I think the idea of a soft cap for block size can be problematic in practice. Also I am not aware of any blockchain project with such a feature, and most of them implement a maximum block size in the protocol.
The most worrying issue I can think of now is the instability in the network this feature may introduce: Assume a very busy network in the future (hundred of users issuing thousand of transactions in a sort window of time). On one hand, the incentive of any delegate would be to include as many transactions as possible in its block for greater profit. On the other hand, the delegate has to be careful not to generate a block too big to be properly broadcast around the whole network. However, the solution of this optimisation problem (trade off between profit and broadcast feasibility) is very complex and depends on the current situation of the network, delegate’s connectivity, peers connectivity, etc. This suggests that having this soft cap on the block size will cause a fork prone network and a significative decrease in the performance.
If you have a potential idea on how to solve this issue, please share it here. Also, it would be great if you can give more details about the general proposal.
Best, Iker
Hi Iker,
As far I remember Ethereum does not have it as hardcoded value, at least it didn’t had when I was familiar with codebase. Bitcoin Cash seems not to have it either. I’d find couple more examples.
Agreed, but I think forging delegate would chose it to maintain reasonable balance, nevertheless at this moment I think Lisk does split rewards from fees equally among all delegates at the end of the round.
It really depends on delegates, I really doubt forging delegate would create insanely huge blocks, after all, they would be getting beaten by voters because of it.
More details about proposal - simply putting const in config, allowing to override current limit. Having this as soft cap, will solve potential problems like these from Bitcoin. Satoshi Nakamoto, initially introduced capped block size only because of spam attacks caused by low value of Bitcoin, it was meant to be removed and/or dynamic soft cap.
Hi tepool,
AFAIK Ethereum has a limit in terms of Gas (~ 1,500,000 Gas) per block. But at the end of the day, this implies a maximum number of transactions per block and therefore a limit in the size.
I am not following this one at all, but did not they set it to 8MB after the fork? I read that they are researching with massive block sizes but I doubt they have no block size limit without any restriction.
If we assume that the Dynamic Fees LIP is accepted and gets implemented then rewards and fees are assigned to the forger of the block and nothing is shared at the end of the round. You can find the rationale behind this change in that proposal.
This is one of the points I find more concerning. As you said, it does not look likely that delegates would behave like this, but there is no theoretical (nor practical) certainty of this. A proper research of incentives would be needed to assess this question, to avoid falling into quick conclusions or personal feelings.
The other point is that, even in the case of the previous research being positive and it is proven that delegates have no clear incentive to create insanely huge blocks, the protocol would still allow this possibility (there would not be size limit or direct punishment for delegates). Therefore this case should be addressed, researched and simulated. Also, this implies a thorough testing and benchmarking of network stability/performance vs size of a new forged block. Something in terms of what the company nchain is trying to do with Bitcoin SV.
That is why my feeling is that this proposal, even with an extensive research of implications can be dangerous, specially given the maturity of the Lisk blockchain. However I totally foresee that this can be one of the parameters to tune in the future when there is a proper on-chain governance given by the protocol.
Iker
Hi,
I understand your arguments and agree mostly, however I consider implications of having this as static hard coded, consensus breaking value to be worse. If not unlimited by consensus, I propose then BitPay solution proposed for Bitcoin.
Hi thepool,
Thanks for the link, I was not aware about this proposal for Bitcoin by BitPay. It looks definitely interesting but somehow I find it incomplete or not thorough enough. In particular, the point where they state that “this proposal DOES NOT propose a blended cost metric for transactions and blocks used for miner transaction selection”. Basically, a solution like this would imply also a re-design of the fee system, adapted for the special case of the different transaction types in Lisk. Our current Dynamic Fee System proposal is based on the assumption of a maximum fixed block size, and as it is mentioned in this BitPay’s solution, this would need to be adjusted accordingly too.
In any case, I see that a solution for the block size like this could definitely improve the Lisk protocol once it has reached a maturity level in which the usage demands scaling solutions in this direction. However, Lisk’s main use case is different from Bitcoin’s one and most of the transfer of value and users interactions will be done off the mainchain (i.e., on the sidechains). That is why I believe a solution in this direction is not a priority, as long as the protocol has not achieved a proper level of maturity with a certain real-world usage.
Having said that, I encourage you (or any other member in the community) to submit a completed proposal for Lisk on this matter.
Iker