Add /r/children/:inscription_id/inscriptions endpoint

[gmart7t2]

It also adds delegate to the inscription details.

[elocremarc]

Nice! Saves some time. Should we not just add a new field in the current children endpoint responses? Is this a different endpoint because of the latency? @casey Did we decide we did not want to add fields to recursive endpoint updates?

pub struct Children {
  pub ids: Vec<InscriptionId>,
+ pub inscriptions: Vec<InscriptionRecursive>,
  pub more: bool,
  pub page: usize,
}

It also adds delegate to the inscription details.

If we are not adding fields then should we update this? It would update the current /r/inscription endpoint right?

[casey]

We need to figure out a way to evaluate the performance impact of PRs like this. Probably the way to do it is to simulate a production workload with tons of requests, and see how it holds up. The worst-case scenario would be we add an endpoint like this, it gets widely used, and we can't ultimately support it, because it overwhelms the ordinals.com servers.

[DrJingLee]

We need to figure out a way to evaluate the performance impact of PRs like this. Probably the way to do it is to simulate a production workload with tons of requests, and see how it holds up. The worst-case scenario would be we add an endpoint like this, it gets widely used, and we can't ultimately support it, because it overwhelms the ordinals.com servers.

Then we buy more powerful servers haha

[owenstrevor]

We need to figure out a way to evaluate the performance impact of PRs like this. Probably the way to do it is to simulate a production workload with tons of requests, and see how it holds up. The worst-case scenario would be we add an endpoint like this, it gets widely used, and we can't ultimately support it, because it overwhelms the ordinals.com servers.

Do we test the performance of this endpoint compared to the normal /r/children request and see the difference on a simulated production env?

Or do you mean testing it in isolation with 10,000+ requests?

[gmart7t2]

The worst-case scenario would be we add an endpoint like this, it gets widely used, and we can't ultimately support it, because it overwhelms the ordinals.com servers.

Couldn't you simply reduce the page size until the servers can cope? Don't commit to the page size staying at 100 so inscriptions don't start depending on any specific page size.

[owenstrevor]

ROUGH PERFORMANCE TESTING

Starting with context

More context here on how it works from @gmart7t2. There's some interesting implications to draw from it about how ord works for those who aren't familiar.

For our purposes, honestly all we really need is part B to get the blockheight. It would be super nice to get the delegate ID, but it appears to be the same burden as getting the content (assuming you put some kind of limit on the size of the content that would be returned). If we mine for IDs via an inscription service, then we don't need anything from A (albeit that's not a great UX, it's definitely workable).

I'm not sure what others will want. But the crux is the blockheight and the content/delegate can be simulated by mining IDs.

An interesting bit of info for those who aren't familiar with ord, is that we are starting with the existing list of inscriptions here. We can't override the function that gets all the child inscriptions to include the delegate ID or blockheight because that would require to change how ord is indexed. Ultimately, without re-indexing, it seems the most performant thing we can do to get what we need is just simplify the PR to only include call B.

TEST RESULTS

@casey Below is a performance benchmark for each part (A, B, C, D) in microsecond μs on 2 children.

And here is the result testing on the first 100 children from the Pizza Ninjas collection.

A: 85.4%
D: 14%
B and C 0.5% together
A is fetching the whole tx from bitcoind. Then D is fetching it again (only it's faster the 2nd time because of disk caching)
So if we remove A, D will become as slow as A

IMPLICATIONS

It appears that B and C are very performant. @casey what would you think about removing A & D for now and redoing the PR just for B and C since we can mine the inscription IDs as we previously discussed?

[gmart7t2]

I was wrong that "D" would be heaviest because it's fetching the raw tx, because "A" also fetches the raw tx, and so the 2nd (redundant?) fetch is quick due to caching.

And the timings for the Pizza Ninja children are for the first page of 100, not for the whole set

[gmart7t2]

Should we not just add a new field in the current children endpoint responses?

No. The current endpoint is fast, only using the ord database. This new endpoint runs getrawtransaction twice per child.

Did we decide we did not want to add fields to recursive endpoint updates?

No. We decided the opposite. See https://docs.ordinals.com/inscriptions/recursion.html :

"additional object fields may be added or reordered, so inscriptions must handle additional, unexpected fields"

[raphjaph]

Closing this in favor of #3771