The more I read comments regarding the SuperNodes (and there are many good ones out there), the more I feel that the initial release of XEL should not include SuperNodes. Although, I think the community will find out quickly that XEL really needs the SNs (i.e. I doubt any exchanges will even list XEL w/o them because it now means they are processing ElasticPL work in their exchange).
There are just too many open questions and too much uncertainty being expressed here. In my opinion it will take a couple of months to fully vet out all these design questions and deploy a fully tested SN solution.
But I have no say in this...I'm just observing what is going on.
Hi Coralreefer, first of all, thank you for your hard work ! I think the uncertainty around SN is mostly because some of us ( like myself) are not tech savvy. We don't know ( in plain language) the pros and cons of having ( being) a SN. Is SN for regular people or tech experts ? Also, the fear of making mistake and losing 250K is also a big concern. How can this be avoided ? I appreciate if you could shed some light on these concerns in plain English
Bgjjj2016, I missed this post earlier.
- From a user perspective, the advantage of running a SN is that you will receive a percentage of all mining rewards.
- From a community perspective, we would need enough SNs running so that all active miners can have their work quickly validated...this will obviously depend on network size.
- It's really up to the individual if they run one...but honestly, I would think there would only be about 10 to 100 running...it's not meant to replace the miners...it's just people that want to support the network and goal of xel.
I completely agree with the concern around the potential to lose 250K xel...I personally think the network would need some extended testing to prove to all of us that this is implemented correctly.
Again the main reason for the SNs is that the core client (the java code you run for your wallet) is used to secure the network and process transactions. Unlike other coins, we don't have a fixed POW algorithm...I could easily come up with something where the POW / Bounty validation takes 1 full second. Now think about the core server having to process all the wallet transactions as well as having to potentially solve 100s or 1000s of these validations dumped on it...it would bring the network to it's knees...this is where the concept of the SN came from (we probably should have chosen a different name as it has nothing to do with securing the network like other coins)...we were just moving all the validation logic out of the core client (i.e. wallet).
If we don't have SNs, we would just have to limit the size / complexity of the work that xel can do (which in turn limits its usefulness to those needing problems solved).
Regarding the suggestion to add a flag to allow the wallet to not process ElasticPL work...I still think its a good short term fix (but my vote doesn't count as I don't work on the core client)...but my guess is the reason this flag didn't exist in the first place is...what if everyone turned that flag off...then there would be no one to process ElasticPL jobs and the xel concept is dead. Or maybe a more realistic scenario...let's say you want to run a POW miner and you have 10 Peers, but all those Peers have the flag off...even though everyone else in the network may be processing ElasticPL jobs, you would be out of luck as a miner because your peers cannot support you.
Hopefully this answers your questions, but unfortunately I know little to nothing about coding p2p networks so I am of little help here as the open SN questions are mostly network related.
.
) in ETH