Easy way to extract genesis block

[SebastienGllmt]

To integrate Yaci local networks with Carp / Paima, I need a few things:

1. To know the network ID
2. To know the protocol magic
3. To know the genesis block content

Although these are all generated dynamically. To tackle this problem, it would be nice if there was a command to export all the genesis file information from the network after it's created.

That being said, with #29 being resolved I can probably just hardcode the default configuration generated (and if people want to do custom stuff, we just won't support it). This still leaves 2 issues though:

1. Even if I want to hardcode this, I still need to generate to reverse engineer what the genesis block used it somehow (so we're back to the original problem kind of)
2. In Well defined default addresses #29 , the solution involved modifying the Shelley genesis block and not the Byron one (whereas tools like Carp just parse the Byron genesis block). It would be good to have clarity on how I'm supposed to make this work

[satran004]

@SebastienGllmt

1. Genesis File Extraction: When we start "yaci-cli.sh," it provides admin API endpoints to get node information. These APIs are available at port 10000 (http://localhost:10000/swagger-ui/index.html). Please check the endpoints under cluster-admin-controller.

Note: Cluster name is "default."

There is an endpoint that can be used to download the contents of the node config folder as a zip file.

curl -X GET http://localhost:10000/local-cluster/api/admin/clusters/default/download -o config.zip

Currently, it returns everything inside the node folder. Not all files in the zip are currently used. So it needs some cleanup.

However, you can find the genesis files under the "genesis" sub-folder. You can ignore the genesis.conway.* files as those are used only during Conway mode.

Let me know if this works for you. We can also provide a separate endpoint later that returns only the genesis files.
There are few other endpoints that may be useful to you, like the "status" endpoint.

FYI, the admin API was developed to support an experimental feature where another devkit node can join the currently running node as a relay or block producer. However, this feature is not yet stable.

2. Well-Defined Addresses in Shelley Genesis: The embedded indexer in DevKit also parses the Shelley genesis file to get the initial "utxo" set.
   I am wondering if a similar thing can be done in Carp to make it compatible with a custom Dev node. As the txId of these utxos are deterministic, those can be populated in the database before actual sync.

Alternatively, we could also expose another admin endpoint to return initial utxo sets or address/amount set. Let me know if it makes sense or if there is any other option.

3. FYI, we are adding a new wrapper script "devkit.sh <start|stop>" which internally invokes start.sh and yaci-cli.sh to reduce the current two step process to one command. (https://github.com/bloxbean/yaci-devkit/blob/boot_upgrade/devkit.sh)

4. For the next release, we are upgrading different components in DevKit. But as the Well defined default addresses #29 fix is already there, we can also push a preview release if it helps with your integration.

[SebastienGllmt]

The embedded indexer in DevKit also parses the Shelley genesis file to get the initial "utxo" set.
I am wondering if a similar thing can be done in Carp to make it compatible with a custom Dev node. As the txId of these utxos are deterministic, those can be populated in the database before actual sync.

Is embedding addresses in the shelley genesis block like this something that is supported by cardano-node as well, or is this something custom you came up with?

[satran004]

Is embedding addresses in the shelley genesis block like this something that is supported by cardano-node as well, or is this something custom you came up with?

This is supported by Cardano node. For mainnet, initialFunds attribute is empty (https://book.play.dev.cardano.org/environments/mainnet/shelley-genesis.json)
But, we are using it for custom devnet.