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?
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:
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.
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:
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.
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.
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.
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.
Follow Asia Blockchain Review on:
We provide information about Asia Blockchain Review latest activities as well as global blockchain news and research. Subscribe to our Newsletter now or Contact us