Ticker uniqueness and Metadata registries

StakePool Metadata registries are already mentioned in the delegation design specifications (Section 4.2)

Based on this back in Feb-2020 I wrote down some thoughts and ideas on a Cardano decentralised stake pool registry.

This mainly concerns existing pool tickers. Either those from the ITN phase, or a reputation built up over a longer period of time in the Mainnet. What if someone then simply registers the same ticker again to collect delegations of incautious users ?

Not allowing ticker duplicates always implicit some sort of centralization (An entity or person can permanently control/block a certain “piece”)

This brings up the question of how wallets, delegations centers, explorers, apps, … can identify and show (sort, filter, block, highlight) the right ticker. How it is possible to prevent adversaries to create a mess in the Cardano Stake-delegation user interfaces or at least to filter it out afterwards?

Looking at the earliest registration date (first reg win) is not useful because one can simply quck register with an acceptable amount of TX fees all known and a lot of probably useful tickers without using it at all.

This brings us directly to a second idea: use the lifetime stake (sum of all epoch stake) or the total number of produced blocks by a certain poolID / Ticker. This is a direct and pure technical indicator allowing the delegation centers to decide which pool deserves a prominent place and which one might a “possible fraud” badge.

Next question is if there is a risk shortly after genesis when all pools start from zero, for attempts to take over existing tickers and their reputations by unknown players. To prevent this we would need some mechanism or verified dataset allowing the wallet in the early stages to know who is the real pool ticker.

Metadata registries can be part of such a solution. To start for example a Cardano Foundation Registry can provide a reliable source, linking all known ITN pool-IDs with the new mainnet chain registration.

Subsequently, however, it can become an interesting additional task for several independent registries to enrich the Cardano ecosystem and to provide several decision criteria in the wallet delegation centers, the pool explorer portals and mobile apps.

5 Likes

What’s important to me from the point of view of proxy servers is - without any changes , will Daedalus and Yoroi be connecting to a community hosted proxy servers?
Since we cannot expect an end user to go and fiddle around changing metadata proxy servers - most end users will use it as-is, and organisations (including the three cardano bootstrap entities) can have higher priorities losing focus, how would a community owned proxy server appear as one of the default metadata proxy servers?

2 Likes

Good question.
I can imagine metadata registries - after they put quite some efforts into their setup and metadata - can become part of a metadata-registry list, maintained individually by each application provider (Yoroi, Daedalus, …) updated with new releases, or hosted by the app provider, and the app pull the list every x days.

Now after first start, the user must pick a metadata registry, or decide to use raw chain data without any metadata.

This also brings up the question how standardized metadata is. If there is an agreement on certain data structures and categories, I could imagine, the wallet can allow to pick multiple registries. This would make sense because different registries can focus on and provide different criteria’s. For example technical or subjective ratings.

If wallets want to keep it simple by allowing only one registry selected at the same time, this raises the bar for new registries to enter the area, because they need to build up a complete database first

Picking up a metadata registry - if available in UI , may be a wallet level option - sure. But how many users take the effort to check the settings and change defaults.

An example is Yoroi wallet having multiple selection for explorers, most of the users I contact in support dont even know they have that option (not that its not announced or isnt marketed well, but a user often refuses to bother with reading pinned messages/videos/blogs/… or even contact for clarification).

I’d assume in longer people would get around to whatever the process is - and is shooting in the dark without clarity , but it would be greatly useful if an indepedent proxy server available outside of the control of original entitites already part of default list of proxies - atleast on official wallets.

If that is not the case, we end up starting a step behind and then expecting to educate users - which is a pretty daunting task since a big section of crowd do not even care to read Red Alerts within UI :slight_smile:

One other point for clarity is whether its useful to poll multiple proxy servers for consensus in case of discrepancies. It’s a bit complicated to discuss because much of this needs interaction with Wallet developers as well as proxy providers - which hopefully is happening behind the scenes, but some participation and FYI about where we are at would be nice-to-have.

Right, without knowing what was developed so far it is difficult to discuss.

Regarding the “default selection” I would expect something like the web browser ballot screen in Windows operating systems (legally enforced by european laws)

showing the available metadata proxies … metadata.

I noted some of the related thoughts how wallets in the earlier mentioned brainstorming document,
eg
“The application asks the user about his preferred data source, or offers a self-maintained preselection of curators.”

(glossary: metadata registry | proxy | curator …all means the same but I would suggest to decide for one name, so all understand what is meant by)

With a certain standardized metadata format (eg JSON data structure) it should even be possible for new metadata proxies to just provide and promote their root URL eg https://new-currator.org/connect
The user can pick a pre-listed proxy in the application or have an option to insert such an external URL. This is not only offering more flexibility (liberty) to end-users, but support also the growth of additional proxy providers.

and yes in order to allow using multiple data sources and let the wallet show a combined result this would require some fundamental agreement + ofc some extra developement efforts for the wallet GUI.

I could imagine proxies can provide a hard/soft blacklisting badge for every pool.
Soft would mean: I wouldn’t show it but if other registries do it’s ok. (AND logic)
Hard instead means a very strong sign from that registry: blacklisted (OR logic)
Wallets might implement some individual logic then, like "Min two proxies need to report hard blacklist )

Beside blacklisting bad behaviour / unreliable pools, also different quality criteria’s would need to be summed up or averaged by the wallet when metadata comes from multiple proxies.

Sounds complicated and definitely is more complex than just using ONE proxy as data source. But it offers much more decentralisation and also reliability. Not only by sharing relevance and opinion to multiple sources, but also because any proxy can stop his services at any time (or have temporary down times)

2 Likes

and here is the repository for the mentioned SMASH (Stakepool Metadata Aggregation Server)

I guess the “h” in smash stands for Haskell code.

So from a first view it looks like a very first and minimal release, looking up the chain for pool registrations and querying the URL hosted by the pool operator.

But from my understanding it’s not (yet) any usable application for metadata proxy providers.

1 Like