SRI stands for Stratum Reference Implementation, and is meant to act as the building blocks for the Bitcoin mining infrastructure.

Now imagine someone wants to write a sv2-enabled pool based on SRI. There are infinite different directions they could go, which I will try to summarize in two main ones:

Right now, SRI has implementation for roles crates, which do include a "demo" pool. But this is just a dummy project which only exists for the purpose of showcasing how to wire the low-level libraries together (e.g.: crates under protocols, commons and utils). This pool implementation is somewhat opinionated in regards to multiple factors, namely:

If someone wants to leverage the low-level libs while writing a production-ready pool from scratch under a different architecture, that is already doable. We believe these low-level crate libs are relatively mature, which is why they are all set as v1.0.0.

This is also likely a path to most pools that already have some codebase, but only wish to integrate SV2 in a modular way. While SRI is a Rust codebase, it provides FFIs to enable integration with other programing languages (e.g.: C, C++, Python).

Putting low-level libraries together implies heavy-lifting. That could be time-consuming and somewhat prohibitive to small teams. That is why it is also desirable that SRI provides high-level libraries with building blocks for roles implementations.

That way, if some small team wishes to implement a pool in a specific way, SRI would already provide some building blocks for that. These building blocks would be opinionated with regards to threading model, error handling, socket handling and any other general aspects of the software. The pool team could then implement their own opinionated strategiesfor coinbase management and share accounting, without necessarilty spending thousands of man-hours on wiring together the low-level APIs.