Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ADR 026: Rosetta API Support #6922

Closed
wants to merge 25 commits into from
Closed

ADR 026: Rosetta API Support #6922

wants to merge 25 commits into from

Conversation

jgimeno
Copy link
Contributor

@jgimeno jgimeno commented Aug 3, 2020

Description

extends: ##6831


Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

  • Targeted PR against correct branch (see CONTRIBUTING.md)
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Code follows the module structure standards.
  • Wrote unit and integration tests
  • Updated relevant documentation (docs/) or specification (x/<module>/spec/)
  • Added relevant godoc comments.
  • Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
  • Re-reviewed Files changed in the Github PR explorer
  • Review Codecov Report in the comment section below once CI passes

@codecov
Copy link

codecov bot commented Aug 3, 2020

Codecov Report

Merging #6922 into master will increase coverage by 6.96%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #6922      +/-   ##
==========================================
+ Coverage   54.61%   61.57%   +6.96%     
==========================================
  Files         547      518      -29     
  Lines       37107    31996    -5111     
==========================================
- Hits        20266    19703     -563     
+ Misses      15185    10716    -4469     
+ Partials     1656     1577      -79     

@alessio alessio changed the title Adr 026 Roseetta. Adr 026 Rosetta. Aug 3, 2020
@jgimeno jgimeno marked this pull request as ready for review August 5, 2020 08:05
@alessio alessio changed the title Adr 026 Rosetta. ADR 026: Rosetta API Support Aug 6, 2020
}
```

And we will provide different implementations of this `adapter` like for 0.38, for 0.39
Copy link
Contributor

@alessio alessio Aug 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
And we will provide different implementations of this `adapter` like for 0.38, for 0.39
We will provide implementations of the `Adapter` interface for each of the Cosmos SDK supported release series. Each implementation needs to support historical data queries.

Copy link
Contributor Author

@jgimeno jgimeno Aug 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case we can just create an Adapter of adapter that query different adapters and return the merged response.

Query -> AdapterOfAdapters --> Adapter1 (cosmos-sdk 0.37) (Hub1)
-------------------------------> Adapter2 (cosmos-sdk 0.38) (Hub2)
-------------------------------> Adapter3 (cosmos-sdk 0.38) (Hub3)

The implementation maybe we need to offer for that is one for every SDK and a wrapper adapter of adapters to build complex use cases.

```

And we will provide different implementations of this `adapter` like for 0.38, for 0.39
and even a `CosmosHub` implementation that will call different versions of the hub.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
and even a `CosmosHub` implementation that will call different versions of the hub.


## Decision

We intend to develop a library that could be extended and used by application
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit lost. if its a seperate repo why is there an ADR in the sdk repo?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I'm a bit lost here as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea was first to be part of the same sdk repo, but @zmanian pointed out that there is one use case where we need to be able to query multiple versions of the hub at the same time, so living in its own repo is more "easy" to maintain than to have the same code in multiple versions of the SDK.

But in the end is very related to the SDK so I opened the ADR here. But if you think is not correct to keep it here we can change it.

Copy link
Member

@tac0turtle tac0turtle Aug 7, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This ADR should be in the repo for where the code lives, IMO. What do others think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that is correct, meanwhile because the repo is not created yet (no permissions) we can use this as the draft discussion. Even I am not sure if finally everyone agrees on using another repo, this will be clarified in the cosmos-sdk call today I hope! Thanks @marbar3778


- Support multiple versions of Cosmos SDK.
- Support Cosmos Hub.
- Implement querying of historical data sets.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Historical datasets of what? Previous hub versions? We can probably condense the last two points into one -- support current and previous versions of the Cosmos Hub.


## Context

We think it'd be greatly valuable to application developers to have the Cosmos SDK
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would probably add a bit more to the "why?". Rosetta does a pretty good job at this and so you may be able to just take some snippets directly from their page. But essentially anything along the lines of API interop and striving towards a common API standard should suffice.


We intend to develop a library that could be extended and used by application
developers to integrate an in-process Rosetta API-compliant server with the
application main binaries. We also intend to provide a standalone gateway server
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are application main binaries?

We intend to develop a library that could be extended and used by application
developers to integrate an in-process Rosetta API-compliant server with the
application main binaries. We also intend to provide a standalone gateway server
program that supports a Cosmos SDK's minimum feature set. Such program could
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the point in a gateway and the main server? You should describe those, specifically the "why".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also note from the Common Mistakes:

Any implementation of the Rosetta APIs must connect exclusively to a running blockchain node in the
same Dockerfile. It is not ok to connect to some external service that preprocesses blockchain data or
to a blockchain node running elsewhere.

It's not clear if this means in-process or just the same host, but you should note this. Also, I don't understand what the gateway is, so unless there is a strong reason for it, we should remove this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pointing this out.

I understand both ways are compatible as long as they live in the same Dockerfile (localhost or in-process), but if we had the Rosetta as external process in one Dockerfile and the node in another Dockerfile would not be possible.


## Decision

We intend to develop a library that could be extended and used by application
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I'm a bit lost here as well.

program that supports a Cosmos SDK's minimum feature set. Such program could
run alongside the client applications main binaries.

### Implementation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no mention of how to handle "offline" mode a la multiple modes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a lot is missing from this section, particularly:

  1. Mode specification.
  2. How it's bootstrapped and started with a blockchain node (it should be via a sub-command of the app binary).
  3. Types should be defined before their use (e.g. Options and Router)
  4. What are Options and how are they used?
  5. How are multiple networks supported from the same process/server?

@alexanderbez
Copy link
Contributor

@jgimeno what is your plan with this ADR? Are you still planning on tackling this? Take a look at https://community.rosetta-api.org/t/multiple-networks/167/2. It looks like we should first tackle supporting a single network with future support for running a gateway that can serve historical queries.

@alessio
Copy link
Contributor

alessio commented Aug 19, 2020

@alexanderbez hey there! As announced in Discord, work has started and is currently ongoing here: https://github.com/tendermint/cosmos-rosetta-gateway.

It looks like we should first tackle supporting a single network with future support for running a gateway that can serve historical queries.

I agree and I believe this is the approach @jgimeno and @ilgooz have taken so far.

Note: the repository is just a temporary location, we'll reach out ICF and arrange the transfer into the cosmos Github organization as soon as we have a POC ready.

In conclusion, considering that this work in being carried out in an external repo this PR should just be closed.

Wdyt?

@alexanderbez
Copy link
Contributor

Why is work being started before the ADR has been properly vetted and reviewed!? There are many holes and missing pieces in this ADR.

@alessio
Copy link
Contributor

alessio commented Aug 19, 2020

We've heard no strong objections to get this started in a separate repo, and we also thought that both ADR and the work on a POC should actually be done in parallel, i.e. pretotyping an implementation as quickly as possible would give us the possibility to write even better specs. Furthermore, developing the library in a separate repo gives us the possibility to support multiple SDK releases without messing around with go modules versioning.

Rest assured everything will be up for review (it actually is already!) and transferring the repo to an ICF-owned organization is on our roadmap (we could even do it now, if that helps)

Does this address your concerns? I am happy to keep this PR open

@tac0turtle
Copy link
Member

I think we can close this PR. The rosetta wrapper/proxy is not part of the sdk but a tool, tools don't have ADR's in the sdk.

@alessio
Copy link
Contributor

alessio commented Aug 19, 2020

I'm OK with that @marbar3778. @alexanderbez wdyt?

@alexanderbez
Copy link
Contributor

alexanderbez commented Aug 19, 2020

OK, if AiB wants to take lead on this outside the scope of the SDK then by all means proceed, just know based on this ADR as-is, I'm highly skeptical of the approach design and overall approach. Good luck!

@alexanderbez alexanderbez deleted the jonathan/adr-rosetta branch August 19, 2020 18:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants