3

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?

Improve this question
0

2 Answers 2

Reset to default
3

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.

Improve this answer
4
  • 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
    Commented Aug 9, 2016 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
    Commented Aug 9, 2016 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
    Commented Aug 9, 2016 at 11:05
  • Yes, you always need to have a binding between the peer that is connecting and the allowed public keys.
    – Sebi
    Commented Aug 9, 2016 at 11:47
1

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.

Improve this answer
5
  • 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
    Commented Aug 9, 2016 at 11:07
  • @Borinho Can you ask specifically what are you trying yo achieve?
    – niksmac
    Commented Aug 9, 2016 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
    Commented Aug 10, 2016 at 14:18
  • @Borinho xy problem
    – niksmac
    Commented Aug 10, 2016 at 17:13
  • you are quite right - im trying to get clues
    – Borinho
    Commented Aug 11, 2016 at 8:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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