valory-xyz / open-aea

A framework for open autonomous economic agent (AEA) development - no package vendor is prioritised over other package vendors
https://open-aea.docs.autonolas.tech
Apache License 2.0
65 stars 16 forks source link

feature_request: Improvements for multichain support. #754

Open 8ball030 opened 2 months ago

8ball030 commented 2 months ago

Is your feature request related to a problem? Please describe. I found the ledger_id and chain_id usage for integration with multiple chains quite cumbersome. I believe it makes more sense to route messages pointed at a say optimism to the optimism ledger, as opposed to configuring the ethereum ledger with a chain_id of optimism.

This is a not hugely intuitive and afaict it also means you cannot have 1 agent controilling 2 different evm chains without carefui crafting of messages as so;

In the below is the current interface;


        ledger_id: str = self.params.ledger_ids[0]
        response_msg = yield from self.get_contract_api_response(
            performative=ContractApiMessage.Performative.GET_RAW_TRANSACTION,  # type: ignore
            contract_address=self.synchronized_data.safe_contract_address,
            contract_id=str(GnosisSafeContract.contract_id),
            contract_callable="get_raw_safe_transaction_hash",
            to_address=vault_address,
            value=0,
            data=call_data,
            safe_tx_gas=SAFE_GAS,
            ledger_id="ethereum",
            chain_id=ledger_id,

Describe the solution you'd like Id like to instead propose a mapping of EVM chains to ethereum ledgers within the file;

https://github.com/valory-xyz/open-aea/blob/80b432192a55e6a9fa668d8f0df4340a6a944ec9/packages/valory/connections/ledger/base.py#L161

If we create a hashmap like so;

EVM_LEDGERS = {
    i: ETHEREUM_LEDGER_ID
    for i in [
        "matic",
        "gnosis",
        "bsc",
        "optimism",
        "arbitrum",
        "celo",
        "avalanche",
        "fantom",
        "base",
        "zksync",
        "canto",
    ]
}
if ledger_id in EVM_LEDGERS:
        api = self.ledger_api_registry.make(ETHEREUM_LEDGER_ID, **self.api_config(ledger_id))
    else:
        api = self.ledger_api_registry.make(
            ledger_id, **self.api_config(ledger_id)
       )

Then, the interface would be like so;


        ledger_id: str = self.params.ledger_ids[0]
        response_msg = yield from self.get_contract_api_response(
            performative=ContractApiMessage.Performative.GET_RAW_TRANSACTION,  # type: ignore
            contract_address=self.synchronized_data.safe_contract_address,
            contract_id=str(GnosisSafeContract.contract_id),
            contract_callable="get_raw_safe_transaction_hash",
            to_address=vault_address,
            value=0,
            data=call_data,
            safe_tx_gas=SAFE_GAS,
            ledger_id=ledger_id,

This would make way way more sense, and then all of the ledger configured within the ledger package would be used by default.

Additionally we wouldnt be over-riding chain_id which is commonly used else where within the industry with a different meaning.

8ball030 commented 2 months ago

Related issues;