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

refactor(core/exchange): suggestion: Rework core-exchange Get() Method #3367

Open
walldiss opened this issue May 6, 2024 · 4 comments
Open
Labels
enhancement New feature or request

Comments

@walldiss
Copy link
Member

walldiss commented May 6, 2024

Implementation ideas

I've reviewed the usage of the Get() method in core-exchange and identified that its primary usage is for subjective initialization. It's employed when launching a bridge node with a specified trusted hash, from which it begins syncing headers.

The current implementation of Get() appears overly complex, relying on multiple Core RPC methods to fetch blocks and construct EDS and headers. Additionally, one of the RPC methods used isn't available in the CometBFT gRPC service, necessitating proxying if we migrate to gRPC.

Instead of utilizing CometBFT RPC to obtain EDS and headers, we could request this data from the network using the hash. This would simplify the logic within core-exchange, reduce dependence on CometBFT endpoints, and eliminate the need to introduce new proxy methods in celestia-app.

@walldiss walldiss added the enhancement New feature or request label May 6, 2024
@Wondertan
Copy link
Member

Requesting from DA network maybe an issue for new networks we start up, like robustas. This becomes chicken and egg problem

@walldiss
Copy link
Member Author

walldiss commented May 6, 2024

Thanks for pointing that out! You're right that the first Bridge node will need to request from a consensus node. Maybe we can add a trusted_height configuration, so we can identify the starting block with both a height and a hash. This could simplify things while keeping the CometBFT interaction efficient.

@Wondertan
Copy link
Member

Why not to add Get operation to their RPC instead?

@walldiss
Copy link
Member Author

walldiss commented May 6, 2024

I see this as a configuration issue. We can determine if trusted_hash is the genesis block by comparing it with a hardcoded constant. If it matches, we can request block 1 directly. Otherwise, we can request the data from the network. This solution simplifies the start of new networks while also eliminating the need for additional APIs or proxy methods.

Adding the Get operation to the RPC is certainly an option, and it could address the issue directly. However, introducing this new operation might increase complexity on the celestia-app side and still require additional proxying, which is unnecessary and can be handled within node logic with a single if statement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants