There are several protocol parameters that have an effect on CPU, RAM, hard disk storage, and bandwidth. For the benefit of decentralization, for example through self-hosting and satellite internet, we should optimize the parameters for a balance between efficiency and performance.
Which parameters are there? Here are the current ones and their values used in Housefire, copied from Shielded Live. Housefire is a test network with a very short epoch time period, which is nice for quick feedback, but grows the chain crazy fast.
| Protocol parameters |
Value |
Affects efficiency? |
| Minimum epoch duration: |
300 |
|
| Minimum number of blocks in epoch: |
4 |
|
| Epochs per year: |
105120 |
|
| Maximum gas for block: |
20000000 |
|
| Gas scale: |
100000000 |
|
| Max transaction bytes: |
1048576 |
|
| MASP epoch multiplier: |
2 |
|
| Max proposal bytes: |
6291456 |
|
| Proof of Stake parameters |
Value |
Affects efficiency? |
| Pipeline length: |
2 |
|
| Unbonding length: |
3 |
|
| Cubic slashing window length: |
1 |
|
| Max validator slots: |
20 |
|
| Validator stake threshold: |
1 |
|
| Duplicate vote min slash rate: |
0.001 |
|
| Light client attack min slash rate: |
0.001 |
|
| Liveness window check: |
1000 |
|
| Liveness threshold: |
0.1 |
|
| Block proposer reward: |
0.125 |
|
| Block vote reward: |
0.1 |
|
| Max inflation rate: |
0.1 |
|
| Target staked ratio: |
0.4 |
|
| Inflation kP gain: |
0.25 |
|
| Inflation kD gain: |
0.25 |
|
| Votes per raw token: |
1 |
|
| Governance parameters |
Value |
Affects Efficiency? |
| Min proposal fund: |
2000 |
|
| Max proposal code size: |
600000 |
|
| Min proposal voting period: |
2 |
|
| Max proposal period: |
27 |
|
| Max proposal content size: |
10000 |
|
| Min proposal grace epochs: |
2 |
|
| Public Goods Funding parameters |
Value |
Affects efficiency? |
| PGF inflation rate: |
0.1 |
|
| Stewards inflation rate: |
0.01 |
|
-
Which of those parameters affect resource consumption and can be lowered to a more reasonable level, while keeping the chain functional and snappy enough?
-
Are there risks of lowering specific values too much? For example, when lowering Max gas for block below the minimum needed for a transaction, the chain would practically break.
3 Likes
Epochs time is 5 minute ?
i would like to know a unstake period
Yes, for Housefire the epoch duration is set to 5 minutes to allow rapid testing. Of course that is not sustainable for mainnet. The question is, how long do we want mainnet epochs to be? How many blocks do we want to generate every day? What should be the maximum size of the blocks?
I am kind of surprised at the lack of responses. The Bitcoin Blocksize War was one of the hottest topics between 2015 and 2017.
Big Blockers wanted to modify the original Bitcoin protocol to increase block capacity and process more transactions. They believed that cheaper, faster transactions would make Bitcoin more scalable and therefore more accessible. While increasing the block size may not be a permanent solution, some suggested it would help keep transactions cheap in the short-term and allow more time for scaling solutions to potentially develop. This would allow Bitcoin to compete on the global stage as an alternative payment system to companies like Visa or PayPal.
Small Blockers fought to keep the 1 MB size limit in place to prioritize Bitcoin’s fundamental principles of security and decentralization. Small Blockers believed that if the block size increased, it would become too expensive for individual users to run a Bitcoin node. This would lead to companies hosting nodes in data centers, which could compromise decentralization of the network. They believed in system resilience and taking a long-term approach to increasing Bitcoin’s market share.
And that was just one parameter.
i would like to know a unstake period
That has no effect on performance I think. The other parameter topic is more suitable for that question. Mainnet parameter discussions: Knowable's proposal
In the Genesis templates folder:
epochs_per_year = 31_536_000
min_num_of_blocks = 4
There are 31,536,000 seconds in a year. With that configuration, unbonding would take just 3 seconds.
Meanwhile for the Shielded Expedition:
epochs_per_year = 730
min_num_of_blocks = 3600
max_expected_time_per_block = 20
As you can see, there is quite a bit of leeway between those parameters sets.
I’d just like to point out that the config in the Genesis templates folder of the namada repo are specifically used for our testing environment. These values are not meant to suggest what is realistic for a mainnet config.
A good starting point for discussion on realistic parameter values is in this doc from Knowable: draft proposal for Namada mainnet parameter discussions - Google Docs