At the moment, the InterchainGasCalculator in the SDK is still written with the expectation that checkpoints are cached, and "real" token exchange rates are not fetched from anywhere when calculating interchain gas payments. The constants in the calculator, like the multipliers and gas costs, should probably be reconfirmed as well
We should:
Rewrite the calculator to not calculate destination gas costs with the assumption that checkpoints will be cached. Specifically, this would involve running some benchmark tests on the contracts to understand what the actual gas overhead of our new non-cached-checkpoint logic is, ensuring that intrinsic gas on the destination chain is only considered once (because now there is only a single transaction to process a message, not two as it was previously), and generally making sure that the code is written for non-cached-checkpoints on the destination.
Some destination gas costs are very dependent upon the quorum threshold of the validator set. Because we expect this to change sort of frequently in the short term as we expand our validator set, we ideally shouldn't have this hardcoded so that we don't need to re-release an SDK (and have developers update their SDK) every time the validator set's quorum threshold is changed. The calculator should therefore perform a view call to the InboxValidatorManager.threshold() function to determine the quorum threshold.
"Real" exchange rates when using mainnet networks are currently not fetched by the DefaultTokenPriceGetter when determining the interchain gas payment. We should update this to fetch exchange rates from CoinGecko (if you have a more trustworthy source in mind, feel free to suggest, I've personally found CoinGecko to be really pleasant to work with & it doesn't require any API keys). Longer term we may want to reach out to a number of APIs for some fault tolerance, but in this initial version let's just keep the scope as small as possible. There are probably some Node.js packages out their for easily getting CoinGecko prices, otherwise fetching them and parsing JSON is a reasonable approach.
For testnet networks, as we know all testnet tokens are not necessarily equal in value (some are harder to get & some testnets have very different gas cost magnitudes). For now, I think we should just hardcode exchange rates between the testnets that we support on testnet2 based off some ballpark estimates. For each pair of testnet networks, look at the gas price in gwei that transactions are using (look at our relayers if you're looking for a specific example). If testnet A txs tend to use a gas price of 10 gwei and testnet B txs tend to use a gas price of 5 gwei, the price of testnet B tokens quoted in testnet A tokens should be 2. I believe this is a better solution than a hardcoded 1:1 exchange rate for all testnets, because e.g. gas prices on OptimismKovan are much much lower than something like BSC testnet. If we force a 1:1 exchange rate, I worry developers will stop using the InterchainGasCalculator in their testnet environment out of convenience, and then they risk also not using it on mainnet while we don't have GRR support
For now, we should continue to just support interchain gas calculations for provided destination gas limits or message bytes. Anything more complicated may be ergonomic for devs, but we should limit scope and wait for feedback on what's actually desired
The desired end state here should be that the InterchainGasCalculator is in a spot where we're comfortable telling people to use it on testnet and mainnet, and it works as we'd expect
tkporter
commented
2 years ago
At the moment, the InterchainGasCalculator in the SDK is still written with the expectation that checkpoints are cached, and "real" token exchange rates are not fetched from anywhere when calculating interchain gas payments. The constants in the calculator, like the multipliers and gas costs, should probably be reconfirmed as well
We should:
InboxValidatorManager.threshold()function to determine the quorum threshold.DefaultTokenPriceGetterwhen determining the interchain gas payment. We should update this to fetch exchange rates from CoinGecko (if you have a more trustworthy source in mind, feel free to suggest, I've personally found CoinGecko to be really pleasant to work with & it doesn't require any API keys). Longer term we may want to reach out to a number of APIs for some fault tolerance, but in this initial version let's just keep the scope as small as possible. There are probably some Node.js packages out their for easily getting CoinGecko prices, otherwise fetching them and parsing JSON is a reasonable approach.testnet2based off some ballpark estimates. For each pair of testnet networks, look at the gas price in gwei that transactions are using (look at our relayers if you're looking for a specific example). If testnet A txs tend to use a gas price of 10 gwei and testnet B txs tend to use a gas price of 5 gwei, the price of testnet B tokens quoted in testnet A tokens should be 2. I believe this is a better solution than a hardcoded 1:1 exchange rate for all testnets, because e.g. gas prices on OptimismKovan are much much lower than something like BSC testnet. If we force a 1:1 exchange rate, I worry developers will stop using the InterchainGasCalculator in their testnet environment out of convenience, and then they risk also not using it on mainnet while we don't have GRR support