ERC-1329: Inalienable Reputation Token

[dr-orlovsky]

eip: EIP-1329
title: Inalienable Reputation Token
author: Maxim Orlovsky <orlovsky@pandoraboxchain.ai>, Andrey Sobol <sobol@pandoraboxchain.ai>
discussions-to: this issue
status: WIP
type: Standards Track
category: ERC
created: 2018-08-13

Simple Summary

Reputation belonging to an identity is frequently used in designing repeated economic games and protect them from malicious actors. The main property of such reputation should be inalienability. This ERC proposes the standard in creating inalienable reputation tokens.

Abstract

Standard in creating inalienable reputation tokens.

Reputation tokens are emitted and burned by a contract depending on balance holders actions and their consequences (i.e. there is a proof of the Byzantine behaviour of the owner). Reputation balances can be queried, but not directly changed or transferred from outside of the contract.

The token balance is protected by two-tier key design that allows signing transactions that can affect the reputation from one address while keeping the ability to replace the address with a compromised key by using the primary key stored in an airgap/secure cold storage.

Motivation

In building trustless decentralized P2P networks sometimes we need to utilize multi-stage/repeated games (in terms of game theory). In such cases, reputation becomes the measure that helps to build economic incentivization schemes for the selected economic game. The reputation works as a "glue" that ties together the actor responsibility over time, creating an ability to utilize the strengths of repeated economic games.

Reputation system needs some specific kind of token, that can't be transferred between actors. Why? Because if the reputation may be transferred, it can be sold; and if it can be sold, it breaks the whole game setting and economic incentives, creating different Nash equilibrium and generally getting worse protection from malicious actors (lower Byzantine tolerance).

Specification

interface ERCReputationToken {
    /// ERC20-like properties providing general information 
    /// about token name and symbol
    function name() public view returns (string);
    function symbol() public view returns (string);

    /// ERC777-like granularity
    function granularity() public view returns (uint256);

    /// Reputation may be limited or onlimited by the supply. These functions
    /// provide information whether the supply is limited and, if not, the
    /// `totalLimit()` and `currentSupply()` will be returning the maximum amount
    /// of the tokens that can be produced and current token issuance
    function hasLimit() public view returns (bool);
    function totalLimit() public view returns (uint256);
    function currentSupply() public view returns (uint256);

    /// Function returns the balance of reputation tokens on an account
    function balanceOf(address owner) public view returns (uint256);
    
    /// Function returns the address that is authorised to sign transactions 
    /// to this contract that can affect amount of the reputation on the account
    function authAddress(address owner) public view returns (address auth, uint duration);
    
    /// Authorizes address to interact with the contract on behalf 
    /// of the balance owner for a some duration (amount of blocks)
    function grantAddressAuth(address auth, uint duration) public returns (address prevAddress);
    /// Extends authorized duration for the registered authorized address
    function extendAuthDuration(uint forDuration)
    /// Remokes authorisation right from the currently authorised address
    /// to interact with the contract on behalf of account owner
    function revokeAddressAuth() public;

    /// Produced when contract generates some about of reputation and assigns
    /// it to a certain account
    event Issued(address owner, uint amountProduced);
    /// Produced when contract burns some about of reputation on a certain account
    event Burned(address owner, uint amountBurned);

    /// Events for operations with authorised accounts
    event AuthGranted(address owner, address auth, uint duration);
    event AuthRevoked(address owner, address auth);
    event AuthExpired(address owner, address auth);
}

The token contract MUST implement the above interface.

The smallest unit—for all interactions with the token contract—MUST be 1. I.e. all amounts and balances MUST be unsigned integers. The display denomination—to display any amount to the end user—MUST be 10¹⁸ of the smallest, like in ERC-777 standard.

Rationale

The standard provides a solution for the trade-off between reputation token inalienability (non-tradability) and security issues in the case when private keys of reputation owner are compromised. This is implemented as two types of addresses associated with token balances, where the primary address and its private key can't be changed and can be used only for authorising some other address and its private key to perform operations with the contract on behalf of the balance owner. Thus, the primary key can be kept in cold storage most of the time, and all necessary operations can be performed by using the authorised key, which can be stored in 'hot' on a server or desktop/mobile. If the authorised key gets compromised it can be replaced or revoked using the primary key. Unfortunately, there is no option to replace the primary key in the case when it was compromised.

Backwards Compatibility

No known issues

Test Cases

Left for future work

Implementation

Left for future work

Copyright

Copyright and related rights waived via CC0.

[dr-orlovsky]

The original discussion of the possible standard for reputation token and associated issues had taken place in Gitter https://gitter.im/ethereum/EIPs?at=5b6efeaf196bc60b6bb5dad3

There was a side discussion about the necessity of inalienable reputation tokens: https://www.reddit.com/r/ethereum/comments/96ocqm/erc_for_reputationtype_token/

The proposed standard design is based on a suggestion from @andreysobol on how to secure the account holding the inalienable reputation in the case when the private key gets compromised or needs to be replaced.

[OFRBG]

I stand against promoting such system. In short, we are likely to end up with essentially central authorities arbitrarily granting users global "approval". What may start as a spam deterrent may end up becoming what blockchain opposes.

[sabina-sa]

I see that by design the proposed reputation token can only take positive values. You can always throw away your private key and start anew. So, there is no way to discriminate against someone, putting him to a position worse that than of a newcomer. Only rewards are gathered long-term.

[dr-orlovsky]

we are likely to end up with essentially central authorities arbitrarily granting users global "approval"

The proposal adds no risks on top of the risks already created for instance by the smart contracts, which can be as well created/controlled by the same central authorities like in China and do a lot of harm to the community when used in a wrong way. Not a knife kills people, but the human hand holding a knife.

[tenthirtyone]

Why would we tie reputation to a token when all of the actions of your account is public, including your asset holdings, trades, etc, which are forms of reputation in themselves. Wouldn't it make more sense for ideas to compete and for organizations seeking reputation systems to decide for themselves which 'ingredients' are important to them for reputation?

I don't get centralization standards like this or understand the technical merit.

[dr-orlovsky]

@tenthirtyone, how do you link this standard with centralization? By the same logic, ERC20 tokens are centralized by their emission model (smart contract). Reputation tokens are issued according to some rules, and if you don't accept the rules, don't participate in this smart contract, what's the problem? The same way you can avoid participation is scammy ICOs with hidden issuing rules...

[OFRBG]

@dr-orlovsky I coincide with @tenthirtyone. If you really want to push reputation badges, I would require the emitters to encrypt the data with their private key before transacting. This is seriously messed up and freely comparing it to the Chinese reputation system only makes it worse.

[AnthonyAkentiev]

We at Thetta.io support this initiative.

In our opinion

1. Reputation SHOULD NOT be transferrable.
   Still, this does not protect us from issuing some transferrable derived token on top of it.
2. Reputation CAN be burned to zero.
   Of course in this case it can be used as a stake.
   Also, we use that feature in scenarios where you can "cash out" your reputation and swap it to some other tokens. "Cashing out" can be implemented by contracts on top of the Rep token.
3. Reputation SHOULD NOT be negative.
   This is just a question of design, that is made just to simplify things.

p.s. Imagine the future.
Your colleague is at address 0xA1A73c22Af2B61cC75Bafd646580a0e46559c336, you don't know his name, you don't know where he is from. All you know is that he has 120 points of "Angular programmer" reputation + 180 points of "AI programmer"...
Reputation is what will help us gain (pseudo)anonymity and eliminate KYC needs.

[larspensjo]

The Motivation and Rationale explain why a non-tradability token is needed and why it should be implemented as proposed. However, it should really explain why an ERC standard is needed.

The reason an ERC standard is needed is when there is a third party that generically should be able to manage or query any token adhering to the standard. If so, a common API is needed. E.g. the ERC-20 is needed to enable any exchange to trade any token that implements this API, without requiring any special code depending on the token.

[dadeg]

How does this sort of system handle Sybil attacks? I imagine that anybody could create a second account, then assign a bunch of reputation tokens to their original account, thus making themselves appear very reputable. Or is the idea that a centralized authority (the owner of the contract) is the only one who can grant reputation to a user?

[OFRBG]

@AnthonyAkentiev Reputation is a very slippery slope. As you mention, your colleague might have 120 points of whatever skill, but who gave him those points? This takes us back at central authorities emitting reputation points, thus fostering a new generation of TSA-companies.

Like @dadeg mentions, you either end up with trusted third-parties who become gatekeepers or risk Sybil attacks.

[sabina-sa]

It appears like some participants have not understood yet that this token does not attempt to measure one’s reputation in the whole Ethereum network. On the contrary, it is a type of token to use in projects internally. There can be thousands of projects, each one tracking some variables that it needs as user’s reputation within that project. Multitude of opinions and choices. Why some of you believe that projects should be barred from doing that? Only because the Chinese government abuses the idea? And if the Chinese government starts to use smart contracts, then must we stop using them? Besides, there is a major difference. This token does not give any way to punish for bad reputation, since in the worst case you scrap the private key and restart anew. It only gives to projects a way to reward users for certain actions and makes that reward non-transferrable. That’s it.

[OFRBG]

@sabina-sa Take for example the infamous case of the American SSN. SSN or Social Security Number was just that, the SSN. Over time, institutions opted to use the SSN due to universality and convenience. A number that was originally meant to be far from private became almost a real-life version of private keys for the USA.

[dr-orlovsky]

@larspensjo good point, I will extend the Motivation section

@dadeg as a reference case you can look at our Proof of Computing Work protocol which utilizes such kind of reputation:

• presentation: https://www.slideshare.net/pandoraboxchain/proof-of-computing-work-protocol-by-pandora-boxchain
• description: https://medium.com/pandoraboxchain/world-decentralized-ai-on-blockchain-with-cognitive-mining-and-open-markets-for-data-and-algorithms-4e192554024a#4fc5 (see Sections 2.2, 2.3, 2.4)
  It is protected from a Sybil attack since there is no way in which you can assign yourself a reputation by creating new accounts. The reputation is assigned by decentralized protocol, part of which is implemented in a form of smart contract.

There are other possible designs, but of course, if there some bad devs, they can create vulnerable implementations of any standard, including ERC20, such that centralized smart contract issues tokens out of limits of the total supply etc.

[dr-orlovsky]

I'd like to emphasize that is not a replacement for usual tokens with economic value and market price, in no way! It's an addition on top to them, that is sometimes (not always) needed to build provable-secure incentivisation system (having Nash equilibrium in a way that is required by the protocol)

[sabina-sa]

@OFRBG That comparison to SNN would stand if I could easily discard my SNN and get a new one every day. A better comparison, in my opinion, would be e.g. a supermarket loyalty card.

[OFRBG]

@sabina-sa I don't know if that was possible originally; discarding and renewing the SSN. Nevertheless, it became ubiquitous to the point that discarding it, even if theoretically discardable, would result in a myriad of incompatibilities across the board.
Your example of the supermarket loyalty card still supports my point: think of a loyalty card that becomes so popular and widely approved that over time it rises to the status of an official ID.

Fun fact: https://en.wikipedia.org/wiki/Social_Security_number#/media/File:Social_security_card.gif

[sabina-sa]

@OFRBG SSN is something very centralised. It is backed by government’s use of force, it is backed by police and courts. This monopoly is its source of trouble, not the use of numbers to track people. On the other hand, your local gym probably assigns a number to each member. Should we really bar it from doing so, because we fear it will become SSN?

[AnthonyAkentiev]

@OFRBG

As you mention, your colleague might have 120 points of whatever skill, but who gave him those points?

If you have the smart contract THAT IS ONLY capable of increasing one's reputation -> then you (of course) should trust it. And you can verify that the smart contract increased rep. only as intended (for example if your collegue completed 12 tasks -> smart contract assigned 120 rep to him). In this example there is no possibility for the collegue to issue reputation, only smart contract can do that according to the code.

In our case (Thetta DAO Framework) we have a simple action like increaseReputation() and you can set permission to what smart contracts/actors are allowed to call it.

[dadeg]

I don't see why blockchain storage is necessary for internal tracking of users.

[dr-orlovsky]

@dadeg it does not aim at user tracking at all! It has completely different goals described in the standard: building specific types of economic games where you need reputation (see https://ncase.me/trust/ for instance). I have games some explanations in Reddit as well: https://www.reddit.com/r/ethereum/comments/96ocqm/erc_for_reputationtype_token/e434kki/

[sabina-sa]

@dadeg IMO, the most logical way to handle reputation would be to let the contract assign reputation for certain observable actions, automatically.

[OFRBG]

@sabina-sa Ethereum has institutions akin to "governments". Many users will blindly trust whatever Consensys or Parity publish. The original card of the SSN literally stated not to be used as an identification. If a company such as Consensys, Parity, Etherscan, MEW, or Augur start giving out "trusted" user badges, that wouldn't be that different from the aforementioned case.

@AnthonyAkentiev Say the colleague did complete said 12 tasks. What were those tasks? Who commissioned said tasks? Which was the quality of the tasks and who rates the outcome?

@dr-orlovsky I still agree with @dadeg. If you need to have a reputation system for your own application, keep the reputation system to yourself. Every entity on the network should be equally trusted/distrusted. I insist that this proposal may snowball into an Ethereum-wide ID system unless only the granting parties may read it.

[sabina-sa]

@OFRBG > If a company such as Consensys, Parity, Etherscan, MEW, or Augur start giving out "trusted" user badges, that wouldn't be that different from the aforementioned case

OK, suppose we know that Augur project trusts a user. Sorry, so what?

[dr-orlovsky]

@OFRBG by the very same logic ERC20 snowballed into investors and led to plenties of scam projects and millions lost. The risk of misuse or some possible scams (either privately or government-organized, like reputation system in China) is not an argument against standardising some common practice.

[dr-orlovsky]

Every entity on the network should be equally trusted/distrusted.

@OFRBG It's not about trusting/distrusting some entity at all. There is no "objective/global" reputation and this standard is not about it. It's about how to count "points"/"score" that accounts some specific smart-contract based protocol-following behaviour that can be used in arbitrating complex cases of Byzantine faults in protocol lately (for the faults that do not have a direct algorithmic solution).

[AnthonyAkentiev]

@OFRBG I am no longer able to continue the conversation with you (out of time, sorry). I described my position above.

[AnthonyAkentiev]

@OFRBG but i suggest looking at how DAO works. In this case there is "source of knowledge" (Oracle or group of people through the voting) that approves that "task is complete" or "task is not complete".

There IS clearly mechanisms on how to confirm that someone has completed the task or start the Dispute Resolution process. That is what we are doing in Thetta.

[andreysobol]

@dadeg

Or is the idea that a centralized authority (the owner of the contract) is the only one who can grant reputation to a user?

Owner of the contract can be another smart contract

[dadeg]

There is a difference between a Bitcoin address that holds coins which are easily transferred and this reputation which is described as inalienable. There absolutely would be a market for private keys since that would be the only way to acquire the reputation without earning it. Also, due to the nature of reputation, once it is bought, it is likely to be abused by the buyer and thus ruined. So the risk to the buyer is quite low because they will abuse it and ruin the address and move on. They won't be using the address for a long time.

And in any case, as Nick said above, contracts could acquire reputation. And those can be easily transferred.

[andreysobol]

@dadeg

There absolutely would be a market for private keys since that would be the only way to acquire the reputation without earning it. Also, due to the nature of reputation, once it is bought, it is likely to be abused by the buyer and thus ruined. So the risk to the buyer is quite low because they will abuse it and ruin the address and move on. They won't be using the address for a long time.

But seller can sell reputation to 10 buyer in one-time, so each bayer can not trust seller.

And in any case, as Nick said above, contracts could acquire reputation. And those can be easily transferred.

We can set condition "isContract==false"
https://ethereum.stackexchange.com/questions/15641/how-does-a-contract-find-out-if-another-address-is-a-contract/15642

[askucher]

You rejected my idea about reputation over the address but I think that it is possible to put 1 million on the address as a confirmation that private key is safe and not compromised. I am ok that you reject but I would like to understand the reason which makes sense for me.

[dadeg]

You can't use extcodesize to determine if the caller is a contract. In a contract's constructor that would return 0.

[dr-orlovsky]

@askucher

You rejected my idea about reputation over the address but I think that it is possible to put 1 million on the address as a confirmation that private key is safe and not compromised.

Can you elaborate on that in more details? I don't get the idea

[dr-orlovsky]

@Arachnid,

At best this will result in people deploying contracts that accumulate reputation and are themselves transferrable

This can be mitigated by linking reputation address to tx.origin, not msg.sender. The same applies to the question by @dadeg

at worst, it will discourage people from migrating to more secure accounts (eg, ones protected by hardware wallets) for fear of losing their reputation.

That's why we proposed a system with two levels of addresses

[askucher]

#1329 (comment)

It was addressed to @Arachnid

[MicahZoltu]

@dr-orlovsky Linking reputation to tx.origin is an even bigger problem IMO because it means only accounts can hold reputation, not multisigs, recoverable wallets, etc. If holding reputation has any tangible value (meaning it is something worth stealing where possible) then restricting users such that they cannot secure their assets using advanced techniques like multisig or 2-factor wallets will likely lead to attacks against users that there isn't a reasonable mechanism to defend against. "Secure your private keys better" isn't a great solution.

On top of this, for a business entity (who presumably wants reputation), you may need to be able to transfer asset control between users as people within the company come/go.

[fubuloubu]

I think this concept is very critical to build a separate standard for, but more in the implemetation and usage sense. Reputation tokens are tradeable (whether you try to avoid it or embrace it), but the use case of staking and burning for an application is what should give them value. As long as the marketplace for them is relatively illiquid, then the only reasonable parties who would perform a transfer should be those who seek to "borrow" or buy reputation to participate in the game where it is earned. They might then return the borrowed reputation (with a given fee) if they did not buy it outright.

This creates an economic incentivize around the token, it gives it value directly centered around it's use case and prevents it from being used as an access mechanism to other systems, since anyone can just buy it.

I think this being a separate token standard may not be necessary from ERC-20, except in standardizing the mint/burn mechanic into the token. An additional feature that might be useful is a "taint" attribute which might mark transferred tokens as tainted, which could be discernable to certain applications who wish to make a distinction of "earned" versus "bought" tokens. Tainted tokens should be allowed to be used in a protocol where they are staked by burning them, and then the smart contract or dApp that accepts that stake would mint untainted tokens in response as that application would hopefully have authority to do so (as it is tied to a single purpose in the application). We might call such a standard "semi-fungible tokens" or "state tokens" as they have common state values associated with it (booleans or enumeratations). This might look like a balanceOf function that returns a struct with the number of tokens in each category given by the token (e.g. { total: 100, tainted: 10 ) where total is a mandatory member)

This is very similar to the "Cyclical Token Model" proposed by Chris Winfrey here: “Introducing Cyclical Token Models” https://medium.com/level-k/introducing-cyclical-token-models-3a0bbb2d3b0

I know Chris, and can put you in touch.

---

TL;DR: the concept behind this standard is absolutely ripe for an ERC, however this particular implementation may need reimagining to be successful for it's intended use cases.

Would love to work on this!

[fubuloubu]

I also think since it's primary use case would be for entering into smart contract based protocol games, that it could use an authorize-and-transact or transfer-and-transact functions like 721 and other standards have. This will reduce transaction calls.

[fubuloubu]

An example of how semi-fungible/stated tokens might work:

Imagine you have someone who has performed well in some economic game in a smart contract of a decentralized application, and now has a surplus of reputation tokens. They could decide to "stake" on a newcomer who wishes to enter into the reputational system with low or no stake so that they may participate by transferring some of their excess tokens to them. The token has the "tainting" option, so those tokens are identifiable as not properly "earned" via the rules of the dApp, in case anyone is looking at that data off-chain to make a determination about this person.

However, since their use case is primarily to enter into the economic game, and the smart contract governing that game does not care about the tainting of those tokens when it accepts them as stake and burns them, the tokens have the same utility as they would if they were not tainted, at least as far as the on-chain portion of the dApp knows about. If the game is played successful and has the "good" outcome, the "privileged" smart contract mints new tokens to replace those that were burned when they were staked, and those tokens are untainted because they are now seen as "legitimately" earned.

Now, the actor with higher reputation may have had monetary gain by offering these tokens on loan or accepting payment for them, or they may have done it for free because they like this person. That transfer of reputation, because it's primary use case is to be burned per the rules of the application, is effectively one party of higher reputation "staking" on another party to perform the game and enter the ecosystem to which the tokens are important. Assuming the rules of contract account for the scenario where "bad" outcomes are possible, and can recover gracefully from them with little damage to the operation of the application, there are no long term effects to the dApp except the loss of stake to the newcomer, which I think is a perfectly acceptable outcome. The account with higher reputation must also earn it back since it was transferred away.

A measure of liquidity (perhaps the overall percentage of tokens that are tainted) is therefore inversely correlated to a measure of the tokens being used for the primary use case of this application, at least as far as actors are not selling keys or other complex workarounds to this model. However, since we have made trade a simply supported operation, this should hopefully be minimal.

Under no circumstances should the tainting option be used by the primary smart contract governing the minting and burning of tokens, as this affects it's economic abilities in this model, but this metadata is import for a actor to make decisions on in off-chain scenarios.

[fubuloubu]

Note: the economic game probably has an external motivator to participate in the game, such as the expection of payment (like ETH or DAI) for services (in the "good" case), that should not be tied to the reputation token itself. As I said before, liquidity or direct value of the token itself is "a bug not a feature", and will hurt it's intended use case as a measure of past performance of an account.

[fubuloubu]

Apologies for all the messages, I have thought of this a lot but never written it down so this is a stream of consciousness. Also, ETH Berlin took a lot out of me.

[larspensjo]

I still can't find any explanation why a standard would be needed. The purpose of having a standard is that all such token systems fulfill the same API. This can then be used by some common contract. The common contract will work, regardless of what instance it is.

E.g. ERC20 enables an exchange to trade in any token. It is possible to set up a decentralized exchange where anyone can trade any token.

But is there really such a need? Would it matter if one inalienable reputation token is implemented differently (from the API) than another?

[fubuloubu]

Display of reputational scores and reputational score aggregates would be a very useful use case and would require a standard API. I agree the use cases I described could be primarily implemented by ERC20, including the non-standard minting/burning function calls which would be fairly standard in a reputation token. A successful reputation token will probably make use of the transfer-and-call mechanisms that other tokens make standard.

However, the semi-fungible design I described above, where account holdings are separated into 2 (or more) categories and that information is accessible via a new function (and probably an event signiture modification) would be the creation of an appropriate standard that extends ERC20 or whatever token standard is desire as the base of that standard.

---

The original author describes a significant modification to the design of other tokens to remove on-chain transferrability, which I think is a significant departure of intent from prior standards such that it would be more effective to create a new one. That is my opinion.

[OFRBG]

@fubuloubu I think that this standard is acceptable as long as only the owner is able to read the reputation. Making reputation secret essentially removes the market value of tokens, while still giving the DApp owner the power to screen users if spam is a problem, which a good DApp shouldn't have. It is possible to do this simply by signing and reading the reputation parameters with the owner's private key. Public reputation schemes, even if Vitalik said would be helpful, would probably go down the drain as soon as the syphon effect started.

[fubuloubu]

@OFRBG not sure I understand exactly what you mean. Do you mean to suggest that there should be some sort of "proof of reputation" exchanged between the dApp owner and any token owners? I'm really not quite sure what you mean by that, but I believe it would not work for any trustless protocols where there cannot be information asymmetry for the protocol to work correctly.

I think a "Partially Fungible Token" will arise out of #1400 being divvied into smaller parts. I believe this would be a better mechanism to facilitate @dr-orlovsky's use case, but that is for him to decide. Both can of course co-exist, but I'm not sure how much value this proposal will add in it's current state with the potential attack of selling private keys, which should not be discounted.

[OFRBG]

@fubuloubu I think, as I've posted above, that transactions are trustless, but DApps aren't trustless themselves. Public reputation for anyone to see can, or will, quickly spiral into a "gatekeeping" system. Unless there is such thing as an impartial reputation oracle, some users will be unfairly favored and others might even be affected by defamation.

Creating a reputation system without any cost for the reputation emitter is wrong. Even if we say that a bad "auditor" will lose prestige, in reality we know that kind of thing is swept under the rug. Therefore, reputation emitter need to either be held accountable for the use of their reputation or simply keep it to themselves. Do we really need to know if you're an Amazon frequent buyer?

[fubuloubu]

I would argue that the purpose of reputation is to have some relative measure of past performance in a network such that you can make determinations of how interactions with untrusted peers before you make them. Reputation is a filtering mechanism that networks employ to make these types of interactions smoother and more productive. By having your reputation be known to any interested parties, it is possible to make these determinations.

Now, this can be done in two ways: zero knowledge or full knowledge. For zero knowledge, there is an attestation that can be "proved" to a participant out-of-band such that they can trust your reputation is valid. For full knowledge, everyone can see what this reputation is because it is made publicly available.

Now, I definitely shouldn't know if you're an Amazon frequent buyer for privacy reasons, but if I have a network of computers who are willing to perform complex calculations in exchange for some token, it is better that this information just be public. It would facilitate the trust-less nature of the interaction by allowing the network to make determinations of this reputation out-of-band before the interaction is started instead of having to validate the proof afterwards. In this way, good performers float to the top, and bad performers fade out, and you will get some normal distribution of this reputation that would probably be tied to some cumulative distribution function for the amount participants are willing to pay (on average).

Public reputation tokens shouldn't have an "owner" because the act of one party validating another's behavior is necessarily individual. A good system is tied to some measure of work such as the proof of correct computation along with the price paid, so you can say that this computer did X work and earned Y tokens prior, and therefore can be trusted to do Z work for a fair market price according to their reputation.

[OFRBG]

Public reputation tokens shouldn't have an "owner" because the act of one party validating another's behavior is necessarily individual. A good system is tied to some measure of work such as the proof of correct computation along with the price paid, so you can say that this computer did X work and earned Y tokens prior, and therefore can be trusted to do Z work for a fair market price according to their reputation.

In this sense, I do somewhat agree, but I think this ERC isn't geared towards that kind of reputation. You can't put reputation and trustless in the same argument because, well, it's contradictory.

If reputation is more like a digest of past performance, then it's less harmful, but then you get a soft oligarchy, where good first-movers get the upper hand, and good late users are almost synonymous with bad users. Maybe this can't be shown with theory, but it's easy to find out if you use any freelancer website.

Even with your computer-verified case, I only see actual use for it in a network such as golem or Brave. I feel like people are trying to solve a problem that doesn't exist.

[fubuloubu]

You can't put reputation and trustless in the same argument because, well, it's contradictory.

What I meant by "trustless" was that you do not trust some central entity to handle your reputation, the protocol defines the rules by which one user can attest to another.

---

Maybe this can't be shown with theory, but it's easy to find out if you use any freelancer website.

I feel like people are trying to solve a problem that doesn't exist.

The idea is to try new concepts. As you noted in the first quote, there is indeed problems with this type of reputation in practice today.

What if it was made partially fungible, such that someone of high reputation could stake or even sell some amount of their reputation points to someone of lower reputation who seeks to improve their standing in such a network? If there was a way that the dApp would see this as the same (they staked the same amount of tokens as someone who used it normally), but a user would understand it differently (the tokens that were used were purchased from someone, therefore it is riskier) I think it would be interesting to see what the outcomes are.

I think staking on another's behalf is tantamount to some sort of attestation of that user, and purchasing a non-liquid token from another who has excess supply is tantamount to that person expending some stake to gain access to a feature.

[falehenrique]

@dr-orlovsky What is the origin of reputation? Example, I am a teacher and have my reputation on ERC 1329, who could give me the reputation?

I would like to use this ERC in GoBlockchain, there the person increase points doing tasks. So the base of reputation are the tasks did in the organization.

Thank you.

[dr-orlovsky]

@falehenrique it's not working like that :) ERC-1329 is a standard of smart contract API for any reputation token. It does not define who is it generated or what it does mean: it depends on the specific application or a system that needs a reputation.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.

[amanintech]

looks like there has been no discussion in the last 3 years on this.

Was this discussion moved somewhere else / any conclusion drawn / any alternative proposed?

I am strongly in favor of such a proposal. I realized the need myself during design of a DAO that needed trust.

Take the example of information truthiness and discouraging misinformation. It is possible to derive truthiness of information if original source could be traced but sometimes it depends upon the authority and reputation of person adding that novel information himself. The person can remain anonymous yet have a reputation calculated based on past contributions and DAO decisions.

A classic example is stackoverflow which helps us to get to a right answer without trusting central agency but a distributed calculated reputation score of the answer poster.

If we want to create a decentralized system which handles information truthiness and accuracy, reputation of the poster would be important.

[dr-orlovsky]

The discussion hasn't moved anywhere; we abandoned ethereum stack in favor of bitcoin and lightning network.