EmerisHQ / demeris-backend

Monorepo containing all the Demeris backend code and infrastructure definitions.
GNU Affero General Public License v3.0
8 stars 1 forks source link

Add "bulk" version of balances endpoints in api-server #777

Open Pitasi opened 2 years ago

Pitasi commented 2 years ago

Frontend is currently polling these endpoints:

but it does for many different addrs, since different chains have different derivation paths.

Let's expose some new endpoints that takes a list of addresses as a param so frontend can make a single requests and gather all data it needs!

DoD

tbruyelle commented 2 years ago

How does the front get those different addresses ? From Keplr ?

isn't it possible to find them in the backend side, from a master address ?

tbruyelle commented 2 years ago

Apparently the chain addresses are derivated from the public key

https://github.com/confio/cosmos-hd-key-derivation-spec#reuse-of-the-cosmos-hub-path-in-cosmos

So that means we could have a single endpoint that takes the public key and returns all the balances for all the derivated accounts. That would be nice I think.

Pitasi commented 2 years ago

That's a nice article, thanks, helped me shed some light on the derivation :D

The most interesting thing is the "hardened" derivation (in m / 44' / 118' / 0' / 0 / address_index you see 44 and 118 are marked with a '). See here https://wiki.trezor.io/Hardened_and_non-hardened_derivation.

Not sure if I'm reading this wrong but it seems that even if we do have the master public key (or any derived public key) we cannot derive children that are hardened:

With non-hardened keys [...] You can also derive public child keys from a public parent key

With hardened child keys, you cannot prove that a child public key is linked to a parent public key.

Even if it was possible, another important sentence:

This means that extended public keys must be treated more carefully than regular public keys.

I have a feeling that users might perceive this as lowering their privacy. If users only give us addresses there's not much we can do. If users give us entire public keys, they are sharing more informations than they did before.

tbruyelle commented 2 years ago

I think you are right about hardened vs non-hardened, but here we don't want to create children public keys, we just want to derive a chain address from the public key, and I think it's not the same thing.

About user's security concern, afaik it's transparent for them: Keplr already gives access to the user's public key, here is the proof where I run this snippet in app.emeris.com console :

image

You can see the public key in the output, and it's the same whatever the chain passed to getKey.

So instead of passing the chain address, the front could give us the public key, and we do all the derivations according to the chains we support.

tbruyelle commented 2 years ago

@Pitasi I did some tests today, and I can assert that it's possible to generate bech32 addresses from key.address, which is apparently the raw address derivated from key.pubKey

(key is the JS object returned by await keplr.getKey('cosmoshub'))

This test passes:

    pb := []byte{
                // a key.address
        177, 243, 71, 181, 77, 57, 172, 212, 184, 184, 174, 87, 29, 214, 159, 253, 244, 92, 248, 194,
    }
    adr, err := bech32.ConvertAndEncode("cosmos", pb)
    require.NoError(t, err)
        // the related cosmos adr in keplr
    assert.Equal(t, "cosmos1k8e50d2d8xkdfw9c4et3m45llh69e7xzw6uzga", adr)

    adr, err = bech32.ConvertAndEncode("osmo", pb)
    require.NoError(t, err)
        // the related omosis adr in keplr
    assert.Equal(t, "osmo1k8e50d2d8xkdfw9c4et3m45llh69e7xzxp0j70", adr)

pub key derivation to generate the raw address : https://github.com/cosmos/cosmjs/blob/main/packages/amino/src/addresses.ts