pipermerriam
commented
7 years ago Thanks for posting this @seusher
Here are my thoughts.
Audits are not something that is machine readable, so anything beyond inclusion as metadata strikes me as being out of scope. I've opened https://github.com/ethpm/ethpm-spec/issues/68 which is intended to standardize inclusion of audit information in packages. With this, it is possible for tooling to filter based on the existence of an audit but I don't believe this is actually the correct route.
This is a problem I feel strongly must be solved as a layer on top of the ERC190 spec. Remember that package management is a multi-layered solution and it isn't likely a good idea to try and cram everything into just the ERC190 spec. Ultimately, the audit itself is not very valuable because end users are rarely going to actually read the individual audits.
Instead, I think the problem that needs solving here is based on reputation. With the current standard of centralized registries, reputation is fragmented since individual package authors can build reputation but the system as a whole is a mixed bag. The structure I'm trying to foster in the Ethereum package management ecosystem is to allow package aggregators as first class citizens. There is room for a company to come into the space and host a package index which contains only high quality audited packages.
Similarly, see https://github.com/ethpm/ethpm-spec/issues/67 which sets up a spec for signing packages. This would allow for tooling to do things like only accepting packages signed from trusted or reputable sources.
@pipermerriam - I suspect that discovery is going to be a difficult challenge when using the package manager once its become mainstream. To combat that, it seems reasonable to add standard metadata to every package which can provide an attestation that the package has been audited for safety and correctness, if it has been.
If you add the following:
I think it will drive better discipline in the smart contract development community, and avoid some of the mess we see in traditional package managers where people use libraries, but are unaware of what rigor has gone into ensuring they are as bug free as possible. It can also help prevent the types of attacks we see in the ICO process today, where people create similar URIs/addresses to trick people into sending Eth to the wrong place.
For example, if someone creates a reusable, safe, and audited library which is then published as a package to a registry, the design allows for others to host the same package in their own registry. I believe that the current idea is that the new registry will point to the same hash as the original one, but there isn't any enforcement for that. After a package becomes popular, it becomes more likely that someone will create a malicious version (with the same name and a different hash in their own registry) and attempt to convince people to use it, much like we see with ICO addresses today.
It seems useful to associate code with an auditor's signature, which can essentially be tied to some identity of that auditor. In that case, we have a distributed, authoritative way of knowing which 'Owned' contract is the one that has actually been tested, and which one is a malicious version.
As auditing becomes more automated and we have fewer humans performing audits, the signing could be replaced with a reputable automated auditing systems' signature.