Shouldn’t this support also erc-1271? As audit company it would make sense to have a smart account, instead of an EOA.
This is considered and mentioned in the ERC under “SignatureTypes” (see here)
I recently wrote a deep dive on ERC-7512 for anyone interested in a comprehensive overview of the cases for and against the proposal (thanks to everyone who contributed to the discussion thread–found many of the insights useful during my research): ERC-7512: Bolstering Smart Contract Security With Onchain Audits
Another possible initial step, rather than doing audits (which are complex) do DeFiSafety protocol reviews. These are fixed format, have a pass/fail and are designed for reading by the general public. This could be implemented quickly with audits brought in later. An example report is at : Liquity - detailed report | DeFiSafety
1 Like
While we’re here, it seems like we might as well provide the bytecode hash as part of the onchain representation so that users of these systems can verify that the deployed code matches the code that was audited.
This could be represented as an array of structs containing the address of the contract and its corresponding bytecode hash.
2077 Research’s analysis of ERC-7512 suggested extending ERC-7512 to aggregating information about other security measures (e.g., bug bounties and formal verification) vs. providing only audit data to investors doing due diligence on protocols.
The article even mentions DeFi Safety’s protocol reviews as an example of how this idea can be implemented, with the caveat that the product has switched to a subscription model vs. as being publicly accessible (which was the case circa 2022 IIRC). Here’s the relevant quote from the article’s conclusion:
ERC-7512 moves us a step closer to building trust in on-chain applications and may inspire more efforts to standardize other aspects of the security review process. For instance, given projects now increasingly adopt a “defense-in-depth” approach to protocol security—bug bounties, formal verification, audit contests, incident monitoring, and more—a system that aggregates (verifiable) information about a project’s various security measures in the same location (as opposed to this information being fragmented across multiple websites and dashboards) would do wonders for investors, users, business development (BD) teams conducting due diligence for DeFi protocols. (DeFi Safety used to have a similar service but recently switched to a revenue model.).
2 Likes
@cylon56 I think this ERC should rely on address.codehash instead and/or on smart-contract based signatures (dependency on ERC-1271).
That would be much more generic solution, allowing re-deployment of code without requiring audited signatures.
Rationale
1. Byte code signing could simplify on-chain verification bytecode security:
Contract deployer does not need to supply any audit data at all. Existing contracts can be easily incorporated to this ecosystem by signing their code.
All signatures for all auditors can be stored in same registry that simply maps byte code hash to signer addresses mapping.
2. Verified state management is better done off trough Factory contract
While use of address.codehash obviously limits auditor responsibility to the state only, It also breaks down audit to pieces, and leaves state verification to be a mission on it’s own.
For example in diagram below we can see that stateful audit can be implemented in form of Trusted Factory. Such design would require less Bridge Operator actions and hence eventually would likely to surpass current form of this ERC.
Even already deployed code contracts could be enlisted by auditors manually adding signature for such contracts or having their own logic, paving way for ERC1271.
NB: in diagram above I assume calldata signed by auditor for factory can be factory-specific instructions, not a particular constructor arguments.
3. More secure
Compilers are the point of failure, signing compiled byte code is intrinsically more solid
4. Revokable
Since signatures are issued for a bytecode, not a contract, audits registry becomes more powerful as in case of disclosed vulnerability, auditors may just use nonce like system to invalidate their signatures.
1 Like
Also, the trusted source makes total sense to implement via EAS
To be not a empty-worded, here is my reference implementation for how I envision this working with byte-code level: