-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Conversation
Codecov Report
@@ 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 |
Co-authored-by: Alessio Treglia <[email protected]>
Co-authored-by: Alessio Treglia <[email protected]>
Co-authored-by: Alessio Treglia <[email protected]>
Co-authored-by: Alessio Treglia <[email protected]>
Co-authored-by: Alessio Treglia <[email protected]>
Co-authored-by: Alessio Treglia <[email protected]>
Co-authored-by: Alessio Treglia <[email protected]>
Co-authored-by: Alessio Treglia <[email protected]>
} | ||
``` | ||
|
||
And we will provide different implementations of this `adapter` like for 0.38, for 0.39 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and even a `CosmosHub` implementation that will call different versions of the hub. |
Co-authored-by: Alessio Treglia <[email protected]>
Co-authored-by: Alessio Treglia <[email protected]>
Co-authored-by: Alessio Treglia <[email protected]>
Co-authored-by: Alessio Treglia <[email protected]>
|
||
## Decision | ||
|
||
We intend to develop a library that could be extended and used by application |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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".
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
- Mode specification.
- How it's bootstrapped and started with a blockchain node (it should be via a sub-command of the app binary).
- Types should be defined before their use (e.g.
Options
andRouter
) - What are
Options
and how are they used? - How are multiple networks supported from the same process/server?
@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. |
@alexanderbez hey there! As announced in Discord, work has started and is currently ongoing here: https://github.com/tendermint/cosmos-rosetta-gateway.
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 In conclusion, considering that this work in being carried out in an external repo this PR should just be closed. Wdyt? |
Why is work being started before the ADR has been properly vetted and reviewed!? There are many holes and missing pieces in this ADR. |
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 |
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. |
I'm OK with that @marbar3778. @alexanderbez wdyt? |
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! |
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.
docs/
) or specification (x/<module>/spec/
)godoc
comments.Unreleased
section inCHANGELOG.md
Files changed
in the Github PR explorerCodecov Report
in the comment section below once CI passes