HackMDIntroducing Firechain
tags: Introduction Overview
Firechain is an asynchronous decentralized application platform designed to power the open economy. It's built on top of the Firechain Async VM (AVM), a Turing-complete virtual machine capable of executing complex logic in a controlled, deterministic environment. Pyro is our async-first dApp development language that's designed to be intuitive and familiar to both Web2 and Web3 developers. Firechain is similar to other smart contract platforms like Ethereum, Cosmos, Solana, or Polkadot, but there are some key differences that set Firechain apart.
NB: The Firechain network is currently in a pre-release stage, and it's not yet open to the public. The entire Firechain platform is intended to be open-source, however we're currently working hard to get it ready for launch and we're not quite ready to open it up to the world. We're excited to share our progress with the community in the coming months, and we'll be releasing more details about the Firechain platform as we get closer to launch.
Platform Highlights
The architecture of the Firechain network unlocks powerful new capabilities that most other blockchains simply can't offer, like no-fee transactions, instant finality, provably secure on-chain randomness, scheduled execution, on-chain event listeners, automation, prioritization, and so much more.
The Async VM
The Async VM (AVM) is our flagship innovation, and it's designed to power the next generation of decentralized applications. It's similar to Ethereum's virtual machine (EVM) in many ways, but it's not a fork of the EVM and it introduces unique concepts that require a slightly different way of thinking when building decentralized applications.
NB: Because Firechain was initially designed to be compatible with the EVM, we extended the Solidity language to create a language (called Fluidity) that accommodated the async design of the platform. Over the course of development, we've moved away from Fluidity and designed an async-first contract language called Pyro.
Most Solidity contracts can be compiled directly to AVM bytecode using the Fluidity compiler, and they'll generally work as designed. However, the async design of the network might introduce some "gotchas" that multi-contract dApps need to consider which may lead to some design changes.
How it works
The AVM is a full-featured virtual machine with a rich set of instructions that can execute complex logic in a deterministic and trustless environment. The instructions are designed to be as simple as possible, so they're easy to understand and reason about. In the AVM, like in other popular blockchain VMs, a call stack is used to store ephemeral states and control the flow of execution.
Unlike other smart contract platforms, the AVM doesn't use a global stack. Instead, each account has its own execution stack, and each message is executed on its own account's stack. This means that the network can execute messages asynchronously, and each of those executions can further spawn reactive executions elsewhere in the system. It also allows contracts to schedule code to run at a specific time in the future, which opens the door to a wide range of use cases. It's easy to see how this model adds utility that the synchronous execution engines of other blockchains simply can't offer.
Transactions that trigger code execution can spawn downstream reactive executions, which in turn may spawn more reactive executions, and so on. This is due to the event-driven nature of the system, and it's one of the most powerful features of the AVM. It allows developers to build complex systems that can react to arbitrary events in real-time, and it opens the door to a wide range of use cases.
Why it matters
The AVM's async architecture allows for an inherently more efficient and scalable network. It provides on-chain event listeners and scheduled execution, which enable a wide range of powerful design patterns. It also opens the door to provably secure on-chain randomness. Event-driven patterns are difficult or impossible to implement on other blockchains because of the synchronous nature of smart contract execution. The event-driven design of the AVM enables advanced use cases like reactive execution, portfolio automation, real-time arbitrage, and dynamic governance, and it goes without saying that on-chain randomness has been on every dApp developer's wishlist since smart contracts were first introduced.
No-Fee Transactions
Firechain is designed to be a public good that is freely available to all users, and we don't charge transaction fees or "gas" to engage with the network. Instead, Firechain uses a dynamic resource sharing mechanism that tracks of the level of demand that an account has placed on the network recently. Accounts generate heat when they interact with the network, and that heat dissipates over time. In this way, heat acts as a form of congestion control, ensuring that the network is available to all users by limiting the amount of demand that any one account can place on the network.
How it works
Heat is a dynamic resource sharing mechanism that replaces the concept of fees within the Firechain ecosystem. It is designed to act as a form of dynamic rate limiting to ensure that the network is available to all users by limiting the amount of demand that individual accounts can place on the network. Accounts generate heat by doing things like transferring tokens, deploying contracts, and calling functions. Heat automatically decreases over time, and accounts are limited in the amount they can generate. That limit is called the heat tolerance, and it's specific to each account. The network will reject any transactions that would cause an account to exceed its heat tolerance. This prevents any one account from placing too much demand on the network.
Firechain measures heat in scovilles. Scovilles are not perfectly reflective of the value of storage space, computational complexity, or any other particular network resource at this time, but they do serve as a proxy for the amount of work required to process a message. Some number of Scovilles are generated by opcodes within the AVM. Because saying the word scovilles gets old fast, we simply call it heat most of the time.
Every account is responsible for its own actions and not those of other accounts. If one account sends a message to another, it is responsible for paying the heat cost of that message. The receiving account may generate messages of its own in response, and the receiver is responsible for the heat of those messages. This means that the heat load of a two-way interaction is equitably shared between the two accounts involved. This is different from the typical fee-based GAS model popularized by Ethereum, where the sender of a transaction is always responsible for paying 100% of the cost of any transaction it sends.
Why it matters
We see this as a fair and equitable way to share access to the network's resources. It removes economic barriers to entry while still encouraging users to be conscious of the "cost" of their actions, and it pushes developers to build applications that are efficient and scalable. Contracts that generate excessive heat will have to stake more and more as activity grows to keep from hitting their heat tolerance, and users will be encouraged to use more efficient contracts because they're simply more reliable. This creates a powerful natural incentive system for developers to build in a way that efficiently utilizes the network's resources.
DAG-based Ledger
Firechain's HotDAG ledger model introduces a novel approach to building decentralized ledgers. It's 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. Every address—both user-owned accounts and dApps—essentially has its own ledger. Each entry represents exactly one transaction and refers to the hash of a previous entry.
How it works
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.
Every Firechain transaction is divided into two parts—a request and response—similar to the way web requests work. Once a request is received, it is permanently recorded to the account's ledger, a context-dependent execution is queued, and the response is generated asynchronously. This decoupling allows the network to handle far more concurrent activity than most other DLT frameworks.
In the diagram above, each colored vertical lane represents an account chain, and the vertices (circles) along them represent that account's transactions. The edges (curved connectors) between the vertices represent transactions from one account to another. The center lane represents the global state chain.
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-style DAG embedded with special purpose chains, 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.
Why it matters
Firechain's HotDAG enables asynchronous execution across account chains, which makes it possible to process and confirm transactions in parallel—so long as they don't interact with the same account. This model is not only dynamically scalable, it also allows for more efficient consensus. That means Firechain is capable of handling massive, ever-growing demand. The HotDAG provides a high degree of flexibility, so Firechain can be used to build any type of decentralized application. In particular, HotDAG opens the door to high-demand applications that are currently infeasible on most networks, including things like high-frequency trading engines and social media products. In fact, these are two of the primary use cases we've designed around.
Group-based Consensus
Firechain uses a layered DPoS consensus mechanism wherein validators are assigned to consensus groups that are responsible for a subset of the network's accounts for a certain period of time. Validators in the group are tasked with processing messages sent from or destined for that set of accounts, which might include executing logic on their behalf. At the local level, validators process messages and propose account-level state changes. Global validators record the interactions between accounts, which includes routing messages to the appropriate validator group for the receiving account. Validators can choose to participate in either selective or global consensus, which means highly successful projects can scale almost independently of the network as a whole.
How it works
Validators stake to become bonded and earn the right to participate in consensus, and those found to be out of integrity—for example, attempting to reorganize history or make invalid state changes—are subject to penalties up to and including the loss of their bond.
You can think of a local consensus group as a sort of self-contained shard that is responsible for a subset of the network's activity. Rather than validating messages for the entire network, consensus groups are responsible for validating messages for a given set of accounts. Because consensus groups are only responsible for validating messages that are relevant to a small portion of the network, they can be managed independently of the rest of the network and commit more concise state updates to the global state. This makes it possible for Firechain to handle a much higher level of activity than would be practical with a single global chain that represents the entire network, and it can do so without sacrificing security or finality guarantees.
NB: By default, validators are part of the global consensus group, which means they agree to process transactions for any participant of the network. Validators may instead choose to only process transactions for whitelisted addresses (or to exclude those from a blacklist). This is called a selective validator, and the most common use case is to support indepent scaling of specific projects. Selective validators aren't eligible for protocol-level rewards, but the decentralized apps they support can implement various forms of incentivization if they choose.
Why it matters
Firechain's group-based consensus model makes it possible to support seamless, targeted scaling with account-level granularity. It also enables a wide range of specialized use cases, like private applications whose functionality and/or state are restricted to whitelisted accounts. For instance, it can provide dedicated support for a regulated on-chain exchange that requires KYC or OFAC-type screening.
