Consider further analysis of more blockchain transactions

[databu]

The idea is that instead of just looking at tx between users, we might also consider e.g. overlaps in the sets of smart contracts (tokens, d-apps, ...) between them. Generally, the idea would be to apply collaborative filtering on all tx involving 2 or more user addresses.

Main questions are

1. Would an application of collaborative filtering be feasible?
2. If not, are there alternative feasible recommender system mechanisms?
3. Would such recommendations actually be meaningful?

[databu]

Let's consider this on a high level. DeFi Protocols are decentralised apps with some financial function, such as decentralised token exchanges (DEX) and lending protocols. Decentralised apps are apps which do not use centralised servers or services as their backends, but smart contracts.

Many DeFi Protocols use liquidity pools:

1. Automated market makers (AMM), a form of DEX, have liquidity pools for trading pairs. E.g. the UTU-ETH pair on Uniswap has UTU and ETH; the price is determined by the relative amount of each token in the pool. Liquidity providers (LP) typically earn fees on swaps that happen on the trading pair, according to their share in the pool.
2. Lending protocols have liquidity pools to be lent to borrowers. LPs typically earn a part of the interest for the loan, according to their share in the pool.

Ocean Market works like an AMM for data asset tokens: The publisher of a data asset creates a data token and a trading pool for that token, where it can be swapped for Ocean tokens. Other people can then buy the data tokens from the pool. They might then consume the data asset -- some are downloadable, others are available for processing by an algorithm in the cloud --, which (at the moment) always costs 1 data token.
But if they want, they might also put up liquidity themselves, by putting the data tokens + according amount of Ocean back in the pool. By doing so, they're basically speculating that the data token will grow in value.

There are certain risks with providing liquidity:

1. By putting tokens into any pool, it gets slower and more expensive for the LP to sell those tokens. Because they must remove the liquidity from the pool first, i.e do an additional transaction which is expensive on Ethereum (several 10s up to a few hundred of USD). Lending protocols might additionally have constraints on when tokens might be removed.
2. If one the tokens in the pool looses value against the other, this can lead to increased loss vs. the case whether the user would have just held the token. This is called "impermanent loss", though it can easily become permanent if the price doesn't recover, and the user has to eventually take their tokens out of the pool.
3. Most lending protocols are over-collateralised. However, the collateral might be paid in volatile assets such as ETH, Bitcoin or other tokens. There's usually a mechanism which automatically distributes the collateral to lenders if its value falls below a certain point, but then of course it would already have lost that value.

Apart from this, there are the general risks that smart contracts or even the blockchain platform are buggy, or that some interactions have unintended side effects. For example, see MakerDAO's "Black Thursday" last year.

To mitigate the risk from smart contract bugs or design issues, most serious protocols have their contract audited by 1 or more auditing firms. Their are some more or lesser known names in the market.

Finally, there are more kinds of DeFi Protocols like yield farms and staking vaults. They generally represent locking up tokens in some smart contract for rewards, so generally it might be said that they carry similar kinds of risks as AMM or lending protocol pools.

For a description of trust issues in the DeFi Space and how UTU can help, see also our concept note.

Taking this all together, the present idea for Ocean is this: consider that a user considers buying (swapping) data tokens for data asset A, e.g. for consumption, putting up liquidity, trading elsewhere, and/or just holding it.
They might also

1. have put up liquidity in pools for data tokens for other data assets and/or in pools for other DeFi Protocols,
2. have swapped using some pools.
3. hold certain tokens (tokens themselves are also smart contracts, except the "native" one, Eth)

Now there might be other users who have bought/consumed/provided liquidity for A, and who's past transactions (partially) overlap with those in 1., 2. and 3. I.e. they might provide liquidity in some of the same pools, have swapped in some of the same pools, and hold some of the same tokens.

The main questions in the description above should be answered in this light.

[LeahN67]

Thank you @databu

[LeahN67]

I think a similarity matrix to calculate the recommended score for the items can be calculated either by the user-based CF or the item-based CF techniques. The information that will be used is from the user preference and ratings on the data assets swapping. These recommendation scores can create a rating system on the blockchain in the form of a smart contract that users can use when selecting new data assets to purchase.
Although, both collaborative filtering techniques can work well in the process the user based CF technique might result to a higher gas cost.

[databu]

Thanks, a few things to note here:

• This is about generation of new types of recommendations from the Trust API, like "Users who also provided liquidity on A and B, and hold tokens C and D, consumed this data asset".
• We scan the tx from the blockchain to add to our (off-chain) graph DB, but we don't want to write anything there; i.e. no smart contract and no gas fees.
• I don't think we should ask user preferences about the CF type to use here. User preferences should refer to easily understandable things, like "Do you trust fellow holders of the same tokens more than others?"

[databu]

Oh, also, while scores might be used internally to identify the most relevant recommender(s), they shouldn't be made visible to the user. The user should only see easily understandable recommendations like the example above.

[LeahN67]

Question: Are the users allowed to rate ?

[LeahN67]

I would like to know what information will be available for the recommender model.

[LeahN67]

To solve the issues you have highlighted above the following can be done:

1. Use the Matrix Factorization CF-you can use either implicit or explicit user information. This means that we don't have to ask for any information from the users.
2. To deal with the gas fees (there is a research done on this):-data is stored in a blockchain structure that is defined in smart contract. This data is then provided to recommender system out of blockchain through the public key of the smart contract to be processed for providing the appropriate recommendations to the user. The results are then stored in blockchain through a transaction to be presented to the user. the results of the present study and comparison with previous works show that performing complex off-chain calculations reduces the transaction cost in terms of gas consumption for the smart contract deployment as well as the execution of recommendation function defined in smart contract.

[databu]

Another idea: common DAO membership

[databu]

@LeahN67 these kind of recommendations would be shown in the Ocean views of our DeFi Portal, and later in the Ocean Market itself (see also our prototype for including community signals).
In our DeFi Portal, connect e.g. with address 0x73bb131dDBA7C32C0B193A0e711C9cf43C7B01d0 to see some numbers > 0.

[databu]

Idea: CF which identifies similar users based on their usage of Ocean Assets (Pools and Datatokens), selected DeFi Protocols and selected tokens which are held.

For example, the current user

1. Consumed datatoken 1,
2. Provided liquidity in a pool for datatoken 2,
3. used Uniswap and Compound, and
4. holds UTU and LINK.

Then other users with a similar "profile" should be considered more relevant than others.

1., 2., and 3. are already available. 4. needs to be added to the scanner: we should model tokens as nodes in the graph and have relationships of type :balance from :Address nodes to them, with properties balance and timestamp, representing the latest known balance.

Technical considerations:

• CF should work on our neo4j DB. Any missing data shall be added to the scanner (create ticket describing which data to get, how to write store that in neo4j, and assign to @tarasherasymchuk )
• Are there easily integratable CF modules? Check this neo4j blog post and link to Graphaware therein.