[move-example] sample of a dynamic dispatch engine in Move

[davidiw]

Description

This demonstrate a proof of concept dynamci dispatch engine in Move that might be useful for applications like bridges or swaps. For bridges, this allows for a bridge to call into user code without having to do the complicated dance of the application layer knowing the on-chain function to call and ensuring end-to-end correctness and validation. For aggregated swaps, this decouples the need to load all dependencies for all swaps at startup time.

Type of Change

• [ ] New feature
• [ ] Bug fix
• [ ] Breaking change
• [ ] Performance improvement
• [ ] Refactoring
• [ ] Dependency update
• [ ] Documentation update
• [x] Tests

Which Components or Systems Does This Change Impact?

• [ ] Validator Node
• [ ] Full Node (API, Indexer, etc.)
• [ ] Move/Aptos Virtual Machine
• [ ] Aptos Framework
• [ ] Aptos CLI/SDK
• [ ] Developer Infrastructure
• [x] Examples

How Has This Been Tested?

Explicit test cases

Key Areas to Review

Checklist

• [x] I have read and followed the CONTRIBUTING doc
• [x] I have performed a self-review of my own code
• [x] I have commented my code, particularly in hard-to-understand areas
• [x] I identified and added all stakeholders and component owners affected by this change as reviewers
• [x] I tested both happy and unhappy path of the functionality
• [x] I have made corresponding changes to the documentation

[trunk-io[bot]]

⏱️ 16m total CI duration on this PR

Job	Cumulative Duration	Recent Runs
rust-move-tests	9m	🟩
general-lints	3m	🟩
rust-cargo-deny	2m	🟩
check-dynamic-deps	1m	🟩
semgrep/ci	51s	🟩
file_change_determinator	14s	🟩
file_change_determinator	12s	🟩
permission-check	4s	🟩
permission-check	3s	🟩
permission-check	3s	🟩
permission-check	1s	🟩

_{settings ⋅ feedback ⋅ docs ⋅ learn more about trunk.io}

[0x-j]

when we build dispatchable_fungible_asset, why didn't we make it dispatchable_object_transfer instead? i.e. you can register arbitrary function to call when transfer an object

[davidiw]

when we build dispatchable_fungible_asset, why didn't we make it dispatchable_object_transfer instead? i.e. you can register arbitrary function to call when transfer an object

There was a business need for dispatchable_fungible_asset, the hope was that we'd have better tech for object trransfer when it was needed. Also I'm curious what we can accomplish with the proposed intent engine (builder) that might make it superior to dynamic dispatch for certain / many applications.

[0x-j]

when we build dispatchable_fungible_asset, why didn't we make it dispatchable_object_transfer instead? i.e. you can register arbitrary function to call when transfer an object

There was a business need for dispatchable_fungible_asset, the hope was that we'd have better tech for object trransfer when it was needed. Also I'm curious what we can accomplish with the proposed intent engine (builder) that might make it superior to dynamic dispatch for certain / many applications.

Where can i learn more about intent engine? First time hearing it.

[lukema95]

@davidiw I implemented an EIP1271-like feature along these lines #15094

[github-actions[bot]]

This issue is stale because it has been open 45 days with no activity. Remove the stale label, comment or push a commit - otherwise this will be closed in 15 days.

[github-actions[bot]]

This issue is stale because it has been open 45 days with no activity. Remove the stale label, comment or push a commit - otherwise this will be closed in 15 days.

[github-actions[bot]]

Forge is running suite realistic_env_max_load on bfad0ac6f1a03114d874ba842aa196e23867d4eb

• Grafana dashboard (auto-refresh)
• Humio Logs
• Axiom Logs
• Validator CPU Profile
• Fullnode CPU Profile
• Test runner output
• Test run is land-blocking

[github-actions[bot]]

Forge is running suite compat on 82240c9c7137087c575bf5d670abfa0dddc3ae9f ==> bfad0ac6f1a03114d874ba842aa196e23867d4eb

• Grafana dashboard (auto-refresh)
• Humio Logs
• Axiom Logs
• Validator CPU Profile
• Fullnode CPU Profile
• Test runner output
• Test run is land-blocking

[github-actions[bot]]

:white_check_mark: Forge suite realistic_env_max_load success on bfad0ac6f1a03114d874ba842aa196e23867d4eb

two traffics test: inner traffic : committed: 12569.31 txn/s, latency: 3165.37 ms, (p50: 2900 ms, p70: 3100, p90: 4000 ms, p99: 8600 ms), latency samples: 4779100
two traffics test : committed: 99.96 txn/s, latency: 3562.13 ms, (p50: 2800 ms, p70: 3400, p90: 7900 ms, p99: 9400 ms), latency samples: 1760
Latency breakdown for phase 0: ["MempoolToBlockCreation: max: 1.033, avg: 0.511", "ConsensusProposalToOrdered: max: 0.311, avg: 0.305", "ConsensusOrderedToCommit: max: 0.661, avg: 0.463", "ConsensusProposalToCommit: max: 0.969, avg: 0.768"]
Max non-epoch-change gap was: 0 rounds at version 0 (avg 0.00) [limit 4], 1.53s no progress at version 31041 (avg 0.21s) [limit 15].
Max epoch-change gap was: 0 rounds at version 0 (avg 0.00) [limit 4], 1.30s no progress at version 2585212 (avg 1.30s) [limit 16].
Test Ok

• Grafana dashboard
• Humio Logs
• Axiom Logs
• Validator CPU Profile
• Fullnode CPU Profile
• Test runner output
• Test run is land-blocking

[github-actions[bot]]

:white_check_mark: Forge suite compat success on 82240c9c7137087c575bf5d670abfa0dddc3ae9f ==> bfad0ac6f1a03114d874ba842aa196e23867d4eb

Compatibility test results for 82240c9c7137087c575bf5d670abfa0dddc3ae9f ==> bfad0ac6f1a03114d874ba842aa196e23867d4eb (PR)
1. Check liveness of validators at old version: 82240c9c7137087c575bf5d670abfa0dddc3ae9f
compatibility::simple-validator-upgrade::liveness-check : committed: 11075.15 txn/s, latency: 2862.25 ms, (p50: 3000 ms, p70: 3200, p90: 3600 ms, p99: 4500 ms), latency samples: 363020
2. Upgrading first Validator to new version: bfad0ac6f1a03114d874ba842aa196e23867d4eb
compatibility::simple-validator-upgrade::single-validator-upgrading : committed: 2739.71 txn/s, latency: 10656.82 ms, (p50: 11500 ms, p70: 13300, p90: 13800 ms, p99: 13800 ms), latency samples: 61740
compatibility::simple-validator-upgrade::single-validator-upgrade : committed: 2792.87 txn/s, latency: 11871.02 ms, (p50: 13300 ms, p70: 14100, p90: 14200 ms, p99: 14200 ms), latency samples: 104420
3. Upgrading rest of first batch to new version: bfad0ac6f1a03114d874ba842aa196e23867d4eb
compatibility::simple-validator-upgrade::half-validator-upgrading : committed: 2927.43 txn/s, latency: 9952.21 ms, (p50: 10700 ms, p70: 12100, p90: 12900 ms, p99: 12900 ms), latency samples: 65100
compatibility::simple-validator-upgrade::half-validator-upgrade : committed: 2783.26 txn/s, latency: 11904.16 ms, (p50: 13200 ms, p70: 14000, p90: 14400 ms, p99: 14500 ms), latency samples: 104800
4. upgrading second batch to new version: bfad0ac6f1a03114d874ba842aa196e23867d4eb
compatibility::simple-validator-upgrade::rest-validator-upgrading : committed: 5384.44 txn/s, latency: 5648.79 ms, (p50: 6500 ms, p70: 7000, p90: 7300 ms, p99: 7400 ms), latency samples: 105240
compatibility::simple-validator-upgrade::rest-validator-upgrade : committed: 5428.85 txn/s, latency: 6310.95 ms, (p50: 6900 ms, p70: 7200, p90: 7500 ms, p99: 7500 ms), latency samples: 186820
5. check swarm health
Compatibility test for 82240c9c7137087c575bf5d670abfa0dddc3ae9f ==> bfad0ac6f1a03114d874ba842aa196e23867d4eb passed
Test Ok

• Grafana dashboard
• Humio Logs
• Axiom Logs
• Validator CPU Profile
• Fullnode CPU Profile
• Test runner output
• Test run is land-blocking