Cover ✅: Code Verification for Canisters on the Internet Computer as an Open Internet Service
Today we’re presenting an alpha release of Cover (short for Code Verification). A new addition to the Psychedelic collective, an open internet service for canister code verification, with an open registry of verified canister code on a per-build basis.
Developers can easily integrate Cover into their developer workflow so that, each time they create a new WASM for a canister, it can be sent to Cover’s registry with its build information (repository, build log, etc…), where it will be available publicly. That information can be compared to the live canister to ensure the live implementation matches the code/WASM the developer submitted publicly (verified ✅).
If there is a mismatch (e.g. the developer made a silent update without notifying cover, or used a modified or potentially malicious version) then the canister is unverified and using undisclosed code. Anyone can query this information to check themselves, or show in UIs if a canister is verified or not by Cover.
As stated, this is an alpha release ✨ so that developers can start to play around, test the general Cover architecture during the weekend, and provide feedback to us! The alpha registry shouldn’t be considered dependable yet. We will follow-up next week with a release that will include the permissioning ruling necessary to ensure all submissions are fully trusted.
Cover: Code Transparency on the IC 🥽
In these early stages of the Internet Computer, many standards and safe practices are currently in active development and discussion. From token and NFT standards, to new contract/canister implementations, infrastructure, and so on.
In this context, safety practices and checks like code audits have not been developed or tied to standard practices yet. Ensuring code is not malicious, or asserting the code a developer shared matches the live canister’s implementation mostly depends on trust. Especially given the fact that once live, a canister’s WASM code isn’t exactly auditable.
So, how can we begin developing a safety and transparency net on the Internet Computer to avoid malicious actors, if we can’t see the live canister’s code? With Cover we are taking the first step by creating a transparent registry of verified and open code.
To promote more trust in their project, and code, developers can use Cover to adopt an open and transparent building flow. Where, at the same time as they publish a new canister, or change the WASM of an existing one, they can pass along the builds, WASM, and repository details to Cover’s registry, where a registry is kept per-canister (by Canister ID) of each new build submitted.
With this information, which includes the unique hash/checksum of the WASM file (unique to the code it includes), Cover can compare the submission to the live canister’s code, and see if it indeed matches ✅ what the developer disclosed.
The First Steps Into Trust(less) 🤝
With this, we hope to push transparent developer practices forward on the Internet Computer, where we do not rely on trusting the open source code is accurate, but eliminate the trust layer by confirming that code is indeed the one being utilized. Something that, with the development of DeFi, NFTs, and other services on the IC, will be a must to avoid malicious actors.
We intend for Cover to grow into a flexible and automated workflow for anyone to integrate to ensure, regardless of the volume of canisters created, they can be openly verified.
We’ll give the example ourselves there to continue building trust in Psychedelic’s projects, like CAP (verifying all NFT/Token history canisters), in DAB’s NFT, Token, and Canister lists (showing verification status for each item), and in Dank (verifying XTC’s canister, and new tokens spawned by Dank… More on that soon! 😉).
How does Cover work? 🧠
The open internet service is fairly straightforward in terms of architecture. There are two main components in Cover.
First, the Cover registry, which receives version/build submissions from developers that are associated to a Canister ID (the canister to which they should be compared with).
Secondly, the Cover GitHub Action, or the “entry point” through which developers make their submissions to the Cover registry. Developers can integrate this action to their development workflow for their canister’s WASM, and the GitHub action will take a snapshot of the the build (CanisterID, Checksums, etc.) that will be sent & kept in Cover’s registry for verification.
Simple as that! Anyone can then use Cover’s APIs to query and check a Canister ID’s verification status/records in Cover, and compare the data to the live canister to see if it matches (verified) or not (unverified).
Start Using Cover: Verify a Canister 🧰
Cover is live on mainnet and both developers can start using it to verify their canister’s code on the registry; or any third-party can query Cover to check a canister’s verification status and records!
The Road out of Alpha? Permissioning 🔒
This first version of Cover is an early iteration that will help us gather feedback, and further develop and toughen up our implementations, including permissioning when it comes to filtering submissions.
In this alpha, we are taking the first step in Cover’s architecture, solving submissions and the registry per-se. To move out of this alpha state, where submissions can be openly made to any canisters (which is part of the testing phase), we are going to follow up with a permissioning/security layer.
We’re experimenting different options/alternatives to filter and regulate submissions, both to protect a canister’s owners trust, and the Cover service itself. Using feedback from this release as a reference, we will make a follow-up release to improve Cover and add the first version of this functionality/check.
Until Next Time 👋
That’s all for Cover’s V1! We can’t wait to hear feedback from developers on the ecosystem, and start receiving the first verification submissions to Cover.
We’ll continue building this first version of cover openly, so feel free to hop on our Discord to discuss ideas, or open up discussions regarding trust and verification on the IC!
