Multi member consortium - governance of shared resources

Copper Contributor

Azure's Blockchain Workbench offers "Multi-Member with one member subscription, and Multi-Member System Deployed in One Shared Subscription options" for consortiums.

 

I understand the "application / blockchain protocol" level governance tools available to each party in a multi-member consortium. 

 

How does governance of the shared infrastructure services work?

 

What I currently see is one party currently launching the blockchain platform on a specific enterprise plan (with a fixed set of nodes), inviting members, giving invited members no capabilities to manage the shared resources (e.g. they can set up private channels and invite other members, and launch/remove their own nodes/peers).

 

Some questions I have:

Does the party who launches the blockchain consortium instance on Azure have more "powers" than invited members?

Can an invited member add more peers or remote nodes than the rest of the consortium, and then perform something like a 51% attack?

Can fees be split between consortium members?

3 Replies

I assume you're talking about the governance built into the Ethereum POA on Azure solution.  Each member on the network gets to deploy and control their own infrastructure.  We make it easy to connect each of these sets of nodes.  The reason each member has multiple nodes is to provide a highly-available representation on the blockchain network.  

 

Does the party who launches the blockchain consortium instance on Azure have more "powers" than invited members?

Just by deploying your nodes and connecting to the existing members, you are now syncing and validating every block on the network.  If you want to start being a block-producer, you must be voted-in as an "admin" on the network.  As an admin, you get the ability to vote for or against other admins, and can assign your nodes to product blocks.  All admins have the same power on the network. 

 

Can an invited member add more peers or remote nodes than the rest of the consortium, and then perform something like a 51% attack?

Each admin can only assign the amount of block producers equal to the first admin on the network (whoever set up the initial deployment).  For example, if the first member deployed four nodes, each member that joins can only add up to four block producer nodes.  They may deploy more than four nodes, however, the remaining will simply act as transaction nodes on the network (not produce blocks).

 

Can fees be split between consortium members?

Transactions are free in POA networks so Ether doesn't have a real purpose.  There are other mechanisms more suited for identity based networks for controlling bandwidth allocation.  See this section of our docs for more details.

Thanks for the feedback Cody. 

On fees, I'm asking about the subscription plan for the nodes, payable to Azure.

IBM allows consortium members to split between members:

"For priced plans in the IBM Cloud, don’t worry, you’re not alone, the cost of a blockchain network is shared across its members!
How does it work? First choose one of the following service plans.  For monthly plans, each member organization must pay a network entry fee, and then purchase Fabric Peers which provide access to the network for deploying and executing chain code, and for updating the ledger." - https://www.ibm.com/blogs/bluemix/2017/08/ibm-blockchain-platform-generally-available/

Is a network split pricing option available on Azure? 
My concern is that the entire existence of the network depends on 1 member being up to date on their fees within a consortium, for the network to exist. Splitting it reduces the risk and is more fair to consortium members

 

- Zaid Mahomedy (unsure why my profile appears as null on this forum)

 

Hi Zaid,

 

You shouldn't have a single party in control of any layer of the ledger stack; from cloud provider to node operator.  As I mentioned above, each member on the network gets to deploy and control their own infrastructure.  This means that the billing is separate and there is no centralized dependency.  If one member doesn't pay their bills, there nodes will go down; however, a blockchain network should exist across multiple members and subscriptions, implying that the ledger will not be impacted.