A cryptographically anchored scheme for reputation.

[pipermerriam]

Clarence is using the portal network to estimate the gas for a transaction and then sending a signed transaction which will get included in a block and recorded in the chain history.

During the gas estimation he will do some sequence of the following.

1. use portal-beacon to anchor to HEAD
2. use portal-history to fetch the HEAD block header
3. using the header.state_root, incrementally fetch the state data needed to execute the tx.data

In many cases, the data that is fetched from the network will be modified by the execution of the transaction. For example an ERC20 token balance would be accessed during the gas estimation and it will then be modified when the transaction is included in a block as they send their tokens.

Suppose that the nodes in the portal network, that served Clarence their data also got a message from clarence that was signed by the same key as they signed their transaction. Those nodes could then "prove" that they were useful in an action that positively benefits the network, aka, serving data for users of the network.

Since transaction sending costs gas... that means that you can issue reputation for this in a quantifiable manner.

So.. the question is... can we cryptographically anchor these in sufficient manner....?

[pipermerriam]

We could implement the reputation system as it's own sub-protocol, possibly in a manner that keeps it entirely independent of the base data protocols needing to be aware of the reputation layer.

[pipermerriam]

Here's a really messy sequence of events. Client and Server are both portal nodes. Reputation is the portal sub-protocol.

• Client and Server are both portal nodes.
• Client is doing an estimate gas on a simple value transfer.
• Server is a node holding some piece of state on the path to Client's account.
• Client learns about Server during a FINDCONTENT.
• Server receives a message packet from Client that initiates a handshake to establish a discv5 session.
• Server sees that a new session was initiated with Client and initiates a message on the Reputation sub-protocol. This message contains a signed message A.
• Client stores A in a buffer for later use.
• Client receives the data for the FINDCONTENT which triggers client to send a message back to Server over the Reputation protocol. This message contains a reference to A as well as a reference to the state data that was retrieved such as the trie path, state root, node_hash. The message needs to be signed with a key that can be cryptographically tied to the same account that signs the transaction. This will be message B
• Client then sends the transaction.
• Server sees the transaction get included, and sees that it has B sitting around.
• Server can then package up a tidy little proof that shows the transaction getting included on the chain, some concoction of merkle proofs to show that the state data was modified between two different blocks, and the signed messages that can be linked to the transaction signer, allowing for a "trustless" issuance of reputation points (like by a smart contract or as a special purpose side chain or whatever).

[morph-dev]

I already see two ways to cheat the system. Depending on the details of how reputation scores would work, they can be more/less effective. I didn't think too much if there is a way to counter-measure them.

1. Client has all the power. Client can use portal network as designed, but testify that he himself (or another node or set of nodes that it wants to boost) provided all the data even if they didn't.
2. I can run a node and only store content that is close to the head of the chain. And I can only store tree paths that are likely to be queried (e.g. top few layers, paths for popular accounts/contracts (WETH, Uniswap, oracles, Layer2 wallets)). While I'm somewhat useful to the system, I'm not following portal network protocol at all.
   • I can run many portal network nodes on one machine with the same data and gain high reputation across all of them. Even more affecting as more nodes means higher chance of being asked for the content.

[pipermerriam]

Ok, so the bigger problem here is that there isn't a check against the power this gives the Client. The Client is the one paying the transaction fees, which effectively works out to the client being the one that issues reputation, so in order for this to work, one would need some way to limit the power the client has...

Said differently, one would need a way to mitigate against:

• Client gets data from Server
• Client then fakes getting data from PuppetServer which is run by Client
• Client cashes in reputation for PuppetServer account and doesn't give proper attribution to Server.

Which I think puts us back to the beginning/starting point on this problem which is that it is fundamentally hard to attribute good behavior on the network because it is trivial to fake that behavior between two colluding nodes. Lame.

[pipermerriam]

I want to spend time brainstorming on this subject in Prague.

[pipermerriam]

Ok, more thoughts on this.

The concept of anchoring to transactions that are included on mainnet is maybe the new part here.

In all of my previous explorations into reputation systems related to Portal network, I've dead-ended on sybil attack problems. If reputation is regulated by a cryptographic anchor to transactions (and their underlying fees) then we get a scarcity mechanic that solves the problem of reputation being easily attacked by puppet nodes.

[pipermerriam]

Under a naive implementation as I've laid it out above, a "client" could:

• A. Report things correctly, resulting in some kind of "incentive" for serving data related to mainnet transactions
• B. Not report things at all: no major effect
• C. Cheat and report things in a way that games the reputation system such as awarding it to themself.

Under option C with the client cheating in some way, they could even go as far as to not use the portal network at all...

So problems that I'm looking at here...

• Is there a way to have any level of reliability in reporting of the "serving of data"
• How can we reduce the power that the Client has in this scheme.
• How can we reliably enforce the "ordering" of these events so that a Client cannot somehow backfill reputation stats after the sending of a transaction.
• Is "weak" reputation still useful in some manner, even if it can be gamed by motivated actors (but still be sybil resistant).

[mynameisdaniil]

Sorry if I somehow bike-shedding the discussion, or stating the obvious, but I believe we have at least two fundamental problems here: 1) reputation system must involve some kind of third-party or even (a weak) consensus. So, there's a problem of request multiplication. 2) since no one on the network knows "everything" or "how things should be", for the lack of better words. There's no way for us (with current network design) to prevent clients from gaming the system by serving only popular content.

Which leads us to, perhaps, the necessity to have some sort of arbiter nodes (like glados). Which is against the idea of portal network and leads to the whole new set of problems.

---

Given all that, perhaps we can start with simpler approach and just maintain distributed ledger of amounts of data served by each of the clients. Have a zero set to a running average of clients around you at some set distance. And have it as a part of routing table/algorithm.

[pipermerriam]

not an active area of research.