Add a transaction context function to get the raw transaction hash #13659

junkil-park · 2024-06-12T15:24:06Z

Description

This commit adds a transaction context function to get the raw transaction hash.

This resolves #14774.

Type of Change

Which Components or Systems Does This Change Impact?

How Has This Been Tested?

unit test and e2e test

Key Areas to Review

Checklist

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

trunk-io · 2024-06-12T15:24:09Z

⏱️ 9m total CI duration on this PR

Job	Cumulative Duration	Recent Runs
rust-move-tests	9m	🟩

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

codecov · 2024-06-12T15:42:05Z

Codecov Report

Attention: Patch coverage is 19.35484% with 50 lines in your changes missing coverage. Please review.

Project coverage is 60.0%. Comparing base (cbb422d) to head (4f7ef2b).

Files with missing lines	Patch %	Lines
aptos-move/aptos-vm/src/transaction_metadata.rs	0.0%	25 Missing ⚠️
...-move/framework/src/natives/transaction_context.rs	42.8%	16 Missing ⚠️
types/src/transaction/user_transaction_context.rs	0.0%	5 Missing ⚠️
aptos-move/aptos-vm/src/move_vm_ext/session/mod.rs	0.0%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##             main   #13659     +/-   ##
=========================================
- Coverage    60.1%    60.0%   -0.1%     
=========================================
  Files         856      856             
  Lines      210640   210692     +52     
=========================================
- Hits       126615   126578     -37     
- Misses      84025    84114     +89

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

movekevin · 2024-06-12T16:38:18Z

aptos-move/framework/aptos-framework/sources/transaction_context.move

@@ -182,6 +182,12 @@ module aptos_framework::transaction_context {
        payload.entry_function_payload
    }

+    /// Returns the hash of the current raw transaction.


Can we add documentation to explain the difference between this one and the other ones. May be say the other ones shouldn't be used?

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

github-actions · 2024-07-28T01:56:47Z

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 · 2024-09-12T01:58:27Z

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.

lightmark · 2024-09-18T18:20:58Z

any updates?

junkil-park · 2024-09-18T19:31:23Z

any updates?

I will add tests and more documentation this week.

lightmark

Let's ship it

lightmark · 2024-09-27T17:15:14Z

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

+                    let raw_txn = RawTransactionWithData::new_fee_payer(
+                        txn.clone().into_raw_transaction(),
+                        secondary_signer_addresses.clone(),
+                        *fee_payer_address,


Let's make this ZERO instead...
We don't want to have two possible valid hash here.
cc @davidiw

We could make the function return a vector of hash values to return both: [hash_for_0x0_fee_payer, hash_for_actual_fee_payer].

what if it is not a fee payer txn? which two hashes would you return?
Also, I think users will be super confused.

what if it is not a fee payer txn? which two hashes would you return?
Also, I think users will be super confused.

If it's not a fee-payer transaction, we could return a singleton vector with the hash of the raw transaction [hash_value].

So it can be either 1 or 2?
Don't you think it is too confusing?

So it can be either 1 or 2?

Yes, 2 return values for fee-payer transactions and 1 return value for other types of transactions.

Don't you think it is too confusing?

I think the more important question is whether it's necessary. The current authentication process utilizes both hash values with the actual fee payer and without it. Would there be any scenario where an AA user needs both hash values?

Each txn must be either case but not both. Do you have any data on this, like how many people are using the each signing pre-image? We will note in the function that the hash is only for all zero if necessary.

I don't think there is a case that they need both. Do you have a use case in mind?

The fee payer must sign the transaction with their own address included. The primary and secondary signers have two options: (1) Signing the transaction with the fee payer's address included, or (2) Signing the transaction with 0x0 as the fee payer address. I believe that option (2) is commonly used when the specific fee-payer account is determined later in the process. However, I don't have specific data to confirm this. Perhaps @davidiw, @gregnazario, or @movekevin may have more context on this.

The second path is important.

The sender initially signs with 0x0, and then the fee payer signs with their address in that slot.

There are then 2 hashes, it would be the fee payer's responsibility to tell the user what the new hash is.

This is important to allow decoupling of knowing who the second signer is, because you don't really care as long as they pay

Though, this definitely points out a use case for a wait on sequence number function

@lightmark, per request, I've updated the function to generate the hash value using 0x0 as the fee-payer address. If we need to generate hash values based on actual fee-payer addresses, we will need to introduce a separate API, as you suggested.

igor-aptos · 2024-10-02T16:03:12Z

aptos-move/framework/aptos-framework/sources/transaction_context.move

@@ -182,6 +182,13 @@ module aptos_framework::transaction_context {
        payload.entry_function_payload
    }

+    /// Returns the hash of the current raw transaction, which is used for transaction authentication.
+    /// This function calls an internal native function to retrieve the raw transaction hash.
+    public fun raw_txn_hash(): vector<u8> {


what will this be for non-user transactions? will it abort or returning something?
is there any uniqueness guarantees?

(irrespectively, function should be raw_txn_hash() -> get_raw_txn_hash() to follow the naming of other functions)

what will this be for non-user transactions? will it abort or returning something?

It will abort when it's a non-user transaction and a user transaction context is unavailable.

aptos-core/aptos-move/framework/aptos-framework/sources/transaction_context.move

Line 273 in 71ec744

// expected to fail with the error code of `invalid_state(E_TRANSACTION_CONTEXT_NOT_AVAILABLE)`

is there any uniqueness guarantees?

The returned hash values should differ if the raw transactions are different. However, it will remain the same across sessions (prologue, execution, and epilogue). In that sense, it's different from the get_transaction_hash function.

(irrespectively, function should be raw_txn_hash() -> get_raw_txn_hash() to follow the naming of other functions)

The convention seems to avoid using the get_ prefix, except for get_transaction_hash and get_script_hash.
https://github.com/aptos-labs/aptos-core/blob/main/aptos-move/framework/aptos-framework/sources/transaction_context.move#L71-L183

what's the hash from get_transaction_hash?

It's the hash of the SessionId, which is an internal data structure within the Aptos VM.

could we add a feature flag and reuse this function?

get_transaction_hash is used extensively with the assumption it is a globally unique identifier to the session (across all transaction types)

new one isn't

so it will break anything that depends on it.

Naming here is very poor. Maybe we should deprecate this one (with #[deprecated]), and add two new functions with clearer names, then compiler will warn people - and we can update in framework accordingly.

we can name them transaction_hash and unique_session_hash

Naming here is very poor. Maybe we should deprecate this one (with #[deprecated]), and add two new functions with clearer names, then compiler will warn people - and we can update in framework accordingly.

I've refactored the code by introducingunique_session_hash and marking the original get_transaction_hash function with the #[deprecated] attribute. Even though the behavior of the original function remains unchanged, do we still need to feature-gate its deprecation?

we can name them transaction_hash and unique_session_hash

How about raw_transaction_hash? It's a bit more descriptive and less likely to cause confusion with other types of transaction hashes in the future.

igor-aptos · 2024-10-18T17:19:49Z

aptos-move/framework/aptos-framework/sources/object.move

@@ -842,7 +842,7 @@ module aptos_framework::object {
    #[test(fx = @std)]
    fun test_correct_auid() {
        let auid1 = aptos_framework::transaction_context::generate_auid_address();
-        let bytes = aptos_framework::transaction_context::get_transaction_hash();
+        let bytes = aptos_framework::transaction_context::unique_session_hash();


either you need a feature flag, or more simply - you can separate all usages of unique_session_hash() into separate PR that lands one release after that native function is introduced.

@igor-aptos , since get_transaction_hash is still available, should get_transaction_hash still be used in this release instead of unique_session_hash?

igor-aptos · 2024-10-18T17:20:27Z

aptos-move/framework/aptos-framework/sources/transaction_context.move

@@ -31,16 +31,19 @@ module aptos_framework::transaction_context {
        entry_function_payload: Option<EntryFunctionPayload>,
    }

-    /// Returns the transaction hash of the current transaction.
-    native fun get_txn_hash(): vector<u8>;


you need to leave this for 1 release

Got it. I added it back.

igor-aptos · 2024-10-18T17:21:35Z

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

@@ -387,7 +406,10 @@ pub fn make_all(
    let natives = [
        ("get_script_hash", native_get_script_hash as RawSafeNative),
        ("generate_unique_address", native_generate_unique_address),
-        ("get_txn_hash", native_get_txn_hash),
+        (


just add both with same:

("get_txn_hash", native_unique_session_hash_internal), ("unique_session_hash_internal", native_unique_session_hash_internal),

I added it back. Now, we have both.

lightmark · 2024-10-23T04:22:00Z

@junkil-park can you resolve @igor-aptos 's comments? We need this for blind signing.

junkil-park · 2024-10-23T10:18:24Z

@junkil-park can you resolve @igor-aptos 's comments? We need this for blind signing.

A bit delayed due to a discussion about this issue on Slack. I will update shortly.

junkil-park · 2024-10-24T22:19:49Z

aptos-move/framework/aptos-framework/sources/transaction_context.move

+        assert!(features::transaction_context_hash_function_update_enabled(), error::invalid_state(ETRANSACTION_CONTEXT_HASH_FUNCTION_UPDATE_NOT_ENABLED));
+        raw_transaction_hash_internal()
+    }
+    native fun raw_transaction_hash_internal(): vector<u8>;


@igor-aptos , this is an entirely new native function (unlike get_txn_hash()). Does this pattern seem right to you, having a public function wrapper and being protected by a feature gate?

yes this is correct.

you can register raw_transaction_hash as native as well, so in next release you can remove raw_transaction_hash_internal completely

igor-aptos · 2024-10-24T23:09:53Z

aptos-move/framework/aptos-framework/sources/transaction_context.move

+        assert!(features::transaction_context_hash_function_update_enabled(), error::invalid_state(ETRANSACTION_CONTEXT_HASH_FUNCTION_UPDATE_NOT_ENABLED));
+        raw_transaction_hash_internal()
+    }
+    native fun raw_transaction_hash_internal(): vector<u8>;


yes this is correct.

you can register raw_transaction_hash as native as well, so in next release you can remove raw_transaction_hash_internal completely

igor-aptos · 2024-10-24T23:11:46Z

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

@@ -405,6 +424,10 @@ pub fn make_all(
            "multisig_payload_internal",
            native_multisig_payload_internal,
        ),
+        (


you need to add now:

("unique_session_hash", native_get_txn_hash),

so that second stage can be done

and you can rename native_get_txn_hash to native_unique_session_hash in rust for cleanliness, as this is just rust code

Done renaming native_get_txn_hash to native_unique_session_hash,
and adding ("unique_session_hash", native_unique_session_hash), and
("raw_transaction_hash", native_raw_transaction_hash_internal,),

@igor-aptos , by the way, we already have some existing native functions such as gas_payer_internal that has its public wrapper gas_payer.
Following the same pattern, we can register gas_payer as native in this release, right? So, adding,

("gas_payer", native_gas_payer_internal),

yup, if you want to clean things up and optimize out - we can do that.

if there is any chance we are going to need to revert a flag, we shouldn't remove the internal variant :)

This commit adds a transaction context function to get the raw transaction hash.

igor-aptos · 2024-10-25T15:26:08Z

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

+        ("get_txn_hash", native_unique_session_hash),
+        ("unique_session_hash", native_unique_session_hash),
+        ("sender", native_sender_internal),
        ("sender_internal", native_sender_internal),
+        ("secondary_signers", native_secondary_signers_internal),
        (
            "secondary_signers_internal",
            native_secondary_signers_internal,
        ),
+        ("gas_payer", native_gas_payer_internal),
        ("gas_payer_internal", native_gas_payer_internal),
+        ("max_gas_amount", native_max_gas_amount_internal),
        ("max_gas_amount_internal", native_max_gas_amount_internal),
+        ("gas_unit_price", native_gas_unit_price_internal),
        ("gas_unit_price_internal", native_gas_unit_price_internal),
+        ("chain_id", native_chain_id_internal),
        ("chain_id_internal", native_chain_id_internal),
+        (
+            "entry_function_payload",
+            native_entry_function_payload_internal,
+        ),


vusirikala · 2024-10-28T04:51:43Z

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

+                    let raw_txn = RawTransactionWithData::new_fee_payer(
+                        txn.clone().into_raw_transaction(),
+                        secondary_signer_addresses.clone(),
+                        AccountAddress::ZERO,


Just curious about the reason behind using ZERO for fee-payer address. Is it because we want the execution of the transaction to be the same independent of which fee payer is paying for the transaction?

For example, the sender and secondary signers can sign without specifying a particular fee-payer address, allowing the gas station to select an appropriate fee-payer account as needed.

secondary signers can sign without specifying a particular fee-payer address,

Oh, I see. In practice, do secondary signers actually set the fee-payer address to ZERO? In the below sign_fee_payer function, both the secondary signers and fee payer seem to be signing the same message. But then, in the verify function, the fee payer address is replaced with ZERO. I'm not sure why.

https://github.com/aptos-labs/aptos-core/blob/main/types/src/transaction/mod.rs#L298
https://github.com/aptos-labs/aptos-core/blob/main/types/src/transaction/authenticator.rs#L172

The sender and secondary signers can sign with or without specifying a fee-payer address; both options are currently supported. However, the fee-payer is required to sign with its address included.

vusirikala · 2024-10-28T04:55:43Z

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

+                    );
+                    raw_txn.hash().to_vec()
+                },
+                _ => txn.raw_transaction_ref().hash().to_vec(),


SignedTransaction actually already has the field committed_hash that is computed during the previous stages of the execution pipeline. If we are okay with using hash(signed transaction) here instead of hash(raw transaction), then we might save CPU cycles?

We need the hash of the "raw transaction" that is used in the authentication process for signers.

If we are okay with using hash(signed transaction), then I guess we may not need to construct RawTransactionWithData as above (as TransactionAuthenticator will already have the info)?

If we are okay with using hash(signed transaction)

In the current setting, I think it's not ok to use hash(signed transaction) because TransactionAuthenticator also contains signatures which should be excluded.

vusirikala · 2024-10-28T05:16:16Z

aptos-move/framework/aptos-framework/sources/transaction_context.move

+    #[expected_failure(abort_code=196609, location = Self)]
+    fun test_call_raw_txn_hash() {
+        // expected to fail with the error code of `invalid_state(E_TRANSACTION_CONTEXT_NOT_AVAILABLE)`
+        let _multisig = multisig_payload();


The function seems pretty innocent :-)
Curious why it is supposed to fail.

The unit test runs in an environment without any user transaction context. In that case, the design decision has been to abort instead of returning some default value.

vusirikala · 2024-10-28T05:17:44Z

aptos-move/framework/aptos-framework/sources/transaction_context.move

+    /// In the case of a fee payer transaction, the hash value is generated using 0x0 as the fee payer address.
+    public fun raw_transaction_hash(): vector<u8> {
+        assert!(features::transaction_context_hash_function_update_enabled(), error::invalid_state(ETRANSACTION_CONTEXT_HASH_FUNCTION_UPDATE_NOT_ENABLED));
+        raw_transaction_hash_internal()


I'm actually not super familiar with why we do this. In general, why do we separate the native function into two functions with _internal tag?

For safety in release. It would've been ideal to just add public native fun raw_transaction_hash(). However, it's turns out to be unsafe during the release process due to the timing not being perfectly aligned between the binary upgrade and the framework upgrade.

github-actions · 2024-10-28T07:30:03Z

✅ Forge suite `realistic_env_max_load` success on `6b724bfda40f0e4488a00f7eeadf8acfd8856f79`

two traffics test: inner traffic : committed: 14101.46 txn/s, latency: 2813.17 ms, (p50: 2700 ms, p70: 2700, p90: 3000 ms, p99: 3300 ms), latency samples: 5361660
two traffics test : committed: 99.92 txn/s, latency: 1517.62 ms, (p50: 1400 ms, p70: 1500, p90: 1600 ms, p99: 7300 ms), latency samples: 1760
Latency breakdown for phase 0: ["MempoolToBlockCreation: max: 2.009, avg: 1.559", "ConsensusProposalToOrdered: max: 0.326, avg: 0.298", "ConsensusOrderedToCommit: max: 0.395, avg: 0.377", "ConsensusProposalToCommit: max: 0.688, avg: 0.675"]
Max non-epoch-change gap was: 0 rounds at version 0 (avg 0.00) [limit 4], 0.99s no progress at version 2802849 (avg 0.21s) [limit 15].
Max epoch-change gap was: 0 rounds at version 0 (avg 0.00) [limit 4], 8.55s no progress at version 2802847 (avg 8.55s) [limit 15].
Test Ok

github-actions · 2024-10-28T07:32:14Z

✅ Forge suite `framework_upgrade` success on `f38ec72e975a4dff4e9919e7a1d8118a75858bab` ==> `6b724bfda40f0e4488a00f7eeadf8acfd8856f79`

Compatibility test results for f38ec72e975a4dff4e9919e7a1d8118a75858bab ==> 6b724bfda40f0e4488a00f7eeadf8acfd8856f79 (PR)
Upgrade the nodes to version: 6b724bfda40f0e4488a00f7eeadf8acfd8856f79
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 1188.43 txn/s, submitted: 1191.54 txn/s, failed submission: 3.10 txn/s, expired: 3.10 txn/s, latency: 2611.31 ms, (p50: 2400 ms, p70: 3000, p90: 3800 ms, p99: 5700 ms), latency samples: 107280
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 1178.13 txn/s, submitted: 1181.20 txn/s, failed submission: 3.08 txn/s, expired: 3.08 txn/s, latency: 2440.51 ms, (p50: 2100 ms, p70: 2700, p90: 3900 ms, p99: 5700 ms), latency samples: 107160
5. check swarm health
Compatibility test for f38ec72e975a4dff4e9919e7a1d8118a75858bab ==> 6b724bfda40f0e4488a00f7eeadf8acfd8856f79 passed
Upgrade the remaining nodes to version: 6b724bfda40f0e4488a00f7eeadf8acfd8856f79
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 1233.55 txn/s, submitted: 1236.63 txn/s, failed submission: 3.08 txn/s, expired: 3.08 txn/s, latency: 2402.92 ms, (p50: 2400 ms, p70: 2400, p90: 3300 ms, p99: 4800 ms), latency samples: 112000
Test Ok

github-actions · 2024-10-28T07:35:24Z

✅ Forge suite `compat` success on `f38ec72e975a4dff4e9919e7a1d8118a75858bab` ==> `6b724bfda40f0e4488a00f7eeadf8acfd8856f79`

Compatibility test results for f38ec72e975a4dff4e9919e7a1d8118a75858bab ==> 6b724bfda40f0e4488a00f7eeadf8acfd8856f79 (PR)
1. Check liveness of validators at old version: f38ec72e975a4dff4e9919e7a1d8118a75858bab
compatibility::simple-validator-upgrade::liveness-check : committed: 17352.52 txn/s, latency: 1976.85 ms, (p50: 2100 ms, p70: 2100, p90: 2200 ms, p99: 2400 ms), latency samples: 553720
2. Upgrading first Validator to new version: 6b724bfda40f0e4488a00f7eeadf8acfd8856f79
compatibility::simple-validator-upgrade::single-validator-upgrading : committed: 7086.67 txn/s, latency: 4032.21 ms, (p50: 4600 ms, p70: 4900, p90: 5000 ms, p99: 5000 ms), latency samples: 131360
compatibility::simple-validator-upgrade::single-validator-upgrade : committed: 6604.28 txn/s, latency: 4870.17 ms, (p50: 5000 ms, p70: 5000, p90: 6800 ms, p99: 7200 ms), latency samples: 218640
3. Upgrading rest of first batch to new version: 6b724bfda40f0e4488a00f7eeadf8acfd8856f79
compatibility::simple-validator-upgrade::half-validator-upgrading : committed: 5588.61 txn/s, latency: 5173.28 ms, (p50: 6000 ms, p70: 6200, p90: 6300 ms, p99: 6400 ms), latency samples: 106860
compatibility::simple-validator-upgrade::half-validator-upgrade : committed: 5214.50 txn/s, latency: 5757.98 ms, (p50: 6200 ms, p70: 6500, p90: 6700 ms, p99: 7000 ms), latency samples: 202080
4. upgrading second batch to new version: 6b724bfda40f0e4488a00f7eeadf8acfd8856f79
compatibility::simple-validator-upgrade::rest-validator-upgrading : committed: 9523.98 txn/s, latency: 2947.66 ms, (p50: 3100 ms, p70: 3500, p90: 3700 ms, p99: 3900 ms), latency samples: 163680
compatibility::simple-validator-upgrade::rest-validator-upgrade : committed: 9375.42 txn/s, latency: 3425.72 ms, (p50: 3600 ms, p70: 3800, p90: 4100 ms, p99: 4300 ms), latency samples: 308160
5. check swarm health
Compatibility test for f38ec72e975a4dff4e9919e7a1d8118a75858bab ==> 6b724bfda40f0e4488a00f7eeadf8acfd8856f79 passed
Test Ok

…saction hash)

…saction hash) (#15123)

movekevin reviewed Jun 12, 2024

View reviewed changes

lightmark reviewed Jun 12, 2024

View reviewed changes

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

github-actions bot added Stale and removed Stale labels Jul 28, 2024

github-actions bot added Stale and removed Stale labels Sep 12, 2024

junkil-park force-pushed the jpark/raw-txn-hash branch from 3f6dae2 to 71ec744 Compare September 27, 2024 16:07

junkil-park marked this pull request as ready for review September 27, 2024 16:07

junkil-park requested review from davidiw, wrwg, zekun000, vgao1996 and georgemitenkov as code owners September 27, 2024 16:07

lightmark approved these changes Sep 27, 2024

View reviewed changes

igor-aptos reviewed Oct 2, 2024

View reviewed changes

junkil-park force-pushed the jpark/raw-txn-hash branch 3 times, most recently from 3cbbd82 to fa93aa3 Compare October 3, 2024 18:49

junkil-park force-pushed the jpark/raw-txn-hash branch 2 times, most recently from 9e9a62b to 4f7ef2b Compare October 10, 2024 01:15

igor-aptos requested changes Oct 18, 2024

View reviewed changes

junkil-park force-pushed the jpark/raw-txn-hash branch from 4f7ef2b to b7576fc Compare October 23, 2024 10:23

junkil-park force-pushed the jpark/raw-txn-hash branch 3 times, most recently from a03f0fe to 313ee22 Compare October 24, 2024 22:14

junkil-park commented Oct 24, 2024

View reviewed changes

junkil-park requested a review from vusirikala October 24, 2024 22:20

junkil-park force-pushed the jpark/raw-txn-hash branch from 313ee22 to df35fd7 Compare October 24, 2024 22:24

igor-aptos reviewed Oct 24, 2024

View reviewed changes

junkil-park force-pushed the jpark/raw-txn-hash branch from df35fd7 to dcfd72d Compare October 24, 2024 23:42

Add a transaction context function to get the raw transaction hash

6b724bf

This commit adds a transaction context function to get the raw transaction hash.

junkil-park force-pushed the jpark/raw-txn-hash branch from dcfd72d to 6b724bf Compare October 25, 2024 06:38

junkil-park requested a review from igor-aptos October 25, 2024 15:25

igor-aptos approved these changes Oct 25, 2024

View reviewed changes

vusirikala reviewed Oct 28, 2024

View reviewed changes

junkil-park requested a review from vusirikala October 28, 2024 05:26

vusirikala approved these changes Oct 28, 2024

View reviewed changes

junkil-park enabled auto-merge (squash) October 28, 2024 07:03

This comment has been minimized.

Sign in to view

junkil-park merged commit 1d05d92 into main Oct 28, 2024
92 checks passed

junkil-park deleted the jpark/raw-txn-hash branch October 28, 2024 07:38

junkil-park added a commit that referenced this pull request Oct 30, 2024

Revert #13659 (Add a transaction context function to get the raw tran…

9265006

…saction hash)

junkil-park mentioned this pull request Oct 30, 2024

Revert #13659 (Add a transaction context function to get the raw transaction hash) #15123

Merged

junkil-park added a commit that referenced this pull request Oct 30, 2024

Revert #13659 (Add a transaction context function to get the raw tran…

1699040

…saction hash) (#15123)

Add a transaction context function to get the raw transaction hash #13659

Add a transaction context function to get the raw transaction hash #13659

Conversation

junkil-park commented Jun 12, 2024 • edited Loading

Description

Type of Change

Which Components or Systems Does This Change Impact?

How Has This Been Tested?

Key Areas to Review

Checklist

trunk-io bot commented Jun 12, 2024 • edited Loading

codecov bot commented Jun 12, 2024 • edited Loading

Codecov Report

Choose a reason for hiding this comment

github-actions bot commented Jul 28, 2024

github-actions bot commented Sep 12, 2024

lightmark commented Sep 18, 2024

junkil-park commented Sep 18, 2024

lightmark left a 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

junkil-park Oct 3, 2024 • edited Loading

Choose a reason for hiding this comment

gregnazario Oct 3, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

junkil-park Oct 2, 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

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

lightmark commented Oct 23, 2024

junkil-park commented Oct 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

junkil-park Oct 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vusirikala Oct 28, 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

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

junkil-park Oct 28, 2024 • edited Loading

Choose a reason for hiding this comment

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

github-actions bot commented Oct 28, 2024

✅ Forge suite realistic_env_max_load success on 6b724bfda40f0e4488a00f7eeadf8acfd8856f79

github-actions bot commented Oct 28, 2024

✅ Forge suite framework_upgrade success on f38ec72e975a4dff4e9919e7a1d8118a75858bab ==> 6b724bfda40f0e4488a00f7eeadf8acfd8856f79

github-actions bot commented Oct 28, 2024

✅ Forge suite compat success on f38ec72e975a4dff4e9919e7a1d8118a75858bab ==> 6b724bfda40f0e4488a00f7eeadf8acfd8856f79

junkil-park commented Jun 12, 2024 •

edited

Loading

trunk-io bot commented Jun 12, 2024 •

edited

Loading

codecov bot commented Jun 12, 2024 •

edited

Loading

junkil-park Oct 3, 2024 •

edited

Loading

gregnazario Oct 3, 2024 •

edited

Loading

junkil-park Oct 2, 2024 •

edited

Loading

junkil-park commented Oct 23, 2024 •

edited

Loading

junkil-park Oct 24, 2024 •

edited

Loading

vusirikala Oct 28, 2024 •

edited

Loading

junkil-park Oct 28, 2024 •

edited

Loading

✅ Forge suite `realistic_env_max_load` success on `6b724bfda40f0e4488a00f7eeadf8acfd8856f79`

✅ Forge suite `framework_upgrade` success on `f38ec72e975a4dff4e9919e7a1d8118a75858bab` ==> `6b724bfda40f0e4488a00f7eeadf8acfd8856f79`

✅ Forge suite `compat` success on `f38ec72e975a4dff4e9919e7a1d8118a75858bab` ==> `6b724bfda40f0e4488a00f7eeadf8acfd8856f79`