Using Quorum

##Running Quorum
Please see the ReadMe for instructions on how to install Quorum and start Quorum nodes with various roles (Maker,Voter, Observer). ##Developing Smart Contracts Quorum uses standard Solidity for writing Smart Contracts, and generally, these can be designed as you would design Smart Contracts for Ethereum. Smart Contracts can either be public (i.e. visible and executable by all participants on a given Quorum network) or private to one or more network participants. Note, however, that Quorum does not introduce new contract Types. Instead, similar to Transactions, the concept of public and private contracts is notional only.

###Creating Public Transactions/Contracts

In order to make a Transacton/Smart Contract viewable and executable by all participants on a given Quorum network, simply send an Ethereum Transaction to the network ( leaving the to param empty if you want the Transaction to create a Contract).

See the Quorum API page for details on the Transaction creation call, which includes some modifications to the standard Ethereum call.

NOTE: Please see the Contract Design Considerations sections below for important points on creating Quorum contracts

###Creating Private Transactions/Contracts In order to make a Transaction/Smart Contract private to a subset of participants on a Quorum network, send a standard Ethereum Transaction but set the privateFor parameter on the message to be the public key(s) of the participant(s) that should be able to view and execute the Transaction or Contract code.

Example JSON message below:

'{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{"from": $FROM_AC, "to": $TO_AC, "data": $CODEHASH, "privateFor": ["$PUBKEY1,PUBKEY2"]}],"id":$ID}'

See the Quorum API page for details on the Transaction creation call, which includes some modifications to the standard Ethereum call.

NOTE: Please see the Contract Design Considerations sections below for important points on creating Quorum contracts

###Quorum Contract Design Considerations

1. Private contracts cannot update public contracts. This is because not all participants will be able to execute a private contract, and so if that contract can update a public contract, then each participant will end up with a different state for the public contract.
2. Once a contract has been made public, it can't later be made private. If you do need to make a public contract private, it would need to be deleted from the blockchain and a new private contract created.

##Setting up a Permissioned Network Network permissioning is enabled at the individual node level by adding the -permissioned flag as the command line parameter during node startup. When enabled, the node looks for a file named permissioned-nodes.json in the node's <data-dir> folder.

The permissioned-nodes.json file contains a list of node identifiers (enode://remotekey@ip:port) that this specific node will accept incoming connections from and make outgoing connections to.

If the --permissioned flag is set but the permissioned-nodes.json file is empty or is simply not present in the node's <data-dir> folder, the node will start but it will neither connect to any other nodes nor will it accept any incoming connection requests from other nodes. Expect to see errors being logged in either case.

The --permissioned flag is available under the Miscellaneous list of geth options:

$ geth --help
  ( truncated output )
  MISCELLANEOUS OPTIONS:
  --permissioned          If enabled, the node will allow only a defined list of nodes to connect

Note: Delegating network permissioning to individual nodes has obvious drawbacks. Moving permissioning to a Smart Contract based model to alleviate this is on the Product Roadmap.

Checkout the permissions example on how to run nodes with permissioning enabled, or see the set up instructions below.

###Steps to Enable Permissioning:

1. Create a file named permissioned-nodes.json in the <data-dir> folder, ensuring it is correctly JSON-formatted.
2. Populate the file with the enode ids of the nodes on the Quorum Network you are setting up/connecting to.
3. Start your node with the --permissioned command line flag.

The format of the permissioned-nodes.json file is as follows:

[ 
"enode://remoteky1@ip1:port1",  
"enode://remoteky1@ip2:port2",  
"enode://remoteky1@ip3:port3",  
]  

For example ( node-id is truncated for clarity):

[
 "enode://8475a01f22a1f48116dc1f0d22ecaaaf77e[::]:30301", 
 "enode://b5660501f496e60e59ded734a889c97b7da[::]:30302",
 "enode://54bd7ff4bd971fb80493cf4706455395917[::]:30303"
]

The above will ensure that this node can only accept incoming/outgoing connections from/to the 3 nodes in this whitelist.

###Adding New Nodes: Any additions to the permissioned-nodes.json file will be dynamically picked up by the server when subsequent incoming/outgoing requests are made. The node does not need to be restarted in order for the changes to take effect.

###Removing existing nodes: Removing existing connected nodes from the permissioned-nodes.json file will not immediately drop those existing connected nodes. However, if the connection is dropped for any reason, and a subsequent connect request is made from the dropped node ids, it will be rejected as part of that new request.

Note: Allowing for dynamic node removal is on the Product Roadmap.

##Quorum API Please see the Quorum API page for details on calling and interrogating the BlockVoting contract.