WIP: SDK2

[jaekwon]

UPDATE: Look at https://github.com/cosmos/cosmos-sdk/projects/2

Everything on the SDK2 branch:

Pre-announcement

• refactor basecoin WIP: refactor basecoin example #332
• test basecoin basecoin fixes and tests #351
• fix existing code documentation write documentation for basecoin example app #335
• update ReadTheDocs update ReadTheDocs with example app documentation #336 — blocked by write documentation for basecoin example app #335
• use errors module correctly instead of hand-returning Result{} as we do in app/ and x/ basecoin-name handler example #337
• merge sdk2 into develop (may require tagging current develop into gaia2-branch) merge sdk2 into develop #338
• fix circleCI fix circleCI or switch to Jenkins #334
• ping Christine and review SDK2 announcement

Post-announcement

• InitChain logic to initialize genesis state InitChain logic to initialize genesis state #339
• BeginBlock/EndBlock logic so apps can do things without transactions BeginBlock/EndBlock handlers #346
• query for the multistore, to query into any part query for the multistore, to query into any part #340
• query with proofs for the multistore, and for the KVStore Specification for Lite Client Proofs #341
• figuring out best integration strategy with Ethermint (more difficult) Figure out best integration strategy with Ethermint #342
• implementing the ibc/gov/staking plugins in x/ibc, x/gov, x/staking respectively Move ibc module into new sdk #343 Write Governance Extension #344 Move staking module into new sdk #345
• integrate & polish /publish
• integrate light-client CLI and REST rewrite #324

[jaekwon]

querying with proofs will first require a common structure format (with interfaces) for supporting any variety of Merkle proof types, in a series (e.g. for SimpleTree (block header) -> SimpleTree (multistore) -> IAVLTree (iavl))

[rigelrozanski]

Additionally I think there is an opportunity to lump some common initialization/execution functionality together (such as found in examples/basecoin) to allow for highly compact applications. Not core for the MVP, but I think it will be important to be able to write a new "hello world" SDK-application in your own repo with ~ 10 lines of code (or something small hehe)

[ethanfrey]

Functioning CLI/REST #324 also.

I think the last line is not needed for sdk release. It can merge without ibc/staking/governance, and they can be built on top of it, as different projects.

Also for merkle proofs of trees, please look at ibc spec v0.3.1, Appendix C. There it specifies a generic binary format to represent any merkle proof and chain them together. It should be compatible with patricia tree proofs as well, but haven't proven that.

[ethanfrey]

I think at least queries without proof is essential before announcing it.

You can put data in, but you can't see it....

[ebuchman]

For now people can send "read" transactions.

It's not ideal but let's get something workeable out there and start rapidly iterating on bringing in the necessary new features

[ethanfrey]

Please explain how a "read" transaction works?

[ethanfrey]

I think query (without proofs) is super essential. Otherwise, it looks like an ugly hack.
With that and a basic cli, it seems like something actually usable.

And really, they should not be that hard. At least for an MVP implementation.

[ebuchman]

A read transaction is a consistent query (ie. a query that passes through consensus). For instance in basecoin, we'd have to define a GetAccountTx that returns the account as the result.

This is how merkleeyes was written for Jepsen. Query isn't sufficient because it can return stale reads - ie. you might be querying from a node thats behind and meanwhile the value has changed. So for proper testing, you actually need "read transactions", or what some call "consistent reads".

Obviously for basecoin that'd be ridiculous, and I'm not proposing we do it. We could and should and must do it for the key-value store app we build, ie. the new merkleeyes-jepsen-app on SDK.

Anyways, no one disagrees that queries are essential. Let's get them in ASAP. But let's not block on it - folks can start building and unit testing their apps without it.

[jbibla]

closing in favour of sprint boards and milestones 🕺