Exec v2 scaffolding to observes prices/costs

[rstout]

Adds scaffolding to the V2 Exec Plugin to enable observing prices and costs (but does not yet observe these values). Once prices and costs are observed, message fees and costs can be computed, and messages with higher costs than paid fees can be filtered.

The core data type is PriceObservations:

type PriceObservations struct {
	// The price of Juels (the smallest denomination of LINK) in USD. Each CCIP message has a fee denominated in Juels.
	JuelPriceUSD cciptypes.BigInt `json:"juelPriceUSD"`

	// The price of gas in the destination chain, denoted in the native token of the destination chain
	GasPrice cciptypes.BigInt `json:"gasPrice"`

	// The price of the native token of the destination chain in USD
	DestNativeTokenPriceUSD cciptypes.BigInt `json:"destNativeTokenPriceUSD"`

	// Maps message IDs to the estimated gas cost of executing these messages
	MessageExecutionGasCosts map[string]cciptypes.BigInt `json:"messageExecutionCosts"`
}

The message fee in USD will be: message.jeuls * JuelPriceUSD * feeBoostFactor
The message execution cost will be GasPrice * MessageExecutionGasCosts * DestNativeTokenPriceUSD

[github-actions]

Test Coverage

Branch	Coverage
prices_observation	72.0%
main	72.0%

[makramkd]

Can we add two things to this comment:

• price is in USD, but how many decimals?
• where is this price expected to be fetched from? e.g which price registry / feed contract

[makramkd]

Small rename to be consistent w/ the rest of the codebase:

Suggested change

	// The price of gas in the destination chain, denoted in the native token of the destination chain
	GasPrice cciptypes.BigInt `json:"gasPrice"`
	// The price of gas in the destination chain, denoted in the native token of the destination chain
	DestChainFee cciptypes.BigInt `json:"gasPrice"`

Also, is this only execution fees or also data availability fees (like for L2's)? We should also state where this is fetched from, I believe in this case the source price registry. Make sure to update the comment to reflect this information as well.

[makramkd]

Similar to the juels comment, we need the number of decimals and the source of this information (I think in this case dest price registry)

[makramkd]

Estimated gas cost is a chain-specific metric, do we want this to be USD instead?

Also, if it is USD, include the decimals count in the comment.

[makramkd]

Also, for this mapping, I believe we can use cciptypes.Bytes32 as the key type to bring it home that this is a msg ID. JSON encoding/decoding is already implemented for this type.

[makramkd]

Is it really sufficient to just call this here? I believe the price observations are a mix of source and dest information, some nodes may have source info, some may have dest info, wouldn't we need to consensus-ify these values (median, etc.) and only then do the boosting on the medianized values?

[makramkd]

Or is this stuff going to be done in upcoming PRs?

[winder]

Medianizing is happening in the outcome phase based on these observations.

[rstout]

I believe the price observations are a mix of source and dest information

Minor point, but I believe everything should be on the dest chain.

wouldn't we need to consensus-ify these values (median, etc.) and only then do the boosting on the medianized values?

We do this consensus in mergePriceObservations in execute/plugin_functions.go

[winder]

I think you could leave this out. The prices would be empty by default on account of no price observations being present. Add a check to VerifiyObservation that there are no price observations when the flag is false.

[winder]

This all looks on track to me.