Beyond Blockchains — DJS

Let’s go!

We are creating a new software architecture. This architecture encompasses existing decentralized application technologies, enhancing their capabilities significantly. It enables a new generation of decentralized and distributed applications that go beyond cryptocurrencies and asset management. For us, expanding autonomy of users, distributing power to them, is the key value of this design.

We are inviting you to join the alliance developing this architecture, and the foundation that is dedicated to it.

Architecture for the creation of cryptographic protocols

The proposed architecture relies on a capability oriented language, with the working title DJS (Distributed JavaScript). Cryptographic protocols are defined simply as business logic.

Bitcoin, Ethereum and OpenBazaar are examples of applications implementing cryptographic protocols designed for a specific purpose. In contrast, DJS goes one step deeper: it is a language for creating different cryptographic protocols for various purposes. The added flexibility is important for safe and secure interconnectedness. Bitcoin can be be seen as one VM at the application layer. If we define VMs this way, DJS allows the creation of multiple VMs (decentralized or otherwise), and enables them to interact safely. This means that integration points, and supporting applications (like exchanges in the case of crypto-assets), may also afford the same decentralization, security and reliability.

Atomic transactions

State changes across multiple VMs happen within a transaction. Transactions are distributed and atomic. This means that an operation across VMs, can be guaranteed to be executed as a whole or not at all. If a transaction is not able to complete, an exception is raised so the developer has a chance to retry, or handle it in a custom way. This, combined with other features like verifiability, and non-repudiability, guarantees the reliability of a distributed state change. Additionally, Distributed transactional software memory, allows for non conflicting transactions to continue, while ongoing transactions complete.

The architecture is modular: the developer is free to choose whether an application is centralized or decentralized, verifiable or not, public or private. The application can be distributed among different VMs securely. The architecture echoes the intent of distributed ledger technology: disintermediation of centralised data control and safe interactions between peers without third parties.

Rights and assets

In DJS, the focus is on rights management. The general category of rights makes possible a wide spectrum of relationships, and moves the enforcement of security and access primitives from the application layer to the language itself. For instance, asset ownership is a special case of the category of rights. The thinking behind DJS is heavily indebted to Mark S. Miller’s ideas on “Capabilities As A Cryptographic Protocol”. Crucially, when VMs interoperate via capabilities (smart contracts over the access VM’s have to each other’s objects) their vulnerability is limited in a known way.

Where the architecture goes beyond what is envisaged by Miller, is in extending the capability framework from private and uniquely identified VMs to both public (verifiable, decentralized) VMs and anonymous private VMs. This is where the proposition learns from Bitcoin and similar later protocols, in replacing a “trusted third party” with a public and trust-less protocol. This step is needed to make the objects (in the VMs) identifiable, without revealing who has control over them. This allows parties to a transaction (“wallets”) to remain private.

Decentralized VMs as Smart Contracts

Under DJS, a smart contract is a shared VM between all the parties to the contract. All parties can be given the possibility to verify every transaction and to reach consensus before the transaction is committed. If acceptance by all parties is required before execution, the contract is a private one; if the contract can be joined at any time, it is a public one. A protocol like Bitcoin may be understood as a public contract.

Coding of efficient distributed applications

For example, through DJS, we may define a cryptographic protocol that replicates what a typical blockchain application does. However, the consensus algorithm may be different. We might additionally experiment with the utility of the application being the only incentive required to run it. This is possible because securing the unforgeability of the records on the DJS does not necessarily require the computational cost of a proof-of-work algorithm, or the setting up a proof-of-stake governance (Although these could be implemented, if needed).

In general, the DJS (via capability orientation and utility-based distribution) presents a gain in efficiency when writing distributed applications. The applications do not need to be “handcrafted” as if written in assembler. In essence, DJS provides a higher level abstraction for distributed application programming. That is the goal: “opening the floodgates” by enabling developers to easily and efficiently code distributed applications.

Governance

On current systems, the governance of an application, meaning the ability to update the business logic or the protocols, happens outside the application. This often means disruptive moves like hard forks. DJS integrates governance into the application logic by allowing the application to be iterated according to the rules defined in the application itself. Modifying the application is a right that may be granted on any criteria; for instance, in a crypto ledger application, on the criteria of proof of stake. Iteration becomes an inherent possibility of applications, while a degree of immutability is also preserved.

Modular application design

Allowing multiple applications to connect and interact safely through the rules defined on their business logic encourages modular design. This additionally helps in alleviating the scalability issues faced by current monolithic architectures, allowing applications to iterate in much smaller units.

Ultimately, the design features mentioned above are tailored towards applications that create new economic space: new financials systems, alternative forms of governance, social and political organization, and legal systems.