Asia Blockchain Review recently spoke to Victor Zhang, CEO of AlphaWallet, a wallet engine for the Web 3.0 world. AlphaWallet is focused on building wallets and protocols to bring ideas for decentralized applications (DApps) to life and the company’s products are recognized for its security, usability, and privacy. Zhang talked about AlphaWallet’s mission, the benefits of TokenScript, use cases for this new product, and his vision for the next step in blockchain technology.

Asia Blockchain Review: What is the mission and long-term goal of AlphaWallet?

Victor Zhang: The team at AlphaWallet is committed to bringing Web 3.0 via tokenization. We provide TokenScript, an open framework acting as the ‘HTML’ of tokens and enabling developers to make their tokens ‘smart’. The AlphaWallet app is like a browser for users to access these SmartTokens, which are analogous to websites in the Web 2.0 world.

ABR: Can you tell us more about TokenScript? What are some of its use cases?

VZ: TokenScript makes SmartTokens. These are like traditional ERC20 or ERC721 tokens, but with extendable structure and signed JavaScript to go with it. TokenScript realizes rich functions that DApps previously struggled to implement, and allows them to be traded with flexible, customized trading rules.

A TokenScript file is made of a) JavaScript to make tokens work in the user’s wallet or across multiple apps and b) XML data to extract the status and value of the token.

In short, it’s like a front-end for tokens.

ABR: What are some of the benefits and challenges of tokenization?

VZ: Blockchain serves the role of 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 are technical experts who went 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 trusted third parties — can achieve two primary functions: 1) it provides a frictionless market and 2) it integrates the web. Tokens enable these two primary functions through a technique we define as ‘tokenization’. 

Tokenized rights can be traded on the market and integrated across systems, forming a frictionless market and allowing limitless integration.

The Challenge of Tokenization

For many markets, it is a new paradigm. However, the way tokens are used today, as they manifested in the ICO (initial coin offering) hype of 2017/18, is far from providing what we call tokenization. Most tokens don’t even try to be more than a proxy for the payment side.

To unleash their potential, tokens need to become a lot more sophisticated and fulfill the delivery side. A token protocol must fulfill several requirements:

• Richness. Tokenization needs an endless variety of tokens, which are tailored for their individual use case. This requires bundling the tokens with their transaction rules and behavior patterns. New tokens should be able to enter the ecosystem on an abstracted layer, so that they can be traded and used in different contexts. With the anticipated proliferation of new plasma subnets, tokens should also be able to seamlessly operate on them.

• Embeddedness. Tokenization must allow users to interact with different systems through the tokens. In the example of a car, the token would contain code to interact with a smart lock (e.g. Open, Start or Lock) and the automaker’s own web service (e.g. Locate). Listing the car for sharing is then enabled by another third-party service, which tokenizes the usage of the car by hours or days and sells them piecemeal. The token must be able to embed in different environments and be used by different services, while the owner must be able to access all these markets solely through this token.

A token must also be renderable and associated with the actions it can perform in the user’s wallet. In the car example, if the registration has expired, the web component at work would paint the token red or display a warning. Actions like ‘List for sharing’ would not be available with an expired registration, and the integrated token interface should clearly communicate that message to the user. Tokens must be rendered differently according to what happens to them in the user’s wallet. Tokenization requires wallets to correctly react to a large variety of token events.

• Flexibility. It must allow new protocols to be developed on tokens. A token should never have a finished state. There should always be options to attach new protocols to it. In the case of property, for example, collateralization might be something wishful to add later, as well as identity information or the ability to transfer the token through plasma state channels. This has to reflect in the user interface, and thus, there must be a way to deploy trusted code to the user agent’s wallet or preferred DApp.

• Trust. A token must carry trust relationships and business contexts to third parties. In the car example, an insurance token could provide roadside assistance through NRMA. Through the token, the driver might then be able to access this service of his insurance provider and immediately be identified as qualified for help. Therefore, the token must carry trust relationships, which shouldn’t depend upon the availability of a certain service, but be passed directly by the token. The token must carry business contexts as well as trust relationships, while being highly available, private, and integrated.

• Availability: NRMA is online 24/7 but Qantas Insurance can suspend their services on public holidays or at night. 
• Privacy: NRMA can learn a user’s GPS location, but Qantas Insurance isn’t legally allowed to learn it. 
• Integration: Most NRMA customers are not obtained through Qantas Insurance, so it would be an additional system to integrate and an extra security concern for NRMA to integrate to Qantas Insurance’s web service. 

Of the three features, availability might be the most visible. Just imagine how angry a customer will be, having his car breaking down in the middle of the barren Australian outback, only to learn that roadside assistance can’t be authorized because the insurer’s web service is upgrading ‘for a better user experience’.

ABR: What would you say are the underlying issues of current token business models?

VZ: Early public blockchain projects attempted to implement both token logic and business processes into smart contracts. In an online retail project, for instance, such a smart contract would not only process an order but also manage inventory. The token transaction logic (e.g. under what conditions the transaction is valid) is tied with business processes (e.g. checking inventory). This method is, naturally, inherited from the way people build websites.

This would be akin to an IKEA manager deciding to format the furniture sales contract to include information like which aisle a customer should go to fetch the furniture package. This wouldn’t work in real life because the contract would have to be modified too many times to reflect IKEA warehouse management — which aisle has the product has no impact on the validity of the trade.

We argue that this method is not suitable for creating a frictionless market and integrating the web. Fulfilling these challenges with the conventional token model is difficult, often nearly impossible. It adds complexity and causes issues of scalability, interoperability, and security:

• Richness. In the world of Ethereum — the de facto standard for tokens — token richness is usually created with DApps. The business logic of a token — all kinds of applications — are coded into a smart contract, and centralized websites enable users to access the contract. Suppose you have an ERC721 crypto kitty token. To use it, you must access the CryptoKitties website.

This method requires the designers to fetch all possible business scenarios before creating a smart contract. As the future is rarely predictable, this method is problematic. It also makes it hard to develop a business model by trial and error. At the same time, it adds a lot of complexity to the code, which often leads to security issues. After the DAO was hacked, the Ethereum community restricted itself to implementing relatively limited behavior patterns in smart contracts.

The result is that developers need to restrict the scope of token richness to prevent security problems.

• Embeddedness. Ethereum tokens have a very limited way of interacting with other systems like wallets or DApps. If the logic of the interaction is part of the smart contract, we have the aforementioned problems and must deal with the fact that you can hardly represent all system languages in one contract. It is impossible to do this without the help of external frameworks.

Currently, this is mostly solved by hosted DApps on websites, which structure the interaction between users and smart contracts. Such DApps have made it possible for users to access relatively advanced smart contracts like CryptoKitties and other token-based games. However, this reintroduces the centralization problems that blockchain was made to solve.

A similar problem lies in the integration of a wallet. Events in the token history must trigger actions in the user interface. It is hard to do this when the smart contract doesn’t define the behavior of all those systems in a way that wallets understand. It’s also hard to do so when a contract is upgraded. The usual solution is, again, to use a hosted DApp instead of a wallet under the user’s control.

• Flexibility. The inflexibility and immutability of smart contract tokens make it hard to develop new protocols for them, especially when those protocols are not known when the contract is written. You will also need your smart contract to interact with other smart contracts in a way you can’t predict when designing it.

This could end with a token locked into one certain protocol. It could also lead to trusted third parties migrating to other protocols or interacting with other smart contracts or tokens.

On Ethereum, there are methods to upgrade a smart contract. They usually add a lot of complexity to the original smart contract and introduce another smart contract that performs the upgrade onchain. This approach increases the complexity of the smart contract system, which causes security issues. An example is the multi-sig contract of Parity, one of the most advanced implementations of Ethereum. Even their developers failed to make the contract secure, resulting in one of the largest losses in the history of Ethereum.

• Trust. To be used in a wide scope of business activities, tokens must carry trust relationships. With the legacy token model, this casts two problems. First, you will have to input private data on a blockchain, which has several risks even when encrypted. Second, you need to carry the relationship over a hosted DApp, which means you are dependent on a website being online. If one part of a chain of trust relationships is offline, your token will not work.

In summary: Tokens on Ethereum suffer from having their entire functionality derived from a smart contract. This introduces inflexibility, complexity, security and privacy issues and a lack of interoperability. Relying on the legacy model drastically increases the resources to launch a new token, while making it hard to adjust the business logic to the real economy. Another major issue is that it is close to impossible to reflect the full functionality of a token in a wallet, especially when token events must create wallet events, or you have to deal with intertwined smart contract events. These problems result in businesses striving to integrate markets by using tokens, but spending all their resources on developing smart contracts.

Most of these shortcomings have one common denominator: there is a missing link between the smart contract and the user. This limits the functionality of the smart contracts and has led to centralized hosted DApps filling in the gap.

ABR: What do you identify as the problems of hosted DApps? How does Tokenscript to address these problems?

VZ: If you use advanced smart contracts today, you usually access them through a website or a hosted DApp. For example, smart contracts like CryptoKitties or the 0x exchange protocol don’t need a trusted third party to serve its functionality — in theory. In practice, Ethereum wallets fail to represent the logic and action options of these smart contracts in a user-friendly way. The result is that much of the advantages which blockchain enables are lost.

Hosted DApps have several shortcomings. They introduce a trusted third party. The website owner can render and manipulate data and block users from accessing the DApp. The user also has to rely on the third-party website to stay available and updated, to not leak private data, and to not be hacked. The back-end of the DApps is decentralized and trustless, but the frontend is as centralized and trusted as traditional websites.

Even more problematic: You can’t integrate the web via tokens instead of accounts or websites when you rely on hosted DApps. When you need to use the advanced business logic of smart contracts, such as passing your car token to the roadside assistance service, which uses it to check your insurance policy, you must use DApps as well as the road service and the insurance company. This is the exact same model as the current web: the information might be attached to the token, but the way information is passed still relies on centralized websites.

This is why we have introduced an alternative approach to handle the way users interact with smart contracts and tokens.

TokenScript as a Solution

We propose TokenScript as a solution to overcome the shortcomings of the legacy token model.

TokenScript is a program interface for tokenization. It is an XML dialect, which describes the functions of the token and the method of interacting and rendering it on the user interface. It serves two purposes: 1) it helps the user to access the token’s full functionality, and 2) it allows the creation of more advanced and complex user-token interactions.

The XML dialect can be easily read by any device and software without the need to pull it into the core of the wallet structuring the interaction with the blockchain. It’s also possible to use TokenScript to execute token actions on another protocol, without the need to migrate the token smart contract.

Basically, TokenScript puts a lot of information offchain, while the core of the token design remains onchain. As TokenScript (and every update) is signed by the token issuer, it is as verifiable as the smart contract itself, while being a set of shared data between the token issuer and its users. In the current blockchain lexicon, it could be described as a Layer 2 technology for interactions with the token.

Think of a computer program for your music files — like the token on a blockchain, the music files remain the same, but the software for playing them can change. It can be automatically updated to eliminate a bug, or it can change to allow new features, like recording, cutting, fine-tuning equalization, or putting it in a library of your favorite songs. TokenScript is the hinge that connects software to the token and makes sure that the interaction of both is not arbitrary, but structured by the issuer of the token.

ABR: Can you tell us about the FIFA World Cup Blockchain Tickets Experiment? What was the main takeaway from that project?

VZ: The experiment was carried out between AlphaWallet and FIFA officials. In June 2018, we set out to solve some of the biggest problems plaguing the ticketing industry, namely fraud and lack of regulation in the secondary market. We partnered with Shankai Sports (an exclusive agent for FIFA in the Great China region) to issue FIFA WC tickets using our non-fungible standard ERC875 and TokenScript. A total of 28 customers, who had never touched cryptocurrencies before, used our tokens to enter the game. Along the way, we implemented an atomic swap system to allow our ticket holders to safely sell and transfer their tickets to others. We also considered implementing KYC (Know-Your-Customer) via cryptographic identity protocols to improve event safety. This solves ticketing fraud and uses smart contracts to regulate the secondary market.  

Takeaway: 

1. It works. With blockchain smart contracts and TokenScript, we can tokenize rights to create a frictionless market and integrate the web.
2. It doesn’t work to connect with ‘real-world’ business. It requires a stable currency on the blockchain.

Follow Asia Blockchain Review on:

• Telegram: https://t.me/asiablockchainreview
• Facebook: https://www.facebook.com/pg/asiablockchainreview
• Twitter: https://twitter.com/abr_blockchain
• LinkedIn: https://www.linkedin.com/company/asia-blockchain-review/
• Website: https://www.asiablockchainreview.com/
• Email: [email protected]
• Youtube: https://www.youtube.com/channel/UCMQ5CVu0c9-pMlwB8LUvkiA