First, of course, the community has a say! Development teams do monitor community platforms like agora, reddit, riot or slack. We also keep in touch with smart contract developers and language teams, as well as bakers and other users. The channels used to coordinate the proposals are also open and transparent, such as Gitlab. However, the final cut on what gets in the proposal that we build and endorse (as opposed to what gets rejected or delayed) is mostly a matter of engineering and code quality. And then of course, the last word goes to the voters, which has an impact on the choices we make about the features on which we concentrate our efforts.
2 Likes
The current plan is to have 3 different proposals: one with baking accounts only, one with sapling only and one with both. All of them will include the same smaller changes.
4 Likes
The first year the foundation was by far the largest actor in the network, so the fact that there are new services adopting Tezos is actually a sign that the network is more decentralized now. With more adoption will come more diversity.
3 Likes
Will the consensus key retain the right to spend in 007, independent of the operator account?
2 Likes
Hi Justin,
My question on your Stateful Baking Account proposal is will the consensus key always be spendable, in and of itself, independent of the operator account? [âŚ] So the question remains is the consensus key always spendable in this update, independent of the operator account?
- As described in the blog post the implementation of stateful baking accounts maintains the consensus key as spendable in order to be as backwards compatible as possible with the existing tooling, such as payout tooling.
If not your proposal is fatal to the chain from a security prospective.
- The proposal for stateful baking accounts contains a spendable consensus key as described in the above bullet point.
1 Like
Hi Klakplok,
Does Nomadic have someone watching Riot?
I know Adrian is in there but he doesnât count. Many of us have been bringing up security concerns with giving bakers smart contracts, and breaking out key roles, since Adrian first announced his ideas over a year ago.
The issue is that nowhere does Cryptum Labs now Metastate consider down stream negative effects.
Their blogs are often hyped and inaccurate at critical points. Nor do they take time engage in conversation to defend their ideas. From example I wrote a micro-economic critique of Adrianâs programmable staking proposal over a year ago, after spending a week trying to talk to Awa and him. No concerns were ever addressed. https://medium.com/@MindsFiction/cryptium-labs-swings-a-death-blow-at-tezos-964e4123888b
This leads to questions like what does Nomadic think about Adrianâs wild ideas? If any answer is given its usually Awa reassuring the community that they are working with Nomadic. Which isnât an answer but it does allow her to use your reputation.
Can Nomadic have a developer in Riot? At the moment Adrian is viewed as Core development which is a problem for those of us who value the chains security.
Thanks,
-Justin
P.S. Iâm looking forward to Sapling. Its been a long time coming. Well done. 
3 Likes
But they said they would âpassâ every single proposals.
Before the giants Coinbase, Kraken and others were there, the voting power of all âsmallâ bakers had much more power. I feel like now, at the current state, the giant bakers are too powerful and I believe it is a threat for Tezos and its decentralised governance.
1 Like
Hi Awa,
You did not answer the question. Nor could you because you donât understand it. This is why I asked Adrian.
Yet your response is just a boilerplate of the flawed blog post. For example the âconsensus key will remain capable of authenticating spendingâ but its just 1 of N in the operator accounts multisig. One could make it 2 of 2 multisig and the consensus key is no longer spendable in and of itself.
Which is a security fail the reasons I already highlighted.
-Justin
4 Likes
No Discord? 
1 Like
I was thinking specifically about protocol releases. Would be great to have all the various efforts documented in one centralized spot - creates more visibility on what to expect in the coming months/years.
2 Likes
Answer to Justin please.
1 Like
This is a question to Cryptium Labs/ Metastate :
How many times are you going to propose âbond poolingâ with different names? This proposal looks like Burebrot 3.0 and you guys are still insisting about an idea vastly refused by the community during years.
Also, please specify if you are receiving grants for âbond pooolingâ / âprogrammable stakingâ developing.
Finally, as granted dev team, I think you should be ultra-mega-clear about the specs of your future proposals. Please no more several blogs entries for describing a unique proposal prototype.
2 Likes
Hey @gholadr, this is something we could try to present/organize on Agora if youâre interested. What would you specifically like to see?
2 Likes
Hi Justin,
Thanks for your questions.
See our reply below, #1 and #2.
#1
Yet your response is just a boilerplate of the flawed blog post. For example the âconsensus key will remain capable of authenticating spendingâ but its just 1 of N in the operator accounts multisig. One could make it 2 of 2 multisig and the consensus key is no longer spendable in and of itself.â Justin / seinca / MindsFiction
As explained in detail in the blogpost , that you only partially quoted, the consensus key is able to authenticate spending, as well as governance transactions independently of the operator multisig. To quote directly from the blogpost:
Thus, the consensus key will remain capable of authenticating spending as well as governance transactions.
This sentence can be found in the last paragraph of the section âThe design of stateful baking accountsâ.
#2
Which is a security fail the reasons I already highlighted. â Justin / seinca / MindsFiction
The current implementation of stateful baking accounts maintains the consensus key as spendable and able to authenticate governance transactions. Due to this fact, your concern is not relevant towards the discussion around the possible 007 proposals, and hence beyond the scope of this AMA.
However, for the sake of clarity it is important to point out that your security analysis of LPoS, which is a specific instantiation of PoS, is flawed and that the security of LPoS does not derive from the fact that the consensus key is spendable. A spendable consensus key is a nice cherry on-top for LPoS, however LPoS is secure due to having slashable security deposits (from committing consensus faults, such as double-signing consensus messages). Some suggested reading to gain a better understanding of PoS security can be found in these references:
- Vitalik Buterin - On Stake : On Stake | Ethereum Foundation Blog
- Vitalik Buterin - Weak Subjectivity: Proof of Stake: How I Learned to Love Weak Subjectivity | Ethereum Foundation Blog
- Enhancing Baking Accounts: Enhancing Baking Accounts | Protocol Research & Development | METASTATE
- What is at Stake in the Tezos Protocol?: Half-Baked is Always Better than Double-Baked â What is at Stake in the Tezos Protocol? | by Awa Sun Yin | Cryptium Labs | Medium
Again, even if this is out of scope, for the sake of clarity, letâs perform a thought experiment:
If the security of PoS in general, and LPoS specifically, was only derived from the fact that the consensus key is spendable, then it could be trivially broken today using trusted execution environments, such as the Intel SGX. An Intel SGX could allow you to generate a consensus key, which can sign blocks and endorsements but requires a multi-signature input in order to sign transfers. Using this system, one can simulate a non-spendable consensus key today. Due to this, if your analysis was correct, it would not only imply that almost every PoS chain (Cosmos, Polkadot, NEAR, and eventually ETH2.0) is insecure, but also Tezos.
Nevertheless, LPoS and Tezos are fundamentally secure today, even in a world with trusted execution environments, because the security of LPoS and PoS is derived from slashable stake and not from whether a consensus key is spendable or not.
Finally, it is important to stress again that the implementation of stateful baking accounts for 007 maintains the consensus keyâs ability to authenticate spending as well as governance transactions.
Thank you, Justin, for participating!
6 Likes
sure why not @governancy! I think we should identify core development players, ie dev teams working on the protocol itself and try to present a clear representation of who is doing what, with expected/anticipated delivery dates.
then, find a home where to present this information on a regular basis, maybe monthly or weekly if there is enough momentum to warrant it. Iâm guessing this forum would be the preferred way to share the âroadmapâ but Iâm not married to it so open to suggestions.
5 Likes
Yes, I like it! I always thought about a âtimelineâ where the teams can integrate milestones by themselves and make transparent when a specific feature/product will be released!
3 Likes
Metastate,
Lets recap. You posted your Stateful Baking Accounts proposal on May 6th. In which the consensus key was non-spendable. This matches your gitlab merg request for Stateful Baking Accounts which has the consensus key as non-spendable.
Both your initial code and your blog spec had the consensus key as non-spendable.
At this point many of us raised concerns about having a non-spendable consensus key. Documented on this agora thread. Then you silently updated your blog to make the key spendable. This was dishonest. You should have told the community directly on the Agora thread which you were engaging on. Nothing wrong with changing ones mind.
However your blog states that you made key spendable for âbackwards compatibilityâ.
Which likely meant you were going to have the consensus key be 1 of N on the multisig contract- easy to implement. The problem with this is if you set the multisig to 2 of 2 you get the same security issues as having a non-spendable key.
This is why I asked specifically âconsensus key always be spendable, in and of itself, independent of the operator account?â while fully quoting your blog post in the initial question. So we could get the key changed to always spendable independent of the multisig. Initially you didnât understand the question, so I had to ask again with an example, and quoted the part that mattered. Of course you lied about the quoting.
At this point the community has burned several weeks getting the proposal tweaked to be more secure, and therefore passable. People have been ignored, gaslighted or given non-answers while on the backside those who are connected see our comments and get Andrian to fix his proposal.
This is a critical point, notice none of the big bakers are here in the AMA asking questions. Why are they absent at this critical juncture? The answer is Awa and Adrian deal with them in private chats and private conversations. This is the Tezos cartel.
This informal cartel is also why Metastate gaslights people and pretends they already made the changes even though the public record shows otherwise. Itâs to maintain an illusion of authority. They donât need the plebs they already have built the support in private channels.
Even now, Metastate has no clue about security nor the implications of their changes. They spam non related links while still arguing for a non-spendable consensus key. This strawman argument doesnât even pass a smell test.
Iâve consistently stated that there are many incentives that secure the network. One of which is having the consensus key spendable because it is a bounty on the node. Node operators secure the node to defend against hackers making the Tezos ledger more secure in the process. Second slashing exists to punish bad baker behavior, not for node security. These are separate incentives that work together to help secure the network. Yet Metastate clearly shows they do not get it by arguing for only slashing.
The other obvious issue that Metastate ignores is the centralizing aspect of non-spendable consensus keys. Which is perhaps the most critical.
Digging further into Metastates merg request you can also see Adrian championing an implicit feature of having one physical baker for multiple operator accounts. Again this is a security fail as it allows any physical baker to grow without capital constrain, also incentivizes fewer nodes to run.
Up until this point Iâve been trying to get their proposal functional by pointing out issues but given Metastate is not ethical, I cant trust their code. Given they donât understand basic security, again, I canât trust their code. Even if we keep getting them to fix all obvious issues, I doubt Adrian has thought of all corner cases.
This proposal is high risk and low reward even though bakers need the ability to change their key.
-Justin
3 Likes
Both your initial code and your blog spec had the consensus key as non-spendable.
At this point many of us raised concerns about having a non-spendable consensus key. Documented on this agora thread. Then you silently updated your blog to make the key spendable. This was dishonest.
It is absolutely not the job of developers to hide their features when thereâs a disagreement with the community. You are being paid, start acting like it.
3 Likes
