Steem Blockchain Platform

FC is a utility library designed to accelerate the development of asynchronous C++ libraries. It provides several core capabilities for high-performance system development:

• Asynchronous Programming: A cooperative multi-tasking library featuring support for Futures, mutexes, and signals.
• Boost ASIO Wrapper: Provides a wrapper for Boost ASIO to handle asynchronous operations cooperatively, allowing developers to write code in a synchronous style.
• Reflection & Serialization: Enables C++ reflection, allowing for automatic serialization of C++ structs into JSON and Binary formats.
• RPC Support: Automatically generates client and server stubs for reflected interfaces, supporting JSON-RPC.
• Cryptography: Includes cryptographic primitives for various hash functions and encryption algorithms.
• Infrastructure: Provides logging infrastructure and wraps several Boost APIs (such as boost::filesystem, boost::thread, and boost::exception) to accelerate compilation times.
• Process Management: Supports the unofficial Boost.Process library.

Steem uses a resource model to manage medium-to-long-term blockchain limits. A resource is any capacity the blockchain needs to limit (e.g., subsidized accounts, history bytes, market bytes, state bytes, and execution time).

For each resource, the blockchain maintains a resource pool that is influenced by three forces every block:

1. Usage: Resources consumed by user transactions are subtracted from the pool.
2. Budget: A fixed amount of resources added to the pool each block.
3. Decay: A fixed percentage of resources subtracted from the pool each block to prevent unused resources from accumulating indefinitely (exponential decay).

Key mathematical concepts for resource pools:

• Equilibrium pool level: The level where budget and decay balance (assuming zero usage).
• Half-life: The time it takes the pool to fall to 50% of its initial level (assuming zero usage/budget).
• Characteristic time: The time it takes the pool to fall to ~36.8% ($1/e$) of its initial level.

AppBase is a framework for building applications composed of plugins. It manages the lifecycle of these plugins to ensure they are configured, initialized, started, and shut down in the correct order based on their dependencies.

Plugin Lifecycle

Every plugin follows these three steps:

1. Initialize: Parse configuration file options.
2. Startup: Begin execution using the parsed configuration.
3. Shutdown: Stop operations and free resources.

Lifecycle Rules:

• All plugins must complete the Initialize step before any plugin enters the Startup step.
• Dependencies: If a plugin specifies a dependency using APPBASE_PLUGIN_REQUIRES, the required plugin will be Initialized or Started before the dependent plugin.
• Shutdown Order: Shutdown is performed in the exact reverse order of Startup.

class net_plugin : public appbase::plugin<net_plugin>
{
   public:
     net_plugin(){};
     ~net_plugin(){};

     APPBASE_PLUGIN_REQUIRES( (chain_plugin) );

     virtual void set_program_options( options_description& cli, options_description& cfg ) override
     { ... }

     void plugin_initialize( const variables_map& options ) { ... }
     void plugin_startup()  { ... }
     void plugin_shutdown() { ... }
};

Automated Actions are categorized into two types based on how nodes handle them:

Required Actions

• Mandatory: Must be included in blocks and verified trustlessly by every steemd node.
• Deterministic: Nodes track expected required actions and apply them in lock-step. Blocks must include these actions in the exact order they are generated by the local node; failure to do so results in consensus rejection.
• Execution Timing: Actions have an execution time and can only be included when the execution time is $\le$ the head block time.
• Ordering: Pending actions are paginated by execution time and follow FIFO (First-In-First-Out) order within each time slot.
• Block Space: 25% of the block size is reserved for required actions. To accommodate this, block generation typically fills user transactions only up to 75% of the block size.

Optional Actions

• Non-Mandatory: Not required to be included in every block. They can be skipped if block space is unavailable.
• Flexible Ordering: Can be included in any order.
• Resource Constraints: For SMTs (Steem Minted Tokens), optional actions like token emissions are excluded from block generation if there are insufficient Resource Credits (RCs).
• Lifecycle: In the reference implementation, pending optional actions are removed from state once their execution time is $\le$ the last irreversible block's block time.