UDAP Architecture Highlights and Implementation Notes I
Written by Bing Ran
UDAP is an abstraction of blockchain technologies that provides Asset Oriented Programming model for third-party applications. It’s a middleware between applications and blockchains that hides the complexity of blockchain programming and provides a unified suite of coarse-grained asset management API with scalability, confidentiality and finality.
This document contains the updated architecture and some implementation details during the last few months of development. While the white-paper on the GitHub contains quite a few important topics and designs that still applies to the current state of UDAP development, there have been some significant changes and development in some of the most critical areas for UDAP to be successfully adapted en mass by projects that aspire to take advantage of blockchain technologies such as Ethereum and other highly visible public chains.
The following areas are the main topics that this note is trying to cover:
● Scalability
● Privacy
● Massive content distribution with copy right protection
● API
● The Universal Asset Wallet
● A showcase mobile application
● A vision of a blockchain where non-fungible asset are natively supported in the protocol level.
As it has happened, some of the initial design in the white paper reflects our wishful thinking, which has turned out to be impractical for the immediate release of UDAP. We are going to update the white paper to make it synchronous to the technical decisions and thoughts in UDAP lab.
There are a few areas where we have taken a different approach in implementing from what being specified in the white paper:
1. We now position UDAP as a pure middleware between applications and public chains. We are NOT going to build and run a public chain, as hinted in the white paper. Instead we’re going to run UDAP on top of the most popular public chains, such as Ethereum and Cosmos. For each of the public chains we will build adapters so that the same set of API can be used to the different root chain, unchanged.
2. We mentioned in the white paper that we would use Cosmos as the first public chain to support. Due to the delayed schedule of Cosmos releases and the initial experience with it, we have moved back to supporting Ethereum as the public chain of choice for the first milestone release of UDAP.
3. We have started implementing a State Channel service in the UDAP layer to support the core features of UDAP: to support tokenizing everything (that is not fungible) and the trading of them, even in the case of . We believe a properly implemented state channel service would help us to deliver a reasonably scalable low-cost framework with decent privacy and finality support. The state channel support we are building is not a general state channel framework that supports arbitrary off-chain performance of smart contracts. It is intended to support the generalized asset-backed token transfers and exchanges. The state channel service in UDAP will allow applications developers to securely scale up token applications without writing any smart contracts that function as the adjudicators in state enforcement, because most common trading patterns will have been built in UDAP as smart contract-based transaction adjudicators.
Asset Oriented Programming
We propose a programming paradigm under the name of Asset Oriented Programming, or AOP, but not to be confused with Aspect Oriented Programming (we may call it something else to avoid the naming clash).
The central idea of AOP in UDAP has a few aspects (pun not intended):
1. We require the applications to identify the assets that the application is managing before throwing something “on the chain”. In fact most of the applications essentially deal with some classes of assets, be it concert tickets, customers, business accounts, hotel rooms, songs, art works, collectibles, healthcare records, academic achievements, etc. Each of the above sampled objects or information has a fundamental attribute: the ownership. A piece of asset must be owned by someone or even something. The entire set of business logic are usually built to manager the life-cycle of these assets. When applications are viewed and architected that way, they lend themselves very well to the UDAP pogromming model.
2. The token service of UDAP and the Universal Asset Wallet from UDAP is analogous to email client, which receives messages from different sources. The difference is that this mail client is blockchain based and messages are actually crypto-tokens. Tokens as received by the wallet can be transferred to another account, if it’s transferrable like a concert ticket. Otherwise the token can only be owned by the recipient as instrumented by the token issuer. Personal identification tokens fall into this category.
3. We endorse a programming model whereby business logic is encoded in the traditional way rather than in smart contracts. Blockchains are used as the repository of the domain specific asset tokens rather than as computing platform. UDAP provides some “stock” smart contracts that enforce some common business transaction patterns. Applications use these contracts by explicitly referencing the contracts’ well-known names, either when declaring business rules or generating blockchain enforceable receipts. This would pose some limitations as what kind of business applications to support by UDAP, but when the applications falls into the asset oriented model, they would find that working with UDAP and underlying blockchains are quite a smooth sail.
4. As such, the border between centralized and decentralized applications are blurred. In most business cases wherein retaining the operating ownership is still desirable, a hybrid model is probably the most logical architecture. On the root level like Ethereum, the construct should be as decentralized as possible for the best security and censorship resistance in both first party and third party. On higher levels, however, the developers can leverage their existing invest in infrastructure and skills to quickly come up with solutions.
Instead of elaborating the UDAP architecture in an abstract fashion, we are building a fairly sophisticated asset trading platform on UDAP to help stabilize the API.
To be continued.
Learn more details, to join UDAP with:
For more information please contact — jhe@udap.io
