“Creativity comes from constraint” - Biz Stone

Because of the properties that DLT offers, any distributed ledger has the capability to heavily enforce certain constraints. No system administrator, hacker or government can break free of the constraints that are defined by the protocol, and this is a property that no centralized system can offer.

On Bitcoin, we can easily see that the following constraints are enforced by the protocol:

• There will never be more than 21M BTC.
• Entries on the ledger are immutable.
• Only the owner(s) of a private key can sign transactions for a certain public key.
• Every transaction requires a fee.
• One can’t spend the same bitcoins twice.
• One can’t send more bitcoins than owned.
• An N of M Multi-signature account can only transact if at least N of the co-signatories sign the transaction.

Some of these constraints seem pretty obvious at the moment. However, it is important to understand that on a traditional database it is extremely expensive to enforce any of them anywhere close to 100%, which can never be reached.

Any DLT protocol can define a set of rules that will be enforced to all and any participants. This rules can then be used to build applications at a fraction of their traditional development cost.

On the other side, in order to pay for the data processing, every transaction has a cost, its fee, based on the network’s load and for most implementations there is a big limitation on the amount of transactions per second that it can process.

Radix, however, is the first DLT implementation that can scale linearly, increasing the throughput as the amount of nodes increase, and that uses minimal node resources, ensuring maximum decentralization.

Relying on constraints

When building an application, most developers are used to relying on frameworks and libraries that help them work faster. These tools saves them huge amounts of development time by offering plug and play code that provide recurring features such as specific API calls, common calculations and user interface elements such as buttons or icons.

Similarly, DLT can save a huge percentage of development time thanks to the use of protocol level constraints. Since the constraints are built in and enforced by the protocol, the developers can effectively rely on them to build their own systems.

Let’s look at a simple example: Imagine a certification process that requires 3 out of 5 sensors to agree on the fact that a product has passed its corresponding tests. Typically this would require a server that asks each one of the sensors for their ‘opinion’ as well as all the necessary security procedures to ensure that their decision has not been tampered with.

Instead, by using a multi-signature account, the ledger takes care of most of the code. The developer just needs to setup a different private key for each device and connect them to a multi-signature account.