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

Merge VerificationBase into JsonTxBuilderBase #427

Open
sebastianst opened this issue Dec 19, 2024 · 0 comments
Open

Merge VerificationBase into JsonTxBuilderBase #427

sebastianst opened this issue Dec 19, 2024 · 0 comments

Comments

@sebastianst
Copy link
Member

Task sep/026 introduced a reusable verification framework to reduce the work of writing, maintaining and reviewing individual verification scripts. Part of this framework is a small VerificationBase contract

contract VerificationBase {
    address[] public allowedStorageAccess;
    address[] public codeExceptions;

    function addAllowedStorageAccess(address addr) internal {
        allowedStorageAccess.push(addr);
    }

    function addCodeException(address addr) internal {
        codeExceptions.push(addr);
    }
}

It provides two dynamic arrays in storage to allow for verification modules to add their respective allowed storage accesses and code exceptions. This allows for a more modular management of these addresses than the static overrides of getAllowedStorageAccess and getCodeException.

I propose that we just merge this contract into JsonTxBuilderBase, and set its getters to just return those arrays, instead of setting default virtual getters that revert. The getters can still be virtual so that they can be overridden, which mostly provides backwards compatibility for the old pattern where individual tasks had to override the getters. I don't see a security risk from providing a default way to add accesses and exceptions via the add... functions. After all, adding these only makes checks more permissive.

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

1 participant