Agree, we will need additional time to coordinate a multisig contract. Make sure the right teams are involved especially if it is 7. Right now we need more feedback on the schema.
1 Like
not all bakers a delegation pools, if I just bake for myself, I don’t need any information publicly and I should be able to bake without providing any additional information.
2 Likes
Just a few thoughts on tonoff`s response:
1.) … there is centralized control (TCF)
The problem I see without this is that people could post illegal content to the contract and there would be no way to remove this, compared to this, centralized control by TCF is better, this is about weighing options and solving problems, not about die-hard decentralization ideology.
- & 3.) i dont think this project should be extended to serve as a name registry, a name regsitry contract would be quite simple in comparison and can stand on its own.
9.) … off-chain registry.json file in the root of their web-site and nowhere else…
what about DNS blocks?
IPFS urls ( via cloudflare or infura ) should work too.
12.) Add “Status” - active or not. This is an suggesion.
There is no one to maintain that on-chain, and listing services can get that info easily.
1 Like
The proposed baker registry is only for bakers who want to share information publicly with potential delegators.
Eventually these public bakers might want to create a DAO to organize and make decisions around standards, but even if that were to happen they would have no power over private bakers.
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:
- from HTML header tags (like used by embeds on social networks, e.g. Twitter Cards)
- or as JSON-LD structured data (like supported by Google Structured Data)
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.
1 Like
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.
1 Like
@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.
3 Likes
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.
8 Likes
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.
2 Likes
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.
Bakers Registry Rent Terminology
Beta Schema
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.
Proposed Schema Change
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
- change feeModel to rentModel
- change feeModel.fee to rentModel.rent
- change feeModel.rewardsPaid to rentModel.rentFormula
Possible Alternatives for Discussion
- If Rent is too loaded a word, maybe a more neutral alternative such as Split
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
2 Likes
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.
