Refactor ethers-contract

[gakonst]

Is your feature request related to a problem? Please describe.
Ethers-contract currently requires that it's connected to a Middleware in order to be able to broadcast the transactions.

It'd be nicer if we were able to have a base contract struct which simply takes the ABI and produces ABI encoded data for its functions (and for filters if given a vec of addresses as the filter's address). You'd then wrap that with an address and a middleware, and you'd get the equivalent functionality of the current Contract.

It'd also be nice if we supported human readable ABIs. We could do the tokenization by looking at a function's parentheses

[pawanjay176]

Hi @gakonst, I'd like to take this up to familiarise myself with the codebase a bit :)

So from what I understand, the task is mainly to split the existing Contract struct to

pub struct BaseContract {
    abi: Abi,
    methods: HashMap<Selector, (String, usize)>,
}

pub struct Contract<M> {
    base_contract: BaseContract,
    client: Arc<M>,
    address: Address,
}

impl BaseContract {
    ....
    
    /// Should be upgradeable to a "full" `Contract` struct.
    pub fn into_full_contract<M>(self, address: Address, client: impl Into<Arc<M>>) -> Contract<M> {
        Contract {
            base_contract: self,
            address,
            client: client.into(),
        }
    }
}

Is this roughly what you have in mind?

It'd also be nice if we supported human readable ABIs.

could you expand on "human readable" a bit?

[gakonst]

Hey! Yes, exactly what I had in mind. Human readable ABIs, are the ones from Ethers-js https://blog.ricmoo.com/human-readable-contract-abis-in-ethers-js-141902f4d917

[gakonst]

hey @pawanjay176! were you able to take a stab at the issue? If there was anything confusing, could I help you in some way?

[pawanjay176]

@gakonst sorry, got busy over the weekend. Have started working on it. Will make some commits in a day or two :)