Running on a custom testnet

[klntsky]

I noticed that in the config we can only specify one of the known networks. How hard would it be to run Blockfrost on a custom private testnet? We definitely need it for our plans of supporting Blockfrost backend in cardano-transaction-library.

[mmahut]

Probably not very hard - you would need some changes to support custom getConfig().network. That being said, I'm not sure if anyone has ever tried it on a custom testnet.

[vladimirvolek]

Just search getConfig().network.

Affected endpoints are:

/epochs/latest/index.ts /epochs/number/index.ts /epochs/number/next.ts /ledger /network and validation functions in /utils.

It should be pretty straightforward. Is that good enough for you?

[klntsky]

They are hardcoded deeply: https://github.com/blockfrost/blockfrost-backend-ryo/blob/1a513e4f37bcf8072663a70d11289ec63ca8c39f/src/types/common.ts#L8

[klntsky]

Would you accept a PR that adds the ability to run on a custom testnet?

[1000101]

I'm probably a little late to the party, but this may also require a change in validation utils.

[klntsky]

@1000101 True. We have a tool called plutip that spawns clusters with network ID set to mainnet, but the network is using very different parameters, so we need to support this case. The validation module relies on the assumption that network name is set to mainnet if and only if the network ID is also mainnet. And network names are tied to particular network configurations.

But there is no concept of network name in cardano domain, there is only ID and protocol parameters.

Network names are something more ad hoc, they are basically defined by whatever is put into this repo: https://github.com/input-output-hk/cardano-configurations

I think the best way to move forward would be to:

• introduce a special custom value to the network enum
• introduce an optional parameter to the config that would allow to point to a genesis file. If the genesis is provided, the network must be set to custom. Otherwise it must not be set to custom
• the genesis file would then be used to populate ResponseTypes.Ledger record. https://github.com/blockfrost/blockfrost-backend-ryo/blob/98a8670c91b3923bcd3662dedac1e41c34e0e663/src/constants/genesis.ts#L5
• replace all uses of GENESIS[network] construct with a function config.getGenesis() that would be a dispatcher to provide the parameters depending on the configuration.

[vladimirvolek]

I will look into this.

[vladimirvolek]

@klntsky Do you have something already?

[klntsky]

@vladimirvolek I started looking into this deeper and realized that the implicit assumption propagates to @blockfrost/blockfrost-utils, so either the validator utils should be changed to accept a network ID (0 = testnet, 1 = mainnet) instead of network name, or I'll have to add code that works around the fact they expect one of 4 variants and "guesses" the correct network name given an ID.

[lemmon-714]

bump