Query by proposal status and voting status.

[0xekez]

Examples:

1. What proposals have I voted yes on?
2. What proposals have I voted on?
3. What proposals are open that I have not voted on?
4. What proposals did I vote abstain on?
5. What proposals have been passed but not executed?

pub enum QueryMsg {
  FindProposals {
    wallet: String,
    status: Option<Status>,
    walletVote: Option<Vote>,
  }
}

[Callum-A]

Will this route require pagination for gas? To ensure it doesn't time out?

[mikedotexe]

👋🏼 it's possible we'd like to take this on if it's a good first ticket

[0xekez]

@mikedotexe this one is probably a zinger. Would love some help / thoughts on it. :)

This is likely tricky because our current contract state isn't particularly well suited to do these kinds of queries with runtimes that are constant time. This is problematic because we need to take some care we don't hit gas limits (though, as these queries are answerable in other ways, it is OK if we do hit gas limits).

In state we have:

pub const PROPOSALS: Map<u64, Proposal> = Map::new("proposals");
pub const BALLOTS: Map<(u64, Addr), Ballot> = Map::new("ballots");

PROPOSALS maps from proposal IDs to proposals and BALLOTS maps from a proposal ID and an address to that addresses' vote on the proposal with that ID. Answering questions like the ones that would be asked for by this query in constant time I'm not sure would be possible with that current state layout.

To do this then we'd either need to

• reorganize our state to make them constant time (hard mode),
• or implement the queries, measure where we hit gas limits, and then figure if those are reasonable enough we can actually reliably use them in a frontend (likely less hard mode).

I suspect the second option there would work fine. You're probably more likely to hit gas limits based on the amount of text you return here than you are to hit them because you exhaust your compute gas.

[mikedotexe]

I'm feeling a little schizo as my brain bounces between, "let's do hard mode!" and then another side of me is like, "this is what indexers are for, remember Mike, that not everything needs to be stored on-chain."

But then it gets even more interesting since we're in the summer of 2022, when indexers are either brand new or might still have some rough edges. So I'm tempted to be hopeful yet cautious on relying on them too much, at least for a few months. But then if the ultimate goal is to use indexers, then perhaps hard mode isn't the best use of time.

I remember attending the online conference Ready Layer One in 2020 and watching a talk by Tezos and Chainlink about how Tezos simply fires events and stores very little on-chain, and that worked for their oracle implementation. It brings a fun mental challenge of what truly is immutable? Is it just contract state, or does our definition of immutable include "things you can derive from replaying events on the blockchain AKA indexing."

We'd like to assign this to ourselves. It's likely @deveusss that will tackle this and/or provide ideas here. :)

[Buckram123]

@ezekiiel How would you feel about adding another state struct like:

pub const PROPOSALS_BY_ADDR: Map<Addr, IndexSet<proposal_id>> = Map::new("proposals_by_addr");

It's easy to paginate and should be constant time/gas usage

[0xekez]

@Buckram123 - Is the idea here that this will map addresses to proposals that they have voted in? This is actually a really clever idea. Think it would give us (1) through (4) above.

To @mikedotexe's excellent point here - I do lean a little towards this being the job of an indexer to do these queries. You're probably right that in order to do this we'll need to add state to the contracts. In this case the state doesn't encode new information so much as it organizes existing state. More state == more gas and more code == more bugs so perhaps we should close this in favor of an indexer solution.

What do you think?

[mikedotexe]

Hey friends, we're chatting offline about putting a (cw-storage-plus) Map in a Map, and Misha thought it might be an approach he'd take here.

I seem to remember @Callum-A mentioning in one of the CosmWasm By Dummies videos that you cannot do that because of serialization, and indeed, when I heard that on the video I slumped back in both relief and agony, since I had run into a problem with serialization and now it made sense. But then came the agony because I REALLY wanna nest those suckers.

Am I reading it right that we can't based on what Callum says here?

https://github.com/Callum-A/cosmwasm-zero-to-hero/blob/3346d7f30bb7277013d4e3f8ad63398a453dd451/05%20-%20State/README.md?plain=1#L89-L94

[JakeHartnell]

What's the status on this? Do we still want it? Is it worth trying to fit into v2?

[JakeHartnell]

Stale.