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

aregng · 2024-12-03T11:30:32Z

Added separate flow for automation transaction handling. It differes from user transaction flow only by custom validation step of inner-payload of automation transaction
Added validation logic for the automation transaction inner-payload
Introuced specific StatusCode for failures during automation transaction inner-payload validation. They are qualified as verification status type and will lead to have transaction kept and the account will be charged.

types/src/transaction/automation.rs

aptos-move/aptos-vm/src/transaction_metadata.rs

api/src/transactions.rs

aptos-move/aptos-debugger/src/aptos_debugger.rs

aptos-move/aptos-vm/src/aptos_vm.rs

aptos-move/e2e-tests/src/executor.rs

aptos-move/framework/src/natives/transaction_context.rs

consensus/src/transaction_shuffler/fairness/conflict_key/entry_fun.rs

consensus/src/transaction_shuffler/fairness/conflict_key/entry_fun_module.rs

third_party/move/move-core/types/src/vm_status.rs

api/types/src/convert.rs

api/types/src/transaction.rs

aptos-move/aptos-debugger/src/aptos_debugger.rs

sjoshisupra · 2024-12-11T10:05:24Z

aptos-move/aptos-vm/src/verifier/view_function.rs

@@ -56,6 +58,7 @@ pub(crate) fn validate_view_function(
    let allowed_structs = get_allowed_structs(struct_constructors_feature);
    let args = transaction_arg_validation::construct_args(
        session,
+        &mut UnmeteredGasMeter,


View functions are typically not charged any gas on their own (unless called from some entry function). I am hoping the metering would not change that.

previously construct_args where not directly accepting gas-meter as argument, but it was creating UnmeteredGasMeter internally to do the construction. But as long as we wanted to charge for AutomationTransaction embedded payload validation, I have updated the functions to accept gas-meter as input. So here specifying UnbeteredGasMeter does not affect affect original view-function economy and no charges will be applied.

aptos-move/aptos-vm/src/aptos_vm.rs

sjoshisupra · 2024-12-11T10:15:02Z

aptos-move/e2e-tests/src/executor.rs

+                    TransactionPayload::Automation(auto_payload) => GasProfiler::new_function(
+                        gas_meter,
+                        auto_payload.module_id().clone(),
+                        auto_payload.function().to_owned(),
+                        auto_payload.ty_args().to_vec(),
+                    ),


Is this here for gas estimation?

I do not think so. GasProfiler simply records gas-cost for predefined set of operations along with gas-cost calculation based on specified meter, and mainly utilized in aptos-debuger and here in FakeExecutor for e2e tests

aptos-move/e2e-testsuite/src/tests/automation_transaction.rs

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

sjoshisupra · 2024-12-11T10:24:33Z

consensus/src/transaction_shuffler/fairness/conflict_key/entry_fun.rs

+        }
+    }
+}
+
 impl ConflictKey<SignedTransaction> for EntryFunKey {


I am unsure of the role of ConflictKey here for consensus. We can discuss.

my understanding it that it is used by aptos-consensus to order/select the transactions while constructing a block to avoid conflicts as much as possible.
Here is the comment for it in code-base

/// `ConflictKey::extract_from(txn)` extracts a key from a transaction. For example, /// `TxnSenderKey::extract_from(txn)` returns the transaction sender's address. The key is used by /// the shuffler to determine whether two close by transactions conflict with each other. /// /// `ConflictKey::conflict_exempt(&key)` returns if this specific key is exempt from conflict. /// For example, we can exempt transaction sender 0x1, so that consecutive transactions sent by /// 0x1 are not seen as a conflict by the shuffler.

This feature is used to reorder the existing transactions avoiding conflicts as much as possible and then build the block from the ordered set.
This is aptos internal logic and in smr-moonshot we are not using it.

sjoshisupra · 2024-12-11T10:27:45Z

third_party/move/move-core/types/src/vm_status.rs

+    // Verification errors related to automation transaction
+    // Automation Transaction payload validation failed.
+    INVALID_AUTOMATION_PAYLOAD = 1132,
+    INVALID_AUTOMATION_PAYLOAD_ARGUMENTS = 1133,
+    INVALID_AUTOMATION_INNER_PAYLOAD = 1134,


The lines above mentions RESERVED_VERIFICATION_ERROR_X, does it mean that this error codes are also referenced/provisioned somewhere else? In which case these new codes would have to be integrated there as well.

I have checked they are not referenced in any other place.

types/src/transaction/automated_transaction.rs

sjoshisupra

Has the changes to CLI been added or planned to ensure that CLI/client can make this new transaction type?

aregng · 2024-12-11T14:16:46Z

Has the changes to CLI been added or planned to ensure that CLI/client can make this new transaction type?

That should be done in scope of smr-moonshot a new CLI command should be added to create automtion-transaction.

sjoshisupra · 2024-12-13T04:40:14Z

api/types/src/transaction.rs

@@ -328,7 +328,7 @@ impl
            u64,
        ),
    ) -> Self {
-        // If at some point Aptos will utilize Automation transactions then here we will use as
+        // If at some point Aptos will utilize Automated transactions then here we will use as


Suggested change

// If at some point Aptos will utilize Automated transactions then here we will use as

// If at some point Supra will utilize Automated transactions then here we will use as

sjoshisupra · 2024-12-13T04:42:35Z

types/src/transaction/automated_transaction.rs

@@ -1,6 +1,3 @@
-// Copyright (c) Aptos Foundation
-// SPDX-License-Identifier: Apache-2.0
-
 // Copyright (c) 2024 Supra.


Suggested change

// Copyright (c) 2024 Supra.

// Copyright (c) 2024 Supra.

// SPDX-License-Identifier : Apache-2.0

- Added separate flow for automation transaction handling. It differes from user transaction flow only by custom validation step of inner-payload of automation transaction - Added validation logic for the automation transaction inner-payload - Introuced specific StatusCode for failures during automation transaction inner-payload validation. They are qualified as verification status type and will lead to have transaction kept and the account will be charged.

- Introduced a new type PayloadTypeReference which will describe user-transaction payload type and reference payload if required. - Updated TransactionMetadata and UserTransctionContext to utilize PayloadTypeReference enabling easy extension of any new payload type when needed - Updated transaction_arg_validation::validate_combine_signer_and_txn_args to accept GasMeter as input argument. - Updated automation inner payload validation to charge gas for it - Added initial set of e2e tests to check Automation transaction flow.

…ng the required arguments for registration

…m native layer

…#134) * [AN-Issue-1346] Implemented custom handling of automation transactions - Added separate flow for automation transaction handling. It differes from user transaction flow only by custom validation step of inner-payload of automation transaction - Added validation logic for the automation transaction inner-payload - Introuced specific StatusCode for failures during automation transaction inner-payload validation. They are qualified as verification status type and will lead to have transaction kept and the account will be charged. * Updated copyright info * Added language-e2e-testsuite to ci-flow with fixed tests * Addressed review comments and added tests - Introduced a new type PayloadTypeReference which will describe user-transaction payload type and reference payload if required. - Updated TransactionMetadata and UserTransctionContext to utilize PayloadTypeReference enabling easy extension of any new payload type when needed - Updated transaction_arg_validation::validate_combine_signer_and_txn_args to accept GasMeter as input argument. - Updated automation inner payload validation to charge gas for it - Added initial set of e2e tests to check Automation transaction flow. * Fixed test failures after rebase * Fixed copyright comment * Introduce means to create and process automation transaction specifying the required arguments for registration * Addressed review comments * Renamed 'automation transaction' to 'automation registration' * Updated automation::registry to be non-entry and made direct call from native layer * Cosmetic chagnes * Copyright fix * Temporarly fixed test failure * Split and reordered test runs in ci * Increased nextest timeout from 2100 to 3000 --------- Co-authored-by: Aregnaz Harutyunyan <>

aregng requested review from nizam-supraoracles and sjoshisupra December 3, 2024 11:30

aregng force-pushed the task/issue-1346 branch from f3cea7a to 6bc98a0 Compare December 3, 2024 11:34

aregng commented Dec 4, 2024

View reviewed changes

types/src/transaction/automation.rs Outdated Show resolved Hide resolved

aregng commented Dec 4, 2024

View reviewed changes

aptos-move/aptos-vm/src/transaction_metadata.rs Outdated Show resolved Hide resolved

aregng force-pushed the task/issue-1346 branch from 6bc98a0 to 61a72a2 Compare December 4, 2024 08:42

sjoshisupra requested changes Dec 5, 2024

View reviewed changes

aregng force-pushed the task/issue-1346 branch from 61a72a2 to 71c43e9 Compare December 6, 2024 10:03

aregng changed the base branch from task/issue-1337 to supra_automation_registry December 6, 2024 10:05

nizam-supraoracles force-pushed the supra_automation_registry branch from 26bc075 to 2392127 Compare December 6, 2024 11:40

aregng force-pushed the task/issue-1346 branch 2 times, most recently from 40bbb05 to 7c1f122 Compare December 9, 2024 09:34

nizam-supraoracles force-pushed the supra_automation_registry branch from 2392127 to d737095 Compare December 9, 2024 09:39

aregng force-pushed the task/issue-1346 branch 3 times, most recently from c63bb23 to 87dab4b Compare December 10, 2024 13:46