feat: read fee params from diamond proxy storage #44
Conversation
ZKS-77 Fee Params
Use storage to get fee params: https://evm.storage/eth/20313953/0x32400084c286cf3e17e7b677ea9583e60a000324/s#map AC:
|
|
I manually parsed the hex data from storage because I couldn't find a way to do it with Viem library tbh |
| @@ -7,6 +7,7 @@ import { | |||
| encodeFunctionData, | |||
| erc20Abi, | |||
| formatUnits, | |||
| Hex, | |||
There was a problem hiding this comment.
Oooh didn't know viem had this type. A little bit more semantically correct for some values than Address
| throw new L1MetricsServiceException("Failed to get fee params from L1."); | ||
| } | ||
|
|
||
| const strippedParamsData = feeParamsData.slice(2); // Remove the 0x prefix |
There was a problem hiding this comment.
This is nitpicking so feel free to ignore it but, what do you think about handling this with a regex replacing /^0x/ with an empty string instead of just doing slice(2)?
Assuming that this is not a performance intensive service, it might be better to specify that those two first characters we expect to slice are 0x and not something else, even if the return type is of Hex type. This way you are not "coupling" your implementation to EvmProviderService.getStorageAt as, right now, if for some reason the return type of that method is modified (or another return type is added), this method will keep doing its stuff with a potentially wrong value.
As an extra, you could remove the comment as the code would be self-explanatory.
There was a problem hiding this comment.
💯 i like the suggestion
| let cursor = strippedParamsData.length; | ||
| const values: string[] = []; | ||
|
|
||
| for (const value of Object.values(feeParamsFieldLengths)) { |
There was a problem hiding this comment.
This one is a little bit similar to one of the comments in a previous PR about data structures + their ordering and it's totally fine to keep it as it is, although I'd strongly suggest leveraging an array for this part of the code, as the order —if I understand this loop correctly— is extremely important (ie unordered feeParamsFieldLenghts could generate wrong values).
Arrays are structures that inherently have a defined order (universally, in other programming languages too); and although newest standards force Object.values to keep the order the keys were declared with, it feels a little bit weaker to me to express the idea of "this must be ordered".
There was a problem hiding this comment.
you're totally right, i wanted to reflect the object "field"->size but it's better an array with sizes in the correct order and just clarify with a comment the reason behind
| //See: https://github.com/matter-labs/era-contracts/blob/8a70bbbc48125f5bde6189b4e3c6a3ee79631678/l1-contracts/contracts/state-transition/chain-deps/ZkSyncHyperchainStorage.sol#L52 | ||
| export type FeeParams = { | ||
| pubdataPricingMode: number; | ||
| batchOverheadL1Gas: number; | ||
| maxPubdataPerBatch: number; | ||
| maxL2GasPerBatch: number; | ||
| priorityTxMaxPubdata: number; | ||
| minimalL2GasPrice?: bigint; | ||
| }; | ||
|
|
||
| // Define the lengths for each field (in hex digits, each byte is 2 hex digits) | ||
| /* | ||
| { | ||
| pubdataPricingMode: uint8 -> 1 byte -> 2 hex digits | ||
| batchOverheadL1Gas: uint32 -> 4 bytes -> 8 hex digits | ||
| maxPubdataPerBatch: uint32 -> 4 bytes -> 8 hex digits | ||
| maxL2GasPerBatch: uint32 -> 4 bytes -> 8 hex digits | ||
| priorityTxMaxPubdata: uint32 -> 4 bytes -> 8 hex digits | ||
| minimalL2GasPrice: uint64 -> 8 bytes -> 16 hex digits | ||
| } | ||
| */ | ||
| export const feeParamsFieldHexDigits = [2, 8, 8, 8, 8, 16] as const; |
🤖 Linear
Closes ZKS-77
Description
Read
feeParamsfrom Diamond Proxy Storage