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

[OFRBG]

@AnthonyAkentiev I do think that a DAO with oracles can circumvent this issue, but I think there are many people who aren't too fond of relying on them. Personally I'm concerned about endorsing something with a small benefit and huge risk.

[dr-orlovsky]

@OFRBG nobody is forcing you and nobody can force you. But you should not prevent because of some fear others from doing what they do, until you are not forced by them. And this is clearly not the case.

[askucher]

In order to control this token you still need to use the private key, don't you?

If yes - why the simple address does not work? Why I cannot build the reputation for address? What happens if I lose my private key? Do I lose my reputation?

if no - how it is possible to manage this token without private key?

[Arachnid]

Assuming that an address is equal to an identity is a terrible idea. At best this will result in people deploying contracts that accumulate reputation and are themselves transferrable; at worst, it will discourage people from migrating to more secure accounts (eg, ones protected by hardware wallets) for fear of losing their reputation.

[askucher]

Does not mean that migration to another account can be a hidden sale of reputation?

[dadeg]

Also a person could sell their private key to another person.

[dr-orlovsky]

@askucher @dadeg that is all already addressed in this proposal. I heard @Arachnid critics in Gitter and I have taken @andreysobol proposal which solve this problem: there are two-tier address/key system. Citing from the spec above (Rationale section):

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.

[dr-orlovsky]

@dadeg

Also a person could sell their private key to another person.

No, he couldn't. Otherwise, there were a private key market for bitcoin wallets.

Why a private key can't be sold? Because there is no guarantee that the seller destroyed the key original and will not do some actions (malicious) on behalf of the new owner having nothing at stake. It's the basics!

https://www.reddit.com/r/Bitcoin/comments/74louv/selling_private_keys_vs_selling_bitcoin/

[dr-orlovsky]

@askucher

Does not mean that migration to another account can be a hidden sale of reputation?

No. It can't. Because if you sell the secondary/temporary address you can't guarantee to the buyer that you would not replace it at any moment.

[dadeg]

@dr-orlovsky sure a person could sell their key. Speaking of reputations, maybe the seller has a good reputation for never using the private keys again after he sells them! If the seller has built a good reputation on selling private keys, he has an economic incentive not to ruin his reputation by re-using a sold key. If he ruins his reputation as an honest seller of private keys, he will ruin his future revenue stream. Now THAT is basic!

[akolonin]

Hi @dr-orlovsky and guys, interesting project - check if this design could be useful: https://arxiv.org/abs/1806.07342

[akolonin]

We are approaching this direction from "liquid democracy" perspective: https://www.youtube.com/watch?v=48XEGcHgi68

[akolonin]

There is a concept of "Reputation Agency", with possibility of multiple agencies of the kind reaching consensus about reputation state in distributed manner: https://medium.com/@aigents/reputation-system-design-for-singularitynet-8b5b61e8ed0e

[dr-orlovsky]

@dadeg First, you intermix terms, playing with words. Reputation discussed here is not a "generic" reputation, but an algorithm of accounting for specific types of actions according to some very narrow economical game. Second, you can, of course, find an on-time "stupid" buyer on your private key, but you can't create a market for private keys. Otherwise, it was already existing.

[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]

https://github.com/ethereum/EIPs/issues/1329#issuecomment-414087533

It was addressed to @Arachnid