So far I think the tldr is:
a payment for the act of delegating
Now hopefully more people will suggest effective terminology to that effect given that the calculation of said payment can either be generally “fixed” as implemented by CryptoDelegate or “dynamic” as done by the majority of bakers.
Until we have time to get more input, it seemed “rent” would be a reasonable start but please everyone suggest other ideas on how to describe this payment in a way that respects the directionality and non-custodial aspects of the protocol.
@cryptodad For the soon to be released beta of the Bakers Registry on mainnet, we were prepared to go forward with “rent” = 90% but maybe something as basic as “delegationPayment” = 90% would be a better place to start? It will take time for the community to standardize, for now my short term priority is what to put into the beta registry schema which is only the base layer of the stack, those on top can choose to call things whatever they wish.
The very soon to be released v1 of the Baker Registry is so we can have a concrete solution to test and learn from as we don’t expect to get it right the first time and even if we have done a good job it will need to evolve as the protocol and baker policies change over time.
Regarding a “splitRange”, you are correct, for many reasons a baker in fact is likely to have a range (e.g. grandfathering, size of delegation, etc). We will learn if eventually it will make sense to model the range or if its accpetable to only record the “primary” split. The purpose is to communicate to those looking for new delegation to express the the current policy and most bakers today have a single split value to communicate. For auditing it gets more complicated, and thats why we look forward to active engagement from those entities that audit and analyze the data to give us feedback on how to improve the registry.
Regarding the “subtractLostFeesWhenAccused” field, this is not a “fee” the baker charges. It’s a completely different category and it accurately refers to the protocol fees. The goal is to encourage people to use language which better aligns with the manner in which the protocol functions.
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.
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).
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
Coordinate parser library versioning with the changes to schema/contract/indexers
Very much in support of this initiative. Maybe my questions might be unripe at this moment as details are rolling out, but I am very interested in how the auditing process is going to occur. For instance, who are the auditors going to be? How will they get selected? What happens during perceivable conflicts of interest(s)? How often are audits going to be done? Is there going to be a formal auditing process including an appeal structure for bakers who feel like auditors have captured incorrect data?
As i’m not and never intend to be an auditor I can only give you what I have observed and understand so far.
First, auditing a baker in this sense really means verifying that a bakers payouts match their stated policy for a given cycle. As to “how will they get selected?”, this is a decentralized blockchain no one selects anyone for anything other than by known blockchain based action; some examples are delegating your account to a delegate, sending someone a transfer, bakers submitting a vote, calling a contract (same as sending a transfer but with parameter data).
So currently the main auditor that the ecosystem has seen appear thus far is Baking Bad. Eventually I would guess there are likely to be others. They decide what they want to audit, how they want to audit, when they want to audit and the community decides how much they value what the auditor produces.
The current audits are all based on blockchain data for payouts, and now with the TCF launched Baker Registry the audits can have access to blockchain (i.e. cryptographically signed by the baker themselves) based data for the policy at a given cycle. So there is no longer an issue with “captured incorrect data” as its now more realistic to audit the auditors by analyzing the blockchain history.
What does the “overDelegationThreshold”: “100” entry stands for, as I couldn’t identify a related entry in the baker registry app?
I’m wondering where the “paymentConfig” data is stored, as it does not appear in the big map, yet it is displayed correctly in the app?
In addition, I found a minor typing error in the baker registry app. In the “Baking Rewards & Payment Details” section, line 6 (“Compensate Low Priority Endrosement Loss”), endorsement is wrongly typed.
Thanks for the feedback, we really want to encourage everyone to ask any question they might have and to point out any potential issues.
The “overDelegationThreshold” is not being used for anything by either the contract or the app. It is left over from an attempt to model overdelegation. It’s use might be revived in the app in v2 but for now it can be ignored.
The “paymentConfig” you see defined in the FAQ schema and displayed in the app is a set of booleans. But for efficiency the contract storage uses a single integer value rather than multiple booleans. The field in the contract is “paymentConfigMask” and the bits of that integer are converted to booleans on retrieval of the data by code found in the tcfBakerRegistry.js and converted back to the mask in the app code found in HomeController.js
The typo you pointed out has been fixed. If you don’t see the change do a full refresh of the web page in your browser to ensure your local web page cache is being cleared for the registry app.
The value is not stored as mutez, its stored with an arbitrary multiplier to support N number of decimal places. N is set to 4 decimal places so what you see in storage is value * 10000 (I made the decision to not use mutez because I felt it was not semantically correct as the app decimal values are not always related to tez, for example the split, but this decision could be flawed and might need to be changed to mutez in v2)
Please keep asking as these questions are all being added to a list that will eventually make it into General Help and Technical Details Docs.
edited: To clarify that some of the decimal fields are tez and thus could be reasonably stored as mutez, but others such as the split are not so rather than have two different approaches to handle decimals decision was made to use a singular more general approach.
I think what currently is missing in the smart contract (or in the offchain additional baker details data) is a variable, probably called “maxDelegation”, which specifies the maximum delegation amount a baker is willing to accept. If integrated into wallets, this could prevent large holders of Tez to over-delegate a baker also when the “openForDelegation” flag is set as “true”.
Something like “maxDelegation” working in coordination with “openForDelegation” is probably needed.
We have a field which was ultimately left unused as it wasn’t yet clear how to utilize it; that field is named “overDelegationThreshold” and you can see it exists in the contract and is set to 100. The intent was that a baker could set the % of their bond utilization at which point they consider themselves to be overDelegated which could help users to make delegation decisions.
By having this baker specified field as a % it would also help those bakers who intend to always add bond at the last moment to specify a value of say 200% which indicates “even if our bond appears to be at capacity we will continue to accept delegation”.
We think this is a great idea and we would like to see a testing baking key added to the baker’s information. This would be the key that bakers would use to bake on the testnet. That way testnets can fund at the genesis block level the baker’s test accounts and block explorers on the testnet can label up bakers that are testing on the testnet explorer. We could even pre-build snapshots in the genesis block now that we have all the bakers testing addresses.
I think you are right that the registry should allow a baker to specify public information to facilitate their participation in test networks.
It’s an open question whether testnets should leverage the current registry “Reporter Account” or whether we need even more testnet related data in the registry and as you suggest even a “Testnet Baking Account”.
I expect we will make these changes soon after community has a chance to better understand the role of a decentralized baker registry in helping all bakers take control over their data.