Ethereum decoupling

[JeremyPansier]

Context
The Ruthenium blockchain validation relies on the unicity of each validator: a single validator node wallet address is allowed for each human. This unicity is ensured by verifying that the validator is registered in Proof of Humanity with the wallet address he is using for its validator node. The Proof of Humanity smartcontract is runnig on the Ethereum blockchain.

Concern
The Ruthenium blockchain is currently strongly dependent on the Ethereum blockchain, and the Proof of Humanity smart contract calls might fail sometimes.

1. The Proof of Humanity smart contract is currently called via infura using the same key for all nodes. The infura free plan is limited to 100,000 requests a day that implies that the current implementation will reach the limit, even for a single node.
2. The Proof of Humanity smartcontract beeing in Ethereum, the reliability of Ruthenium is strongly impacted by the reliability of Ethereum.
3. Proof of Humanity smart contract sometimes returns 503 Service Unavailable: internal server failure, which might introduce blocks validated by non-registered validator.
4. Ruthenium currently relies on Ethereum for the private key generation.

Goal
Determine whether these concerns are relevant and find some ways to solve them. Intermediate workarounds are welcome because the final solution might imply a lot of work.

[JeremyPansier]

Suggestion
The decoupling might be done in several steps:

1. Require the POH smartcontract infura key as a program argument (see The POH smart contract calls might reach the limit #212)
   This might reduce the usability of the blockchain because the validator needs to create its own infura account. But it is a quick win to implement and it improves the reliability and scalability.
2. Create an extra light Ethereum node to directly call the POH smartcontract (see Unreachable poh contract might introduce unverified blocks #141)
   This might reduce the portability because the node will embed an Ethereum, and then will certainly be heavier and more resources consumer. This step might imply a lot of work. But it restores the usability because the validator doesn't need to create an own infura account anymore. It improves the reliability because it avoids key sharing potential issues. It improves the scalability because there will not be any smartcontract requests limitation.
3. Integrate Ruthenium own POH smartcontract (see Integrate POH smart contract #213)
   This part implies a huge amount of work. Besides, it reduces the usability because the smartcontract popularity will not benefit of the Proof of Humanity community which is growing each day. However, this should restore the portability because the node doesn't need to hold the Ethereum blockchain anymore. It improves the reliability because there should never be smartcontract requests errors, and the sustainability of Ruthenium will not depend on Ethereum anymore.
4. Handle private key generation (see Handle private key generation #214)
   Once the smartcontract will not be the official Ethereum powered POH one, there will not be any reason to relates an Ethereum wallet address to a Ruthenium one. Then, the private key generation could be handle by Ruthenium, and thus, finishes up decoupling Ruthenium from its lovely launchpad Ethereum.

feature	none	personal infura key	embedded light node	own smartcontract
related issue		#212	#141	#213
achievability	✓✓✓	✓✓	✓
reliability		✓	✓✓	✓✓✓
scalability		✓	✓✓	✓✓
usability	✓		✓
portability	✓	✓		✓