Current coverage is 50.05% (diff: 33.33%)

Merging #372 into develop will increase coverage by 0.25%

@@            develop       #372   diff @@
==========================================
  Files            37         37          
  Lines          4450       4453     +3   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits           2216       2229    +13   
+ Misses         2022       2013     -9   
+ Partials        212        211     -1   

Powered by Codecov. Last update a073b1d...00d4157

Wanted to go back to comment you made in previous PR about removing query/proof and letting apps expose it however they want. That sounds good in theory, but what about chained tmsp apps? Ie. if you want to get a proof from basecoin, but basecoin uses merkleeyes .... basecoin can expose a custom proof rpc for the user, but what should merkleeyes expose to basecoin? should basecoin not be using merkleeyes over abci ? or should it expose the query/proof stuff separately, and make basecoin connect to both endpoints (one for driving txs, one for getting info) ?

It already feels silly to use merkleeyes in basecoin. Shouldn't be just use go-merkle directly? Why bother with the extra serialization steps to pack a (get, key) or a (set, key, value) into a tx ?

It already feels silly to use merkleeyes in basecoin. Shouldn't be just use go-merkle directly? Why bother with the extra serialization steps to pack a (get, key) or a (set, key, value) into a tx ?

We can eventually but we're putting these cuffs on so we can grow our non-golang ecosystem. So the question may be, how serious are we about supporting non-golang apps?

It would make a lot more sense if we're using a container orchestration tool. Then we can focus on supporting the orchestration tool and all app programmers can benefit from it.

I agree with the point of exposing proofs for a non-go application. However, I think the approach from merkleeyes is a bit problematic for two reasons:

1. The proof returned can currently only be decoded and verified with go code. It is not too hard to port that logic, but without it, it is hard to truly say proofs (and thus the main purpose of the merkle-tree) are cross-language

2. A deeper problem is the semantics of the abci interface do not align with the semantics one expects from a database query. To truly make merkleeyes some language-agnostic, merkle-proofing, key-value store (which seems to be the goal), we need another interface than abci. Here is why:

When I make a query to tendermint core (and thus an abci app), I expect the value to correspond with some block that was committed, ideally along with the block height corresponding to that answer, so I can request a proof later. I do not expect to read intermediate values from an in-progress block. Or is this a false understanding?

When I make a query on my data store from within an app, I expect to have a choice of which version I see, last committed block, or current working state, like an uncommitted transaction in a database. I did this relatively simply in merkleeyes using Tree.Copy to maintain a few states, but nothing before the last saved/commited state. This allows abci queries to be routed to the last committed state, while the application code can read/write on the current working state.

I believe this is a more "correct" approach to querying the data. But maybe I am wrong? If so, ocrrect me and ignore the rest of this post.

If we want to keep these different views for different users, we discover that there is no clean way to do this over abci. So basically, we have to embed this logic in-process (as I did in merkleeyes), or provide a proper network interface to go-merkle that models what we want to use a data store for, not how we use abci apps.

I never did understand this concept of chaining abci apps, as if abci is some sort of universal protocol. It seems a very good interface between business logic and consensus in building a blockchain, but not the best formulation for interfacing with a database. I really suggest building out its own protocol if that is what merkleeyes should be (at which point, it is basically a re-write).

There may have been some longer discussions on these points long ago, which bring up some issues which I am totally ignorant of, and if so, please correct me here.

Committed an alternative solution w/ the more general Query interface. Closing.