Approach for exposing Stacks primitives to 3rd parties

[stjepangolemac]

The goal of this discussion is to decide on how to proceed with making Stacks primitives available for general development. This is important for 3rd parties and for us when working on libraries such as sbtc-core (SDK). Lowering friction of building on top of standard types and logic will increase adoption and interest.

After several tries and a lot of discussion with multiple parties the right path forward remains unclear.

Option 1: Extraction ⛏️

Move basic types and modules out of the blockstack_lib package into a new stacks-core package in the stacks-blockchain repo. At some later point make effort to change the stacks-core license from GPL to MIT.

After a couple of attempts we've come across several important findings about this approach:

• the extracted code must be identical to the current blockstack_libstate, feature to feature, bug to bug, due to it being used in critical consensus code
• any modifications or potential bugfixes can result in a hard fork
• it's unclear if we can use it in sbtc-core before it's relicensed and how long the relicensing process can take, making the sbtc-core work and release hard to estimate
• stacks-blockchain codebase is very complex and the feedback loop between writing code and compiling is very long (compared to other Stacks projects)
• blockstack_lib reimplements parts of the bitcoin crate and their equivalent types are not interchangeable

This approach should make sure that there's always one "canonical" implementation of Stacks primitives. However, it should also make the process of maintaining, improving, and extending stacks-core slower and considerably less flexible.

Option 2: Reimplementation 📝

Reimplement basic types and logic in the stacks-core package that can start in the sbtc repo and later be moved to stacks-blockchain, or just start it in the stacks-blockchain repo. It can be MIT licensed from the start. It would not need to follow the procedures and have the same guarantees as the consensus critical code.

We've also started to reimplement parts of blockstack_lib in this repo in the stacks-core package (PRs pending) and discovered a few things:

• for reasons stated above it's unreasonable to expect blockstack_lib ever switching or depending on it
• the APIs of some fundamental blockstack_lib types and functions are non-ideal and can easily be improved without backwards compatibility guarantees
• the naming and structure of some blockstack_lib code hide failure modes and contain intentional or unintentional bugs (or are they features)
• blockstack_lib contains custom implementations for widely available, stable and tested libraries such as hex (with more potential candidates such as uint support and crockford32 encoding)
• we can focus on using types from bitcoin and bdk crates which are both standard when working with Bitcoin and Rust

This approach would result in having multiple implementations of the Stacks primitives, as is already the case with stacks.js. At the same time it would decouple consensus critical code from the rest of the ecosystem. That should allow both 3rd parties and us to move and build faster, improve APIs, fix bugs, etc.

Note

Let's aim to give feedback before the end of this week, so we can act upon the decision and move forward next week.

[jcnelson]

Take option 1 if you want your library to become a dependency on stacks-blockchain.

Take option 2 if that's not a goal.

[netrome]

It would be nice to eventually make this a dependency on stacks-blockchain but that is not the primary goal currently, and we technically don't ever have to make it so.

The primary goal is to build a developer friendly SDK that allows us and other developers to move fast and implement the signer library and binaries, sBTC transaction construction and other sBTC related tools and features.

So therefore, option 2 feels like the path best aligned with the goals of this SDK.

[sergey-shandar]

IMHO: Option 2 can also help in education. Developers, who will work on the library, can get knowledge which can help them to understand better Stacks. Also, they have a chance to simplify and clean code and don't carry legacy design decisions. One of the principles that I would like to see, is no I/O in the library. That would significantly simplify testing, if we can mock any I/O and have a complete control over it.

[stjepangolemac]

Yeah I agree with everyone here. I think we'll take the reimplementation route and see where it takes us.

I'll close the discussion just to keep the general state tidy but feel free to reopen and continue it if needed.