Stateful Baking Accounts

Research and Development
#1

Abstract
In this article we will describe the specific implementation of Stateful Baking Accounts , which has been further refined from the feature design path A) that was briefly described in the previous article. Moreover, this article details what Stateful Baking Accounts would enable and how it would achieve it.

Link to full article here: https://medium.com/metastatedev/stateful-baking-accounts-d483a63a173c

Other resources

7 Likes
#2

Operator account : The operator multi-sig will be set to a 1 out of 1 multi-sig with the key being the former implicit account used by the baker. Note that afterwards, should the baker desire so, the multisig can be set to 1 out of n .

Question: baker tz1abc with a balance of 20,000 XTZ will see its balance transfered to the multi-sig contract?

1 Like
#3

The balance will be controlled by the same set of keys and will be tracked under the SG1 (baker) account.

#4

Being able to rotate keys for bakers is essential. What I don’t understand is why the SG accounts are still being implement as these were needed for programmable staking. My initial impression is that the solution sounds bloated or is an attempt to slow roll the community into programmable staking.

Would be great if someone from Nomadic could weigh in on if this is a clean technical solution or not.

1 Like
#5

What I don’t understand is why the SG accounts are still being implement as these were needed for programmable staking.

  • SG accounts add structure and logical separation for the functionality of bakers. This structure is required to enable functionalities, such as key-rotation. In case you haven’t read the article yet, you will find more detailed information about the design by navigating to the article and scrolling down to the section “The design of Stateful Baking Accounts”.

My initial impression is that the solution sounds bloated or is an attempt to slow roll the community into programmable staking.

  • The architecture and implementation of Stateful Baking Accounts is characterised for cleanly distinguishing the different account types (implicit accounts, contract accounts, and baking accounts), by encapsulating the logic and storage of each account into its own module. Additionally, this future-proofs the accounts system and makes the codebase more maintainable going forward. Finally, this design enables easier testing of the accounts system.

Would be great if someone from Nomadic could weigh in on if this is a clean technical solution or not.

  • Possible features under research and development by Metastate, Nomadic Labs or individual contributors are being explored, designed, and implemented in collaboration with core development teams and a number of individuals contributors.
2 Likes
#6

Hi Awa / Adrian looks like you have re-branded Cryptium Labs into Metastate.

Your proposal is dead on arrival. Dozens of members in the community have already highlighted to you - for over a year - that breaking out a spend key from the consensus key destroys the security of the network.

Bakers secure their nodes in order to secure their funds. By removing the ability for the consensus key to spend you are removing the primary reason bakers secure their nodes, financial risk. This will lead to insecure setups, like bakers leaving their consensus keys on their hard drives rather than today’s hardware security modules.

While it is unlikely many single actors are going to spend the time to hack nodes for their consensus keys, state actors and possibly rival chains may do so. You are allowing catastrophic risk for the sake of convenience which is a security fail.

Since you initially introduced Burebrot over a year ago the community brought up two basic protocol security concerns one was the issue of in-protocol lending imploding the baker fee market, and the other was breaking out the spend key from consensus. Now over a year later you have failed to address the spend key issue. If your “collaboration” with developers is anything like it is with the community then you are not collaborating but dictating.

The Foundation bringing you both in house at Zug was a mistake. I believe this is likely why instead of taking feedback, direction is dictated because the board who is paying you gave the nod.

Hopefully things change going forward.

P.S. I am not a fan of bringing up concerns without solutions, so I’ll suggest two.

  1. Make the consensus key spendable.
  2. Scrap the re-packaged Burebrot bloat and implement a native solution. You could have a special transaction type to change the key, for example. Simple.
#7

I am not sure if you are operating a Tezos bakery yourself or if you are part of the team, that operates it.
Either way, having the ability to do a key-rotation and having a separate consensus key and spending key brings much needed functionality for Tezos bakeries operators IMO.

I don’t understand how separating consensus key and spending key will destroy the security of the network. Bakers are still having the risk of being slashed for doublesigning. Nothing changes regarding this -> bakers will still need to secure their nodes.

disclaimer: we are operating HappyTezos bakery

1 Like
#8

Hey Andrew its Justin, it was great meeting you at the TQ event last year.

I think this depends on ones view.

If you think Tezos should remain a secure chain - one worthy of being a monetary instrument - then security is paramount. If the view is more around STO or just game use cases then security can be traded for convenience.

I’d put the monetary instrument valuation well over 100 billion marketcap, over seven years. I don’t know how to evaluate an STO/game database, it cant be worth much.

Bakers need the ability to change their key in the event of suspected comprise. Even though this too is a security trade off. Because it enables secondary markets, where bakers can sell their delegates to another baker. This makes reasoning about a 51% attack more difficult. Yet I support bakers being able to change their keys. Notice Adrian and Awa never mention this obvious risk. Nor do they do analysis on it, as any core developer proposing it should.

The primary reason that bakers secure their nodes is the bounty the node has attached to its key, not slashing. This bounty is the reason every baker obsesses about security and so secures their node.

Bakers are unlikely to obsess about some remote chance a hacker takes the time to swipe their non-spendable consensus key and gets them slashed for lulz. Many will leave the key on the disk rather than hardware wallets, over time. Which greatly undermines the security of the network. Because state actors and rival chains would be the hacker exceptions. This would take years to play out but fatal if it occurs.

Notice again, that Adrian and Awa do not do analysis on their new network security model which removes the key bounty in favor of only slashing risk. Any core developer proposing large security trade offs should have analysis supporting their new model.

Another point if you’re serious about slashing risk being the necessary incentive to secure the chain you can make a strong argument for in-protocol lending (bonding pools/self-bonding) as Awa has previously.

Overall bakers need the ability to change their keys. Yet removing the key bounty, and going to an only slashing model for securing nodes makes zero sense from a network security prospective. Because the key bounty is the primary incentive to secure the node, not slashing. Moving to non-spendable consensus keys is trading momentary convenience for future catastrophic risk.

I think the way forward is to make the consensus key spendable. Or someone implements a native solution to just change the existing key, easy.

-Justin

#9

Hello Justin. If I understand correctly, your defining “security” more in the macro sense, i.e. “the network” - while the proposal deems “security” more on the micro side, i.e. “the baker”. It seems this is where your disagreement stems from since the incentive to secure the baking key becomes lower and thus, by the laws of the universe, the network becomes less secure while the individual baker might feel more secure, having removed the spend risk from his baking key. Am I understanding you correctly here? If yes, then this is a philosophical question but I tend to agree that the Guardians of Tezos should first and foremost look at the health and security of the network, instead of the individual baker. This is why I gave Carthage the benefit of the doubt (the argument there was similar, (but opposite) a benefit for the network but a (potential) disadvantage for smaller bakers - which on 2nd order becomes an issue for the network itself again but that’s a different discussion that was supposed to be held (but never really was)).

#10

Hi Justin!

The bakeries that are closer to being fully delegated have basically the same amount of funds, that are slashable (especially at the end of each cycle which is the point attacker would use) as their actual spendable amount.

I haven’t done a proper analysis on this, I am just saying, that there is a case where amount_of_slashable_funds is approximately equal to amount_of_spendable_funds.

I don’t think people will rush to make their bakeries less secure by abandoning their HSMs / HW wallets, since they already invested time and effort to make them secure in the first place.

#11

Hey Awa,

thank you for this thread and the resources you provide. Staking Facilities is in full support of this proposal.

First of all, consensus key rotation is a much needed feature that especially allows bakers to increase their OPsec (for example by migrating from a legacy cli keyfile to a key secured by an HSM / that can be imported into an HSM). The current implementation without rotation rather disincentivizes increasing your OPsec because moving your baker to another key would mean that you potentially lose your customers.

In regards to the question if the consensus key should be spendable, I first want to say that if I remember correctly, Adrian told me in a conversation that they will be spendable in the first implementation and would only be updated to non-spendable in a future upgrade if the community approves.

But that part aside, I would really like to see some separation of concerns here, meaning I would want to see consensus keys to be not spendable. Arguments that bakers will run less secure nodes because of this are in my opinion incorrect. A Ledger Nano S costs as of today 59€ including VAT & shipping.

That makes a Ledger cheaper than the risk of double signing and losing your deposits even on a single endorsement bond (64XTZ as of today are worth ~150€). Hackers still have the incentive to create a double bake by getting 50% of your slashed XTZ by including the accusation in their following block. It just requires a bit more timing.

So why should the consensus key not be spendable? Well, while I said that hackers still have the incentive to create a double sign if no protection is in place (like a double sign protection in a HSM), the difference for me are people with physical access to the HSM. That could be employees in the staking company (who probably also have access to the ledgers pin in case they need to restart it) or people working in the data center.
Those people have no interest in double signing you / or even can’t because of double sign protection, but they could still steal funds from you if they have access to the running ledger.

PVSS keys will not see any real impact right now, but they open up much potential for future improvements on the protocol. Activating them now gives bakers enough time to get familiar with the concept and add them to their SG1 account so that they are ready when the time comes.

Florian from Staking Facilities

3 Likes
#12

Hi Andrew,

Bakeries that are fully delegated should have no spendable amount because it is all locked up in deposits. :wink:

I agree that people will not “rush to make their bakeries less secure” but by design, this new system encourages more slack with securing one type of key vs the other. It’s like changing the laws of physics, eventually the system will gravitate towards them, slowly but surely. So yes, few people will likely make their system less secure now and in the near future but new bakers will possibly see this system and mostly care about their spend keys (makes sense, right?) and make sure to secure them first while not really feeling the same need for the baking keys. After all, who is “seriously” going to attack their baking keys and for what reason?

However, in the case of a concerted attack on the network, (say after enough bakers have simply saved their baking keys somewhere on their computer (who have been compromised)), then this might prove to be a fatal attack on the network from which there might not be a recovery. I think this is what Justin means.

This chance is remote - similarly to the remoteness of bad bakers gaming the system for some trivial advantage, which was the reason for Carthage rewards change. Nevertheless, it was hailed as a great step in adding security to the system. So if Carthage was so important to add that layer of security to prevent some theoretical and remote chance of the network being attacked, why do devs want to potentially create a similar kind of systematic security risk with the next proposal? It feels as though there is no clear line and if Tezos wants to present itself as the most secure chain for all things finance and beyond, then development needs to take this into account and create proposals that do not weaken the system, even potentially.

I see big baking services all applauding this proposal, CL, Happy Tezos, Staking Facilities. Of course, this makes it more convenient for bakers to do stuff like Florian mentioned. But as Justin says, you can just create a way to change address natively. I would much rather see that as a first step and give this discussion more time rather than another proposal being shoved down our throats. It is an important consideration and represents much more than simply making some things more convenient to us bakers. It is about the philosophy to where the network is going and if your view is, like Justin’s, and you think Tezos’ target market will be as a monetary and financial instrument, then security will be the #1 priority.

Finally, I’d like to say that network upgrades should not be made firstly with bakers in mind, but with users. (Perhaps core devs running a huge bakery is an ethical conflict?) Bakers secure the network, that is what they are being rewarded for. But they (we) work for Tezos and its users, not the other way around. Tezos is currently carving out a niche for itself and needs to become the best in something. Not everything. But something. Is that security? If yes this proposal probably needs to change.

1 Like
#13

Hi Lukas!

Indeed, this is exactly what I meant. This means that the consensus key inherently needs to be as secure as the spending key.

I don’t want to go into specifics here. We can discuss this privately if you want.

I think everyone agrees that security is paramount. What we seem to disagree on is that having the separate consensus key will have a negative impact on the overall security of the network.

#14

Hi Andrew,

Thanks for your reply. Yes, I agree there are reasons as to why there might be an attack. But these might not be obvious to all and many might discount them as unbased, hence lowering the barrier for the attack.

I believe we disagree on how the security risk arises. You, if I understand correctly, are saying that you don’t believe (current) bakers will make their bakeries less secure. This I agree with 100%. My point is that, inevitably, in some time, somewhere down the road, new bakers will arise; perhaps old ones taken over or abandoned and new bakers will be presented with the challenge of setting up their bakers and that is where slack can (and knowing human nature WILL) come into play. Without this change, this attack vector would not exist. With this change, it will. So imo, by definition, this lowers the in-built security by design. As we say in German: “A steady drip will wear the stone”. Generally, I am happy to change my mind and am glad we are discussing important topics early. Let’s hope more stakeholders will chime in.

3 Likes
#15

Is it possible for you to abstract the problem to a high enough level that we keep this in open channels? I’m interested in hearing how others perceive the problem.

#16

Sure! I just didn’t want to go too much into details.

I was just trying to say, that from my point of view it is clear, that people will need to keep their consensus key as secure as their spending key.

2 Likes
#17

Hey Andrew,

The slash is there primarily to ensure bakers behave. Slashing discourages bakers from trying to game the system. While the value of the xtz on the key is the incentive a baker has to secure their node. Sure there is light overlap but they are separate incentives that work together to secure the network.

The max delegation argument is somewhat of a strawman.

Very few bakers are fully delegated. Having extra XTZ available signals to delegates that there is space and how much. And with today’s key system if someone gets their key they can still drain their account by waiting for the coins to unfreeze. Plenty of reason for hackers to make the effort, and plenty more reason for bakers to secure their nodes.

Lets take a look at your baker Happy Tezos, you currently have 274,213 XTZ available or $685k. This immediately available bounty is why your rightly are obsessed with security, not the slashing mechanism which discourages bad behavior.

If you scroll up, you’ll see that I said “This would take years to play out”.

Yet changing incentives to allow sloppy Baker setups will have negative effects on the networks security long term.

-Justin

#18

Hey Lukas,

Exactly, its confused semantics. Security of the Tezos network should always be paramount.

I’d look at having the consensus key spendable as the primary incentive to secure the node because account can be drained. While the slash feature is the primary incentive to ensure bakers behave and don’t try and game the system.

#19

Hey Florian,

If you read Awa’s post at the top you will see their latest proposal does not have the consensus key as being spendable.

If Adrian has since changed his mind. Posting here that the consensus key will be spendable would save everyone a lot of time.

Look if your setup is physically insecure, it should only effect you. We shouldn’t have to reduce the security of the network by enabling sloppy setups to accommodate insecure nodes.

#20

Awa, if we are going to share Medium articles as sources for a discussion on Agora best practice is to make note of when changes to the source. The purpose is to keep everyone updated so nuanced discussions can continue without having to compare notes which is time consuming. Often time we might not have which discourages participation. We have been told very little about protocol 007 to date so this information is crucial on how everyone is going to vote. While the consensus key is spendable please explain how this works with multi-sig. thanks.

3 Likes
Home Learn
Get Started Wiki
Developers Stack Exchange

Be part of the conversation