Hi everyone,
I wanted to follow up here with some more details on what Hiro is focusing on with respect to some of the issues mentioned in this thread.
First, quick summary of the work items mentioned earlier in this thread:
- For miners: 2.0.11.3.0-rc2 was tagged 6 days ago. A release build is under review, I’m optimistic that we’ll have a 2.0.11.3.0 release available shortly. Worth repeating though that it’s ultimately up to the miners to upgrade their software.
- RBF support in Hiro Wallet / Connect etc: Covered in ample detail by Mark earlier in this thread
- For exchanges: Or anyone else using the send-many contract + CLI, v1.3.0 of the CLI now supports a fee multiplier. It already supported specifying a nonce, and together this enables one to RBF their existing send-many transactions.
Obviously performance and reliability at the blockchain layer directly affects developer satisfaction and so I want to take a moment to talk about what Hiro would be focusing on. We can think of possible improvements / changes / new capabilities on the Stacks blockchain in the short (4-6 weeks), medium (1-2 quarters) and long-term (6-12 months).
In the short-term, Hiro is focusing our efforts on three workstreams:
- Facilitate a healthy fee market: As I mentioned earlier, the lack of a robust and dynamic fee market on Stacks makes the chain less resilient. An expensive but popular contract call can make the entire network crawl. We have already started implementing our proposal for improving cost estimation and mempool processing. While this won’t fundamentally change the underlying blockchain capacity, it will allow for more natural throttling and traffic control to emerge via transaction fees.
- Profile, Benchmark, Optimize: We’d like to dramatically improve the visibility into the current performance of the Stacks blockchain – exactly where time is being spent (e.g. block assembly, block propagation, block assembly, MARF I/O etc). We’re also going to run some rigorous benchmarks to understand the limits of the current implementation under different workloads (e.g. how many contract-calls for a specific contract/call can be packaged in a block). This profiling and benchmarking will shed light on the biggest bottlenecks in the current codebase which we can then work on improving. We’re also working on integrating some of this benchmarking within Clarinet, so smart-contract developers have more visibility and insight into expected costs and performance of their Clarity contracts.
- Explore feasibility of Clarity cost-voting as a non consensus-breaking solution: Changing block limits and runtime costs would normally be a consensus breaking change (necessitating a hard-fork). Clarity supports in-situ upgrades, which allows changing runtime costs through an on-chain vote. Hiro is currently validating this on the testnet and exploring the general feasibility of this approach.
I strongly encourage to also read Muneeb’s post on a “Framework for Stacks Scalability”
There’s also amazing ongoing discussion around topics like nonces, block capacity, performance, microblocks etc on the community Discord server. Join us there!