-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Research]: Savlagable Aspects sBTC-mini #27
Comments
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 |
I'm looking through any contracts I can find with 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. |
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 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. |
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. |
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. |
Closing because we've already discussed and agreed on above. |
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:
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:'
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 text was updated successfully, but these errors were encountered: