Vulnerability: Impossible to remove malicious nodes after the initial period
Severity: medium

Description:
The system has centralized power structure for the first year after deployment. An `unregisterKey` (creator of the contract) is allowed to remove Nodes that are in state `Stages.Active` from the registry, only in 1st year.\\nHowever, there is no possibility to remove malicious nodes from the registry after that.\\n```\\n/// @dev only callable in the 1st year after deployment\\nfunction removeNodeFromRegistry(address \\_signer)\\n    external\\n    onlyActiveState(\\_signer)\\n{\\n\\n    // solium-disable-next-line security/no-block-members\\n    require(block.timestamp < (blockTimeStampDeployment + YEAR\\_DEFINITION), "only in 1st year");// solhint-disable-line not-rely-on-time\\n    require(msg.sender == unregisterKey, "only unregisterKey is allowed to remove nodes");\\n\\n    SignerInformation storage si = signerIndex[\\_signer];\\n    In3Node memory n = nodes[si.index];\\n\\n    unregisterNodeInternal(si, n);\\n\\n}\\n```\\n

Impact:

Recommended mitigation:
Resolution\\nThis issue has been addressed with a large change-set that splits the NodeRegistry into two contracts, which results in a code flow that mitigates this issue by making the logic contract upgradable (after 47 days of notice). The resolution adds more complexity to the system, and this complexity is not covered by the original audit. Splitting up the contracts has the side-effect of events being emitted by two different contracts, requiring nodes to subscribe to both contracts' events.\\nThe need for removing malicious nodes from the registry, arises from the design decision to allow anyone to register any URL. These URLs might not actually belong to the registrar of the URL and might not be IN3 nodes. This is partially mitigated by a centralization feature introduced in the mitigation phase that implements whitelist functionality for adding nodes.\\nWe generally advocate against adding complexity, centralization and upgrading mechanisms that can allow one party to misuse functionalities of the contract system for their benefit (e.g. `adminSetNodeDeposit` is only used to reset the deposit but allows the Logic contract to set any deposit; the logic contract is set by the owner and there is a 47 day timelock).\\nWe believe the solution to this issue, should have not been this complex. The trust model of the system is changed with this solution, now the logic contract can allow the admin a wide range of control over the system state and data.\\nThe following statement has been provided with the change-set:\\nDuring the 1st year, we will keep the current mechanic even though it's a centralized approach. However, we changed the structure of the smart contracts and separated the NodeRegistry into two different smart contracts: NodeRegistryLogic and NodeRegistryData. After a successful deployment only the NodeRegistryLogic-contract is able to write data into the NodeRegistryData-contract. This way, we can keep the stored data (e.g. the nodeList) in the NodeRegistryData-contract while changing the way the data gets added/updated/removed is handled in the NodeRegistryLogic-contract. We also provided a function to update the NodeRegistryLogic-contract, so that we are able to change to a better solution for removing nodes in an updated contract.\\nProvide a solution for the network to remove fraudulent node entries. This could be done by voting mechanism (with staking, etc).