Programmable Smart Assets: Real World Assets (RWA) Digitized Future

Expanding RWA Beyond Fintech to Every Physical and Digital product, certificate, etc.

By: David Beberman and Michael Holdmann

Rethinking The Blockchain Account Concept

Bitcoin introduced the decentralized, consensus-based ledger concept, and how to use it to represent a cryptocurrency. Bitcoin used a simple scripting language to enable the management of the ledger concept, enabling the exchange of cryptocurrency between entries on the ledger (i.e. accounts).

Ethereum added to the decentralized, consensus-based ledger concept, by generalizing the simple scripting language to a Turing complete language, while using the concept of “gas” to solve the non- termination problem inherent in Turing complete languages.

I think everyone would agree that these two concepts have had an amazing impact worldwide. But as great as these concepts are, possibly a watershed moment in history, we think there is yet another evolutionary stage in blockchain technology which will further increase its adoption.

To explain our new technology concept, lets start with a simplifying, somewhat inexact, analogy between blockchain technology and a more well understood technology, spreadsheets (e.g. MS Excel, Google Sheets).

Spreadsheet analogy

If we view Bitcoin as a single (virtual) spreadsheet, we can consider each account as a row in the spreadsheet. Transfers of bitcoin between accounts are transfers between the rows. The pay-to-script hash (“P2SH”), can be thought of having a script associated with an individual cell on a row of an individual account. Since this is a virtual spreadsheet, one useful feature is that the number of rows is essentially infinite. This means that users can create as many accounts as they would like, which conceptually are as many rows as they would like in the virtual spreadsheet. I would note that other than the P2SH, which is associated with an individual transfer of bitcoin, the concept of an account storing state is not part of Bitcoin.

Ethereum introduced the concept of the smart contract. If Bitcoin is a single virtual spreadsheet, we can consider the Ethereum smart contract as introducing multiple virtual spreadsheets. Each smart contract is its own virtual spreadsheet. A token smart contract (i.e. ERC 20), has an array that contains accounts and the amount of token that each account owns. Thus, each token smart contract can be thought of as having a row for each account and an associated count of tokens. Since a token smart contract is represented by an individual account on the blockchain, and again, accounts are essentially unlimited, there can be an unlimited number of individual smart contracts accounts, representing unique types of tokens, on an Ethereum blockchain. It should be understood that each smart contract is essentially stand-alone, isolated. That is, although one smart contract may call another smart contract explicitly, in particular as a library call, there is no generalized means of sharing code. To create a new token or other data representation on Ethereum, a new smart contract must be registered.

In summary. from an account viewpoint, Bitcoin introduced the account as an entry on a single global virtual spreadsheet. Ethereum introduced the smart contract account, which enables multiple virtual spreadsheets, while regular accounts continue to be more like Bitcoin accounts.

What if we revisited the concept of account and made all accounts smart?

In Ethereum, a smart contract has state data associated with it. What if every account has state associated with it?

What if an account could create and contain arbitrary objects in its state?

What if, using an object-oriented paradigm, the code for such objects came from classes, and those classes were registered once on the blockchain and reused by accounts?

What if the object-oriented concept of inheritance was supported such that objects were instances of classes, which in turn could inherit most of their code from ancestor classes.

Ramifications

What are the ramifications of accounts owning objects instead of just a count of native token?

What are the ramifications of creating (instantiating) new objects without needing to register new code?

What are the ramifications of new classes once registered on the blockchain becoming an immediately useable, essentially integral part of the blockchain for all users?

To consider these, we need to propose new ways we would like to use a blockchain:

As a user of a blockchain, I would like to be able to create new assets in my account on the blockchain and be able to sell them. Similarly, I would like to be able to buy other assets and resell them. I would like to be able to do such transactions both on marketplaces and exchanges as well as person-to-person (i.e. wallet-to-wallet).

Since I can’t know in advance the type of asset I might buy or sell, I want all assets to have some commonality between them but support unique features for each type of asset. I want my account to support all assets, regardless of type, and I want my wallet to be able to support all assets, regardless of type. As a user and asset owner I don’t want to know about or touch and software code. I do want assurances that the code that manages my assets is valid, but I no more want to look or touch that code than I do the code that runs my cellphone or laptop. As it turns out, in computer science we solved this problem with the object-oriented concept and class inheritance.

If accounts can have arbitrary asset objects associated with them, and the objects are instances of classes that contain the code to manage the assets, then we can deliver to the user these capabilities. This is a direct result of the ramifications of accounts owning objects, objects as instances of classes, and classes as the main concept for code on the blockchain.

The SagaChain Account Model

The SagaChain Account Model generalizes the account concept first introduced in Bitcoin and extended to include Smart Contract Accounts with Ethereum to all account entries including state data, not just smart contracts. On the SagaChain, every account entry now includes a state hash instead of just the smart contract accounts. In essence this makes every account “smart”. Each account can now include objects that can represent assets.

Further, through object-oriented inheritance all asset objects can inherit common behavior from a parent class, (e.g. Class Asset). Complex relationships can be easily represented by the state information of each object instance which is captured in the state information of each account. Since accounts are essentially unlimited, there can be an unlimited number of accounts contains both object instances and code for inheritable classes stored on the blockchain.

Returning to my desire as a user to never need to touch or know explicitly about code, through the magic of inheritance, I can simply create new asset objects of a known type (i.e. class) by sending transactions to an account I own, referencing the type of the object I want created. Further, I can buy and sell such asset objects, by sending transactions referencing these objects. I don’t need to know about Bitcoin’s Forth scripting language, or Ethereum’s Solidity smart contract language as a user.

The PraSaga SagaChain creates this new approach to blockchains, tokens and assets ownership through the introduction of the following complimentary technologies:

1. The SagaChain Systemic Extensible Blockchain Object Model (SagaOS)
2. The Extensible Smart Object Asset (“SagaSA”) Classes
3. The SagaChain Scalable Sharding Algorithm(SagaScale) and Hybrid Consensus Protocol

To learn more about PraSaga’s patented technology contact us through our website at prasaga.com

Objects, Classes and Transfer Flows

Transaction Flow: Explicit Seller and Buyer

1. Creator Account creates an asset object. This asset object may refer to a virtual or physical asset
2. Asset Seller Account creates a quote object with the Buyer Account’s address. (Buyer is provided the quote object reference externally)
3. Asset Buyer Account creates a purchase order object with quote object reference. (Seller is provide the PO object reference externally)
4. Asset Seller Account accepts the PO by passing the PO to the Qoubojteect
   1. The Quote object sends the PO object the asset reference
   2. and receives a message with the SagaCoin amount from the PO. object.
5. The Quote object increments the account SagaCoin, and deletes itself.
6. The PO object stores the asset object reference and deletes itself.

Transaction Security Via Signatures

1. All accounts contain an incrementing nonce value
2. All transactions on an account use the incrementing nonce value
3. All transactions are hashed and signed using the account private key
4. A random nonce can be added to each transaction additionally to further protect the private key signature
5. Result: all asset transfer transactions verify accounts involved using signatures.

Smart Asset Objects & Fractionalization

Tiered Asset Fractionalization

1. A fractionalization object contains a reference to an asset. The asset may be owned by the account that contains the fractionalization object, or it may reference to another account.
2. The fractionalization object contains a count of the total fractions created, and a count of the remaining fractions that have not been sold to other accounts.
3. An account that contains a fractional object reference instance has a reference to the fractionalization object. The fractional object reference instance may have a count of one or more fractions.

Multi-Tiered Fractionalization

1. Any account containing an asset object reference may use the asset object reference as the asset for a fractionalization object, and thus create the opportunity to sell fractions of the asset object.
2. Any account containing a fractional object reference may use the fractional object reference as the asset for a new fractionalization object, and thus create the opportunity for a nested series of fractions of fractions of asset objects.
3. There is no logical limit to such fractioning, however we may impose some arbitrary limit in case of computational resource exhaustion (say 256 levels, or something similar)

Fractional Class Structure

1. Class Fractionalization Asset
2. Members
3. Contains a reference to an asset object or a reference to a fractional asset
4. Total count of fractions (i.e. shares)
5. Current count of remaining unreferenced shares (i.e. unsold shares)
6. Must be great than or equal to zero
7. Methods
8. Decrement unreferenced shares
9. Increment unreferenced shares
10. Class Fractional Asset
11. Members
12. Reference to a fractionalization asset object
13. Total count of fractions (i.e. shares)
14. Must be less than or equal to total count of fractions in fractionalization asset object

Fractionalized Asset Groupings

1. A grouping fractionalization asset object may contain multiple asset object references.
2. Each grouping fractionalization asset object contains a total count of fractions (i.e. shares), and current available shares. This is identical to a non-grouping fractionalization asset object.
3. A grouping fractionalization asset object contain both asset object references and fractional asset object references. Thus complex asset ownership relationships may be created.

Grouping Fractional Class Structure

1. Class Group Fractionalization Asset
   1. Members
   1. List of Asset Object References and Fractional Asset Object. References
   2. Total count of fractions
   3. Current count of remaining unreferenced shares (i.e. unsold shares)
   1. Must be great than or equal to zero
2. Methods
   1. Decrement unreferenced shares
   2. Increment unreferenced shares

Fractionalized Cashflows

Cashflow Pull Model

1. Cashflow starts with a distribution of SagaCoin to an asset object
   1.1 This SagaCoin is only extractable via an asset object reference or a fractionalization asset object reference
2. A cashflow distribution occurs when an Asset Fraction Reference Orebqjueectsts its distribution
   2.1. It sends a cashflow distribution request message to the Asset Fractionalization Reference Object
   2.2. The Asset Fractionalization Reference Object queries the asset object via its asset object reference for any new distributions
   2.3. It then distributes the fraction due to the Asset Fraction Reference Object
3. Nested cashflows occur naturally when an Asset Fractionalization Asset Reference Object refers to a Asset Fraction Reference Object, which in turn references another Asset Fractionalization Asset Reference Object
4. Each cashflow distribution to an asset is a distinct separate entity
   4.1. A cashflow distribution request may aggregate the separate cashflows or provide them as unique flows
5. Grouping Asset Fractionalization Objects query all of the contained asset reference objects for all distributions, and the provide the fractional cashflows

Class Multi-Asset & Class Multi-Asset Reference

Class MultiAsset
1. Members
1.1. Type of Asset
1.2. Count of Asset
2. Methods
2.1. Increment Asset Count
2.2. Decrement Asset Count

Class MultiAsset Reference
3. Members
3.1. MultiAsset Object Reference
3.2. Count of Asset
4. Methods
4.1. Increment Asset Count
4.2. Decrement Asset Count

Source Multi-Asset Transfers: Explicit Buyer & Seller

1. Creator Account creates a multi-asset object. This asset object may refer to a virtual or physical asset. A count of the multiple assets is initialized
2. Asset Seller Account creates a quote object with the Buyer Account’s address. The multi-asset object count is decremented, and the quote object reference is incremented by the amount of asset for sale. (Buyer is providedthe quote object reference externally)
3. Asset Buyer Account creates a purchase order object with quote object reference. (Seller is provide the PO object reference externally)
4. Asset Seller Account accepts the PO by passing the PO to the Quote object.
   4.1. The Quote object sends the PO object the multi-asset object reference and count
   4.2. and receives a message with the SagaCoin amount from the PO object.
5. The Quote object increments the account SagaCoin, and deletes itself
6. The PO object stores the asset object reference and count, and deletes itself.

Secondary Multi-Asset Transfers: Explicit Buyer & Seller

1. Asset Seller Account creates a quote object with the Buyer Account’s address. Decrements its multi-asset reference object’s count and incremented quote object reference is incremented by the amount of asset for sale. (Buyer is provided the quote object reference externally)
2. Asset Buyer Account creates a purchase order object with quote object reference. (Seller is provide the PO object reference externally)
3. Asset Seller Account accepts the PO by passing the PO to the Quote object
   3.1. The Quote object sends the PO object the multiasset object reference and count
   3.2. and receives a message with the SagaCoin amount from the PO object.
4. The Quote object increments the account SagaCoin, and deletes itself.
5. The PO object stores the asset object reference and count, and deletes itself.

Secondary Multi-Asset Transfers: Any Buyer

1. Asset Seller Account creates a quote object without referencing the buyer account. Decrements its multiasset reference object’s count and increments quote object reference is incremented by the amount of asset for sale. (Quote object reference is listed by some external means)
2. Asset Buyer Account creates a purchase order object with quote object reference. (Seller is provide the PO object reference externally)
3. Asset Seller Account accepts the PO by passing the PO to the Quote object
   3.1. The acceptance binds the specific buyer to the seller for this Quote/PO exchange.
   3.2. The Quote object sends the PO object the multi-asset object reference and count,
   3.3. and receives a message with the SagaCoin amount from the PO object.
4. The Quote object increments the account SagaCoin, and deletes itself
5. The PO object stores the asset object reference and count, and deletes itself