Open troggy opened 4 years ago
@TheReturnOfJan I don't really get the structure of walkProof
. Can you explain? In a period proof we now have a prev period hash, so given a period proof we can check that the previous period was submitted. Should we provide a proof for that previous as well? Otherwise I don't see how can we check that they are indeed consecutive.
So the walkProof
is an array like [evenMorePreviousPeriodProof, previousPeriodProof, periodProof]
?
So the walkProof is an array like [evenMorePreviousPeriodProof, previousPeriodProof, periodProof]
Yes. You can think of it as array of arrays of bytes32 [[bytes32, bytes32, bytes32], [bytes32, bytes32, bytes32], [bytes32, bytes32, bytes32],...]. The length of the outer array is the length of the walk (how many periods back you go), and the length of the inner array is the size of the prevPeriod inclusion proof, which is constant (but I do not know of the top of my head what it is). The input parameter type is currently bytes, since at the time I did not want to commit to details yet. But maybe it would make sense to change the type of walkProof to bytes32[][].
expired. Needs to be resubmitted by gardener
Bounty
We've designed a validator heartbeat challenge game as defined here (alternative link). Some parts of it are not yet implemented. Including a period walk proof verification. Since we now have previous period hash in a period proof, we can implement it. This bounty is all about that.
Scope
PoaOperator.verifyWalk
to verify the period chain: they should be consecutive referencing one anotherDeliverables
Gain for the project
ability to use
minimumPulse
> 0 for validator heartbeat challengesRoles
bounty gardener: @troggy / 50 DAI bounty worker: name / share bounty reviewer: name / share
Funded by
Dev Circle