Hi everybody, sorry it took me so long to get here. I really like the proposal, the ideas discussed here are very interesting, and I believe that if this is successful it will be a great hit!
+1 to putting it to vote!
Some additional questions/comments:
-
I’m not sure I understand who is expected to run the off-chain Convenience API. The front-end application?
-
I believe the proposed idea is that the Convenience Middleware inside the CM will wrap or decorate the existing back-end HTTP API. Is that the case?
-
I agree with @Augusto’s comments that it may be tricky to know when randomness is necessary. I believe both scenarios are plausible:
- The client (front-end application) has enough logic to know when randomness is necessary, in which case it can signal the middleware to hold subsequent inputs until the beacon arrives (which is what this proposal supports)
- Only the back-end knows when randomness is necessary, in which case it would need to signal to the middleware that further input processing can only happen after a new beacon arrives. I don’t think this is covered by the current proposal, but I think that’s ok - we could stick to use-case (1) for a first implementation, but keep (2) in mind
-
A futuristic idea/comment: I was wondering if we could avoid sending an input to each DApp that needs randomness. Ideally we would like to send this input to some “broadcast” address and have all interested DApps receive it. Maybe we could have a “Drand DApp” and have other DApps run it inside using a “Cascades” approach…? Or have explicit support in Cartesi Rollups for “broadcast inputs” (e.g., inputs sent to
address(0))
Cheers!