seen this test failure a couple times now. eg, https://github.com/ava-labs/subnet-evm/runs/8120806684?check_suite_focus=true

    --- FAIL: TestArchiveBlockChain/TestStatefulPrecompiles (0.06s)
        test_blockchain.go:166: head state missing 1:0x9bd1529846788581c59ad30279e44797e094f6f00d391d4a48cc4324a91dad01

Subnet-evm's e2e tests currently download the network runner multiple times. Let's migrate to using go install so that we don't need to repeat the install process multiple times.

This ticket is to switch from using HardHat to the Foundry tool with the goal of switching from JS to Rust dependency for security reasons.

Use Foundry cli tooling with DS-test instead of HardHat. Benefits include (but are not limited to):

• removes dependency on npm/node-modules as a potential attack vector on CI

Implementation plan

• Make sure DS-test works with a local subnet
• add docs for installing foundry locally
• add script(s) for running local tests locally
• add github action (CI) for foundry tests (https://github.com/foundry-rs/foundry-toolchain)
• Migrate precompile tests to solidity-based tests (DS-test) using Foundry/Forge for deployment
• deprecate HardHat tests in CI

Remove the JSON file that was used as the airdrop for the WAGMI genesis and switch to allowing users to specify a path to an airdrop genesis that WAGMI can use to maintain backwards comaptibility.

Describe the bug

After the Fee Config Manager's setFeeConfig function is called and the fee config values are updated the gas fee estimation does not reflect latest changes.

In our case the initial "minBaseFee" was 1,000,000,000, after increasing it to 50,000,000,000 we were not able to send any transactions with the default fee estimations using metamask or core (Transactions were being rejected because of low fee). As a workaround we had to override and set "Max Priority Fee" and "Max Fee" to higher numbers in order to push one transaction. Once a new block was accepted by the network the estimations were fixed, Metamask and Core started suggesting better values.

To Reproduce

1. Initial feeConfig:

"feeConfig": {
        "gasLimit": 20000000,
        "targetBlockRate": 2,
        "minBaseFee": 1000000000,
        "targetGas": 100000000,
        "baseFeeChangeDenominator": 48,
        "minBlockGasCost": 0,
        "maxBlockGasCost": 10000000,
        "blockGasCostStep": 500000
}

2. Observe fee estimations work using Metamask/Core

3. Update feeConfig:

"feeConfig": {
        "gasLimit": 35000000,
	"targetBlockRate": 2,
        "minBaseFee": 50000000000,
        "targetGas": 100000000,
        "baseFeeChangeDenominator": 48,
        "minBlockGasCost": 0,
        "maxBlockGasCost": 10000000,
        "blockGasCostStep": 1000000
}

4. Observe fee estimations of Metamask/Core are still the same for same type of operation

Expected behavior

Fee estimations should be updated accordingly

Describe the bug

After creating a workable subnet, the admin cannot mint native coins.

I have add contractNativeMinterConfig in the genesis.json.

To Reproduce

1. Create my genesis.json referring to the genesis example.
2. Create a workable subnet following the official document: Create an EVM Subnet on Fuji Testnet.
3. Create NativeMinterInterface following the official document: Minting Native Coins.
4. Use Hardhat console to call mintNativeCoin.

> contract = await ethers.getContractAt("NativeMinterInterface", "0x0200000000000000000000000000000000000001")

> [admin] = await ethers.getSigners()

> await admin.getBalance()
BigNumber { value: "99999999999845284000000300" }

> r = await contract.mintNativeCoin(admin.address, 100)
{
  hash: '0x87fd1435355b54bc5e7f0eb07d826df43ba043bdab1ea7c3766dac11725908d3',
  type: 0,
  accessList: null,
  blockHash: '0xd2c8176d26e1d3c8a400d3a9d15cbf0e258b35dc0a5cde91deab40d95461e709',
  blockNumber: 4,
  transactionIndex: 0,
  confirmations: 1,
  from: '0x63B7076FC0A914Af543C2e5c201df6C29FCC18c5',
  gasPrice: BigNumber { value: "1000000000" },
  gasLimit: BigNumber { value: "51572" },
  to: '0x0200000000000000000000000000000000000001',
  value: BigNumber { value: "0" },
  nonce: 3,
  data: '0x4f5aaaba00000000000000000000000063b7076fc0a914af543c2e5c201df6c29fcc18c50000000000000000000000000000000000000000000000000000000000000064',
  r: '0xa163fd7b436369e19488abfa288ff760f89cd6d519a2e0b7710bd2de9fe0683f',
  s: '0x0e175ca8e5c63709b9dbe9ebc830b141c11d808a383975effb4b017ebc09386b',
  v: 21052,
  creates: null,
  chainId: 10508,
  wait: [Function (anonymous)]
}

> await admin.getBalance()
BigNumber { value: "99999999999793712000000400" }

Expected behavior

Admin can mint native coins and receives the minted coins.

Screenshots

N/A

Logs

Complete Hardhat logs

Metrics

N/A

Operating System

1. OS: Ubuntu 20.04.4 LTS (AWS instance)
2. Avalanchego: v1.7.14
3. subnet-evm: commit 1a7f57e (2022-07-01)

Additional context

Shared this issue in #subnet-chat on Discord, and the team asked for more details. Please feel free to let me know what are the logs to be helpful, and I will provide them soon. Thanks!

Avalanche Bug Bounty program can be found here.

patrick-ogrady#1
patrick-ogrady#2

Allow subnet-evm to sync the full state of the network and begin processing blocks from there instead of fetching the entire block history and executing them from genesis.

I have been trying to understand all Avalanche genesis block . I would like to have a better understanding of Hardforks. What represents to change these values. And understand more in detail feed config. Did not find information in details about : blockGasCostStep, targetBlockRate, baseFeeChangeDenominator

 "config": {
            "chainID": chainID,
            "homesteadBlock": 0,
            "eip150Block": 0,
            "eip150Hash": "0x2086799aeebeae135c246c65021c82b4e15a2c451340993aacfd2751886514f0",
            "eip155Block": 0,
            "eip158Block": 0,
            "byzantiumBlock": 0,
            "constantinopleBlock": 0,
            "petersburgBlock": 0,
            "istanbulBlock": 0,
            "muirGlacierBlock": 0,
            "subnetEVMTimestamp": 0,
            "feeConfig": {
                "gasLimit": 8000000,
                "targetBlockRate": 2,
                "minBaseFee": 13000000000,
                "targetGas": 15000000,
                "baseFeeChangeDenominator": 36,
                "minBlockGasCost": 0,
                "maxBlockGasCost": 1000000,
                "blockGasCostStep": 200000
            },
            "allowFeeRecipients": false
        },
        "alloc": {
            "8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC": {
                "balance": balance
            }
        },
        "timestamp": "0x0",
        "gasLimit": "0x7A1200",
        "difficulty": "0x0",
        "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "coinbase": "0x0000000000000000000000000000000000000000",
        "number": "0x0",
        "gasUsed": "0x0",
        "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000"
    }

Hi!

I am trying to create a blockchain using the subnet EVM but the nodes won't start after placing the VM binary in build/plugins. Here is the error:

FATAL[01-10|09:33:25] app/process/process.go#162: error initializing node: couldn't initialize chain manager: Unrecognized remote plugin message: 

This usually means that the plugin is either invalid or simply
needs to be recompiled to support the latest protocol.

I built the subnet EVM (with go1.17.3 on Ubuntu 20.04) using:

cd subnet-evm
./scripts/build.sh ./build/spePNvBxaWSYL2tB5e2xMmMNBQkXMN8z2XEbz1ML2Aahatwoc
Using branch: v0.0.2
Building Subnet EVM Version: v0.1.0; GitCommit: a59f55e17460eada644b6942895d281407120be9

I tried using different versions of avalanchego (1.6.0, 1.6.5, 1.7.0, 1.7.2) but the error remains. Btw I am running the Avalanche nodes using the Docker avaplatform/avalanchego images.

We should either instruct people to deploy contracts to the blackhole address or should create a precompile that lets an admin dynamically adjust where fees go.

Describe the bug

After upgrading avalanchego (1.7.14 -> 1.7.16) and subnet-evm (commit 1a7f57e -> 0.2.7), I cannot connect RPC to one of my two EVMs (on different subnets separately).

1. Can-work EVM
   1. with a plain genesis
   2. can connect RPC and transfer native coins
2. Cannot-work EVM

   1. with the genesis containing contractNativeMinterConfig and feeManagerConfig

   2. cannot connect RPC and avalanchego showed the error below

      [07-30|09:47:43.692] ERROR chains/manager.go:293 error creating chain "2StUZ1a5omGxvMRm7b2LHjuoDKTmsVEoCEwNeDRZouWvFZwWir": error while creating new snowman vm rpc error: code = Unknown desc = failed to create backend: database contains incompatible genesis (have af912611960895cc0c3f533ec6b87c55966714cb877632491a2c7b83309a395e, new d108973f4d32737daa30b06c67d8de7c40dc846b2ea326fbb61dc1f87f0ab930)
      

To Reproduce

Steps to reproduce the behavior.

1. Download the pre-build avalanchego and subnet-evm.

2. Copy subnet-evm to avalanchego-v1.7.16/plugins/<vmid>

3. Stop the running avalanchego v1.7.14.

4. Run avalanchego v1.7.16

   cd avalanchego-v1.7.16
   ./avalanchego --whitelisted-subnets=CXPiHVHEutq3cs9ddNxxhW5C6trRTXzfGZsNEvpNm6vyuLugj,2fQBahhq3F9eip8KobMgjbvBEahW3153kvAy6YPDrGMTceZcGG --network-id=fuji --http-host=0.0.0.0
   

Expected behavior

MetaMask can connect to both blockchains via RPC and transfer native coins.

Screenshots

N/A

Logs

avalanchego-log.zip

Metrics

N/A

Operating System

1. OS: Ubuntu 20.04.4 LTS (AWS instance)
2. Avalanchego: v1.7.16
3. subnet-evm: v0.2.7

Additional context

N/A

Hi!
I'm trying to deploy EVM Subnet locally wtih avalanche-cli, and running avalanche subnet deploy sabchain -l after creating the said subnet, but getting an error Error: failed to query network health: the health check failed to complete. The server might be down or have crashed, check the logs! rpc error: code = DeadlineExceeded desc = context deadline exceeded
I tried to look in the /var/log/ directory for logs but couldn't find any, no info on this issue in focumentation either. Where to find the deployment logs for debugging?

https://github.com/ava-labs/avalanchego/releases/tag/v1.7.5

Reserve the following addresses for future precompiles:

• Addresses in the range 0x0100000000000000000000000000000000000000-0x01000000000000000000000000000000000000ff for precompiles from coreth
• Addresses in the range 0x0200000000000000000000000000000000000000-0x02000000000000000000000000000000000000ff for optional subnet-evm precompiles
• Addresses in the range 0x0300000000000000000000000000000000000000-0x03000000000000000000000000000000000000ff for subnet-evm forks

Create a tutorial that walks through building a precompile based off of the abigen precompile work and walks through all of the steps necessary to creating a custom precompile all the way through using it within Remix.

Currently, if a subnet-evm node misses an upgrade.json, it will not be allowed to move forward.

We should provide a way to allow subnet owner to move forward instead.

Related code:

We have added json log format to coreth. We can port those changes to Subnet-EVM ad well.

• Switch to using formatted errors where necessary to ensure that it's clear to users what has gone wrong if the precompile could not be generated (if a solidity file is passed in, it results in a vauge error)
• Print some output on success indicating where the file was successfully generated
• Add fmt to the var block so that errors from it not being used in the code are suppressed
• Add CUSTOM CODE label to the var block with suppressing the errors so people know to remove it
• Add CUSTOM CODE label to the address
• Outputs are not packed correctly, PackOutput("funcName") does not include the arguments that need to be packed
• Getting output of error message, generated file, exit status 1 when running with what appears to be an invalid ABI
• Move ABI JSON into separate file and use JSON embedding within the actual file
• Functions with multiple un-named outputs are not handled correctly since the precompile template assumes that this will be a valid type (we should require outputs have names when validating the ABI)
• Nil value is sometimes used incorrectly as the return type to packing functions that return a type whose empty value is not nil ex. common.Address{}
• Switch to always use UnpackIntoInterface instead of sometimes using abi.ConvertType when there is a single parameter

It's currently difficult to re-generate with a changed solidity specification without overwriting work. I've used the process of re-generating the file with a different name and then copy pasting the modified code over.

One alternative approach would be to generate two files:

• Generate the config file which invokes execution functions that take in the set of go typed arguments that are specified by the solidity functions
• Generate the execution functions in a separate file, so that they are separate
• Separate the generation of these two files, so that if there's a change in the arguments/return types, you can re-generate only the config file and it will still automatically call the same functions, but the compiler will signal the change in arguments so that the implementer can easily see what argument and return types have changed without overwriting or copy and pasting their work to a new file

./script/run.sh don't work.
Closing error:

The EVM does not perform overflow checks when transferring the native token from one address to another and does not need to since it's a safe assumption that there will never be more than uint256 of the native token.

Since we have introduced the native token minter precompile, we should evaluate whether it is better to clearly document that it is up to the user of the native token precompile to ensure that their minting logic will not allow funds on the order of overflowing uint256 to get minted or whether it makes sense to add overflow guards.

We should add a requirement that the SubnetEVM upgrade is enabled so that we can deprecate support for it being disabled. It should always be enabled from genesis.

Describe the bug
Error grpc: failed to unmarshal the received message proto:\u00a0cannot parse invalid wire-format data in seen in some E2E executions. This is related to ANR GRPC usage under runner.StartNetwork().
eg https://github.com/ava-labs/subnet-evm/runs/7544641585?check_suite_focus=true

To Reproduce
Execute E2E under b69c71e49a8bdcd6aaee64a052bb3d01913e1eeb
E2E=true scripts/run.sh 1.7.13 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC

Expected behavior
E2E failure (probably flaky) with the given err msg

Screenshots

Logs
stdout/stderr of E2E

Metrics

Operating System
ubuntu

Additional context

Avalanche Bug Bounty program can be found here.

Context

SubnetEVM needs to handle upgradeBytes in order to allow subnetEVM users to easily upgrade an instance of the vanilla subnetEVM without creating their own fork.

Upgrade Bytes Serialization

Stateful precompiles are enabled in subnetEVM by placing a config in the ChainConfig. However, this locks blockchains in to that config for their entire lifetime and we would like to support toggling stateful precompiles as a sometimes necessary (although still discouraged and to be used as infrequently as possible) capability.

upgradeBytes will be specified as a json object that may contain the following keys:

{
  “precompileUpgrades”: [...]
  “networkUpgrades”: {
     “SubnetEVMTimestamp”: 0
   }
}

Suggested approach: If networkUpgrades is specified, it is considered a full replacement for the timestamp (or block #) that activates forks specified in the chain config. Therefore any activated forks must be specified or upgradeBytes will be rejected as incompatible
Alternative 1: only apply upgrades specified in upgradeBytes. This provides an easier UX, where specifying all upgrades is more explicit.
Alternative 2: make networkUpgrades mandatory.

Suggested approach: If precompileUpgrades is specified, it contains an array of possible precompile configs. Each precompile config must include a blockTimestamp, and blockTimestamps specified in the array must be sorted in increasing order (duplicate timestamps allowed). If a precompile upgrade specifies "disable": true, it will deactivate the precompile (that may be later re-activated). eg,

"precompileUpgrades": [
        {
            "contractNativeMinterConfig": {
                "blockTimestamp": 1657892836,
                "disable": true
            }
        },
        {
            "contractNativeMinterConfig": {
                "blockTimestamp": 1657893137,
                "adminAddresses": [
                  "0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC"
                ]
              }
        }
      ]

The benefit of this approach is reusing the same configuration types in precompileUpgrades as in genesis.

Alternative:
Use a map like “timestamp”: [ {change} ] then overriding blockTimestamp in each config. Downside will be special handling of omitempty for blockTimestamp in genesis vs. upgradeBytes.

Alternative 2:
Special parsing for Unmarshalling JSON into an array of configs with special case handling when there is only one present vs. an actual array for backwards compatibility. This is a little gross, so very open to alternatives here, but not sure what the best path forward is.

DB Spec and Startup

On startup, the VM is passed in genesisBytes and upgradeBytes. The genesisBytes passed into the VM will always be the same throughout the lifetime of the chain.

upgradeBytes should be used to configure the timing of network upgrades without changing the code.

When subnetEVM starts up, it should read in the upgradeBytes and verify that it is compatible with the genesis chain config and previously applied upgradeBytes that is currently on disk. If it’s not, this should return a fatal error.

If the config is compatible with what’s on disk, then it may contain a new upgrade that is not present in the genesis chain config and previously applied upgradeBytes stored on disk. In this case, the upgradeBytes should be validated with CheckConfigForkOrder and overwrite what is currently on disk.

Where to store upgradeBytes?
Suggestion: Directly into a key in vm.db (eg, upgrade_bytes). Seems simple.

There are a few cases that we will want to make sure to handle:

• Compatible Upgrade that Occurs in the Future: If upgradeBytes contains a new upgrade that occurs at a future timestamp relative to the last accepted block, then it should overwrite the chain config stored on disk and go into effect
  After this, we should require that any upgradeBytes that were supplied once are always supplied in the same way
• Incompatible upgrade that occurs in the future
  If upgradeBytes contains a new upgrade that occurs in the future but is not compatible with the current chain config, then it should return a fatal error
• Attempt to perform an upgrade prior to the last accepted block’s timestamp
  Any new upgrade that occurs prior to the timestamp of the last accepted block should return a fatal error
• Delete upgrade that occurs in the future
  If there is a future upgrade stored on disk that has not activated yet, it is considered abortable.
  If upgradeBytes is set with an abortable upgrade removed from the parsed ChainConfig the chain will remove the abortable upgrade from the ChainConfig on startup
• Delete upgrade that has already occurred
  Will be considered a fatal error.

Enabling and disabling pre-compiles

When a new block is processed:

• Check if any upgrades are being enabled or disabled
• For all transitions that are occurring from the previous block to the current block:
  • If the upgrade enables a precompile:
    • Set the nonce for the precompile to 1
    • Set the code of the precompile to non-empty
    • Perform additional precompile specific state modifications
  • If the upgrade disables a precompile:
    • Suicide the address space for the precompile to prevent leaving certain allow-listed addresses in place to avoid any unintended consequences.

Enabling and disabling other features?

Open question: If we want to support changing allowFeeRecepients in upgrade bytes do we…
Support this as a fork with a blockTimestamp (then it cannot be disabled)
Support this as a precompile configuration
What details will be needed for this?

./scripts/run.sh 1.7.10 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC Responds with Failed to complie e2e

main module (github.com/ava-labs/subnet-evm) does not contain package github.com/ava-labs/subnet-evm/tests/e2e

Describe the bug
All versions of web3 are vulnerable to Insecure Credential Storage. The package stores encrypted wallets in local storage and requires a password to load the wallet. Once the wallet is loaded, the private key is accessible via LocalStorage. Exploiting this vulnerability likely requires a Cross-Site Scripting vulnerability to access the private key.

Recommendation

No fix is currently available. Consider using an alternative module until a fix is made available.
GHSA-27v7-qhfv-rqq8

Does the subnet-evm implementation contain any functionality for tracing transactions / checking state diff of transactions? This is very useful functionality when e.g. running an archive node for a chain. I see there's a TraceTransaction function in eth/tracers/api.go, but I can't see how this is exposed over RPC? I have enabled the debug-tracer in config.

During the WAGMI network upgrade, it was noticed that there was no log print-out on the timestamp of network upgrade. It would be helpful to print a message right after the timestamp to indicate an upgrade just happened and other related info.

Describe the bug
The DFK subnet-EVM process unclean shutdown will cause historical state regeneration. Regeneration will take a long time that downgrades the RPC service time.

To Reproduce
systemctl stop avalanchego or
docker stop avlalachego

Expected behavior
The DFK process starts quickly and provides RPC services immediately.

Screenshots

Logs

[09-08|02:30:54.480] INFO <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> snowman/transitive.go:327 shutting down consensus engine
2022-09-08T02:30:54.579Z [ERROR] plugin process exited: path=/opt/apps/dfk/bin/plugins/mDV3QWRXfwgKUWb9sggkv4vQxAQR4y2CyKrt5pLZ5SzQ7EHBv pid=435501 error="signal: terminated"
[09-08|02:30:54.581] ERROR <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> handler/handler.go:775 failed while shutting down the chain {"error": "rpc error: code = Unavailable desc = error reading from server: read unix @->/tmp/plugin3795322057: read: connection reset by peer"}

INFO [09-08|03:13:33.071] <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> github.com/ava-labs/subnet-evm/eth/backend.go:191: Initialising Ethereum protocol network=53935 dbversion=8
INFO [09-08|03:13:33.076] <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> github.com/ava-labs/subnet-evm/core/blockchain.go:521: Loaded most recent local header number=6,934,933 hash=24c903..5bba0f age=3m34s
INFO [09-08|03:13:33.076] <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> github.com/ava-labs/subnet-evm/core/blockchain.go:522: Loaded most recent local full block number=6,934,933 hash=24c903..5bba0f age=3m34s
INFO [09-08|03:13:33.076] <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> github.com/ava-labs/subnet-evm/core/blockchain.go:1442: Loaded Acceptor tip hash=24c903..5bba0f
INFO [09-08|03:13:33.077] <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> github.com/ava-labs/subnet-evm/core/blockchain.go:1450: Skipping state reprocessing root=5f8cf5..52aabb
INFO [09-08|03:13:33.078] <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> github.com/ava-labs/subnet-evm/core/blockchain.go:1424: Initializing snapshots async=true rebuild=true headHash=24c903..5bba0f headRoot=5f8cf5..52aabb
INFO [09-08|03:13:33.079] <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> github.com/ava-labs/subnet-evm/core/blockchain.go:388: Starting Acceptor queue length=64
WARN [09-08|03:13:33.084] <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> github.com/ava-labs/subnet-evm/internal/shutdowncheck/shutdown_tracker.go:63: Old unclean shutdowns found count=6
WARN [09-08|03:13:33.084] <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> github.com/ava-labs/subnet-evm/internal/shutdowncheck/shutdown_tracker.go:67: Unclean shutdown detected booted=2022-09-03T08:04:04+0000 age=4d19h9m
WARN [09-08|03:13:33.084] <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> github.com/ava-labs/subnet-evm/internal/shutdowncheck/shutdown_tracker.go:67: Unclean shutdown detected booted=2022-09-04T22:39:26+0000 age=3d4h34m
WARN [09-08|03:13:33.084] <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> github.com/ava-labs/subnet-evm/internal/shutdowncheck/shutdown_tracker.go:67: Unclean shutdown detected booted=2022-09-06T15:25:33+0000 age=1d11h48m
WARN [09-08|03:13:33.084] <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> github.com/ava-labs/subnet-evm/internal/shutdowncheck/shutdown_tracker.go:67: Unclean shutdown detected booted=2022-09-07T01:38:40+0000 age=1d1h34m
WARN [09-08|03:13:33.084] <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> github.com/ava-labs/subnet-evm/internal/shutdowncheck/shutdown_tracker.go:67: Unclean shutdown detected booted=2022-09-07T10:34:09+0000 age=16h39m24s
WARN [09-08|03:13:33.084] <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> github.com/ava-labs/subnet-evm/internal/shutdowncheck/shutdown_tracker.go:67: Unclean shutdown detected booted=2022-09-07T10:56:20+0000 age=16h17m13s
WARN [09-08|03:13:33.084] <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> github.com/ava-labs/subnet-evm/internal/shutdowncheck/shutdown_tracker.go:67: Unclean shutdown detected booted=2022-09-07T15:25:31+0000 age=11h48m2s
WARN [09-08|03:13:33.084] <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> github.com/ava-labs/subnet-evm/internal/shutdowncheck/shutdown_tracker.go:67: Unclean shutdown detected booted=2022-09-08T00:14:09+0000 age=2h59m24s
WARN [09-08|03:13:33.084] <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> github.com/ava-labs/subnet-evm/internal/shutdowncheck/shutdown_tracker.go:67: Unclean shutdown detected booted=2022-09-08T01:09:13+0000 age=2h4m20s
WARN [09-08|03:13:33.084] <q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi Chain> github.com/ava-labs/subnet-evm/internal/shutdowncheck/shutdown_tracker.go:67: Unclean shutdown detected booted=2022-09-08T02:26:12+0000 age=47m21s

Metrics
If applicable, please include any metrics gathered from your node to assist us in diagnosing the problem.

Operating System
Ubuntu 20.04 and Kubernetes env.

Additional context
Add any other context about the problem here.

Avalanche Bug Bounty program can be found here.

Context and scope
Make the fee recipient address updatable after genesis

Discussion and alternatives
Could be done as a precomile contract upgrade with an Allowlist or each update could be a network upgrade.

Open questions
...

Stateful precompiles currently require that the developer manually encode/decode arguments as per the ABI encoding schema: https://docs.soliditylang.org/en/latest/abi-spec.html. We should switch to using ABI arguments for encoding/decoding function arguments and return types: https://github.com/ava-labs/subnet-evm/blob/master/accounts/abi/argument.go.

The abigen command can be used to auto-generate golang binding for interacting with a smart contract, but we don't even need to go that far. We can do the following with this existing tool in order to create automatic generation of precompile configs and contracts available to users and make our own precompile development workflow significantly easier.

1. Parse a Solidity interface into the corresponding ABI
2. Generate a golang file containing the ABI as a variable
3. Generate the precompile config with a single block timestamp as the only type in the struct (named based off of Solidity contract name)
4. Iterate over the functions available in the contract ABI to create golang function stubs for each one, which will include the first line to use ABI unpack to unpack the input arguments into the expected inputs (add a line to pack the function return type as well at the end with nil values passed in to start)
5. Create a function stub for the fallback function if specified
6. Create a function to construct the actual stateful precompile at the bottom of the file

This should allow us to support the auto-generation of a fully stubbed out stateful precompile and take all of the hassle and difficulty out of packing and unpacking arguments and return types from the precompile developer.

Currently subnet-evm uses the notion of stateful precompiles to configure the state of a specific address at runtime and then expose a precompile with custom functionality.

Many times this custom functionality comes with an allow list to ensure only a specific set of addresses is allowed to access parts of the precompile's functionality eg. tx allow list and contract deployer allow list.

This ticket is to add the ability to create a one-off precompile that will configure the state when it is activated without exposing a precompile within the EVM execution.

This is intended to build on top of the fee config manager, so that a fee config update can go into effect by coordinating only a network upgrading and not requiring any admin address to be used. Therefore, instead of configuring an admin address to update the fee config, the precompile will actually perform a one-off fee config upgrade when it activates and there will be no trusted addresses.

We should create the functionality to perform a network upgrade that creates a contract at a given address.

Note: in order to make this as simple as possible for users, this precompile should use the binary of a contract and perform a create operation to store the resulting code in the state as opposed to simply setting the code explicitly, which may lead to unexpected behavior for users that expect normal contract initialization.

Currently many names can be used for subnet-evm. Let's decide on one and start using it as case sensitive. Some alternatives:

• subnet-evm
• Subnet-EVM
• Subnet EVM
• SubnetEVM
• subnet-EVM
• subnet EVM

We should change README in subnet-evm repo, documentation site and other places accordingly.

Create a PR template to add a new subnet to the networks/ directory to make it easier for people to make their subnet PRs and for us to review them in a standardized format.

Hello,

I am trying to create a local subnet using this tutorial: https://docs.avax.network/subnets/create-a-local-subnet.

I see a large number of errors when running inside a docker container, but not when running the code directly on my machine.

The errors all appear to be the same:

[node1] [06-02|02:25:59.939] WARN health/health.go:101 Failing health check: {"C":{"message":{"consensus":{},"vm":null},"timestamp":"2022-06-02T02:25:59.549122122Z","duration":13939},"P":{"message":{"consensus":{},"vm":{"primary-percentConnected":0.2}},"error":"platform layer is unhealthy reason: connected to 20.000000% of primary network stake; should be connected to at least 80.000000%","timestamp":"2022-06-02T02:25:59.549180581Z","duration":108784,"contiguousFailures":148,"timeOfFirstFailure":"2022-06-02T02:21:05.549196206Z"},"X":{"message":{"consensus":{},"vm":null},"timestamp":"2022-06-02T02:25:59.549154951Z","duration":5329},"bootstrapped":{"message":["X","P","C"],"error":"chains not bootstrapped","timestamp":"2022-06-02T02:25:59.549141235Z","duration":11967,"contiguousFailures":148,"timeOfFirstFailure":"2022-06-02T02:21:05.549075558Z"},"network":{"message":{"connectedPeers":0,"sendFailRate":0,"timeSinceLastMsgReceived":"459482h25m59.549199374s","timeSinceLastMsgSent":"459482h25m59.549199374s"},"error":"network layer is unhealthy reason: not connected to a minimum of 1 peer(s) only 0, no messages from network received in 459482h25m59.549199374s \u003e 1m0s, no messages from network sent in 459482h25m59.549199374s \u003e 1m0s","timestamp":"2022-06-02T02:25:59.549239066Z","duration":69760,"contiguousFailures":149,"timeOfFirstFailure":"2022-06-02T02:21:03.548121268Z"},"router":{"message":{"longestRunningRequest":"0s","outstandingRequests":0},"timestamp":"2022-06-02T02:25:59.549067566Z","duration":35061}}

The process finally fails with:

{"level":"warn","ts":"2022-06-02T02:26:02.622Z","caller":"server/server.go:367","msg":"start failed to complete","error":"context deadline exceeded"}
panic: context deadline exceeded

This occurs when I run ./scripts/run.sh 1.7.11 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC inside of the docker container.

The docker image is based on archlinux, but it works fine on my archlinux machine. I believe I am following exactly the same steps on both.

Any advice on how I can start solving this issue is appreciated. Perhaps I am missing something obvious?

Thanks!

We should add the WAGMI upgrade bytes to: https://github.com/ava-labs/subnet-evm/tree/master/networks/11111

This ticket is to create a tutorial for how to use a precompile once it has been activated from within Remix

Allow an address to pay fees on the behalf of another address. This should be implemented as a precompile that allows any address to "claim a dependent" to pay for. It is unclear what should happen if a single address is claimed by multiple sponsors.

We should make priority regossip addresses exempt from tx pool eviction (even if NoLocals=true). Otherwise, there is now way to extend the number of slots allocated to these "special addresses" without disabling all tx pool eviction/extending account slots for all addresses.

Describe the bug

file scripts/parser/main.go doesn't exist anymore but still used here https://github.com/ava-labs/subnet-evm/blob/master/scripts/run.sh#L274

#252 (comment)

Some subnet creators want to limit the addresses that can deploy contracts to a pre-defined list.

Right now, all fees are burned instead of being distributed to some address. This is a common request for subnet builders and shouldn't be too hard to add (genesis config boolean + node config with recipient). As long as there is no block reward, this shouldn't be too gameable by validators (they'll try to produce the largest block they can at the time before their snowman++ window expires and try to propagate pretty quickly to reduce orphan risk).

This ticket is to create a trustless fee config update, so that a fee config update can be performed without using an admin address on the current fee config manager.

Ideally, this ticket will be a backwards compatible modification to the current fee config manager precompile to support performing the network upgrade when it activates and not setting any admin addresses in the config, so that the entire upgrade can be performed by coordinating a network upgrade.

Current transaction allow lists are purely additive (permission-based, no "deny" rules).

The opposite can be useful to deny transactions from a set of addresses -- opposite of tx allow list configuration:

Implementation should be basically the same as tx allow list (@aaronbuchwald)

ref.