Baker Registry v1 Details
Version 1 of the baker registry contract has been originated on the Tezos mainnet by the Tezos Commons Foundation (TCF).
The baker registry is a smart contract which allows a baker (and only that baker) to submit updates to their public data. To make it easier for bakers to generate the operation with parameters to submit to the contract we have created an initial version of a web form which has only been tested using Google Chrome; this is known as the baker registry app and can be found here. The web app can also be downloaded from the repo linked below and run from a local web server without public internet access if the user supplies their own indexer endpoint in the app settings.
The baker registry app is not a wallet and as such it does not put your baker key at risk as the user does not provide any secret information in the app. All it currently does is allow you to:
- Query the contract for a baker’s data by entering their public delegate account (baker pkh)
- Provide a web form to edit the data and generate the command text to be entered into the Tezos client command line
The baker registry contract was originated with the maximum amount of baker data that the current Tezos blockchain parameters allow. This resulted in a pre-populated list of 103 bakers generated from the public APIs of MyTezosBaker, BakingBad, and Tezos-Nodes. It was not possible to pre-populate all the fields as the public APIs did not contain all the data; it is up to bakers to go to the registry and make sure their data is accurate and complete. For more information on the type of information stored in the registry continue reading the full Baker Registry FAQ
The goal of this first version of the registry contract and app is to move forward in learning how the community should best address the sharing of this information. It is likely that we will agree that changes need to be made to the data schema, the contract, and the app.
The current baker registry repo can be found here.
The baker registry contract address is KT1ChNsEFxwyCbJyWGSL3KdjeXE28AY1Kaog
Q: What should I do now?
A: Everyone is encouraged to provide feedback on Agora and the baker slack. Depending on your role in the ecosystem you should do the following:
- Bakers: Go to the registry app, find your baker using pkh. If not found, then add your baker to the registry. If found, carefully check all the fields for accuracy and enter any missing fields. In both cases, the app allows you to generate the command text, paste the text into your Tezos client to call the contract. (make sure to remove the --dry-run flag once you are ready to submit the actual operation). Note: The field “Offchain Baker Data Url” was originated as empty, it is a link to where the baker stores the off-chain JSON file with additional information as described in the FAQ. An initial version of this file was created for each baker and stored in the public repo folder named offchain. Each baker is expected to copy their matching file, edit it, rename it to what they want, host it where they want, and enter the new link to their self hosted file into the registry field to update the contract.
- Aggregators (Listing Services): The registry app makes use of a simple parser library of JavaScript functions in a file named tcfBakerRegistry.js which retrieve the registry contract data, parse the big map using an indexer API, decode the UTF-8 fields from bytes, and return a list of bakers and their on-chain data. You should make use of these JavaScript functions to retrieve the data, filter it using your existing processes, and merge it into your workflow and databases. We will set up a channel for discussion on how to best improve and modularize this JavaScript code; we will also want to standardize the retrieval of the off-chain URLs for each baker – it’s likely that will move to include the off-chain retrieval into the the same js library, for now each aggregator must do this independently.
- Auditors: There are two important things needed from auditors. First verify that the registry is capturing all the fields needed to effectively audit a baker’s payouts. Second review how effective the blockchain history of the contract storage will be in enabling historical audits. Additionally participate in the channel that will be created for Indexers as their APIs will be leveraged to effectively retrieve the history data.
- Wallets, Apps, Tools, and Services (including Agora and the notifier bots) : We need to hear from all “consumers” of baker registry data that use it to display in their solutions. In particular there is still work to be done on how to best standardize the filtering and delivery of the data via reliable APIs to these solutions. Ultimately the Aggregators and Auditors will likely play a vital role in adding analysis and filtering to the raw registry data to make it more useful to all solution builders.
- Indexers: The baker registry contract and app has the same needs that most other “app devs” will need – a reliable and consistent way to access the Tezos blockchain information. There is more work to do in parsing and decoding all the data, especially when it comes to the more complex data structures and areas that aren’t likely to be supported by the RPC. We will be setting up a channel to discuss how to best standardize the core indexer APIs needed by the registry (especially in regards to the contract’s use of big_map).
Moving Forward
The baker registry has been a collaborative effort by many entities in the Tezos community. But we still need to prove that the registry provides real value to the ecosystem before we can expect everyone to use it. It is important that the registry continue to be a community lead effort in order to have confidence in this vital source of data needed by many apps, tools, and services.
Next steps for the app
- Add the ability to use other wallets to submit calls to the contract (e.g. Kiln aren’t likely to have access to the Tezos command line) – this can be supported by having the app output only the parameter string needed by wallets when calling a contract. But will need to work with wallet providers to make sure that the formatting works consistently across their implementations.
- Add better data entry validation (currently mostly only command side validation, i.e. you will get an error when running the command on the Tezos client if you have entered invalid data)
- Add better error messages and UX when app fails to successfully retrieve data from the blockchain
Next steps for the schema
- Have bakers verify it captures all the data they want to share
- Have auditors verify it captures all the data needed to audit payouts
- Have auditors and indexers suggest any new fields needed for tracking history
- Continue improving the terminology used in the baker ecosystem which is expressed in the schema
- Based on usage and cost/benefit analysis, determine where the data should be optimally stored – the preference should always be to store data off-chain, and limit the on-chain data to what is really needed. One example would be only storing on-chain a hash of the data document.
Next steps for the contract
- Incorporate feedback on entry points, annotations, rules checking
- Optimize the data types
- Review the current use of a single entry point for both updating the “baker data” and the “reporter” – related issue that the entire dataset for a single baker must be resubmitted on every update which makes the retrieval of the accurate data for display and command generation very important and a potential source of data entry error
- Begin preparing how the registry contract will handle versioning issues as the schema eventually goes through changes (not only impacting the contract parameter and storage but possibly logic as well). Lambda vs Proxy approach to versioning.
- Begin discussing how the contract can move from TCF control to either a multi-sig controlled by a collaborative group of community organizations or even a DAO
Next steps for the parser library
- Determine if should add code to query the baker off-chain URLs and merge the on/off data into a single set of data for use by aggregators
- Improve the use of promises and error handling
- Modularize the JavaScript library of functions to make them easier to integrate with other code
- Coordinate parser library versioning with the changes to schema/contract/indexers
