Guides
HotDAG Ledger Model
The HotDAG ledger model is a novel approach to building a decentralized ledger. It's a hybrid between a blockchain and a directed acyclic graph that's designed to be fast, scalable, and secure. The HotDAG ledger model is the foundation of Firechain's architecture. It's designed to be flexible, so it can be used to build any type of decentralized application or network.
What is a DAG?
A directed acyclic graph (DAG) is a data structure that consists of a set of nodes and edges. Nodes represent data or objects, and edges represent relationships between the nodes. A DAG is a directed graph, meaning that edges have a direction, and acyclic, meaning that there are no circular relationships between nodes. DAGs are used to represent a variety of data structures.
The DAG is a useful data structure for modeling complex relationships between objects. For example, you can use a DAG to model a social network, where nodes are users and edges are friendships. You can also use a DAG to model a file system, where nodes are files and edges are directories. DAGs are also useful for modeling ledgers, where nodes are transactions and edges are dependencies between transactions.
What is HotDAG?
HotDAG is a hybrid between a lattice-type DAG and a blockchain that we call the lattice-chain. It combines the speed and flexibility of a DAG with the security of a blockchain, and it's designed to be fast, scalable, and secure. At a high level, it's a graph of accounts connected by their interactions. It's a directed acyclic graph, meaning it has a (linear, temporal) direction and it's not possible to have circular dependencies. This means that you can reach any point in the graph by traversing the graph forward in time, starting from the genesis block, or backward in time, starting from the latest block.
In the diagram above, each colored line represents an account chain, and the vertices along them represent that account's transactions. The curved connectors between vertices represent transactions from one account to another. The center lane represents the global state chain. The global state chain is a special chain that tracks state changes across the entire network and serves as the ultimate source of truth.
You might notice that, on their own, account chains look a lot like blockchains. That's because, essentially, they are blockchains. The HotDAG ledger is modeled as a lattice of blockchains, where each account has a dedicated account chain, and a global state chain ties them all together. In this way, HotDAG leverages the best of both worlds: the robustness of blockchains and the scalability of DAGs. Having a strong separation of concerns at the account level enables fast and efficient state synchronization, and the global state chain provides a mechanism for enforcing account consistency across the network.
The global state chain
The global state chain keeps track of the state of the network by observing account activity and maintaining a changelog of state changes. It's a special chain that's not tied to any particular account, and it's the ultimate source of truth for the network.
Each block in the global state chain contains a log of state changes that occurred across the network since the previous block. The global state chain is a single chain that's common to all accounts, and it's the only chain that's required to be fully synchronized by all nodes at all times. This adds a layer of security to the lattice structure by ensuring that account chains, and therefore the state of the network as a whole, remain consistent once consensus is reached.
Because the HotDAG lattice consists of account-specific chains, it's possible to process transactions in parallel—so long as they don't interact with the same account. This allows for a highly efficient consensus mechanism highly optimized for scaling, which means it's capable of handling massive demand. The HotDAG provides a high degree of flexibility, so it can be used to build any type of decentralized application or network.
Account chains
Account chains are the foundation of the HotDAG ledger model. They're blockchains that are specific to a particular account, and they're used to track the state of that account. Each account chain is a separate blockchain that's independent from the other account chains. This means that transactions in one account chain can be processed in parallel with transactions in another account chain. Each account chain works more or less like a segregated blockchain, and they can only process transactions in a synchronous, linear manner.
Only actions that are performed by an account are included in that account's chain. For example, if Alice wants to send Bob some money, she does so by including a transaction in her account chain. Bob can send a request to Alice, which will be added to his own chain, and if Alice later decides to accept the request, she can add a transaction to her chain that effects the transfer to Bob. There's no way for Bob to append an entry to Alice's ledger that isn't signed by her account, and similarly there's no way for Alice to directly modify Bob's account chain. In other words, account chains are completely segregated from each other, and they can only be appended with entries signed by the account that owns them.
In general, accounts process requests in the order they're received. However, there are no rules that specify that this must be the case, and dApp developers have a great deal of control over the settlement process. For example, an application may require a minimum number of global state chain confirmations before they'll process an inbound transaction. This is particularly valuable in cases where it's necessary to have a high degree of confidence that a transaction is irreversible, like moving funds through the traditional banking system, or settling a physical asset transfer.
Delegation and pre-approvals
The notion of approvals is somewhat different here than on networks like Ethereum, but the concept and impacts are quite similar. At a high level, there are three ways to authorize remote spenders on Firechain: spend requests, delegated authorities, and logical authorizations. Spend requests are the most basic form of remote spending, and they're used to authorize a remote spender to spend (up to) a specific amount of tokens from an account over any number of transactions. Delegated authorities are signature-based permits that authorize a remote spender to spend tokens from an account, but can only be used once. Logical authorizations are programmatically controlled and can specify arbitrary conditions and limits. These are the most powerful form of remote spending, and they can be used to implement any type of authorization scheme.
Spend requests: A spend request is a request to use funds held by an account. They can be sent to any account, and they're always subject to approval by the account owner. Approved spend requests remain valid until they expire, are revoked, or are exhausted (i.e. when the approved amount has been spent).
Delegated authorities: Delegated authority works more like a signed permit. It's a way for an account owner to delegate authority to another account to spend funds from their account by providing a valid signature, rather than approving an on-chain spend request. Delegated authorities are more flexible than spend requests, because they can be used to initiate a transfer on an account owner's behalf at any point up until expiration, but they're also more limited because they can only be used once. The only way for a delegated authority to become invalid is if it expires or is used to initiate a transfer; there's currently no way to revoke a delegated authority once it's been issued.
Logical authorizations: Logical authorizations allow an account to authorize a remote spender to spend its funds as prescribed by a set of conditions and limits that must be met in order for the transfer to be valid. This type of approval is extremely powerful, and it can be used to implement complex authorization schemes, including those that are based on time, location, or other arbitrary conditions. They offer the most flexibility, but they're also the most challenging to implement.
Both spend requests and delegated authorities can be open (unlimited) or capped (e.g. 1000 sparks), and they always have explicit expirations. Logical authorizations rely on programmatic approvals, rather than externally defined rules like caps or expirations.
Finality
Requests are considered finalized once they've been included in a global state chain block that's accepted by the network, which is usually about a second after it's proposed. However, it's important to note that finality in this sense refers to the point at which a request is probabilistically irreversible, which is not necessarily the same as the time it takes for the transaction to be fully processed by its receiver. For example, if Alice sends Bob 100 sparks, the request is finalized once it's included in a global state chain block, but it's not actually complete until Bob accepts the transfer. Bob may choose to accept the transfer immediately, or he may choose to wait a while before accepting it. In the latter case, the request will remain in a pending state until it's accepted, and it's possible for Bob to reject the transfer or for Alice to reverse it at any point before it's accepted.
In theory, a request should be final once it's been included in an account chain. In practice, it's possible for a transaction to be included in an account's chain but later be invalidated at the global consensus level. One might initially think of this as a problem, but it's actually a feature that allows for developers to make informed trade-offs where appropriate for their particular use case. For example, a developer might choose to require a minimum number of global state chain confirmations before processing a transaction, or to process it as soon as possible. Neither approach is inherently better than the other, and Firechain empowers developers to decide what's best for their applications.
It's not strictly required for a request transaction to be included in the global state chain in order for it to be processed by the receiving account, but it might be prudent to wait for global confirmation before processing some types of requests. This is especially true where doing so involves some form of off-chain handling, such as in our earlier example of an off-ramp that converts on-chain assets into fiat currency. For purely on-chain handling, it's not necessary to wait for global confirmations. This is because all downstream transactions are dependent on the validity of the original request, and they'll be rolled back if the request is invalidated. In other words, if a request is invalidated, all downstream transactions will be invalidated as well, and any account that was touched will be rolled back to the last known state.
Rolling back transactions
When a request is invalidated through consensus, any downstream executions that reference it are rolled back because they depend on an invalid state transition. This is a feature, not a bug. It effectively prevents malicious actors from forcing the system into an inconsistent state, and it's quite similar to the way that popular blockchains like Ethereum resolve chain reorgs and reverted transactions.
For example, a malicious validator might attempt to propagate a transaction that violates the rules of consensus. He may even be able to bribe other validators in the same consensus group to include the transaction in their copies of an account's chain. However, the transaction will be rejected by the global state chain because the state transition it's effecting isn't valid and consensus wouldn't be reached. This means that the transaction will never be included in the global state chain, and it will never be considered final.
This type of attack is both risky and self-limiting, but it's a valid threat nonetheless. It's risky because it requires the malicious actor to successfully bribe at least 2/3 of the validators in the local consensus group, and failing to do so all but guarantees a complete loss of the briber's stake. It's self-limiting because, ultimately, the invalid state changes still won't make it into the global chain. This means that the attack is only effective if the validator is able to bribe a qualified supermajority (i.e. more than 2/3) of the network's validators at once, which puts each of their stakes at risk. While this is exceedingly unlikely, it's important to consider the degree of finality your use case requires and to design your application accordingly.
At a high level, this is fairly similar to how other blockchains handle finality. But rather than arbitrarily defining "final" to mean "included in a block," Firechain doesn't enforce any minimum confirmation thresholds. Instead, it's up to the application developer to decide what degree of confidence in a transaction is necessary for its own purposes. This approach allows for a lot of flexibility and enables the HotDAG to be used to build any type of decentralized application or network, and for developers to make informed trade-offs where it makes sense.
HotDAG vs. other DAGs
DAGs have been used in other blockchain projects as a way to increase scalability and reduce latency. However, they're not without their drawbacks. For example, DAGs are inherently more complex than blockchains, and they're more difficult to reason about. This makes them more difficult to audit. DAGs also tend to be more susceptible to certain types of attacks, such as double spends and reorgs. Some projects that use DAGs include IOTA, Nano, and Byteball.
HotDAG vs. IOTA
IOTA is a Proof-of-Work DAG-based cryptocurrency that uses a Tangle instead of a blockchain. The Tangle is a directed acyclic graph that's used to track transactions in a UTXO-based ledger model. Each transaction in the Tangle references two prior transactions in a pay-it-forward system that's designed to strengthen the network's security by continually building on top of the most recent transactions. The Tangle is a single chain that's common to all accounts. IOTA recently introduced ISC, a basic smart contract framework that proposes to eventually support "on-tangle" logic. It uses a UTXO-based transaction model, which makes it challenging to design real-world applications that require complex state transitions.
HotDAG doesn't use a Tangle, and it doesn't use a single chain that's common to all accounts. Instead, it uses a HotDAG that's made up of account-specific chains. This means that transactions in one account chain can be processed in parallel with transactions in another account chain. HotDAG also uses an account-based model, rather than UTXOs, and it is designed to support complex state transitions at the account level. HotDAG is generally more powerful than IOTA due to its robust support for on-chain logic.
HotDAG vs. Nano
Nano is another a Proof-of-Work network that is credited as being the pioneer of the block lattice DAG structure. The block lattice is an account-based DAG that's used to track account activity. Each account in the lattice is segregated, so it's possible to process transactions in parallel. The block lattice is inherently more susceptible to double spends and reorgs than a blockchain, and it's also more difficult to reason about. Nano doesn't have any real support for decentralized applications or complex logic.
HotDAG was strongly influenced by Nano's block lattice model, but it introduces a number of improvements that make it more flexible and more secure. For example, it uses a global state chain to strengthen security by mirroring important changes to accounts in the network. Both Nano's block lattice and the HotDAG model are account-based, rather than using UTXOs. Whereas Nano doesn't offer much in terms of programmability, HotDAG is designed to support complex state transitions at the account level. Overall, HotDAG is able to support a much broader set of real-world use cases than Nano.
HotDAG vs. Obyte (Byteball)
Obyte (recently rebranded from Byteball) is another UTXO-based cryptocurrency that uses a generic DAG structure to track transactions. Each transaction in the Obyte DAG references one or more prior transactions, and the Obyte consensus model incentivizes users to build on top of the most recent transactions in order to strengthen the network's security. Obyte supports two types of logic-based actors: smart contracts and autonomous agents. Smart contracts in Obyte are not particularly similar to the common notion of smart contracts on other DLT platforms; they're used to describe conditions for the settlement of transactions between two parties. Autonomous agents are more similar to the typical definition of a smart contract, and they're used to define logic that's triggered whenever they receive a transaction.
HotDAG shares some commonalities with Obyte, but it's also quite different. HotDAG's lattice-chain model is more flexible than Obyte's DAG model, and it's also more secure. HotDAG's global state chain mirrors important changes to accounts in the network, which dramatically reduces the risk of account chain reorgs without requiring additional activity to extend any particular DAG path. HotDAG is account-based, which makes it easier to reason about than typical UTXO-based models, as well as a lot more flexible. For example, whereas Obyte offers simple conditional transaction settlement and tightly constrained on-chain logic, HotDAG is a dynamic, event-driven platform that's designed to support complex state transitions at the account level in response to transactions, on-chain events, and time-based triggers.