search

paritytech / substrate

Substrate: The platform for blockchain innovators
Apache License 2.0
8.39k stars 2.65k forks source link

Expose block hash in pallet-contracts #14724

Open SkymanOne opened 1 year ago

SkymanOne commented 1 year ago

Is there an existing issue?

Experiencing problems? Have you tried our Stack Exchange first?

Motivation

See https://github.com/paritytech/ink/issues/1849

Request

ink! requires block_hash environment function to be exposed on the pallet-contracts' side: https://github.com/paritytech/substrate/blob/28e906dffcaa91e85f59aff628d953ebeb036ae2/frame/contracts/src/wasm/runtime.rs#L1022

Solution

No response

Are you willing to help with this request?

Yes!

agryaznov commented 1 year ago

If such a host function is intended to serve as a source of randomness, then for the reasons stated in https://github.com/paritytech/substrate/pull/13204, I don't think we should expose in the pallet API.

burdges commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.