Quote from: pararius on April 05, 2019, 10:13:44 AM

since you generated the idea in Q1 can you tell us what's different from Elastic for example that has a working mainnet? Or Golem? Or SONM?

Not all technical details are already shaped, but its already possible to point out to some differences of Prometheus59 and existing solutions:

1. Specific market pricing based on auction (not applied to Charity mission)

In Prometheus59, the so-called "marketplace" will have an auction element, which, in the event of a lack of capacity, will allow prioritizing the execution of tasks depending on the proposed payment (of course, prioritizing will not touch the Charity mission). This may be a win-win at the initial stages of development.

At the same time, if the price rises and there is a shortage of total computing power allocated for commercial tasks, the power providers will receive greater rewards proportionally to the amount of provided computing power.

Also, if there is a shortage of computing power in the network, a power renter (someone who needs computing power) can offer a higher price and thereby attract more users. In addition, users will be able to earn not only on the power provision but also on PoS. P59 will also have a task formalization system to process the maximum number of types of tasks suitable for distributed computing.

2. Specific way to determine payments for provided computing power

Payments will be formed depending on the total income of the system, but here is a fundamental nuance: all the resources allocated for Charity mission will be paid in the same way as resources used to solve commercial tasks. This will be good for marketing and drive more public attention.

3. Payments for the provided computing power, not a task
Instead of estimating the task itself by several parameters (which, for example, Golem does), Prometheus will take rely on computing power itself as an object of assessment. This will exclude the possible negative influence of certain task parameters, such as "timeout," when the task may remain unsolved.

When the marketplace object is a task, few possible outcomes are possible (for example: failed, timeout, rejected, accepted.) When the object of the marketplace is computing power, negative outcomes eliminated or even reduced totally. At the same time, the user only pays for the power he uses.