Software packaging and updates for validators
faddat opened this issue · 3 comments
This started its life as a terrible issue. It was unclear for sure. Basically what I was asking Tuan initially was if he felt that I should package the two pieces of a tendermint blockchain app in a single container ("Tendermint" + the app itself) or have them in two containers, which are linked.
....but he's now got Tendermint in the codebase as a library for the app, so that is not necessary-- the app can be distributed as a single binary.
....but the questions remain about how to package this despite that. There are also questions that come up as a result of scaling a chain like this, and of course, that pesky speed of light.
Depends completely on what your running shit on. In k8s you can probalby just set it to be 2000 scale. Reliability is going to probably be important.
Thanks Dan! I appreciate your contribution and very happy to see you here!
Let me tell you that first of all, this issue has a problem with it, which is specifically that I greatly overestimated the number of validators that we could do without pushing github.com/tendermint/tendermint to much higher per-block times (and thus possibly encountering bitcoin-esque issues with confirmation times.)
I'd like to take you (and thus any other visitors here) through the situation in as deep a fashion as I can, so here goes:
- I've been operating form the assumption (and I don't think this is incorrect in any way) that more validators is better-- except for speed, that is. So if you download a bitcoin full wallet (https://bitcoin.org/en/download) (or if you are still an Arch user you can just sudo pacman -S bitcoin) (or maybe bitcoin-qt.... and you definitely want the QT wallet in this case...) then you open up the client and look at the network stats you'll see you are downloading a monumental shit-ton of data. This is because you're going to be a full node, and full nodes store the whole chain. Now, bitcoin is designed to scale to an unlimited number of full nodes.
Tendermint is not. At least, not yet. Now, the blockchain-religion types do get their head in here somewhat about this, saying that because N random user cannot participate in the validation of blocks if they do not have a validator key (a key that is made by nodes running the chain which nodes to be able to validate blocks, and therefore, to recieve funds in exchange for their validaton services.) I'm of two minds on these keys:
a) Using them causes a type of SPOF, specifically, us.
b) They're useful: Helps us to find people who are actually interested in the project because we charge for the keys.
- The ideal distance for these nodes is as far away from one another as possible with the lowest possible ping. We have a router that we're going to be selling that should help to reduce this distance by accepting two high-speed, residential-class connections. So, k8s-- at least in a single cluster, we've got to rule out, though I'm not going to entirely rule it out though... I think it looks pretty ill-suited to the task compared to swarm or nomad+consul. Docker swarm would be a one-up on it because it has a looser clustering concept that has been tested in projects like (I think it was...) swarm 2000 (and swarm 3000 ) randomish machines all over the web that ran in an efficient swarm.
....but then there's the next bit:
Depending on our business model, we may never want to operate a swarm. The chain may be better off (in terms of its well-being) if it doesn't have a central update mechanism for a ton of reasons. So then, it would come down to all of the validators keeping their nodes up to date. There are good options for doing this automatically with relative ease in go, but we would find once again that this would become an SPOF. Your thoughts are welcome here, as well.
- Solutions
a) modify tendermint to include a structure with node elevation-- essentially, kazaa/skype/gnutella old-school super-peers, but we would take that a step or two further and elevate a peer exactly as much as its variance from the norms requires. This couldn't be a "now" thing as it's complex on the best of days and nightmarishly complex on days that are average. Still, it's probably something that could be done, albeit with risks.
b) Never worry about docker and proceed forward without it.
c) Assist validators in getting the first container running, and show them how to update it.
Vis-a-vis validators, the current plan is to get set up with ten of them, and then begin to operate chains sequentially.
There's also been some recent talk of operating purely permissioned chains that DO have clear operation via the company. Spent some time writing this up, and going to grace it with a diagram of peer elevation, as well.
Polls will be an easy to set up and execute type of content on glogchain. They're essential to great collaboration.