Closed wertikalk closed 9 months ago
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:
serialization/deserialization (i.e. result.deserializeMinerRawPowerReturn()
) methods could potentially be impacted
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.
Description