[EAN-Issue-2530] Added emv-contracts-details move module by aregng · Pull Request #342 · Entropy-Foundation/aptos-core

aregng · 2026-03-10T08:29:19Z

The module will hold the evm contract names associated with the corresponding addresses
Supra node runtime will utilize this information to retrieve evm block-metadata and automation-registry contract addresses
Users can retrieve the 0x1::evm_contracts_details::EvmContractsDetails resource to get info on supra native evm contracts

Fixes: https://github.com/Entropy-Foundation/smr-moonshot/issues/2530

sjoshisupra · 2026-03-26T06:41:59Z

+    public(friend) fun on_new_epoch(framework: &signer) acquires EvmContractsDetails {
+        system_addresses::assert_supra_framework(framework);
+        if (config_buffer::does_exist<EvmContractsDetails>()) {
+            let new_config = config_buffer::extract<EvmContractsDetails>();


is this compatible with another PR that @supra-yoga worked on ? Essentially this config_buffer::extract is an unprotected extraction flagged by auditor so we have extract_v2 somewhere which takes framework signer. This is going to conflict with that.

sjoshisupra · 2026-03-26T06:45:30Z

+    /// Input for DKG key output - contains threshold type and keys for one committee
+    struct DkgCommitteeOutput has copy, drop {
+        /// The threshold type (0=validity, 1=quorum, 2=unanimous, etc.)
+        threshold_type: u8,
+        /// Public key shares for each validator (indexed by validator position)
+        keys: vector<vector<u8>>,
+    }


struct should be before any method as a standard practice in Move modules

sjoshisupra · 2026-03-26T06:47:13Z

+    public fun new_dkg_node_config(addr: address, identity: vector<u8>, dkg_pubkey: vector<u8>,): DkgNodeConfig{
+        DkgNodeConfig{
+            addr,
+            identity,
+            dkg_pubkey
+        }
+    }
+
+    public fun get_addr(dkg_node: &DkgNodeConfig): address{
+        dkg_node.addr
+    }
+
+    public fun get_dkg_pubkey(dkg_node: &DkgNodeConfig): vector<u8>{
+        dkg_node.dkg_pubkey
+    }
+
+    public fun len(committee: &DkgCommittee): u64{
+        vector::length(&committee.committee)
+    }
+
+    public fun get_committee(dkg_committee: &DkgCommittee): vector<DkgNodeConfig>{
+        dkg_committee.committee
+    }
+
+    public fun new_dkg_committee(committee: vector<DkgNodeConfig>, threshold_type: CertificateThresholdType): DkgCommittee{
+
+        assert!(vector::length(&committee) > 0, EINVALID_DKG_COMMITTEE_SIZE);
+        DkgCommittee{
+            committee,
+            threshold_type
+        }
+    }
+
+    public fun new_dkg_committee_from_validator_consensus_info(validator_committee: vector<ValidatorConsensusInfo>, threshold_type: CertificateThresholdType): DkgCommittee{
+
+        assert!(vector::length(&validator_committee) > 0, EINVALID_DKG_COMMITTEE_SIZE);
+
+        // The order of the committee members is important for DKG.
+        // The order should correspond to the order of the validator committee.
+        // The output of the DKG has keys in the same order as the committee.
+        let dkg_committee = vector[];
+        vector::for_each(validator_committee, |x|
+            {
+                let validator_keys_bytes = validator_consensus_info::get_pk_bytes(&x);
+                let addr = validator_consensus_info::get_addr(&x);
+                vector::push_back(&mut dkg_committee, DkgNodeConfig{
+                    addr,
+                    identity: bcs::to_bytes(&addr),
+                    dkg_pubkey: validator_keys_bytes,
+                });
+            }
+        );
+
+        DkgCommittee{
+            committee: dkg_committee,
+            threshold_type
+        }
+    }
+
+    public fun new_receiver_committee(is_resharing: bool, dkg_threshold_type: CertificateThresholdType, committee: DkgCommittee): ReceiverCommittee{
+        ReceiverCommittee{


I think all of the methods here are pure functions so should either be tagged as view or perhaps use public(friend) if this is to be invoked only from other module? Not sure what purpose is served by this module since Move state is not changed at all. If this is only for validators, wouldn't it make more sense to do this in rust layer?

sjoshisupra · 2026-03-26T06:49:36Z

    use supra_framework::system_addresses;
    use supra_framework::staking_config::{Self, StakingConfig, StakingRewardsConfig};
    use supra_framework::chain_status;
+    use std::dkg_committee;


use supra_framework::dkg_committee

sjoshisupra · 2026-03-26T07:29:23Z

+        let len = vector::length(&public_key_shares_all_comms.commitments);
+        while (i < len) {
+            let commitment = vector::borrow(&public_key_shares_all_comms.commitments, i);
+            // As the first index contains the committee's threshold public key, we can skip that
+            let evals = vector::slice(&commitment.bls12381_commitment_evals, 1, vector::length(&commitment.bls12381_commitment_evals));
+
+            vector::push_back(
+                &mut committee_outputs,
+                new_dkg_committee_output(commitment.threshold_type, evals)
+            );
+            i = i + 1;
+        };


if the vector is ok to be destroyed use vector::for_each_reverse otherwise use vector::for_each_ref, in general use functional style vector operations available in vector.move

sjoshisupra · 2026-03-26T07:30:01Z

    }

+    /// Return the last completed DKG session state, if it exists.
+    public fun last_completed_session(): Option<DKGSessionState> acquires DKGState {


Should this be public fun or public(friend) fun?

if it should be public fun then should be tagged as view

sjoshisupra · 2026-03-26T07:38:05Z

+// Copyright (c) Aptos Foundation
+// SPDX-License-Identifier: Apache-2.0
+


Not sure why Aptos Foundation header got added, is this auto generated?

sjoshisupra · 2026-03-26T07:38:44Z

+// Copyright (c) Aptos Foundation
 // SPDX-License-Identifier: Apache-2.0



Again, not sure why this got added as header, this is purely SUPRA code

sjoshisupra · 2026-03-26T07:39:40Z

+// Copyright (c) Aptos Foundation
+// SPDX-License-Identifier: Apache-2.0
+


Purely supra code, remove this header, not sure why this got added

- The module will hold the evm contract names accosiated with the corresponding addresses - Supra node runtime will utilize this information to retrieve evm block-metadata and automation-registry contract addresses - Users can retrieve the 0x1::evm_contracts_details::EvmContractsDetails resource to get info on supra native evm contracts

isaacdoidge

Looks good, only a few minor things.

sjoshisupra · 2026-04-24T11:33:14Z

@@ -0,0 +1,78 @@
+module supra_framework::evm_contracts_details {


Actually this file got renamed in task/isssue-2716 and is creating tree conflict. Since task/issue-2716 is based on this issue-2530 branch I think it is better to merge issue-2716 first to 2530 and then merge 2530 to dev @aregng

sjoshisupra · 2026-04-24T11:33:46Z

    use std::string::String;
    use std::vector;
    use aptos_std::simple_map;
+    use supra_framework::evm_contracts_details;


same, a lot of these have been renamed and overwritten by task/issue-2716 @aregng @isaacdoidge

sjoshisupra · 2026-04-24T11:35:00Z

+// Copyright (c) 2026 Supra.
+// SPDX-License-Identifier: Apache-2.0
+
+use crate::on_chain_config::OnChainConfig;


this file was also augmented and renamed to evm_config.rs in task/issue-2716, this creates tree conflicts @aregng @isaacdoidge

* add evm_config in Move state * add config validation for required key and value type match * add test * remove double negative assert check * change to EvmScalarCOnfig with everything u128 * minor * add evm config to encode testnet * Fixed test * Fixed build error * Enabled serde for OnChainEvmConfig required by to be able to cache on-chain-config * remove nested if * validate gas used ratio, add other evm parameters --------- Co-authored-by: Saurabh Joshi <sjoshi@supra.com> Co-authored-by: Aregnaz Harutyunyan <>

… well (#354) Co-authored-by: Aregnaz Harutyunyan <>

aregng requested review from isaacdoidge and sjoshisupra March 10, 2026 08:29

aregng force-pushed the task/issue-2530 branch 2 times, most recently from 31a63cb to 0cf508d Compare March 25, 2026 11:30

sjoshisupra requested changes Mar 26, 2026

View reviewed changes

aregng changed the base branch from dev to feature/dkg-integration April 6, 2026 08:10

Base automatically changed from feature/dkg-integration to dev April 12, 2026 07:57

Aregnaz Harutyunyan added 3 commits April 19, 2026 22:01

Addressed review comments

18a200c

Addressed license headers

b97a3a4

aregng force-pushed the task/issue-2530 branch from fe8016f to 96b264d Compare April 19, 2026 20:41

Fixed TODO and test failures

66ba102

aregng force-pushed the task/issue-2530 branch from 96b264d to 66ba102 Compare April 19, 2026 23:07

Merge branch 'dev' into task/issue-2530

cec2eba

isaacdoidge reviewed Apr 23, 2026

View reviewed changes

Fixed EvnContractName string values

9445861

aregng force-pushed the task/issue-2530 branch from 1717357 to 9445861 Compare April 23, 2026 06:53

Addressed review comments

d7a89ad

isaacdoidge previously approved these changes Apr 24, 2026

View reviewed changes

sjoshisupra reviewed Apr 24, 2026

View reviewed changes

sjoshisupra dismissed isaacdoidge’s stale review via 78bc753 April 24, 2026 11:38

sjoshisupra previously approved these changes Apr 24, 2026

View reviewed changes

[Issue-2530] Extended GenesisEvmContract to support function calls as…

c7a346a

… well (#354) Co-authored-by: Aregnaz Harutyunyan <>

aregng dismissed sjoshisupra’s stale review via c7a346a April 24, 2026 16:38

		// Copyright (c) Aptos Foundation
		// SPDX-License-Identifier: Apache-2.0

		@@ -0,0 +1,78 @@
		module supra_framework::evm_contracts_details {

Conversation

aregng commented Mar 10, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

isaacdoidge left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants