[AN-Issue-1347] Implemented Automated transaction execution flow #136

aregng · 2024-12-11T13:56:30Z

No description provided.

aptos-move/framework/supra-framework/sources/transaction_validation.move

sjoshisupra

@aregng , it seems that from the issue 1347 I did not see

Chain ID check being done (if it is not done for other tx, we may not do it for automation as well)
Check that there is a corresponding active task for this tx (each automation task would have a unique id provided by registry) and sender seems missing. If we assume however that nodes are honest I wonder if this check is required though.

sjoshisupra · 2024-12-12T09:09:32Z

aptos-move/framework/supra-framework/sources/transaction_validation.move

+        assert!(
+            timestamp::now_seconds() < txn_expiration_time,
+            error::invalid_argument(PROLOGUE_ETRANSACTION_EXPIRED),
+        );


I was under the impression that if an automation task is beyond it's expiry, the SMR layer would never include it in the set of tx to be executed. Is that still correct? Because otherwise it would result in continuous failed assert here in the prologue.

That is true, but as mentioned in my previous comment, I think each layer should validate its input and not rely on the other component correctness. If we do not agree with this approach and here we will always assume that input will not be expired, then this check can be removed.

aregng · 2024-12-12T10:00:14Z

@aregng , it seems that from the issue 1347 I did not see

Chain ID check being done (if it is not done for other tx, we may not do it for automation as well)

Check that there is a corresponding active task for this tx (each automation task would have a unique id provided by registry) and sender seems missing. If we assume however that nodes are honest I wonder if this check is required though.

ChainID, During pervious discussion it was marked as optional, that's why I have not add it and wanted to clarify one more time. The check is done for user-transaction. So I will add it here as well.
Regarding check against registry: As mentioned in the above comment, either we always trust that the input provided by other component can not be incorrect, or each component does some checks on its own as well.
Can you point where sender is missing ?
@aregng I am referring to point 3 in prologue requirement of 1347 (https://github.com/Entropy-Foundation/smr-moonshot/issues/1347), I believe it is not checked in the prologue that task-id indeed belong to the sender.

aptos-move/aptos-gas-schedule/src/gas_schedule/aptos_framework.rs

sjoshisupra · 2024-12-20T13:38:58Z

aptos-move/framework/supra-framework/sources/genesis.move

@@ -188,6 +189,7 @@ module supra_framework::genesis {
        reconfiguration::initialize(&supra_framework_account);
        block::initialize(&supra_framework_account, epoch_interval_microsecs);
        state_storage::initialize(&supra_framework_account);
+        automation_registry::initialize(&supra_framework_account);


I don't think we should call this here. Otherwise replay of the chain would not agree on its state. Since we have launched mainnet, this should not be touched now. automation_registry::initialize can be called via governance script (upgrade framework followed by call to initialize)

The testing will not be easy if we do not have initialize called here. as during testing we start the chain from genesis.
I remember you once mentioned that you want to avoid conditional initialization, but at this moment I do not see easy way to have the module initialized properly with genesis startup.
Featuer enable/disable interface might be investigated to picture and cover all scenarios.

Mentioned in ticket https://github.com/Entropy-Foundation/smr-moonshot/issues/1422 to be addressed later.

sjoshisupra · 2024-12-20T13:40:20Z

aptos-move/framework/supra-framework/sources/stake.spec.move

@@ -437,7 +437,8 @@ spec supra_framework::stake {

    spec on_new_epoch {
        pragma verify = false; // TODO: set because of timeout (property proved).
-        pragma disable_invariants_in_body;
+        // TODO: Why we need to disable invariants in body? (SUPRA)


I think Move prover will fail compilation if we do not have this pragma.

This is not part of my change-set. it comes from this change-set f9652d1

aptos-move/framework/supra-stdlib/sources/enumerable_map.move

sjoshisupra · 2024-12-20T13:52:44Z

aptos-move/framework/supra-stdlib/sources/enumerable_map.move

+    }
+
+    /// Add Multiple Keys in the Enumerable Map
+    public fun add_value_bulk<K: copy+drop, V : store+drop+copy>(


Just like vector::for_each and vector::for_each_ref, it may be helpful if we add enumerable_map::for_each_value and enumerable_map::for_each_value_ref

will be addressed in scope https://github.com/Entropy-Foundation/smr-moonshot/issues/1425 ticket

sjoshisupra · 2024-12-20T13:57:34Z

ecosystem/indexer-grpc/indexer-grpc-fullnode/src/convert.rs

+            let expiration_timestamp_secs = Some(convert_timestamp_secs(std::cmp::min(
+                at.meta.expiration_timestamp_secs.0,
+                chrono::NaiveDateTime::MAX.timestamp() as u64,
+            )));


@aregng I am not sure I quite understand what is happening here. min of MAX time and at.meta.expiration_timestamp_secs.0 would always result in at.meta.expiration_timestamp_secs.0, right? Not sure what is happening here.

My assumption will be that if user specified timestamp exceeds expected MAX of the chrono::NaiveDateTime::MAX.timestamp() it will take the later one. This part might require revision as AutoamtedTransactions will never be posted by users. I need to spend more time to understand APTOS-API and how it is utilized to make sure that these changes were valid or invalid. But at this moment they do not play any role it the main automation-flow implementation.

chrono uses i64 for timestamp and we use u64 so i64::MAX can be potentially less than u64 value specified for expiration time.

aregng · 2024-12-25T10:12:23Z

@aregng , it seems that from the issue 1347 I did not see

Chain ID check being done (if it is not done for other tx, we may not do it for automation as well)

Check that there is a corresponding active task for this tx (each automation task would have a unique id provided by registry) and sender seems missing. If we assume however that nodes are honest I wonder if this check is required though.

ChainID, During pervious discussion it was marked as optional, that's why I have not add it and wanted to clarify one more time. The check is done for user-transaction. So I will add it here as well.

Regarding check against registry: As mentioned in the above comment, either we always trust that the input provided by other component can not be incorrect, or each component does some checks on its own as well.
Can you point where sender is missing ?
@aregng I am referring to point 3 in prologue requirement of 1347 ([Automation: MoveLayer] Automated transaction prologue/epilogue smr-moonshot#1347), I believe it is not checked in the prologue that task-id indeed belong to the sender.

Addressed, sender check is also added.

- Added chain-id verification and task availability check by task index - Added e2e tests for AutoamtedTransaction

* [AN-Issue-1347] Implemented Automated transasction execution flow * Updated automated task prologue and added e2e tests - Added chain-id verification and task availability check by task index - Added e2e tests for AutoamtedTransaction * Fixed test failure * Added task sender check in automated_transaction_prologue --------- Co-authored-by: Aregnaz Harutyunyan <>

aregng requested review from nizam-supraoracles and sjoshisupra December 11, 2024 13:56

aregng mentioned this pull request Dec 11, 2024

[AN-Issue-1346] Implemented custom handling of automation transaction #134

Merged

aregng force-pushed the task/issue-1346 branch from 87dab4b to e1c46bf Compare December 12, 2024 08:39

aregng force-pushed the task/issue-1347 branch from dba982b to 4dad402 Compare December 12, 2024 08:50

nizam-supraoracles reviewed Dec 12, 2024

View reviewed changes

aptos-move/framework/supra-framework/sources/transaction_validation.move Outdated Show resolved Hide resolved

sjoshisupra reviewed Dec 12, 2024

View reviewed changes

aregng force-pushed the task/issue-1346 branch from 69f54b6 to 7a19798 Compare December 17, 2024 08:30

aregng force-pushed the task/issue-1347 branch from 4dad402 to 4a3ce54 Compare December 17, 2024 16:54

aregng marked this pull request as ready for review December 17, 2024 16:55

aregng force-pushed the task/issue-1347 branch from 4a3ce54 to f52e235 Compare December 18, 2024 16:18

aregng changed the base branch from task/issue-1346 to task/registry-update-on-new-epoch December 18, 2024 16:18

aregng force-pushed the task/issue-1347 branch 2 times, most recently from a92b1bd to ace749e Compare December 20, 2024 09:36

aregng force-pushed the task/registry-update-on-new-epoch branch from ab774df to bc106d9 Compare December 20, 2024 12:32

sjoshisupra reviewed Dec 20, 2024

View reviewed changes

aptos-move/aptos-gas-schedule/src/gas_schedule/aptos_framework.rs Outdated Show resolved Hide resolved

sjoshisupra reviewed Dec 20, 2024

View reviewed changes

aptos-move/framework/supra-stdlib/sources/enumerable_map.move Outdated Show resolved Hide resolved

sjoshisupra reviewed Dec 20, 2024

View reviewed changes

aregng force-pushed the task/issue-1347 branch 2 times, most recently from 361e3ba to 3e787dc Compare December 24, 2024 09:39

aregng changed the base branch from task/registry-update-on-new-epoch to feature/automation-networks December 25, 2024 16:08

Aregnaz Harutyunyan added 4 commits December 30, 2024 13:41

[AN-Issue-1347] Implemented Automated transasction execution flow

bc489c0

Updated automated task prologue and added e2e tests

eb0f721

- Added chain-id verification and task availability check by task index - Added e2e tests for AutoamtedTransaction

Fixed test failure

ac06695

Added task sender check in automated_transaction_prologue

bf33fa8

aregng force-pushed the task/issue-1347 branch from 727fe8f to bf33fa8 Compare December 30, 2024 10:22

nizam-supraoracles approved these changes Dec 30, 2024

View reviewed changes

aregng merged commit 70f4027 into feature/automation-networks Dec 30, 2024
1 check failed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[AN-Issue-1347] Implemented Automated transaction execution flow #136

[AN-Issue-1347] Implemented Automated transaction execution flow #136

aregng commented Dec 11, 2024

sjoshisupra left a comment

sjoshisupra Dec 12, 2024

aregng Dec 12, 2024

aregng commented Dec 12, 2024 •

edited by sjoshisupra

Loading

sjoshisupra Dec 20, 2024

aregng Dec 23, 2024 •

edited

Loading

aregng Dec 23, 2024

sjoshisupra Dec 20, 2024

aregng Dec 23, 2024

sjoshisupra Dec 20, 2024

aregng Dec 24, 2024

sjoshisupra Dec 20, 2024

aregng Dec 23, 2024 •

edited

Loading

aregng commented Dec 25, 2024

[AN-Issue-1347] Implemented Automated transaction execution flow #136

[AN-Issue-1347] Implemented Automated transaction execution flow #136

Conversation

aregng commented Dec 11, 2024

sjoshisupra left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aregng commented Dec 12, 2024 • edited by sjoshisupra Loading

Choose a reason for hiding this comment

aregng Dec 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aregng Dec 23, 2024 • edited Loading

Choose a reason for hiding this comment

aregng commented Dec 25, 2024

aregng commented Dec 12, 2024 •

edited by sjoshisupra

Loading

aregng Dec 23, 2024 •

edited

Loading

aregng Dec 23, 2024 •

edited

Loading