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:

	Permissionless	Best-of-both worlds	Permissioned
Transactions/second	Slow	Fast	Fast
Consensus protocol	Nakamoto	BFT family	BFT family
Network setting	Open to everyone	Open to everyone	Enterprise/Consortium
Censorship resistance	Yes	Yes	No
Network effects	Yes	Yes	None
Economic valuation	Higher with cryptocurrencies	Higher with cryptocurrencies	Lower due to its closed-nature
Identity	Pseudo-anonymous	Wildcard identity list	Wildcard identity list
Regulation compliance	Non-compliant	Legal and compliant	Legal and compliant
Sybil-resistance	PoW/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.