We need a better framework for applications using blockchain

TokenScript is the framework for better blockchain applications. I’m sure you have seen many of these tech stacks before, most of them are correct and quite useful for explaining what technologies are involved with blockchain or web 3.0. But none of them is useful when you need to make an application which uses blockchain.

I’m sure you have seen many of these tech stacks before, most of them are correct and quite useful for explaining what technologies are involved with blockchain or web 3.0. But none of them is useful when you need to make an application which uses blockchain.

A bit confusing? Let’s look into more details; below is the most popular structure for making a blockchain application. No matter web-based or native-app-based, 99% of existing blockchain applications are in this structure.

By using the web framework for both web app and blockchain, it makes a blockchain application nothing more than a web app.

Just to highlight a few points:

• Security: The whole system is on the same security level as a web app, which is much less secure than the underlying blockchain and smart contract.
  You won’t be able to know that the transaction you sign is what you want to sign. With standard payment transaction this is a minor problem, but as some instances of the keylogger-malware show, still a problem. But when it comes to the complex logic of token transfers, this structure faces significant problems. Sure, you can render transactions in a user-readable format. It’s easy to start with such an effort with a transaction visualizer tool, but ultimately the system integrates and the UX needs would surpass what a dictionary-style transaction visualizer can do.
• Trust: As the code for constructing a blockchain transaction and rendering secure visual or audio is provided by a web app. Which brings done the trust level from blockchain to a typical web app level.
• Availability: The blockchain and smart contract have high availability, notable as 24*365. The web app has a much lower availability compare with blockchain. Put together, it makes the blockchain application’s availability the same as a web app. When the web app is unavailable or down — or maybe when webmaster forgot to pay the SSL certificate — your blockchain application effectively unable to be used, this could essentially be abused in a time-limited event like a voting, auction, etc. The problems become worse when this blockchain application is dependent on another blockchain application.
• Interoperability: It is same as a web app, much less interoperability than a smart contract. Let’s suppose a property guru named Peter creates a website called “Peter’s Pride Asset”, where he selects the best properties available on the market and represents each by a token that serves as the deliverable. Peter can create a listing of those properties with rich information about price, location, and so on, and allow users to purchase it with one click. Peter doesn’t need permission, because the data of those tokens are on the blockchain. However, he needs knowledge of how to render the token on his website. And he also needs to upgrade his website, when the underlying smart contract or the transaction rules was changed. If he misses doing it in time, his users would submit transactions not conforming but getting rejected.
• UX: same as a web app, no context-based UX. Imagine you have purchased a few 1% property shares on Peter’s site. In a traditional wallet, you only see it as little symbols — at best — with no further information. This is not what property investors want to see. They want to have pictures of the estate, prices, charts about the regional estate properties, expected date of payout and so on. You could show this in a wallet. It would ‘just’ require the wallet to adjust to the individual smart contract overloaded with this information or to trust a random website providing this information and adjust the UX to match it. In reality, no wallet made this possible, ending with users either using a website or smart contract providers trying to create their own wallet matching their needs.
• Scalability: Horizontally, the same type of asset might have its token instances across multiple networks like Plasma Chains. Without such architectures, a token economy is hardly able to scale. But having an all-knowing node to provide rendered token information for all existing tokens is hard — and detrimental to the goal of scaling the blockchain economy while keeping the burden on nodes small. Therefore, the knowledge about the token (TokenScript) must be detached from the access to the token.
• Privacy: Almost all business operations involve some kind of identity. When you purchase 1% property token, in most jurisdiction, you are required to provide some kind of identity proof. In the traditional model, when you use a third-party website like Peters Pride Assets, this site requires the identity proof and forward it to the seller, the notary or the authority. We already see this in masses when ICOs try to comply with regulations. Investors are uploading passport pictures on mass. The problems with this approach are well known. You simply don’t want your identity documents being stored on many website databases, if you don’t want to fall victim to identity theft. The website taking your credentials can abuse it — for example, sell or analyze it — or the website can be hacked. The problem of uploading passport images or other identity files on webservers is one of the worst consequence of a web integrated by webservers and lacking an ownership and identity mechanism.

P.S. There are many “solutions” to address each point above. They are more like, busy with fixing different broken parts of a building, but don’t realise those are caused by the wrong architecture was used to build the building.

Before we talk about a new framework, let’s quickly have a look at what is a blockchain for?

The remarkable blockchain speculations that took place in 2017–2018 brought everyone’s attention to crypto tokens. As we bought and sold them, we forgot their intended purpose was to be used; this is analogous to the housing bubble in which people forgot that houses were not merely speculative assets but rather a place to live.
The blockchain serves the role of the trusted third parties. To derive its practical use, knowing its role is not enough; we must understand its utility to the world economy and the Internet. We have gone through years of research and experimentation into its applications both via financial institutions and startups. With this experience, we came to realize that blockchain — as the trusted third parties — can achieve two primary functions:

It provides a frictionless market.
It integrates the web.

Despite the great folly in 2017–2018, it is not a bad thing to initially focus on tokens. Tokens are the enabler of the two primary functions. We define the technique to make it happen in “Tokenisation”. Tokenised rights can be traded on the market and integrated across systems, forming a frictionless market and allowing limitless integration.

What information should be “stored on” (tokenized by) blockchain? Let’s understand it with 2 examples:

Example: USDC

Example: a token is representing a car ownership

a. The information to represent I own this car

b. The information to represent my driver license

c. The information to represent my car instruction manual

d. The information to represent the transaction logic of rights related to this car, transfer, sell, collateralize

e. The information to represent the operating logic of this car: open door, close door, start the engine or locate the car.

The answer is a and d.

If there is no ownership like c and e, please use a digital signature. If there is no ownership transfer, like b, please use an attestation.

The blockchain is for tokenizing transferable rights like ownership and defining the transaction rules. The key takeaway is that all of these are linked to a tokenized right thereby making the token the key point in unlocking web3.0.

After we understand that token is the key, it will be much easier to understand a new structure for blockchain application and the TokenScript framework

Previous efforts in this industry primarily focused on enhancing the technical dimensions like transaction throughput. TokenScript focus on tokenization which serves in the functional dimension. It is a standard which makes the blockchain technical stack complete, providing utility for the economy and the Internet.

A TokenScript file is made of a) JavaScript to make Token work in the user’s wallet or across multiple apps and b) XML data to extract the status and value of the token. It further secures it with a sandboxed and code signed model. In short, it’s like a secure front-end for tokens.

How is TokenScript created and used?

A TokenScript is typically created by the token’s modeller, the team which builds the underlying smart contracts dictating the token’s transaction rules.

TokenScript allows the context (user-agent or trading engine) to:

• Fetch token related information from its holding smart contract, attestations and references.
• Produce a visual or audio rendering of the token
• Produce a list of actions that can be performed and explain how to construct the transactions.

Any party is able to render and apply functions to the token using TokenScript, including entities like generic marketplaces, user-agents and 3rd party apps. We call these parties “context” in general.

What’s in a TokenScript file?

TokenScript is an XML dialect. It describes the functions provided by the token (through smart contract or not), the method to render it on the user’s interface, the ERCs token behaviour templates it uses and the JavaScript needed to construct transactions and render the token. It also defines how attestations are used to decorate, or convert to, or validate a transaction.

Why use XML rather than JSON or some other JS format?

It is helpful to think of the TokenScript file as a project file and the canonicalized version as the final distributable, build target.

XML has certain standards and tools that have been built over time that helps us here:

A. XML canonicalization (c14n) which specifies and provides a portable way to represent an XML file under transmission in an always identical format.

B. XML digital Signatures which is based on signing canonicalized XMLs.

C. XML allows developers to list and describe attributes and actions/transactions declaratively. While it’s possible to do it with JSON, it would likely involve listing them in dictionary and string literals that are harder to enforce schema, validation and track schema changes.

D. standardized static types, with XML we can easily enforce ASN.1 variable encodings to ensure the variable is as defined.

Used together, we can ensure that a given signed, canonicalized TokenScript file has not been tampered with. Without using XML, these crucial properties of XML have to be reinvented and made available.

Ultimately, if we look at the TokenScript XML file as a project file, we can foresee that in the future, we might build tools to manage them instead of relying on editing the XML file directly, then how the file is itself being editable ceases to be that important, and integrity of the file becomes more important.