search

stacksgov / sips

Community-submitted Stacks Improvement Proposals (SIPs)
132 stars 80 forks source link

Stacks 2.1: Support continuous stacking #6

Open agraebe opened 3 years ago

agraebe commented 3 years ago

In the current implementation, stackers would have to skip one cycle after a previous commitment. This is happening because the STX tokens from a previous commitment will unlock after the prepare phase of the next cycle.

314159265359879 commented 3 years ago

I agree, it should be possible to continuously stack. If the number of cycles committed ends and you want to stack the next cycle that should be possible without a mandatory unstacked cycle.

jcnelson commented 3 years ago

Implementing this as written will require a hard fork. Per SIP-011, adding this feature is not sufficient justification for a hard fork. But fortunately, this is something that could be addressed in Stacks 2.1, which is scheduled for Bitcoin block 700,000 (at which point all Stacks 2.0 nodes will stall). Let's go ahead and add this to a wishlist for Stacks 2.1 on the stacks-blockchain repo. Once we know what's going into Stacks 2.1, we can write a "Stacks 2.1" SIP.

cuevasm commented 3 years ago

@jcnelson what/who decides what is sufficient justification for a hard fork? If others feel as I do, that this could be an impediment to the broader adoption of the network at a critical time in the market, can't the community move forward on pushing for this sooner than waiting 5-6 months for 2.1? I am aware quite a few folks, including miners and Stacks 2.0 launch partners that would definitely support swifter movement on this. I think the early indications are that Stacking is probably the first major way the ecosystem can win right now and there's some urgency we can move with to capture users.

Edit: Will add that some exchanges have explored support for Stacking, but essentially can't do it because of this limitation. They are forced to hold double the amount their users commit to Stacking to cover their users each cycle, or to cut the rates in half for their users (or make them skip cycles). Both paths are very suboptimal and for some becoming untenable/not scalable.

jcnelson commented 3 years ago

SIP-011 codifies what constitutes a severe-enough problem to warrant a hard fork. Stacking's behavior today is 100% in compliance with SIP-007, so there is not even a bug to fix. What you are asking for is a new backwards-incompatible feature.

The system is working as designed right now -- people who Stack are getting a Bitcoin payout. If exchanges misrepresented the service they're selling to users, then that's the exchange's fault, not ours. It's not like any of these Stacking behaviors were unanticipated or developed in secret -- SIP-007 and the Krypton and Xenon testnets were public for ~6 months before mainnet went live. Why didn't these several exchanges who supposedly cannot Stack do some due diligence and raise questions then, at the time when we could have actually addressed it?

We all agreed last year to do a network upgrade at Bitcoin block 700,000 to finish implementing backwards-incompatible changes that we wanted to ship in Stacks 2.0, but didn't have time to get to. This includes making it so people can "top off" their already-Stacked STX in increments of 10k, and making it so people can re-Stack their STX without the 1-reward-cycle cool-down. I see no reason to bump this timeline up, because believe it or not there are higher priority things that myself and Hiro's engineers must take care of first before we can work on the Stacks 2.1 upgrade.

But, as I've written here and elsewhere, exchanges have plenty of options to acquire reward addresses and STX liquidity that don't require a hard fork, and exchanges can easily create a "futures" smart contract that will allow a user's STX to remain liquid while they're Stacked. Please see my original explanation to Alex for details, as well as find links to all the Github discussions we had about it over the last year when SIP-007 was being designed: https://forum.stacks.org/t/hiro-s-feedback-on-stacking/11680/8. As far as I know, exchanges haven't even begun to explore their options here.

agraebe commented 3 years ago

I think it would be good to have a balanced point of view on this issue. With that spirit, please see my thoughts below.

Stacking's behavior today is 100% in compliance with SIP-007, so there is not even a bug to fix.

This would imply full confidence that SIP-007 was describing the exact behavior. I just reviewed it again and I don't see a callout that would explain clearly that continuous stacking shall not be possible. In general, there could be implications that are not mentioned in a SIP and we should have a way for the community to navigate that. SIP 011 seems not to be the right framing for this particular issue.

It's not like any of these Stacking behaviors were unanticipated or developed in secret -- SIP-007 and the Krypton and Xenon testnets were public for ~6 months before mainnet went live.

This is not a fair characterization. Integration partners were not involved in the testnet process. There are multiple reasons for that and saying they had a chance to course-correct this behavior is not true. The testnet wasn't reliable and edge cases of the implementation were uncovered just right before the mainnet release (and some even after) - even for PBC and the foundation.

But, as I've written here and elsewhere, exchanges have plenty of options to acquire reward addresses and STX liquidity that don't require a hard fork, and exchanges can easily create a "futures" smart contract that will allow a user's STX to remain liquid while they're Stacked.

The Stacks blockchain is just one "feature provider" for an integration partner - they have a lot of others and often note that it is much simpler to use them. We're in competition with other providers and the status quo of stacking is limiting the opportunity we provide to the ecosystem. The value creation does not come from an accurate implementation of a SIP but from broader adoption.

Apart from that, exchanges integrate a vast amount of providers and don't have time/skills/incentives to get familiar and improve the limitation of one single provider. It is already quite an effort to get to successful contract calls -- asking them to develop a smart contract will in all likelihood never happen. They'd just look elsewhere to offer the features to their users. Our ecosystem doesn't benefit from this. We should not take on a "take it or leave" standpoint when it comes to a product that was just released. The world of crypto will look very different in 6 months and we should be clear that we're choosing to be ok with missing opportunities in the meantime.

jcnelson commented 3 years ago

This would imply full confidence that SIP-007 was describing the exact behavior. I just reviewed it again and I don't see a callout that would explain clearly that continuous stacking shall not be possible.

It doesn't say that it's required either. As I've said here and elsewhere, it can be addressed in Stacks 2.1. That's not a point of contention for me. My contention is entirely on the proposed solution -- an unforced hard fork.

SIP 011 seems not to be the right framing for this particular issue.

I think SIP 011 is exactly the right framing for this particular issue. Hard-forking the blockchain to change its monetary policy is supposed to be hard -- so hard that it can only be done with overwhelming consensus, instead of on the whims of a few people. But we currently do not even have a way to measure that consensus. A few posts on Github isn't consensus -- we need to see that miners will overwhelmingly vote for the change with their blocks and users will overwhelmingly vote for it with their STX. And to do that, we need to come up with and ratify a protocol for doing so, which would require its own governance-track SIP.

This is not a fair characterization. Integration partners were not involved in the testnet process. There are multiple reasons for that and saying they had a chance to course-correct this behavior is not true. The testnet wasn't reliable and edge cases of the implementation were uncovered just right before the mainnet release (and some even after) - even for PBC and the foundation.

My point is that integration partners could have done due diligence on Stacking at any point in time up to choosing to list Stacking as a service for users. So yes, this is an entirely fair characterization -- we gave them every opportunity by making the code open-source, publishing SIP-007, and running testnets for them to try out. For example, if these partners were VCs, you can bet they'd have sent domain experts to audit the code and raise any questions about it -- it's standard practice. If these partners had actually done that due diligence, then they should not be surprised by Stacking's behavior. If they did not do due diligence, then that's on them. We did our part.

The Stacks blockchain is just one "feature provider" for an integration partner - they have a lot of others and often note that it is much simpler to use them. We're in competition with other providers and the status quo of stacking is limiting the opportunity we provide to the ecosystem. The value creation does not come from an accurate implementation of a SIP but from broader adoption.

Stacks is the first blockchain that implements Stacking, so it's not surprising to me that exchanges have to do a little bit of learning to figure out how it works. But regardless, Stacking on behalf of users is a service that the exchange offers, not Hiro or the Foundation. As far as I know, Hiro never agreed to build a Stacking service for another exchange. But if Hiro needs to commit engineering resources to help them build out Stacking, then that's something Hiro can do today without a hard fork.

As for competition, users like the idea of Stacking in general, and users are driving exchanges to adopt STX and Stacking. We can see it on Twitter, on the Stacks reddit, and the Stacks discord. Services who don't offer Stacking will be replaced by services that will (this is already happening -- see https://pool.friedger.de for example).

As for value creation, no one wants to use a blockchain whose monetary policy can be changed overnight. Like, what's the point of having a blockchain then? Why would anyone invest in its token, if the caprices of its developers and exchange partners can change the monetary policy overnight? Even if the change is beneficial now, the same muscles that make the change today can be flexed to enact harmful changes later. The drawbacks of enduring the temporary discomfort with Stacking is vastly outweighed by the benefit of the chain's stewards proving that they can be trusted with maintaining stable monetary policies.

Apart from that, exchanges integrate a vast amount of providers and don't have time/skills/incentives to get familiar and improve the limitation of one single provider. It is already quite an effort to get to successful contract calls -- asking them to develop a smart contract will in all likelihood never happen.

There's no way around having to learn a little bit about how a new blockchain works. That's just the cost of doing business. If Hiro wants, they could create the smart contract for them.

They'd just look elsewhere to offer the features to their users. Our ecosystem doesn't benefit from this. We should not take on a "take it or leave" standpoint when it comes to a product that was just released. The world of crypto will look very different in 6 months and we should be clear that we're choosing to be ok with missing opportunities in the meantime.

This may be true in other industries, but it is definitely not true in this one. The whole point of selling a financial product manifested as a blockchain is to make it extremely difficult for a few well-connected people to change the rules on a whim. That's why you can trust blockchains with your money without relying on the force of law -- the rug isn't going to be pulled out from under you.

Also, even if I was 100% sold on the idea of an unforced hard fork, it would take about 6 months to get a Stacking upgrade out the door. So trying to execute an unforced hard fork is taking on a lot of needless risk for absolutely zero gain.

And, even if I was 100% sold and the upgrade could ship tomorrow, the governance process is not adequate to execute an unforced hard fork. The Steering Committee that exists today includes just myself -- it's the provisional SC defined in SIP-000, because there doesn't exist a SIP yet for deciding how the community is represented on it. So in my mind the SC lacks the governing legitimacy to ratify an unforced hard-fork SIP. SIP-011 intentionally doesn't do this.

Look, I agree with you that Stacking can be improved -- no one likes locking up 70,000 STX only for the minimum lock-up to get bumped to 80,000 at the last minute. In fact, I wrote up an alternative Stacking auction system here, as a follow-up to my issue that the dynamic adjustment window is considered harmful. Trust me when I say I'm well aware of Stacking's shortcomings -- I wrote about them in August 2020, and I hope the community finds it fit for me to address them in Stacks 2.1. But I'm not seeing any reason try and execute an unforced hard fork -- with all the technical and reputation risk it will entail, without even knowing how much support it truly has -- when we know that the Stacking feedback will be addressed by August 2021.

cuevasm commented 3 years ago

I think you may be missing that this entire push IS coming from the community. None of us is making unilateral decisions here and we didn't wake up hoping to have to push a hard fork or wanting to battle anyone about the merits or philosophy of one. Alex and I are really the messengers here and are trying to help everyone understand the options because folks are unclear or still learning how to push something like this forward.

The continuous Stacking issue is a universal problem/impediment to overall growth. You can count my and Alex's posts on this for multiple miners, multiple exchanges, 5-10 community members, and a handful of other integrators and partners of the ecosystem. If helpful, we can compile feedback here.

Anyway, I am not claiming that a hard fork is the only solution, my understanding is that it will be hard to solve without one.

cuevasm commented 3 years ago

I'd like to start this conversation over a bit as I feel like it's becoming a general debate about hard forks that we're probably not going to agree on. @jcnelson I totally respect all your points as valid. In a world where we say there is no hard fork until 2.1, but still want/need to solve this specific continuous Stacking problem earlier, how would we proceed?

Fundamentally, can this issue of continuous Stacking be solved without a hard fork? I have heard talk of a series of smart contracts that might make this possible with the current structure. This is something I think we can resource against and help our partners with. The ability for them then to help us grow the ecosystem in a critical time for the market is multiplied.

314159265359879 commented 3 years ago

I have heard talk of a series of smart contracts that might make this possible with the current structure.

jcnelson mantioned this "exchanges can easily create a "futures" smart contract that will allow a user's STX to remain liquid while they're Stacked. Please see my original explanation to Alex for details, as well as find links to all the Github discussions we had about it over the last year when SIP-007 was being designed: https://forum.stacks.org/t/hiro-s-feedback-on-stacking/11680/8. As far as I know, exchanges haven't even begun to explore their options here."

It is my understanding that such a futures smart contract will allow users to remain liquid while stacking.

cuevasm commented 3 years ago

Thank you! I hadn't seen this yet or maybe hadn't connected the dots, super helpful.

jcnelson commented 3 years ago

@cuevasm If you only care to read about how to address this problem, then please scroll to the end of this comment. I can't let most of what you wrote go unaddressed, however, since there are more than just you and me reading this.

@cuevasm I think you may be missing a key point here, and this is perhaps our fault for not being more clear, this entire push IS coming from the community and from other key stakeholders.

Re-quoting myself, since I've already answered this point:

@jcnelson A few posts on Github isn't consensus -- we need to see that miners will overwhelmingly vote for the change with their blocks and users will overwhelmingly vote for it with their STX. And to do that, we need to come up with and ratify a protocol for doing so, which would require its own governance-track SIP.

@cuevasm None of us is making unilateral decisions here and we didn't wake up hoping to have to push a hard fork or wanting to battle anyone about the merits or philosophy of one.

Re-quoting myself, since I've already answered this point too:

@jcnelson Hard-forking the blockchain to change its monetary policy is supposed to be hard -- so hard that it can only be done with overwhelming consensus, instead of on the whims of a few people.

Also:

@jcnelson The whole point of selling a financial product manifested as a blockchain is to make it extremely difficult for a few well-connected people to change the rules on a whim.

And don't forget:

@jcnelson no one wants to use a blockchain whose monetary policy can be changed overnight. Like, what's the point of having a blockchain then? Why would anyone invest in its token, if the caprices of its developers and exchange partners can change the monetary policy overnight? Even if the change is beneficial now, the same muscles that make the change today can be flexed to enact harmful changes later.

@cuevasm Alex and I are really the messengers here and are trying to drive this forward because folks are unclear or still learning how to push something like this forward.

The codebase is open source. No one needs our permission to make a fork of the Stacks blockchain with new rules. They don't even need to tell us that they're doing it. I find it highly unlikely that these two things are simultaneously true:

But as you point out later in your comment, a hard fork isn't the only option.

@cuevasm We are the two that are the most on the frontlines here and have the vantage point between infrastructure providers, users, and the blockchain team and have been asked by a growing number of people to see what's possible sooner than the scheduled hard fork.

As I said above, these people aren't helpless. They can speak for themselves, and some of these people can even submit SIPs and PRs that make the changes they want to see in the world.

Trying to route around this by claiming to be their unelected representative is going to get you nowhere in the governance process. To be clear, "you" here isn't just you, @cuevasm; it's everyone who reads this in the future.

@cuevasm The continuous Stacking issue is a universal problem/impediment to overall growth. You can count my and Alex's representation on this for multiple miners, multiple exchanges, 5-10 community members, and a handful of other integrators and partners of the ecosystem.

A few things:

Okay, this is the part where I talk about altering Stacking without doing a hard fork.

@cuevasm Fundamentally, can this issue of continuous Stacking be solved without a hard fork? I have heard talk of a series of smart contracts that might make this possible with the current structure.

Yes, it can! I wrote about some of these solutions in the original forum post.

As @314159265359879 points out, you can write a smart contract that keeps users liquid while their STX are locked (through a stx-future derivative). Instead of Stacking directly, I Stack through a smart contract that mints me a stx-future token for each STX I Stack. The contract takes possession of my STX, executes the PoX stack-stx function with them, and it mints me an equivalent amount of stx-future tokens.

Now, instead of having to miss a reward cycle, I can trade my stx-future tokens for real STX on the open market and re-Stack those STX anytime before my locked STX tokens unlock. Since there are just as many stx-future tokens in circulation as there are locked STX, and since the only purpose of the stx-future contract is to use them to reclaim STX tokens that were locked up by the stx-future contract, the price of a stx-future should should follow the market price of STX.

Recall that once my real STX tokens unlock, they will be owned by the stx-future contract that I Stacked them through. We'll use this to ensure that whoever holds a number of stx-future tokens can go to this smart contract and redeem them for the same number of now-unlocked STX (thereby decreasing the supply of stx-future tokens). It doesn't matter who currently owns the stx-future tokens when this happens -- it could be me coming back to the contract and redeeming my stx-future tokens (if I didn't trade them), or it could be whoever I traded them to coming back and getting their due STX.

This is way, way easier and far, far less risky than a hard fork, and it can be done today. Also, no one in the ecosystem is blocked on implementing this. In fact, when I mentioned the possibility of doing this on the Stacks discord, a couple of prominent community members said they were already working on it!

So, please stop asking for a hard fork, and stop making unfalsifiable representations that there is a desire for a hard fork, when far safer and far easier options exist.

cuevasm commented 3 years ago

Driving forward the gathering of information and requirements, and driving forward the hard fork are not the same thing. Some level of support and translation are needed and proper here given the early stages we're still in. I'm very familiar with the factors at play here, feel free to trust I'm not going to step into territory I shouldn't.

Consensus starts with a few voices/posts and grows as discussion progresses, I'm aware a sip would be needed at some point. The comment about representing folks was poorly written, I simply meant to communicate to you that this isn't my agenda alone and that were a hard fork the only solve, it's not unlikely there would be a community push for one.

Everyone here is trying to do their due diligence, the community is still learning how to do this, certainly some guidance and hand holding from the more familiar is appropriate and welcome as they build this muscle. You said yourself even the work itself would likely need core devs, so certainly helping everyone wrap their head around the issue and options before that would also require some input and support from the 'well-connected' too.

Let's assume best intent. Were a fork actually to move forward, the folks that have happened to chat with me are absolutely willing to submit SIPs, pull requests, and put up resources - we're still in fact finding here whereas I feel like being you've jumped a few steps ahead to fight a fork. You've also repeated to me the message that a hard fork should be difficult which I never argued or indicated otherwise toward. No one is trying to take things lightly or insult the integrity of the monetary policy by having a discussion. I frankly regret even mentioning a fork earlier seeing as how it's dominated the discussion despite only being intended to remind everyone that it's really up to them, that if they really want to fork, even for something you or me think they shouldn't, they can.

The sense around this topic is one of rejection (because of immediate reaction even to hypothetical discussion of a fork in some places) and I think it's quieted some voices. In general, I think that's something we should all keep in mind in public discussions like this. Not everyone is comfortable with discussions of this tenor, don't have a rich history of working together where they've built mutual respect on which to have it (❤️ you Jude), and further, will take the opinion of certain influential people as gospel and clam up despite what they really want.

Last on this process, I'll again repeat that I've NEVER asked for a hard fork. Maybe others have and you're attributing that to me. I've asked for more clarity on what it takes to do one. I've respectfully sought your opinion on one as someone with the right knowledge. And, I've rejected your outright rejection of one in hopes of getting to a solutions oriented discussion where nothing (including a possible fork) need be eliminated before it can even get started.

All that out of the way, I'm ecstatic to see this other thread about a solution. Are you able to make connections to the community folks you mentioned? I'd like to see how I can support them and learn enough to take back to exchanges and partners as an option.

Last, are there other possible solutions we should surface as well?

jcnelson commented 3 years ago

I went ahead and wrote up a prototype stx-future contract here: https://github.com/jcnelson/stx-future

friedger commented 3 years ago

The current protocol provides an incentive to stack for more cycles at once. If continuous stacking is coming there should be a similar incentive. For example:

314159265359879 commented 3 years ago

The current protocol provides an incentive to stack for more cycles at once. If continuous stacking is coming there should be a similar incentive.

Why is it incentivized in the current protocol? I am not sure it was intentional or that it should stand with this proposed change.

I ask this question because of these snippets: by @agraebe "This would imply full confidence that SIP-007 was describing the exact behavior. I just reviewed it again and I don't see a callout that would explain clearly that continuous stacking shall not be possible..." And @jcnelson replied "It doesn't say that it's required either. As I've said here and elsewhere, it can be addressed in Stacks 2.1..."

As I see it there is already an incentive to stack for 12 cycles at once. Convenience: you only have to look at it again after ~6 months. It has its risks for a stacker, stacking for exactly one slot with the exact amount required (ie 80K), because the minimum requirement can go up (say 90K).

If it is beneficial for the consensus model that owners of stacks stack, I do not think the protocol has to force them in one or the other direction, stacking long term or stacking short term.

friedger commented 3 years ago

Higher risks should result in higher returns.

314159265359879 commented 3 years ago

Higher risks should result in higher returns.

I disagree if that means the penality is hurting a stacker with a small stack of stx (or small pool) compared to a whale or big pool. Decentralized systems benefit from more participants in the network, and hence the protocol should not penalize stackers with a small bag.

friedger commented 3 years ago

This is the same for any stacker whether solo or a pool.

314159265359879 commented 3 years ago

This is the same for any stacker whether solo or a pool.

Ah yes I understand. That was not so clear from my reply. Perhaps I should have included an example consider this based on users on telegram. One user/pool has stacked 70.000 stx and we compared this to a pool/stacker who stacked 10.000.000 stx. Now both stack for 12 cycles. After 1 cycle the minimum goes up to 80K.

70k stacker/pool: He will have no profit after the first cycle. 10M stacker/pool: He fills 125 slots instead of 142 after the first cycle and he's actually 100% stacked whereas 60k/10M stacks being unused with 70k slots.

If #7 is implemented the stacks unusable for a slot would unlock so someone can restack at a bigger pool or with a bigger bag. If the unlocking still happens after the cycle has started it would have a very unpleasant effect for (new?) network participants, they lose all profit for a cycle. It is probably not possible to allow unlocking stacks as per @jcnelson comment there (#7) "Also, I think this might be illegal -- I think there was a reason Hiro engineers had to make it so people have to explicitly lock their tokens and keep them locked." Which means that people (or pools for that matter) with a small bag have the most to lose when stacking long term. Whereas many small stackers are more valuable to the network then a few whales.

I stand by my point that it should be as easy as possible to stack for the duration deemed appropriate by the stacker. Let pool operators incentivize longer stacking periods by lower fees. That way users who are looking for a reliable pool can test with one cycle without being penalized and once they deem it reliable they can commit to many cycles.

That way the number of cycles committed will be a measure of pool operater reliability or network reliability. Not based on a fabricated penalty/reward?

jcnelson commented 3 years ago

"Also, I think this might be illegal -- I think there was a reason Hiro engineers had to make it so people have to explicitly lock their tokens and keep them locked."

Ah. Here, I was referring to ensuring that people who are getting BTC yield are actually doing something to help the network. Keeping your yield-bearing tokens locked ensures that there's a meaningful signal in the stack-stx call's start-burn-ht argument (which itself signals that you expect PoX to be active at a future block height -- a statement to miners about the health of the network). This form of signaling -- i.e. STX holders continuously doing useful work for the network -- is what I was saying had to be maintained.

We've discussed the possibility of ensuring that only STX tokens that will clinch reward addresses will get locked (https://github.com/blockstack/stacks-blockchain/issues/1857). Because this also requires continuous signaling, I think it would be okay to build out for 2.1.

In general, I think that making it so STX that don't clinch a reward address should not be locked is something that should be added in 2.1. Similarly, I think that making it so you can re-Stack your STX just before they unlock could be added, as well as making it so you can "top off" your lock somehow in case the minimum threshold increases again.