You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, I've been looking over the codebase the last few days and I noticed you could use some help optimizing the contract so that it may be better suited for a production environment. To get us started, I thought I'd first start by listing some potential solutions:
I'm not entirely sure, but I think most of the arithmetic can be unchecked. (NOTE: where underflow/overflow is impossible or not possible in realistic conditions)
Storage can be optimized/packed into less slots since most of mutable state is updated together.
// single storage slot, rather than 3uint32private latestBlockTime; // equal to lastBlockTime % 2**32uint112private latestBlockHeight;
uint112private expectedTarget;
// can these be simplified or condesed?mapping(uint256=>bytes32) private blockHeightToHash;
mapping(uint256=>uint256) private blockHeightToTotalDifficulty;
SLOADs can be avoided, consider caching state variables in memory before using them several times in a function.
A rewrite in inline assembly or yul+ could potentially provide some benefit as well.
P.S. Feel free to send questions my way!
The text was updated successfully, but these errors were encountered:
// can these be simplified or condesed?
mapping(uint256 => bytes32) private blockHeightToHash;
mapping(uint256 => uint256) private blockHeightToTotalDifficulty;
BTC hash is 256 bit long, so that is one slot gone, Difficulty could fit in a 48bit uint
The biggest single cost before was the 20k gas per block to open a new storage slot.
I've optimized that using a ring buffer--by only storing the last n (eg n=1000) blocks, after the initial n blocks to fill the array, we pay only 3k gas per block, because we're overwriting an existing storage slot.
Hello, I've been looking over the codebase the last few days and I noticed you could use some help optimizing the contract so that it may be better suited for a production environment. To get us started, I thought I'd first start by listing some potential solutions:
SSTORE2 could potentially be implemented
I'm not entirely sure, but I think most of the arithmetic can be unchecked. (NOTE: where underflow/overflow is impossible or not possible in realistic conditions)
Storage can be optimized/packed into less slots since most of mutable state is updated together.
SLOADs can be avoided, consider caching state variables in memory before using them several times in a function.
A rewrite in inline assembly or yul+ could potentially provide some benefit as well.
P.S. Feel free to send questions my way!
The text was updated successfully, but these errors were encountered: