# Node Client (Daemon)

The main endpoint of an SDK application is the daemon client, otherwise known as the full-node client. The full-node runs the state-machine, starting from a genesis file. It connects to peers running the same client in order to receive and relay transactions, block proposals and signatures. The full-node is constituted of the application, defined with the Cosmos SDK, and of a consensus engine connected to the application via the ABCI.

# Pre-requisite Readings

Anatomy of an SDK application

# `main` function

The full-node client of any SDK application is built by running a main function. The client is generally named by appending the -d suffix to the application name (e.g. appd for an application named app), and the main function is defined in a ./appd/cmd/main.go file. Running this function creates an executable appd that comes with a set of commands. For an app named app, the main command is appd start, which starts the full-node.

In general, developers will implement the main.go function with the following structure:

First, an appCodec is instantiated for the application.
Then, the config is retrieved and config parameters are set. This mainly involves setting the Bech32 prefixes for addresses. Copy // Config is the structure that holds the SDK configuration parameters. // This could be used to initialize certain configuration parameters for the SDK. type Config struct { fullFundraiserPath string bech32AddressPrefix map[string]string txEncoder TxEncoder addressVerifier func([]byte) error mtx sync.RWMutex coinType uint32 sealed bool sealedch chan struct{} }
Using cobra (opens new window), the root command of the full-node client is created. After that, all the custom commands of the application are added using the AddCommand() method of rootCmd.
Add default server commands to rootCmd using the server.AddCommands() method. These commands are separated from the ones added above since they are standard and defined at SDK level. They should be shared by all SDK-based applications. They include the most important command: the start command.
Prepare and execute the executor. Copy // Executor wraps the cobra Command with a nicer Execute method type Executor struct { *cobra.Command Exit func(int) // this is os.Exit by default, override in tests }

See an example of main function from the simapp application, the SDK's application for demo purposes:

Copy package main import ( "os" "github.com/cosmos/cosmos-sdk/server" "github.com/cosmos/cosmos-sdk/simapp/simd/cmd" ) func main() { rootCmd, _ := cmd.NewRootCmd() if err := cmd.Execute(rootCmd); err != nil { switch e := err.(type) { case server.ErrorCode: os.Exit(e.Code) default: os.Exit(1) } } }

# `start` command

The start command is defined in the /server folder of the Cosmos SDK. It is added to the root command of the full-node client in the main function and called by the end-user to start their node:

# For an example app named "app", the following command starts the full-node. appd start # Using the SDK's own simapp, the following commands start the simapp node. simd start

As a reminder, the full-node is composed of three conceptual layers: the networking layer, the consensus layer and the application layer. The first two are generally bundled together in an entity called the consensus engine (Tendermint Core by default), while the third is the state-machine defined with the help of the Cosmos SDK. Currently, the Cosmos SDK uses Tendermint as the default consensus engine, meaning the start command is implemented to boot up a Tendermint node.

The flow of the start command is pretty straightforward. First, it retrieves the config from the context in order to open the db (a leveldb (opens new window) instance by default). This db contains the latest known state of the application (empty if the application is started from the first time.

With the db, the start command creates a new instance of the application using an appCreator function:

Copy app := appCreator(ctx.Logger, db, traceWriter, ctx.Viper)

Note that an appCreator is a function that fulfills the AppCreator signature: Copy // AppCreator is a function that allows us to lazily initialize an // application using various configurations. AppCreator func(log.Logger, dbm.DB, io.Writer, AppOptions) Application

In practice, the constructor of the application is passed as the appCreator.

Copy func newApp(logger log.Logger, db dbm.DB, traceStore io.Writer, appOpts servertypes.AppOptions) servertypes.Application { var cache sdk.MultiStorePersistentCache if cast.ToBool(appOpts.Get(server.FlagInterBlockCache)) { cache = store.NewCommitKVStoreCacheManager() } skipUpgradeHeights := make(map[int64]bool) for _, h := range cast.ToIntSlice(appOpts.Get(server.FlagUnsafeSkipUpgrades)) { skipUpgradeHeights[int64(h)] = true } pruningOpts, err := server.GetPruningOptionsFromFlags(appOpts) if err != nil { panic(err) } snapshotDir := filepath.Join(cast.ToString(appOpts.Get(flags.FlagHome)), "data", "snapshots") snapshotDB, err := sdk.NewLevelDB("metadata", snapshotDir) if err != nil { panic(err) } snapshotStore, err := snapshots.NewStore(snapshotDB, snapshotDir) if err != nil { panic(err) } return simapp.NewSimApp( logger, db, traceStore, true, skipUpgradeHeights, cast.ToString(appOpts.Get(flags.FlagHome)), cast.ToUint(appOpts.Get(server.FlagInvCheckPeriod)), simapp.MakeTestEncodingConfig(), // Ideally, we would reuse the one created by NewRootCmd. appOpts, baseapp.SetPruning(pruningOpts), baseapp.SetMinGasPrices(cast.ToString(appOpts.Get(server.FlagMinGasPrices))), baseapp.SetHaltHeight(cast.ToUint64(appOpts.Get(server.FlagHaltHeight))), baseapp.SetHaltTime(cast.ToUint64(appOpts.Get(server.FlagHaltTime))), baseapp.SetMinRetainBlocks(cast.ToUint64(appOpts.Get(server.FlagMinRetainBlocks))), baseapp.SetInterBlockCache(cache), baseapp.SetTrace(cast.ToBool(appOpts.Get(server.FlagTrace))), baseapp.SetIndexEvents(cast.ToStringSlice(appOpts.Get(server.FlagIndexEvents))), baseapp.SetSnapshotStore(snapshotStore), baseapp.SetSnapshotInterval(cast.ToUint64(appOpts.Get(server.FlagStateSyncSnapshotInterval))), baseapp.SetSnapshotKeepRecent(cast.ToUint32(appOpts.Get(server.FlagStateSyncSnapshotKeepRecent))), ) }

Then, the instance of app is used to instanciate a new Tendermint node:

Copy tmNode, err := node.NewNode( cfg, pvm.LoadOrGenFilePV(cfg.PrivValidatorKeyFile(), cfg.PrivValidatorStateFile()), nodeKey, proxy.NewLocalClientCreator(app), genDocProvider, node.DefaultDBProvider, node.DefaultMetricsProvider(cfg.Instrumentation), ctx.Logger.With("module", "node"), )

The Tendermint node can be created with app because the latter satisfies the abci.Application interface (opens new window) (given that app extends baseapp). As part of the NewNode method, Tendermint makes sure that the height of the application (i.e. number of blocks since genesis) is equal to the height of the Tendermint node. The difference between these two heights should always be negative or null. If it is strictly negative, NewNode will replay blocks until the height of the application reaches the height of the Tendermint node. Finally, if the height of the application is 0, the Tendermint node will call InitChain on the application to initialize the state from the genesis file.

Once the Tendermint node is instanciated and in sync with the application, the node can be started:

Copy if err := tmNode.Start(); err != nil { return err }

Upon starting, the node will bootstrap its RPC and P2P server and start dialing peers. During handshake with its peers, if the node realizes they are ahead, it will query all the blocks sequentially in order to catch up. Then, it will wait for new block proposals and block signatures from validators in order to make progress.