Expose block hash in pallet-contracts

[SkymanOne]

Is there an existing issue?

• I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

• This is not a support question.

Motivation

See use-ink/ink#1849

Request

ink! requires block_hash environment function to be exposed on the pallet-contracts' side:

substrate/frame/contracts/src/wasm/runtime.rs

Line 1022 in 28e906d

pub mod env {

Solution

No response

Are you willing to help with this request?

Yes!

[agryaznov]

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.

[burdges]

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.

[SkymanOne]

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?

[burdges]

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.