If you mention blockchain, newcomers at first associate the term primarily with Bitcoin, or generally with cryptocurrencies. But that’s only half the story, just like the belief in the one and only blockchain. Meanwhile, we now have nearly as many implementations and associated networks as there are text editors.
One of the most popular platforms besides Bitcoin and its derivatives is Ethereum. Designed by the Canadian-Russian software developer Vitalik Buterin and formally specified by the British developer Gavin Wood in the Ethereum Yellow Paper, Ethereum is known above all as a pioneer in the management and execution of decentralized programs in the form of smart contracts. But Solidity, the contract-oriented, Turing-complete programming language for Smart Contracts, is by no means the only thing that distinguishes Ethereum from the rest. The transition from the energy-consuming proof-of-work (PoW) to the more efficient proof-of-stake (PoS) consensus algorithm already foreseen in the Yellow Paper began in late 2018 with Hard Fork on the new Constantinople version of the Metropolis milestone.
|
Security |
Proof-of-Work | Proof-of-Stake | Proof-of-Authority |
|
New blocks are secured by applying very costly mathematical puzzles (mining). |
The blockmaker vouches for the correctness of the new block with his or her own stake. |
Only special accounts, the Validators, are allowed to create new blocks. |
|
| Incentive | The first miner to solve the math problem gets a reward. | The stakeholder may claim the transaction costs. | The validator may claim the transaction costs. |
| Conclusion | The required power can usually only be provided by a few large mining networks.
Low throughput Power-hungry |
A very fast and inexpensive alternative, but it also has its problems. | This variant is well suited for use in trusting partner networks.
Trusting partners as a prerequisite |
With such a change of the consensus engine planned from the beginning, it is therefore not surprising that most Ethereum clients have also been using alternative engines for quite some time. This includes Parity, the most widely used Ethereum client.
Parity
This client, which was developed in Rust, focuses on performance and security and is also supplied as a Docker image, in addition to the binaries for Windows, Mac and Linux. You launch the modern and sleek web interface by default at http://127.0.0.1:8180/, giving you easy access to the included tools and external DApps. In addition, it supports not only the current PoW engine, but also a hybrid Casper FFG as well as a simple and very fast Proof-of-Authority (PoW) algorithm called Aura. The latter is a nearly perfect solution especially for consortium chains (see Table 1).
Parity can be configured in two ways: Using CLI options or through a .toml configuration file. If parity is known in the system path, calling up parity –help will provide an overview of the available options. Further information can also be found in the official Parity Wiki in the Configuring Parity Ethereum menu item.
Chain Specification
To start your own user-defined chain, a chain specification must first be created. Ethereum uses the JSON format with a special structure (Listing 1) for this.
{
"name": "CHAIN_NAME",
"engine": {
"ENGINE_NAME": {
"params": {
ENGINE_PARAMETER
}
}
},
"genesis": {
"seal": {
ENGINE_SPEZIFISCHES_GENESIS_SIEGEL
},
"difficulty": "0x20000",
"gasLimit": "0x2fefd8"
},
"params": {
"networkID": "0x656e747769636b6c6572",
"maximumExtraDataSize": "0x2",
"minGasLimit": "0x1388"
},
"accounts": {
GENESIS_ACCOUNTS
}
}
While some configuration parameters are still self-explanatory, the importance of others can quickly raise questions:
- name: desired name of the chain, used for identification purposes
- engine: Configuration of the consensus engine
- genesis: the legendary Genesis block (Patient 0, we would be in a zombie movie)
- difficulty: Starting difficulty of the chain – this is irrelevant in a PoA chain and can therefore be set to an arbitrary value (required field)
- gasLimit: Initial limit on transaction costs (gas)
- params: General settings of the chain
- networkID: ID of the chain network as hexadecimal value
- maximumExtraDataSize: Amount of additional data, head of a block
- minGasLimit: Absolute minimum of transaction costs
- accounts: Accounts that should already be available at the start of the chain, such as system accounts or a bank account with the starting balance of the chain
To make sure that our new chain behaves the same way as the official Ethereum chain and all Solidity features are supported, we still need four system accounts or contracts for the functions ecrecover, sha256, ripemd160 and identity. These should be entered in the accounts are of chain.json (Listing 2).
"accounts": {
"0x0000000000000000000000000000000000000001": {
"balance": "1",
"builtin": {
"name": "ecrecover",
"pricing": {"linear": {"base": 3000, "word": 0}}
}
},
"0x0000000000000000000000000000000000000002": {
"balance": "1",
"builtin": {
"name": "sha256",
"pricing": {"linear": {"base": 60, "word": 12}}
}
},
"0x0000000000000000000000000000000000000003": {
"balance": "1",
"builtin": {
"name": "ripemd160",
"pricing": {"linear": {"base": 600, "word": 120}}
}
},
"0x0000000000000000000000000000000000000004": {
"balance": "1",
"builtin": {
"name": "identity",
"pricing": {"linear": {"base": 15, "word": 3}}
}
}
}
As I had already mentioned, normal accounts can also be created during the Genesis. The line of code then corresponds to a simple balance assignment to the address of the account (public key):
0x…”: {“balance”: “100000000000”}
An extended overview of the possible setting variants in the chain specification can be found in the Parity Wiki in Chain Specification.
Proof-of-Authority with Aura
The PoA algorithm which is included in Parity and can be activated is very simple and easy to explain. The engine numbers the available validator nodes and creates timelines. Then each of the time slots is assigned a so-called Primary Validator as a block generator. The formula for this is:
Primary = Slotindex % Validator_amount
To operate our new blockchain network using the Aura Engine as a PoA chain, we still need to add the appropriate engine configuration in chain.json (Listing 3).
"engine": {
“AuthorityRound": {
"params": {
"stepDuration": "5",
"validators": {
"list": [
LIST_OF_VALIDATORS
]
}
}
}
},
“genesis": {
“seal": {
“AuthorityRound": {
"step": "0x0",
"signature": "0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
}
}
}
It should be noted that in the area of validators, a static list of account addresses of the validator nodes is expected. Now, this approach is somewhat inflexible and virtually useless in practice because there is no way to add or remove validators and thus consortium members. But again, Aura offers a solution in the form of progressive switching from a static list to a smart contract, which then keeps a dynamic list and performs administrative tasks (Listing 4).
“engine": {
“AuthorityRound": {
"params": {
"stepDuration": "5",
"validators": {
"multi": {
“0": {"list": [INITIAL_VALIDATORS_LIST]},
“10": {"contract": "0x..."}
}
}
}
}
}
The multi option allows for a blockwise configuration. In our example, the engine is operated from block 0-9 with a static list and from block 10 with a dynamic list of validators in the form of a smart contract. From my own practical experience, I can report that this procedure can spare a lot of stress when setting up a new chain. The smart contract responsible for data management and administration has only one limitation: It has to implement the official ValidatorSet interface (Listing 5).
contract ValidatorSet {
/// Issue this log event to signal a desired change in validator set.
/// This will not lead to a change in active validator set until
/// finalizeChange is called.
///
/// Only the last log event of any block can take effect.
/// If a signal is issued while another is being finalized it may never
/// take effect.
///
/// _parent_hash here should be the parent block hash, or the
/// signal will not be recognized.
event InitiateChange(bytes32 indexed _parent_hash, address[] _new_set);
/// Get current validator set (last enacted or initial if no changes ever made)
function getValidators() constant returns (address[] _validators);
/// Called when an initiated change reaches finality and is activated.
/// Only valid when msg.sender == SUPER_USER (EIP96, 2**160 - 2)
///
/// Also called when the contract is first enabled for consensus. In this case,
/// the "change" finalized is the activation of the initial set.
function finalizeChange();
}
An example of a current publicly running validator contract can be found on the Ethereum-Kovan network. Among the vast amounts of existing implementations, in addition to voting/reporting systems used to select (deselect) validators, there are those that limit access to owner or individual administrator accounts.
If the implementation is selected or self-written, the contract must be compiled and pasted into the Genesis block as a bytecode. This is done through an entry in the accounts range of the chain specification in the form of a line of code in the following format:
“0x…”: {“balance”: “1”, “constructor” : “0x…”}
1Once complete, the chain specification can be passed to the Parity client with the startup parameter.
parity –chain path/to/chain/spec.json
Alternatively, the path can also be entered in the aforementioned config.toml to not have to manually specify it each time:
[parity]
chain = “path/to/chain/spec.json”
If everything went well, you are now the proud owner of your own Ethereum Blockchain network based on PoA via Parity Aura Engine. Adding new nodes and validators is relatively easy afterwards. All you need is exchange the chain.json with your new partner to connect to your network. After successful synchronization, if necessary, the new node can be added as a validator by calling the appropriate method on the Validator Contract.
Conclusion
The open-source Ethereum platform, in conjunction with the Parity client, is a powerful tool for building your own blockchain networks. Whether for private use, small or medium-sized companies, you can implement your own Blockchain solutions with moderate effort. The trick here is to find trustworthy and willing partners for a common set-up, rather than technical implementation. Only in a multi-participant community can this technology, which is based on trust-building through cryptographic mechanisms, realize its full potential.
