Remove random function #1442
Remove random function #1442
Conversation
| @@ -6,6 +6,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 | |||
|
|
|||
| ## [Unreleased] | |||
|
|
|||
| - Remove random function from ink!. | |||
There was a problem hiding this comment.
| - Remove random function from ink!. | |
| ### Removed | |
| - Remove random function ‒ [#1442](https://github.com/paritytech/ink/pull/1442) |
There was a problem hiding this comment.
Could you please add some more information in a section ### How to replace random here?
My concern is that we're just removing it without providing guidance on how to substitute this functionality.
Is there no pallet out there which we could create a chain extension with?
There was a problem hiding this comment.
On ethereum contracts need to look for randomness on their own anyways. They rely on oracle contracts AFAIK. If we had some reliable way to provide randomness in the general case we wouldn't remove it. I don't think there is anything at the moment.
@burdges has some ideas but nothing readily available. So we can't really give any advice beyond "good luck bro".
There was a problem hiding this comment.
This pseudo random function was useful enough for our contract but now its removed. Any guidance on how to recreate this functionality would be appreciated.
There was a problem hiding this comment.
We need a random seed per block that is good enough to randomly read a value from a vector within our contract. There is no transaction involved. The operation is not high value and the seed calculated by the validators was fulfilling this purpose very well. Are the validators no longer committing this random seed to each block?
Could the current block hash be made available in ink! as a substitute?
There was a problem hiding this comment.
There are several randomness sources available in polkadot, but they won't all be available in all ink deployments, especially ink deployments on stand along chains. We'd really like deployers to understand their limitations.
A block hash based randomness is good when you're doing a Fiat-Shamir transform, but usually not so great otherwise, but if your usage is low enough value then fine. There is nothing wrong with a parachain block knowing its own block hash, because although this makes parachain execution non-deterministic relative to when the block is built, it clearly stays deterministic from the perspective of polkadot. It's fine to make the block hash available and just warn people that they should look at other randomness options if they think about using it for randomness.
BABE's VRF usage provides three slightly different randomness sources, each with their own use cases. Sassafras should add a fourth, but not too different either. ParentBlockRandomness might fit your use case.
A drand gives strong fresh randomness every 15 seconds. It's desynced from polkadot though, so one needs a "drand bridge" to sync reads from drand, without giving someone too much authority to tweak the syncing.
Advanced randomness like polkadot's candle auctions require some sort of commitment before the randomness exists, after which the chain chooses the randomness with which the commitment gets used. VRF keys held by users fit roughly into this category too, but less strictly.
There was a problem hiding this comment.
We need a random seed per block that is good enough to randomly read a value from a vector within our contract. There is no transaction involved. The operation is not high value and the seed calculated by the validators was fulfilling this purpose very well. Are the validators no longer committing this random seed to each block?
Could the current block hash be made available in
ink!as a substitute?
We would need way for information to give some advice and to determine if using predictable randomness is actually safe. I recommend asking on stack exchange.
There was a problem hiding this comment.
I've provided more info on stack exchange.
Codecov Report
@@ Coverage Diff @@
## master #1442 +/- ##
==========================================
- Coverage 70.39% 64.43% -5.97%
==========================================
Files 200 200
Lines 6137 6101 -36
==========================================
- Hits 4320 3931 -389
- Misses 1817 2170 +353
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
We need to move away from on-chain randomness. We cannot rely on hosting chains to provide unpredictable randomness. Like on ethereum that should be provided by oracles or maybe a chain extension of a chain has a way to provide randomness. It should not be part of the core API.