Skip to content
This repository has been archived by the owner on Dec 8, 2022. It is now read-only.

Update how-to-install-smash.md #59

Merged
merged 1 commit into from
Aug 19, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions doc/getting-started/how-to-install-smash.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,13 +5,13 @@ cabal build smash
cabal install smash
```

### Prerequisites
### Overview

Cardano Shelley introduces the concept of stake pools - reliable server nodes that keep an aggregated stake of pool operators and delegators in a single entity. Stake pools are registered on-chain, and their on-chain data (such as information required to calculate rewards) is critical to the operation of the ledger. Stake pools also possess metadata that helps users to make a rational choice of a stake pool to delegate to. This metadata is stored off-chain as it might reflect sensitive content, and such an approach allows for a degree of decentralized censorship.

On the other hand, off-chain metadata storage prerequisites a challenge of seamless access by different users. On-chain stake pool registrations contain an URL pointer to the off-chain metadata and a content hash that can be fetched from a specific stake pool. This might cause both performance and privacy issues. Another crucial aspect to address is the stake pool’s “ticker” name, which is the short name a stake pool is recognized by. Ticker names might reflect prominent brands or trademarks. This positions an issue of misleading use of brand names by dishonest individuals or the confusion of duplicate ticker name registrations.

To solve performance and privacy issues, a stake pool metadata aggregation server (SMASH) is introduced. SMASH provides a higher level of metadata accountability and maintenance. It aggregates metadata from existing stake pools and provides an efficient way to fetch it and store it in a semi-centralized environment. This metadata can then be curated and reviewed for censorship. In particular, stake pools with illegal content can be blacklisted, and disputes over offending stake pool ticker names or their disambiguation can be resolved. SMASH can be provided as a service to delegators, stake pool operators, exchanges, wallets, etc., enabling independent validation. Users (e.g. wallets, exchanges, etc.) can choose to interpret the non-availability of the metadata as an indication that the pool should not be listed.
To solve performance and privacy issues, a stake pool metadata aggregation server (SMASH) is introduced. SMASH provides a higher level of metadata accountability and maintenance. It aggregates metadata from existing stake pools and provides an efficient way to fetch it and store it in a semi-centralized environment. This metadata can then be curated and reviewed for censorship via the delisting feature. In particular, stake pools with illegal content can be delisted, and disputes over offending stake pool ticker names or their disambiguation can be resolved. SMASH can be provided as a service to delegators, stake pool operators, exchanges, wallets, etc., enabling independent validation. Users (e.g. wallets, exchanges, etc.) can choose to interpret the non-availability of the metadata as an indication that the pool should not be listed.

**SMASH Characteristics**

Expand All @@ -26,7 +26,7 @@ The metadata aggregation server possesses the following characteristic features:
- serves requested metadata via an API to wallets and other users in a performant way, including for the case of incremental updates;
- indicates that metadata is not available in response to requests;
- serves the requested metadata preserving the content hash to be verified against the hash from the on-chain registration certificate;
- allows operators to use a blacklist of stake pools to exclude when metadata is requested;
- allows operators to delist stake pools when requested;
- allows operators to configure, check and adjust their chosen policy via an appropriate interface without service interruptions;
- scales to reasonable numbers of metadata requests, directly or indirectly (e.g. caching HTTP proxies, multiple instances);
- follows typical behaviours, e.g. configured via CLI and/or configuration file, stdout/stderr logging.
Expand Down