In the past few days, there has been a sharp spike in the number of pending transactions on the Stacks blockchain (> 3000 as I’m writing this). A few different factors came together to create a perfect storm of mempool congestion. In this post we share some observations and specific next steps as far as Hiro’s products are concerned.
How we got here
- There’s a known issue with how the current miner software walks the mempool, that does not properly factor in transaction fees and only considers the origin account nonce: this ends up penalizing origin accounts with high nonce values. A fix is under review in this PR.
- Block limits and various cost-related constants were set with conservative initial values in Stacks 2.0. There are several known improvements related to cost-tracking in Clarity — most of them are slated for Stacks 2.1 and a lot of work has been underway. However, with the basic cost-estimates set in Stacks 2.0 and presumably most miners running the default miner software (which undoubtedly has a lot of room for improvement and sophisticated strategies), miners end up over-estimating the compute budgets — this acutely manifests itself in contracts like Stacks Punks. In the public blockchain meeting earlier today, it was reported that roughly two thirds of recent transactions exceeded the runtime compute budget, while the remainder exceeded the read_count budget.
- Most of these transactions originate from the Hiro web wallet, which currently does not support Replace By Fee (RBF) — a mechanism to rebroadcast transactions with a higher fee. This means once users sent a transaction, and if the network was already congested, they did not have any recourse to try and get their transaction processed.
These factors put together make it impossible for an efficient “fee market” to exist for transactions on the Stacks blockchain right now: it’s not easy for users to set or choose higher transaction fees, the default miner software doesn’t properly take fees into account and some Clarity contracts gaining in popularity are pushing against the conservative default cost estimates in Stacks 2.0.
What happens next?
- Miner improvements: as mentioned above, there is a PR in review. This was also discussed at length in the public blockchain call today (Monday 8/30, 11am ET) and on public Discord channels. Miners are welcome to try this PR, while it goes through the standard release process.
Hiro web wallet: We are working to release a version of the Hiro Web Wallet in the next 1-2 days that allows users to set manual nonce and fee values upon signing of any transaction.
- The build will give the users a prominent “Replace by fee” option for all pending transactions listed under activity.
- This will take them to a form to submit the same transaction with the same nonce but different fee, with guidance about increasing it.
- Note that Chrome and Firefox will need to approve this build before it’s live for most users. Meanwhile power users can install from source.
- There are many pieces that must come together to create a robust fee market. In the meantime, the current default transaction fees don’t reflect or capture network activity adequately. To improve the experience for our users the default fee for transactions made through the Hiro Wallet will be changed to 0.25 STX, with optionality for users to change that fee.
- Clarity cost tracking: Hiro has made a proposal to introduce a cost-estimator abstraction in the miner software that would allow for incrementally improving the cost-estimates without having to wait for Stacks 2.1. This proposal was shared with Stacks core-developers last week and is being reviewed.
- In addition to an immediate fix to the Hiro Wallet, the Hiro team is working on a modification to stacks.js/connect that would allow developers to pass a default fee amount upon hand-off to transaction signing.
- That way developers like StacksPunks can choose for their users to pay higher fees by default (e.g. 2 STX if they deem that appropriate to get their transactions settled reliably).
- Of course, users can then edit this developer-set amount as they please subsequently before broadcasting.
- This seems like an important change to prevent lots of users from still broadcasting transactions with too low fees before realizing there’s even a problem with fees, and having to go back and replace by fee (or depend on the app to inform them first of the fee to set manually).
Observations on operating in a decentralized ecosystem
- The Hiro team will always be there to respond to Hiro-related products. This is an open source ecosystem, like Bitcoin, and there is no one party that can unilaterally make changes nor implement new features to the Stacks blockchain. Around the core decentralized base of the Stacks blockchain, individual companies can update their products however they want and as frequently as they want.
- Decentralization is one of core values of the Stacks ecosystem and there is sometimes a natural trade-off between “doing it fast” and “doing it right”. Hiro understands these tradeoffs of the underlying technology. The Hiro wallet fix should be complete soon, however any changes to the underlying network may take more time to be more broadly socialized given it requires independent Stacks miners to opt into the new mining software that we anticipate will be ready for deployment, following the release process, later this week. It is in Stacks miners’ economic interest to run the new mining software, as they can collect higher fees, so we expect that the economic self-interest will result in faster adoption. Miners may implement their own versions of the open-source software to further optimize revenue from gas fees as well.
- Longer term, we also expect a healthy network fee market to emerge where users can pay higher transaction fees for important transactions or do replace-by-fee to bump up the priority of their transactions. A robust fee market is a sign of a healthy blockchain network and Hiro plans to update Hiro products as the underlying network fee market evolves.
Overall, it’s wonderful to see the Stacks ecosystem thriving, developers building apps that are gaining traction, resulting in increased network usage. This is a good problem to have, and one I’m confident that we – different ecosystem entities and stakeholders, developers and users, miners etc – can solve together!