There is no elegant way to remove liability except to relinquish control entirely. Multi-sig or not we would not retain the ability to modify information. Third-parties should be curating this information to provide to the public. I tend to lean towards a DAO structure as the contract already limits the owner to only being able to change the fee.
Perhaps it would make sense to post up the contract code @tezit to prevent confusion?
I started something like this a year ago called the “Baker Index Project” - a non-profit project.
So we can use that as a place to get started, and I can lend insight into the process of gathering the data. There have been 27 bakers registered so far.
Please add your baker if you haven’t already. Let me know if you have any questions.
During the TQuorum Global Summit @adrian shared in a workshop about “programmable staking” his vision of how staking will look like in the future ex. a dedicated address format for baker contracts which as far as I know will be described in a baker contract standard.
In my opinion having crucial information like a human readable baker name should be directly in such a standard.
Alex from TzStats here. Just found your proposal, thanks! I had given the topic some thought before, so here are my comments:
The on-chain data you designed is too verbose and requires too frequent updates, resulting in high tx fees and overall it’s too risky for bakers to use their private keys for signing contract calls. Nobody would want to use it.
I think a single on-chain registration of a very limited piece of information has to be sufficient. I propose to only track a baker’s public DNS name along with the public key hash (the address) on-chain, preferably in a big_map. That way we have a verifiable anchor of truth on-chain and that’s all we need.
From there anything else could be obtained from the baker’s web server either:
To verify integrity a Baker could publish a signature for the JSON-LD data generated from the private baker key. However, that seems overkill and bakers with HSMs may not be able to do this anyways.
The benefit of this spec is that it allows a natural evolution of the publishing standard through versioning without requiring to store large amounts of data on-chain or updating on-chain data on every change.
On top of that, such a DNS-by-Tezos-Address registry could serve other purposes outside baker info maintenance.
Thanks for joining the discussion, we need as many voices as possible involved.
As others have pointed out, the Tezos Name Service (TNS) concept is very important for many reasons to the ecosystem. There are others working on such solutions and I encourage everyone to engage in those discussions.
The bakers registry is not a TNS – it only contains the baker name until a viable TNS exists at which time the bakers registry would drop the name from the schema.
Regarding your 2 concerns about the proposed schema and solution:
overall it’s too risky for bakers to use their private keys for signing contract calls
The proposed solution includes a “reporter” account specified by the baker to avoid the problem you correctly point out.
too verbose and requires too frequent updates, resulting in high tx fees
Can you point to exactly which proposed fields you think would change often and lead to high tx fees? This is exactly what we are trying to experiment with and determine what is the correct data that should be stored onchain. The proposed schema outlined here is the result of many discussions with bakers and others.
I encourage everyone to share their thoughts. We still need more feedback on the proposed schema and solution. In order to encourage more discussion I am planning to release an mvp version onto mainnet for bakers and aggregators to test (alphanet would be preferable but I don’t think we will get enough bakers to participate if they have to create new accounts).
Oh, the schema is good. It’s just that I believe there should only be a minimal anchor on-chain. Ideally this anchor is registered once and does not need to change afterwards. Like in all standards you want to retain the ability to evolve over time, adjust to usage patterns and embrace new use cases. In blockchain this is hard because smart contracts are often not updatable and on-chain data is expensive to change. With expensive I mean that somebody (a) has to pay tx fees to do so and (2) construct+sign a smart contract call.
Frequent updates will occur at openForDelegation and sub-fields of feeModel (implicitly also bakerRegistryLastUpdated). I don’t think such things belong on chain. Especially not in JSON format!
Also the extra fees seem a bit arbitrary unless you want bakers to pay for your dev efforts, which is fine.
If you really like to limit signup to active bakers, here’s a trick: you could test if a caller is actually an active delegate by setting your smart contracts’ delegate to the caller and immediately resetting the delegate on success. If the first set_delegate op fails, the caller was no delegate to begin with.
This is more excellent feedback. You are absolutely right that one of the biggest challenges moving forward will be versioning not only the contract, but the data schema, the parsing APIs, and all related tooling.
For the first version we also have a desire to actually use the Tezos blockchain, so we might be erring on the side of too much data onchain. But given that the fields such as openForDelegation and feeModel will likely not change too often and that updates will be at a cost of “dues” (likely around 1xtz) and fees of less than 0.08xtz it does not seem too prohibitive as a starting point.
bakerRegistryLastUpdated is not a user entered field, it will be modified by the contract on each update.
The schema is displayed in the FAQ as JSON format for readability as it will be parsed into by the API and used by most participants integrating with the data. I currently have 2 versions of the contract, one which is well typed and one which is just bytes. The assumption is we want to store it well typed, but as I’ve worked on the entire solution the more I think that’s an open question for us to test and discuss.
Regarding the extra fees (“dues”), this is not intended as payment for dev. It’s primarily an anti-spam mechanism which is not effectively dealt with by using the “set contract delegate” you suggest. I looked into that but since it doesn’t cost anything to register as a delegate, verifying that the caller has registered doesn’t buy us much and only ends up being extra michelson code for little benefit. A small fee seems to be a better gate for now as the fees would be enough for TCF to originate a new contract if needed.
The more input we get now and as we test out a simple version the better we can all decide how to move this forward. TCF will originate a test and if that goes well then they will originate the first production version. We will learn how to deal with all the versioning issues that come up and eventually move it all to a baker association multisig or DAO.
@pascuin Yup also we’re working on a not-for-profit (for grant proposal) project called bakepool.org in which delegates can delegate to an organized pool instead of to an individual baker. Pools will be able to compete with each other based on the particular qualities of their pool. To do so they’d need to vet (by their own standards) a collective of bakers. Readily available self-volunteered baker data would be helpful for this as well.
I’m very interested in this topic. I have a small (non public) baker and it would be very useful in order to be listed and, possibly, grow larger.
Welcome to the discussion, now that Babylon has been successfully applied we will soon be originating a beta test of the Baker Registry contract.
Your feedback as a new baker adding yourself to the registry will be very helpful.
Tezos Commons will be originating a test of the Bakers Registry on main net over the weekend. We will post more details soon, but we encourage all public baker services to take part in the test and give us feedback. MyTezosBaker, BakingBad, and Tezos-Nodes have been very helpful and agreed to share their public baker data to help TCF pre-populate the contract storage.
For better security, the registry contract allows bakers to specify a “reporter” account so that they don’t have to sign updates to the registry with their baking key. If you would like to have your reporter account added to the initial data please direct message me on Agora, Slack or Telegram.
Excellent initiative.
Glad to be help. Welcome any time!
The template for the on-chain data talks about “fees”. While that’s a popular way to talk about what bakers do, I think it’s a perniciously harmful viewpoint which promotes the mistaken idea that the baker’s block rewards somehow belong to someone else.
I agree the bakers would be well served by communicating more clearly about the payouts and that all rewards belong to the bakers until they decide if they want to make a payment to the delegation for having “rented” their rights to the baker.
Maybe the registry can be a good first step toward helping the ecosystem transition to this new messaging around how rewards are paid by the protocol and therefore belong to the baker.
I’m asking everyone to give feedback on these proposed changes to the registry as we are planning to originate a contract very soon.
The beta terminology is that bakers charge a “fee” on the rewards they earn for their delegation. The implication is that that the rewards belong to the delegation and that the baker custodies them until they are paid out.
Example 10% fee: after a number of cycles defined by the schema field “payoutDelay” the baker pays out 90% of the rewards and keeps the 10% fee.
The baker does not bake rewards that belong to the delegation. The baker rents the rights rents the delegation, earns all the rewards, and pays out a rent that may or may not be dynamically determined based on how effective the baker was at making use of the rights from the accumulated delegation staking power.
Example 10% fee changes to 90% rent: rent is paid after a number of cycles still defined by the schema field “payoutDelay”
Implementation: see current schema in the top post
edits: added clarity that the delegation “rights” don’t actually exist at time of delegation, and thus the baker is renting/compensating the delegation act rather than the rights
That’s true, and it’s been stuck in my mind as a hang up as well. But in playing my own devil’s advocate, since there is a fiduciary responsibility (despite no legal obligation) in the form of an expressed agency relationship between the baker and the delegate XTZ holder, those rewards are (in a soft sense) indeed someone else’s, and “fees” or “agency fees” would be accurate though no?
Other agency relationships work in that way as well. Like an actor with a talent agent. The talent agent can take the check, deducts her fee, and passes the rest to her client.
No that’s exactly what this is NOT like. The talent is the baker, you have it all backwards.
In Coinbase’s staking announcement, they say:
The Tezos network sets the underlying return rate depending on the number of staking participants. Coinbase distributes the return to customers and keeps a portion as commission.
Do you agree or disagree that it could accurately be described as a commission? If not, do you have any suggested alternative word or words? And can you please give us a more clear description or analogy of what the relationship between a baker and a delegator is or is like?
I know that, in your view, bakers would ideally keep the entirety of the rewards, but I would have a hard time attracting anyone to delegate to my baker if I didn’t offer them something in return when virtually every other public baker is doing so. And anyone who delegated to me under those circumstances would understandably feel entitled to “their portion” of the rewards.
I disagree that the word “commission” is a good description. I’m not saying bakers shouldn’t pay delegates, I’m disagreeing with the idea that the rewards somehow “belong” to the delegate and that the baker is a service that helps them obtain it for a fee. Bakers buy / rent baking rights from delegates.
Important to remember that Coinbase is very different from your typical baker. Coinbase has done all the regulatory work to establish themselves as a legal custodian of other people’s funds. As such they are the one in control of most of the funds delegated to their own service.
For most bakers you don’t want or need to ever be holding funds that belong to someone else. The Tezos protocol grants rights to a baker which are utilized by a baker to earn rewards to a baker.
The non-baking token holder only has the ability to delegate their token balance. This delegation is worth something to a baker as the baker can make use of it to generate rights for itself.
The non-custodial relationship is that a baker rents/compensates a token holder for delegation. But the rights and the rewards are very specifically given to the baker by the protocol. The baker does not custody rights or rewards for any entity unless they want to establish an offchain private agreement to that effect. Instead the baker pays out either a fixed or dynamic amount as rent/compensation for the delegation.
The subtle but very important distinction is that the token holder is not paying the baker anything that resembles a fee for a service as this implies a relationship that does not truly exist and generates potential legal complications depending on your jurisdiction. Instead the baker is paying a type of rent to the token holder for the delegation. It can be difficult to communicate this distinction but it’s important to be accurate as this is how the protocol functions.
