Written by Bing Ran

UDAP Middleware Layer

The above diagram shows the entire process of asset tokenization, and asset trading, with the help of the Token Service and State Channel Service of UDAP.

Asset Backed Token (ABT) Service

The Asset Backed Token Service takes care of asset meta information storage and asset tokenization. Some of the API functions are:

● createTokenClass: to declare the class of asset, with meta information. In the case of UMedia, the meta information includes required field names, such as the song information, copy limit, the recipients of income and proportions, price, etc.

● tokenize: to tokenize a piece of asset of a token class. In the demo case, this is a specific song, with proper values for the required fields as specified in the token class.

State Channel Service

State Channels are very powerful layer-2 technology that off-load computation from the main blockchain to semi-private computing components, probably not based on blockchain technologies, for better scalability, better privacy, lower cost and immediate finality.

There are a few projects that are building generic state channel solutions., such as Counterfactual, Perun, and Celers. State channels are conceptually simple, but difficult to do in a generic way.

Fortunately UDAP does not need to be a generic state channel framework. UDAP has well defined scope of applications and for those applications a limited number of pre-defined adjudicator contracts are all they need to run state channels. They do NOT need to write smart contracts to use state channels. The state channel service of UDAP are composed of a set of channel maintenance functions + pre-defined adjudicator contracts, as explained in the Smart Contracts session of this document.

The State Channel Service layer supports using state channels in applications. The mains responsibilities of the service are:

● Receipt issuance.

● Receipt custody.

● Contract enforcement.

● Channel updating.

● Double-spent detecting.

● Withdrawal monitoring.

The state channel service of UDAP is optional for applications. They’re there simply for application developers to implement state channels easily, including the evidence generation and rule enforcement. These applications usually managers assets of low value and of high frequency of hand changes, such as songs. These applications do not care too much about immediate on-chain insurance, but they are very sensitive to transaction fees and transaction speed. Other applications that deal with high value objects can take advantage of the state channel technology too for quick finality. All they would probably do additionally is to issue command to update the state in the root chain more often to make sure the state recorded on the root chain are the latest state of their assets.

Receipts, de defined here, are state certificates signed by the counter-parties. They are usually composed of the following properties:

● Business contract type identifier, as predefined in UDAP as smart contracts.

● Unique transaction ID

● Nonce.

● Transaction details.

● The final state after the transaction.

UDAP receipts would make perfect fault proofs in case one party is trying to abuse the application system.

The Workflow of the UMedia App

With all the concepts explained, let’s go through the typical use case in the UMedia to find out how a full featured application can be built on top UDAP and indirectly on Ethereum.

1. The application UMedia and all of its customers would form a hub-and-spoke of state channels. The channels between the application and the customers are formed when the customer sign on to the application. Any deposit from the customer will go to the customer’s account on the root Ethereum chain. The customer can choose to put whatever amount of fund to the state channel between the customer and the UMedia app. A dynamically synthesized smart contract of AppCustomers will enforce the state of the customer channels.

2. As shown in the diagram, a song owner named Star first needs to register the song with the UMedia application, which actually calls into UDAP to register the asset on chain. Step 1 and 4 do that part of work. Star might set the total number of copies available for sale, the price of each copy, and declare how to split the sales income of the song among the contributors. Please note that what being put on sale is not the ownership of the song. Rather it’s the license of experiencing is for sale.

3. Once the song is registered in the market, fans can find them in the UMedia app. A fan named Alice would like to buy a copy of the song. Assuming she has deposited enough money in her account with the application, she sends a purchase order (PO) to Star, via the application. The PO is declared as an OfBuying type of transaction, with a time lock so that Alice can claim back the fund she has committed in the transaction if the seller does not fulfill the order timely. The transaction is counterfactually executed locally on her device. The application passes the message over to Star. During the process, the application also sends a request to the UDAP State Channel Service for a properly formed receipts be drawn and signed by UMedia. The receipt goes back to Alice. The step 7–10 covers the above processes.

4. Once Star receives the PO, he would check the availability of the song copy and commit the copy back to the order in exchange for the fund. A proper receipt is created for him to attest the order fulfillment. The same receipt is also copied to Alice to show that she owns the copy of the song. Once Star has received the fund, the fund will be split among song contributors accordingly. Step 11–15 cover the above the processes.

5. The UMedia app has decided to entrust UDAP State Channel Service with the duty of transaction auditing. The UDAP State Channel Service will actively monitor if Star would try to generate music copies of the same serial number, or the serial number is bigger than the maximal allowed copies on the market. The UDAP State Channel Service would go the root chain to enforce the contract if it finds any violation. The adjudicator contract on the root chain would simply refund the buyer and slash Star by a previously agreed amount, 10x of the retail price of a copy for example. If the UMedia app decides not to entrust UDAP with the auditing responsibility, Alice would need to find a way provided by the application to find double-spent copies and complain to the application, or even UDAP directly. The dotted lines in the diagram covers these processes.

The User Experience

The UMedia is a standalone mobile applications which apparently is an e-commerce platform. Shoppers buy songs directly from the song writers with fiat money and/or cryptocurrencies, nothing spectacular, except for the buttons that prompt the users to “Announce on the blockchain,” “Check the authenticity of the product” or something like “Report to blockchain”.

Internally there is an Asset Wallet that contains all the assets a user owns, either in the channels with the application or in the public blockchains. The on-chain channel contracts cannot be destroyed even when an application decides to go out of business and shut the door. The asset owned by users will have to withdraw to the root blockchain before an application closes the business. This ensures that what a user has acquired from an App will stay with the user independently of the life cycle of the application.

There is quite of bit design that goes the extra mile to make the UMedia unique. Blockchain has boasted about its ability to remove the middlemen. But middlemen are actually a positive thing for information propagation in many situations. In fact there has been a whole movement of social marketing wherein every individual plays the double role of consumer and middleman. People have design many ways to track the information flow that helps business deals. Blockchain and tokenization of everything would make the tracking much easier. Since each unit of product is uniquely identified by a crypto-token, which usually has clear ownership, the product information can be easily tracked by following the tokens, assuming the owners have decided not to conceal the ownerships of songs from friends circle or even general public. In an open community where people openly share their song purchases and opinions, it’s very easy to see how people are influenced by each other to make buy decisions. The influencers are rewarded in real time in the deals they have participated explicitly or implicitly.

Some other interesting features that uniquely enabled by token ownerships are:

● One can loan a song to other people. When a song copy is on loan, only the one who currently in possession of the copy can play the music. The lending relationship runs on a smart contract, counterfactually of course, which can even be configured to charge fees to the borrower, and/or return the copy after some time has elapsed.

● One can list some song copy for sell in his playlist. Effectively the public playlists of individuals become the catalog for others to browse and buy from.

● Every time a song is transferred from one owner to another, all the digital signatures associated with each period of ownership will be transferred along as well. This would be especially useful to trace the origins of valuable items such as paintings and other collectibles.

Secure Distribution of Content

It’s by incident that we need something more than just blockchain in the showcase application. One of the features of the music market is that the buys of music really owns a copy of the music in her own “wallet” — all the media content including the music file, the lyrics text, the story behind the songs are all pushed to the buyer so she can enjoy the media entirely off-line. This is in contrast with the streaming model whereby buys are granted the permissions to listening to online music in streaming mode. The end users do not actually own the material.

It’s our belief that blockchain technologies enables a new model of DRM, while the old watermark based DRM has largely failed. In the blockchain based DRM, there is no central company that controls the content ownerships. The ubiquitous nature of the public ledger allows much more flexibility and interoperable with other applications.

To protect the content delivered to buyers wallet, each distribution should be custom made to the receiver so that only the authorized receiver can open the delivery. Obviously it’s not practical for the musicians to burn custom copies of their work for customers, particularly if the musicians are hugely popular.

Proxy Re-encryption (PRE) technology is employed to do the work instead. The goal of proxy re-encryption is to securely enable the re-encryption of ciphertexts from one secret key to another, without relying on trusted parties. Specially purposed nodes (proxies) are employed to re-encrypt the media content according the public keys of the receivers, during which process the plain text is not revealed to the proxies, thus the content is properly protected.

We are currently explore the work from NuCypher to build a secure content distribution mechanism in the UMedia app.

The basic scheme is described in the following diagram:

In practice, the scheme is slightly more sophisticated in that an ephemeral key is used in the middle for better performance, like what is described in the Nucypher white paper.