First Attempt in XBOM (eXtensible Blockchain Object Model) | by KC Tam | Oct, 2020

Introduction

Those having experience in developing chaincode in Fabric know well how a chaincode looks like. In a nutshell, we define the data structure (state) for some assets, and functions which one can query the state, or invoke if change of state is needed. Since v2.1, Fabric team also introduces Contract API (link) which simplifies the way chaincode is written. This still follows the same pattern.

Recently I see another attempt to change the way we develop smart contracts with classes and objects, which is a favourite model for many developers. Prasaga introduces Extensible Blockchain Object Model, XBOM, in which assets are defined as objects and owned by accounts. XBOM provides a coding environment and methodology, which is currently implemented in Hyperledger Fabric for a permissioned chain offering and will be available on DataGrid Blockchain (DGB), an open permissionless chain in the future.

With XBOM, developers build applications with object oriented programming model, and XBOM provides an infrastructure serving them. The infrastructure (named Class Manager Infrastructure) then interacts with the underlying infrastructure, which is a fabric network in this case. Theoretically the developer does not care about the blockchain, as it is well handled by the infrastructure. That is the reason XBOM is positioned as “Decentralized GlobalOS”, like an operating system on top of the blockchain.

For those who are interested in this approach, the best way is to gain more information from their website. Here is the overview of XBOM.

The first available XBOM material is a set of chaincode in Golang. Since this summer they have published several videos. I have tried the code and here I document some of my experience and observation during my first attempt.

Some Concepts about XBOM

While you can always find good and official explanations on the material, here I try to provide some quick ideas about XBOM.

XBOM is a First-Class Object Model, meaning that everything is object in this environment. While the developers are dealing with the classes and objects in their code, these classes and objects are objects inside XBOM. XBOM provides a Class Manager Infrastructure such that developers can focus on their applications with their own classes and objects on a blockchain environment, without involving the chaincode and handling the ledger natively.

The Class Manager Infrastructure interacts with the underlying blockchain platforms. Taking Fabric as an example, each object is stored as a key-value pair in the ledger. The key is a unique identifier, called Ledger Object Identifier (LOID), and the value keeps all relevant information about this object. The Class Manager Infrastructure is responsible for interacting with the ledger storage, and is in fact a set of chaincode when it is implemented in Fabric.

We can see this approach in a layered representation, and compare this with traditional coding on Fabric environment (source: David’s slide shown in the video with some colour code).

Application developers are no longer coding at chaincode level. Instead they are working at object level. They will use the object transaction model provided by Class Manager Infrastructure. In general, each transaction is to specify which account context the transaction is working, the target object, method and input arguments for the method. The Class Manager Infrastructure processes the transaction and returns the output.

Transaction at object level

We will go in depth into how Class Manager Infrastructure works with the fabric network and ledger later in the demonstration.

Our demonstration is to create an account object. Here we introduce the concept of object containment in XBOM, and how account is associated with the containment. Each object has reference to a parent object or directly (and eventually) to an account object (Class Account). This forms a tree structure of objects. This model is good for providing ownership of assets (objects) to an account. (Source: David’s slide shown in the video.)

Tree structure for objects, owned by an account.

After bootstrap we have the first account: System Account. In the demonstration we are going to create a new account with the System Account. We will detail how this is done.

Our demonstration is to create a new Account object with System Account.

This is just a tip of an iceberg in XBOM, but should be good enough for the demonstration. You can always get the latest update on their site.

Demonstration and Illustration

The demonstration follows the material (videos) on XBOM website. You can find the video of how the demonstration works. Meanwhile I make some illustrations and observations about the demonstration.

Video sources

A Ubuntu 18.04 LTS server on AWS EC2 is instantiated for demonstration. The code and installation instruction is available here through registration.

We broadly divide the demonstration into two steps.

Step 1 is mainly on Fabric operation. The fabric network follows the Test-Network in fabric-samples with modification. In particular, a script classmanager.sh is created to perform all the tasks. This classmanager.sh largely follows network.sh in Test-Network. During the whole demonstration we use classmanager.sh to perform all the tasks, including bringing up the network, deploying the Class Manager Infrastructure and bootstrapping all components. After Step 1 we have a Class Manager Infrastructure ready for our next step.

Step 2 focuses on Class Manager Infrastructure. We will interact with objects provided in the Class Manager Infrastructure. All commands are working in this layer, and Class Manager Infrastructure is handling the relevant activities in chaincode invocation. During the demonstration we will take a look at what happens in the ledger. This gives us a better understanding about how Class Manager Infrastructure is interacting with the Fabric. Our task is to create a new Account object, and after that we will use “inspect” method from the Class Object to take a look at the new Account object.

Step 1.1: Bring up modified Test Network and Create Channel

This brings up a sample network, following the Test Network in Hyperledger Fabric 2.0+. It contains three organizations. One orderer organization and two peer organizations. A channel mychannel is created and the two peer organizations join this channel.

./classmanager.sh up createChannelor./classmanager.sh up createChannel -s couchdb

Note: couchdb can be used as the world state database for each peer with -s couchdb.

Step 1.2: Deploy Class Manager Infrastructure

Class Manager Infrastructure is a set of chaincode designed with the purpose of building the Class Manager Infrastructure. It uses the standard lifecycle chaincode to deploy this set of chaincode to the Fabric network.

./classmanager.sh deployCC

After deployment, it is what we observe in the ledger. We see a database is created on the channel (mychannel) and chaincode (classmanager).

Inside ledger, mychannel_classmanager is the database holding all objects.

Step 1.3: Initialize Bootstrap

Class Manager Infrastructure bootstrap creates all the required components to support the transaction at XBOM level.

./classmanager.sh InitBootstrap -loid default

This is equivalent to invoking the chaincode function InitBootstrap with LOID default.

After the bootstrap function is invoked, we see more records in the database.

We see some objects are created after bootstrap completes.

Here are the records created. The keys are LOID of various objects defined in XBOM. As LOID is a hash version of something, you will see many “unreadable” items in the database, except for the RootDictionaryLOID, which gives us some idea in the demonstration.

Now we have the Class Manager Infrastructure. We start working at the XBOM level from now on.

The demonstration is to obtain the Object Handle for Root Account object, and create a new account (i.e. a new Account object) using Root Account object.

After bootstrap in Step 1.3, we now have several objects we are going to work with.

Root Account object: A root account or system account is represented by a Root Account object. As introduced above, we need an Account object as a context when we interact with the Class Manager Infrastructure. We are using the Root Account object to create this new Account object.

A direct query (GetSystemAccountObject) is provided to get the LOID of the Root Account object. This is shown in Step 2.1

Root Dictionary object: The root dictionary stores a map from unique string names and unique LOIDs. As our purpose is to obtain the Object Handle of Root Account, we need to make a query on the root dictionary.

A direct query (GetRootDictionary) is provided to get the LOID of the Root Dictionary object. This is shown in Step 2.2.

With this information we can start working at transactions like this.

The input includes the following information

  • Account Object: the context of current account
  • Target Object: the object our transaction is acting upon
  • Method Name: the method of our action
  • Input Argument: arguments needed for the action

After processing in Class Manager Infrastructure, we will get back the designed result (returned argument).

In this demonstration we are going to perform two transactions. Both in the context of Root Account object:

  • Get Root Account Manager object handle from Root Dictionary (in Step 2.3)
  • Create new account using the Root Account Manager object handle (in Step 2.4)

We will see the transaction more in detail.

Finally, Class Object comes with a method for inspection. As all objects inherit from Class Object, so does our new Account Object. This is shown in Step 2.5.

Step 2.1: Get System Account Object

./classmanager.sh Invoke -ic '{"Args":["GetSystemAccountObject"]}'

We get back the System Account object: [83, 121, 115, 116, …]

Step 2.2: Get Root Dictionary Object

./classmanager.sh Invoke -ic '{"Args":["GetRootDictionary"]}'

We now have the Root Dictionary object: [82, 111, 111, 116, …]

Step 2.3: Transaction: Get Object Handler of Root Account Manager

Now we perform the first XBOM transaction: use System Account object (obtained in Step 2.1) to access Root Dictionary object (obtained in Step 2.2), by specifying the method ClassDictionary_GetObjectByName with input argument RootAccountManager.

This is the first XBOM transaction.

  • Account Object: System Account object [83, 121, 115, 116, …]
  • Target Object: Root Dictionary ObjectHandle [82, 111, 111, 116, …]
  • Method: ClassDictionary_GetObjectByName
  • Input Arguments: ObjectPathName: RootAccountManager
./classmanager.sh Invoke -ic '{"Args":["ObjectSend","[83,121,115,116,101,109,65,99,99,111,117,110,116,79,98,106,101,99,116,0,0,0,0,0,0,0,0,0,0,0,0,0]","[82,111,111,116,68,105,99,116,105,111,110,97,114,121,76,79,73,68,0,0,0,0,0,0,0,0,0,0,0,0,0,0]","{\"Mtdstring\":\"ClassDictionary_GetObjectByName\"}","{\"ObjectPathName\":\"RootAccountManager\"}"]}'

The returned argument is the ObjectHandle of Root Account Manager object: [44, 32, 80, 101, …]. We will use it in Step 2.4.

If we take a look on the ledger, we see RootDictionaryLOID is updated with a new revision. The transaction above has made some updates on the Root Dictionary object.

If we go deeper into how the transaction is processed in Class Manager Infrastructure, this is the actual process of a transaction flow.

How Class Manager Infrastructure interacts with the Fabric.

The Class Manager Infrastructure takes care of all the tasks interacting with the underlying Hyperledger Fabric system. Object information is retrieved from the ledger, and updated when needed after the process. This is why we see updates on the ledger.

Step 2.4: Transaction: Create a New Account

With the Root Account Manager object handle available, we now send another transaction. Still in the context of System Account object, the target is now Root Account Manager, with method ClassFactory_NewObject. An input argument, number of accounts to be created, is set 1.

Here is the transaction to create a new account.

  • Account Object: System Account object [83, 121, 115, 116, …]
  • Target Object: Root Account Manager ObjectHandle [44, 32, 80, 101, …]
  • Method: ClassFactory_NewObject
  • Input Arguments: NewCount: 1
./classmanager.sh Invoke -ic '{"Args":["ObjectSend","[83,121,115,116,101,109,65,99,99,111,117,110,116,79,98,106,101,99,116,0,0,0,0,0,0,0,0,0,0,0,0,0]","[44,32,80,101,53,74,36,52,35,113,59,53,46,50,89,84,97,56,35,92,98,95,35,66,96,32,90,118,81,80,89,68]","{\"Mtdstring\":\"ClassFactory_NewObject\"}","{\"NewCount\":1}"]}'

The ObjectHandle of New Account object handle is returned: [45, 38, 60, 97, …]

If we take a look on the ledger, we see RootDictionaryLOID and more records are updated. Besides, a new record is created, which should be corresponding to the new account object created in this transaction.

Step 2.5: Inspect the Account Object Newly Created in Step 2.4

Class Object comes with a handy method Inspect_Object. Since all objects in XBOM inherit Class Object directly or indirectly, we can use this method to get more detailed information about any object. Here we use it for the Account Object we created in Step 7.

The transaction looks like

  • Account Object: System Account object [83, 121, 115, 116, …]
  • Target Object: New Account ObjectHandle [45, 38, 60, 97, …]
  • Method: ClassObject_Inspect
  • Input Arguments: Unused: 0
./classmanager.sh Invoke -ic '{"Args":["ObjectSend","[83,121,115,116,101,109,65,99,99,111,117,110,116,79,98,106,101,99,116,0,0,0,0,0,0,0,0,0,0,0,0,0]","[45,38,60,97,79,122,35,32,42,105,59,110,88,54,43,43,80,80,49,116,38,43,55,123,58,33,102,79,50,44,95,43]","{\"Mtdstring\":\"ClassObject_Inspect\"}","{\"Unused\":0}"]}'

We see a big output. Here is the collapsed view of the output.

Here is the first item in “definitions”.

You can see this is a huge output of an object, including the object itself, methods, and class ancestry tree. The result is a JSON object parseable for information or other uses.

This is the end of demonstration.ly the

Summary

Hope you can get some ideas through this first attempt in XBOM. As mentioned above, XBOM itself can be seen as a way of coding smart contracts with developer-friendly object-oriented programming model. The demonstration has shown the first Class Manager Infrastructure implemented on top of Hyperledger Fabric with Golang. I will come back with further elaboration once there are more detailed documentation and more demonstrations. Stay tuned.

This article has been published from the source link without modifications to the text. Only the headline has been changed.

Source link