I would like to invite everyone to participate in a discussion around implementing a Bakers Registry. The registry will store important data about a baker’s policies to help keep delegators better informed. I have had an opportunity to discuss this topic in detail with a number of people in the ecosystem and it is time to have a more public discussion so that we can move forward with an actual deployment very soon.
The Tezos Commons Foundation has indicated that they would be willing to manage the smart contract.
Q: What is the purpose of a bakers registry?
A: There are two primary goals.
First is to demonstrate a great use case for blockchain – the sharing of information between independent parties without central control.
Second is to reduce the friction/cost for bakers and aggregators by helping the bakers to more easily communicate timely updates to their policies and status.
Q: How does it work?
A: The core component is a smart contract that keeps each baker’s public information in its storage. Each baker will add themselves by calling the contract from their baker account specifying their information as a parameter.
The full FAQ details a proposed schema for the public baker information.
Feel free to ask any questions, but I would like to start the discusion by focusing on a few specific requests.
For everyone interested (especially bakers):
Please review both the proposed onchain and offchain json data schemas to confirm that all the information needed for you to provide your services is present
If you are uncertain about any proposed data field, please ask for clarification – one of our early goals in this discussion is to agree on naming standards, defaults, and descriptions in order to better support tools and apps that will interact with the data
For aggregators, auditors, and indexers:
Help with evaluating how we will handle history. If the contract only stores the last update which is considered to be the “current” payment model, can we rely on the blockchain history to retrieve the “payment model at cycle X for a baker”
note: Bakers will be expected to always update their onchain split information during the cycle in which it takes effect, there is no plan to support editing a past cycle. Future cycle changes to the payment model can optionally be communicated via the offchain field “upcomingPaymentModelDescription”
i think that this is an excellent idea to help standardize and share baker information. As a delegation service, it would be great to update our information in one file and have all services that track and rank bakers pull from the associated smart contract.
Regarding history handling, here is what came to my mind:
Let’s store each update in a big_map entry with the key baker_address:cycle plus keep two additional fields in the body (field names are subject to change):
prev_contract (if we’ve updated the contract this will help to preserve history)
prev_cycle (using this value we can access the previous state)
There should also be a map of pointers to the current state (possibly in a separate big_map), say with keys == addresses.
What we get is a linked list with an ability to fix errors (!) and to retrieve the history for the required depth.
Thanks Jonas, it is very helpful to hear feedback on the proposed schema from the bakers who will be entering the information to be shared publicly. It’s very important we capture all the details bakers want to provide.
I am also looking forward to working with everyone to find a good way to standardize on all the naming conventions and descriptions so that it can be easy for newcomers to understand the purpose of each data field.
Your linked list approach to history is definitely interesting and exactly the type of history alternatives I’m hoping to see discussed.
If we decided to support the ability to fix errors I had come up with an approach that uses a big_map key of baker address with values being a pair of the data plus an “effective cycle”. This would handle both past and future and has the benefit that it would not require bakers to enter their updates in the cycle they take effect.
As of right now, I was planning to begin public testing with the simplest approach to history as it’s only a big_map key of baker address with values being a pair of the data and the timestamp.
I am curious if this simple approach can suffice when indexing/querying as long as we come to an agreement that editing past cycles baker data isn’t a requirement. The tradeoff if we were to allow such editing is then we would need to somehow track if a baker is improperly altering their history.
The simple approach will work, we can get history by using indexed data provider, e.g. Conseil.
All we have is to request all operations and then for each operation get big_map_diff via RPC (optionally we can filter by baker using the parameters).
In order not to give too much freedom, one can specify a short time interval for fixes, or allow to fix only the latest state, or make edits subject for fees. Anyway, all edits are indeed traceable via big_map_diffs.
We at Bake’n’Rolls are very looking into having all important Public Baker’s information on-chain and therefore we are fully supporting your initiative!
An interesting idea, and I think this is really a useful thing for the WHOLE community. In fact, to some extent, we have implemented roughly the same, but locally, for our ranking of public bakers, providing an opportunity for bakers to independently change important parameters for them in their personal account. A personal account was created for bakers to automate the processes in our ranking as much as possible so that delegates were always aware of the changes in their baker. The baker does not need to ask anyone to change such parameters as the size of fees, the minimum amount for delegation, and so on. He simply logs into his account and changes what he wants to change. We described this in more detail in the article https://medium.com/@tezosnodes/tezos-nodes-com-d405d6bb4fcd, and there is a visualization of the baker’s personal account.
Your idea is much wider and more technological, and this is very good.
I’ll share some statistics right away: out of 100 bakers represented in our rating, 45 of them activated their accounts to control the data flow, and this is only in 10 days. I think that most public bakers will be interested in the registry and take the initiative. Thanks for your idea, we will be happy to share our experience.
Thanks for the support. I don’t think its necessary to go as far as having the protocol require a baker to sign up for the registry.
The bakers will be incentivized to sign up as long as the listing, ranking, auditing, and indexing services all get the raw baker data only from the registry. This will make it a de facto requirement if a baker wants to be seen publicly. And it should help everyone keep all their sites updated.
In order to make the registry a benefit to all those services providers such as MyTezosBaker, BakingBad, Bakendorse, Tezos-nodes and others, we will need to work together to come up with good standards for the data and APIs.
This is a great approach and moves from having to trust a third party storing these names and might maliciously abuse it. You definitely have the support from AirGap & tezblock.
Some feedback from my side
I would propose having a multi-sig with other parties beside the Tezos Commons Foundation as the contract owner.
Instead of implementing alias/naming of the baker in the contract it should be handled by a Naming System similar to ENS (Ethereum Name Service)
For storing the off chain .json file there should be requirements ex. having them on IPFS
This is very useful feedback. I’m hoping to hear what others think of your suggestions.
I definitely believe the ecosystem will benefit from a naming service and if one arises then the Bakers Registry contract would not need to store the baker name. The AgoraBot might currently be using a custom naming service. Hopefully they and others working on such solutions will start that as a separate Agora topic “Tezos Naming Service Discussion”.
It is not necessary for Tezos Commons Foundation to be responsible for the registry contract long term. But it seemed like a reasonable place to start in order to get a first version deployed as soon as possible while giving people confidence that the owner is a neutral and reputable entity. Soon we will need to tackle versioning of not only the data schema and APIs, but the contract itself. There will be opportunities to revisit the contract owner as a multi-sig or even a DAO.
I don’t have a strong opinion on requiring IPFS for the off chain data. Let’s see if others express an interest in such a requirement.
Hello!
This is tonoff from the Norn team (@TezosNotifierBot, Norn Delegate).
First of all, we fully support you and believe that this is a very cool idea. It is not difficult to implement, but will demonstrate the power and organization of the Tezos community.
Next, we want to give comments and suggest changes / additions that, in our opinion, will improve the process.
You say that “There are two primary goals: … & …”, but in fact these goals are not achieved, because: there is centralized control (TCF), anyone can write anything to the registry, costs are only increasing. But, in any case, the goals are correct and we must figure out how to achieve them.
We must also add to the goals that we want to increase transparency. This is a very important factor for the community. The use-cases and goals of such a registry should also be protection against fraud. A group of honest bakers creates a DAO. Bakers are motivated to join it, because it will increase user confidence and therefore profit. Voting is using for remove unscrupulous bakers. The question is whether members will have equal voice weights.
The contract will be able to call any participant, regardless of whether he is a delegate or not? If so, then it is better for us not to do a “register of bakers”, but a “register of public addresses” and remove the word “baker” from the parameter names, then anyone who wants to make the address public will be able to report it (for example, exchanges, etc.) This not necessarily, but I propose to think about such an opportunity.
2.1. If we will make a “public address registry”, then in the future we will be able to implement something like the Ethereum Name System, and that’s cool!
In addition to paragraph 2, add the “type” of the address - baker, exchange, service, etc.
Information about baker should be entered and changed only by the baker or his authorized addresses, and not all in a row. This will help to deal with incorrect data.
Add the parameter “Authorized addresses” - these are addresses that can change information about the baker, except for the baker.
If the baker submits incorrect information, then this must be recorded. And a permanent violation should threaten with exclusion from the register or affixing the label “liar”
6.1. As an option, make deposits for registry participants, which will be debited in favor of those who find discrepancies.
Add “Associated addresses” with the name - for example, there may be payout addresses, etc.
Off-chain part should be optional. Only if the owner of the address himself wants to indicate it (see the next paragraph).
Off-chain and on-chain parts should be both connected, for this I suggest that bakers store the off-chain registry.json file in the root of their web-site and nowhere else. And in on-chain add only the parameter “website”.
In off-chain part we need to add the address of the baker.
Paragraphs 10 and 9 will allow in the future to implement a GUI to the register and access all the information about the baker from anywhere.
What is overDelegation? On-chain parts should not have dynamic parameters that change frequently.
Add “Status” - active or not. This is an suggesion.
Despite decentralization, TCF will set the rules for the game, and bakers will pay. This is a violation of one of the goals. I propose to implement one of the options:
A. Multi-signature. For example, 7 participants with a required majority of 5 votes. The funds received should be issued to developers of a smart contract and related tools (register GUI, for example)
B. Distribution of contributions automatically to all bakers who entered information about themselves in the register. But this may require a separate linked smart contract.
In other words, it is necessary to ensure that no one is interested in changing fees.
For clarification we have no desire to retain ownership of the contract or profit from it. Tezos Commons acts as a neutral party for retaining IP or ownership of specific infrastructure if there is no clear home for it. The contract code limits us, Tezos Commons, to update the fees required only. We would only own it through the beta, for the sake of time, and move to a new multisig contract once the schema and data are finalized.
Regarding the ENS system it doesn’t meet a growing need for a baker registry. There are numerous third-parties that are requesting this data. I think a separate discussion for an ENS style system would be great.
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.
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.
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.
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.
