Cloud Services - Decentralization  

  RSS

bumble
(@bumble)
Active Member
Joined:5 months  ago
Posts: 5
22/06/2018 12:01 am  

Using cloud services it would be possible for the Coop to essentially offer pre-configured instances optimized for validating in a specific shard--could suggest geography, instance type, and even supply the image. There are several cloud compute companies, including Amazon, Microsoft, and Google but also probably many others. Is it possible to make any statements about the impact on perceived "decentralization" based on the mix of on-prem machines and cloud instances (perhaps considering geography of the instances, domicile of the companies providing them, and anybody's best guess at the likely correlation between triggers that would cause cloud services to pull the plug on instances)?


ReplyQuote
nash e. foster
(@nash)
Member Admin
Joined:10 months  ago
Posts: 5
22/06/2018 3:41 pm  

I worry particularly that the use of the large cloud providers would have undesirable effects on the network. Decentralization is one such effect, but I'm a bit less worried about that than you might think. Some shards will be more decentralized than others and having an "AWS West" shard doesn't seem unreasonable, on its face. On the other hand, the large cloud providers will take a large chunk of the validator's revenue, and that amounts to us paying "rent" to AWS to provide services that we could provide ourselves. Rather than coordinate with large-scale providers like AWS, I would prefer to see more individuals, Coops, and companies within the RChain ecosystem step up to provide infrastructure themselves. I think this will happen in time as we release more details about the infrastructure needed, so stay tuned.

Whether or not the large providers of cloud infrastructure would shut us down is an interesting question that I haven't thought about deeply, yet. Losing your service means you're likely to lose your stake or, at best, be ejected from the validator pool. That's a serious financial risk to validators that are trying to make a living building the RChain network. Validation doesn't require special hardware or anything, but it does require bandwidth and general purpose compute, so load is likely to be significant. I doubt that would be cause to terminate nodes, but if the cloud companies wanted to prevent nodes from validating our network, it would be relatively easy to tell who was doing it. After all, the IP Addresses of validators are well-known and public.

Nash E. Foster
Cofounder & CEO, Pyrofex Corporation
"Nearly all software is in the future."


ReplyQuote
jerry
(@jerry)
Eminent Member
Joined:8 months  ago
Posts: 31
23/06/2018 4:03 am  

Losing your service means you're likely to lose your stake 

@nash, as I understand from Casper,  it does not make harm when validator does not send message, or the network is too slow to deliver messages. In fact validators are unable to differentiate these 2 cases and slow/unresponsive validator is  slashed by others.

The threaten is from equivocation, that is, validator bets on different fork on the same state.

I thought only equivocation would be punished.
Do you mean  slow/unresponsive validator will also lost stake besides  equivocation?

We care about this because we are from the mainland of China and intent to participate in validation(mining).
The connections/bandwidth from mainland to other areas of the world are significantly impacted by GFW(Great Firewall), it is not stable for a validator located in mainland to communicate with the rest of the world with normal network connection. We usually pay extra/higher fee to rent a special line for stable overseas access . Hence hosting a validator on cloud platform in HongKong or Taiwan might be a better choice for us.


ReplyQuote
nash e. foster
(@nash)
Member Admin
Joined:10 months  ago
Posts: 5
23/06/2018 10:58 pm  

Great questions! Looking back at my comment, it looks like I could have been clearer.

1) Can I lose my stake due to network failure/performance?

No.

2) Is equivocation the only thing that is punished?

Yes.

3) Can I validate from China?

Definitely! In fact, tweet me @NashEFoster if you are interested in participating in TestNet launch.

Just remember: RChain is a sharded blockchain. There will be global shards, but global consensus algorithms are slow. Global shards can be very secure. We need validators from all over the world to contribute to the security of the global shards. We want parts of the network to be very fast, so there must be some local shards too. You should plan to run a local shard in China that is very fast in China. People who want to run dApps targeting the Chinese market will want to deploy smart contracts to your shard. Many namespaces across the world will be suitable for validators located in China, particularly those namespaces that want maximum decentralization.

4) You said the word "ejected."

First, I was answering a hypothetical question, so I was speculating a bit. That said... Some shards do need to be fast for the users. IMO, such shards must get rid of validators that are too slow. In PoW, if you are "slow" then you simply don't earn anything. But, in RChain there are forms of fee-splitting between validators and a slow or down validator is still earning fees while doing nothing. We have to worry about freeloaders because in the limit freeloading is denial-of-service. My preferred solution is removing validators from the validator pool if they freeload, but not slashing their stake. Not everyone agrees with me, notably Vlad, so this might not be a thing in the end.

Reminder: If you forward bad blocks, that is equivocation, rather than freeloading.

5) Anything else?

If you're on a cloud computer, the VM's owner can take control of the machine while it's executing. On PoW networks, the worst they can do is halt your program so that you stop getting revenue. On a Casper network, they can take control and cause your node to equivocate, resulting in a loss of stake. This can happen very fast. Much faster than you could detect it and respond to it. Staking the network with someone else's computer has inherent risks.

For low stake nodes, maybe this isn't a problem. Maybe the hosting provider is trusted for other reasons. Regardless, please be very careful when considering your security model and choosing cloud vendors. Make sure that the provider's interests are aligned with the best interests of yourself and the communities you care about.

Nash E. Foster
Cofounder & CEO, Pyrofex Corporation
"Nearly all software is in the future."


ReplyQuote
jerry
(@jerry)
Eminent Member
Joined:8 months  ago
Posts: 31
24/06/2018 1:46 pm  

Thanks @nash

Equivocation, also known as nothing-at-stake problem, is caused by the incentive that -- validator intents to gain more rewards.
Only finalized block grants rewards to the miner(validator who generates).
As a result, baleful validator produces mutliple blocks at the same height but links to different forks. They want to their blocks to be finalized as possible as they could so that miner gains more transaction fees.

What I can't understand is the word control in your reply.

they can take control and cause your node to equivocate, resulting in a loss of stake.

What kind of control do you mean?   cloud provider hacks its customer's server? 

Personally I trust cloud provider like Google, I dont believe they would hack my VM.
Still there could be some tiny influences from the platform to my VM.
e.g. When there is some problem with the physical machine and they move my VM to another physical machine seamlessly, and I even cant feel that.
e.g. Sometimes they have some incident and my VM is inaccessible.

So, if cloud provider does not hack into my VM,  how could they control my VM to equivocate?

Edited: 5 months  ago

ReplyQuote
  
Working

Please Login or Register