ROI is not something given, it’s something earned. We are confident we can lower both OpEx and CapEx to levels that will exceed a 10% ROI. The burden is on us to prove it to our investors!
The other thing to consider is that the returns assume no appreciation in the underlying asset, VID. It’s a finite supply token essential to the production of the network. The demand can only go up unless Delegators lose confidence in the network operators. At this point that would just be sad.
Please don’t take my comments negatively.
What’s the economical life of hardware before it needs upgrading?
3-5 years? Would you consider this to be a good investment even if ROI is 20%?
It’d take you 5 years to get initial investment back. I’m not shooting down any good ideas or work but trying to see how dCDN like videocoin can grow for new comers.
This model is highly skewed towards existing under utilised data centre I think who will only have to worry about acquiring vid token.
I can understand that. Here’s a hint at how we intend to approach it:
(1) Co-location with power plants
(2) Modular Blocks that precluded data centers
(3) scalable labor models
(4) retail value optimized compute components
The above formula tells us that we can beat the competition with margin. Like I said, its up to us to prove it not for you to believe it. We hope you’ll come along for the ride with us when the time comes!
I am looking forward to seeing what you can produce.
When do you think it’ll be ready?
Will your model work for anyone including those who aren’t programmers or limited knowledge of operating such things.
We anticipate our pilot to be online in a few months, preferably AFTER a publisher has been oboarded to the VideoCoin network so we can point to it and tell our investors, “see, people are using it, now give us money to compete!”. We are in the process of building our suppy chain and validating our thesis (it includes other forms of concurrent compute besides transcoding, that’s just one piece of the portfolio). We are very excited over the future with permissionless incentivized compute in general.
From there our 5 year goal is 50 MWe of deployment equivalent to about ~ 29,000 CPUs in service. We hope to be able to give each delegator a “batch of CPUs” that they each have a claim on revenues, rather than the inverse model of a mining pool.
@devadutta The more thought I put into it the more it’s becoming clear that the “traditional” mining pool model of PoW is inappropriate for VideoCoin. What we really need are anti-pools. Hear me out.
The reason that mining pools first originated in both Bitcoin and Ethereum is that the underlying incentive (BTC / ETH) are fixed for each block time. Since the network difficulty is variable, designed to maintain a constant block time to avoid double-spend & uncle/orphan blocks, the ability of a given unit of hash to derive the incentive via competition is stochastic (variable). This means even the operators with the largest amount of hash available have no economic guarantee of earning awards, and even less so, those with less hash.
The solution to this uncertainty of capital deployment was to form a pool of operators that agree to split the reward mined by any participant in the pool in direct proportion to their relative hash contribution. This makes sense because it’s taking the risk proposition of deploying capital for hashing and spreading it evenly among the hashrate.
VideoCoin does not work that way, nor does transcoding. The amount of work introduced to the VideoCoin network, and therefore the incentive payout for that work, has nothing do with a stochastic process nor a fixed block time. Furthermore, the distribution of that work, although weighted by VID delegation in the randomizer, is in proportion to the network throughput for a quantity of 30 second packets. This means a saturated VideoCoin network (more demand for compute than available supply) means that all workers will obtain work regardless of VID staked above the minimum self-stake.
This is true because a video of any significant duration will exceed the real-time available transcode compute in a saturated condition and packets will “waterfall” to the next available worker in the que because all of the other workers with greater quantities of VID are “busy” with the first round of packets.
Let’s imagine a scenario in which there are 100 workers on the network and for simplicity the total time for processing of a micro-job (packet of video) is equal to real-time (1:1) because of network latency and CPU performance. If 3,000 seconds of video (50 minutes) come into the network for processing the network will become saturated. Now imagine the first 50 of those workers has twice the amount of VID as the second half of 50 workers, it won’t matter because all the workers will get work in this scenario.
Given this understanding, if we return to the pool concept we realize it’s backwards. Each worker in a saturated network is guaranteed to get work (regardless of total VID staked). What actually matters isn’t that workers / delegators share risk of deploying capital (like in the case of BTC pools) for rewards, what matters is that their capital receives the MAXIMUM amount of value in greater proportion to the competition.
In theory delegators should want workers in which they don’t have to share their rewards with any other delegators. This is because lone-delegation in a saturated network is guaranteed capture the full 20% of the transcoding revenue. This in contrast to shared delegation in which a delegator receives a prorated amount as compared to the total stake (other delegators + worker self-stake).
The long term growth of the network is therefore predicated on workers striving to dedicate compute to delegators without them having to share it. This is how workers can differentiate themselves, not by spreading the risk of capital to all worker nodes and delegators, but rather committing a dedicated amount of compute per unit of VID delegation. Those workers that provide a given unit of transcode on a per VID basis (think fps / VID) will ultimately outperform the competition. I called this the Anti-Pool.