WIP: thoughts on apis needed for mining process #10
Conversation
|
considerations:
|
|
Also not accounted for here: What to do if we receive a new better tipset while mining? Curious on peoples thoughts about the api there, should i just get a channel of 'new best tipsets' ? |
|
|
||
| // returns a set of messages that havent been included in the chain as of | ||
| // the given tipset | ||
| PendingMessages(base *chain.TipSet) ([]*chain.SignedMessage, error) |
There was a problem hiding this comment.
this could be very large, probably better to do sth like iterator/paging/lazy loadinf
There was a problem hiding this comment.
We could return a channel here, implementing those over RPC should be easy
There was a problem hiding this comment.
Also, when this is made into a subscription, we'll also need to subscribe to incoming blocks to keep track of which messages we care about
It's probably easier to keep it this way for now, and fix when we actually have some miner code
|
|
||
| // returns a set of messages that havent been included in the chain as of | ||
| // the given tipset | ||
| PendingMessages(base *chain.TipSet) ([]*chain.SignedMessage, error) |
There was a problem hiding this comment.
We could return a channel here, implementing those over RPC should be easy
|
|
||
| // returns a set of messages that havent been included in the chain as of | ||
| // the given tipset | ||
| PendingMessages(base *chain.TipSet) ([]*chain.SignedMessage, error) |
There was a problem hiding this comment.
Also, when this is made into a subscription, we'll also need to subscribe to incoming blocks to keep track of which messages we care about
It's probably easier to keep it this way for now, and fix when we actually have some miner code
| // TODO: Not sure this feels right (including the messages api). Miners | ||
| // will likely want to have more control over exactly which blocks get | ||
| // mined on, and which messages are included. | ||
| GetBestTipset() (*chain.TipSet, error) |
There was a problem hiding this comment.
It's what chain head would return, right?
There was a problem hiding this comment.
yes, for the most part that should be the same operation. I don't have a good enough reason for them to be different yet
Update proofs to v25 parameters, win PoSt
thinking through (with code, obv) what the api surface a miner needs is.
It gets a little tricky when you try to have the miner actually create the block, as doing that requires full access to a blocks state tree (potentially hundreds of GBs) and the ability to execute VM state transitions. So this sketch chooses to just assume the miner doesnt have to do that, and the api can take care of it.
In this mode, the miner is responsible for keeping track of what the best tip to mine on is, checking if they are winners, selecting the messages to go in their blocks, and then making sure blocks get made at the right times.