We are working on some ideas around pseudo randomness for ULIDs and UUIDs and it occurred to me that it would be really nice to have some exposure to the message ID that is currently being processed as input for creating pseudo-randomness. Something like Hash.hash(Principal.fromActor(this), Time.now(), msg.messageID) would produce a ‘good enough’ randomness for most applications. I understand that after an await this value might change? But maybe that is a good thing.
1 Like
When designing the system interface (and the conceptual programming model), it was a design goal to insulate the programming from implementation details of the underlying system.in particular stuff like blocks are clearly implementation details (although back then were framing the system as not a blockchain, so maybe we would do it differently now?).
So I still don’t recommend exposing data. Instead, of you need pseudo randomness, maybe request a synchronous access to pseudo randomness from the system, so that the API stays declarative.
That would work as well. What are the chances of getting psuedo randomness exposed through the random package?
I guess if simple pseudo randomness, seeded with the available information to the canister, is enough, it could be a Motoko feature that doesn’t require changes to the Internet Computer. But the Motoko team isn’t really overstaffed at the moment, so I’m not sure how fast we can do it.
It might be an interesting task for someone who wants to get involved with Motoko developent, though!
(But first write an issue with a rough design outline and get approval from Andreas first before pouring work into this. It would probably a single prim returning a Nat64, and the internals a simple PRNG, seeded with canister id and reseeded with, say, time and message size and other data upon every message invocation; that would be implemented in the RTS code.)
2 Likes