I might be wrong here, but I'm really trying to find out how to effectively control admission to a private Blockchain instance.

Sure, I can put the IP + PubKey into the static-nodes.js or trusted-nodes.js but do I need to do this to all nodes???

Is there any way to decouple admission control from the nodes?

  • Modify the connection process so any connecting node must have a certificate proving its identity and authorization? – user253751 Aug 9 '16 at 11:27

Unfortunately, by design, Ethereum is not a permissioned (i.e. Eris) block chain (anybody can interact with the block chain given they know at least a bootstrap node's address).

The answer to this question overviews the access control mechanism used by Eris.

  • Alright Sebi, i can both agree and disagree to your statement :) I should have been more precise and generalize on Blockchain rather than to an implementation. But in any case i'd be interested to know, if going down the path of Ethereum and running a private instance, do i need to keep the static-nodes/trusted-nodes.json file consistant across all peers at all times? – Borinho Aug 9 '16 at 8:27
  • Depends on what you mean by private. A private net that has a bootstrap node accessible from the outside (through its address eth://<pub_key>@<IP>:<PORT>) is not private in a sense that any client connecting to it can sync with its copy of the block chain. The same goes if the private net is in a LAN, you only have one layer of security (anybody in that LAN can connect to a bootstrap node and sync with its block chain). Ethereum does not allow for ACL in the proper sense. Yes, the trusted peer list and their level of access must be made available to all nodes. – Sebi Aug 9 '16 at 8:56
  • Private as in permissioned where access to the BC is controlled via explicit Pub_Keys. Now the method via trusted peers might be hard to govern over time... just saying... But I fully get your point! – Borinho Aug 9 '16 at 11:05
  • Yes, you always need to have a binding between the peer that is connecting and the allowed public keys. – Sebi Aug 9 '16 at 11:47

Another choice is to use --networkid along with geth

Read How Peers Are Found and Custom Networks where it states

Sometimes you might not need to connect to the live public network, you can instead choose to create your own private testnet. This is very useful if you don't need to test external contracts and want just to test the technology, because you won't have to compete with other miners and will easily generate a lot of test ether to play around (replace 12345 with any non-negative number):

geth -—networkid="12345" console

You can start geth with geth -—networkid="1434343434" and do the same on other private nodes.

  • Yepp, that works charming, the question was more in general on some proven governance model on how to best admit "members" to any given permissioned blockchain... – Borinho Aug 9 '16 at 11:07
  • @Borinho Can you ask specifically what are you trying yo achieve? – niksmac Aug 9 '16 at 15:05
  • Yes you can. Imagine an industry community with same interest but in competition. Imagine blockchain is an answer to their respective business challenges. I'm looking for a good methodology to explicitly allow members to participate to the blockchain/consensus... Probably whitelisting... But there are implications... – Borinho Aug 10 '16 at 14:18
  • @Borinho xy problem – niksmac Aug 10 '16 at 17:13
  • you are quite right - im trying to get clues – Borinho Aug 11 '16 at 8:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.