Sigma Σ hardfork rules#41
Open
x100111010 wants to merge 57 commits into
Open
Conversation
- monitor sync state and update anything that cares about is_sycned to use the updated rules - sync rate rule: allow mining if sync rate is below threshold and finality point is recent - instantiate Hub in daemon - Reverse the dependency of flow context and MRE - remove the async_is_nearly_synced consensus api - add get_sink_daa_score_timestamp consensus API
- retention bug fix upgrade logic - improved readability - align test with activation triggering (which moves tight parents limit check to in-context validation) - rothschild: add payload size config and fix default spectre testnet ports - set sync rate rule threshold to 0.5 - unit tests for sync rate rule
- for 8 bps our k = 102 - Coinbase Maturity: Originally defined as 100 seconds or ~100 blocks at 1 bps, this will now correspond to 800 blocks at 8 bps - Mergeset Size Limit ( L ): 204 (2k) - Max Block Parents: Increased from 10 to 16 according to `max_block_parents` - induced increase in total rewards is 60 SPR (see tests::calc_high_bps_total_rewards_delta()) - `gen_testnet11_genesis` test expects bps to be 10 and used a constant - Activation of earlier KIPs: KIP-4, KIP-9, KIP-13, KIP-10
dividing subsidy values by 256 (for 16 years) or 65536 (for 32 years) produced fractional results (like 585937.5 and 2288.8) but actual implementation uses div_ceil which rounds up
also added debug prints for finality_depth assertions
- adds a hardfork logic `matrix_activation` which improves randomness in heavy_hash
- adds mempool stats to tps log
With increased blockrate syncing becomes quite slow and due to astrobwt our header verification takes more time to process, to compensate this we reduce the finality duration to 9h and also the pruning duration to around 20.32h. These values satisfy two critical mathematical constraints which are important to maintain the pruning mechanism integrity across the fork boundary: 1. finality_depth.after() % finality_depth.before() == 0 - At 9 hours (32,400 seconds) this is actually exactly 3× the original 24-hour finality period of 86,400 seconds - ensures blocks with the same finality score before the fork maintain the same score after the fork 2. pruning_depth.before().div_ceil(finality_depth.before()) == pruning_depth.after().div_ceil(finality_depth.after()) - This maintains the ratio of 3 between pruning depth and finality depth - For a 9-hour finality, this requires pruning duration to be between 18 and 27 hours or 518400 and 777600 blocks (at 8bps) Our chosen pruning duration of 73,141 seconds (20.32 hours) translates to approximately 585,128 blocks at 8bps. Also make the comment about finality depth (not absolute mathematical finality) simpler and more accurate.
when we set `matrix_activation::ForkActivation::always()` the test won't fail now because it will use the correct header version based on activation status
changed the net_suffix to 8 for our testnet and removed tn11 from wallet core utxo settings and added todo
std lib no longer linking advapi32 by default
Use estimated_blue_depth_at_level_0 instead of fixed depth calculation (required_level_depth + 100) when finding sufficient roots for proof levels. Use exponential scaling that was previously commented out, scaling depth by 2^(level - current_dag_level)
KIP-0013 introduced transient storage mass to prevent excessive storage growth from payload abuse. Without this limit, blocks filled with maximum payloads could consume ~775GB (testnet 11) during pruning periods, making node operation prohibitive for regular users. Since our pruning depth and finality depth are different due to different consensus parameters and a block rate of 8 blocks per second, we adjust the factor to 3. - Block size limit: 125KB (Kaspa with the transient mass factor of 4) -> 167KB (+33% capacity) - Worst-case storage: ~141GB (vs original 775GB threat)
-re-enable lto = "thin" for better release performance (needs to be further tested)
…eaders in pp logging
This reverts commit b035693.
…ore PoW) and use sp_parent for the switch - state::calculate_pow() to select algorithm based on header version - moves header version validation before PoW to prevent unreachable()! - Use selected parent DAA score for header version/pow activation per KIP-14 spec - selected parent DAA score for block version in template builder - error handling to include expected version in WrongBlockVersion
e54476d to
c509612
Compare
disable uninlined_format_args lint
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
target_time_per_blockreduced from 1000ms to 125msL): 204 (2k)max_block_parents: 10 -> 16gen_testnet11_genesistest expects bps=10 (const)bb64053
With increased blockrate syncing becomes quite slow and due to astrobwt our header verification takes more time to process, to compensate this we reduce the finality duration to 9h and also the pruning duration to around 20.32h. (represents social consensus tolerance rather than cryptographic security)
a7f0dbd
The transient storage mass intruced in KIP-0013 prevents excessive storage growth from payload abuse.
Since our pruning depth and finality depth are different due to different consensus parameters, we adjust the factor to 3.
Subsidy calculation has been rethought to preserve our monetary policy with 8x faster blocks. Instead of each block getting a fixed reward amount (which would accelerate emission by 8x), we now treat rewards as per-second values. When blocks come 8x faster, each one gets 1/8th of the original reward. So to calculate the actual block reward, we divide these values by the current BPS rate (1 before activation, 8 after).
tests::calc_high_bps_total_rewards_delta())https://github.com/x100111010/rusty-spectre/blob/sigma_2/consensus/src/processes/coinbase.rs#L78
There's a small 60 SPR supply increase because we use ceiling division.
88638cf which was consolidated into
sigma_activation33ede2aAdds a hardfork logic
matrix_activationwhich improves randomness in heavy_hash (switch to XOR-based bit mixing in heavyhash forheader_version == 2instead of original bit shifting). spectre-miner was already updated to support this algorithm improvement and will automatically detect header version 2, this way we also avoid hardcoding any fixed daa_score or timestamp