Guides
Understanding heat
The Firechain network is a shared resource. It is a public good that is available to all users. In order to ensure that the network is available to all users, Firechain uses a dynamic resource sharing mechanism called heat. Heat is a measure of the amount 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. 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.
Understanding Heat
Most blockchains require accounts to pay some sort of fee in order to transact over the network, primarily to prevent spam and misuse of the network's resources. Firechain does not use transaction fees. Instead, we developed the concept of heat which enables the network to operate without economic barriers that can be untenable for a large percentage of the population. Let's explore gas, the fee model used by Ethereum and other EVM-based blockchains, and why we chose to replace it with heat.
Heat vs. Gas
Heat and gas can be thought of as complementary mechanisms, each of which aims to limit resource consumption in different ways. Heat is used to limit the amount of demand that any account can place on the network. Gas is used to limit the amount of resources that a single transaction or block of transactions can consume. Both mechanisms are designed to ensure that access to the network's inherently limited resources is as fair and equitable as possible while also being simple and easy to understand.
What is Gas?
Gas is a resource sharing mechanism that aims to limit the amount of resources that can be consumed by a single transaction or block. Gas is used to limit the amount of computation that a transaction can perform, and to limit the amount of storage that a transaction can modify. It's designed to discourage users from consuming too many resources and restrict the pace of growth of the global state. In order to have a meaningful impact, gas is priced in Ether, an asset whose price is determined in the open market. Both the amount and price of gas can change over time, which makes it difficult to predict the cost of a transaction before it's made. Gas has had the unfortunate side effect of making all types of transactions substantially more expensive as the network has gained popularity.
Who pays for gas?
Any time a transaction is sent to the Ethereum network, it must include an amount of gas which is a transaction fee denominated in Ether and paid by the sender. Part of this transaction fee is paid to the miner who includes the transaction in a block, who can use that revenue to pay for the real-world resources (e.g. electricity and specialized hardware) they consumed in the process of producing the block. The rest of the fee is burned, meaning it is permanently removed from the supply of Ether which reduces the token's rate of inflation. Charging the sender of a transaction the gas fee is Ethereum's way of ensuring that the network's resources are not being wasted on spam or malicious activity.
What is Heat?
Heat is a dynamic resource sharing mechanism that replaces the concept of gas and 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 necessarily aligned with the value of storage space, computational complexity, or any other particular network resource, but they serve as a proxy for the amount of work required to process a message. Some number of Scovilles are generated when an account interacts with the network, and they dissipate over time. Because saying the word "Scovilles" gets old fast, we simply call it heat most of the time.
If you're curious about the name, it's a reference to the Scoville scale, which is a measure of the spiciness of peppers. Feeling brave? Challenge yourself to discover your personal heat tolerance by climbing the Scoville scale. Pro tip: don't eat the seeds.
Who pays for heat?
Trick question! Heat is not a fee, tax, or any other type of direct economic cost. It is a free, open, and fair resource sharing mechanism that is designed to ensure that the network is available to all users. Legitimate users can generate as much heat as they need to use the network, and the network will reject any transactions that would cause an account to exceed its heat tolerance. It's not a cost, it's a limit.
Every account is responsible for its own actions and not those of other accounts. If an account sends a message to another account, it is responsible for paying the heat cost of that message. If the receiving account generates messages of its own in response, it is responsible for paying the heat cost of those messages. This means that the heat load of a two-way interaction is shared between the two accounts involved. This is different from Ethereum's gas model, where the sender of a transaction is always responsible for paying 100% of the cost of any transaction it sends.
What about unwanted messages?
If an account sends a message the receiver doesn't want, the receiving account can simply ignore the message. The sender is still responsible for the message's heat, but the receiving account does not have to use its own capacity for receiving it. Smart contracts can implement their own logic to handle unwanted messages. For example, a contract can implement a whitelist of accounts that are allowed to send messages to it. If a message is received from an account that is not on the whitelist, the contract can simply refuse it.
This is similar to how unwanted interactions are handled in the real world. For example, anyone can have an unsolicitated offer delivered to your mailbox, even if they know for a fact that you don't want it or know literally nothing about you. The sender is obligated to provide postage, but you're not obligated to open the envelope or respond in any way.
We see this as a fair and equitable way to share access to the network's resources. It encourages users to be conscious of the heat 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 more reliable. This is a powerful incentive for developers to build in a way that efficiently utilizes the network's resources.
Protecting the Network
You might be wondering how this model protects against spam or other types of malicious activity. The short answer is that it doesn't. Heat is designed to ensure that the network is available to all users, not to enforce arbitrary standards on value, quality or importance. It's a resource sharing mechanism, not a censorship mechanism.
Not the speech police
Heat is not some sort of moral compass, and it isn't designed to prevent speech or personal expression. It's a resource sharing mechanism that helps to ensure that the network is available to all users. This is a very important distinction: heat's job is to ensure that the network is equally available to all users, and it's the job of the network's governance mechanisms to prevent abuse. Heat is a tool to help the network operate efficiently, not to censor or punish anyone.
If an account is spamming the network, it will quickly reach its heat tolerance and be unable to send any more messages. This will cause the spammer's messages to be rejected by the network, which will prevent the spammer from consuming any more resources. Gas is designed to limit spam by making it prohibitively expensive to send a large number of low-value transactions. Heat is designed to limit spam by throttling an account's maximum throughput. Neither mechanism can totally prevent spam, but they both make it more difficult and costly to have a meaningful impact on the network.
Heat Tolerance
Every account has a heat tolerance which is a measure of the amount of demand that it can place on the network within a rolling time period. An account's heat tolerance modulates the degree to which it can utilize the network's resources. Almost everything an account does generates heat, and the network will not accept work on an account's behalf that would cause it to exceed its tolerance. This prevents any one account from placing too much demand on the network.
Generating Heat
Heat is generated when an account sends a message or executes logic in response to a message. The heat generated by a message is proportional to the size of the message, and the heat generated by executing logic is commensurate with the complexity of the code and any state changes it makes. For example, a message that transfers tokens will generate less heat than a message that deploys a contract because the former can be done with an empty body while the latter must include the contract's bytecode. Similarly, executing a simple function that only reads from storage will generate less heat than one that reads data, modifies it and writes the updated contents to storage.
Dissipating Heat
Accounts "cool off" over time. Nothing needs to be done to cause this to happen, it is totally automatic. The rate at which an account dissipates heat starts at the default of 1 H/s (one unit of heat per second) and can change over time. This is called heat decay, and it is specific to each account. The heat decay of an account is the amount of heat that is removed from the account every second. The heat decay of an account is determined by the account's past behavior. It's always greater than or equal to 0, and it is always less than or equal to the heat tolerance of the account.
Right now, every account cool off at the same rate, but in the future we plan to implement a system that allows accounts to cool off at different rates based on their past behavior. This will enable the network to apply higher or lower rates to account for different types of behavior. This way, the more an account behaves in a way that is consistent with the network's goals, the faster it will cool off. The more it violates the network's rules, the slower it will cool off. This is a powerful incentive to help keep accounts with the network's goals.
Down the road, the decay rate may consider things like:
- AGE: account's age in seconds, capped at 1 month;
- TOTAL_HEAT: account's total historical heat generation, capped at 1 month;
- HEAT_PER_DAY account's average heat generation per day, capped at 1 month;
- HEAT_TOLERANCE: account's average heat tolerance over the past 30 days;
- COUNTERPARTIES: number of unique accounts that have interacted with the account over the past 30 days;
- FOULS: number of times the account has been penalized for violating the network's rules since the account was created;
- STAKE: amount of value staked by the account over the past 30 days.
Future Work
We're confident that we've found a good balance between simplicity and flexibility, but the system still needs a lot of tuning and testing. We're going to be iterating on the heat model as we see how the system performs in the wild, and we'll be relying on feedback from the community along the way.
We're currently working on a tool that allows developers to simulate the effects of different heat models which will help to better understand the trade-offs, and it will help contract developers to understand how their contracts will behave in different scenarios. The compiler can also estimate the heat generated by functions which can help developers understand their contracts' heat profiles and make informed optimization decisions.
We're also working on a tool that allows users to visualize their heat profiles and see how their heat tolerance utilization changes over time. This will help users to understand how they can optimize their behavior to get the most out of the network, which might include things like changing their stake or sending fewer messages.
Conclusion
Heat is a powerful feature that enables Firechain to become a network that is open and available to everyone, regardless of their economic status. It's a simple and elegant solution to the problem of network congestion, and it's a natural incentive for developers to build applications that are efficient and scalable. It's not perfect, but we're confident that it's a good starting point. We're looking forward to the community's feedback, and we're excited to see how it evolves over time.