Neither Permissioned, Nor Permissionless: Better Together!

One of the biggest enemies of innovation is the instauration of a false dichotomy. Blockchains, and the field of distributed computing is general, has been suffering from this hidden malady for decades: as a general rule of thumb, a distributed computing system should be either permissionless or permissioned (i.e., open v. closed). Below a comparison of the features of each setting:

PermissionlessBest-of-both worlds Permissioned
Consensus protocolNakamotoBFT familyBFT family
Network settingOpen to everyoneOpen to everyoneEnterprise/Consortium
Censorship resistanceYesYesNo
Network effectsYesYesNone
Economic valuationHigher with cryptocurrenciesHigher with cryptocurrenciesLower due to its closed-nature
IdentityPseudo-anonymousWildcard identity listWildcard identity list
Regulation complianceNon-compliantLegal and compliantLegal and compliant
Sybil-resistancePoW/PoS (costly)Wildcard identity list (affordable)Wildcard identity list (affordable)

Our paradigm-shifting blockchain architecture challenges this decades-old conventionalism: by being both permissionless and permissioned at the same time (i.e., a permissioned blockchain that is safe to execute on an open, permissionless environment that includes everyone), we are able to cherry-pick the best features of both settings (highlighted in bold in the table above).

An additional advantage is that there is no need to create permissioned variants of permissionless blockchains, a common activity that is wasting lots of development resources: both settings can co-exist on the same blockchain network.