Introduction to EOS system contract chain accounts

First, the purpose

This document focuses on the use of the nine basic chain accounts of the EOS system contract in the source code. It is suitable for beginners and developers who want to understand the system contract chain accounts, and helps them quickly understand and get started with the creation and creation of EOS system contract chain accounts. use.

2. Introduction to chain accounts

EOS accounts are human-readable identifiers stored on the blockchain. Determined by the permission configuration, whether the account is authorized by an individual or multiple people. EOS accounts have a 12-character limit (allowing characters a~z, 1~5), which are derived from the base-32 encoding of a 64-bit integer.

EOS short accounts are accounts purchased through auctions between accounts, such as: com, a, etc. Short accounts are very rare. The secondary account created by the short account obtained through the auction is also a short account, similar to a website domain name. For example, a com account can create sub-accounts such as a.com and 1.com. Short accounts can participate in account bidding to obtain them, but the auction transaction price generally ranges from thousands to tens of thousands of EOS. You can also purchase a secondary account from a short account owner, such as purchasing an ee account from an e account.

3. Introduction to system chain accounts

1. System account introduction

In the origin of the EOSIO-based blockchain, only one account existed, which was the eosio account. It is the main system account, and there are several other system accounts that are created from it. The following are several important system accounts:

account	privilege	contract	describe
Jesus	yes	`eosio.system`contract	The main system account on the EOSIO-based blockchain.
eosio.msig	yes	`eosio.msig`contract	Multi-signature transaction proposals are allowed to be signed for later execution if all required parties sign the proposal before the expiration time.
eosio.wrap	yes	`eosio.wrap`contract	Simplify block producer operations for superusers by making them more readable and easier to audit.
eosio.token	no	`eosio.token`contract	Defines the structure and operations that allow users to create, issue and manage tokens on EOSIO-based blockchains.
eosio.names	no	no	The account that holds namespace auction funds.
eosio.bpay	no	no	The account that pays block producers for producing blocks. It allocates 0.25% inflation based on the number of blocks created by block producers in the past 24 hours.
eosio.ram	no	no	An account that tracks SYS balances based on user purchases or sales of RAM.
eosio.ramfee	no	no	Account that tracks fees collected from users’ RAM trading behavior: 0.5% of the value of each trade goes into the account.
eosio.saving	no	no	Hold an account with 4% network inflation.
eosio.stake	no	no	An account that tracks all SYS tokens that have been staked for NET or CPU bandwidth.
eosio.vpay	no	no	The block producer's account is paid accordingly based on the votes won. It allocates an inflation rate of 0.75% based on the number of votes won by block producers in the past 24 hours.
eosio.rex	no	no	An account that tracks fees and balances incurred by REX-related operations.

2. Use of chain accounts in source code

（1）eosio.msig

In EOS, eosio.msig is a special chain account used to manage multi-signature (multisig) operations and deploy proposal contracts.

Multi-signature (Multisig): Multi-signature is a security mechanism in which authorization from multiple accounts is required to perform certain sensitive operations or transactions. For the eosio.msig account, multiple accounts can be configured to require authorization to perform transactions.

eosio.msig account function: The eosio.msig account is a special account in the EOS.0 software platform, responsible for managing and executing multi-signature operations.

Multi-signature transaction execution process:

Create a proposal: Use the eosio.msig account to create a proposal that includes the transaction to be executed and the required signature authorization list.
Authorized signature: Accounts participating in multi-signature sign proposals according to the specified authorization list. Once all signatures are authorized, the proposal is ready for execution.

Executing proposals: The eosio.msig account can execute proposals that have collected sufficient authorized signatures, thereby triggering the execution of transactions.

（2）eosio.names

eosio.names: The account that holds namespace auction funds. Bid name operation, allowing account bidders to bid for the name newname. The parameters are as follows:

bidder: the account that received the refund;

newname: the name of the bid;

bid: the number of system tokens paid for the bid;

The account's alias definition in the source code eosio.system.hpp:

` static constexpr eosio::name names_account{"eosio.names"_n};`

Usage in source code eosio.system/src/namebidding.cpp:

void system_contract::bidname( const name& bidder, const name& newname, const asset& bid ) {
      ......//other code
        
      require_auth( bidder );check( (bool)newname
      check( newname.suffix() == newname, "you can only bid on top-level suffix" );

      check( (bool)newname, "the empty name is not a valid account name to bid on" );
      check( (newname.value & 0xFull) == 0, "13 character names are not valid account names to bid on" );
      check( (newname.value & 0x1F0ull) == 0, "accounts with 12 character names and no dots can be created without bidding required" );
      check( !is_account( newname ), "account already exists" );
      check( bid.symbol == core_symbol(), "asset must be system token" );
      check( bid.amount > 0, "insufficient bid" );
    
      //Tokens transferred from bidder to names_account
      token::transfer_action transfer_act{ token_account, { {bidder, active_permission} } };
      transfer_act.send( bidder, names_account, bid, std::string("bid name ")+ newname.to_string() );
}

A bid refund action that allows the account bidder to get back the amount bid so far on the name newname. The parameters are as follows:

bidder: the account that received the refund;

newname: the name of the bid; now refundable;

Usage in source code eosio.system/src/namebidding.cpp:

void system_contract::bidrefund( const name& bidder, const name& newname ) {
      bid_refund_table refunds_table(get_self(), newname.value);
      auto it = refunds_table.find( bidder.value );
      check( it != refunds_table.end(), "refund not found" );

      //Tokens are transferred from names_account to bidder
      token::transfer_action transfer_act{ token_account, { {names_account, active_permission}, {bidder, active_permission} } };
      transfer_act.send( names_account, bidder, asset(it->amount), std::string("refund bid on name")+(name{newname}).to_string() );
      refunds_table.erase( it );
   }

(3) Use of eosio.saving, eosio.bpay and eosio.vpay

eosio.saving: An account holding 4% network inflation.

eosio.bpay: Account that pays block producers to produce blocks, with 0.25% inflation allocated based on the number of blocks created by the block producer in the past 24 hours.

eosio.vpay: An account that pays block producers corresponding fees with won votes. An inflation rate of 0.75% is allocated based on the number of votes won by the block producer in the past 24 hours.

The account's alias definition in the source code eosio.system.hpp:

static constexpr eosio::name saving_account{"eosio.saving"_n};
static constexpr eosio::name bpay_account{"eosio.bpay"_n};
static constexpr eosio::name vpay_account{"eosio.vpay"_n};

Usage in source code eosio.system/src/producer_pay.cpp:

        if( new_tokens > 0 ) {
            {
               token::issue_action issue_act{ token_account, { {get_self(), active_permission} } };
               issue_act.send( get_self(), asset(new_tokens, core_symbol()), "issue tokens for producer pay and savings" );
            }
            {
               token::transfer_action transfer_act{ token_account, { {get_self(), active_permission} } };
               if( to_savings > 0 ) {
                  transfer_act.send( get_self(), saving_account, asset(to_savings, core_symbol()), "unallocated inflation" );
               }
               if( to_per_block_pay > 0 ) {
                  transfer_act.send( get_self(), bpay_account, asset(to_per_block_pay, core_symbol()), "fund per-block bucket" );
               }
               if( to_per_vote_pay > 0 ) {
                  transfer_act.send( get_self(), vpay_account, asset(to_per_vote_pay, core_symbol()), "fund per-vote bucket" );
               }
            }
         }

(4) Use of eosio.ram and eosio.ramfee

eosio.ram: An account that tracks SYS balances based on user purchases or sales of ram.

eosio.ramfee: An account that tracks fees collected from user ram transactions, with 0.5% of the value of each transaction going into this account.

The account's alias definition in the source code eosio.system.hpp:

static constexpr eosio::name ram_account{"eosio.ram"_n};
static constexpr eosio::name ramfee_account{"eosio.ramfee"_n};

When buying RAM, the payer irreversibly transfers the amount to the system contract, and only the recipient can withdraw the tokens through a sellram operation. The recipient pays the storage costs of all database records associated with this operation. RAM is a scarce resource and its supply is defined by the global property max_RAM_size. RAM is priced using the bancor algorithm such that the price per byte has a constant reserve ratio of 100:1.

Usage in source code eosio.system/src/delegate_bandwidth.cpp:

     // If quant.amount>1, then quant_after_fee.amount should be>0. If quant.amaunt==1, then quant_after_fee.amount==0, and the next inline transfer will fail, causing the buyram operation to fail.
      {
         token::transfer_action transfer_act{ token_account, { {payer, active_permission}, {ram_account, active_permission} } };
         transfer_act.send( payer, ram_account, quant_after_fee, "buy ram" );
      }
      if ( fee.amount > 0 ) {
         token::transfer_action transfer_act{ token_account, { {payer, active_permission} } };
         transfer_act.send( payer, ramfee_account, fee, "ram fee" );
         channel_to_rex( ramfee_account, fee );
      }

(5) Use of eosio.stake

eosio.stake: Tracks all accounts staking SYS tokens for NET or CPU Broadband.

The account's alias definition in the source code eosio.system.hpp:

static constexpr eosio::name stake_account{"eosio.stake"_n};

Usage in source code eosio.system/src/delegate_bandwidth.cpp:

auto transfer_amount = net_balance + cpu_balance;//NET或CPU
         if ( 0 < transfer_amount.amount ) {
            token::transfer_action transfer_act{ token_account, { {source_stake_from, active_permission} } };
            transfer_act.send( source_stake_from, stake_account, asset(transfer_amount), "stake bandwidth" );
         }

(6) Use of eosio.rex

eosio.rex: Account that tracks fees and balances generated by REX-related operations.

The account's alias definition in the source code eosio.system.hpp:

static constexpr eosio::name rex_account{"eosio.rex"_n};

Usage in source code eosio.system\src\rex.cpp:

const asset payment = from_net + from_cpu;
      // inline transfer from stake_account to rex_account inline transfer from stake_account to rex_account
      {
         token::transfer_action transfer_act{ token_account, { stake_account, active_permission } };
         transfer_act.send( stake_account, rex_account, payment, "buy REX with staked tokens" ); //Buy REX with staked tokens
      }
      const asset rex_received = add_to_rex_pool( payment );
      add_to_rex_balance( owner, payment, rex_received );
      runrex(2);
      update_rex_account( owner, asset( 0, core_symbol() ), asset( 0, core_symbol() ), true );
      // dummy action added so that amount of REX tokens purchased shows up in action trace
      rex_results::buyresult_action buyrex_act( rex_account, std::vector<eosio::permission_level>{ } );
      buyrex_act.send( rex_received );