The common API about blobs HOT 7 CLOSED

Almost.

around a spawned child process

I think spawning a child process is a unnecessary complication. I was envisioning that the shim process would be launched by a docker-compose or another similar program.

which implements APIs for every adapter

Yes, althought I am not sure if those should be enabled/exposed by default. Maybe for e.g. opstack you may need to pass an --expose-opstack, but not sure yet.

JSON-RPC

I was hoping to avoid JSON-RPC if possible. That's tangential anyway.

Internally these APIs would be implemented with something like the common-denominator API, which is itself not exposed.

Yeah, kinda, but not necessarily. It should be just reasonably designed.

from blobs.

we just implement the current API in the form of RPC and that's it.

I really like this approach
There are only a couple of rollups stack so implement each da-interface as an rpc should not be really difficult (maybe going deeper we will discover the opposite, but for now seems a good approach)

The ad-hoc API has a downside, that probably the adapters will have to be in-tree.

Why keeping them in tree is needed?

(referring to the common denominator API) this API may inform under the hood abstractions for the ad-hoc API approach.

we could also proceed with both, on the sugondat-chain the more complex thing is to setup the RPCs that are able to able to use some runtime-apis so maybe created the base layer having both: common divisor and ah-hoc api should not be that complex

I will present my current vision of the common denominator API

Asking to the da for ALL blobs of a namespace inside a specific block, is split in a number of rpc calls equals to 1+n where n is the number of blobs submitted in the block, why not something like get_blobs(height, Namespace) -> Vec<Blobs>? because it seems to me a standard behavior for a rollup and it could decrease the amount of calls to 1

from blobs.

Why keeping them in tree is needed?

well, to add another adapter would mean that the devs of that rollup stack will have to fork the project and implement their set of endpoints (assuming that they don't want to use the existing endpoints for other adapters). Then they either keep it out of tree or upstream it making it in-tree. Another alternative, is that we provide an extension point somewhere, but that feels kinda overkill and goes against the idea of having a single binary as I described in #24. But possible.

we could also proceed with both, on the sugondat-chain the more complex thing is to setup the RPCs that are able to able to use some runtime-apis so maybe created the base layer having both: common divisor and ah-hoc api should not be that complex

TBH, I am not sure if I follow. But generally going for both adhoc and the common denominator doesn't make sense to me, because we will have to spend time on it to make common denominator API reasonable (or do a half-assed approach), then support both versions. It's a no go.

Asking to the da for ALL blobs of a namespace inside a specific block, is split in a number of rpc calls equals to 1+n where n is the number of blobs submitted in the block, why not something like get_blobs(height, Namespace) -> Vec? because it seems to me a standard behavior for a rollup and it could decrease the amount of calls to 1

Well, yes, that's the problem I was trying to describe. There is a natural tradeoff between the flexibility of the API and its efficiency. Maybe, it is the common way to ask blobs in such a way, and it does seem to me this way as well, but what are you going to do when that's not the case? Probably, you will add the bare versions of the API. But now you will have to maintain all of those new APIs (you don't want to break older clients do you?). Are those efficiency gains worth it? Maybe or maybe not.

That also shows the advantage of the ad-hoc APIs. You don't touch the old APIs, if the adapter changes you add new API, if something requires change, that something is not public API.

from blobs.

Then they either keep it out of tree or upstream it making it in-tree

the added set of RPCs is upstreamed, not the adapter code itself, right ?¿

because we will have to spend time on it to make common denominator API reasonable

yeah, that's true, in my initial equation I imagined the difficulty of creating a common denominator API too low.... for sure satisfy all different adapters is not easy

But now you will have to maintain all of those new APIs (you don't want to break older clients do you?). Are those efficiency gains worth it? Maybe or maybe not.

I see your point now... decide something like this require some security on the functioning of the system and right now we don't have this

That also shows the advantage of the ad-hoc APIs. You don't touch the old APIs, if the adapter changes you add new API, if something requires change, that something is not public API.

yeah, and this could also fit with the shim described in #24 where it changes overtime with the adapters evolving

from blobs.

the added set of RPCs is upstreamed, not the adapter code itself, right ?¿

yep!

from blobs.

Do I have this right? The proposed architecture is that every adapter is a thin wrapper around a spawned child process which is the API worker and which implements APIs for every adapter to be served over some serialized query/subscription protocol like JSON-RPC.

Internally these APIs would be implemented with something like the common-denominator API, which is itself not exposed.

from blobs.

Closed by #32

from blobs.