As stated in last week’s blog, Binance, the fast-growing cryptocurrency exchange, can greatly benefit from Inery's blockchain-based decentralized database management system to enhance its performance, security, and data privacy. 

IneryDB addresses the limitations of traditional centralized databases like Cassandra and Redis, offering benefits such as decentralized data storage, enhanced data security, tamper resistance, and cost-effectiveness. 

Inery’s solution provides a reliable and secure database management system that is highly scalable, easily integrated, and can handle sensitive financial data; while protecting Binance from unauthorized access and breaches. By partnering with Inery, Binance can overcome its database challenges and enhance its overall operational efficiency. 

Here is an overview of Inery’s technical aspect for Binance:

Tables:

historical_trade_data: This table stores historical trade data with the following parameters:

trade_id: The unique identifier for each trade.

timestamp: The timestamp for when the trade occurred.

price: The price at which the trade was executed.

volume: The volume of the trade.

symbol: The symbol for the asset being traded.

 

order_data: This table stores information about orders placed by users with the following parameters:

order_id: The unique identifier for each order.

timestamp: The timestamp for when the order was placed.

user_id: The unique identifier for the user who placed the order.

symbol: The symbol for the asset being traded.

order_type: The type of order (e.g., limit, market, stop).

order_side: The side of the order (e.g., buy, sell).

price: The price specified in the order.

quantity: The quantity specified in the order.

status: The status of the order (e.g., filled, partially filled, canceled).

 

account_data: This table stores information about user accounts with the following parameters:

user_id: The unique identifier for each user.

account_balance: The balance of the user's account.

currency: The currency in which the account balance is denominated.

 

user_activity_logs: This table stores logs of user activity with the following parameters:

log_id: The unique identifier for each log entry.

user_id: The unique identifier for the user who generated the log entry.

activity_type: The type of activity (e.g., login, logout, trade).

timestamp: The timestamp for when the activity occurred.

 

transaction_data: This table stores information about transactions with the following parameters:

transaction_id: The unique identifier for each transaction.

user_id: The unique identifier for the user who initiated the transaction.

transaction_type: The type of transaction (e.g., deposit, withdrawal, trade).

timestamp: The timestamp for when the transaction occurred.

amount: The amount involved in the transaction.

currency: The currency in which the transaction amount is denominated.

status: The status of the transaction (e.g., completed, pending, failed).

 

market_data: This table stores market data with the following parameters:

symbol: The symbol for the asset.

last_price: The last traded price for the asset.

volume: The trading volume for the asset.

timestamp: The timestamp for when the market data was updated.

 

compliance_data: This table stores information about compliance checks with the following parameters:

compliance_id: The unique identifier for each compliance check.

user_id: The unique identifier for the user being checked.

compliance_type: The type of compliance check (e.g., KYC, AML).

compliance_status: The status of the compliance check (e.g., passed, failed).

user_authentication_tokens: This table stores authentication tokens for users with the following parameters:

user_id: The unique identifier for each user.

auth_token: The authentication token for the user.

 

user_session_data: This table stores information related to the active user sessions in the system. The parameters for this table are:

session_id: unique identifier for the session

user_id: unique identifier for the user associated with the session

session_data: session-specific data (e.g. user preferences, shopping cart contents, etc.)

timestamp: the time when the session was started

 

trading_data: This table stores information related to trades that have been executed in the system. The parameters for this table are:

trade_id: unique identifier for the trade

user_id: unique identifier for the user who placed the trade

symbol: the trading symbol (e.g. stock ticker) for the asset being traded

order_type: the type of order (e.g. market, limit, stop) used for the trade

order_side: the buy/sell direction for the trade

price: the price at which the trade was executed

quantity: the amount of the asset traded

status: the status of the trade (e.g. filled, canceled, pending)

timestamp: the time when the trade was executed

 

api_keys: This table stores information related to the API keys used by users in the system. The parameters for this table are:

user_id: unique identifier for the user associated with the API key

api_key: unique identifier for the API key

api_secret: secret key associated with the API key

 

distributed_locks: This table stores information related to distributed locks used in the system to prevent concurrent access to shared resources. The parameters for this table are:

lock_id: unique identifier for the lock

lock_status: the status of the lock (e.g. locked, unlocked)

timestamp: the time when the lock was acquired or released

 

message_queues: This table stores information related to message queues used in the system to facilitate communication between different components. The parameters for this table are:

queue_id: unique identifier for the message queue

queue_data: the data contained in the message

timestamp: the time when the message was added to the queue

Actions:

create_trade(trade_id, timestamp, price, volume, symbol): Adds a new trade to the historical trade data table with the given trade ID, timestamp, price, volume, and symbol.

place_order(order_id, timestamp, user_id, symbol, order_type, order_side, price, quantity): Places a new order in the order data table with the given order ID, timestamp, user ID, symbol, order type, order side, price, and quantity.

update_account_balance(user_id, new_balance): Updates the account balance for the given user ID in the account data table with the new balance value.

log_user_activity(log_id, user_id, activity_type, timestamp): Adds a new user activity log to the user activity logs table with the given log ID, user ID, activity type, and timestamp.

record_transaction(transaction_id, user_id, transaction_type, timestamp, amount, currency, status): Records a new transaction in the transaction data table with the given transaction ID, user ID, transaction type, timestamp, amount, currency, and status.

update_market_data(symbol, last_price, volume, timestamp): Updates the market data table with the latest information on the given symbol, including its last price, volume, and timestamp.

add_compliance_entry(compliance_id, user_id, compliance_type, compliance_status): Adds a new compliance entry to the compliance data table with the given compliance ID, user ID, compliance type, and compliance status.

generate_authentication_token(user_id): Generates a new authentication token for the given user ID and adds it to the user authentication tokens table.

create_user_session(session_id, user_id, session_data, timestamp): Creates a new user session in the user session data table with the given session ID, user ID, session data, and timestamp.

update_trade(trade_id, user_id, symbol, order_type, order_side, price, quantity, status, timestamp): Updates the trade data table with the latest information on the given trade ID, including the user ID, symbol, order type, order side, price, quantity, status, and timestamp.

create_trading_strategy(strategy_id, user_id, strategy_name, strategy_params): Creates a new trading strategy in the trading strategies table with the given strategy ID, user ID, strategy name, and strategy parameters.

create_api_key(user_id, api_key, api_secret): Creates a new API key for the given user ID and adds it to the API keys table, along with its corresponding secret.

acquire_lock(lock_id, timestamp): Acquires a distributed lock with the given lock ID and timestamp and adds it to the distributed locks table.

enqueue_message(queue_id, queue_data, timestamp): Adds a new message to the message queue table with the given queue ID, message data, and timestamp.

 

 

Final Words

Use in-memory Inery blockchain database (IneryDB) in Binance with blockchain-like features to provide high performance and reliability for their trading system. The IneryDB is designed to provide transactional consistency and durability by storing data in memory and periodically persisting it to disk.

The IneryDB uses a consensus mechanism based on the Equal Proof Of Stake (EPOS) algorithm to ensure data consistency across multiple nodes in the system. Each node in the network maintains a copy of the database, and a majority of nodes must approve any changes to the database before they can be committed.

In addition to its consensus mechanism, IneryDB also provides cryptographic authentication and verification to ensure the integrity and authenticity of data. This is achieved through the use of digital signatures and hash functions.

The use of IneryDB in Binance's trading system provides several benefits, including high transaction throughput, low latency, and fault tolerance. The blockchain-like features also provide an added layer of security and transparency for the system, which is essential for a trusted and reliable trading platform.