Implement slashing prototype within rdPoS

[jcarraror]

• Motivation: Currently, the rdPoS consensus mechanism lacks checks for malicious nodes attempting to push malicious transactions or failing to create a block or a given transaction. It is essential to address these edge cases to maintain the chain's progress.

• Objectives: Successfully handle edge cases, such as malicious validations, to ensure the chain continues moving forward.

• Success Criteria: Prevent the chain from halting due to malicious actions by validators working against the network.

• Dependencies: No external dependencies are required for this milestone.

• Risks and Mitigations: This challenging milestone requires a deep understanding of the rdPoS consensus mechanism and the implementation of appropriate conditions for each type of misbehavior. Each edge case must be analyzed and understood. For example, a node might not produce a block or a transaction while being selected for it within the rdPoS random list. A potential solution is for other validators on the list to agree that the validator was offline, reshuffling the random list, and temporarily removing the offline validator. Another case might involve a validator attempting to spoof a transaction or create an invalid block. The same solution can apply, but the validator may be permanently banned from rejoining the list. Transactions that call the rdPoS contract within the block can be introduced to include slashing operations, ensuring that this operation is reproducible across all nodes in the network and everyone can be synced to the same state.

• Resource Allocation: This milestone may affect multiple areas of the source code. Implementing a new transaction type to handle rdPoS exceptions more efficiently could be beneficial. This transaction type could be placed within a separate container within the block, simplifying the handling of processing a new block that has activated any slashing mechanism.