Blockchain Analytics
Blockchain and private distributed ledgers through the lens of privacy-preserving data science — analytics techniques, visualization, data modelling with BlockchainDB, and benchmarking Ethereum, Parity, and Hyperledger.
The aim of this blog is to demonstrate the concept of blockchain and private distributed ledger with respect to privacy-preserving data science. The blog also states the currently used blockchain analytics techniques for blockchain-oriented data science, visualization techniques, and benchmarking of popular blockchain frameworks which highlight some significant limitations in Ethereum, Parity, and Hyperledger blockchain frameworks.
Blockchain technology has become popular in the last decade. The blockchain is a public ledger that records a list of transactions in the distributed network. The first introduction of blockchain technology was by Satoshi Nakamoto, who introduced Bitcoin cryptocurrency. Since then, the technology has found its place in many different decentralized systems. As technology revolutionized transactions and exchanges, it has been widely used in industrial applications. Some of the popular blockchain frameworks are Bitcoin, Ethereum, IBM Hyperledger, etc.
Blockchains allow parties that do not trust each other to exchange transactions and agree on a common view of their balances. It enables auditability and traceability in order to detect potential malicious operations in a shared state. Blockchains can be operated reliably in a completely decentralized manner without the need to involve a central trusted instance.
This blog assumes that the general underlying mechanism of the blockchain structure is well understood by the reader.
1. Blockchain Oriented Data Science
A blockchain framework is capable of generating huge volumes of data as it is designed to track every single transaction in the distributed network. This develops the need to have some data analytics mechanism in place to keep track of a number of things like money flows, user behaviour, transaction fees, analysis of entity relationships, etc. With this, the need for some efficient underlying blockchain database for querying the blockchain data is also developed. There are also some limitations with respect to blockchains which restrict their wide-scale use.
There are many visualization techniques being used and produced in the industrial and academic literature. Before analysing any blockchain system, it is important to understand every element in the blockchain framework. There are three types of blockchain frameworks:
- Public — Anyone can participate and join the consensus.
- Private — Fully controlled by an organization.
- Consortium — These are semi-private blockchains that restrict the consensus process to selected groups.
Each of these frameworks may have most of the components in common. Let’s take an example of the Bitcoin framework and use this as our baseline for understanding how we can perform data analytics on a Bitcoin framework. Before jumping into analytics, let’s understand different components of a Bitcoin framework:
- Transaction: The most granular level of blockchain data. A transaction records the transfer of value between addresses.
- Blocks: Transaction records are stored in blocks. They hold and group a certain number of transactions.
- Ledger: Multiple blocks are connected in a linked list called the Ledger.
- Nodes: Electronic devices that maintain and distribute a copy of the ledger in the blockchain network to maintain synchronization of data.
- Miners: Special nodes in peer-to-peer networks that participate in verifying transactions and adding new blocks to the ledger, with the possibility to receive a reward.
- Entity: Represents a real blockchain user or organization behind a transaction.
By knowing all the components within a blockchain system, we get to understand where to look for a particular type of data for doing analytics.
Tovanich et al. proposed a taxonomy of blockchain analytics for the Bitcoin framework based on analysis themes:
- Analysis of entity relationship
- Metadata
- Money flows
- User behaviour
- Transaction fee
- Market wallets
This taxonomy helps to frame our analytics goals for analyzing any kind of blockchain framework depending on the task domain. For example, for a Bitcoin framework the following can be the analysis goals: anonymity, market analytics, cyber crime, metadata analysis, and transaction fees.
Any data science activity for a blockchain framework can be classified into two types:
- Analysis tasks — Based on the analytics goals.
- Visual representations — of blockchain data or system.
Tovanich et al. introduced a classification scheme of visualization on blockchain data, focusing on Task Domains for data analysis:
- Transaction detail analysis: Analyze transaction patterns for individual blockchain components or derived entities in blockchain networks.
- Transaction network analysis: Show transaction networks, network entities, and value flows tracing the transfer of cryptocurrency values through transactions over time. Mostly represented by directed bipartite graphs.
- Cyber crime detection: Visualizations that detect suspicious transactions and entities or investigate cyber attack events. A popular technique is value-flow analysis, which allows visualization of a deep transaction flow graph to trace money laundering and stolen Bitcoins.
- Cryptocurrency exchange analysis: Visualize cryptocurrency conversions from crypto values into real-world currencies. Mostly used for visualizing conversion rates and market analysis.
- P2P network activity analysis: Visualize time series to show the aggregated statistics of P2P networks, plus map-based visualizations to show the geographical distribution of blockchain usage around the world.
- Casual / entertainment purpose: Visual encodings for understanding blockchain networks, maybe for casual entertainment. An example is Bitcoin VR, an open-source project that visualizes Bitcoin transactions as balloons flying over a 360-degree view.
2. Data Modelling for Blockchain Framework
For performing efficient data analytics on a blockchain framework, it is important to have a managed underlying data model which enables systematic blockchain data analysis. El-Hindi et al. introduced the concept of BlockchainDB with the aim of coming up with a shared database on blockchains. BlockchainDB introduces a database layer on top of the existing blockchain framework that extends the blockchains by classical data management techniques. The aim of BlockchainDB is to increase performance and scalability of blockchains for data sharing but also decrease complexities for organizations intending to use blockchains as a DB.
As El-Hindi et al. mentioned, there are two main reasons why blockchains are not being used widely:
- Limited scalability and performance: Even state-of-the-art blockchain systems like Ethereum or Hyperledger can only achieve tens or at most hundreds of transactions per second, which is way below the requirements of modern applications.
- They lack easy-to-use abstractions: Current blockchain systems lack a simple query interface and guarantees such as well-defined consistency levels that guarantee when and how updates become visible. Most of them come with proprietary programming interfaces.
BlockchainDB attempts to address these main issues for blockchain data management. It leverages blockchains as a storage layer. This way, existing blockchain systems can be used without modification as tamper-proof and decentralized storage. On top of the storage layer, BlockchainDB adds a database layer which implements partitioning & replication and query interface & consistency.
BlockchainDB also offers off-chain verification procedures in which clients can detect potential misbehaving peers in the BlockchainDB network. It comes in two flavors, offline verification and online verification. El-Hindi et al. mention the advantages and disadvantages of each but specify that offline verification is preferred and is less costly.
In the database layer, BlockchainDB additionally provides easy-to-use abstractions including different consistency protocols, namely eventual consistency and sequential consistency:
- Eventual consistency: A get-operation is immediately answered; however, no guarantee is given that a potential outstanding put operation has already been committed to the blockchain.
- Sequential consistency: The database layer needs to execute put/get operations in order, and this potentially blocks a get-operation until an outstanding put-operation has been committed to the blockchain.
3. Visualization Challenges in Blockchain
There are some significant challenges identified by Tovanich et al. in their paper:
- Multiple views of visualization of blockchain data: Currently, most visualizations are single-view charts showing a particular blockchain measure over time. These single disconnected views make it difficult to relate multiple blockchain characteristics to each other.
- New visual representations for transaction network and analysis: Existing visualizations present transaction networks and value flows as static graphs at specific points of interest; there is a need for dynamic network visualizations.
- Uncertainty visualization: Sometimes analysis tools may label certain transaction patterns as fraudulent and make false predictions. Any uncertainty in the data should be made evident in the visualization.
- Progressive visual analytics: The blockchain evolves over time — for example, continuous evolution for maintaining clustered Bitcoin entities up to date. There is a need for computationally efficient visualizations and progressive visual analytics for processing large amounts of data from an ever-evolving blockchain.
4. Data Analysis Challenges for Blockchain
Almost every blockchain system uses a key-value store as the underlying data storage mechanism. Key-value stores offer a great amount of flexibility and cost- and space-efficient storage. Although, as we know, key-value stores are optimized only for data with a single key and value; when there are multiple nested key-value pairs, a parser is required. This also makes it inefficient for lookup operations, as lookup requires scanning the entire collection or creating separate index values. Since key-value stores are mostly unstructured, it becomes difficult to put foreign keys which might be needed for looking up values in a lookup or other tables. For data analysis, we often crunch a lot of data and view it from different perspectives and perform a lot of joins or aggregations, and it may become painful if the underlying data store doesn’t offer much support for this. Also, maintaining integrity and consistency among data attributes is a key thing to monitor — since there are no database constraints, it is easily possible to create new attribute names for the same value which might affect maintainability.
5. Data Analytics for Benchmarking Blockchain Systems
One of the prominent applications of any data analytics work is benchmarking. Dinh et al. propose the BlockBench framework for analyzing private blockchains. They present the first benchmarking framework for understanding and comparing the performance of permissioned blockchain systems. In their research, they conduct comprehensive evaluations of Ethereum, Parity, and Hyperledger which present concrete evidence of blockchain’s limitations in handling data processing workloads and reveal bottlenecks — these systems serve as a baseline for further development of blockchain technologies.
Below are the key bottlenecks they report with respect to each of the three blockchain frameworks they analyzed:
- Hyperledger: BlockBench identifies that there is a trade-off in data models. The key-value model of Hyperledger means analytical queries cannot be supported, although it enables optimization which helps answer queries more efficiently.
- Parity: Parity trades performance for scalability by keeping states in the memory. The bottleneck in Parity is not due to the consensus protocol, but due to the server’s transaction signing.
- Ethereum: Ethereum was the more mature of the three systems benchmarked, yet not ready for mass usage according to their findings. Ethereum incurs large overhead in terms of memory and disk usage for data processing.
6. Final Words
This blog focused more on blockchain-oriented data analytics from the perspective of visualization, data modelling, and one of the applications of blockchain-oriented data science, which is benchmarking.
References
- Tovanich et al. (2019). “Visualization of Blockchain Data: A Systematic Review.” IEEE Transactions on Visualization and Computer Graphics.
- Dinh et al. (2017). “BLOCKBENCH: A Framework for Analyzing Private Blockchains.” Proc. SIGMOD.
- El-Hindi et al. (2019). “BlockchainDB — Towards a Shared Database on Blockchains.” SIGMOD.