search

unionlabs / union

The trust-minimized, zero-knowledge bridging protocol, designed for censorship resistance, extremely high security, and usage in decentralized finance.
https://union.build
Apache License 2.0
377 stars 30 forks source link

Restructure light clients #3245

Open aeryz opened 1 week ago

aeryz commented 1 week ago

Thanks to the state lenses, we will have multiple implementations of the our light clients on different ecosystems. Before this, it made sense to have the light-clients directory. But now, it will be a mess very soon.

My suggestion is to split up everything based on its execution layer (evm, cosmwasm, move) such as:

evm/
    ibc/
    cometbls-light-client/

move/
    aptos/
        ibc/
    other-move/
        ibc/

cosmwasm/
    union-ibc/
        core/
        light-clients/
            ethereum/
            scroll/
            cometbls/
        lib/
            union-ibc-light-client/
        app/
            some-union-ibc-specific-app/
    ics08/
        light-clients/
            cometbls/
        lib/
            ics08-light-client
    some-common-contract/
cor commented 1 week ago

Would move contain both aptos move and sui move? or are they so distinct that they deserve two top-level directories?

benluelo commented 1 week ago

considering that they would be two separate ibc stack implementations, they would most likely be two directories

aeryz commented 1 week ago

Would move contain both aptos move and sui move? or are they so distinct that they deserve two top-level directories?

Unfortunately yes. Aptos supports dynamic dispatch, but sui not. And their token and storage logic is considerably different. So yeah, SUI won't be a slightly different aptos.