Blockchain across Oracle
上QQ阅读APP看书,第一时间看更新

Security starts at the network architecture level

One of the first decisions to make when establishing a blockchain is the choice between a public blockchain and a private blockchain. Do you want to bring your application to the whole world, or do you want only certain parties to be able to join the network? When implementing an application on a public blockchain like Ethereum, there are already tens of thousands of nodes in the network. This means that your solution will be fully decentralized, and nodes can come and go without the need to operate them yourself. By making it explicitly harder or impossible to do certain things by yourself, then others are likely to trust you more and engage with your application sooner. Also, if your blockchain application needs to be censorship resistant, a public blockchain can be a viable option. This is the case because if you are pressured by another entity, it is impossible to hand over information even if you wanted to do so.

If your blockchain application is used by (partially) trusted parties, then the application can be implemented on a private blockchain. When implementing an application on a private blockchain such as Hyperledger Fabric, operators have control over the method of consensus, the number of nodes, the available smart contracts, which parties can write and approve new transactions, and other configurations that you normally can't control in a public blockchain.

Private (or permissioned) blockchains, such as Hyperledger Fabric, provide a greater level of privacy. In addition to the main chain, it is also possible to configure dedicated channels where two or more parties can communicate without the involvement of the rest of the network. When running a private blockchain network, operators, usually from multiple participating member organizations, are in control over the number of nodes in the network. When establishing the network architecture, you need to take into account how they should treat uncommunicative, intermittently-active nodes. Nodes can go offline for harmless reasons, but the network must still be resilient in order to function (verifying new transactions and obtaining consensus) without these offline nodes. Thus, the network architecture must define an adequate number of nodes to be able to bring back the offline nodes and get them up to speed quickly when they return.

In the following diagram a centralized ledger (database, excel) is compared to a private and a public blockchain (distributed ledger). It shows how end users (individuals and organizations) interact with the ledger and how it affects the infrastructure architecture of each network:

Centralized ledger versus private blockchain versus public blockchain