Challenges with the current Accelerator blockchain system approach

There are some challenges with the current Accelerator approach. They can be overcome by closer integration with Hyperledger Fabric, but, as currently implemented, they represent limitations to its adoption. These sub-sections explain the challenges and discuss how they might be overcome.

Transaction “blurring”

The transaction submitted by an application to Accelerator is not the transaction that appears on the ledger. Instead, the ledger contains multiple transactions that have been “blurred” together. This occurs because Accelerator blocks transactions into jobs, and the actual submitted transaction is the sum of all the individual transactions within a job. This creates challenges for auditability, as users cannot look through the ledger and identify the transactions they have submitted. It makes it difficult for applications, administrators and auditors to link the actual submitted transaction to the one that appears on the ledger. This is a significant problem given purpose and value of a blockchain as an immutable transaction log.

Transaction proposal “mis-signing”

Without Accelerator, the transaction that is submitted by an application is signed by it and the peer that executes it, and these signatures are retained with the transaction as it is recorded in the ledger. When Accelerator is used, the transaction that appears on the ledger is the result of a collection of transactions – a job - and it is this aggregated transaction that is signed by Accelerator and the peer. It means that the transactions that appear on the ledger are not signed by the submitting applications, and again this presents a significant challenge to the current implementation given the purpose and value of a blockchain as a true record of agreed transactions.

User chaincode wrapper

Although it is a fairly mechanical process, chaincode developers have to write a chaincode wrapper to de-block a job into its individual transactions that are then individually executed to generate an aggregate transaction response. This is an extra development task and requires chaincode to be re-installed and re-instantiated. As discussed below, this would be a relatively straightforward feature to be built-into Fabric.

Non-standard APIs

Finally, the APIs provided by Accelerator to applications are only gRPC-based; they are significantly different to the regular SDK programming languages. It means that applications which currently use the JavaScript, Java or GOLANG SDKs have to change to exploit Accelerator. Again, this would be a relatively straightforward feature to be built-into Fabric.

Transaction blurring, transaction mis-signing, user chaincode wrappers and non-standard APIs could all be overcome by making Hyperledger Fabric aware of the concept of a job. The peers and orderers that form a network could treat a job as a collection of transactions and treat them accordingly at execution, ordering and validation time, making sure that transactions proposals, and response signatures were preserved. In this way the benefits of aggregation would be gained without these downsides. Transaction collisions cannot be overcome; other techniques not discussed in this paper are required to alleviate this issue.

Discussion

Applicability

Accelerator provides the improved performance in terms of transactions per second when data are less correlated with each other; e.g., data from a comparatively large number IoT sensor/edge devices as they mostly generate sporadic data. When it comes to the entire volume of such transactions, the larger volume of data would lead to better performance since Accelerator works in a way of aggregating up to enough number of transactions and committing them in a batch. That is, according to what specific business use cases or scenarios Accelerator supports, its expected performance benefits will vary. Therefore, it is recommended to consider applicability based on such performance characteristics and experimental test results to get more precise TPS expected.

Adaptability

Accelerator can adapt to the entire blockchain network condition according to, for example, the number of transactions that it is supposed to process in a given time. For example, if the number of transactions that Accelerator receives as inputs is getting smaller, it would be better to decrease Aggregator’s window size, i.e., the number of transactions for the aggregation, to reduce the additional transaction latency, which can be caused by a wait time condition in the Aggregator. In the meantime, if Accelerator is processing transactions more and more in time, it needs to increase the window size to maximize the TPS. To enhance this capability, it is necessary to consider developing additional accelerator monitoring and analytics components described in the following sections.

Monitoring

Accelerator’s status data by monitoring can be utilized to maximize the adaptability. It collects Accelerator-related system information such as:

• how many transactions are submitted during a specific time

• how many transactions are committed correctly

• how many batched transactions fail

• how long it takes to reach to the consensus and get finality

• the entire computing and network resource consumption, etc.

This information would be beneficial not only when system operators check the system health but also when Accelerator Analytics, described in the following paragraph, decides when it should increase or decrease the window size and even when it should turn on or off the Accelerator.

Analytics

Based on the information gathered by Accelerator Monitoring, Analytics can provide more insightful adaptation capability to Accelerator. By analyzing transaction processing-related status such as the number of inbound and outbound transactions, and their occurrence distribution in time, Accelerator Analytics can suggest optimal parameters such as dynamic window size for greater efficiency. Accelerator Analytics is a component where users and developers build the appropriate models for specific use cases and they can load such models on. Accelerator, in the meantime, will have handler mechanisms to interact with Accelerator Monitoring and Accelerator Analytics. In this sense, an Accelerator that is supplemented by both monitoring and analytics will have dynamic adaptation capability, which can reduce the transaction latency while increasing transaction throughput performance.

Roadmap

The purpose of this collaboration between IBM and SDS on the Accelerator is to, by running efficiency and performance tests, propose additional functions for the Hyperledger projects such as Hyperledger Fabric SDK, improve performance efficiency and functionality, and, ultimately, integrate the additions with the IBM Blockchain Platform (IBP).

Socialize

The first stage, Socialize, took its shape through the first workshop between IBM and SDS. In this stage, based on the results from the assessment of Accelerator that Samsung SDS and IBM worked together, we hold the purpose to form this whitepaper collaboratively. This stage includes preparation for us to share Accelerator in the next step, “INNOVATE”. Accordingly, the design concept and principles, the problem background, the assumption of use cases and scenarios, main functions of Accelerator, and the framework of testing and evaluation are explained in this whitepaper. The underlying system is built by using as-is Hyperledger Fabric docker images that no modification from the public github are implicated. We present the performance comparison results on the system with and without Accelerator as well.

Innovate

The purpose of this stage is to develop an “Innovation Sandbox” available in a public github repository where anyone can download, test, and reproduce the expected performance results using Accelerator on Hyperledger Fabric. This allows us to clearly demonstrate the level of performance of improvement through Accelerator as well as to provide deeper understanding of the technology described on the whitepaper. The Innovation Sandbox will be provided with a docker image of Accelerator and a performance benchmark tool, which additionally has an adaptor module based on Hyperledger Caliper open source to connect Accelerator for performance evaluation. Technical details will be presented to the audience who are working on/with Hyperledger-based projects at technology conferences such as a technical session at IBM THINK. This stage will provide a conduit for valuable feedbacks from the Fabric community with regard to the appropriateness of including Accelerator into Fabric open source projects. Further, additional use cases/refinements may also be identified.

Develop@Scale

In “DEVELOP@SCALE” stage, we target to release Accelerator as an open source component after getting agreements from blockchain community, so that even more engineers can jointly develop and improve Accelerator together. Specifically, the current version of Accelerator can be refactored and incorporated into one of Hyperledger opensource projects. For example, the client-side acceleration approach can be embedded into Hyperledger Fabric SDK in this stage first. Other Fabric enhancements made at this point will be under consideration to integrate alongside the Accelerator capability into the open source. Also, along with opening the source code to the public, Samsung or IBM may design the additional tools (not subject to open source) in need for Accelerator, for example, deployment and monitoring tools, and the systems from such design will be useful when Accelerator is applied to the commercially operating services such as the IBM Blockchain Platform. Additional components, such as Accelerator Analytics described in the Discussion may also be designed during this stage to provide additional business opportunities derived from the incorporation of Accelerator into Hyperledger opensource projects.

Optimize

“OPTIMIZE” stage is to further optimize and advance Accelerator. More specifically, Accelerator will be in a form of server-side one, adding a service discovery function to consider multi-region operation where a number of peers are geographically dispersed and aligning with other enhancements that will be made at this point in Hyperledger Fabric. If the server-side Accelerator is added to the client-side one from the previous stage, its performance benefits will be even improved because the traffic from more endpoints and client software can be intensively collected and processed together at the server-side Accelerator. In addition, Accelerator can reach to comparatively better performance if the client (with Accelerator) is geographically close to peer node in Fabric network while it would suffer from performance degradation if the clients are geographically dispersed.

Conclusion

Samsung SDS and IBM have developed and evaluated Accelerator intensively and formulated roadmaps to work with open source communities. Accelerator consists of three major and one supplementary component: Classifier, Aggregator, Router, and the chaincode installed in endorsement peers. All components work to increase TPS in a way of bundling uncorrelated transactions in a batched transaction and submitting it to the Hyperledger Fabric network which can lead to reduce the total required number of endorsement procedures. By deploying Accelerator in front of the Hyperledger Fabric network and connecting to peer nodes, we have successfully developed Accelerator without any modification on Hyperledger Fabric at this phase. According to our evaluation and assessment, Accelerator reaches up to 10x TPS performance on IBM Cloud testing environment. By its design, Accelerator can be easily plugged into an existing Hyperledger Fabric-based blockchain network, and we recommend that current users of Hyperledger Fabric try it out during the “Innovate” phase.

Accelerator’s performance is affected by the characteristics of data and transactions. If they are strongly correlated and the correlations occur at the nearly same time, the throughput gain in terms of TPS will not be as high as ten times. For example, a high-frequency trading system would not easily expect the best performance benefits. A more adaptable use case is the one where transactions are uncorrelated or correlated but sporadic. Examples may include not only an IoT scenario, but financial services such as Smallbank operations shown in Evaluation section. In such use cases, Accelerator is able to show the best performance improvement.