FIP-0095: First draft of add FEVM precompile to fetch beacon digest from chain history #1048
Conversation
ZenGround0
requested review from
momack2,
arajasek,
jennijuju,
kaitlin-beegle,
anorth,
raulk,
jsoares and
TippyFlitsUK
as code owners
|
Could you add a discussion topic? |
anorth
changed the title
|
@jennijuju thanks for being so speedy, but I don't think this PR was ready for review yet. It should probably have been marked draft while @ZenGround0 and I collaborate on the details. |
FIPS/fip-rand-precompile.md
Outdated
| |------------------|---------------------------| | ||
| | randomness_epoch | U256 - low i64 | | ||
|
|
||
| The call errors with `PrecompileError::InvalidInput` if the epoch is invalid. |
There was a problem hiding this comment.
should outline what "invalid" means here, just future epochs? negative i64's?
There was a problem hiding this comment.
I'v adjusted it slightly, but I think it's easier to define this via what positively is valid than the inverse.
FIPS/fip-rand-precompile.md
Outdated
| The call errors with `PrecompileError::InvalidInput` if the epoch is not a valid, prior epoch number. | ||
|
|
||
| This calls directly to the FVMs `get_beacon_randomness` syscall, which returns a Blake2b hash digest of the | ||
| randomness value from the drand beacon at the associated Filecoin epoch. |
There was a problem hiding this comment.
what would happen if it was a null round of a given filecoin epoch?
There was a problem hiding this comment.
Whatever would already happen in that case, which this FIP doesn't propose to change.
I can see a reasonable motivation to want to describe this for potential users, which now extend beyond built-in actors. This FIP isn't proposing to change any of the semantics, but they are poorly documented at present. I will try to come back with some edits to describe them here as context, but I need some help because I wasn't involved in developing the underlying syscall.
jennijuju
changed the title
anorth
changed the title
|
I've pushed edits in response to review. I think this draft is ready for merge. I acknowledge the outstanding request for more detail about semantics of the underlying syscall, but since this FIP is not proposing to change any of them, I don't think that should block progress. I'll endeavour to come back with an update to describe that better in a subsequent PR. |
|
…out further processing.
Co-authored-by: Rod Vagg <[email protected]>
anorth
force-pushed
the
fip-xxxx/evm-randomness-precompile
branch
from
e74ccdb
to
a96f07c
Compare
| but is missing the hook-up to where user-deployed smart contracts can use it. | ||
| This proposal provides that hook-up. | ||
|
|
||
| The EVM does already provide a PREVRANDAO opcode, but this is limited to access randomness from the immediately prior epoch. |
There was a problem hiding this comment.
I'm very late to the party here, but I don't understand the motivation of having an opcode for searching the block history vs just exposing a method for verifying drand/arbitrary BLS signatures.
If the caller is triggering some PDP by calling the user space smart contract, providing the relevant drand signature as calldata seems much more flexible (and could allow for granularity better than filecoin block time).
There was a problem hiding this comment.
@CluEleSsUK yes BLS precompiles are the generally better solution. We essentially introduced this FIP to work around the PDP timeline.
Basically this FIP has the two properties of
- it's is an overall improvement and a nice positive change for the network
- we could get a FIP ready for last call to land in nv24 and ship PDP this year
We would love to see BLS precompiles and @anorth started exploring this direction before flagging it would take too much time. If your team would like to continue work on BLS precompiles we can share what we've learned so far and support you getting it into nv25.
There was a problem hiding this comment.
One other nice thing about this FIP is the potentially efficiency speedup. Since the network has gone through the trouble to validate these signatures once it is convenient for users' gas margins to make use of the relatively cheaper fetching of the already validated randomness.
There was a problem hiding this comment.
I think there’s still appetite from our team to pick up the BLS precompiles but I can’t commit to a timeline just yet. Will discuss it next week
The FVM exposes a syscall for fetching the digest of a drand beacon included in some prior Filecoin chain header.
The built-in actors use this facility to provide randomness for storage proofs.
This proposal introduces an EVM actor precompile exposing this functionality to user-deployed smart contracts
so that they can also use random challenges for other types of proofs.
Discussion: #1051