Add docs

docs/README.md

@@ -6,3 +6,39 @@ slug: /
 # IBAX Documentation
 
 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.
+
+## Concept
+
+* [IBAX Overview](concepts/about-the-platform)
+* [The IBAX Network](concepts/blockchain-layers)
+* [Proof-of-Authority Consensus](concepts/consensus)
+* [Terms and Definitions](concepts/thesaurus)
+* [FAQ](concepts/faq)
+
+## Tutorial
+
+* [Tutorial for application development](tutorials/app_tutorial)
+* [Development Tutorial](tutorials/tutorial)
+
+## Guide
+
+* [Smart Contracts](topics/script)
+* [Template Language](topics/templates2)
+* [Compiler and Virtual Machine](topics/vm)
+* [Daemon](topics/daemons)
+
+## Reference
+
+* [RESTful API](reference/api2)
+* [Platform Parameters](reference/platform-parameters)
+* [Server Configuration File](reference/backend-config)
+* [Synchronized Monitoring Tool](reference/desync_monitor)
+* [JSON-RPC Application Programming Interface](reference/json-rpc)
+
+## Deployment
+
+* [Deployment of A IBAX Network](howtos/deployment)
+
+## Needle Language
+
+- [Specification](/needle/spec)

docs/concepts/blockchain-layers.md

@@ -0,0 +1,113 @@
+# The IBAX Network {#the-ibax-network}
+
+
+In this section, we will brief you how to use IBAX.
+
+- [The IBAX Network](#the-ibax-network)
+  - [Application developers](#application-developers)
+  - [ECOLIB members](#ecolib-members)
+  - [ECOLIB applications and platform applications](#ecolib-applications-and-platform-applications)
+  - [Underlying model](#underlying-model)
+  - [Implementation](#implementation)
+
+
+
+If you are interested in the development, use or management of applications in IBAX, then you may not need to understand it at all.
+
+In IBAX, the blockchain and the blockchain network are hidden from ECOLIB members, administrators, and application developers. IBAX offers [RESTful API](../reference/api2.md) for all user groups, which provide a tamper-proof and distributed access to the **global state** of the blockchain.
+
+## Application developers {#application-developers}
+
+In technical terms, the **global state** is a set of data, which is implemented via IBAX's database. From the perspective of application developers, an application interacts with the database by querying, inserting and updating tables.
+
+In IBAX, transactions are written into the blockchain by implementing various contracts. These transactions will call contract codes implemented by blockchain network nodes, which will update the global state (database) accordingly.
+
+For application developers, a contract is a function that data will be written to the database when it is implemented. Pages are like scripts and the page code is a set of page [template](../topics/templates2.md) functions, some of these functions display page elements, while other data comes from the database. Application developers do not need to understand what are transactions, block generation and consensus algorithms, just use it.
+
+## ECOLIB members {#ecolib-members}
+
+Applications written by developers run in an environment called [ECOLIB](thesaurus.md#ecolib). An application usually serves a specific purpose and complete various tasks together with several other applications.
+
+A user must become a member of an ECOLIB if wants to access applications in it, and it can be a member of multiple different ECOLIBs at the same time.
+
+ECOLIB members can view and modify the database from application pages, just like filling out forms, clicking buttons and navigating pages in a common web application.
+
+## ECOLIB applications and platform applications {#ecolib-applications-and-platform-applications}
+
+Applications may fall into **ECOLIB applications** and **platform applications**.
+
+> ECOLIB applications
+
+An ECOLIB application implements certain unique functions or business processes of an ECOLIB, but it is only available in that ECOLIB.
+
+> Platform applications
+
+A platform application is applicable to all ECOLIBs. Any application could be developed as a platform application. IBAX developers would provide platform applications that support the core functions for ECOLIB governance, such as voting, notification, and ECOLIB member role management.
+
+## Underlying model {#underlying-model}
+
+> Definition of layers
+
+IBAX consists of several layers:
+
+* User interaction layer
+
+    ECOLIB members interact with the application through pages and page elements.
+
+* Application layer
+
+    Application developers interact with the global state (data tables) through contract codes and page codes.
+
+* Global state layer
+
+    Update and synchronize the global state (database) based on operations written to the distributed ledger (blockchain)
+
+* Blockchain layer
+
+    Update the distributed ledger with new blocks. Operations (transactions) saved in new blocks must be performed on the global state.
+
+* Node network layer
+
+    It implemented the IBAX Network protocol, which distributes, verifies transactions and generates new blocks on the node network. Similarly, new blocks are distributed and verified by the node network.
+
+    The distributed ledger of all nodes is kept in sync. If having conflicts in a node, the node will identify which blockchains are considered valid and invalid blockchains will be rolled back accordingly.
+
+* Transaction layer
+
+    Transactions are the basis for generating blocks and blockchain protocols, and transactions themselves are the results of operations performed at the user interaction layer. Transactions are generated by Weaver.
+
+    When a user or developer performs an operation such as clicking a button on a page or implement a contract from the code editor, Weaver will convert this operation into a transaction and send it to the network node connected to it.
+
+Therefore, the flow of transactions is as follows:
+
+  * A user operation in a user page will become a transaction;
+  * The transaction is contained in a block;
+  * The block is included in the blockchain;
+  * The change of operation will cause the global state of the blockchain to change, and such operation will be applied to the database;
+  * Any database change will be reflected in the application.
+
+## Implementation {#implementation}
+
+IBAX has two major components, i.e. server [go-ibax](https://github.com/IBAX-io/go-ibax) and Weaver [Source code](https://github.com/IBAX-io/weaver).
+
+Weaver:
+  * Providing the user pages;
+
+  * Providing the IDE for application development;
+
+  * Storing public keys of user accounts and perform authorization;
+
+  * Requesting database data from application pages and display application pages to users;
+
+  * Sending transactions to the server through [REST APIs](../reference/api2.md);
+
+      In order to automatically create transactions against user operations, Weaver will convert such operations into transactions when application developers implement a contract from the IDE.
+
+Server:
+
+  * Keeping the global state (database) of the node;
+  * Implementation of the blockchain protocol;
+  * Implementation of contract codes in the IBAX [Virtual Machine](../topics/vm.md);
+  * Implementation of page codes in the [Template Engine](../topics/templates2.md);
+  * Implementation of [RESTful API](../reference/api2.md).
+

docs/concepts/consensus.md

@@ -0,0 +1,153 @@
+
+# Decentralized Proof-of-Authority Consensus {#decentralized-proof-of-authority-consensus}
+
+* What is Decentralized Proof-of-Authority consensus
+
+* Advantages of DPoA consensus
+
+* DPoA consensus and common means of attack
+
+* Implementation of DPoA consensus in IBAX
+
+In this section, we will describe the Decentralized Proof-of-Authority consensus and its implementation in IBAX. 
+
+
+ - [What is Decentralized Proof-of-Authority consensus](#what-is-decentralized-proof-of-authority-consensus)
+  - [Advantages of DPoA consensus](#advantages-of-dpoa-consensus)
+  - [DPoA consensus and common means of attack](#dpoa-consensus-and-common-means-of-attack)
+    - [DoS](#dos)
+    - [51 percent attack](#percent-attack-51)
+  - [Implementation of DPoA consensus in IBAX](#implementation-of-dpoa-consensus-in-ibax)
+    - [Honor node](#honor-node)
+    - [Leader node](#leader-node)
+    - [Generation of new blocks](#generation-of-new-blocks)
+    - [Forks](#forks)
+
+## What is Decentralized Proof-of-Authority consensus {#what-is-decentralized-proof-of-authority-consensus}
+
+Considering commercial application scenarios and real-world environments, IBAX Network has built a new consensus mechanism, DPoA (Decentralized Proof of Authority). 
+
+Decentralization has always been our firm belief. It refers not only to IBAX’s infrastructure network environment. Instead, we will let decentralization take root in each ecoLib created in IBAX Network and use technical solutions to achieve a high degree of self-governance in each of them. For the purpose of highly distributed self-governance, we have made many changes in the overall architecture and technical implementation. However, in practice, we cannot avoid the centralized management concept. In order to find a balance between centralization and decentralization, in addition to the DPoA consensus mechanism, we have also formulated certain reward and incentive programs.
+
+IBAX Network has created a new consensus mechanism that combines distribution, weak centralization, and a certification authority. We call it DPoA (Decentralized Proof of Authority). To ensure continuity for the entire IBAX Network, the consensus covers not only IBAX Public Network, but also ecoLibs created by each user and user group. This creates a truly self-governed, decentralized, fair, transparent, and fraud-proof Decentralized Autonomous Organization (DAO). 
+
+DPoA has a prevention mechanism against network attacks and allows creation of Mint Nodes that guard the network and mint new IBXC coins. IBAXCoin holders can stake a part of their IBXC liquidity balance in Mint Nodes for Mint & Stake Emission Rewards. Minting and staking serve to increase the cost and difficulty of attacks and increase the total value of IBXC coins proportionally. With this mechanism, the probability and harm of any attack are infinitely close to zero. 
+
+## Advantages of DPoA consensus {#advantages-of-dpoa-consensus}
+
+Compared to Proof-of-Work (PoW) or Proof-of-Stake (PoS) consensus, DPoA consensus has the following advantages:
+
+* No need of high-performance hardware. Compared to PoW consensus, nodes implementing the DPoA consensus does not spend computational resources for solving complex mathematical logic tasks;
+
+* The interval of time to generate new blocks is predictable, but that for  PoW and PoS consensuses are different;
+
+* High transaction rate. Blocks are generated in a sequence at specified time interval by authorized network nodes, which increases the speed of transaction verification.
+
+* Tolerance to compromised and malicious nodes, as long as 51% of nodes are not compromised. IBAX implements a mechanism of banning nodes and revoking block generation rights.
+
+## DPoA consensus and common means of attack {#dpoa-consensus-and-common-means-of-attack}
+
+### DoS {#dos}
+
+An attacker may send large amount of transactions and blocks to a targeted node in the network, making an attempt to disrupt its operation and make its services unavailable.
+
+The DPoA mechanism is possible to defend against DoS attacks:
+
+* Because network nodes are pre-authenticated, block generation rights can be granted only to nodes that can withstand DoS attacks.
+
+* If a honor node is unavailable for a certain period, it can be excluded from the list of honor nodes.
+
+### 51% attack {#percent-attack-51}
+
+As to the scenario with the DPoA consensus, the 51% attack requires an attacker to obtain control over 51% of network nodes. But the scenario for the PoW consensus is different, which an attacker needs to obtain 51% of network computational power. Obtaining the control over nodes in a permissioned blockchain network is much harder than obtaining the computational power.
+
+For example, in a network implementing the PoW consensus, an attacker can increase computation power (performance) of the controlled network segment thus increasing the percentage of controlled nodes. This makes no sense for DPoA consensus, because the computational power of the node has no impact on the blockchain network decisions.
+
+## Implementation of DPoA consensus in IBAX {#implementation-of-dpoa-consensus-in-ibax}
+
+### Honor node {#honor-node}
+
+In IBAX, only honor nodes can generate new blocks, which maintain the blockchain network and the distributed ledger.
+
+The list of honor nodes is kept in the blockchain registry. The order of nodes determines the sequence in which nodes generate new blocks.
+
+### Leader node {#leader-node}
+
+
+The leader node is the honor node that generates a new block at the current time. The following formula determines the leader node in the current honor node list:
+
+``` text
+leader = ((time - first) / step) % nodes
+```
+
+> leader
+
+    Current leader node.
+
+> time
+
+    Current time (UNIX).
+
+> first
+
+    First block generation time (UNIX).
+
+> step
+
+    Number of seconds in the block generation interval.
+
+> nodes
+
+    Total number of honor nodes.
+
+#### Generation of new blocks {#generation-of-new-blocks}
+
+New blocks are generated by a [leader node](#leader-node) of the current time interval. At each time interval, the leader role is passed to the next honor node from the list of honor nodes.
+
+![avatar](/img/block-generation.png)
+
+a) Steps for Generation of new blocks
+
+Main steps for generating a new block are as follows:
+
+1. Collects all new transactions from the transaction queue of the node;
+
+2. Executes transactions one by one. Invalid or inexecutable transactions are rejected;
+
+3. Checks if the [block generation limits](../reference/platform-parameters.md#configure-the-generation-of-blocks) is in compliance; 
+
+4. Generates a block with valid transactions and signs it with the private key of the honor node through the ECDSA algorithm;
+
+5. Sends this block to other honor nodes.
+
+b) Verification of new blocks
+
+Steps for verifying new blocks on other honor nodes:
+
+1.Receive a new block and verify:
+
+    – whether the new block was generated by the leader node of a current interval;
+
+    – whether there are no other blocks generated by the leader node of a current interval;
+
+    – whether the new block is properly signed. 
+
+2. Execute transactions from the block one by one. Check whether the transactions are executed successfully and within the [block generation limits](../reference/platform-parameters.md#configure-the-generation-of-blocks) .
+
+3. Add or reject the block, depending on the previous step:
+
+    – If block validation is successful, add the new block to the blockchain of the current node;
+
+    – If block validation failed, reject the block and send a **bad block** transaction;
+
+    – If the honor node that created this invalid block continues to generate bad blocks, it can be banned or excluded from the list of honor nodes.
+
+### Forks {#forks}
+
+A **fork** is an alternative version of the blockchain, which contains one or more blocks that were generated independently from the rest of the blockchain.
+
+Forks usually occur when a part of the network becomes desynchronized. Factors that are probably result in forks are high network latency, intentional or unintentional time limits violation, time desynchronization at nodes. If network nodes have a significant geographic distribution, block generation interval must be increased.
+
+Forks are resolved by following the longest blockchain rule. When two blockchain versions are detected, honor nodes rollback the shorter one and accept the longer one. 
+
+![avatar](/img/block-fork-resolution.png)