The Decerver: The Distributed Application Server

Apps
1

Secure Autonomous Serverless - The Distributed Application Software Stack

- YouTube

When We Started Eris Industries, We Asked Two Questions

  1. Is it possible to build applications which have the benefits of interconnectedness, but without servers? It is. Distributed applications can perform the same functions of modern web applications by enlisting users to participate in the management and security of these applications’ data.
  1. Is it possible to create data-driven interactions which are both autonomous and legally compliant? It is. Data-driven interactions are not exempt from legal norms and procedures, and platforms capable of operating within existing legal frameworks will be profoundly useful to businesses and individuals alike.

With Eris Industries’ open-source Distributed Application Software Stack, developers can rapidly design, test, and deploy distributed applications which are as flexible, user-friendly, and legally compliant as they are secure.

Think of us as the node.js of peer-to-peer technology.

Components:

Decerver
The Distributed Application Server

The Decerver is the application server for our Distributed Application Software Stack. Using the Decerver, developers can build distributed applications which easily interact with a diverse set of blockchain and peer-to-peer protocols, all of which have been harmonized in an interactive layer that can be accessed via a JavaScript runtime. The Decerver empowers blockchain technology to become usable in a fully legally-compliant context for the first time.

Thelonious
The Makers’ Blockchain Design

Thelonious is Eris Industries’ customizable, smart-contract enabled, smart-contract controlled blockchain design and one component of our Distributed Application Software Stack. Derived from the Ethereum protocol, but built to meet differing design goals, Thelonious gives developers the control to define their own state-of-the-art blockchain. Thelonious is not meant to be one blockchain, but millions of them, each made for specific applications.

The Decerver: The Distributed Application Server

Introduction

The Decerver helps developers build applications which leverage opt-in data ownership and significantly increased data utility for both customers and businesses – a software design paradigm we call Participatory Architecture. Using peer-to-peer and distributed systems, the Decerver allows the creation of web style, data-driven, interactive distributed applications that can be safely, securely, and reliably deployed and managed. The Decerver significantly lowers the barrier to entry for the production, distribution and maintenance of distributed applications. All while allowing users to participate in the scaling and data security of the application.

More specifically, the Decerver is a distributed application server harmonizes actions across various modules which act as distributed file stores, distributed data stores, or other utility modules. The Decerver integrates distributed data stores (blockchains), a distributed filesystem, a scripting layer, and a legal integrator to incorporate Legal Markdown-based contracts into the smart contract stack – effectively putting the “contract” into “smart contracts.”

Applications built for the Decerver are based on web design modalities. In other words, the user interfaces for these applications are written in languages which almost any developer, and even some heads of state, can write. Applications for the Decerver use HTML, CSS, and Javascript to provide their user interface.

Each of the modules which the Decerver utilizes has an established interface which exposes functions to a javascript runtime that executes inside of the Decerver’s core. These exposed functions allow a distributed application developer to design and implement a distributed application almost entirely in javascript – with the exception that if a blockchain that uses smart contracts is needed for that distributed application, the developer will need to use one of the smart contract languages to build those smart contracts (and the other exceptions of html and css of course).

When put together it looks like this:

Thelonious: The Makers’ Blockchain Design

Introduction
Thelonious is Eris Industries’ open-source blockchain design. Thelonious is both smart contract enabled as well as smart contract controlled. Thelonious is a heavily modified version of Jeffrey Wilcke’s Go client for the ethereum protocol.

Thelonious is not a single blockchain, it is a blockchain design. It is purposely designed not to be one blockchain, but millions of them: to complement, rather than compete with, its larger, fully-distributed cousins. Although at its base level Thelonious can deploy a blockchain which has the same parameters as the draft ethereum blockchain, Thelonious was designed with a different set of parameters in mind. We have designed Thelonious as a corporate-, organisation-, family-, or application-specific blockchain to work in conjunction with the Decerver and the other components of Eris Industries’ Distributed Application Software Stack.

Thelonious allows developers to use blockchain architecture to design, test, deploy, and operate distributed applications. Developers who use a Thelonious client to manage their blockchains are able to benefit from having a parameterized smart contract in the genesis block which is capable of managing the consensus and security mechanism of the blockchain through the use of smart contracts. By moving the block consensus and security mechanism out of the client and placing those parameters and instructions into the blockchain itself, we have been able to significantly diversify the types of blockchains which a single client can manage.

Combined with the Decerver, Thelonious is able to interact with other blockchain protocols and APIs with ease. Using the Decerver and Thelonious together allows developers to harmonize the building of their distributed application with a chain that has been purposely designed for their application rather than trying to fit their application into the structure of a general-purpose blockchain that was not designed for them.

But what about security? In distributed systems, security and consensus are different names for very similar concepts. Thelonious puts the power, and the responsibility, onto distributed application developers for properly parameterizing the Thelonious blockchain design for their application. Whether security comes in the form of checkpointing a chain against Bitcoin’s (or eventually ethereum’s) larger, heavier, and more secure blockchain, or whether security comes in the form of greatly restricted committing (“committing” being Thelonious’ equivalent of what other blockchains call “mining”) ability, Thelonious allows developers to craft consensus and security mechanisms which match the design goals of their distributed application.

Thelonious was designed for deployment in a variety of contexts, from locked-down internal corporate deployments to more decentralized and public deployments, or from deployments which require tokenization to those that only require the utility of a blockchain but not monetized tokenization to compensate miners for automated database management services.

A single Thelonious client is all that is required in order to participate in all of these blockchains.

1 Like
2

A blog post that breaks the Decerver concept down somewhat:

Eris & dapp infrastructure

This week, Eris released their distributed software application stack. A lot of people have been wondering: what’s the point? So I dug in.

There’s (roughly) 4 parts to blockchain-based applications.

The blockchain.

The protocol.

A protocol implementation.

An interface.

—-

The blockchain is the distributed ledger. (Bitcoin’s chain. Dogecoin’s chain.)

The protocol is the agreed upon “language” by the participants in a specific network to be able to work with the blockchain and its peers.

A protocol implementation is software written that directly interacts with the blockchains (committing and retrieving information). This is tied together with a network layer. Protocol implementations talk through p2p protocols, syncs blockchains, mines them, modifies them, etc. Examples are Bitcoin Core, btcd, Obelisk and so forth.

The interface is the software that “talks” to a protocol implementation to get information about the network and the blockchain.

Sometimes the interface is combined with the protocol implementation. In early Bitcoin history, this was the case, but over time, they have been split: to separate concerns. You don’t want to run memory related to the wallet interface when you aren’t using it. In some cases, they are still combined.

Combined examples: Android Wallet & MultiBit [usually SPV wallets].

Non-combined examples: Coinbase, Hive, Blockchain.info.

Both protocol implementation & Interface [don’t have to be used in conjunction]: Coinbase’s Toshi & Bitcoin Core.

Additionally, interfaces can probably be divided into 2 parts: Developer interfaces (such as Chain.com), or user interfaces (Coinbase). They are sometimes combined as well: such as Blockchain.info.

As the protocol implementations improve, increasingly, the question becomes: What does your interface look like? And how does your interface talk to the protocol implementations?

When I built Min.io with my brother early last year (don’t go to the site, I’m pretty sure it’s broken), we rolled out our own Bitcoin node (on aws), and we wrote our own server that interacted with it [handling payments and so forth]. Building it now, we would probably have used Chain.com instead. We also wrote our own Node.js wrapper to Bitcoind. Effort that should been spent on: 1) building cool shit.

Now this is where Eris comes in.

The most important is their “Decerver” [short for decentralized server]. It’s an application server [‘back-end’] that specialises in building dapps [decentralized apps].

Usually a back-end consists of a language [Python, Javascript, PHP] and the framework that processes the requests [Django, Node.js, Laravel]. Decerver uses a javascript-based scripting language called Ate that processes requests from the front-end. Ate then, with the help of several modules (that you choose), interacts with the protocol implementations.

So, compared to the usual web infrastructure, Decerver replaces your back-end so that you can more easily interact with your database [which is a blockchain]. You could build a Bitcoin wallet interface with Decerver without worrying about writing your own wrappers.

What’s the point?

Decerver provides several new functionalities that makes it easier for dapp developers (and users).

  1. There is a sandbox. When interacting with Bitcoin, you don’t really have to worry that you’ll run some script that will destroy your computer. However, with more complex dapps, you must contend with the possibility that a rogue entity might embed some actions into the blockchain, that when read and executed by your app, it could be harmful (Gregory Maxwell embedded javascript in an OP_RETURN that would be harmful if not properly protected). Ethereum implements its own virtual machine. Decerver does this at the app layer.
  1. It’s about decentralized distribution as well. Like “Docker for dapps”. You can clone a decerver app, run it, on your local machine and immediately use it. This is where decerver makes the most sense. The decerver app contains the front-end code and the “controller” code [ate]. You could however run a decerver like a usual server (someone uses the app remotely). In a way, it’s like Tesla’s motto. “We want to make a great car, that happens to be electric.” With the decerver, it’s an app server that happens to works decentralized as well.

Thinking bigger.

Thinking of Eris in terms of building wallets to Bitcoin is somewhat limiting and doesn’t quite explain why you would want to use it. It’s only marginally useful in that case.

Thelonius is their other product that explains the scope of their stack. Thelonious is a “moddable” blockchain. It’s taking the blockchain and stripping it into 2 areas: the data-structure, and the consensus rules. With Thelonious, the aim is to with a smart contract itself define how the blockchain functions: who gets to commit, and how, etc. A new Bitcoin-like blockchain would have rules related to saying it is PoW with SHA256.

The cool thing here is that with Thelonious you can create, for example, a blockchain that records your company’s inventories: it automatically doubles as an audit trail. The initial smart contract specifies that only certain company employees can write/change it. A company would then not need to run any additional servers or “cloud” architecture if you install thelonious chains on each employees PC, and then get them to download the interface (the decervers).

It’s an exciting space, I must tell you this. I feel they are thinking almost 5 years too far ahead. Here’s a definite business goal, especially in terms of enterprise. If you can roll this out and do immense cost savings for companies, it’s a definite winner.

In other circumstances, I feel tools such as Counterparty or OpenBazaar would benefit from this. I spent a week trying to get Dogeparty to run natively on my Mac. A decerver would smooth out a lot of this process.

3

What is “opt-in data ownership?” Does this mean if you opt in Google owns your data? Or is it somehow that you data is by default owned by whoever is spying or bait and switching?

4

“What is ‘opt-in data ownership?’”

This is a decent question. It does seem rather like buzz words.

“Does this mean if you opt in Google owns your data?”

I’m having a tough time considering this a question worthy of any sort of answer. Where would you get the idea that Google or any other large corporatioin would have the ability to own data from decentralized data stores?

“Or is it somehow that you data is by default owned by whoever is spying or bait and switching?”

What possible meaning could you mean by “sping or bait and switching” on open source distributed protocols and software interfaces to those protocols?

5

@McChris

I see your point. Sorry about the tone. Presumably this would be someone trading information about themselves in exchange for some service. I find this on its face to be a bad and dangerous business model. The mining of privacy strikes me as inherently dishonest. I am also uncomfortable with the notion that more contract (even smart contract) is better. Old arguments about freedom of contract strike me as pure idiocy or generally not amounting to more than “freedom to oppress” claims where the abusers couldn’t just come right out and say they were trying to argue for injustice. The best that can be said about contract is that it can make life more predictable but its still a crude means as we humans are not able to see that far in the future. Asking for more contract than is necessary or more risk mitigation is like trying to increase gambling or unnecessary betting.