derekpierre
commented
5 years ago Thoughts (attaching a spreadsheet which clarify Arj's calculations) NU Service - Cost Pricing.xlsx
(1) Our assumption about equal Ursula stakes is a big one, in that revenue will vary widely across the different Ursulas given their variance in size of stake.
(2) For the one-time cost of a machine, I don't think we should factor it into a monthly profit calculation. The machine is either a sunk cost if they have a machine already, or a fixed cost if they have to purchase the machine neither of which should be used in a contribution margin calculation. I agree it is a real cost, but it can be amortized over a long period of staking and can be used for other purposes if no longer staking.
(3) It is possible that Ursulas with smaller stakes/hobbyists will potentially not utilize the cloud as much as Ursulas with larger stakes, so the revenue needed to cover the cost would be different. In your calculation above, something ~$10.95 in cost - still something that needs to be covered, but smaller revenue needed.
What's interesting is that your calculations have illuminated the issue of the professional stakers (including us as a company) having a tougher time profiting from staking since this group is more likely to utilize the cloud.
(4) For pricing, we have two approaches: cost, which Arj has done clearly, and the 'willingness to pay' of adopters. As a product we are offering functionality that is unavailable elsewhere: decentralized, censorship-resistant, no single point of failure, data privacy protection. The question becomes given the current less feature-rich alternatives, the requisite centralization and data privacy issues, what are applications willing to pay for our service. For example, in the use cases above the Azure Key Vault calculation works out to a higher cost than the KMS solutions. This is presumably because of Microsoft (ugh) but also the extra functionality provided by an HSM.
We are somewhat bounded, but centralization for a decentralized application would seem to be a big deal to me. A dApp that doesn't work because Amazon was down would not bode well. I think the value of data privacy and decentralization is worth something, and charging value for that worth could be something that applications would be willing to accept.
arjunhassard
Firstly, we confirm that, at launch, the network service will be fully commoditised. In other words, initially there will be a default, universal relationship between a policy's duration (+ # Ursulas involved) and the price of that policy, regardless of other factors (e.g. historical reliability of those Ursulas). Next, we need to narrow in on this uniform cost in real terms (i.e. in ETH or USD), through:
(1) analysing of overheads required to run a reliable Ursula (2) comparing to existing services and their pricing models (3) testing potential pricing (outcomes of 1 & 2) with adopter budgets (4) taking into account other third-party costs (e.g. fiat->ETH conversion fees)
(1) Overheads Assumptions based on network expectations: a. Ursulas must be online (nearly) of the time – minimise interruptions b. Ursulas should dedicate a machine or server to re-encrypting – minimise security/downtime risks d. Ursulas will ideally have an anti-DDOS solution running – minimise censorship/downtime
Most Ursulas will achieve these requirements in one of two ways: with a cloud solution or a physical machine.
Cloud Monthly Costs
Cloud Ursulas will still need an internet connection, which varies worldwide from $10 to $150 per month, but we can assume that most nodes do not need to upgrade their internet to service the network. Given minimum memory constraints, the minimum spend for a cloud approach is at least $10/month, but more likely to be between $20-40/month.
Physical Machine Costs
Assuming that Ursulas will predominantly be located in regions with cheaper energy, and that re-encryptions do not require high wattage nor an expensive machine, and that the Ursula spreads out their payments for the hardware over 1 year with 0% interest: Cost/month = ( [$0.10/kwh]/1000 150W 730h ) + ($450/12m) = $10.95 + $37.5 = ~$50
Conclusion There will be lots of variance, but we can assume that if an Ursula is earning less than $10 per month in revenue, they'll be making a loss. Or, if most Ursulas aren't making more than $10, it will make node operation unsustainable or pointless in all but a few super cheap regions. If they're earning less than $50, then they're not covering the cost of their hardware, which is significant because we may expect a dedicated machine that shouldn't be used for anything else (TBD).
It's important to note that this floor of outbound costs is largely unaffected by the size of the Ursula's stake, since the vast majority of expense goes into ensuring high availability rather than handling a big re-encryption load. In other words, we've identified the minimum cost of running a node, regardless of how much work is taken on.
(2)Pricing of alternative products It is likely that customers will pay more for better security, trustlessness, decentralization, a wider range of operations, or the unique capabilities of Ursulas, Enricos, etc. However, our prices are still bounded to some extent by the cost of alternative providers (centralized or otherwise) and their pricing structure:
Software protected
HSM-protected
Use case Let's walk through hypothetical use cases and see if our nodes are profitable. We'll assume we have 500 nodes in our network. A gaming DApp has 10,000 users who play 2 games per day. In each game, 50 decryptions occur per user. We will also assume that the game developer wants to provide a semblance of trustlessness to users, so generates an individual 'master key' for each (_Note: this is a big assumption as most developers use a small number of master keys to handle access for a large population of users). In any case, using AWS KMS would cost the app $91 in decryptions and $10,000 for maintaining unique keys each month, which equals $1.01/user/month. Using GC KMS would cost $456 for decryptions and $13,000 for keys, which equals $1.35/user/month. If NC matched GC KMS on total cost, this would yield $27 in revenue for each of the 500 nodes. Looking at other use cases with the same number of users and matching GC KMS's per user price:
Other assumptions:
(3) Adopter Budgets Our prices are also bounded our adopters' budgets, which in turn are bounded by their revenue models – e.g. how much does a DApp make per user, and does this justify the overhead of each user's sharing flows. So the next questions are:
TBD: Changing the pricing How easy is it to dynamically alter the price as a respond to demand (or lack of), or other factors?