Simple^2 and the hazard of layers

Getting your Trinity Audio player ready...

This post originally appeared on Elas.Digital site and we republished with permission from its author, Brendan Lee.

While I was developing the Elas token system’s base patent I had the pleasure of working with Cerian Jones who is one of, if not the most experienced patent attorneys in the Bitcoin and Blockchain space. And this was so important because she knew exactly where to challenge me on the idea.

When I put forward that things were a particular way because of an assumption her first move was always to challenge that assumption. Before my very eyes what I thought were the best parts of the idea were unmasked as cruft, excised and re-defined as embodiments that demonstrated a function of the core structure. Working in this way we were able to pare the whole idea down to its absolute core—a token that is created as an unspent output and which is transferred by spending it to a new unspent output. This transfer action effects a state change on the token, meaning anything from a change of ownership, a change to a parameter, new activity in a database or any other of a number of actions that could be performed on a token. The issuer has complete control in this system and can add whatever definition they like to the tokens within their system.

We have demonstrated Static tokens, which were used in our Commemorative Bitcoin token giveaway, but we have many different token types coming for many different purposes, and all are built upon our core token creation method.

Layers 

I watched the recent CoinGeek Live panel on tokens and the discussions on layer 0 vs 1 vs 2 etc. I would summarise it thus:

Layer 0 – A token held in a script which performs all token management logic within the spending action, looking at the input and forcing conditions into the output to manage future token behaviour.

Layer 1 – A token or tokens that are carried in a UTXO but where token values are represented by data carried outside of what is evaluated by the consensus network

Layer 2 – Tokens controlled by an agent or smart contract using instructions published in False Return scripts

Elas tokens are at their core raw Bitcoin protocol. There are no requirements for scripts that look forward, no script templates, data carriage, unspendable outputs, or third-party agents, however we can (and plan to) make use of all of these things to enhance our value offering.

Elas is a token system that has none of these constraints as a requirement, but where some or all of these elements can be applied, but only if they are needed. It is none, some or all of these layers at once…

I would thus define layers as follows:

Layers are for the platform to add, not for the token system to require.

If you’re building on a token system that depends on one or more of these things when your platform does not, they become a burden that you must manage and build around. This takes time and adds a complexity burden to any project.

Our tokens have a few rules that users must follow which aren’t part of the consensus rules of the network and which can lead to tokens being removed from circulation if not followed. Problems like this are simple to fix and can be managed through proper wallet integration. When paired with a system that removes the need to handle BSV to pay fees with results in almost no impact to usability.

But how does it work?

Over the three days of the CoinGeek conference we handed out an estimated 1200 collectible commemorative Bitcoin cards to people from all over the world using a simple web wallet we put together to test our tokens. The experiment was a great success and I had several people coming to me perplexed that there was just a regular P2PKH script holding the tokens. I think part of the magic of our system is that token transactions are practically indistinguishable from Bitcoin transactions.

Tokens are held in a live UTXO and can be recognised through a tracing mechanism that follows the token back to when it was created. This mechanism is free of any constraint relating to scripts, data or agency, allowing Elas tokens to be released into an economy in a form representative of private cash.

The platform is enhanced using a back end that we have developed to manage token identification and validation for user wallets. This allows for instant transfers and will be how most implementations of the system will work long term. A connection to the Metastreme fee payment API means that users don’t have to touch BSV to send or receive payments while keeping transactions safe, simple and instant.

Soon we will begin internal testing of a new token minting layer that will enhance our token ledgers, making them much easier and less complex to manage longer term and give us some much-needed usability enhancements we need to accelerate and simplify the creation of sophisticated sub-ledger structures and tokens.

Simple^2 or how to KISS

As an engineer I have spent my career working around complexity. It is almost never helpful or wanted and usually creates a huge burden, especially when it is not well understood at the beginning of a project. Keep It Simple Stupid, or the KISS Principle is touted throughout the engineering world and is something that I’ve seen applied both beautifully and not at all…

Elon musk says it best:

The best process is no process. The best part is no part.

With Elas, only exactly what is needed is used, and as such the overall complexity of the system is kept as low as possible, without sacrificing utility or security.

Say that a simple thing has a difficulty quotient of 1, and a complex thing of 2. If you must take an existing platform and build your application on top of it, we can thus say:

Simple on top of Simple is Simple^2, or 1 x 1 = 1.

Simple on top of Complex is Simple.Complex, or 1 x 2 = 2.

Complex on top of Complex is Complex^2, or 2 x 2 = 4

Where a base system has an inherent complexity function, everything you build on top of that system compounds that complexity. That compounded complexity increases the cost and time it takes to deploy a system and makes it far harder to maintain and extend in future.

To summarise…

When evaluating token systems, if the vendor has already defined the box that you need to operate out of, you must be sure that your platform can function from within that box. Tokens can be applied in many ways and I think people have really only begun thinking about new and different use cases. We at Elas are excited to bring our system to market. I believe that Elas has managed to find a means by which tokens that fully embrace the KISS principle can be created and deployed in a way that accelerates development and ensures the best possible user outcomes.

Watch Brendan Lee’s presentation at CoinGeek Live 2020 Day 2.