Implement the LocalStateQueryServer #1507
Conversation
|
TODO:
|
mrBliss
force-pushed
the
mrBliss/local-state-query
branch
3 times, most recently
from
0554eae to
5b07c4f
Compare
| class QueryLedger blk where | ||
|
|
||
| -- | Different queries supported by the ledger | ||
| data family Query blk :: * |
There was a problem hiding this comment.
Make this is type class parameter instead so that we can have multiple Query types for a single blk. Result can remain a data family.
ouroboros-consensus/src/Ouroboros/Consensus/LocalStateQueryServer.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus/src/Ouroboros/Consensus/LocalStateQueryServer.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus/test-consensus/Test/Consensus/Ledger/Byron.hs
Outdated
Show resolved
Hide resolved
| @@ -1101,6 +1108,7 @@ type LimitedApp' m peer blk unused1 unused2 = | |||
| (AnyMessage (TxSubmission (GenTxId blk) (GenTx blk))) | |||
There was a problem hiding this comment.
Turn this into a Lazy.ByteString to be uniform and compatible with the plan to use a single functor (either Const Lazy.ByteString or AnyMessage) for NetworkApplication.
ouroboros-consensus/test-consensus/Test/Consensus/LocalStateQueryServer.hs
Outdated
Show resolved
Hide resolved
mrBliss
force-pushed
the
mrBliss/local-state-query
branch
2 times, most recently
from
602e134 to
3739854
Compare
Querying the ledger state can only happen for a ledger state corresponding to a block, not to a ledger.
mrBliss
force-pushed
the
mrBliss/local-state-query
branch
from
3739854 to
50f3dd1
Compare
|
@coot @dcoutts Can we merge this without breaking network compatibility if we don't change the |
|
@coot Edsko already reviewed the consensus side of this PR. You only have to look at the changes in |
mrBliss
force-pushed
the
mrBliss/local-state-query
branch
from
50f3dd1 to
f0fa03a
Compare
Answer: "network compatibility" is determined by the |
This new abstraction replaces `getPastLedger` and can, in the future, allow for more efficient rolling forward. For example, when requesting a ledger state 100 blocks after some ledger snapshot we have in memory, we'll need to apply 100 blocks to the ledger. This won't change with the `LedgerCursor` abstraction, but if we then starting rolling forward and requesting the ledger states 101, 102, 103, ... blocks after our in-memory ledger snapshot, we only have to apply one block each time, instead of having to apply 101, 102, 103, ... blocks each time! This optimisation has not yet been implemented, but by introducing the abstraction now, we can later implement it without having to change the API.
It was storing both the last applied point (slot + hash) and hash. We only need to store the former.
This will be used for the LocalStateQuery protocol.
As the `LocalStateQueryServer` will send this over the network in the form of `Result ByronBlock`, we must be careful not to break network compatibility with clients, hence the golden test.
To actually enable it, we still need to add it to `NodeToClientProtocols`. This means we're not breaking "network compatibility" yet.
The protocol will now guarantee that the response to a Query has the right type.
mrBliss
force-pushed
the
mrBliss/local-state-query
branch
from
f0fa03a to
0ec858c
Compare
|
bors r+ |
1507: Implement the LocalStateQueryServer r=mrBliss a=mrBliss Closes #1366. Co-authored-by: Thomas Winant <[email protected]>
Closes #1366.