Expose block hash in pallet-contracts #14724

Activity

1. SkymanOne

   added

   J0-enhancementAn additional feature request.An additional feature request.

   on Aug 7, 2023
2. github-actions

   added

   J2-unconfirmedIssue might be valid, but it’s not yet known.Issue might be valid, but it’s not yet known.

   on Aug 7, 2023
3. agryaznov commented on Aug 7, 2023

   

   agryaznov

   on Aug 7, 2023

   Contributor

   More actions

   If such a host function is intended to serve as a source of randomness, then for the reasons stated in #13204, I don't think we should expose in the pallet API.
4. burdges commented on Aug 8, 2023

   

   burdges

   on Aug 8, 2023

   More actions

   We removed the collective-flip randomness there, which afaik never really suffices. In theory, you could've whole block fiat-shamir transforms, but this winds up really nasty in practice.

   A smart contract parachain could expose VRF based randomness, of which we've two choices:

   1. Slot VRFs - Adversary knows these 6 hours in advance, so they have many choices for their own tx. If otoh an honest user binds their tx to a specific slot, then the adversary has only one choice, accept the tx or not.
   2. Running hash of slot VRFs - We do not currently collect or expose these in polkadot, except at epoch boundaries, but we'll try to change this in sassafras. An adversary spends like 10 n DOTs to have 2^n choices for a running hash of slot VRFs, but their n is bounded by their control over block production, backing, etc.

   A smart contract could also create commit-reveal protocols, which work somewhat better in some scenarios, but again require thought.

   It all depends somewhat upon what the smart contract chain really does.

   👍React with 👍1Reacted by Gherman
5. SkymanOne commented on Aug 8, 2023

   

   SkymanOne

   on Aug 8, 2023

   Author

   More actions

   We removed the collective-flip randomness there, which afaik never really suffices. In theory, you could've whole block fiat-shamir transforms, but this winds up really nasty in practice.

   A smart contract parachain could expose VRF based randomness, of which we've two choices:

   1. Slot VRFs - Adversary knows these 6 hours in advance, so they have many choices for their own tx. If otoh an honest user binds their tx to a specific slot, then the adversary has only one choice, accept the tx or not.
   2. Running hash of slot VRFs - We do not currently collect or expose these in polkadot, except at epoch boundaries, but we'll try to change this in sassafras. An adversary spends like 10 n DOTs to have 2^n choices for a running hash of slot VRFs, but their n is bounded by their control over block production, backing, etc.

   A smart contract could also create commit-reveal protocols, which work somewhat better in some scenarios, but again require thought.

   It all depends somewhat upon what the smart contract chain really does.

   To sum up what you are saying, it still all comes down to the specific smart contract chain exposing their own randomness interface to the smart contract developer via, let's say, chain extensions, and we should not (or can not) provide a default method of achieving randomness on-chain?
6. burdges commented on Aug 10, 2023

   

   burdges

   on Aug 10, 2023

   More actions

   It feel premature.. At minimum there should be some way to turn it off since there might even bespoke uses for smart contracts where exposing the block hash creates problems.