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

exp/lighthorizon: Research Spike - Smart Contracts - Are txmeta archives usable by other tooling? #4459

Closed
Tracked by #4571
paulbellamy opened this issue Jul 15, 2022 · 4 comments

Comments

@paulbellamy
Copy link
Contributor

This is a, "see how feasible" it is spike task.

It would be useful if we could use the lighthorizon txmeta-style archives for github.com/stellar/stellar-contract-cli instead of re-implementing captive-core in Rust. Maybe there is an opportunity to join forces there?

@paulbellamy paulbellamy changed the title services/horizon: Get lighthorizon txmeta archives to a state where they are usable by other tooling services/horizon: Smart Contracts: Get lighthorizon txmeta archives to a state where they are usable by other tooling Jul 15, 2022
@Shaptic
Copy link
Contributor

Shaptic commented Jul 21, 2022

From an cursory glance, it seems like the main task to achieving this becomes reimplementing the ledgerbackend/HistoryArchiveBackend and its dependents in Rust in order to fetch from txmeta archives in a backend-agnostic way.

@Shaptic Shaptic mentioned this issue Jul 21, 2022
7 tasks
@Shaptic Shaptic changed the title services/horizon: Smart Contracts: Get lighthorizon txmeta archives to a state where they are usable by other tooling exp/lighthorizon: Research Spike - Smart Contracts - Are txmeta archives usable by other tooling? Jul 21, 2022
@paulbellamy
Copy link
Contributor Author

MetaArchiveBackend now, right?

@paulbellamy
Copy link
Contributor Author

paulbellamy commented Aug 29, 2022

From discussion and diagramming (Pink option 3), it seems like the answer is yes, we could. But we would have to implement MetaArchiveBackend (or whatever it is called), but more importantly current state ingestion in rust, so for now we're opting against this due to time constraints.

@Shaptic
Copy link
Contributor

Shaptic commented Aug 29, 2022

It'd be metaarchive.MetaArchive now, heh.

You would only need to write a subset of ingestion related to events, right? So mostly XDR parsing and some Pre/Post change stuff. I wouldn't expect it to be as significant as reimplementing the ingest package in Rust (which would definitely be massive).

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

No branches or pull requests

2 participants