Identify potential improvement ideas for smart contracts

[nikipapadatou]

Based on the documented list of Document current and planned smart contracts, provide potential ideas for improvement or redesign — along with a short rationale for each.

For each improvement idea we need:

• Description of the improvement.
• Outline the expected benefits (e.g., performance, maintainability, decentralization, security, etc.).
• Rough time estimation. (S/M/L)
• High-level risks/trade-offs (e.g., gas costs, complexity, upgrade risk). - if applicable
• Priority score.

This work is exploratory; no implementation is expected.

The deliverable should be a project canvas summarizing the above information, linked to this issue.

[0xCardiE]

There are no potential improvements discussed for current smart contracts. We did a lot some year and half ago. I was optimizing code structure and gas usage and the whole deployment process. Also checked some security in process there. So this was considered done at that point. What we could do is work more on security checks and talk about possible outside audit from audit companies.

[janos]

I would like to add a short feedback from the contracts usage/integration, particularly in the bee node implementation.

Given that there are a few contracts that are used in the node client, we keep their addresses in the configuration. For mainnet and testnet in the abi repositories. Synchronising updates is now explicit and require releasing new bee versions to update contracts. Sometimes that may not be needed. By using the proxy contract that will keep track of all swarm contracts addresses, smart contract could gain more flexibility related to their coupling with the node implementation and also the referencing of smart contracts by using only one proxy smart contract address would be more reliable from the node point of view.

I have a feeling that proxy smart contract could improve contracts usage and updating.

[mfw78]

I would like to add a short feedback from the contracts usage/integration, particularly in the bee node implementation.

Given that there are a few contracts that are used in the node client, we keep their addresses in the configuration. For mainnet and testnet in the abi repositories. Synchronising updates is now explicit and require releasing new bee versions to update contracts. Sometimes that may not be needed. By using the proxy contract that will keep track of all swarm contracts addresses, smart contract could gain more flexibility related to their coupling with the node implementation and also the referencing of smart contracts by using only one proxy smart contract address would be more reliable from the node point of view.

I have a feeling that proxy smart contract could improve contracts usage and updating.

This works to a degree, but when there's substantial change to storage kept in the contracts, this becomes very much non-trivial with many foot-guns. It would essentially yield greatest benefits if there are logic-only changes, with no underlying storage changes. If new functionality / storage were added this would likely then necessitate some form of migration itself to clean-up the storage on-chain.

I would actually suggest to follow a registry pattern instead. This would work something like:

1. Contracts are deployed.
2. A 'registry' contract is deployed.
3. Contracts deployed in (1) are stored against some mapping in (2).

For example, Registry.set("POSTAGE_STAMP") = 0xbadcodebadcode.... Now subsequently within bee code when there is startup, the addresses can be retrieved by consulting the Registry.

This leaves one with ensuring that only the ABI remains relatively stable, and would allow for non-breaking migration paths to be carried out.

[mfw78]

An example of where this pattern has been used extensively: https://github.com/sky-ecosystem/dss-chain-log

[janos]

I would actually suggest to follow a registry pattern instead. This would work something like:

1. Contracts are deployed.
2. A 'registry' contract is deployed.
3. Contracts deployed in (1) are stored against some mapping in (2).

For example, Registry.set("POSTAGE_STAMP") = 0xbadcodebadcode.... Now subsequently within bee code when there is startup, the addresses can be retrieved by consulting the Registry.

This leaves one with ensuring that only the ABI remains relatively stable, and would allow for non-breaking migration paths to be carried out.

Yes, I agree. The registry pattern gives all benefits of easier referencing, but keeping the abi strict. Thank you @mfw78.

[0xCardiE]

I was proposing using proxy patterns some 2 years ago, there were heavy discussions about this, made some proofs of concepts but it was decided that we want to stick with current pattern and not change it. So this probably wont be changing.

Reasons against proxy would mostly apply also for registry patterns which were basically that we dont want to have control on what code is used in nodes, meaning if we can change logic in proxies or change values in registry without user consent for their nodes this is something that we dont want to do or have option to.

[janos]

That argument is strong. At least, now, the user can validate all the changes before the node upgrade. The assumption if users are actually doing that is not relevant if silent mutability of contracts if forbidden as a principle. What if the registry contract is only providing information about other contracts that are set on contract deployment and could not be changed. So that mutability is not possible, but there is only one address to reference a set of contracts to be more reliable as a coherent suit of contracts (not to mistakenly mix contracts that are not "compatible")?

[mfw78]

Just pass along the version as well that bee is running with Register.get('COMPONENT', '2.6.0'). In which case, upgrading the node is an implicit agreement to the new contracts (if applicable). This still provides substantial benefits by not having to bump in multiple places and provides reasonable logical separation and division along 'areas of responsibility' for node developers and smart contracts.