# An Internet of Things Access Control Scheme Based on Permissioned Blockchain and Edge Computing
## 6 Security and Performance Analysis
### Performance Analysis
Figure 8: Read/write blockchain speed for 10 peer nodes. Figure 9: The processing time of the two schemes. Figure 9 shows that when the data request size is set to less than 106 B, the processing time of the two schemes is very close and short. However, as the size of the data request increases, the processing time will rapidly widen the gap, which can be nearly three orders of magnitude. Obviously, the access control scheme in this paper can process the user's data request for the object resource more quickly with less computational overhead. In order to verify the effectiveness of the access control mechanism, the following methods are used to test and compare the effectiveness of the access control policy, RBAC policy, ABAC policy, and CapBAC policy under different policies. The test content is the efficiency of policy adjudication in the access control mechanism. The policy decision delay is calculated based on the average response delay of all requests. In each simulation, the test set sample constructs 100 different access requests for 10 user IDs, each with five attribute values, and each request has five random sending opportunities. The experiment simulated the algorithm using the same dataset: when fully operational, the simulation results averaged 10 experiments, with 100 connection requests per experiment. The confidence interval of the 95% confidence interval was derived using the independent replication method. There are five requests for test base samples, corresponding to 100, 200, 300, 400, and 500 single policies. The experimental results are shown in Figure 10.  
From Figure 10, it can be seen that the adjudication latency of all policies grows with the increase in the test set samples. When the number of the tests set sample is small, the delay of this access control policy, RBAC policy, ABAC policy, and CapBAC policy decision is not significant; when the number of samples is 100, the decision delay of each policy is basically controlled at about 300 ms; and when the number of samples is 200, the decision delay of each policy is basically controlled at about 400 ms, the reason being that when the samples are small, the system throughput (i.e., the number of transactions requests per second) using the above four different strategies can meet the normal processing conditions of a small number of samples, and there is no difference in delay. With the increase in the number of test set samples, the decision delay of the four policies gradually shows a gap. When the number of samples in the test set increases to 500, the latency of the CapBAC strategy and the strategy in this article has a slower growth trend compared to the RBAC strategy and the ABAC strategy, where the RBAC policy decision latency increases from 300 ms to 1700 ms, while the strategy decision latency in this article only increases to 1100 ms, which is lower than the CapBAC policy decision latency of 1200 ms. The reason is that the throughput of four different policies mechanisms cannot satisfy the decision requests with a large number of concurrent policies in the same period due to the increasing number of samples, which leads to the queuing of policy decisions, and the difference in throughput makes the performance of the four policies  
Figure 10: Delay comparison of four policies. gradually widen the gap. However, due to the P2P network architecture of the blockchain, each node can make decisions on policy transaction requests, and process more policy requests concurrently. Smart contracts are used to implement complex algorithms to make decisions on policies quickly.