valory-xyz/autonolas-v1

Autonolas on-chain protocol

autonolas-v1's Issues

Known issues/optimisations

• address remaining coverage gaps
• we loop and request the same data twice in one function: here and here; probably more can be optimised across these two loops.
• this wondering whether the address lookup can be optimised by storing the list of addresses permanently so we don't need to look up each time.
• if this map was to serviceId instead of serviceOwner we'd probably save a lot of lookups in the loops as we'd only need to lookup unknown addresses; further casual inspection suggests we don't need the owner at all and can get away with only the service id
• remove ERC721Enumerable (see an argument here) - we don't need it anywhere: 1 can use IERC721 instead; 2 can be achieved via simple counter if we remove burn functionality (which we don't need, as here we can simply set the service state to burned, which also makes tokenomics better as for whatever reasons late arriving donations won't cause any issues); 3 same argument if we remove burn - just the identity; 4 same as 1; 5 same as 2
• this and this and this and this and this is not used
• with the removal of burn in ERC721, existence checks can be done more easily by checking once that highest index is below total supply here and here
• Flatten and gas optimise ERC20 by implementing it similarly to the Uniswap contract with a peak at Solmate (https://github.com/Rari-Capital/solmate/blob/main/src/tokens/ERC20.sol) - although we cannot directly reference solmate and should avoid too much similarity due to the licensing issue - (take this data as reference: https://github.com/alephao/solidity-benchmarks)
• Restrict agents to have at least one component for symmetry with services having at least one agent.
• Convert all ipfs hashes for v1 support only
• this and this and this and this and this can be made external
• this should be made internal
• The Pausable implementation here does not make sense. We cannot recover the funds anyway once they are in the disperser. So I suggest we remove Pausable here. The transfer from Treasury to Dispenser is governance controlled anyway atm.
• optimise storage layout, especially here
• IStructs creates dependencies between the entire architecture. I think it would be desirable to limit the dependencies to the minimum of the shared data structures, suggesting it is broken up. Affecting e.g. this creates
• We should use a more generic interface here which the Treasury then implements. We only use one method of the treasury interface here and if we don't change it we are forced to implement all treasuries with this interface.
• We have to be careful with this. When we deploy the Treasury will not be live yet. So for some time this functionality is broken. Will it revert if the zero address is initially set here?

Update ci to tag by branch name

Need to identify the correct contextual flag to use for the tag for the docker, build + push stage

Address state machine design for services

#29