IBAX Overview
Features
The IBAX Network (IBAX) has an integrated application development environment (IDE). It is a multi-level access control system for data, user pages and smart contracts.
In terms of its structure and functions, IBAX is quite different from most existing blockchain platforms:
The development and use of IBAX applications are in an autonomous software environment called ecosystem. Each ecosystem has its own membership rules that are initially established by the creator;
Ecosystem activities, such as the data involved in database table records or updates, are based on registers created with smart contracts. In most other blockchain platforms, activities are based on transaction exchange between accounts;
The access to registers and the control of relationships between ecosystem members are managed by a set of rules called smart laws.
Architecture
Network
IBAX is built on a peer-to-peer (P2P) network.
Guardian nodes in the network store the latest version of the blockchain database, which records the latest status of IBAX's blockchain.
Network users can receive data by sending requests from the guardian node database via Weaver or REST API commands. After signing by users, new requests are sent to the network as transactions in binary format. Essentially, these transactions are commands to modify relevant database records. Transactions are aggregated in blocks, and such blocks are sent to the blockchains of all network nodes. Each guardian node will process the transactions in the block, thereby updating the corresponding data in the database.
Honor Node
A guardian node which is privileged to generate new blocks in the network is called a honor node. The maximum number of honor nodes is defined by number_of_nodes in the platform parameters table, showing that the number of honor nodes is limited.
An Honor Node is one of the key components of IBAX Public Network. It executes and validates transactions, collects transaction information from other nodes, adds transactions to the queue, and verifies the correctness and validity of new blocks using the confirmation mechanism. Generally, it has two states: packaging and on-packaging.
An Honor Node in the packaging state delivers the highest performance. It obtains transaction requests to be executed from the transaction queue and verifies the ignature validity and correctness of transactions, e.g. transfer amount, permission for transaction operations, and accurate execution of transactions. All ransactional operations, correct or wrong (wrong transactions will be rolled back), will be written into the block. Wrong transactions will incur a punitive gas fee. Executed transactions are notified to other Honor Nodes along with the block through broadcasting.
An Honor Node in the non-packaging state is mainly responsible for block verification to ensure in-block transactions generated by a packaging node are executed orrectly. In case of an anomaly, it will trigger the exception handling mechanism and IBAX Network will roll back and re-verify the block.
In order to ensure transaction execution efficiency, Honor Nodes collect transaction information constantly.
Transactions
Transactions, including data used to implement smart contracts, are generated by Weaver.
Transactions are signed by users with a private key. The private key and Weaver's signature function can be stored in browsers, software clients, SIM cards or dedicated physical devices. In the current implementation, the private key is encrypted with the ECDSA algorithm and stored at the Weaver side. All transactions are signed with the ECDSA algorithm.
The structure of a transaction complies with the following format:
ID - ID of the contract implemented;
Params - parameters sent to the contract;
KeyID - ID of the user sending the transaction;
PublicKey - public key of the honor node;
Time - timestamp generated by the transaction;
EcosystemID - ID of the ecosystem where the transaction is made;
ТokenEcosystem - ID of the ecosystem, 1 by default, and tokens within it are used to cover the transaction costs.
Network protocol
Transactions will be sent to honor nodes by users, where they are subject to basic verification to ensure the formats are correct and then are added to the queue. Transactions are also sent to other honor nodes on the network and added to the respective queue.
A honor node is privileged to generate new blocks within a specific time period which is determined by the platform parameter full_nodes and a special algorithm. Honor nodes retrieve transactions from queues and send them to the block generator. When generating a new block, transactions in such block will also be processed: each transaction is sent to a virtual machine, where the contract corresponding to the transaction parameters is implemented, thereby updating records in the database.
New blocks should be verified to ensure there are no errors before sending to other honor nodes on other networks.
A new block will be added to the block queue when received by other honor node and, after verification, to the blockchain of the honor node where it is located to process transactions in the block, and thereby updating records in the database.
Block and transaction verification
After generating or receiving a new block, it will be verified on all other honor nodes, which cover the following:
The first byte of the data received should be 0. If not, the data received will not be considered as a block;
The received block generation timestamp should be before the current timestamp;
The block generation timestamp should correspond to the time interval at which the honor node having privilege to generate new blocks;
The height of a new block should be greater than the height of the largest block on the existing blockchain;
It cannot exceed the maximum expenses allowed for all transactions in the block;
The block must be properly signed with the secret key of the node which it is located. The signature data should contain:
The height of the block, the hash of the previous block, the timestamp of the block, the ID of the ecosystem where the block is located, and the account address of the honor node of the block;
The position of the honor node in the platform parameter full_nodes array, the Merkel Root (MrklRoot) of all transactions in the block, and the revert hash of the previous block. To check the correctness of each transaction in the block with the following methods:
The hash of each transaction must be unique;
A key-signed transaction cannot exceed the limit (max_tx_block_per_user);
It cannot exceed the limit of the maximum transaction size (max_tx_size);
The transaction time can neither be greater than the block generation time nor be greater than the block generation time plus 600 seconds, and it can be no less than the block generation time minus 86400 seconds;
The transaction must be signed properly;
The user who implements the contract must have sufficient tokens in his account to pay for the transaction cost.
Database
The underlying data storage layer of IBAX Network is a PGSQL database completely open to the public. Based on the permission design of the IBAX Operating System Platform, users do not need to worry about data security. With an object-oriented design philosophy, IBAX Network pre-compiles data through a relational PGSQL database and improves the data processing efficiency.
You may be interested in the following if you are a technical specialist, or just skip it if you are not. ① All tables without a number prefix in their name belong to permission tables of IBAX Network Basic; ② All tables with a number prefix in their name belong to permission tables of ecoLibs.
ECOLIB
It is quite easy for users, even common users, to create an ecoLib of their own on the IBAX Network System Platform. We have integrated and developed an application where ecoLib creation takes just one click.
When creating an ecoLib, you can configure the ecosystem parameters and rules, and set the administrator account and charging model. Most importantly, to apply the DPoA consensus within ecoLibs better, creators can set it up by writing or importing their own contracts.
We support quick emission of ecoLib tokens by importing contract templates.
Due to the differences in consensus and management permissions, ecoLibs fall into decentralized and centralized ones. They have no specific advantage or disadvantage by type. You should choose the appropriate one against your service needs. What to do if it is OK for now but not for the future? You can change ecoLib parameters, even the consensus mechanism, token, and governance method, on the IBAX Network System Platform. You can leave it all to the self-governance mechanism maintained by the ecoLib administrator or members (depending on the ecoLib type).
On the IBAX Network System Platform, an ecoLib has complete data control permissions and permissions to design and access independent database tables and fields. In the data control permission design, we support triggering when a field satisfies a logical expression. This feature allows for imagination space in special services like monitoring, logic satisfaction, and triggering by time and specific conditions.
There may be multiple DApps in an ecoLib, and each of them can have independent parameters. An ecoLib is like a platform where you can implement anything you want.
In order to better support ecosystem developers, we provide the editing, management, and development tool Weaver. It will reduce the ecosystem development, maintenance, and management costs greatly.
IDE
Weaver has a complete integrated development environment (IDE) for creating blockchain applications, which does not require software developers to have a deep understanding of the blockchain technology.
Weaver provides a table management tool, contract editor, page editor and other functions needed to create applications in the ecosystem, without the support of any software module.
The IDE mainly includes the following parts:
list of ecosystem parameters;
contract editor;
table management tool;
page editor and visual page designer;
multi-language resources editor;
application import/export functions.
Applications
An application is a collection of elements such as database tables, smart contracts, and user pages with access rights for configuration. The ecosystem to which the application element belongs is indicated by the prefix in the element name, such as @1ElementName, where the ecosystem ID is indicated by the number 1 after the @ symbol. When using application elements in the current ecosystem, the prefix @1 can be omitted. These applications can perform useful functions or implement various services.
Tables
In IBAX's database, each ecosystem can create an unlimited number of tables. Tables of a specific ecosystem can be identified by a prefix containing the ecosystem ID, which will not be displayed in Weaver.
A table is not bound in any way and belongs to a certain contract. It can be used by all applications within the scope of the table's access rights.
Each ecosystem can create a set of data tables for developing its applications or may, possibly, access data tables of other ecosystems by specifying the table name prefix.
By configuring access rights through smart laws, data are logged into tables. Smart laws are used for rights management.
Table table management tool
You can find the table management tool in Weaver menu Table, which cover the following functions:
View the list of tables and their entries;
Create new tables;
Add a table field and specify its data type, such as Text, Date/Time, Varchar, Character, JSON, Number, Money, Double, Binary;
Manage privileges for insert, update data and change table structure.
Table data manipulation
For better database manipulation, both Needle and Logicor have the DBFind function, which is used to retrieve values and data arrays from tables.
The contract language DBInsert function is used to add entries to tables. The DBUpdate and DBUpdateExt functions are used to update the value of an existing entry. During updating, the corresponding data in tables will be updated, and the blockchain will add new transactions while retaining all historical transactions. Data in tables can only be modified and cannot be deleted.
In order to minimize the contract implementation time, the DBFind function cannot query multiple tables simultaneously, and JOIN is not supported. Therefore, we recommend not to normalize application tables, but to store all available information in entries or repeat the information available in other tables. This is not mandatory but necessary for a blockchain application. In this case, data should be stored fully, which cannot be updated even if the same data in other tables is updated, though it is updated synchronously in a relational database.
Ecosystem Parameters
You may view and edit the list of ecosystem parameters (1_parameters) in Weaver's menu. Ecosystem parameters can be divided into the following groups:
General parameters: the account of the ecosystem creator (founder_account) and other information;
Access rights parameters: used to define access permissions for application elements
change the table structure (changing_tables);
change the contract (changing_contracts);
change the user page (changing_page);
change the menu (changing_menu);
change the multi-language resources (changing_language).
Technical parameters: used to define the user styles (stylesheet);
User parameters: used to define constants or lists (separated by commas) required for application operation.
You may specify the edit permission for parameters of each ecosystem.
You may use the EcosysParam function to retrieve the value of an ecosystem parameter by passing the ecosystem parameter title as a parameter to it.
Access rights control mechanism
IBAX has a multi-level access permission management system. By configuring access rights, you can create and change any application element, such as the contracts, tables, user pages, ecosystem parameters. You may also change the access rights through configuration.
By default, all rights in the IBAX ecosystem are managed by its creator, which is defined in the MainCondition contract of each ecosystem. But after creating smart laws, access control can be transferred to all or a group of ecosystem members. Access rights control
The access rights are defined in contract tables (1_contracts ), data tables (1_tables ), user page tables (1_pages ), menu tables (1_menu ), and code block tables (1_blocks ). You can find the corresponding menus in Weaver.
Access rights management
The rules of access rights are configured by filling in the corresponding contract expressions ContractConditions(“@1MainCondition”), ContractAccess(“@1MainCondition”) or logical expressions in the permission field. If the result of the request expression passes (true ), then access is granted. Otherwise, access is denied and related operations are terminated.
The easy way to define rights is to enter a logical expression in the right field. For example, $key_id == 8919730491904441614, where $keyid represents the ID of an ecosystem member.
The most common and recommended way to define rights is to use the ContractConditions("@1ContractsName1","@1ContractsName2") function. The contract name ContractsName is passed to the function as a parameter, and the contract result must be the result of a logical expression (true or false).
Another way to define rights is to use the ContractAccess("@1ContractsName3","@1ContractsName4") function. The contract ContractsName qualified to implement the corresponding operation can be passed to the function as a parameter. For example, if the right field of the amount column is configured as ContractAccess("@1TokenTransfer"), then you can only implement the contract @1TokenTransfer if you want to change the value in the amount column. The right to access the contract itself can be managed in the conditions section, which are quite complex and may contain many other contracts.
Exclusive rights
In case of emergencies or situations that are critical to the operation of an ecosystem, there are many special parameters in the list of ecosystem parameters (1_parameters) (such as changing_contracts, changing_pages ), etc., which defines rights to access all contracts, data tables, and pages of the current ecosystem. These rights are configured by key contracts.
Virtual private ecosystem
In IBAX, you can create a virtual private ecosystem - Cross Ledgers Base (CLB). A CLB has the full functionality of the standard ecosystem, but operates outside the blockchain. In CLB, you can use and create contracts and template languages, tables, and use Weaver to create applications. You may call contracts on the blockchain ecosystem via API.
Requests to web resources
Rights to read data
Though it is readable, data in CLB is not saved within the blockchain. You can choose to grant the read permission to database tables. You can set rights to read for individual columns, or for any row using a special contract.
CLB creation
You may create a CLB node on the network. As predefined, the CLB node administrator is privileged to use the ecosystem list with the CLB functionality, and designate a user with ecosystem creator privileges to install applications, receive new members and configure the resources access permissions.
CLB usage
You may use a CLB to create registration forms, send verification information to users via email or phone, and store publicly accessible data. You can write and test applications, and then import them into the blockchain ecosystem. In a CLB, you may use scheduling contract tasks, create oracle machines to receive data from web resources and send such data to the blockchain ecosystem.
Last updated