[Research]: Savlagable Aspects sBTC-mini

[AshtonStephens]

Completing the issue description and arriving at a conclusion is the deliverable of this issue.

Research - Savlagable Aspects sBTC-mini

This ticket holds the research relating to identifying the savlagable aspects sBTC-mini and how they would need to be altered or the process needed to alter them to work with sBTC-v1.

1. Summary

sBTC-Mini was an attempt to implement a decentralized pool of stackers that maintained the sBTC-peg without a required hard-fork. The key to understanding sBTC-Mini is to realize that the core consensus mechanism revolves around a specific stacker pool (instead of a group of signers, there's a new group of pool members every reward cycle).

Every new reward cycle, a new group of stackers register to the stacking pool & vote (by weight) on the next cycle peg-wallet during their tenure (v much like Nakamoto).

This logic is implemented with the follow contracts:

Contract	Description
Controller	Admin contract that registers/holds other contracts
Registry	State-tracking contract that holds state for updates/freezes/etc
BTC TX Helper	Custom implementation of 'clarity-bitcoin' for sbtc-mini
Token	SIP-10 fungible token contract
Hand-Off	Verifier contract for hand-off pegged-BTC from one threshold wallet to the next
Stacking-Pool	Main contract for stacker life-cycle including registering, voting, etc..
Deposit Verification	Deposit contract that verified burnchain deposit
Withdrawal Request BTC	Initiate withdrawal request on burnchain
Withdrawal Request STX	Initiate withdrawal request on mainchain
Withdrawal Reclaim	Claw back withdrawal request
Withdrawal Verifier	Confirm withdrawal request

2. Context & Relevance

3. Research

What Is sBTC-Locked & Why Use Another FT?
As you'll see below, sbtc-locked is simply a tracking token used at the protocol level. Why use this mechanism? Because every FT has a native 'get-ft-supply' function that clients call to get the circulating supply at any point in time. Since these tokens are locked, they technically shouldn't count as in-circulation which means the true supply would deviate from the 'get-ft-supply' function. In order to keep this function intact globally, we opted for a workaround locking mechanism by introducing a non-transferrable, for-tracking-purposes-only 'sbtc-locked:'

;; --- Protocol functions
(define-public (protocol-lock (amount uint) (owner principal))
	(begin
		(try! (is-protocol-caller))
		(try! (ft-burn? sbtc-token amount owner))
		(ft-mint? sbtc-token-locked amount owner)
	)
)

(define-public (protocol-unlock (amount uint) (owner principal))
	(begin
		(try! (is-protocol-caller))
		(try! (ft-burn? sbtc-token-locked amount owner))
		(ft-mint? sbtc-token amount owner)
	)
)

(define-public (protocol-burn-locked (amount uint) (owner principal))
	(begin
		(try! (is-protocol-caller))
		(ft-burn? sbtc-token-locked amount owner)
	)
)

3.1 Proposed Research Conclusions

1. Controller/Registry Combination
Seen in sbtc-mini & structured after executor-dao, this is a modular approach to maintaining a flexible Clarity-based protocol that'll be specifically helpful as we update into a v2.

2. Protocol Locking/Unlocking (sbtc-locked)
Described above, I believe it's worth keeping this mechanic intact as a tracking system in order to maintain precision in the built-in FT function.

3. Voting Mechanics
Seen now both in sbtc-mini & in the new sbtc-voting, there are chunks of the voting mechanics (including required maps & functions) that we'll very likely re-use.

4. Personalized sbtc-clarity-bitcoin-helper Contract
In the same spirit seen here, it makes sense to either keep the version seen here or create a wrapper for a lighter model of bitcoin-clarity. Especially because I believe a new version of bitcoin-clarity was released.

3.2 External Resources

3.3 Areas of Ambiguity

---

Closing Checklist

• The takeaway from this issue is clearly documented in the description of this ticket.
• Everyone necessary has reviewed the resolution and agrees with the takeaways.
• This ticket has or links all the information necessary to familiarize a contributor with the topic and how it was resolved.

[AshtonStephens]

@netrome @setzeus @8marz8 to do a look at this and see what we can add concretely into the deposit / withdrawal flows for sBTC-v1.

[8marz8]

I'm having a change of mind about going with the "Deposit API" route for the deposit flow. Especially if, for the first iteration, we can mostly reuse the deposit/withdrawal contracts from sBTC and only replace the role of the stacking pool and details of the voting mechanism to instead integrate with the signers and however the voting/verification gets done in Nakamoto and subsequent sBTC release.

Sorry if I am undoing one aspect that we sort of agreed on, but I have listed my assumptions here. I think concluding this aspect will shed more light on this ticket

[netrome]

I'm having a change of mind about going with the "Deposit API" route for the deposit flow. Especially if, for the first iteration, we can mostly reuse the deposit/withdrawal contracts from sBTC and only replace the role of the stacking pool and details of the voting mechanism to instead integrate with the signers and however the voting/verification gets done in Nakamoto and subsequent sBTC release.

Sorry if I am undoing one aspect that we sort of agreed on, but I have listed my assumptions here. I think concluding this aspect will shed more light on this ticket

Good point. I've looked at the sbtc-deposit-verifier contract from sBTC mini now, and I don't think we can use the contracts as-is. However, I believe we can use it to accelerate development of our deposit flow since most of the parts we'd need for our deposit request contract is already present there. So from this perspective, the contract call route seems like the faster way as opposed to developing and hosting a separate service.

[netrome]

I'm looking through any contracts I can find with voting in their names. In sBTC Mini there doesn't seem to be voting implemented (I'm on commit 1b260e537a4a944859e2969ad489c3bce094cd86 in the stacks-sbtc repo), and the Nakamoto voting seems to have a lot of logic revolving time windows for tallies which aren't translating well to the current sBTC design as I see it.

To me, it seems simpler to require individual signatures from all signers than having them making separate contract calls with votes for all of their actions in sBTC. I'd love to hear any arguments for using a voting mechanism over the solution with the signatures.

[setzeus]

Voting logic is in the stacking pool contract: https://github.com/Trust-Machines/stacks-sbtc/blob/main/sbtc-mini/contracts/sbtc-stacking-pool.clar

Starting in line 480.

[netrome]

Voting logic is in the stacking pool contract: https://github.com/Trust-Machines/stacks-sbtc/blob/main/sbtc-mini/contracts/sbtc-stacking-pool.clar

Starting in line 480.

Oh I see, thank you for the pointer. This is similar to in Nakamoto, where tallies have a time window and a lot of the logic revolves around them. I suspect that the logic we'd have to implement for a voting mechanism to collectively call deposit-accept or any other function would be very different since there is no pre-defined time window for those tallies, and there may be multiple votes happening in parallel whereas the current logic is using shared structures like next-cycle-stacker which only works if tallies are non-overlapping.

So while we don't have to start completely from scratch implementing a voting mechanism for all signer contract calls, my hunch is that using a batch of ECDSA signatures is a simpler way forward.

[setzeus]

Agreed. Discussed this #36 but slightly leaning towards consuming a list of ecdsa signatures. We haven't implemented that exact logic but we've recently done parts of it (voting in sbtc-mini & Nakamoto, signatures in Nakamoto) so I don't believe it'll be an incredibly challenging task.

[AshtonStephens]

We will know more about what we can take once the HLD is done, BUT the HLD will not need to be changed to use sBTC-mini code.

[AshtonStephens]

Closing because we've already discussed and agreed on above.