flare-foundation / coreth Goto Github PK

Description

type validatorRegistry struct {
}

func (v *validatorRegistry) Run(evm *EVM, caller ContractRef, address common.Address, input []byte, gas uint64, read bool) ([]byte, uint64, error) {

	// TODO
	// 1) Initialize FTSO system around the EVM.
	// 2) Retrieve current reward epoch from EVM.
	// 3) Retrieve last reward epoch from FTSO system.
	// 4) Check against last validator list in precompiled contract state (just some DB wrapped around the EVM DB).
	// 5) If the reward epoch increased, retrieve all provider details and compute FTSO provider weights.
	// 6) If new weights calculated, insert into the DB (by epoch) and update latest epoch.
	// 7) If we stored a new latest epoch, set precompiled contract address' byte code to hash of validator state.
}

Source

Hello, I see you have forked avalanche coreth repo, I wonder to know, I want to run how to run avalanchego based on fork repo? The only things I need to do is replace all ava-labs into your repo name?thanks

We should properly inject the context logger into all validator-related components and do logging where appropriate to debug potential issues.

With the introduction of AP3/EIP-1559 a couple of new RPC calls have been introduced to estimate the required gas price. One of them is eth_feeHistory, that is the call used by MetaMask to calculate the low/market/aggressive priority gas prices on EIP-1559 enabled chains.

FTSO providers are encouraged to use a higher gas price to prioritize their transactions, with the assumption that most of the gas is automatically refunded by the system.

When combined, the result is that the eth_feeHistory call can return very high priority fee values at the end/start of a price epoch, as if all recent transactions had to spend a lot of gas to be included in a block, while actually most of gas was refunded. This deceives MetaMask that proposes absurdly high (and unneeded) priority fees to send transactions, ruining all the advantages of the dynamic fees introduced in AP3.

A solution might be to ignore or to normalize the gas used by transactions sent to the PriceSubmitter, in order to have meaningful values returned by eth_feeHistory.

For reference, this is the MetaMask code: https://github.com/MetaMask/controllers/tree/main/src/gas

Example:

The current keeper code is messy, and the tests are even more so. For example, the tests define one separate mock for every failure scenario, instead of using a generic mock. This would be a great candidate to refactor and make more robust.

The state connector has a mechanism to refund data providers for transactions to the price provider, if the transactions succeed.

This used the nominal fee for a normal transaction of tokens as a baseline, which was 21k gas with a gas price of 225M. However, with the hard fork we did, the minimum gas price was reduced to 25M instead. This means that data provider submissions are now 9 times as expensive as they should be.

We need to implement a mechanism to transition to the new gas price as part of the next hard fork.

We should create a default validators component that returns the default validators by epoch, rather than only be chain ID. That way, we can reduce the number of default validators after a certain point, which in turn allows us to shut down a good number of nodes. Rather than running 20 validators, we can only run 5 and save a bunch of costs.

For context, if there would ever be an issue with rewards being awarded for one reward epoch, or if all FTSO data providers would unset their validators, we would fall back to the default validators again.

In the params package, we already have a lot of hard-coded values, and then we have a couple of parameters sprinkled throughout the code base that depend on what hard fork we are on. We should factor all of that into a FlareConfig struct, potentially in the same package, that manages all of the hard-coded and fork-dependent values in a single location.

Description

Depends on precompiled validator registry logic being implemented already.

func NewFTSOSystem(evm *vm.EVM, addressSubmitter common.Address) (*FTSOSystem, error) {

	// TODO
	// 1) The `AtBlock` goes away, and we always work directly on the EVM handle.
	// 2) This means `FTSOSnapshot` goes away, as we work on a single snapshot.
	// 3) All calls related to `ValidatorRegistry` go away, because that's in the precompiled now.
	// 4) Should we move all this to the `core/vm` package with the precompiled contracts?

Source

Currently, we have nothing to check whether the smart contract byte code changes for the core contracts that get upgraded / created are properly applied to the chain state.

We should write code that initializes the state, and tests whether the byte codes get updated when the hard fork time is reached.

Currently, we can only mint a maximum of 50M, as dictated by the Flare Daemon. We need to increase this limit to 90M instead of 50M. It's given in the GetMaximumMintRequest function in keeper.go.

Like the other changes, this needs to activate as part of the upcoming hard fork.