Designing a Security Token Blockchain.
Design choices series 1: Permissioned or permissionless?
Public or Private? We discuss key decisions in designing our digital securities blockchain.
Jump to series 2: direct settlement finality, fork and pool resistance.
Jump to series 3: privacy.
This is the first in a multi-part series where we deep-dive into the design choices behind the Dusk Network. In this article we explain why we are creating a permissionless blockchain.
First, let us briefly touch on the role of a consensus mechanism. This mechanism sets out the rules whereby nodes, or in our case provisioners and block generators, check and audit transactional input (data) before storing it indefinitely in the blockchain. At the same time, the consensus mechanism makes sure everyone is running the same blockchain.
Defining Permissionless, Permissioned, Public and Private.
The term permissionless blockchain relates to the consensus. If any node can participate in the consensus at any moment, a blockchain is deemed permission-less. The ability to read and write transactions, and to freely build and deploy dApps and Smart Contracts makes a blockchain public.
Conversely, permissioned blockchains elect consensus members either centrally or through select stakeholders.
A permissioned blockchain can be public or private. Which means it is closed to authorised parties by a central authority. Permissionless blockchains are de facto public.
Why we chose a permissionless blockchain.
Deciding on a permissioned or permissionless blockchain architecture is one of the most consequential design choices. Primarily, the decision is about the level of centralisation in the governance of the blockchain, the potential for interoperability and thus its ecosystem and ability to expand.
Interoperability has a lot to do with scalability. If we take an educated guess into the future outlook of digital securities we expect a rich ecosystem with various tech providers. So designing for interoperability across protocols is key. Reconciling (private) permissioned blockchain networks at scale is infeasible, because it requires approval from the federations governing them, and leads to power structures we want to avoid. Conversely, the permissionless domain treats interoperability as an important maturity requirement, which matches our industry view.
Trust in the immutability of the blockchain is another key aspect. The ability to audit open source code, and transactions provides a level of transparency that people have come to expect from ecosystems reliant on blockchain technology. In a private and permissioned blockchain network, consensus committee members are elected by a central authority. Transactions are not publicly auditable and reversing transactions is technically possible. This leads to the inevitable concern that there is potential for fraud and collusion, to the detriment of trust.
In fact, the topic of permission goes against the inclusivity we strive for at Dusk. Anyone should be able to use the Dusk Network, participate in the consensus and expand the ecosystem. By using a permissionless blockchain any party can become a consensus member and contribute to checking and auditing of transactions. And, without their identities being disclosed — we can significantly reduce the risk of collusion or fraud. However, a point of attention are the issues that come from pooling or resource centralization (i.e. hashing power aggregation), demonstrated in current Proof-of-Work (POW) based consensus mechanisms, where a group of mining pools own a majority of the hashing power. Aside from the resource centralization, PoW is also an extremely wasteful mechanism, which is another point that does not sit well with regulators and policy makers.
Aside from the issues with resource centralisation in permissionless blockchains, there is also quite a lot of improvement needed to achieve a high-throughput blockchain. By mixing the innovations in the field of consensus mechanisms, most notably proof-of-stake (POS), Byzantine Fault Tolerance (BFT) and Byzantine Agreement (BA), we have identified a way to tackle both issues simultaneously. While creating a high-throughput and scalable consensus mechanism, that combats resource centralisation in the process.
During the inception of the Dusk Network, it’s been our priority to create an ecosystem that is accessible by anyone, truly lowering the barrier to enter the financial industry, and replace intermediaries effectively with technology. A (private or public) permissioned blockchain lacks the prerequisite for a global digital securities ecosystem that needs to be built on trust and worldwide collaboration.
Summarizing this into key features, we have a desire:
- to combat governance monopolies
- for interoperability and scalability
- for an open source trustless ledger, preventing collusion
- for high throughput
Hence our decision for a permissionless public network. Because of a choice for a permissionless blockchain we are actively contributing to the topic of zero-knowledge cryptography, to successfully deliver privacy on-chain, while enabling programmability. At the same time we are establishing the foundation for instant settlement finality, and various other novelties to provide pool and fork resistance. Starting on the 17th of May, our code is released modularly.
In our next series, we will touch on the rationale behind designing for privacy. With subsequent articles covering our design for instant settlement finality, fork & pool resistance and smart contracts: specifically a controllable standard for digital securities.
Dusk — Technology for Securities
Dusk streamlines the issuance of digital securities and automates trading compliance with the world’s first programmable and confidential securities.
Designing a Security Token Blockchain. Design choices series (1): Permissionless vs Permissioned. was originally published in Dusk Network on Medium, where people are continuing the conversation by highlighting and responding to this story.