Background In order to properly understand the proposal below, we need to first agree on some terminology. [Untitled drawing] As the drawing above shows, a canister smart contract can expose two types of functions, update functions and query functions. A canister can be called by external users o…

Just saying “possibly” to indicate that I wouldn’t consider it a blocker if we can’t support everything. Based on the paper abstract certainly sounds interesting. Not open access though and it’s too late today for my brain to process papers anyways. Did we discuss this paper before, when designing …

[image] jzxchiang: Is the only benefit of making a replicated query call that it’s more safe? For example, certificate (or certified variable) validation wouldn’t be necessary. Replicated queries are essentially calling https://sdk.dfinity.org/docs/interface-spec/index.html#http-query via an …

Something like that, with a generic (not application specific) way to relate the hash tree to the payload in the CandidStruct. So that, for example, Candid UI or ic.rocks can validate such responses from arbitrary canisters. Hmm, that seems to be a good criteria to evaluate solutions: is it express…

Could also be a good opportunity to defintely decide what information about a canister we would like to be private or public by default? there have been earlier discussions about this before. [image] Canister controller and cycle balance need to be public Developers …

@Fulco : good points. I agree these need to be addressed as well. This will significantly increase the scope of this RFC. Based on the discussions so far, I think I need to go back to the drawing board a bit on replicated vs. non-replicated queries. I have some vague ideas that I want to write d…

I was thinking about the above proposed API for read_state and how I was not happy with it. I ended up writing down my thoughts on why I am not happy with it. I am posting them here to keep the conversation going. No precise proposal yet. I think more discussions and design is needed here. Repl…

Good analysis! This bifurcation, making query methods no longer a restricted update method has always bothered me (certified variables, but also inter-canister calls). But just giving up and letting the developer deal with this even increased complexity isn’t a satisfying answer either. Isn’t a goal…

I agree, the goal should always be to not expose unnecessary complexity to the user. However, we should also avoid the temptation of pre-mature abstraction. In particular, in this case, maybe the complexity can be hidden by some language extension or a library. I would still like to experiment wi…

I morally agree with @nomeata ’s point that we should not make developers’ lives harder than necessary. But I also think that by using abstractions that do not quite fit, we did this already. The API for certification is one pretty good example. But there are more (meeting with @akhilesh.singhania ar…

[image] bjoern: like: Both good reasons to develop in the pure actor model and ditch this convenient but dangerous async stuff :slight_smile:

RFC: Standardising how smart contracts expose state

Developers

akhilesh.singhania January 19, 2022, 9:29am 23

Topic		Replies	Views
Wallet canister standards Developers Discussing	7	982	March 7, 2023
[Discussion] Data certification on IC Developers	6	1905	September 19, 2022
The biggest problem with the IC - InterCanister Calls Developers	26	3062	July 28, 2022
EVM RPC Canister Developers	70	6123	November 19, 2025
Tackling CertifiedData in Motoko Language Support Motoko	36	3067	August 18, 2022

RFC: Standardising how smart contracts expose state

Related topics