# LBFT: An Asynchronous Committee-Based Blockchain Storage Strategy on Zero Trust Model
## 4 Design
### Adapting to the Zero-Trust Model  
In our system model mentioned in Section 2, we construct LBFT in a zero-trust model, in which all the system resources and packets are assumed threatening by default unless they are verified to be inspected, authorized, and secured [8]. To achieve this, all the received values are verified by the receivers through the CLAS in LBFT. Moreover, the key technologies to support the implementation of the zero-trust model on LBFT are depicted in Figure 4.  
It can be seen that there are two layers in the architecture; in the control plane, the core and supporting components collaborate to manage the access, while in the data plane, the users and/or devices establish connections with resources and/or data through Policy Enforcement Point.  
There are three core components in the architecture of the zero-trust model responsible for enabling the users or devices to access resources and data successfully.  
The **Policy Engine** makes decisions to grant permission for users or devices to certain system resources or data. In addition, it calculates and assigns different confidence levels to the users and devices.  
Figure 4: The high-level architecture of the zero-trust model implemented on LBFT.  
The **Policy Administrator** is responsible for establishing and maintaining the connection between a user or device and certain system resources or data during the access.  
The **Policy Enforcement Point** monitors the connections between a user or device and certain system resources or data and eventually terminates the connection after this access is complete.  
In addition, we also adopt four supporting components, to guarantee the tenets and requirements of zero-trust in the whole access process. Among them, the NAV system and RBAC system are key components, which will be described in detail.  
The **Continuous Diagnostics and Mitigation (CDM) System** gathers information and parameters about the current state of the resources and data from the NAV system and updates the related records in configuration settings.  
**Threat Intelligence** collects newly discovered attacks and/or vulnerabilities in the packets from internal and/or external sources and then reports to the Policy Engine, as a basis for making access decisions.  
The **Role-based Access Control (RBAC) System** is a standard technology that is well-suited to prevailing business and technology trends. In LBFT, we deploy the basic model \(RBAC_{0}\)[45].  
The users are dynamically placed into various roles, and the Policy Engine designates different permissions to certain resources based on the roles to avoid abuse of the resources and data in the system.  
The **Network Analysis and Visibility (NAV) System** is a set of diverse tools used to supervise, log, and analyze the network traffic [7]. It collects and records the information in the network, for other components to further operate and analyze. It has two main functions, as follows:  
* **Provide real-time information on the network situation.** The NAV system helps the core components to learn what is going on and to decide the permissions to resources or data for users.
* **Give caution to the potential malicious nodes.** The deployment of NAV can warn both the inside and outside individuals that their behavior is under supervision so that they will be less tempted to behave maliciously, which lessens the potential malicious behaviors and attacks to some extent.