Key-based interfaces problem.

[zie1ony]

Based on the meeting recording I asked AI to summarized the problem identified by @davidatwhiletrue.

AI Prompt:

Describe the problem raised at the end by David and Maciej about the problem of interfaces that are based on Key.

AI Response:

Key-based interface problem

At the end of the meeting, David and Maciej raised concerns about the potential fragmentation and compatibility issues arising from the change in key types used in smart contracts. Here are the key points of their discussion:

Problem Description

1. Key Type Change:

• The new version of the smart contracts (CEP18) uses an "entity address key" instead of the traditional "account hash" or "contract hash" keys.

• This change means that the method signatures for interacting with these contracts will differ between the old and new versions.

2. Fragmentation:

• In the network, there will be contracts that use the old key types (account hash, contract hash) and new contracts that use the entity address key.

• This creates a situation where different contracts, even if they follow the same standard (e.g., CEP18), will require different types of keys for the same operations (e.g., transferring tokens).

3. User and Wallet Confusion:

• Users and wallet applications will need to handle both types of keys, which can be confusing and error-prone.

• For example, a wallet will need to know whether a contract has been migrated to the new version to prepare the correct type of transaction.

4. Compatibility Issues:

• Contracts that are not upgradable and remain on the old key system will not be able to interact seamlessly with new contracts that use the entity address key.

• This could lead to situations where certain functionalities or integrations break, requiring significant changes to maintain compatibility.

5. Operational Complexity:

• Maintaining two different key systems increases the complexity for developers and administrators.
• For instance, a marketplace contract that interacts with multiple token contracts will need to handle both key types, adding to the development and maintenance burden.

Specific Concerns Raised

David Hernando:

• Highlighted the issue of having to specify different key types (account hash vs. entity address) for different contracts in the same network.
• Pointed out that this could be confusing for users and difficult for wallets to manage.

Maciej Zieliński:

• Emphasized that the best strategy might be to continue using the old key types (account hash, contract hash) to maintain compatibility across the ecosystem.
• Raised the concern that new contracts using entity address keys might not be able to interact with old contracts that have not been migrated, leading to potential abandonment of those old contracts.

[zie1ony]

I identified also other problems with entity hashes design a few months ago, but without any response. casper-network/casper-node#4511