You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I propose the development of an indexer designed to subscribe to new blocks on our testnets. The primary function of this indexer would be to extract the source code of the uploaded packages from these blocks and then commit them to a dedicated GitHub repository.
Rationale:
Having the source code on GitHub offers multiple advantages:
Allows for easier exploration and understanding of the code without directly querying the testnet.
Facilitates static analysis to ensure the code's quality and safety.
Enables the testing of our tools on a larger, more diverse codebase, thereby increasing their reliability.
Inspiration:
A point of reference for this endeavor could be tx-exports that I formerly maintained. It primarily focused on archiving blocks. While it had its limitations regarding speed and efficiency, the idea behind it remains solid. Leveraging better infrastructure and a more sophisticated transaction indexing system could greatly enhance its performance and usefulness. (@Milos and @Albert for insights on potential improvements)
I believe that this tool would be a significant asset to our development and analysis workflows. Eager to hear thoughts and potential approaches!
The text was updated successfully, but these errors were encountered:
A WIP extractor is currently waiting for reviews and @zivkovicmilos & @ajnavarro's gnotxsync and indexer efforts. Related PR #5 on the tx-exports repo.
Objective:
I propose the development of an indexer designed to subscribe to new blocks on our testnets. The primary function of this indexer would be to extract the source code of the uploaded packages from these blocks and then commit them to a dedicated GitHub repository.
Rationale:
Having the source code on GitHub offers multiple advantages:
Inspiration:
A point of reference for this endeavor could be tx-exports that I formerly maintained. It primarily focused on archiving blocks. While it had its limitations regarding speed and efficiency, the idea behind it remains solid. Leveraging better infrastructure and a more sophisticated transaction indexing system could greatly enhance its performance and usefulness. (@Milos and @Albert for insights on potential improvements)
I believe that this tool would be a significant asset to our development and analysis workflows. Eager to hear thoughts and potential approaches!
The text was updated successfully, but these errors were encountered: