-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: initial draft for Proof-of-Stake in Witnet #96
base: master
Are you sure you want to change the base?
Conversation
38bd3db
to
d30ba9a
Compare
c1a5369
to
07d1e77
Compare
value. | ||
|
||
**()** Upon consolidating a block candidate, for each of the commitment transactions contained therein, the amount of | ||
coins in each committer's stake entry in the `StakesTracker` MUST be decremented by an amount equivalent to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This statement does not align with the latest simulation results I shared and on which this description is based. You have to reset all coins of the selected stakers to age 1. Otherwise the most powerful stakers will always be eligibile to solve a data request.
Regardless of that, I'm not even sure what decrementing the amount of coins would look like? That sounds permanent and at some point you won't be able to solve data requests anymore regardless of the coin age?
07d1e77
to
670b5e3
Compare
witnessing power, multiplied by the query's own replication factor (witnesses count), and the commitment round. | ||
- When proposing a block, all the mining power of the proposing node is used at once. That is, if the block ends up | ||
being consolidated, the average "mining age" of its proposer's stake is reset to zero. | ||
- When resolving an oracle query, only the required collateral is used. That is, the average "witnessing age" of the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See this point: #96 (comment)
|
||
#### UnstakeTransaction | ||
|
||
**()** A new type of transaction, `StakeTransaction`, MUST be introduced, following this schema: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
UnstakeTransaction
|
||
**()** The identifier of an `UnstakeTransaction` is the SHA256 hash of the Protocol Buffers serialization of its `body`. | ||
|
||
**()** For an `UntakeTransaction` to be valid, it MUST contain one valid ECDSA Secp256k1 signature, such that the public |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
**()** For an `UntakeTransaction` to be valid, it MUST contain one valid ECDSA Secp256k1 signature, such that the public | |
**()** For an `UnstakeTransaction` to be valid, it MUST contain one valid ECDSA Secp256k1 signature, such that the public |
power and provide a valid VRF proof that MUST satisfy all the following requirements: | ||
1. the VRF input is the concatenation of the previous block hash, the data request hash, and the current epoch, all | ||
of them in big-endian format, | ||
2. the witnessing power of the block proposer is in the `rf / stakers`th quantile among the witnessing powers of all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2. the witnessing power of the block proposer is in the `rf / stakers`th quantile among the witnessing powers of all | |
2. the witnessing power of the committer is in the `rf / stakers`th quantile among the witnessing powers of all |
This introduces a pretty straightforward mechanism for unifying mining and witnessing eligibility through a single Proof-of-Stake consensus algorithm.
Because this mechanism requires a non-trivial bootstrapping period, a second WIP shall be drafted, describing such process and the details of the transition into 2.0.
The () things in front of every article in the specification are left empty on purpose while we shuffle things around, and will be changed later to include incremental article numbers we can refer to.