I’m looking for a way to give users a guarantee that they will always be able to see key state changes in certain canisters - is this possible?
There is currently no way to call from a canister to outside the Internet Computer, if that is what you mean. If you are programming a web application that wants to show live data from the a canister, you have to resort to polling (using
query calls, presumably) for now.
Hm I see - thanks.
On Ethereum, the “Event” construct enables smart contracts to basically log and publish an activity with defined parameters within a function, to a shared, Ethereum-wide, immutable logbook available independently of the given contract and instead through the EVM itself (I suppose), which can be queried by anyone at any time in connection with the contract (for convenience, using Etherscan, for example). An Event looks something like the following: “Transfer(address _from, address _to, bytes _symbol, uint _amount).”
That users can see written in the contracts they use that key functions publish (“emit”) these Events means that users can rest assured that they will always be able to see when key state changes take place and what caused them, in a completely decentralized way. This gives teeth to important governance mechanisms like time locks, e.g. to manage the risk of abuse in case of governance capture.
For example, if a dominant token holder were to commit a potentially self-serving state change to the detriment of the broader group of given token holders without anyone knowing, then even a time lock on that function would be useless. But time locks in combination with published Events can deter abuse in case of governance capture, for example, by giving other holders a chance to react before a change would go through, and often thereby rendering abusive behavior counter to the dominant holder’s self-interest in the first place, helping to align holder interests. (To partially achieve the same effect, token holders could periodically poll all important state variables of course; but this would be at least less efficient, and also in many cases less informative, as the cause of any change may not be detailed.)
Fully recognizing the priority to ship shortly what promises to be the revolutionary platform that is the IC, I might at this point ask that a construct like Events be considered among other feature requests for potential inclusion in the future.