In Ethereum, practically anyone can join the network, as long as they have the client code, easily accessible on Github, and a decent internet connection. Storage space could be a bit of a problem, but storage is relatively cheap, even in case of a full node, since as of writing this, the entire Ethereum main chain takes around 50GBs. Stating the obvious for the sake of clarity, in an Ethereum network, a node has the same copy of the ledger as everyone else does, since all transactions are public.
Quorum, however, is a different beast altogether. Getting a Quorum node up and running means you not only require the client, but you will also need a corresponding Constellation node. These are an addition made necessary to fulfill the private transaction requirement. Constellation nodes are responsible for key management and encryption/decryption of the private transaction payloads, which we will further discuss with regard to private transactions. On top of that, every node will now keep track of a public state and the private state, where the former is the ledger of all the public transactions and the latter is where a node keeps track of all the data that it is privy to.
There is no mining in Quorum since it uses Raft based consensus, which we will hopefully discuss in another article. It must be added that Quorum can also be used with the Istanbul Byzantine Fault Tolerance (IBFT) consensus protocol.
Intended for B2B applications, Quorum has a requirement for enforcing permissions so that only a select group of nodes are allowed to participate in the network. A node is identified by its enode address, which is a long hex string.
Permissioning, in Quorum, is based on a file, where you provide the enode addresses that are allowed to be a part of the network. Not only do you specify the enode address of every individual node that you want to allow your node to connect with, you will also append to it the IP address, port and the raft port of that node, which looks something like this: enode://firstname.lastname@example.org:21001?discport=0&raftport=50401.
Permissioning is an option that can be used with the flag `permissioned` when using the client. This is bidirectional permission, where the whitelisted nodes will be allowed to make incoming connections and the node will be allowed to make outbound connections with them. There could be both permissioned and non-permissioned nodes in a Quorum network.
In Quorum, there are both public and private transactions, which means that you can create smart contracts that are public, but also ones that are only privy to a select few. It should be noted that transactions of value in Quorum remain public, the rationale being that the currency associated with the blockchain and its expenditure should remain forever transparent to every participant in the network.
This is where the aforementioned Constellation nodes come in. The evidences (hashes) of private transactions are stored in the public ledger, however their payload is encrypted and only shared with those allowed to access that transaction. This is determined by the `privateTo` attribute in the transaction a client sends, which will include the public key — not the same as public address, but part of a key pair generated specifically for interaction with the Constellation node.
Quorum provides a way to create private transactions and allows controlling access to chosen nodes in the network. It has a moderately active community behind it, nowhere close to the size of Hyperledger’s following, though. The fact that it is based on Ethereum gives it a solid backbone, which has been extended with as little interference in the Ethereum core as possible. This is the first in our series of articles about Quorum, and Enterprise blockchains in general. In the next article of this series, we dive deep into Quorum’s privacy and permissioning mechanisms, how they work and how well they work.