For a business use case I am conceptualizing for my master's thesis, which is based on a Blockchain system, I need to understand impacts on decentralization/trustlessness.

Many people argue that private instances are utter nonsense, and you might as well use centralized databases because you need some kind of access control to let parties join the network and therefore and central entity controls it all. In my case, a consortium of three companies would set up a private Blockchain for confidentiality reasons.

Question: How to implement access to permissioned/private/consortium Blockchains in a decentralized or at least democratic manner?

If the nodes and their respective network addresses are defined contractually, let's say each stakeholder sets up 3 nodes, I don't see the need need for a central gate keeper. A befriended ethcore dev told me that still anybody could join the network an compromise it, yet I don't know how and why. Alternatively, I could imagine staking as Sybil-control where each member gets an equal share.

3 Answers 3


The original question seems to conflate the underlying platform and the application built upon it which can be thought of, in some cases, as an overlay network and often has its own access control concerns.

As you know, a public network is generally organized so that anyone who follows protocol can attach a node. By extension, that means node operators are pseudo-anonymous and accountability will be weak while censorship-resistance will be high. In many contexts accountability is a desirable thing and there may be no good reason for the general public (non-members) to access the network, e.g. a B2B network for a consortium of trading partners.

Great. So, given a context and set of requirements, the appropriate network topology should be approximately self-evident.

Application-level concerns still exist and they are not addressed with precision by network topology alone. Consider that everything-to-everything TCP/IP networks are populated by applications that do indeed authenticate users and categorize them according to privileges. To say that another way, nothing about the Internet's open architecture implies that everyone can anything. And, there are valid reasons for private networks that are not reachable from the public network. The same applications can often run in either context - internal web-based app and external public-facing web site.

It is very common for a system of smart contracts on the Ethereum public network to restrict access to sensitive functions to the owner/deployer, an admin, or something more granular. Standard libraries like OpenZeppelin's Ownable, Whitelisted and Role-based Access Control implement such patterns in Solidity.

Such patterns can re-introduce degrees of centralization, intentionally or accidentally, because only specific authoritative users can do certain things. This can lead to a governance consideration at the application level. Who should decide? Is that a single user or a committee? How does the committee decide?

So, there are platform-level concerns and they imply certain things about what's going on. Ethereum means everyone can see, while Quorum's private transactions mean certain parties can see, Hyperledger Fabric's channels mean messages go to groups of nodes and Corda networks work on a need-to-know basis. When working with private networks, one can expect to spend considerable time working out a topology that doesn't advantage or adversely disadvantage the intended participants. One will spend more time on that because of the flexibility offered.

As with any platform, the choice of platform implies certain low-level properties of anything one builds and concerns for the applications one constructs, so it is wise to select the right platform, but, application-level concerns still exist. Access control will still be a concern on a function-by-function and message-by-message basis.

You can create centralized points of control in contracts on Ethereum's public network. One of the key concerns when designing a system is where to vest the trust, especially if a decentralized design is desired. Indeed, when auditing contracts one of the key concerns to look for is elements of the contract logic that might give certain users non-obvious advantages. For example, if a contract can be paused by the owner, immutability has been compromised and users should be informed about that possibility.

Hope it helps.

  • Design patterns to introduce centralized control to smart contracts like ownable.sol are known. My question was rather pointing to how to deploy a private Ethereum instance (such as Quourom, Besu) in a decentralized way. How to exclude external nodes and how to give access? NetworkId is insufficient. So you would need certificates or some kind of whitelisting. But then, who would be in control of that?
    – Marcellvs
    Mar 10, 2020 at 11:26
  • I did not understand that from your question. You are correct. Admission-control may be a centralized source of authority that is meant to represent off-chain governance. The group is free to implement their own procedure for applying, voting and admitting new members. The protocols are unopinionated about how that works so it often looks like a singleton. It wouldn't be controlled by a lucky individual with outsized privilege, because the others wouldn't agree. They will all want a say in what is decided and how it is decided. Mar 10, 2020 at 16:46
  • The signing key becomes a fiduciary or custodial responsibility, something the target users are familiar with. Whoever has it is constrained from using it without formal authorization from the governing body. Even if the keyholder goes rogue and uses it without authorization, the change won't stand because the governance process will clearly show it was an unauthorized action. The threshold for a rollback is the consent of the participants - much lower than mainnet - the same people who vote on changes. If they decide something was improper, they can amend it. Mar 10, 2020 at 16:51
  • I might have to rephrase the question to make it more clear, but I think the discussion is heading the right way. "The group is free to implement their own procedure for applying, voting and admitting new members. The protocols are unopinionated about how that works so it often looks like a singleton." What I am also talking about are best practices on how to set up the network (I suppose whitelisting certain IP addresses) and how to distribute the genesis configuration. Furthermore, the question would be if onboarding of new parties could be solved in a democratic on-chain manner.
    – Marcellvs
    Mar 28, 2020 at 18:20
  • You can look at Tezos for an example of on-chain governance. I think you'll governance of network membership is an off-chain process left up to the network operator in most private chain settings. It does not necessarily need to be that way, but the alternative implies an opinionated approach and the need for everyone to agree on it. Many use a certificate authority or gatekeeper to manage memberhip, so it is about proposing an automated process that would guide it. Mar 28, 2020 at 22:44

You could create a smart contract token, even on a public block chain, requiring a user to have one of a predetermined set of wallet addresses.

Alternatively, you could use a system like Blockstack in a similar way to SSO. Where you limit users logging in to a specific set of domains @whitelist.com, @partners.com, etc

  • I am aware the access control mechanisms allowing only transactions from certain pubkeys and I also consider this type of implementation but it does not solve privacy associated issues. zk-SNARK transactions cost up to 1.6 million gas which is not feasible.
    – Marcellvs
    Dec 10, 2018 at 12:58
  • You could use the same mechanism with a private blockchain Dec 10, 2018 at 12:59
  • You are right, and in order to keep in decentralized on consortium level I would require a multi-sig mechanism in order to add or remove certain participants?
    – Marcellvs
    Dec 10, 2018 at 13:19
  • Yes, that's one of many ways Dec 10, 2018 at 13:29
  • @marcellvs how does zk SNARK cost that much gas? Curious to know. Mar 6, 2019 at 16:28

Maybe this can help you, you can manage the access trough addresses with the Smart Contract: https://docs.openzeppelin.com/contracts/4.x/api/access

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.