Optimize IpRoyaltyVaultStorage struct

[Vectorized]

struct IpRoyaltyVaultStorage {
    address ipId;
    uint32 unclaimedRoyaltyTokens;
    uint256 lastSnapshotTimestamp;
    mapping(address token => uint256 amount) ancestorsVaultAmount;
    mapping(address ancestorIpId => bool) isCollectedByAncestor;
    mapping(address token => uint256 amount) claimVaultAmount;
    mapping(uint256 snapshotId => mapping(address token => uint256 amount)) claimableAtSnapshot;
    mapping(uint256 snapshotId => uint32 tokenAmount) unclaimedAtSnapshot;
    mapping(uint256 snapshotId => mapping(address claimer => mapping(address token => bool))) isClaimedAtSnapshot;
    EnumerableSet.AddressSet tokens;
}

can be rewritten as:

struct IpRoyaltyVaultStorage {
    address ipId;
    uint32 unclaimedRoyaltyTokens;
    uint40 lastSnapshotTimestamp;
    mapping(address token => uint256 amount) ancestorsVaultAmount;
    mapping(address ancestorIpId => bool) isCollectedByAncestor;
    mapping(address token => uint256 amount) claimVaultAmount;
    mapping(uint256 snapshotId => mapping(address token => uint256 amount)) claimableAtSnapshot;
    mapping(uint256 snapshotId => uint32 tokenAmount) unclaimedAtSnapshot;
    mapping(uint256 snapshotId => mapping(address claimer => mapping(address token => bool))) isClaimedAtSnapshot;
    EnumerableSet.AddressSet tokens;
}

This saves a storage slot.

If you want to save 2 more slots for the majority of the case (e.g. tokens is small), I have add a drop-in replacement for EnumerableSet.AddressSet in Solady v0.0.191. It's under EnumerableSetLib.AddressSet. It has been heavily fuzz tested, but not audited.

[jdubpark]

We expect tokens size to be small, e.g. USDC, USDT, and WETH. Thanks for the alternative, please review cc @Spablob

For uint40 lastSnapshotTimestamp, any caution on casting between block.timestamp and uint40?

[Ramarti]

We could also do condense the nested mappings into 1 level by hashing

mapping(uint256 snapshotId => mapping(address token => uint256 amount)) claimableAtSnapshot;

becomes

mapping(bytes32 key => uint256 amount) claimableAtSnapshot;

with the key being

keccack256(abi.encode(snapshotId, token, amount ))

[Spablob]

We expect tokens size to be small, e.g. USDC, USDT, and WETH. Thanks for the alternative, please review cc @Spablob

For uint40 lastSnapshotTimestamp, any caution on casting between block.timestamp and uint40?

Would keep it as ERC20 has - uint256. In future, we could be whitelisting a token that may need it?

[Spablob]

We expect tokens size to be small, e.g. USDC, USDT, and WETH. Thanks for the alternative, please review cc @Spablob

For uint40 lastSnapshotTimestamp, any caution on casting between block.timestamp and uint40?

agree with timestamp being uint40

[Spablob]

We could also do condense the nested mappings into 1 level by hashing

mapping(uint256 snapshotId => mapping(address token => uint256 amount)) claimableAtSnapshot;

becomes

mapping(bytes32 key => uint256 amount) claimableAtSnapshot;

with the key being

keccack256(abi.encode(snapshotId, token, amount ))

After further measurements by @ Ramarti we decided not to make this change