Implement (part-of) http-bridge API (get network tip, get block)

[KtorZ]

Context

We want to outline a first network layer that abstract away the retrieval of blocks from a chain producer. In the first iteration, this chain producer will be the cardano-http-bridge which serves blocks through a basic simple http API.

Decision

• Implement the necessary HTTP calls to retrieve blocks from the network
• The implementation should satisfy to the following interface:

nextBlocks 
  :: Natural -- | Number of blocks to retrieve
  -> (EpochIndex, SlotNumber) -- | Starting point 
  -> ExceptT ErrGetNextBlocks m [Block]

With m a monad that may be specialized by the implementation. We do not care about rollbacks yet and will introduce them later.

---

Development Plan

Questions:

1. I would really like to import some property tested slotting arithmetic functions rather than re-implementing them poorly? Is this possible?
2. How are we going to configure number of slots in the epoch?
3. Have we already requested a change to cardano-http-bridge to provide a function to return a range of blocks from the latest epoch?
4. Is servant-client ok for accessing the node api, or just plain http-client?

Plan

• Add some slot arithmetic and comparison functions where necessary
• Number of slots in the epoch hard-coded to 21600.
• Initially model nextBlocks in IO then make it polymorphic over the chain producer backend.
• Unit tests with a mock chain producer.
• Add function to get a range of blocks from the latest epoch, to work around missing endpoint in the cardano-http-bridge API.
• Servant types and client code to model the 3 necessary API endpoints.

PR

Number	Base
#40	master
#41	master
#57	master
#60	master
#63	master

QA

• This will be partly covered by unit tests with a mock chain producer.
  • The test cases for nextBlocks are in Cardano.ChainProducer.RustHttpBridgeSpec.
  • The associated mock network layer is in Cardano.ChainProducer.RustHttpBridge.MockNetworkLayer
• The servant-client API has no test coverage (yet). It seems to work, having tried it with informal testing.
• Integration tests with an actual cardano-http-bridge will be possible after Spawn http bridge and a wallet server from specified options #8 is complete. Although executing these tests will require an external dependency (a network to connect to).

[KtorZ]

I would really like to import some property tested slotting arithmetic functions rather than re-implementing them poorly? Is this possible?

What do you mean by "import some" ? We won't import anything from cardano-sl, though we may port code from there that is relevant and have a fairly small impact / footprint. Have you examples of that? It's maybe overkill for the wallet to be testing those things 🤔 ? As far as we are concerned, the slot and epoch are just indexes.

How are we going to configure number of slots in the epoch?

In the long-run, yes, this is a protocol parameter which may change via protocol updates.

Have we already requested a change to cardano-http-bridge to provide a function to return a range of blocks from the latest epoch?

No, and we won't likely do it. The http-bridge API won't change, but we'll get to use, at some point, the API of the new Rust node. For the http-bridge, we'll have to work it out ourselves.

Is servant-client ok for accessing the node api, or just plain http-client?

Sounds a bit overkill to me in this particular case because the http bridge just replies with raw binary format. So, we'll have to define a small servant API that have rather little value. So, use your judgement, but you have my two cents.

[rvl]

Cheers.

I was thinking about the Slotting functions in cardano-chain. Or maybe someone has a nice little module somewhere. If we could import just those it might save some work and avoid some bugs.

[KtorZ]

I truly believe it's unnecessary here. And that would be opening the door to many more issues and coupling. Let's not. Slot and Epoch number are really just indexes for us; there's nothing we really do with them.

[piotr-iohk]

lgtm 👍  
I wanted to ask about SlottingOrphans.hs but I see it has been removed by #57.