Membrane

Everything you wanted to know, but were too afraid to ask.

About

If you have been hanging around on Merge's communities for a while, you have probably heard about Membrane. Little has been said about it: what it is, how to use it, how it will affect the development of Merge ?— are questions that remained unanswered for a long time. Does it even exist? Is it a software tool? Or is it just an idea? These are questions that are addressed one by one in this article.

First off, let’s start by stating what Membrane is not — Membrane is not a software tool or framework. But that doesn’t mean that a framework cannot be built following the Membrane specification.

In a nutshell, Membrane is a protocol. A protocol consists of a series of definitions on how multiple pieces of software can communicate and interoperate. And the main goal of this protocol is to define a standard for value exchange within an application and among applications.

Before the advent of smart contracts, all software execution was “for free”. All you needed was call a function and wait for it to return the desired results. It did not matter if the function required a lot of CPU processing power to execute, or activated a physical device that uses up electricity, fuel or any other scarce/expensive resource for its execution. It would just run and give you the desired results without charging you a penny.

Overview

However, we do know this is not how the real world operates. Companies normally use equipment that requires energy, fuel and other resources to ensure its continuous operation. And many times, the different machines that integrate a supply chain operation belong to different companies or individuals. The resource sharing between components can become incredibly complicated as the operation plant becomes more complex. That can make billing systems unmanageable. Membrane protocol provides fine-grained strategies for value exchange within an application, as well as between different software modules. It will enable us to, for example, create an ecosystem where mobile phones can make their data connections available (through Wi-Fi or Bluetooth connections) to anyone who wants/needs to access the internet and is willing to pay a few cents for it, thus creating a distributed network that everyone can use to access the internet, provided there is proper value exchange for the amount of data or connection time used. That enables mobile phone owners to be paid for offering that service to the network users, and thus monetize their personal connections, like in the picture below.

In the picture above, a user trades a token of a certain value, for a certain amount of time or data in order to connect to the Internet. The value exchange between the user and the access point provider occurs automatically following the Membrane protocol.

Membrane also has another interesting facet: It specifies a modeling standard for DAGs. DAG stands for Directed Acyclic Graph, which is the common ancestor of blockchains and other data structures where cryptocurrencies and other logical models are built upon. This means that a blockchain, for example, can be defined in terms of building blocks that follow the Membrane specifications. And the protocol goes even further — it allows for defining Business Model classes, that is, application classes that map the most basic blockchain transactions (for blockchain-based applications) into end-user objects and functions, making it easier for application developers to use the blockchain and other DAGs as a resource to enable value exchange within a real world application.

The picture above exemplifies, in a simplified manner, the different levels of abstraction that the Membrane specification covers. The actual specification is more detailed though, but the chart above gives you a grasp on how basic logical blocks are mapped onto real world object classes for a blockchain-based end-user application.

The next paradigm that Membrane addresses is that of value exchange or value transport. Like in the Wi-Fi sharing application explained earlier, calling a function that requires resources is a costly process and will require the caller to send a certain amount of tokens to the callee, and this ensures that the calling process or thread rewards the called function for its service, assuring proper transfer of value throughout the application. Many other examples and use cases can benefit from this concept, like the classical Uber-like application for example.

In the example above, the Rider is mapped as an Entity (A Membrane Business Model object) and the Driver is an object of the type Business Unit. To request a ride, the Rider calls the RequestRide() function which ensures that the ride is funded via the sub function called FundTransaction(). The Driver then accepts the ride via the AcceptRide() function call and makes sure that funds are locked until the end of the trip via the LockFunds() function call. When the ride reaches its end, two additional functions are called: The OnReachedDestination() called synchronously (triggered by the device GPS, for example) releases the funds to the driver via UnlockFunds() call, and finally there is an asynchronous call to SetReputation() that might happen later when the rider wants to give feedback about the driver and vice-versa.

Use Cases

Like these two, many other use cases can be thought of as real world applications for the Membrane protocol. Here are a few more examples:

• An ecosystem for publishing game credits along with a marketplace where they can be utilized.
• A software activation tool based on specific tokens.
• DACs — Decentralized Autonomous Companies — Companies that work by putting together independent business units which interoperate by exchanging services in an autonomous manner.

The two initial examples are being listed as MVPs for a basic implementation of Membrane.

So value is a fundamental issue when it comes to Membrane’s working internals. But where does value come from? Are these ‘tokens’ just yet another coin? How do they interact with Merge and other cryptocurrencies? This is what it is addressed in this last section.

The last concept that makes it possible for Membrane-based systems to operate is the two-way peg between internal tokens and legacy tokens. Internal tokens are generated within Membrane's infrastructure by means of a sidechain, with the purpose of value transfer among the constituent parts of a Membrane-based app. Legacy tokens, by their turn, are our good old cryptocurrencies — more specifically, Bitcoin-derived cryptocurrencies like Merge, PIVX, Dash and Bitcoin itself.

So the two-way peg takes place when legacy tokens are held in a type of escrow feature, so that internal tokens are generated in exchange for them. This can be accomplished by means of an atomic swap. This way, value assigned to Bitcoin and other coins can be internally conveyed by internal tokens during the life cycle of an application. In the end, once these tokens are no longer needed (and the value they carry is properly restored) they can finally be returned to the escrow layer and the legacy tokens can be released to the outer side of the ecosystem.

The image above shows a comprehensive approach for the paradigm of value transport within a Membrane application. To the left, you can see the coins that play the role of legacy tokens that provide value to the ecosystem. These coins are pegged to the internal tokens by means of the atomic swap process. These tokens, by their turn, belong to a membrane sidechain and feed the basic functionality for the Membrane Business logic, which can be accessed by the Membrane Application via a basic API.

What makes this approach very interesting is that the peg layer can be implemented in such a way that Bitcoin, Merge and any altcoin that implements a gateway to the Membrane ecosystem can map their coins into the internal tokens in the same value scale as Bitcoin does. In other words, the Membrane ecosystem will see the value assigned to a Merge-pegged token in the same order of magnitude as a Bitcoin-pegged token. The main consequence of this approach, as the Membrane ecosystem grows and gains adoption, is to drive Merge's market value up towards the direction of Bitcoin's market value.

Conclusion

So this is all you need to know about Membrane so far. Much has been developed, thought and drafted, but, how much of this is real? The good news is that the Membrane specification is close to 100% defined in its white paper, as well as many auxiliary documents. At the current stage of development, parts of the protocol itself are being implemented alongside the development of an MVP (Minimum Viable Product) which is simply a small application that uses the protocol whilst solving a real world problem. But despite all the effort, unfortunately we don’t have a working implementation of the Membrane network yet. The biggest drawback is the lack of development resources and funding. Moreover, we haven’t been lucky enough to find a group of developers that could grasp the greatness of Membrane technology and could carry on with the development of a fully functional implementation that could be launched as a live network.

But we hope this will change in the upcoming months, as more developers and investors get to know the Membrane proposal and how it could change their lives by opening up a myriad of opportunities by adopting an entirely new software paradigm.

Next Steps

The next steps for making Membrane a reality are:

• Building up a team capable of handling all the aspects of the basic implementation.
• Finishing the partial implementation along with at least one MVP.
• Working on the essentials until a basic implementation of the Membrane protocol can be spinned up as a live network.

Project Merge
Knowledge Base