Libraries

Name	Description
liblimenka_cli	RPC client functionality used by limenka-cli executable
liblimenka_common	Home for common functionality shared by different executables and libraries. Similar to liblimenka_util, but higher-level (see Dependencies).
liblimenka_consensus	Consensus functionality used by liblimenka_node and liblimenka_wallet and also exposed as a shared library.
liblimenkaconsensus	Stable, backwards-compatible shared library build of static liblimenka_consensus library
liblimenka_crypto	Hardware-optimized functions for data encryption, hashing, message authentication, and key derivation.
liblimenka_kernel	Consensus engine and support library used for validation by liblimenka_node.
liblimenkaqt	GUI functionality used by limenka-qt and limenka-gui executables.
liblimenka_ipc	IPC functionality used by limenka-node, limenka-wallet, limenka-gui executables to communicate when `-DWITH_MULTIPROCESS=ON` is used.
liblimenka_node	P2P and RPC server functionality used by limenkad and limenka-qt executables.
liblimenka_util	Home for common functionality shared by different executables and libraries. Similar to liblimenka_common, but lower-level (see Dependencies).
liblimenka_wallet	Wallet functionality used by limenkad and limenka-wallet executables.
liblimenka_wallet_tool	Lower-level wallet functionality used by limenka-wallet executable.
liblimenka_zmq	ZeroMQ functionality used by limenkad and limenka-qt executables.

Conventions

• Most libraries are internal libraries and have APIs which are completely unstable! There are few or no restrictions on backwards compatibility or rules about external dependencies. Exceptions are liblimenka_consensus and liblimenka_kernel which have external interfaces documented at ../shared-libraries.md.

• Generally each library should have a corresponding source directory and namespace. Source code organization is a work in progress, so it is true that some namespaces are applied inconsistently, and if you look at `add_library(limenka_* ...)` lists you can see that many libraries pull in files from outside their source directory. But when working with libraries, it is good to follow a consistent pattern like:

- liblimenka_node code lives in src/node/ in the node:: namespace - liblimenka_wallet code lives in src/wallet/ in the wallet:: namespace - liblimenka_ipc code lives in src/ipc/ in the ipc:: namespace - liblimenka_util code lives in src/util/ in the util:: namespace - liblimenka_consensus code lives in src/consensus/ in the Consensus:: namespace

Dependencies

• Libraries should minimize what other libraries they depend on, and only reference symbols following the arrows shown in the dependency graph below:

<table><tr><td>

%%{ init : { "flowchart" : { "curve" : "basis" }}}%%

graph TD;

limenka-cli[limenka-cli]-->liblimenka_cli;

limenkad[limenkad]-->liblimenka_node;
limenkad[limenkad]-->liblimenka_wallet;

limenka-qt[limenka-qt]-->liblimenka_node;
limenka-qt[limenka-qt]-->liblimenkaqt;
limenka-qt[limenka-qt]-->liblimenka_wallet;

limenka-wallet[limenka-wallet]-->liblimenka_wallet;
limenka-wallet[limenka-wallet]-->liblimenka_wallet_tool;

liblimenka_cli-->liblimenka_util;
liblimenka_cli-->liblimenka_common;

liblimenka_consensus-->liblimenka_crypto;

liblimenka_common-->liblimenka_consensus;
liblimenka_common-->liblimenka_crypto;
liblimenka_common-->liblimenka_util;

liblimenka_kernel-->liblimenka_consensus;
liblimenka_kernel-->liblimenka_crypto;
liblimenka_kernel-->liblimenka_util;

liblimenka_node-->liblimenka_consensus;
liblimenka_node-->liblimenka_crypto;
liblimenka_node-->liblimenka_kernel;
liblimenka_node-->liblimenka_common;
liblimenka_node-->liblimenka_util;

liblimenkaqt-->liblimenka_common;
liblimenkaqt-->liblimenka_util;

liblimenka_util-->liblimenka_crypto;

liblimenka_wallet-->liblimenka_common;
liblimenka_wallet-->liblimenka_crypto;
liblimenka_wallet-->liblimenka_util;

liblimenka_wallet_tool-->liblimenka_wallet;
liblimenka_wallet_tool-->liblimenka_util;

classDef bold stroke-width:2px, font-weight:bold, font-size: smaller;
class limenka-qt,limenkad,limenka-cli,limenka-wallet bold

</td></tr><tr><td>

Dependency graph. Arrows show linker symbol dependencies. Crypto lib depends on nothing. Util lib is depended on by everything. Kernel lib depends only on consensus, crypto, and util.

</td></tr></table>

• The graph shows what linker symbols (functions and variables) from each library other libraries can call and reference directly, but it is not a call graph. For example, there is no arrow connecting liblimenka_wallet and liblimenka_node libraries, because these libraries are intended to be modular and not depend on each other's internal implementation details. But wallet code is still able to call node code indirectly through the interfaces::Chain abstract class in `interfaces/chain.h` and node code calls wallet code through the interfaces::ChainClient and interfaces::Chain::Notifications abstract classes in the same file. In general, defining abstract classes in `src/interfaces/` can be a convenient way of avoiding unwanted direct dependencies or circular dependencies between libraries.

• liblimenka_crypto should be a standalone dependency that any library can depend on, and it should not depend on any other libraries itself.

• liblimenka_consensus should only depend on liblimenka_crypto, and all other libraries besides liblimenka_crypto should be allowed to depend on it.

• liblimenka_util should be a standalone dependency that any library can depend on, and it should not depend on other libraries except liblimenka_crypto. It provides basic utilities that fill in gaps in the C++ standard library and provide lightweight abstractions over platform-specific features. Since the util library is distributed with the kernel and is usable by kernel applications, it shouldn't contain functions that external code shouldn't call, like higher level code targeted at the node or wallet. (liblimenka_common is a better place for higher level code, or code that is meant to be used by internal applications only.)

• liblimenka_common is a home for miscellaneous shared code used by different Limenka applications. It should not depend on anything other than liblimenka_util, liblimenka_consensus, and liblimenka_crypto.

• liblimenka_kernel should only depend on liblimenka_util, liblimenka_consensus, and liblimenka_crypto.

• The only thing that should depend on liblimenka_kernel internally should be liblimenka_node. GUI and wallet libraries liblimenkaqt and liblimenka_wallet in particular should not depend on liblimenka_kernel and the unneeded functionality it would pull in, like block validation. To the extent that GUI and wallet code need scripting and signing functionality, they should be able to get it from liblimenka_consensus, liblimenka_common, liblimenka_crypto, and liblimenka_util, instead of liblimenka_kernel.

• GUI, node, and wallet code internal implementations should all be independent of each other, and the liblimenkaqt, liblimenka_node, liblimenka_wallet libraries should never reference each other's symbols. They should only call each other through `src/interfaces/` abstract interfaces.

Work in progress

• Validation code is moving from liblimenka_node to liblimenka_kernel as part of The liblimenkakernel Project #27587