1.Background

Bitcoin can only handle 3-7 trades per second while consuming a lot of money, and its trading efficiency is too low compared with other centrally-located legal currencies (MasterCard, 1200; Visa, 56000). There are two main factors that limit the volume of transactions:

1. The speed at which blocks are generated (10 minutes)
2. The block size limit (1MB), changing the first parameter increases the probability of bifurcation and changes the second parameter , will increase the network traffic, require more bandwidth.
   Here presents for the first time an ELASTICO with Byzantine fault tolerance in open blockchain networks, which increases the blockchain throughput linearly with the computing power of the entire network.

Using the traditional Byzantine agreement faces two basic challenges:

• Open non-admitted blockchain network node has no default identity, no public key infrastructure support
• The traditional Byzantine protocol (PBFT) requires O (n2) communication bandwidth. In the open non-admitting blockchain network, the number of nodes is large and the bandwidth limitation is obvious.

2.Overview

2.1 Threat Model

Static rivals: Byzantine rival control of malicious nodes can be out of agreement, discarding the message, collusive.
Dynamic adversary (wheel adaptive): 1) Through the information of the previous round of trading, it is possible to select the specific node before the start of the round of control; 2) The protocol starts to run and a communication link is established between the nodes so that the adversary can obtain all Complete message

2. 2Security Assumptions

• Honest nodes in the network are interconnected
• Honest communication between nodes is synchronized
• All nodes during the protocol operation are reliable
• Once the protocol is up and running, it can not be modified.

2.3 Challenges

1. Without a unified fiduciary identity, malicious nodes can create many witch nodes;
2. Divide all nodes into small communities while ensuring that each community has an honest number of nodes;
3. It must be ensured that the wheel adaptive adversaries observe the operation of all the agreements but do not have operational advantages.

3.Proposed method

Divide the network into smaller communities, each dealing with disjoint transactions, a typical Byzantine consensus agreement running within the community, a transaction validation digest sent to the final community (with a specific ID) after the community completes the transaction verification, and finally the community is responsible Consolidate transaction summaries from other communities to generate signature summaries and random numbers needed for the next run and broadcast across the web.

3.1 Identity established

Each node uses (PK, IP) as its identity information. And generates a valid nonce value according to O = H (epochRandomness || IP || PK || nonce) ≤2γ-D as the PoW for verifying identity, and at the same time indicates from O's last s-bit that the identity belongs to The first epochRandomness is generated by robust P2P system random number algorithm, and then passed through the fifth step of the program.

3.2 Community members to establish contact

First generated c nodes as directory nodes, and broadcast to the entire network. The resulting node notifies the corresponding directory community that the directory community can track the messages generated by all the nodes. After a certain number of community members reaches c, the directory community will broadcast all its members information to all nodes in the community and request that all communities Distributed evenly, the number of malicious nodes is less than 1/3.

3.3 Community consensus builds

After the community is established, the community uses the BFT protocol. After the consensus is reached, the transaction requires at least c / 2 + 1 node signature, and then sends the signature content and signature value to the final consensus community (id-specific community).

3.4 The formation of the final result and the whole network broadcast

The final community members verify that each transaction has enough signatures, run an intra-community consensus algorithm, require that more than c / 2 + 1 community members sign the transaction, and generate a digest of encrypted signatures to broadcast throughout the network.

3.5 The next round of random number generation

Each member in the final community randomly generates r bits Ri and broadcasts H (Ri) within the community, generates a random value S through an intra-community consensus agreement, and broadcasts S and final digest signatures to the entire network.

Performance Evaluation

The figure shows that with the network size increaseing, ELASTICO's block throughput approaches linear growth, reaching a consensus that time is essentially unchanged and the network latency is not appreciably increased, confirming ELASTICO's well-expanded transaction throughput .

The next figure shows that with the number of network nodes increaseing, the number of messages per node decreases. This is because the additional information required by the Final community to run the second community consensus protocol is shared. At the same time, we see that each node consumes about 5MB of bandwidth, and the authors have confirmed that even if more nodes are added, the bandwidth will remain roughly the same without any additional cost, which means the solution is efficient.

Conclusion

Starting with the low transaction efficiency of bitcoin, this paper proposes a new ELASTICO protocol that effectively increases the transaction rate linearly with the expansion of the network size and provides a high degree of support for the development of next generation cryptographic currency Usability.