How Constellation is Different Than Blockchain
Over the past few years, Blockchain technology has taken the world by storm. It has been extended to a broader category of Distributed Ledger Technology (DLT). Constellation proposes an enterprise grade DLT that is scalable, secure, and inclusive. We recently published a detailed business whitepaper discussing our technology. In this post, we dive particularly into how the technology in Constellation is different than a traditional Blockchain.
In a Blockchain network, hundreds of thousands of computing devices create a distributed network without inherently trusting each other. They reach consensus about the shared data through unique mechanisms and ensure that once the consensus is reached, the data is tamper-proof. This allows the devices, otherwise known as nodes in the network, to transact, i.e. send tokens to each other. Tokens are the unit representation of the value created by the network, and fuels a shared economy in a secure digital network.
The technology behind Blockchain is ingenious. The transactions sent among the nodes are bundled together into Blocks of data. These blocks are chained in a fashion that the cryptographic hash of a previous block is included in the next block — making the entire Blockchain tamper-proof. A transaction is valid when the sender has enough tokens to send that transaction — analogous to having enough money in a bank account before sending someone money. Understandably, only valid transactions are allowed to be included in the block data. Since it is a network of nodes that virtually do not trust each other, transactions deemed valid by the majority of the nodes are selected to be valid. In a Blockchain network, this forces each transaction to be sent to every node, and requires a way to incentivize each node to do the right thing. The Bitcoin network famously mandates each node to solve a cryptographically challenging puzzle to provide the proof of honesty — tuned in a way that it does not make sense for a node to both burn enough electricity to solve the hard puzzle as well as act maliciously.
Regrettably, this entire process is too slow to be suited for mass adoption. Users are accustomed to Internet applications that are massively distributed with hundreds of thousands of concurrent users — transactions need to be verified in a matter of seconds, instead of hours. Constellation proposes a novel mechanism to improve upon the Blockchain technology with decades of learning from the scalable distributed technology. In this post, we would discuss some key ways Constellation is different than what is typically conceived as a Blockchain.
Network of Nodes
Like any standard Blockchain network, Constellation consists of a set of nodes that assumably do not trust each other. However, as in real life, some nodes may actually trust some other nodes — maybe they are from the same organization, or some nodes are globally trustworthy because of their branded reputation. Constellation takes this trust into the consensus mechanism in a unique way — more on that in the later sections.
In a mining-oriented Blockchain, each participant has two potential roles to play — a user who mostly transacts tokens, or a miner who mostly mints new tokens. This often results in a two-directional economy inside the network as their incentives may not always align. Also, the power in a Blockchain, especially one that requires computationally heavy mining, gets concentrated to the nodes that are computationally strong and backed by financially powerful entities. Constellation, on the other hand, eliminates the mining mechanism and is open to all types of devices, from low-key mobile devices to high-end servers.
In Blockchain, each node is not necessarily directly connected to all other nodes — as it is with Constellation. When needed, a node sends a transaction to a handful of connected nodes (usually less than 10), and the transaction is spread through a gossip protocol. In Constellation, transactions are also spread through the network by a unique gossip protocol, but not necessarily to all nodes in the network. The data flown also bears more complexity, but more on that later.
The distance among the nodes bears importance in Constellation. The distance is defined by multiple factors, such as the geographic distance along node IPs, transitive distance of trust imposition (more on trust later), and repeated communication. When a transaction is submitted, it is gossiped to different parts of the network defined by this distance, so that the randomness and the complex distance factor minimizes the possibility of collusion among the nodes to verify a particular transaction.
Data flow in the network
In Constellation, data flows in bundles. Any unit of data in Constellation is a Bundle and Bundles are differentiated by rank. A transaction is a rank-0 Bundle, a checkpoint block is a rank-1 Bundle and Bundles after rank-1 are referred to as a ‘rank-n Bundle’. A bundle of size n includes a set of bundles of rank n-1. As the term Bundle naturally evokes the idea of items bundled together. In the case of transactions, we can think of them as a fiber, or as the single indivisible unit of data. Bundles of rank n>= 1 are formed from a collection of unconfirmed data of preceding rank taken from a mempool, signature data for those transactions, and reference to two other Bundles of the same rank. The signatory data includes the information (timestamps, node identifiers etc.) about all nodes that sign the transactions.
Blocks in a traditional Blockchain vs Constellation’s Bundles (seen here as checkpoint blocks)
A Bundle is reused multiple times as a pointer from one Bundle to another. We call number of acceptable reuses the ‘tip factor’. As Bundles are observed and gossiped around, its hash will inevitably change between the reuse. Keeping in mind the data and network optimization, we store these different versions of Bundle hashes as observation edges. One way to visualize observation edges are as leaves in a trie with the bundle being the parent. The trie itself is part of the Directed Acyclic Graph (DAG) of observations — also called the observation-dependency DAG (OD-DAG). The observation edges originating from a bundle form a trie, embedded inside the DAG data structure of OD-DAG.
A snapshot is a special kind of bundle that includes data and pointers to all previous bundles till the earlier snapshot. Snapshots give a clear view of the state of the network at any given point, and the goal of the protocol is to ensure consistent snapshots across the network.
Being a node
Since not all nodes in Constellation are required for verifying every transaction, they run asynchronously with data flown through them. Each node has three key steps:
- Gather: The node continuously gathers data bundles from neighbor nodes it is connected to.
- Apply: It then reads the incoming bundles. The signatory data, along with the timestamps included, gives the node a unique view of the neighbor nodes and their distances from it. The node then uses the bundle to as a ‘tip’ to sign the incoming bundles in a way that the data dispersion is optimal over the network. If the node finds a conflict in the data in that process, a conflict resolution process is triggered (more on that later).
- Scatter: Once the new bundles are created, they are sent across new nodes across the network through the gossip protocol.
Reputation of a node
The reputation of a node in a Blockchain network is often tied to its computational (proof-of-work), financial (proof-of-stake), or political (delegated-proof-of-stake) power. Constellation, on the other hand, ties the reputation to its behavior to the network and is relative to other nodes. Constellation proposes Proof of Reputable Observation (PRO), a novel reputation-based mechanism to incentivize nodes to act honestly.
Constellation associates a global reputation score to every node in the network. The score is calculated with a machine learning algorithm that takes into account the behavior of the node to the network. On top of that, each node can impose trust on other nodes based on, possibly, off-chain information. The node may choose to declare this trust to the network or keep it to itself.
It is important to note that the consensus mechanism in Constellation does not trigger with each transaction. Instead, when a node finds a conflict in some data, a conflict resolution mechanism is triggered that acts as the distributed consensus among the nodes. When choosing between two pieces of conflicting data, the node takes into account the reputation scores of the nodes who observed and signed that data, thus providing a proof of reputable observation. It also takes into account the trust flow across the nodes when deciding on the data, thus not solely depending on the global score.
How does a node verify a transaction?
Verifying a transaction simply means ensuring that the sender of the transaction has sufficient fund to initiate the transaction.
In a Blockchain, verifying a transaction is relatively easy for a node. A node has the entire Blockchain data. Hence, it is fairly straightforward to do a reverse-search of the transactions of the sender to find out if the sender has sufficient funds for initiating the transaction.
In Constellation, since nodes may not always have the entire state of the network, verifying a transaction is not as obvious. A node, according to the relative ordering of incoming data, picks a transaction from the mempool of unverified transactions or a regular block that requires more signature data. The node then looks for the snapshot data it has access to. If the snapshot data can confirm the validity of the transaction, the node marks the transaction has valid, signs it and puts it in the observation block before scattering it away. However, if it can not confirm the validity, depending on the computational power and ability of the node, it may simply sign and scatter away the transaction for someone else to validate it (thus merely providing an observation to the transaction). Otherwise, it can also send request for more snapshot data from reputed nodes with more data.
When does a transaction become valid?
In a Blockchain, once a transaction is included in a block with a valid nonce (proof of work by the node announcing the block), the block gets attached to the chain of previous blocks and the transaction (along with other transactions) in the block is deemed to be valid and notarized.
In Constellation, it works in an asynchronous fashion over the nodes in the network. A transaction is broadcasted to a set of nodes, gets verified, and gets included into blocks fairly quickly because of the asynchronous nature of the gossip protocol. When enough signatory data about the transaction is gathered into the block and it turns into a checkpoint block, the transaction is deemed to be valid. Since the checkpoint block (or rather the observation block version) is pointed to by other checkpoint blocks, this validity gets notarized and becomes tamper-proof.
In conclusion, the Constellation borrows from the best of both the worlds — traditional single partitioned Blockchains and decades of research in scalable technology. We will keep more updates on our technology coming as we continue performance testing and iterate testnet development.
Interested in becoming part of the Constellation network? We are looking for node operators who will host some of the early nodes on the network (in a testnet environment). You’d be providing valuable feedback, and earning $DAG tokens for doing so. You can register to run a node here.
Become a Constellation Member
Participate in our Community
- Join our Discord Channel
- Join our Telegram Community
- Join our Facebook Group
- Follow us on Twitter
- Chat with us on Reddit
Check out our Technology
Stay Educated
Originally published at Constellation Labs Blog.
