This series of articles introduces Java-based solutions for the Ethereum blockchain. By introducing the main modules and classes defined by EthereumJ, I hope to provide some help for everyone to learn and use EthereumJ.
Overall structure
Ethereum's Java solution is mainly implemented by two projects:
l EthereumJ (https://github.com/ethereum/ethereumj), which implements the core protocol defined by Ethereum and completes the core functions of the blockchain.
l Ethereum Harmony (https://github.com/ether-camp/ethereum-harmony), which provides the functions of the Ethereum user access layer.
The diagram below depicts the main modules in both projects.
In EthereumJ,
l The bottom layer of DataSource provides persistence of data. The data is in the format of <key, value> and is saved in the form of bytes. The default is Facebook's RocksDB.
l Blockchain Management implements the Trie node, Transaction, Block, Block chain and other data structures defined by Ethereum, as well as the management functions of these data structures.
l P2P Network implements the devp2p protocol defined by Ethereum, and realizes the functions of the Ethereum network, discovery between nodes and communication between nodes.
l Sync Management, which implements the function of synchronizing blocks/Transactions between nodes in the Ethereum network.
l Block Mining implements the function of block generation and consensus generation defined by the Ethash protocol.
l Program/VM implements Solidity's compile and prgram execution functions.
Inside Ethereum Harmony,
l Json RPC implements the RPC interface defined by Ethereum, through which applications can access EthereumJ data, such as Blocks, Transactions, Balance, etc.
l Wallet implements a simple Wallet function, which can use the same key store format as Ethereum Go to store the Account's private key. The Balance balance of the Account is recorded. But the history of the Account's Transactions cannot be displayed.
l Command Terminal can perform RPC operations.
l Peer Connection shows the status of peers linked to EthereumJ.
main configuration file
Ethereum Harmony/EthereumJ provides many sample configuration files, through which different configuration files can be used to access different Ethereum networks, such as MainNet, TestNet and private networks.
EthereumJ.conf
EthereumJ provides a lot of configuration options to customize the system differently, and the configuration file is in Json format. The default Ethereumj.conf file configures most of the parameters of the system. Generally, users only need to define a few parameters in their own configuration files, such as the file storage location of the database, the location of the genesis configuration file, the system's privateKey, listening system external parameters such as port.
The configuration file of EhereumJ is read by SystemProperties.java through the typesafe config class library. Users can use multiple configuration files to realize the differentiated configuration required for the system to run in different deployment environments.
l A parameter defined by the system property of the JVM
l The location of the ethereumj.conf.file (-Dethereumj.conf.file) file defined by the JVM command line
l test-user.conf under the resource path of the JVM
l test-ethereumj.conf under the resource path of the JVM
l /config/ehtereumj.conf in the user.dir directory of the OS
l user.conf under the resource path of the JVM
l The ethereumj.conf.res (-Dethereumj.conf.res) file defined by the JVM command line in the resource path of the JVM
l The system default ethereumj.conf
The order in which the configuration takes effect is listed above (priority from top to bottom).
Genesis.json
Genesis.json defines the 0th block of each Ethereum network. The blocks on the blockchain of subsequent mining in the network are all based on the data of this block. If you want to build a private Ethereum network, you need to define a gensis block that is different from other Ethereum networks. The genesis.json of the same private network needs to be exactly the same.
A typical genesis.json configuration file is as follows:
// genesis.json
{
"alloc": {
"0xca843569e3427144cead5e4d5999a3d0ccf92b8e": {
"balance": "1000000000000000000000000000"
},
"0x0fbdc686b912d7722dc86510934589e0aaf3b55a": {
"balance": "1000000000000000000000000000"
}
},
"config": {
"chainID": 68,
"homesteadBlock": 0,
"eip155Block": 0,
"eip158Block": 0
},
"nonce": "0x0000000000000000",
"difficulty": "0x0400",
"mixhash": "0x0000000000000000000000000000000000000000000000000000000000000000",
"coinbase": "0x0000000000000000000000000000000000000000",
"timestamp": "0x00",
"parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
"extraData": "0x43a3dfdb4j343b428c638c19837004b5ed33adb3db69cbdb7a38e1e50b1b82fa",
"gasLimit": "0xffffffff"
}
The alloc data defines the account that has been in effect since the beginning of the network. Configuration data, including the account's address and account's state, such as balance.
Config also defines the configuration parameters of the Ethereum network. The configuration here will override the configuration parameters of the Ethereum network configured in the EthereumJ configuration file. In the actual deployment process of the Ethereum network, some problems were found, and the network has been upgraded accordingly to correct these errors. These upgrades are reflected in the configuration parameters of the Ethereum network, and the programs on the Node in the Ethereum network work according to these configuration parameters. The configuration in Config determines which network working version the network node adopts at a certain block number. The following are the different block serial numbers defined in MainNetConfig, using different network working versions.
add(0, new FrontierConfig());
add(1_150_000, new HomesteadConfig());
add(1_920_000, new DaoHFConfig());
add(2_463_000, new Eip150HFConfig(new DaoHFConfig()));
add(2_675_000, new Eip160HFConfig(new DaoHFConfig()));
add(4_370_000, new ByzantiumConfig(new DaoHFConfig()));
If it is a private network, the latest working version can be used from the first block.
Difficulty defines the difficulty of the consensus algorithm. The smaller the value, the easier it is to generate new blocks. If it is a private network, you can define a smaller value to generate blocks quickly, thereby improving the response speed of the network.
gasLimit defines the maximum amount of gas allowed to be used when each block of the network is generated.
The following parameters are mainly used to configure network nodes to generate new blocks, and are not used in genesis blocks.
Nonce/MixHash is to verify whether the newly generated block is valid.
ParentHash is the hash of the previous block.
After Coinbase successfully generates a block, the account of the address will be rewarded.
start up
EthereumJ uses Spring Framework to load various modules.
In the samples of EthereumJ, many examples are provided, using createEthereum() of EthereumFactory to load Spring's Application Context. Spring loads other modules of EthereumJ by loading DefaultConfig and CommonConfig defined by EthereumJ. In addition to the multiple spring beans created in these two classes, EthereumJ creates multiple Components and Services defined by EthereumJ through Spring's ComponentScan function in CommonConfig.
The main Spring Beans launched by EthereumJ include:
l DataSources class, which defines the access classes of multiple Data Sources (implementing the Source<K,V> interface), adopts the Decorator mode, and implements various functions such as cache and DB access.
l BlockMiner, the main management module of block mining.
l WorldManager, as the main management module, starts the creation of block chain and synchronization between Ethereum nodes.
l EthereumImpl, which implements the Ethereum interface. The Ethereum interface provides several methods for external applications to access the internal functions of Ethereum.
Other main modules will be introduced in subsequent articles.