[Not for review] Add new TransactionPayload variant for orderless txns #15115
+6,557
−2,759
Conversation
This file contains 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
vusirikala
requested review from
msmouse,
lightmark,
grao1991,
davidiw,
wrwg,
zekun000,
vgao1996,
georgemitenkov,
banool,
gregnazario and
0xmaayan
as code owners
⏱️ 3h 56m total CI duration on this PR
|
vusirikala
requested review from
igor-aptos
and removed request for
davidiw,
gregnazario,
lightmark,
msmouse,
grao1991,
banool,
vgao1996,
wrwg,
0xmaayan,
georgemitenkov and
zekun000
vusirikala
requested review from
bchocho,
sasha8,
gelash and
ibalajiarun
as code owners
vusirikala
force-pushed
the
satya/add_orderless_to_payload
branch
from
972010d to
76eca53
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
❌ Forge suite
|
❌ Forge suite
|
igor-aptos
reviewed
Dec 20, 2024
| TransactionExecutable::Script(_) => { | ||
| GasProfiler::new_script(gas_meter) | ||
| }, | ||
| TransactionExecutable::Empty => { |
There was a problem hiding this comment.
when is Empty used / needed?
| executable, | ||
| extra_config: _, | ||
| }) => { | ||
| // TODO: Should we separate orderless transactions here? |
There was a problem hiding this comment.
I don't think so, they are same transactions. if we wanted a breakdown, other things would make more sense first - like fee payer. but no need here.
| @@ -133,6 +133,7 @@ pub enum FeatureFlag { | |||
| CollectionOwner, | |||
| NativeMemoryOperations, | |||
| EnableLoaderV2, | |||
| OrderlessTransactions, | |||
There was a problem hiding this comment.
is the feature flag for OrderlessTransactions for for TransactionPayload::V2 ?
or do we need two separate feature flags?
| mulitisig.as_transaction_executable(), | ||
| Some(mulitisig.multisig_address), | ||
| ), | ||
| TransactionPayload::V2(TransactionPayloadV2::V1 { |
There was a problem hiding this comment.
we need to gate somewhere , by a feature flag, that V2 payload is discarded until feature flag is enabled. (maybe here?)
Comment on lines
+3149
to
+3150
| // Question: Is this condition correct? | ||
| && txn_data.replay_protector() == ReplayProtector::SequenceNumber(0) |
There was a problem hiding this comment.
yeah , we shouldn't create account for orderless transactions.
| use aptos_types::transaction::{EntryFunction, Script}; | ||
| use aptos_types::transaction::{ | ||
| EntryFunction, Script, TransactionExtraConfig, TransactionPayloadV2, | ||
| }; | ||
|
|
||
| pub struct TransactionBuilder { |
There was a problem hiding this comment.
probably for a separate PR, but thinking about it logically - TransactionBuilder is there to take "executable" and convert it to RawTransaction.
So it should probably be changed to take TransactionExecutable, instead of TransactionPayload, be able to set replay protection (both nonce and sequence number on it), have a multisig address, and then select between v1 and v2 (or make v2 default after flags get enabled)
| @@ -86,13 +86,13 @@ impl OnChainExecutionConfig { | |||
| impl BlockGasLimitType { | |||
| pub fn default_for_genesis() -> Self { | |||
| BlockGasLimitType::ComplexLimitV1 { | |||
| effective_block_gas_limit: 30000, | |||
| effective_block_gas_limit: 5_000_000, | |||
| #[derive(Debug, Copy, Clone, Eq, PartialEq, PartialOrd, Ord, Hash, Serialize, Deserialize)] | ||
| pub enum ReplayProtector { | ||
| Nonce(u64), | ||
| SequenceNumber(u64), |
There was a problem hiding this comment.
I would probably put SequenceNumber first, as we added Nonce later - though that really doesn't matter :)
| ReplayProtector::SequenceNumber(sequence_number) => RawTransaction { | ||
| sender, | ||
| sequence_number, | ||
| payload: TransactionPayload::V2(TransactionPayloadV2::V1 { |
There was a problem hiding this comment.
V2 probably here needs to be gated until V2 format is enabled?
or you have a separate PR to support V2 format and it's processing, and then a later PR (in a later release) to use it throughout
| @@ -422,6 +525,49 @@ pub enum TransactionPayload { | |||
| /// A multisig transaction that allows an owner of a multisig account to execute a pre-approved | |||
| /// transaction as the multisig account. | |||
| Multisig(Multisig), | |||
|
|
|||
| /// Question: Any better name for this variant? | |||
| V2(TransactionPayloadV2), | |||
There was a problem hiding this comment.
thinking about how to use this nicely, maybe we should deprecate payload() function (i.e. remove it / rename to payload_deprecated), and instead provide these functions:
executable() - which for V2 returns executable, for others, extracts Script/EntryFunction, and createsExecutable from it
multisig_address() - which gives it from either V2 or Multisig variant
replay_protector() - which you have
and then from outside , it looks like TransactionPayload doesn't even exist, nobody matches on V2, we can even rename it to TransactionPayloadWrapper or something and have this V2 be named Direct. We don't expect ever to need v2, changes will go to TransactionExecutable/TransactionExtraConfig.
only issue might be how to do that without too much cloning for executable() call - maybe adding some non-serializable field that keeps the wrapper when accessed first, like we do for hash - maybe others have better ideas
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.
Description
How Has This Been Tested?
Key Areas to Review
Type of Change
Which Components or Systems Does This Change Impact?
Checklist