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.
Continue reading the full Bakers Registry FAQ
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”