[v10] Adds block backwards compatibility for fetching metagraph.

[thewhaleking]

Resolves the metagraph portion of #3138

Demonstrated with:

import asyncio
from bittensor.core.async_subtensor import AsyncSubtensor
from bittensor.core.subtensor import Subtensor
from bittensor.core.settings import ARCHIVE_ENTRYPOINT

async def main():
    async with AsyncSubtensor(ARCHIVE_ENTRYPOINT) as subtensor:
        print(await subtensor.metagraph(netuid=0, block=6500000))
        print(await subtensor.metagraph(netuid=0, block=5500000))
        print(await subtensor.metagraph(netuid=0))


def main_sync():
    with Subtensor(ARCHIVE_ENTRYPOINT) as subtensor:
        print(subtensor.metagraph(netuid=0, block=6500000))
        print(subtensor.metagraph(netuid=0, block=5500000))
        print(subtensor.metagraph(netuid=0))

if __name__ == '__main__':
    asyncio.run(main())
    main_sync()

What this does not cover:

Legacy (think 2023) Runtime API methods were defined through dicts. This is still an issue that needs resolved upstream in async-substrate-interface. However, once that is resolved, no additional work will need done here, but until then the legacy runtime call will not work.

[basfroman]

Good work on adding backwards compatibility for metagraph!

Current approach:
If we're only targeting get_metagraph_info, the current solution is fine. However, if we plan to apply this pattern to other methods, we should consider a more scalable approach.

I consider these options:

1. RuntimeAPIVersionAdapter (or something like this) in SDK (short-term)

• create a centralized adapter with method mapping and fallback logic.
• avoids duplicating logic in each method.
• can be implemented quickly without changing dependencies.

2. Move logic to ASI (preferred long-term)

• SDK (or any other clients) shouldn't need to worry about which method to use.
• the low-level library should handle version detection and return the right data for a given block.
• better separation of concerns: SDK focuses on business logic, version handling belongs in the substrate layer.
• reusable for other clients.

[thewhaleking]

2. Move logic to ASI (preferred long-term)

• SDK (or any other clients) shouldn't need to worry about which method to use.
• the low-level library should handle version detection and return the right data for a given block.
• better separation of concerns: SDK focuses on business logic, version handling belongs in the substrate layer.
• reusable for other clients.

The logic cannot live in ASI. ASI is a general-purpose Substrate library, and thus does have any concept of which methods retrieve which data.

[thewhaleking]

The failing tests are failing upstream. Seems a new devnet-ready release broke them.

[basfroman]

Looks great! Please resolve the conflicts and let's merge it.

[basfroman]

The failing tests are failing upstream. Seems a new devnet-ready release broke them.

Yes, tomorrow in the next PR these tests will be fixed.