Bakers Registry Discussion

@tezit: Yes, I understand that we need to take care to not run into legal complications in any jurisdiction.

It is therefore important to not construct a relationship between baker and delegators that looks from the outside as something that was just constructed to avoid such complications.

I felt the need to point that out in my previous post, as the suggested terminology would be too easy to debunk.

The goal of avoiding legal complications is a ultimately a decision to be made by each individual baker. As you see earlier in the discussion Coinbase has taken a very different approach to these issues. I am not trying to suggest there is a one size fits all or that any baker should share these concerns if they choose not to do so.

My intention is to encourage us to discuss what actually exists in the protocol; and to find a way to describe it as best we can.

I only emphasize the potential for legal complications as there are still many people who don’t appreciate that side of things. Once people are aware, then they are more likely to see the value of describing the baker/delegator relationship as it actually exists in the protocol. Which is merely an independent act by a delegator with no compensation which can be undone at any time. This act can bring value to a baker and therefore it can make sense that the baker compensates the delegator for the act.

The direction of payment is important i.e. it is from baker to delegator (the protocol does not imply and it is not necessary to suggest that there is ever a payment from the delegator to the baker, and especially that there is ever a custodial relationship).

I don’t see how this is being constructed to avoid potential complications. It’s how the protocol works.

I was not referring to your posts, but rather to the buying/renting relationship between baker and delegators, which I found as sounding constructed.

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.

2 Likes

What about „rewardShare“, which would imply the direction from baker to delegator imho, and does also not provide false connotations?

2 Likes

Pooling. Pooling is an “social act” and the one that is providing the pooling infra gets a compensation.
You could run it as a “pooling club” if the fee just covers the expenses.

Cross-posting given relevance to fee-for-service vs. rent-rights conversation above:

Btw. have you considered that some bakers are giving out different reward splits meaning it should maybe to called “splitRange”: “80-90”?

Should all the parameters with the name “fee” also change? E.g. “subtractLostFeesWhenAccused”.

Good work so far!

I think we are getting very close to a good definition. I vote for “rewardShare”.

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.

1 Like

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:

  1. Query the contract for a baker’s data by entering their public delegate account (baker pkh)
  2. 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
11 Likes

Just updated our data using the generated tezos-client command.
Everything works like a charm!
Great work guys!

3 Likes

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.

1 Like

I have updated our data and it works fine using tezos-client. Really well done and much appreciated!

The following questions arose while analysing the big map data stored on chain for LetzBake!: https://api.staging.tzstats.com/explorer/bigmap/17/tz1aqcYgG6NuViML5vdWhohHJBYxcDVLNUsE

  1. What does the “overDelegationThreshold”: “100” entry stands for, as I couldn’t identify a related entry in the baker registry app?
  2. 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.

1 Like

Thanks for the feedback, we really want to encourage everyone to ask any question they might have and to point out any potential issues.

  1. 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.
  2. 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.

1 Like

Thank you @tezit for your answers. Just one more question:

I set the “Minimum Delegation Amount (tez)” to 1 tez. In the big map of the smart contract it is stored as “10000”. If this is in mutez, shouldn’t the value be 1’000’000?

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.

1 Like

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”.

1 Like