Price discovery in lieu of a market

[mhluongo]

We're avoiding on-chain markets and the number of issues they bring to keep node selection, including Sybil attack vectors. The random beacon will let us fairly match keep providers and clients, but we still need a way to discover price.

One approach is to eschew price discovery, and instead set prices centrally. This approach has the benefit of predictable pricing, though it's not adaptive to the market. This might work in the short-term.

Another approach is to try to remove the "bad parts" of the ask/bid market by making order matching random, but still taking client and provider preference into account to set a price. This makes for unpredictable pricing and requires a more complex incentive structure.

The best mechanism I've seen to solve this problem is Bitcoin's "difficulty re-targeting", which adapts to miner hashpower. If we take a similar approach, we'll still need an objective function.

[mhluongo]

Variables that might impact price discovery

• Per-node deposits
• Keep sizes
• Price per operation
• Price per block

[mhluongo]

To simplify pricing initially, we can only offer a single keep size.

We can also collapse price per block and price per operation into one variable using something like this.

Price_RSA = Constant_RSA * PricePerOperation(PricePerBlock, N)
Price_AES = Constant_AES * PricePerOperation(PricePerBlock, N)

That way, the only price that needs discovering is the price per block. The constants for AES, RSA, and other operations can be centrally planned and found empirically based on the protocol performance of each operation.

Clients might want to require a higher keep node deposit, affording some extra security against collusion without the price and performance penalty of additional nodes. To support this without devolving into a market, it should be an input to the price per block.

PricePerBlock = BasePricePerBlock + (Constant_NodeDepositDiscount * (KeepNodeDeposit - BaseKeepNodeDeposit)

That implies another parameter that needs to be fixed- BaseKeepNodeDeposit.

[mhluongo]

We're now down to two floating parameters, BasePricePerBlock and BaseKeepNodeDeposit.

The two are related- the price per block divided by the number of nodes gives us the reward for each keep node, per block, in the worst case without operations. The likelihood of a keep node failing per block is the likelihood of a node losing its deposit per block.

BasePricePerBlock / NumberNodes = NodeRewardPerBlock
BaseKeepNodeDeposit * LikelihoodOfFailurePerBlock = NodeRiskPerBlock

Obviously NodeRewardPerBlock needs to be greater than NodeRiskPerBlock. The closer together they are, the better for the client and worse for the provider's margins. If some minimum margin isn't met, the opportunity cost of running a node and risking a deposit will be too high.

We're starting to get closer to something like difficulty. If we don't have enough providers, increase the reward / risk ratio. If we have enough, lower the ratio.