Open source address: https://gitee.com/tianyalei/md_blockchain
https://gitee.com/tianyalei/md_blockchain_manager
Java blockchain platform, a blockchain platform developed based on Springboot. The company wanted to develop a blockchain, originally thinking of using Ethereum to develop a contract or using a third-party platform to do it, but later found that it did not meet the business needs. The company asked to develop its own blockchain platform, only the alliance chain. Therefore, research and development began in March, and this version was released in January. The basic functions are there, but the details are not yet in place. I hope that the experts will give me some advice to make a blockchain platform project, suitable for various scenarios, distributed storage, not just ledgers.
There are mainly storage modules, network modules, encryption modules, block analysis and storage, etc.
The blockchain platform belongs to "chain", not "coin". It is mainly used for alliance chain, which is used for distributed storage and does not involve virtual currency. Essentially similar to the Tencent blockchain project trustsql.
Blocks store Sql-like statements. Each node can generate blocks after reaching more than half of the agreement, and then broadcast to the whole network, pull the blocks, and then execute the sql statements in the block.
Each node implements a synchronized sqlite database by executing the same sql. In the future, data queries will be directly query sqlite, and the performance is higher than that of traditional blockchain projects.
There are many applicable scenarios, but anything that can be represented by sql can be used, and bills such as Bitcoin can also be stored in a database.
If the chain is forked for some reason, a rollback mechanism is also provided, and SQL can be rolled back.
How to use: First start the md_blockchain_manager project ( https://gitee.com/tianyalei/md_blockchain_manager), then modify the name, appid and managerUrl in application.yml and the one-to-one correspondence in the manager project database, and start it as a node.
You can generate a block by visiting localhost:8080/block?content=1. At least 2 nodes must be started. When generating a block, you need at least half consent except yourself. After the block is generated, it will be found that other nodes will also automatically synchronize the newly generated block.
You can view the data stored in sqlite through localhost:8080/sqlite, which is the result of executing the sql statement in the Block.
Block storage uses the key-value database rocksDB. If you know about Bitcoin, Bitcoin uses levelDB, which are similar things.
The block stores statements similar to sql, such as ADD (addition, deletion and modification) tableName (table name) ID (primary key) JSON (json of the record).
Nodes can land data based on these statements in the block. The embedded database sqlite I use here, of course, also supports databases such as mysql. Jpa is used, and there is no difference between operating sqlite and mysql.
In the network layer, each node is connected to each other for a long time, disconnected and reconnected, and then maintains the heartbeat packet. Any node can generate a block. Unlike Bitcoin mining and others, which need to be elected first, they can only be generated by a specific node. I can be generated by any node here, as long as the majority agree. When generating a block, it needs to be broadcast on the whole network, waiting for the verification of other nodes (verification format, hash, signature, and table permissions). Update Block.
I deployed the project to docker and started a total of 4 nodes, as shown in the figure: 
The manager is the md_blockchain_manager project, whose main function is to provide the ip of each node in the alliance chain 
The IPs of the four nodes are all written to death. After they are all started, they will all be connected to each other and maintain long connections and heartbeat packets. 
I call the block generation interface of the block project, http://ip:port/block?content=1
Other nodes will be like this, receiving the request of the block project to generate a block, and start verification, and reply whether they agree or not. 
When the block project receives more than half of the approval, it starts to generate blocks and broadcasts their own new blocks to other nodes. Other nodes start to pull the new blocks, and the verification is passed and updated to the local.
This block generation interface is written for testing. The normal process is to call the instruction interface, first generate instructions that meet your needs, and then combine multiple instructions to call the block generation interface in BlockController.