Allow more than one nodes running under the same account for redundancy

[ngtuna]

Only allow one node to create block. The other node(s) only import.

Adding a check message calling to bootnode to collect running nodes in the network at this below function:

func (s *Ethereum) StartStaking(local bool) error {
	// TODO: check bootnode.
	// send findnode msg to bootnode here

	eb, err := s.Etherbase()
	if err != nil {
		log.Error("Cannot start mining without etherbase", "err", err)
		return fmt.Errorf("etherbase missing: %v", err)
	}
	if posv, ok := s.engine.(*posv.Posv); ok {
		wallet, err := s.accountManager.Find(accounts.Account{Address: eb})
		if wallet == nil || err != nil {
			log.Error("Etherbase account unavailable locally", "err", err)
			return fmt.Errorf("signer missing: %v", err)
		}
		posv.Authorize(eb, wallet.SignHash)
	}
	if local {
		// If local (CPU) mining is started, we can disable the transaction rejection
		// mechanism introduced to speed sync times. CPU mining on mainnet is ludicrous
		// so noone will ever hit this path, whereas marking sync done on CPU mining
		// will ensure that private networks work in single miner mode too.
		atomic.StoreUint32(&s.protocolManager.acceptTxs, 1)
	}
	go s.miner.Start(eb)
	return nil
}

[etienne-napoleone]

Isn't a node already a redundancy of the data at the blockchain level?
Wouldn't it be implement redundancy for redundancy?
What are the use cases in a stable chain for that?

[ngtuna]

Isn't a node already a redundancy of the data at the blockchain level?
Wouldn't it be implement redundancy for redundancy?
What are the use cases in a stable chain for that?

Considering the master-slave model that a masternode get trouble and the slaved one can quickly pop-up to producing/validating blocks. It means that we will support multiple nodes running under the same coinbase account but there will be only one of those can produce and validate block.

On the other side, if a masternode runner owns more than one masternode, this case might not be preferred as he can quickly copy the data between them.

[redrocketgt]

I love the master-slave idea.

There are many scenarios where it will be useful eg, at some point a data center will have maintenance. Why should a normal event like that cause a master node to be slashed at no fault of theirs? Natural disasters etc. If people are on vacation/sleeping and the master node has an issue the slave can take over until the master is fixed.

As of right now I run a full node (in a different country) as backup so that I have chain data available if needed. The chain data is large and hard to copy in-time before a node gets slashed. I would sleep much better if my backup node could automatically take over if needed.

Some people may vote basted on slash history, if there is a way that greater up-time can be achieved I am all for it. It is not mandatory and who desire to run a backup node can. It will only benefit the network.

[etienne-napoleone]

@redrocketgt
I have no strong opinion about this feature, but wouldn't running a backup node cost much more than getting slashed for one/two epoch until the maintenance/outage/restoring from backup is finished?
I agree on the argument about the slashing history

[redrocketgt]

That would be true if we babysit the node 24hrs a day. What if the node operator is working and does not have access to a PC, sleeping or on a plane traveling? It will be alot longer than one/two epoc.

[ngtuna]

In fact this feature isn't designed for rich person who owns multiple masternodes with strong network connection; and it's also fair to say that this feature doubles the money which is quite bad at this time when $TOMO is under value. Consider the technical pov, master-slave design is quite a standard in the term of database operation. Thus I think in the long run this feature is valuable. But tbh we don't really pay attention on this feature at this moment.