I would like to propose adjustment in tokenomics params to reduce impact of gap between real and target block time.
Target time on parachains is 12s.
Those are our avg block times calculated based on onchain data.
Average block time in last 1 day 16.4 s
Average block time in last 1 week 15.7 s
Average block time in last 2 weeks 15.5 s
Average block time in last 1 month 16.1 s
Average block time in last 2 month 15.7 s
As you can see we have long term 30% gap. It impacts all features which base on block number (not timestamp).
For example mining rewards are block based - which directly impact APR of owners and stakers. It is worth noting that in app.phala.network all values you see are also block based.
If you calculate your APR time based you will see it differs for 30%
Worth noting (mentioned by team):
This issue occurs because substrate has limited (obvious) throughput in processing blocks and simultaneously Phala extremely utilize onchain actions.
Compare Moonriver and Khala below (at most it is even 100x more transactions).
Btw. Moonriver is second most used chain ;)
As you can see lot of things happens on Khala and it is probably not possible to improve throughput in short term.
However this proposal is to reduce impact of that issue.
IMO block time in any contract calculations should not be fixed to target 12s value.
I think we should periodically adjust that value to reflect real block time.
Depending how much it will vary we should adjust it monthly based on last month average block time.
I hereby confirm that the Proposal and the Proposal Hash is correct. I've reproduced the same encoded proposal and hash on my own.
0x5d03045705508d976e1283c0aa0000000000000000fd7eb4062f0b000001000000000000000000000000000070080000000000000000000000000000003075000000000000255a8ed66500000000000000000000009d3473f8f34f030000000000000000000000000000000000000000000000000033333333333333330000000000000000140000003b1c318036762473000000000000000000000000000000000000000000000000000000000000008001000000000000000000000000000000320000000000000000000000000000000100000000000000
0x3fb8adf8a43d49fefa480749bfba3a70c12ee707a2c0c7b171a842e5ee6d1b7d
The encoding of this proposal is incorrect. We need to submit the "raw encoded proposal" instead of the polkadot.js prefixed version. Please don't second this proposal!
Details here: https://forum.phala.network/t/topic/3274/12
虽然提案的内容是正确的,但作为公投提案,必须提交call的原始编码,而不是polkadot.js生成的带前缀的编码。请不要second这个提案!
Very reasonable, especially given the block time is not achievable by the Kusama validator throughputs.