ava-labs / subnet-evm Goto Github PK
View Code? Open in Web Editor NEWLaunch your own EVM as an Avalanche Subnet
Home Page: https://docs.avax.network/subnets/create-a-fuji-subnet
License: GNU Lesser General Public License v3.0
Launch your own EVM as an Avalanche Subnet
Home Page: https://docs.avax.network/subnets/create-a-fuji-subnet
License: GNU Lesser General Public License v3.0
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.
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.
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
"feeConfig": {
"gasLimit": 20000000,
"targetBlockRate": 2,
"minBaseFee": 1000000000,
"targetGas": 100000000,
"baseFeeChangeDenominator": 48,
"minBlockGasCost": 0,
"maxBlockGasCost": 10000000,
"blockGasCostStep": 500000
}
Observe fee estimations work using Metamask/Core
Update feeConfig:
"feeConfig": {
"gasLimit": 35000000,
"targetBlockRate": 2,
"minBaseFee": 50000000000,
"targetGas": 100000000,
"baseFeeChangeDenominator": 48,
"minBlockGasCost": 0,
"maxBlockGasCost": 10000000,
"blockGasCostStep": 1000000
}
Expected behavior
Fee estimations should be updated accordingly
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).
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
...
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"
}
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.
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.
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.
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.
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.
This ticket is to create a tutorial for how to use a precompile once it has been activated from within Remix
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):
Implementation plan
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.
Some subnet creators want to limit the addresses that can deploy contracts to a pre-defined list.
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?
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.
Lines 698 to 703 in b98d745
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.
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
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.
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.
./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
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 have added json log format to coreth. We can port those changes to Subnet-EVM ad well.
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!
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.
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.
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.
Reserve the following addresses for future precompiles:
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
After creating a workable subnet, the admin cannot mint native coins.
I have add contractNativeMinterConfig
in the genesis.json
.
To Reproduce
genesis.json
referring to the genesis example.NativeMinterInterface
following the official document: Minting Native Coins.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
Metrics
N/A
Operating System
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.
We should add the WAGMI upgrade bytes to: https://github.com/ava-labs/subnet-evm/tree/master/networks/11111
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
PackOutput("funcName")
does not include the arguments that need to be packedcommon.Address{}
UnpackIntoInterface
instead of sometimes using abi.ConvertType
when there is a single parameterIt'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:
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.
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 blockTimestamp
s 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.
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:
When a new block is processed:
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?
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).
with the genesis containing contractNativeMinterConfig
and feeManagerConfig
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.
Download the pre-build avalanchego
and subnet-evm
.
Copy subnet-evm
to avalanchego-v1.7.16/plugins/<vmid>
Stop the running avalanchego
v1.7.14.
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
Metrics
N/A
Operating System
Additional context
N/A
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
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.
No fix is currently available. Consider using an alternative module until a fix is made available.
GHSA-27v7-qhfv-rqq8
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:
subnet-evm/params/precompile_config.go
Lines 275 to 284 in 9711be8
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.
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.
subnet-evm/plugin/evm/config.go
Line 112 in 368d291
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.