ERC-7512 - Onchain Representation for Audits

Created 2023-09-05
Status Draft
Category ERC
Type Standards Track
Authors
Requires

Proposal to define a contract parseable representation of Audit reports.

Abstract

The proposal aims to create a standard for an onchain representation of audit reports that can be parsed by contracts to extract relevant information about the audits, such as who performed the audits and what standards have been verified.

Motivation

Audits are an integral part of the smart contract security framework. They are commonly used to increase the security of smart contracts and ensure that they follow best practices as well as correctly implement standards such ERC-20, ERC-721, and similar ERCs. Many essential parts of the blockchain ecosystem are facilitated by the usage of smart contracts. Some examples of this are:

The usage and impact smart contracts will have on the day-to-day operations of decentralized applications will steadily increase. To provide tangible guarantees about security and allow better composability it is imperative that an onchain verification method exists to validate that a contract has been audited. Creating a system that can verify that an audit has been made for a specific contract will strengthen the security guarantees of the whole smart contract ecosystem.

While this information alone is no guarantee that there are no bugs or flaws in a contract, it can provide an important building block to create innovative security systems for smart contracts in an onchain way.

Example

Imagine a hypothetical ERC-1155 token bridge. The goal is to create a scalable system where it is possible to easily register new tokens that can be bridged. To minimize the risk of malicious or faulty tokens being registered, audits will be used and verified onchain.

Onchain Audit Example Use Case

To illustrate the flow within the diagram clearly, it separates the Bridge and the Verifier roles into distinct actors. Theoretically, both can live in the same contract.

There are four parties:

As a first (1) step, the bridge operator should define the keys/accounts for the auditors from which audits are accepted for the token registration process.

With this, the user (or token owner) can trigger the registration flow (2). There are two steps (3 and 6) that will be performed: verify that the provided audit is valid and has been signed by a trusted auditor (4), and check that the token contract implements the bridge's supported token standard (ERC-1155) (7).

After the audit and token standard validations have been performed, it is still advisable to have some form of manual intervention in place by the operator to activate a token for bridging (10).

Once the token has been activated on the bridge, Users can start bridging it (11).

Specification

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Audit Properties

Auditor Verification

Data types

struct Auditor {
    string name;
    string uri;
    string[] authors;
}

struct Contract {
    bytes32 chainId;
    address deployment;
}

struct AuditSummary {
    Auditor auditor;
    uint256 issuedAt;
    uint256[] ercs;
    Contract auditedContract;
    bytes32 auditHash;
    string auditUri;
}

Signing

For signing EIP-712 will be used. For this the main type is the AuditSummary and as the EIP712Domain the following definition applies:

struct EIP712Domain {
    string name;
    string version;
}

EIP712Domain auditDomain = EIP712Domain("ERC-7652: Onchain Audit Representation", "1.0");

The generated signature can then be attached to the AuditSummary to generate a new SignedAuditSummary object:

enum SignatureType {
    SECP256K1,
    BLS,
    ERC1271,
    SECP256R1
}

struct Signature {
    SignatureType type;
    bytes data;
}

struct SignedAuditSummary extends AuditSummary {
    uint256 signedAt;
    Signature auditorSignature;
}

Rationale

The current ERC deliberately does not define the findings of an audit. Such a definition would require alignment on the definition of what severities are supported, what data of a finding should be stored onchain vs off-chain, and other similar finding-related attributes that are hard to strictly describe. Given the complexity of this task, we consider it to be outside the scope of this EIP. It is important to note that this ERC proposes that a signed audit summary indicates that a specific contract instance (specified by its chainId and deployment) has undergone a security audit.

Furthermore, it indicates that this contract instance correctly implements the listed ERCs. This normally corresponds to the final audit revision for a contract which is then connected to the deployment. As specified above, this ERC MUST NOT be considered an attestation of a contract's security but rather a methodology via which data relevant to a smart contract can be extracted; evaluation of the quality, coverage, and guarantees of the data is left up to the integrators of the ERC.

Further Considerations

Future Extensions

Backwards Compatibility

No backward compatibility issues have been identified in relation to current ERC standards.

Reference Implementation

TBD.

The following features will be implemented in a reference implementation:

Security Considerations

Auditor Key Management

The premise of this ERC relies on proper key management by the auditors who partake in the system. If an auditor's key is compromised, they may be associated with seemingly audited or ERC-compliant contracts that ultimately could not comply with the standards. As a potential protection measure, the ERC may define an "association" of auditors (f.e. auditing companies) that would permit a secondary key to revoke existing signatures of auditors as a secondary security measure in case of an auditor's key compromise.

Copyright

Copyright and related rights waived via CC0.