Address poisoning is suspected to be the cause. In other words, a trap was set in the system.
To prevent such traps, it’s important for humans to verify the source code before deployment, and if it’s OK, then deploy it. It’s crucial to be able to confirm that the deployed modules match what was deployed at that point in time.
On EVM chains and Solana, smart contract verification is possible. However, this alone is insufficient. There needs to be a way to verify the entire system, including the front-end and back-end.
With ICP, this is possible. As a killer use case for enterprises, could you please provide a mechanism that makes it easy to verify that the front-end and back-end modules are identical to the source code at the time of deployment?
On EVM (Ethereum Virtual Machine) chains like Ethereum, you can use tools like Etherscan to verify smart contracts. This allows anyone to view the source code of the smart contract as it was at the time it was deployed to the blockchain.
Having a similar verification mechanism on the Internet Computer (ICP) blockchain would be very useful. It would enable enterprises and users to easily confirm that the frontend, backend, and deployed modules match the source code that was deployed, providing transparency and helping prevent issues like the DMM Bitcoin hack where a “trap” was suspected to have been set in the system.
The ability to verify the entire system, not just smart contracts, is an important security and trust feature that ICP could potentially provide as a unique selling point for enterprise use cases. Enabling easy verification of frontend and backend code in addition to on-chain modules would give ICP an advantage in this area compared to EVM chains that currently only allow smart contract verification.
The issue with wasm hash is that the IC is powerful enough to build significant configurable state and virtual machines inside a canister. Using this, canister deployers can issue “configurations” after deployment that significantly change the behavior. For a real example, the Azel framework is completely based on a rust program(that would have a consistent wasm) that exposes a JavaScript vm that any code could be uploaded to, including code that steals all the tokens. Now, I don’t know the underpinnings of Azel and I know @lastmjs has this kind of stuff on his radar, so I’m not worried about Azel in particular(and maybe even dynamic code side loading is disabled), but about a non-Azel fork that does a switcharoo after deployment and completely changes the codebase in the vm without changing the wasm hash.
Note: Rust and motoko are not immune from this as any competent dev could mash together some kind of simple vm in those languages too.
For maximum safety you need an online compiler that only uses known-good and audited specifically for the IC components.
You can do a ton of cool stuff without that level of rigor, but once you start messing with tokens and value we may want to step up our game.(I’ve had “try to compile motoko with Azel in a canister” on my todo list since Jordan mentioned it might work a few months ago. Apparently, oCaml has a transpiler to js and that is what motoko playground uses for checking code…cycle limits may limit usefulnesss…but maybe we could get an expensive subnet just for compiling)
Yes with dynamic languages, so Azle and Kybra for example, you can just swap out the source code while the canister is still running. I say “can” as in it’s possible. Azle does this with its auto reload feature, and Kybra used to do it before the Wasm binary limit was lifted.
Neither CDK relies on this functionality for regular use at the moment, but could and I would guess probably will in the future. The Kybra book explained this caveat with the Wasm binary hash in the past.
Also Azle does allow you to execute Wasm binaries from inside of an Azle canister. You can compile those as well.
I think Motoko compiling does work, I tried it out with a basic example…or maybe I only executed Motoko in the interpreter? Not sure.
Some canisters (for example Internet Identity) have support for verifying builds, see e.g.:
The dashboard team has been considering adding support for verified canister builds, where the dashboard could link to the source. This is significantly more work than for something like Etherscan, because the IC canisters can be a lot more powerful than Ethereum contracts, and can have a significantly more complicated build process. There may also need to be some fees charged for this verification to prevent DoS attacks on the dashboard. @Dylan might be able to tell you more about what the status there is.
Also, @skilesare makes a good point. Knowing that the code was produced by some particular build process from some particular code base is a necessary first step, but it’s not enough to trust a canister; for full trust, you need to understand the build process, check the dependencies, and audit the code. Interpreters (such as Azle) add yet another layer of complexity and baggage that you need to verify. The best solution that I can think of for interpreters right now is for them to expose a hash of the “currently loaded” interpreted program (JS/Python source), so you could do the verification of the build of the interpreted program itself.