Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

πŸ§™β€β™‚οΈ Outlining a path towards gas optimization #4

Open
0xClandestine opened this issue Sep 2, 2022 · 3 comments

Comments

@0xClandestine
Copy link

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.

    // single storage slot, rather than 3
    uint32 private latestBlockTime; // equal to lastBlockTime % 2**32
    uint112 private latestBlockHeight;
    uint112 private 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!

@speedmax
Copy link

@0xClandestine
That should work right? exactly uint256

    uint32 private latestBlockTime; // equal to lastBlockTime % 2**32
    uint112 private latestBlockHeight;
    uint112 private expectedTarget;
    // 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

struct Block { hash: byte32, difficulty: uint}
mapping(uint256 => Block) private blockHeightToBlock;

It may save a table of look up key, not sure how much overhead the struct would introduce.

@dcposch
Copy link
Owner

dcposch commented Nov 5, 2022

@0xClandestine i just saw this. Thank you!

This looks excellent.

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.

PR #6

@dcposch
Copy link
Owner

dcposch commented Nov 5, 2022

Combining latestBlockTime/latestBlockHeight is a good suggestion. I'll do that too.

After #6, we're already down to 11k marginal cost per block proven for a big batch. Doing that in addition should bring us to ~8k.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants