04 Apr
Introduction
In our previous blog post, we described how we empowered a blockchain developer to implement tokenization feature using Blockchain App Builder by easily generating the token chaincode without any specialized skills, while also making the maintenance of the complete token life cycle very easy. This innovation enables tokenization capabilities in Hyperledger Fabric, which doesn’t provide token capabilities at the infrastructure level. Blockchain App Builder is a low-code development toolset developed by Oracle for Oracle Blockchain Platform to generate an application chaincode from a declarative specification file. When we first released the tokenization feature on Blockchain App Builder at Hyperledger Global Forum on June 10th, our objective was to make any token chaincode development, deployment and testing faster and to make the complete token lifecycle maintenance simpler. We believe in driving the speed of innovation through simplicity. To ensure the simplicity in developing blockchain applications, we adopted account/balance model for token record keeping rather than UTXO (i.e. Unspent Transaction Output) model pioneered by Bitcoin.
UTXO vs. Account/Balance Token Model
The account/balance model also used by Ethereum keeps track of the balance of each account as a global state. The balance of an account is checked to make sure it is larger than or equal to the spending transaction amount. The benefit of having account/balance model is simplicity and the speed of execution. With account balance model, developers can easily create any complex chaincode that requires tracking of state information and interaction with multiple parties. Since, each transaction only needs to validate that the sending account has enough balance to pay for the transaction, the chaincode execution is faster. On the contrary, UTXO model adds complexity in application development. UTXO doesn’t store “account balances”, but it keeps track of all the “spent” and “unspent” transactions. User wallet apps or chaincodes have to track the spent and unspent tokens, invoking a “transfer” chaincode specifying the list of unspent transactions, creating new unspent transaction during each token transfer, and computing the amount of tokens available to a user, while tracking and adding up the amounts of all unspent transactions. Hence, the account/balance model was a natural choice to simplify the application development.
However, in account/balance model, executing concurrent transactions involving the same account is a challenge. For example, in an airline loyalty program using a token application, the airline awards loyalty tokens to the travellers, which they can redeem with airline partners, such as a car rental company. The travellers hold the loyalty tokens in their respective individual token accounts. When two or more travellers try to redeem / transfer their respective loyalty tokens concurrently to the same account of the car rental company to rent cars, the transactions can end up in the same block, which would lead to the second transaction failing the peer node validation due to Multi Version Concurrency Control (MVCC) Read Conflict error.
Oracle Blockchain Platform or Hyperledger Fabric – as most other permissioned blockchains – rely on an optimistic lock approach: a transaction is “simulated” at endorsement time – with no locks applied to the data, and the transaction is committed once the block has been cut and sent to the peer nodes. At commit time, the read-write sets of the transactions are “validated”, to make sure that data hasn’t been modified between endorsement and commit phases. If the transaction passes the validation phase, its write set is applied to the blockchain’s State DB. This will succeed for the first transaction in the block, but any subsequent transaction updating the same account balance, will fail this validation. If the transaction doesn’t pass the validation phase, the transaction is stored in the ledger with a “failed” status – “MVCC Read Conflict”. To avoid the error, either the application developers need to serialize the transactions or they have to identify the failed transactions with “MVCC Read Conflict” status and re-execute (i.e. re-submit for endorsement and commit request) the same transactions. Serialization of transactions or re-execution of the transactions will significantly reduce the overall transaction throughput of an application.
Throughput Optimization for an Account/Balance Token Model System
In the latest release of Blockchain App Builder-21.3.2, we introduced throughput optimization with account/balance model to avoid MVCC read conflict errors on Oracle Blockchain Platform (OBP). With the new feature of “MVCC optimization”, the application developers neither need to serialize the token transactions nor do they have to re-execute the token transactions in the situations where a single token account is involved in concurrent transactions. During the scaffolding of chaincode project from a specification file, developers can select “Enable MVCC Optimization” option to avoid MVCC read conflict errors on OBP and increase the overall transaction throughput of the application.
MVCC Read Conflict errors happen at validation time when a key-value pair included in the transaction’s read set is reported at a “height” which is lower than the current “height” of the same key-value pair in the StateDB. When that happens, it means that another transaction modified that key-value pair after endorsement. For MVCC optimization, we relaxed the MVCC read conflict checks in Oracle Blockchain Platform (OBP) peer nodes during the validation time but enforced additional validations on OBP peers, such as the account balance can’t be negative (which help avoid the perennial double-spend issue) or the total token supply can’t exceed the maximum token quantity limit.
By enabling the MVCC optimization option, Blockchain App Builder identifies the token amount fields (e.g. Balance, BalanceOnHold) that would change during concurrent token transactions. During the endorsement time, when the chaincode modifies the value of a StateDB field, OBP computes the delta between the new and old values, adds the delta to the transaction’s write set and flags the operation as “optimized account balance”. During the commit time, OBP detects the fields flagged as “optimized account balances” and additionally verifies the static rules (e.g. account balance can’t be negative or the total token supply can’t go beyond the maximum token quantity limit). After the verification, if the transaction is valid, the State DB field is updated from the delta value to the absolute value relying on the current data – which may have been modified since endorsement time. With MVCC optimization, in the airline loyalty token application, multiple travellers can concurrently redeem / transfer tokens from their respective individual token accounts with the car rental manager’s account. The MVCC optimization avoids having to limit account updates to one per block, which significantly increases the transaction throughput.
Fig-3: Token transfers into single account with endorsement-time and commit-time optimizations.
Conclusion
We strongly believe that a blockchain developer can be truly empowered if they can leverage an automatically generated production-ready token chaincode and easily manage the complete token life cycle in broader applications ranging from simple loyalty programs to complex payments, trade finance, securitization, and other applications. To expedite the token chaincode development and to manage the complete token life cycle easily, the token chaincode design has to be simple. Our simple design approach with account/balance model to build complex chaincodes helps to propel the innovation in the enterprise. To make this scale in production, these chaincodes must also provide high throughput and great scalability. Our optimizations in Blockchain App Builder-21.3.2 release to solve the MVCC conflict issue inherent in account/balance chaincode model helps to accelerate the innovation and enables the real world token applications for mass adoption.
