Integration of the ledger, consensus, networking and node shell repositories.
Logging is provided as a feature by the node shell to the other packages.
The cardano-node is the top level for the node and aggregates the other components from other packages: consensus, ledger and networking, with configuration, CLI, logging and monitoring. The node no longer incorporates wallet or explorer functionality. The wallet backend and explorer backend are separate components that run in separate external processes that communicate with the node via local IPC.
The download includes cardano-node.exe and a.dll. to run the node with cardano-node run you need to reference a few files and directories as arguments. You can just copy these directly from the cardano-node repo into the executables directory. The command to run the node on mainnet looks like this.
This refers to the client being used when running a node.
The general synopsis is as follows
Usage: cardano-node run [--topology FILEPATH] [--database-path FILEPATH]
[--config NODE-CONFIGURATION] [--validate-db]
Run the node.
• --topology - Filepath to a topology file describing which peers the node should connect to. • --database-path - path to the blockchain database.
• --byron-delegation-certificate - An optional path to the Byron delegation certificate. The certificate allows the delegator (The user of the certificate) to give his/her own block signing rights to somebody else (the delegatee). The delegatee can then sign blocks of behalf of the delegator
• --byron-signing-key - Optional path to the Byron signing key.
• --shelly-signing-key - Optional path to the Shelly signing key.
• --shelly-kes-key - Optional path to the shelly KES signing key.
• --shelly-vrf-key - Optional path to the Shelly VRF signing key.
• --shelly-operational-certificate - Optional path to the Shelly operation certificate. • --socket-path - Path to the socket file.
• --host-addr - Optionally specify your node's IPv4 address.
• --host-ipv6-addr - Optionally specify your node's IPv4 address.
• --Validate-db - Flag to revalidate all on-disk database files
Configuration .ymal files
The --config flag points to a .ymal file which is responsible to configurig the logging & other important settings for your node. E.g. see the Byron mainnet configuration in the following link. Some of the more important settings will be below the link.
• Protocol: RealPBFT -- The protocol the node will execute
• RequiresNetworkMagic: RequiresNoMagic -- Used to distinquish between the mainnet (RequiresNoMagic) and the testnets (RequiresMagic)
Logs are output to the logs/ dir.
Ptofiling & statistics
Make sure you see scripts/README.md for how to obtain profiling information using the scripts.
Be sure you've seen scripts/README.md for information on the various scripts.
A CLI utility to support a variety of key material operations (genesis, migration, pretty-printing) for different system generations. Usage documentation can be found at the following link.
The general synopsis is on the following line of code.
Usage: cardano-cli (Era based commands | Byron specific commands | Miscellaneous commands)
Keep in mind that the exact invocation command depends on the enviornment. If you only have cardano-cli bult, without installing it, then you have to prepend cabal run -- before cardano-cli. From now on we'll just assume that the necessary enviornment-specific adjustment has been made. Now you'll only have to mention cardano-cli.
The subcommands are subdivided in groups and their full name list is visible in the output of cardano-cli --help.
Remember that all the subcommands have help availible. An example is visible below.
cabal run -- cardano-cli -- byron key migrate-delegate-key-from --help
NB: This by efault creates transactions based on configuration/defaults/liveview/config-0.yaml
If you don't have a genesis_file you can run scripts/benchmarking/genesis.sh to create an example genesis file for you. The script scripts/benchmarking/issue-genesis-utxo-expenditure.sh has defaults for every requirement of the issue-genesis-utxo-expenditure command.
The submit-tx subcommand gives you the option of submitting a pre-signed transaction in its war wire format. (See GenTx for Byron transactions)
The canned scripts/benchmarking/submit-tx.sh script submits the supplied transaction as a testnet launched by scripts/benchmarking/shelly-testnet-liveview.sh script.
Issuing UTxO expenditure (genesis and regular)
If you plan to make a transaction using UTxO, you can either the following subcommands directly ot you can use one of the canned scripts that make transactions tailored for the testnet cluster. Keep in mind that the first two commands are the directly used subcommands and the next two commands use the canned scripts.
Keep in mind that the script requires the target file name so it can write the transaction to it input Txld (If you're using normal UTxO), as well as optionally allows specifying the source txin output index, source and target signing keys and lovelace value to send.
The target adress defaults to the 1-st richman key (configuration/delegate-keys.001.key) of the testnet, and lovelace amount is almost the entirety of its funds.
Local node queries
You can query the tip of your local node with the get-tip command. The instructions are listed below.
You should then see the output from the stdout in the format below.
Block hash: 4ab21a10e1b25e39
Block number: 5
A byron update proposal can be created with the command below
cardano-cli -- byron governance
(--mainnet | --testnet-magic NATURAL)
The mandatory arguments for this to work are --mainnet | --testnet-magic, signing-key, protocol-version-major, protocol-version-minor, protocol-version-alt, application-name, software-version-num, system-tag, installer-hash and filepath.
Any remaining argument is an optional parameter you want to update in your update proposal.
To work around this, you can run the script ./scripts/reconfigure-hlint.sh which will generate a .hlint.yaml file with HLINT ignore rules derived from the source code.
Cardano-node is basically a container which implements several components such as networking, consensus, and storage. All of these components have individual test coverage. The node goes through integration and release testing by Devops/QA while automated CLI tests are ongoing alongside development.
It may be useful if you print the on chain. representations of blocks, delegation certificates, txs and update proposals. There are two commands that do this (for any cbor encoded file.), though only one is listed directly below this line.
To pretty print as CBOR: cabal exec cardano-cli -- pretty-print-cbor --filepath CBOREncodedFile
Validate CBOR files
You can validate Byron era blocks, delegation certificates, txs and update proposals with the validate-cbor command.
Native tokens is a new feature that enables the transacting of multi-assets on Cardano. Native tokens are now supported on mainnet and users can transact with ada, and an unlimited number of user-defined (custom) tokens natively.
Below is a compiled list of resources which can help you get started.
additionally to that, you can read more about native token and how they compare to things like ada and ERC20 with the link below. Browse native tokens made on the Cardano blockchain itself as well as see their transactions in an interactive dashboard which allows filtering and searching: nativetokens.da.iogservices.io.
The documentation is built with each push, but is only published from the master branch. If you want to test if the documentation is working, you can build the documentation loccaly with ./scripts/haddocs.sh and ipen haddocs/index.html in the browser.