Faster L2 WG: Intro Thread

[blocks8]

Objective

We recognize the reality that market expectations for "table stakes" performance from smart contract chains have shifted in the last 2 years. To remain competitive in this landscape, the Stacks layer (L2) must be "fast enough" for developers and end users.

Scope

This working group will explore:

• Performance improvements that can be made without requiring a hard-fork -- these can be rolled out at any time.
• Performance improvements that are consensus-breaking -- these require a hard-fork and given the higher bar / overhead of such upgrades, it's desirable to "package" up related consensus-breaking changes into fewer releases.

Deliverables and Timeline

To be fleshed out.

Lead

• Brice Dobry (@obycode) -- non consensus-breaking performance improvements
• Jude Nelson (@jcnelson) -- consensus-breaking performance improvements

Participants

• Greg Coppola (@gregorycoppola)
• Alie Slade (@a3slade)
• Brittany Laughlin (@blocks8)
• Jesse Wiley (@wileyj)
• Cyle Witruk (@cylewitruk)
• Will Corcoran (@will-at-stacks)
• Pavitthra Pandurangan (@pavitthrap)
• Hero Gamer (@Hero-Gamer)
• <you could participate too, just let us know!>

How do I stay updated / involved?

• Announcements / Updates: posted to Github discussions in this repo
• Architecture / Designs: posted as RFCs to the Forum. There will be a corresponding update in Github discussions too
• Implementation: will be opened as PRs against the stacks-blockchain repo.
• Real-time / near-time discussion: #stacks-core-devs channel on the Stacks Discord server. Click emoji related to Developer channels to view and join.

Links

• Related Issues

[wileyj]

I'm happy to participate where I can @blocks8

[blocks8]

Added you to the working group!

[obycode]

Our first related PR, stacks-network/stacks-core#3337 has been merged today and should be released soon in 2.05.0.5.0.

[cylewitruk]

Happy to join this WG :) @obycode

[obycode]

Thanks @cylewitruk. Added you!

[cylewitruk]

🙏

[Hero-Gamer]

May I join this as an learner/observer? Would like to understand more so maybe can connect the willing contributor from the community in the future if I ever come across. @obycode

[obycode]

Of course!

[obycode]

For anyone else interested, we'll start really digging into this, and having some regular meetings / discussions once the 2.1 work settles down. In the meantime, for anyone not working on 2.1, please go ahead and collect your ideas here and in issues on the stacks-blockchain repo and use the "L1 Working Group" tag.

[will-corcoran]

@blocks8 @obycode I would love to listen in to these calls, if possible (for grants / bounties visibility). Would you mind adding me? Thanks, Will

[will-corcoran]

Thanks @obycode !

[obycode]

Now that 2.1 is mostly out the door, I think we can finally get moving with this WG. For the non-consensus-breaking changes, I see several different avenues to explore:

• General performance analysis to identify targets for improvements (this should be the first priority)
• Mempool processing
• Clarity checkers
• Clarity VM
• MARF
• Other miner components

Does anyone have additional items to add to that list? I'd suggest that we start off doing some performance analysis to see where we stand and where the hotspots are, then schedule a meeting to do some brainstorming. Thoughts?

[jcnelson]

Yes, there are a few additional non-consensus-breaking changes we can make:

Transaction Latency Improvements

• Unconfirmed microblock anti-entropy protocol. Right now, microblock propagation is best-effort. If your miner node gets unlucky and never receives a microblock, then it won't be able to confirm it or any of its descendants. What we should do at some point is make it so that nodes asynchronously monitor each other's unconfirmed chain tips, and if one discovers that the other has a higher chain tip, it pulls the missing microblocks and forwards them to neighbors that are also missing them. This would make microblocks much more reliable than they are now. See #2031.

• Optimistic microblock confirmation. When a miner broadcasts a Bitcoin block-commit transaction, they implicitly commit to confirming a microblock stream. Exposing this information would be very useful to block explorers and wallets, because it would help users determine what fraction of the mining power has committed to building atop a microblock that contains their unconfirmed transactions. To do this, miner nodes would need an efficient way to inform the rest of the network when they have sent a block-commit, and inform the network what microblock tail they built upon (this is more involved than just looking in the Bitcoin mempool, I'm afraid, because Bitcoin doesn't provide an efficient way to query unconfirmed transactions by OP_RETURN bit pattern).

• Mempool admission based on unconfirmed state. Once unconfirmed microblock replication is more or less reliable, we should make it so that the node can determine an inbound transaction's validity against the unconfirmed microblock stream. Wallets would use this to determine what nonce to use for a user who has multiple transactions in-flight. This is what #2787 attempts to do.

Database Optimizations

• Analysis DB columns. Most of the analysis DB queries load the full analysis state for a contract into RAM whenever they want to read a part of it. Instead, the analysis DB should reorganize its data into columns that get queried often, so we don't need to do O(contract-length) reads to get O(1) data.

• Co-locate MARF data with MARF tries. Right now, querying any Clarity state is a two-step operation: (1) resolve the MARF key to a MARFValue, which contains a data hash, and (2) resolve the data hash to the data in a wholly-separate DB. Step (2) incurs an O(log n) penalty for n data items in the whole blockchain due to the need to walk the sqlite B-tree. We can remove step (2) by just storing the data directly into the MARF .blobs file, instead of storing a MARFValue. Moreover, this would remove a big O(1) I/O cost because we wouldn't be hitting any of sqlite's paging logic to read or write data.

Network Optimizations

• I/O thread pool. Right now, both the P2P and HTTP server state-machines run in a single thread. This includes both control-plane logic and data-plane logic. The control-plane logic -- i.e. socket management, RAM management, authentication, access control, etc. -- should continue to reside within a single thread, but data-plane tasks like loading block data, loading contract data, and processing read-only contract calls can be farmed out into a separate worker thread pool. In particular, we'd want to move all I/O-bound request handling into separate threads, so we can free up the main thread to handle control-plane bookkeeping.

---

I'll add more if I think of any. None of these are consensus-breaking.

[jcnelson]

Also:

• Rewrite the type checker to have better error messages
• Drop the 2.05 type checker once 2.1 is live

[jcnelson]

Also:

• Upgrade SIP-006 to make cost votes easier, and make it so that a SIP-006-style vote can add native Clarity keywords

[pavitthrap]

I volunteer to implement general performance analysis (or help with it if someone else feels strongly about taking the lead)

[obycode]

Also:

• Drop the v1 parser once 2.1 is live (and confirmed that transactions up to 2.1 are compatible
• Drop the ASTRules once 2.1 is live

[friedger]

Here is a proposal to make use of bitcoin blocks more efficiently. Looking at current data, this could lead to 10% increase in number of stacks blocks.

Currently, the canonical fork is the longest fork. The proposal is a change to encourage to build on the longest stacks chain with the least bitcoin gaps. Inspired by SIP 21, we calculate a temperature of a fork and let the coldest fork win. The mining software should be changed so that forks with gaps are abandoned earlier. This is a non-consensus breaking change and should lead to less bitcoin blocks that are not linked to a canonical stacks block, ie. less orphan blocks.

Furthermore, the change can discourage bad acting miners to create sibling blocks.
The graphics below show the current state and the proposed change:

This proposal is a work in collaboration with @Ston3cutt3r

[obycode]

Reading through this discussion, it makes me wonder why honest miners can't out-compete the dishonest miners. I don't think the dishonest miners are doing anything that couldn't be successfully counteracted by honest miners, so then the question becomes, why aren't the honest miners able to out-compete the dishonest miners? That seems like the market for mining is inefficient. Instead of trying to make it easier to punish the dishonest miners, which adds complexity, could we alternatively solve this problem by making the market for mining more efficient?

The mining market inefficiency likely has two components:

1. Technical complexity - it's technically difficult to start mining
2. Startup costs - there are some startup costs to "warming up" a miner which can make it infeasible for small miners

Number 1 can be solved by improved tooling and documentation, and seems very do-able. Number 2 should be solved by the trustless mining pools that 2.1 enables. If we solve these two issues, does the market for mining become more efficient and the problem goes away? The honest miners would benefit from the failed attempts of the dishonest miners, and eventually the dishonest miners lose money and go away, or become honest miners.

[Ston3cutt3r]

As long as the default release builds it´s block on the longest fork, honest miners are not able to compete against the dishonest entity C. Even if A and B represent e.g. 52% of the mining power.

With a self built release C is able to ignore blocks from A and B as long as C has a longer fork and A or B builts the next block on it.

Decentralized mining pools wont solve that problem. Furthermore you can´t presume that A and B communicate with each other and dislodge C with a self build release

[jcnelson]

@obycode it makes me wonder why honest miners can't out-compete the dishonest miners.

The default fork-choice rule means that a mining coalition with over half of the mining power will produce the canonical fork. It's statistically guaranteed. But, the minority coalition can opt to ignore that fork (but it won't do them a lot of good to do so unless they can also get users and exchanges to ignore it as well).

why aren't the honest miners able to out-compete the dishonest miners?

Simple: they spend less BTC than the dishonest miners.

---

There's nothing inherently wrong with there being a coalition of miners. What's proven to be problematic is that this coalition can prevent other miners from receiving STX, even if the other miners are honest. My proposal here and on the forum about "pre-commits" is meant to force the network to acknowledge and reward miners for building on the canonical fork, even if their block gets orphaned later. This would make mining more fair than it is today -- if you spend X% of the total BTC building on the canonical fork, then you get X% of the STX reward.

[obycode]

I built a simple simulator to play around with these mining scenarios - https://github.com/obycode/miner-sim

[igorsyl]

I built a simple simulator to play around with these mining scenarios - https://github.com/obycode/miner-sim

@obycode Amazing! Check this out! @obycode

https://github.com/Trust-Machines/blocksim/

[igorsyl]

@jo-tm has experience with VDF's and can provide design guidance and reviews.

[jio-gl]

added one idea on Forum to improve Microblocks consensus, will also need some form of clock validation (more simple) or VDF verification (more complex): https://forum.stacks.org/t/microblock-consensus-using-stx-proof-of-transfer-pox/15091