bring mining.md doc up to speed with new EC changes #153
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sternhenri
reviewed
Feb 25, 2019
| - Ensure that all tickets in both arrays are signed by the same key. | ||
| - For the `Tickets` array, ensure that each ticket was used to generate the next, starting from the smallest ticket in the Parent tipset (at `N-1`). | ||
| - For the `ElectionProofs` array, ensure that each ticket was used to generate the next, starting from the smallest ticket in the Lookback tipset (at `N-K`). | ||
| - Ensure that both arrays contain the same number of tickets. | ||
| - For the `ElectionProof`, ensure that the correct ticket was used to generate it, from `K` blocks back, accounting for null blocks. | ||
|
|
||
| We detail ticket validation as follows: | ||
|
|
||
| ```go |
There was a problem hiding this comment.
great work adding the below! I should have done it :/
sternhenri
reviewed
Feb 25, 2019
mining.md
Outdated
|
|
||
| Next, compute the aggregate state of your selected parent blocks, the `ParentState`. This is done by taking the aggregate parent state of *their* parent tipset, sorting your parent blocks by their tickets, and applying each message in each block to that state. Any message whose nonce is already used (duplicate message) in an earlier block should be skipped (application of this message should fail anyway). Note that re-applied messages may result in different receipts than they produced in their original blocks, an open question is how to represent the receipt trie of this tipsets 'virtual block'. For more details on message execution and state transitions, see the [Filecoin state machine](state-machine.md) document. | ||
|
|
||
| Once you have the aggregate `ParentState`, you must apply the mining reward. This is done by adding the correct amount to the miner owners account balance in the state tree. (TODO: link to block reward calculation. Currently, the block reward is a fixed 1000 filecoin). |
There was a problem hiding this comment.
typo: miner owner's.
It'd be nice if htere was some special "coinbase" type thing here as opposed to just add to the balance to mark a special event. Just a thought.
There was a problem hiding this comment.
Also a way to gracefully correct miscalculation here if it happens.
sternhenri
reviewed
Feb 25, 2019
mining.md
Outdated
|
|
||
| Next, compute the aggregate state of your selected parent blocks, the `ParentState`. This is done by taking the aggregate parent state of *their* parent tipset, sorting your parent blocks by their tickets, and applying each message in each block to that state. Any message whose nonce is already used (duplicate message) in an earlier block should be skipped (application of this message should fail anyway). Note that re-applied messages may result in different receipts than they produced in their original blocks, an open question is how to represent the receipt trie of this tipsets 'virtual block'. | ||
| Now, a set of messages is selected to put into the block. For each message, subtract `msg.GasPrice * msg.GasLimit` from the senders account balance, returning a fatal processing error if the sender does not have enough funds (this message should not be included in the chain). Then apply the messages state transition, and generate a receipt for it containing the total gas actually used by the execution, the executions exit code, and the return value (see [receipt](data-structures#message-receipt) for more details). Then, refund the sender in the amount of `(msg.GasLimit - GasUsed) * msg.GasPrice`. Each message should be applied on the resultant state of the previous message execution, unless that message execution failed, in which case all state changes caused by that message are thrown out. The final state tree after this process will be your blocks `StateRoot`. |
There was a problem hiding this comment.
typo: sender's account balance.
Should also explicitly specify what happens to gas balance (I assume refund) in case of both fatal processing error and message execution failure.
sternhenri
reviewed
Feb 25, 2019
| - Ensure that the new ticket was generated from the smallest ticket in the block's parent tipset (at height `N-1`). | ||
| - Recompute the new ticket, using the miner's public key, ensuring it was computed appropriately. | ||
|
|
||
| 6. You must validate that the tickets in `ElectionProofs` array were correctly generated by the miner, and that they are eligible to mine. | ||
| 5. You must validate that the `ElectionProof` was correctly generated by the miner, and that they are eligible to mine. | ||
| - Ensure that the proof was generated using the smallest ticket at height `N-K` (the lookback tipset). |
There was a problem hiding this comment.
May be worth reminding here that this includes null blocks
sternhenri
reviewed
Feb 25, 2019
sternhenri
reviewed
Feb 25, 2019
|
|
||
| Now, a set of messages is selected to put into the block. For each message, subtract `msg.GasPrice * msg.GasLimit` from the senders account balance, returning a fatal processing error if the sender does not have enough funds (this message should not be included in the chain). Then apply the messages state transition, and generate a receipt for it containing the total gas actually used by the execution, the executions exit code, and the return value (see [receipt](data-structures#message-receipt) for more details). Then, refund the sender in the amount of `(msg.GasLimit - GasUsed) * msg.GasPrice`. Each message should be applied on the resultant state of the previous message execution, unless that message execution failed, in which case all state changes caused by that message are thrown out. The final state tree after this process will be your blocks `StateRoot`. | ||
| Now, a set of messages is selected to put into the block. For each message, subtract `msg.GasPrice * msg.GasLimit` from the sender's account balance, returning a fatal processing error if the sender does not have enough funds (this message should not be included in the chain). Then apply the messages state transition, and generate a receipt for it containing the total gas actually used by the execution, the executions exit code, and the return value (see [receipt](data-structures#message-receipt) for more details). Then, refund the sender in the amount of `(msg.GasLimit - GasUsed) * msg.GasPrice`. In the event of a message processing error, the remaining gas is refunded to the user, and all other state changes are reverted. (Note: this is a divergence from the way things are done in Ethereum) |
There was a problem hiding this comment.
nit: some explaining of why we choose to do it differently (I'm guessing it's cost to DOS?)
sternhenri
approved these changes
Feb 25, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.