UDAP Architecture Highlights and Implementation Notes II
Written by Bing Ran
UDAP State Channels
First of all, UDAP applications (or almost any traditional applications for that matter) can be viewed as N state channels in a hub-and-spoke topology, as shown below, where N is the number of users:
The app itself has formed a state channel for each of the users. The state of each of the channels is made of what is usually called the “account information” or “account balance,” such as the balance of her deposit, the items (tokens) that she owns. The state of the whole application is the sum of all the state channels.
Virtual channels, shown as the orange lines in the above diagram, are formed when the users start conducting transactions with each other, facilitated by the application. These virtual channels are closed when transactions are settled, at which point the state in the virtual channels are withdrawn to the persistent channels between the users and the application.
The UDAP State Channel Service is an abstraction of smart contracts that are state repositories for each of the user state channels and adjudicators of standard UDAP asset transactions. Although we may consider supporting app defined transaction types for app defined assets, we initially support the so-called “standard” UDAP transactions, such as Buy, Pledge, Lend, Swap and Split. What we are offering to the applications is transparent state channel support without requiring the developers to write smart contract adjudicators for UDAP supported asset types, which can cover a majority application scenarios.
An interaction between Applications and UDAP: The UMedia Application with UDAP
The UDAP development team is working on a full-featured mobile application that takes full advantages of the UDAP API. The application is a marketplace for musicians to sell songs to their fans directly. The idea is that we use the full-featured mobile application as the harness to test the completeness of the UDAP services.
The name of the application is UMedia (Creator sometimes internally), which is a marketplace for content creators, musicians particularly, to sell content, usually in limited quantities, directly to fans. The scarcity of the content is guaranteed by blockchain technology. Since the supply of the content is hard capped to limited copies, there is a second-hand market where each of the copies can be resold to other fans at the price agreed between the buyer and seller in private.
Smart Contracts
Near the bottom is the root blockchain, which is Ethereum in this case.
The UMedia Fidelity Bond contract, the UMedia Asset Types, UMedia User Channels and {Song} Contract contracts are synthesized based on respective UDAP defined templates when the application is registered with UDAP, or when a new asset class is declared, or when a new user is added to the app, or when a new song is released, as shown below:
Some of the smart contracts are UDAP pre-defined smart contracts, such as those to define the basic contractual relationships of most business transactions:
● Buy: A to buy an asset token from B for some amount of cryptocurrencies, valid till some point in the future.
● Lend: A to lend a token to B till some time point in the future, possibly charging a time-based fee.
● Pledge: A to pledge a token for some credit in exchange.
● Transfer: A to transfer a token to B, in exchange of nothing.
● Swap: A and B would like to an atomic swap of the token.
There are also smart contracts that capture common patterns in token generations, such as the “LimitedTokenFactory” as shown in the diagram. The Factory pattern is a basic pattern as described in the [Design Patterns](https://en.wikipedia.org/wiki/Design_Patterns_(book)). It describes how some quantities of objects are to be generated from a single source in a controlled manner. It’s relevant to the demo application because the tokens representing song copies or album copies must be created according to the publicly declared hard caps, which ensures the scarcity of the assets. The factory can be configured to generate several instances of the token class (song meta information), or exactly one copy, in which case the token is a Singleton. For example, songs are usually sold in multiple copies while an original painting has exactly one copy and must be sold as such. If the content owner somehow manages to sell more than she should have, it would violate the contract she has made to the fans. The “double-spending” act can be detected by the consumers or by designated agents in the community and should be challenged to the contract. The contract would then refund the consumer and likely slash the cheating content owner.
The MoneySplitter contract is another one pref-defined by UDAP. It’s a very simple contract that will take some amount of cryptocurrency and split it according to a configured set of recipients in pre-configured proportions. A simple case in the demo app is how the income from song sales is split to multiple content contributors, such as the music writer, the lyric author, the singer and all the instrument players.
To be continued.
Learn more details, to join UDAP with:
For more information please contact — jhe@udap.io
