Hey there!
As you might know, I develop various IC libraries - this is what I like and how I contribute to the community.
So, I have this experimental thing for a while now
It allows your canister to run arbitrary wasm code uploaded dynamically. You can have a single “container” canister, that handles multiple dynamically uploaded (without canister upgrade) wasm-scripts (each of which, btw, can be more than <message limit> bytes in size) which are able to simultaneously modify the shared canister state and do everything a normal canister can.
Basically, lambdas.
The idea looks pretty neat to me, but I don’t know if someone else is also interested in such a functionality. And there are other things I can allocate myself to right now.
So, in this thread I need your opinion on whether it is a useful thing and you would love me to prioritize and finish it, or not.
That’s interesting, now is the goal to allow users of a deployed application to add, adjust, “basic” behavior or is it to provide an ecosystem to make lambdas? In the last case what would be the added value compared to making a motoko canister.
One last point: with a solution of this kind, don’t we break the characteristics of the smartcontract, which guarantees that, I can verify its algorithm and it cannot be altered?
Now is the goal to make it more functional. To add an ability to pass CandidType arguments to these scripts, to make them able to call various external ic-related functions (like manipulating storage or sending a message to another canister) and to create a sandboxing environment (so you could choose, whether or not a script can use some of the external functions).
Once this is done, such a library can be used to achieve any other goal, including providing an ecosystem for lambdas.
About guarantees. It is up to hosting canister. Nothing prevents you from storing a hash of an uploaded module and to check if this hash is the same that was acquired during the build procedure of this module.
Thanks for the answer, I remain a bit reserved on the notion of “integrity” of the smartcontract, because what you say implies that the application provider is honest or totally transparent. Let’s make an assumption, you produce a nice application that promises to respect some rules on data processing. In a “classical” environment, even if it is opensource, I don’t really have a way to check the respect of the commitments. With dFinity, if I’m motivated I can check that the source you publish is the code that is actually being executed in the canister, so there is a real added value of trust. If you can modify the algorithm afterwards, isn’t that a bias on one of the trust goals of the solution.
I find your idea very interesting but the fact that it is possible I wonder. Isn’t it an anomaly?
My message is not critical, your proposal simply makes me curious.
I don’t see any real difference with the way it works for the real canisters right now.
Right now there is no way for you to check whether a canister runs a program you expect it to run, except to compile this program from source by yourself and to compare hashes.
If the program is open source, it doesn’t imply that you run the same version of that program that you see in Github. There is only one way to guarantee that - deterministic compilation.
Yes but I can do it. I can get the hash of a running canister I don’t own dfx canister --network ic info qjoks-wyaaa-aaaab-qadsa-cai and verify it. I don’t know how to do the same thing with a microservice or a web application deployed on Azure, AWS, etc
This was just my thinking about this notion of trust in smartcontract. But I must admit I never did it with a canister application I use regularly.
Among other things, this is essential for interoperable immutability, or bringing permissionless style functionality to the IC. Thanks for making this available!
