Anatomy of Asset and Value Transfers with the SagaOS Account Model and Extensible Smart Object Assets on SagaChain

by David Beberman, CTO Prasaga Foundation

• What if there is a better, more intuitive, more scalable way to manage assets on the blockchain?

Overview

The following describes at a conceptual level a simple model for the transfer of assets and value between two accounts on the SagaChain. This makes use of SagaOS’s an Extensible Blockchain Object Model unique flexibility for representing objects directly in user accounts. The descriptions given are deliberately simplified to highlight main features. This paper follows from the “Rethinking Sharding and Smart Contracts For Maximizing Blockchain Throughput”[1] and “Extensible Smart Object Assets, Smart Object Asset Ownership and Fractional Smart Object Asset Ownership With the SagaChain Extensible Blockchain Object Model” (SagaOS) [2] papers. We start off with some definitions, present simplified transfer transaction flows, and conclude with further comments.

Object Reference Definition

All accounts on the SagaChain consist of object instances. Each object is identified by an object reference. An object reference consists of the account address and the object index within the account. Object references are defined as the following:

· System global wellknown

· Account wellknown

· Account local

A system global wellknown object reference is to a unique object that is always available on the blockchain. Any object may send a message to a global wellknown object.

An account wellknown object reference is to an object that every account contains an instance of. As will be described below, every account contains a root object, and a SagaCoin balance object.

An account local object reference is to an object that is dynamically created by an account and is specific to a particular account’s state. For example, an account may contain multiple asset reference objects.

As stated, an object reference consists of two parts:

Account Address : Object Index

Where the account address is the account ledger entry address. If the account address is blank, then all messages referenced by the object index are defined to be to an object that is within the current account.

Object Accessibility

Object accessibility has the following possible scopes:

· Global accessibility: anyone can send a message to the object

· Local accessibility: only the account containing the object may send a message to the object

· Account friends: only accounts that have been authorized by the account containing the object may send a message to an object within that account.

Simple Account Object Structure

A basic logical account structure consists of a wellknown root object, which contains by reference a SagaCoin balance object and a list of asset reference objects owned by the account.

Account Root Object

Every account has a wellknown root object which receives transactions that are sent to an account when not explicitly referencing an object within the account. That is, the object reference is the following:

Account Address : <blank>

Equivalently a transaction sent to an object reference as the following:

Account Address : <wellknown root object index>

Also references the root object in the account.

SagaCoin Balance Object

The SagaCoin balance object maintains the balance of token owned by the account. All additions and subtractions of SagaCoin balance are accomplished through messages to this object. A SagaCoin Balance object shall reject a subtraction that would result in a negative balance.

Asset Reference Object

The asset reference objects define the ownership of assets for the account. An account may have an unlimited number of asset reference objects. The reference field values contained within these objects are transferred between accounts for asset ownership transfer transactions.

Simple Purchase Model

The simple purchase model enables the direct sale of an asset from one person or entity to another. As an example, this can be thought of as a private sale. There two transaction flows to accomplish such an exchange between accounts. The transactions are initiated by the buyer or the seller. The transaction flows are as follows:

A seller initiated transaction:

· The seller creates an offer-to-sell object with the following parameters:

o An asset reference object that the seller owns. The object is removed from the asset list and inserted in the containment tree of the offer-to-sell object.

o An amount to pay for the asset in SagaCoin

o The address of the buying account

· The seller gives the buyer, the reference to the offer-to-sell object

· The buyer creates an offer-to-buy object with the following parameters:

o The offer-to-sell object reference

o The amount of SagaCoin

o The offer-to-buy object sends a message to the offer-to-sell object with its self object reference

§ The offer-to-sell object verifies the amount of SagaCoin in the offer-to-buy object

o The offer-to-buy object creation finishes successfully returning its object reference to the buyer

· The seller sends a message to the offer-to-sell object, accepting the offer-to-buy:

o The offer-to-sell object sends the asset object reference value to the offer-to-buy object.

o The offer-to-sell object increments the seller’s SagaCoin balance retrieved from the offer-to-buy’s SagaCoin.

o The offer-to-sell object sends a delete message to the offer-to-buy.

o The offer-to-sell deletes itself

Notes:

This transaction flow is written as a 3-way protocol. The seller explicitly accepts the buyer’s offer. It is also possible to have an automatic offer acceptance. In that use case, the offer-to-sell object would perform the last transaction directly on receipt of the offer-to-buy message. It is then a 2-way transaction and the object-to-buy object is deleted immediately, returning a null object reference on its creation transaction.

Alternatively, there may be multiple additional related transactions before the seller accepts the offer-to-buy and completes the asset transfer.

A buyer initiated transaction:

· The buyer creates an offer-to-buy object with the following parameters:

o The address of the seller account

o The type of the asset to buy

§ Asset specific parameters

o The amount of SagaCoin of the offer

· The buyer gives the seller the offer-to-buy object reference

The seller then creates an offer-to-sell as above, passing it the offer-to-buy object reference, and performs the offer acceptance transfer.

Simple Payment Model

A simple payment model does not include an asset transfer. It consists solely of a SagaCoin balance transfer between accounts. The transaction flow is from the sender to the receiver. The transaction flow is as follows:

· The sender creates a SagaCoin transfer object with the following parameters:

o The amount of SagaCoin

o The address of the destination account

· The SagaCoin transfer object sends a message to the destination account with its self object reference

· The destination account retrieves the SagaCoin and adds it to its SagaCoin balance

· On return the SagaCoin transfer object deletes itself

Notes:

In this example, the SagaCoin transfer object exists only during the transaction as a temporary object. It is not added to the state of the sending account.

Further Comments

In the above examples we used the generic terms “offer-to-sell” and “offer-to-buy” as the names of the objects involved. Depending on the types of asset and value transfers, the offer-to-sell can be thought of as an analogous to a price quote, and the offer-to-buy as a purchase order.

It should be understood that the above are intentionally simplistic examples. The flexibility of the SagaOS enables near infinite variations of value and asset transfers on SagaChain. SagaOS is an open architecture. We encourage and expect users globally to independently develop and use their own variations of value and asset transfers.

If should also be understood that there are no smart contracts involved in these examples, or needed in even more complex variations. All transactions occur directly with user accounts. The all code is directly associated with the object instances alleviating the need for separate smart contract accounts, and any associated bottlenecks.

[1] https://medium.com/@dbeberman/rethinking-sharding-and-smart-contracts-for-maximizing-blockchain-throughput-5eaf91bb5781

[2] https://medium.com/@dbeberman/extensible-smart-object-assets-smart-object-asset-ownership-and-fractional-smart-object-asset-995c259a8508

SagaOS, XSOA, Smart Object are trademarks of Prasaga, Founation, all rights reserved.