propose system transactions #10971

zjma · 2023-11-18T03:19:12Z

Description

This PR introduces a new feature ProposeSystemTransactions: when enabled, validator should do the following:

When proposing a block, use variant ProposalExt and include SystemTransactions from a list of SystemTransactionProviders it was given.
- The proposal will be filled by in the following order: system_txn_provider[0] > ... > system_txn_provider[-1] > payload.
- System transactions and user transactions will share txn_count_limit and block_size_limit.
When verifying a proposal, ensure it is of variant ProposalExt.

TODOs

Add system transactions into DAG node.

consensus/consensus-types/src/block_data.rs

consensus/src/liveness/proposal_generator.rs

consensus/src/round_manager.rs

grao1991 · 2023-11-18T04:35:26Z

consensus/src/round_manager.rs

+            );
+        }
+
+        let (num_sys_txns, sys_txns_total_bytes) = {


nit:

proposal.sys_txns().map_or(...)

and for the closure you can use reduce.

address the comment?

fixed. i thought nit is fine xD

grao1991 · 2023-11-18T04:37:25Z

consensus/src/round_manager_test.rs

@@ -261,6 +261,8 @@ impl NodeSetup {
            PipelineBackpressureConfig::new_no_backoff(),
            ChainHealthBackoffConfig::new_no_backoff(),
            false,
+            vec![],


should have some test coverage when it's enabled?

sure. how do we want to do it: forking every test here with sys_txn_enabled = true?

prop test?

testing everything with true is probably also ok.

@grao1991 how to run prop tests? any example?

https://sourcegraph.com/github.com/aptos-labs/aptos-core@a676c1494e246c31c5e96d3363d99e2422e30f49/-/blob/storage/aptosdb/src/db_debugger/truncate/mod.rs?L248

grao1991 · 2023-11-18T05:19:50Z

consensus/src/epoch_manager.rs

@@ -132,6 +133,7 @@ pub struct EpochManager<P: OnChainConfigProvider> {
    commit_state_computer: Arc<dyn StateComputer>,
    storage: Arc<dyn PersistentLivenessStorage>,
    safety_rules_manager: SafetyRulesManager,
+    sys_txn_providers: Vec<Arc<dyn SysTxnProvider>>,


you probably don't need shared ownership here?

I'm not sure. But something might be easier if it's shared ownership.
E.g., at the beginning of every epoch, we need to send a clone of this vec from epoch manager to the newly created proposal manager.

I think you can either send a &, or just let proposal manager owns it?

epochmgr and roundmgr (owner of proposal manager) each has their own thread, I don't know how to send a & here... maybe you can suggest a sub-PR :)

move it into roundmgr (then proposal manager) is possible, but then epochmgr needs to take it back before shutting down roundmgr... doesn't sound simpler than cloning Arcs?

Arc is what we've been doing unless we can figure out how to convince compiler the lifetime of round manager is shorter than epoch manager

grao1991 · 2023-11-18T05:30:30Z

aptos-move/aptos-release-builder/src/components/feature_flags.rs

@@ -93,6 +93,7 @@ pub enum FeatureFlag {
    VMBinaryFormatV7,
    ResourceGroupsChargeAsSizeSum,
    CommissionChangeDelegationPool,
+    ProposeSystemTransactions,


Is it better to put in OnChainConsensusConfig instead? @zekun000

FeatureFlag makes more sense to me. It is not consensus specific feature.

tbh this is more like a consensus feature whether to propose system txn

No strong opinions

zekun000 · 2023-11-24T19:49:42Z

consensus/src/round_manager.rs

@@ -633,10 +634,27 @@ impl RoundManager {
            .author()
            .expect("Proposal should be verified having an author");

+        if !self.onchain_config.should_propose_system_txns()


we should add unit test for the new behavior

…ctions

github-actions · 2023-11-24T23:14:29Z

✅ Forge suite `compat` success on `aptos-node-v1.7.3` ==> `fcfd1d395bc0a0b0b36773f933cde09da0ad943b`

Compatibility test results for aptos-node-v1.7.3 ==> fcfd1d395bc0a0b0b36773f933cde09da0ad943b (PR)
1. Check liveness of validators at old version: aptos-node-v1.7.3
compatibility::simple-validator-upgrade::liveness-check : committed: 3121 txn/s, latency: 6693 ms, (p50: 6900 ms, p90: 10200 ms, p99: 10500 ms), latency samples: 190420
2. Upgrading first Validator to new version: fcfd1d395bc0a0b0b36773f933cde09da0ad943b
compatibility::simple-validator-upgrade::single-validator-upgrade : committed: 1850 txn/s, latency: 15622 ms, (p50: 19200 ms, p90: 22000 ms, p99: 22500 ms), latency samples: 92540
3. Upgrading rest of first batch to new version: fcfd1d395bc0a0b0b36773f933cde09da0ad943b
compatibility::simple-validator-upgrade::half-validator-upgrade : committed: 1617 txn/s, latency: 17559 ms, (p50: 19800 ms, p90: 26800 ms, p99: 27900 ms), latency samples: 77660
4. upgrading second batch to new version: fcfd1d395bc0a0b0b36773f933cde09da0ad943b
compatibility::simple-validator-upgrade::rest-validator-upgrade : committed: 3296 txn/s, latency: 9466 ms, (p50: 9900 ms, p90: 12500 ms, p99: 16400 ms), latency samples: 128580
5. check swarm health
Compatibility test for aptos-node-v1.7.3 ==> fcfd1d395bc0a0b0b36773f933cde09da0ad943b passed
Test Ok

github-actions · 2023-11-24T23:15:44Z

✅ Forge suite `realistic_env_max_load` success on `fcfd1d395bc0a0b0b36773f933cde09da0ad943b`

two traffics test: inner traffic : committed: 7404 txn/s, latency: 5284 ms, (p50: 5100 ms, p90: 6600 ms, p99: 10500 ms), latency samples: 3213600
two traffics test : committed: 100 txn/s, latency: 2332 ms, (p50: 2300 ms, p90: 2700 ms, p99: 3200 ms), latency samples: 1900
Latency breakdown for phase 0: ["QsBatchToPos: max: 0.204, avg: 0.196", "QsPosToProposal: max: 0.188, avg: 0.173", "ConsensusProposalToOrdered: max: 0.684, avg: 0.633", "ConsensusOrderedToCommit: max: 0.554, avg: 0.530", "ConsensusProposalToCommit: max: 1.237, avg: 1.162"]
Max round gap was 1 [limit 4] at version 1538509. Max no progress secs was 4.191058 [limit 10] at version 1538509.
Test Ok

github-actions · 2023-11-24T23:28:11Z

✅ Forge suite `framework_upgrade` success on `aptos-node-v1.7.3` ==> `fcfd1d395bc0a0b0b36773f933cde09da0ad943b`

Compatibility test results for aptos-node-v1.7.3 ==> fcfd1d395bc0a0b0b36773f933cde09da0ad943b (PR)
Upgrade the nodes to version: fcfd1d395bc0a0b0b36773f933cde09da0ad943b
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 7019 txn/s, latency: 4800 ms, (p50: 4800 ms, p90: 7700 ms, p99: 8300 ms), latency samples: 245680
5. check swarm health
Compatibility test for aptos-node-v1.7.3 ==> fcfd1d395bc0a0b0b36773f933cde09da0ad943b passed
Test Ok

* propose system transaction, initial * update feature name * fmt * update * update * format update * updapte * fmt * filter out pending sys txns * UTs; resolve comments * comments * sys txn pool * update * feature flag -> consensus config * remove feature flag * nitfix * dummytopic as test-only * bugfix * update existing tests * uts for receiving limits

zjma added 3 commits November 17, 2023 19:18

propose system transaction, initial

bd197fc

update feature name

f6ae666

fmt

4f02a72

zjma added the CICD:run-e2e-tests when this label is present github actions will run all land-blocking e2e tests from the PR label Nov 18, 2023