I want to discuss why the source code for canisters on the Internet Computer (ICP) is kept private. Yesterday, while using some dApps on ICP, I noticed something felt off. I tried to check the canister’s source code, only to find that it was inaccessible; the dashboard only shows the candid interface and WASM hash. Without access to the source code, I can’t verify if the dApp is trustworthy or not.
The main concern is: if canister code isn’t publicly available, how can anyone trust their money or assets on these platforms? I understand that ICP’s “private by default” design principle aims to protect code privacy. However, the core of blockchain technology is transparency and user ownership of assets. Without knowing what’s happening in the canister it’s hard to trust it , also we can’t forget that the canister can be upgraded anytime and the controller can be changed too .
Hi Alsharif
I think it’s a good idea to think about which canisters to trust and why. I agree that publicly available canister code is a pre-requisite for many applications. This is also the reason why DFINITY submits proposals (see, https://dashboard.internetcomputer.org/proposal/134043 for a recent example) to upgrade protocol canisters come with a wasm hash and with instructions on how to build the canister from source to arrive at the same hash. The hash of a canister is publicly accesible by anyone, so it can be used to determine what exact code version is being run.
There are also applications which don’t want to reveal their source code with everyone. With publicly accessible wasm hashes, canister developers can select who to make source code and build instructions accessible to.
Well I did some research about this matter, to be honest at the start I was thinking that most of layer 1 Blockchains are showing the source code by default same as Ethereum, and I was thinking that’s why it might effect IC defi on the long term, but I found that there is some popular blockchains that not allowing anyone to see the code at all, but they still have very good defi ecosystem and everyone seems to trust it ( the public users can be strange some times ).
So I understand that this general purpose chain, and there might be some cases that need the code to be private.
But believe that we need someone to build some audit platform, that give certificate to any project that work on defi, security or any field that target users assets, as way to show the integrity.
And this platform work is to check your code after you make it open , and watch the upgrades and the controllers, and then they give audit report in plain English so even non technical users can read and understand.
Who knows maybe I will work in something like that
First off - It’s important to say to people who haven’t met me, I’m a big fan of ICP and have built hundreds of smart contracts on it… so this isn’t FUD.
I don’t know how many times this topic has to be brought up. Honestly I could explode with frustration with how little attention this is getting. Dfinity is doing a power of good work and delivering some really cool stuff, but we’re still lacking the basics in regards to core blockchain functionality.
Standards are getting there, but we should acknowledge that we’re years down the line and our delay has cost us dearly. (We’re going to repeat this with code visibility and suffer the same pain later on)
We can’t see the underlying blocks
We can’t see canister code/ WASM (even when the developer wants to share it)
Sure we can verify the wasm hash if the developer helps with via github (nice web2 dependency there!), but then every person who wants to check a canister would have to find, build and check the hash EVERY SINGLE TIME they want to use it. Are we really asking people to store all the WASM hashes for every smart contract they want to use and then manually check them? Is that really the future?
Given that a developer can update code in a few seconds (SNS aside) then basically there is no safe way for people to use non-SNS/ Dfinity canisters. We spend a lot of time talking about how un-hackable, un-stoppable and tamper proof ICP is - This is true as a protocol but if the application layer is total dog-shit then it doesn’t really matter.
I don’t want to get into the Motoko NFT thing… whatever happened here, neither side can quickly or easily show they are correct. This should be a warning and a wake up call for action.
WHAT DO WE NEED? Well just look at other blockchains, you can check a smart contract in a few seconds. Ideally we need a way of telling people who are interacting with an ICP canister that it’s verified. If the wasm differs from the published code then users should be warned of this.
Of course this should be an opt-in for developers. You can still have private code, but people can at least spot which canisters/ devs are being open and those that are not.
Thanks for bringing this up. This is a very important topic. And the verifiability of canisters needs to be solved.
For a point of reference, I don’t think other blockchains have this verifiability either. If there is one chain/ecosystem that has it nailed then please point us all to it and we can learn from it. In Ethereum for example you can get a smart contract‘s byte code from the chain. Admittedly, that’s more than a wasm hash but it does not help understand the smart contract. For some smart contracts the developer has uploaded the source code to Etherscan. Etherscan checks if the source code compiles to the byte code on chain and only then accepts it. As a verifier you can now read the source code. But you still have to verify yourself that it compiles to the on chain byte code. Or you have to trust Etherscan (a centralized website). That situation as a whole is more user friendly, but not fundamentally different or better than what we currently have on the IC. It is fundamentally the same.
That being said, the problem is real and needs to be solved. At MR Research we are working on some things in this direction. For example we are working on a standard docker image that makes it easy for anyone to reproduce builds. So that it is easy to verify the step from source code to wasm hash.
Then we are working on a canister that scrapes and preserves the complete history of watched canisters (controllers and wasm hashes). This platform also stores and provides reproducible build information. At this point we will have feature parity with Ethereum/Etherscan.
From there we have multiple options to go beyond that. For example if we can have an on-chain compiler then we can have a trustless unchain verifier. And nobody has to individually verify the build anymore. Or if we have a trustless system where known verifiers can attest to their verification results, that would also help.
Of course serious DeFi projects also need to consider making their canisters immutable (blackhole).
As a final note, keep in mind that even with all this kind of infrastructure in place you still need to be able to determine if the source code has bugs or not. Most likely you will rely on a small set of known people for that.
Implementing such a service on the IC would elevate the ecosystem to a whole new level. I believe this is one of the most critical issues to address at the moment, and I’m excited to see its progress.
Putting some code and slapping a verified badge is not going to cut it security-wise. It may calm users down and help them figure out if they are using open-source software, but that will be it.
Users won’t bother understanding the code unless it’s really simple and short
The ones who can understand it - like @timo has mentioned are very few
It takes weeks to go through the code to find bugs and vulnerabilities and it requires meticulously testing it, not just drinking a cup of coffee while browsing through the code.
Just checking the last deployed code won’t do it. The stable memory could have been altered by code 10 deployments ago. Someone has to check the code of every version from the beginning until now
The malicious code can be inside an imported third-party module. These also need to be checked
If the only benefit is that users can figure out if the app is open-source or not, then someone can just create an automated service that fetches a repo, builds, and compares to the deployed hash, providing the app with a badge image inserted at the bottom of a page that becomes red if the build fails and green if it matches. No need to put code inside the Dashboard.
Or, perhaps a browser extension that figures out automatically if the canisters being called are open-source and notifies the user.
Yourself and Timo make good points. This isnt a silver bullet, but like most things in security its about making it harder to cheat.
Crypto’s ethos is about being open and verifiable. Sure, not everyone has the skills to verify crypto transactions/ code - but when a memeber of the community sounds the alarm… its a lot easier for those with the skills to have a look.
Even if this was just an ‘optics’ thing… its still worth doing. We wonder why large parts of the crypto ecosystem doesnt take ICP seriously- while at the same time we ignore core crypto fundamentals. We then have the cheek to lecture other blockchains on their principles.
