Discussion for OT-RFC-06

[branarakic]

Hi Tracers,

This issue is dedicated for discussions on OT-RFC-06 - OriginTrail utility market automatic adjustment plugin (AAP).

For convenience, the link to the latest version of the RFC is here

We are looking forward to the discussion!

[hottogo]

This is absolutely fantastic, I won't pretend to understand the finer details but I did read through it all carefully.

One thing I wanted to bring up: Why isn't the node holders available staked Trac taken into account? In my mind this is the most important factor to determining what price a node holder is willing to bid on jobs for.

For instance if you have 5,000 Trac available for jobs and you are winning roughly 5 jobs a month at an average Trac reward of 100 per job, you will only have 3,000 Trac locked up of your 5,000 at any one point (assuming 6 month jobs). This means you are willing to lower your price to win more jobs, as you have excess Trac available for lockup. Inversely if you have 1,000 Trac you would want to only take the higher paying jobs as you don't have enough Trac to accept all of the jobs in those 6 months.

The formulas and rationale don't seem to cover this consideration, unless I misread them which is very possible. The rationale and proposed solution seems to concentrate on the many other factors like data size (which is important given node storage constraints on servers), market price of Trac. gas price, length of time to hold data etc. However it does not cover the supply constraint which I would think is the main determining factor to what price jobs nodes are willing to accept.

At a very basic view (ignoring data size, gas fees etc.) a node will want to accept any job if they have available Trac staked that won't get used otherwise.

Hope this helps, feel free to ignore given my lack of understand of most of the formulas!

[DalSlacker]

Our (node runners') current issue with V5 is accurately described on Page 3: “Maximizing R can happen by Increasing Pmin which will require more TRAC per single job, but will at levels high enough effectively lower the number of jobs received k, thus having services underutilized and operating at a suboptimal level.” There has been no time in which the conditions of the ODN allowed this method to be effective at increasing R. Therefore without any benefit to increasing Pmin, there is no opposing force and thus the market “optimal” value for Pmin has been moving closer and closer to zero. Market forces have been one-sided and ineffective. A short-term problem, as V6 will have a different incentivization system.

The cryptoeconomics related to the AAP appear to be solid. However the fundamental issue lies in it being an optional component, which will therefore only be used under conditions that are beneficial for the user. The purpose of the plugin is to help provide an equilibrium, which in this case means moving DH lambda lower than they would like and moving DC lambda higher than they would like (both of which the user would see as detrimental). I believe the AAP, despite the intelligent design, would ultimately be used much less than intended. This would leave the network open for maliciousness. I believe that the solution will need to be implemented into the smart contract to promote good behavior.

The most basic work-around for the AAP system would appear to be a DC that creates DH nodes for their own use. By spinning up 10 DHs with 0 lambda, they could bypass the entire reward system (and abuse the nature of the decentralized knowledge graph) by winning all their own jobs and still appearing legitimate to outside parties/searches.