Evolving from the Smart Contract Blockchain Platform to the Extensible Blockchain Object Model Platform
In an attempt to understand the difference between a Smart Contract Blockchain Platform and an Extensible Blockchain Object Model Platform we have chosen an analogy, which we believe is widely understood at a high level: That is, Sheets and workbooks as an explanatory model.
For this exercise let’s assume three types of Sheet architectures
1. Single sheets, external input and references between cells on a single sheet only.
2. Workbooks with multiple sheets, limited such that all external input and internal sheet references, are within each individual Sheet. No references or relations are allowed between or across multiple Sheet in the workbook.
3. Workbooks with multiple sheets, both external input and internal references between cells within and across Sheets in the workbook are fully supported.
Bitcoin Blockchain an Example of a Single Sheet
In the first analogy, Single sheets, external input and references between cells on a single sheet only, we have Bitcoin. All transactions happening in the single Sheet are initiated and completed from/to user accounts. A user account is a row in the Sheet. You can only reference different rows within the single sheet.
• A Bitcoin blockchain represented as a single Sheet.
• No explicit account state tracking.
• No asset ownership tracking, only bitcoin transfer transactions
• Any and all “asset” transfers happen outside of the blockchain
Smart Contract Blockchain Platforms (Ethereum) as an Example of a Sheet Workbook
The Second Sheet analogy, Workbooks with multiple sheets, limited such that all external input and internal sheet references, are within each individual Sheet. No references or relations are allowed between or across multiple Sheet in the workbook, represents the Smart Contract Platform: Whereas the smart contract is a separate Sheet within the workbook. Each smart contract Sheet acts somewhat analogous to a standalone Bitcoin Sheet, all contained within one workbook, which is the blockchain. In the Smart Contract model, each individual Sheet may complete only one transaction at a time serially on the underlying blockchain.
Commonly smart contracts are used for tokenization. Each smart contract manages a completely separate and unrelated token. Thus, with the Sheet model, each smart contract is a separate Sheet that manages a single token, keeping track of the accounts and balances. All token transfers are represented as changes in account balances in the smart contract Sheet. Each account can be thought of as a row in the Sheet with its current balance and any other associated data. Again, using the Sheet analogy, all such transactions must be ordered and serialized, as though you were manually entering data and updating a Sheet.
• A smart contract blockchain platform represented as a Sheet workbook
• Each smart contract represented by a separate Sheet
• A single underlying blockchain completes all transactions serially
• Account state explicitly tracked
• A smart contract Sheet tracks a token as single asset
• User accounts contain smart contract token balances or any other assets
- Only 1 transaction at a time per smart contract
Extensible Blockchain Object Model (“XBOM”) Platform
DataGrid Blockchain (DGB) with XBOM™
The DGB is the reference for the third example, Workbooks with multiple sheets, both external input and internal references between cells within and across Sheets in the workbook are fully supported.
In the Extensible Blockchain Object Model Platform we have the blockchain represented as a Sheet workbook with each account as a separate Sheet within the workbook. The Extensible Smart Object Asset (“XSOA™”) Model built on the XBOM evolves the Smart Contract Model from a Sheet as a token smart contract to each account’s Sheet containing multiple assets of varying types represented as Smart Objects™ .
The XBOM eliminates the limitations of the Smart Contract Model such that Smart Objects may be referenced across multiple account Sheets. This can be thought of as referencing cells between Sheets in a workbook of Sheets. Each Smart Object is represented as a cell on user accounts, Sheet which establishes ownership of the Smart Object. A Smart Object can represent virtual assets (e.g. title to property, vehicles, Stocks, Bonds, Electronic Medical Records (EMR) etc.).
Smart Objects are transferred between user accounts. This is analogous to deleting a cell on one Sheet and adding a new cell to another Sheet. Unlike the Smart Contract Model, transactions between accounts do not need to be serialized with a common smart contract account. Perhaps, think of this as several people editing separate workbook Sheets simultaneously on a shared workbook. Provided the editing does not overlap, all edits can be directly merged together.
What this leads to is a global system where all assets are under control of the user account that owns them represented as Smart Objects.
• An extensible blockchain object model represented as a Sheet workbook
• Each user account represented by a separate Sheet
• User accounts contain Smart Objects (assets), analogous to cells in each Sheet
• Transactions are directly between user accounts, analogous to transferring cell contents between Sheet. No smart contract account needed.
- Multiple simultaneous Smart Object (asset) transactions supported, instead of serialized per smart contract
We hope this post visually reveals some advantages enabled in the DGB and XBOM architecture over current approaches taken in the industry. The DGB allows developers to use live code, reducing instances of bugs and malicious code. It creates individual Sovereignty, as all assets are in control of each account on the blockchain. Additionally, DGB reduces time to market for Smart Business to open on the blockchain for services such as exchanges, marketplaces, etc. We look forward to receiving comments on the overview we shared over the previous 5 Medium posts and working with the community on making this project reality.
 XBOM, XSOA, Smart Object are trademarks of Prasaga, LLC, all rights