Reduce high number of custom nested structs

[wertikalk]

Description

• Flatten the struct’s member’s (reducing bytecode and improve code readability) where it makes sense
  • This will need to be carefully performed, having in mind the scope of changes as tests would need to be modified as well

[wertikalk]

We are discussing ways to approach this.

This is the current state (example taken from MinerAPI.sol):

function minerRawPower(uint64 minerID) internal view returns (int256, PowerTypes.MinerRawPowerReturn memory) {
    bytes memory raw_request = minerID.serialize();

    (int256 exit_code, bytes memory result) = Actor.callByIDReadOnly(PowerTypes.ActorID, PowerTypes.MinerRawPowerMethodNum, Misc.CBOR_CODEC, raw_request);

    if (exit_code == 0) {
        return (0, result.deserializeMinerRawPowerReturn());
    }

    PowerTypes.MinerRawPowerReturn memory empty_res;
    return (exit_code, empty_res);
}

where:

struct MinerRawPowerReturn {
    CommonTypes.BigInt raw_byte_power;
    bool meets_consensus_minimum;
}

The two main issues of replacing custom structs (in the example PowerTypes.MinerRawPowerReturn) with flatten parameters are that:

• replacement will cause a ripple effect throughout the library, changing API methods, needing integration test modifications, ...

• serialization/deserialization (i.e. result.deserializeMinerRawPowerReturn()) methods could potentially be impacted

  • this would be needed in order to lower method's execution costs

    
    function minerRawPower(uint64 minerID) internal view returns (int256, CommonTypes.BigInt memory, bool) {
    bytes memory raw_request = minerID.serialize();

  (int256 exit_code, bytes memory result) = Actor.callByIDReadOnly(PowerTypes.ActorID, PowerTypes.MinerRawPowerMethodNum, Misc.CBOR_CODEC, raw_request);

  if (exit_code == 0) { (CommonTypes.BigInt memory raw_byte_power, bool meets_consensus_minimum) = result.deserializeMinerRawPowerReturn( return (0, raw_byte_power, meets_consensus_minimum); }

  ... }

  
  - the alternative would be for API methods to have flat parameters/return values and have the existing custom structs be created and decomposed inside them internally. This would preserve (de)serialization methods but would increase gas costs, and maintenance difficulty.

Soon we will post proposed structs that should be replaced according to their priority.