SSZ Engine API Call #2

Transcript

Tamaghna Choudhuri: GMGM.

Marius van der Wijden: Hey, it's the same people I've been talking to all day, just in a different call.

Tamaghna Choudhuri: Yep, then I guess we can start. So, welcome everyone to the SSZ Engine Breakout. room number two. So basically, there should be a lighter call, because not much in the agenda items. Maybe we can do some client, updates, and then also testing updates, and if, the people from Nimbus are here, maybe we can go through whatever the asset growth in the comments. So, I'll start from my side. So, on the testing side, basically, we have decided on how, let's say, the Vectors are going to be, so, Majorly, first will be, like, the steps is… Majorly, we'll be starting with, integrating all of the SSIL support which exists in the project ZKEVM into the EELS, Amsterdam branch, and then from there, we'll be taking it forward. We'll be adding the reference vectors and…

Also, we'll be starting work on the REST, and, like, we… the idea is to have something abstract, so we can have both REST and everything there. And in due time, we'd also, like, this is more of a directional thing that we discussed over the calls, that in due time, we'd also like the eels to maybe serve all of the engine requests and such, and, like, maybe have it as a temporary… like, the temp EL current is high for the CL to work against, and that would also… the CL spec would also be like that. In this regard, something that I would like to bring to attention is, one of the Yasek's comments was basically that we should be moving towards,

FastAPI OpenRPC, so, like, that's something that I do have in mind for the short term, because, yeah, so, like, that's something that is… I have planned in the short term, and in the longer term, we'll be integrating the majority of the execution API-related… all of the testing and everything inside EOS, but, like, that's also something a bit farther out. So, like, that's on the testing side, maybe… Others can drop the updates.

Dustin Brody: I can comment on the Jacek stuff if you want, I don't know. He is not going to be able to be here right on this meeting, and so I'm the… Nimbus representative, I guess, on this one, so I don.

Tamaghna Choudhuri: I mean, sure, like, I don't… yeah, sure, like, I guess I don't think anyone else would be… Taking this day, so it's free for you to discuss regarding that.

Dustin Brody: Okay, okay, great. So… So, Jacek, and I will say that in this case, I kind of independently agree with him. I've looked at his things, and I've I think he's right. No, I mean, at that, so he has 2 broad points. 1 of them is that Okay. is this sort of path thing. And so, right now, we have the… actually, I don't know if people have seen this in… I'll link in a moment in, Here in Discord, as well, we'll keep talking, is that they're… they are, the REST API has a sort of path setup. And a convenient property of like the. what's called a quasi-paths, like HTTP paths, like for REST, is that they can be… they can coexist. So you could have the same kind of server, or they can be…

that they can exist on the same port. And in particular, for example, Nimbus, as people may be aware, has a unified client, for example, and it would be really convenient to be able to use the same REST port. and have… and serve both on the same REST port, just as… as one example, but… but in general, it's… it's a nice design to have them be able to close it, so that's one point. So, another point is that this is related to what is called this top-up sync, and it's essentially this capability that current… the current Engine API doesn't really have, and I can… if people think it does, I can, you know, address those points and why those things don't, in fact, solve the problem. But the current Engine API does not really address, which is to say, a way of

finding out if a… if a CL wants to, kind of, sit back… Backfill, or… Fill anyway, a, the gap between the EL's, head, a current head, and sort of the chain tip, then it doesn't know where to start. And there is no reliable way for it to find out where to start, because it can't get enough information, because if the EL is not synced, it will just say, syncing, syncing, syncing, accept it, accept it, accept it, something of this sort. But it will… but it will not really tell you you know, and… you know, where the CL should start, and it will not give a hint in that regard. So, those are the two things Jasper mentioned, and I'm happy to…

Talk about that on his and Vanessa's behalf City. I would wonder… oh. Well, it's… one port is not a requirement. It's not as if… If you don't This works for 90 to 5 clients too, it works fine. But it's just… it's… Right now, it creates more opportunity, it creates an opportunity for a unified client that doesn't otherwise exist. Well…

Marius van der Wijden: Yeah, it's one part for the EL REST API and the CL REST API, right? That's your idea.

Dustin Brody: Yes, yeah, yeah, yeah, yeah, that's the idea.

Marius van der Wijden: Yeah, the thing is, like.

Dustin Brody: It was.

Marius van der Wijden: I can, I can, I can see this with the. like, non-engine API? Like, the JSON… like, the normal JSON-RPC API, not the engine JSON-RPC API? like, the user APIs, I could totally see us unifying them, but the, the, the engine API is like, Like an internal thing, right? Like, you don't want to expose it to the internet. You don't want… you don't want it to live in the same…

Dustin Brody: Okay.

Marius van der Wijden: There we go, yes. as, like, the user APIs.

Dustin Brody: Well, I… Regard both the REST Beacon API and this thing as actually very similar in that regard. I mean, I'm not sure, you know, If that's… They don't need to be unified, no. No, it's not, like, on… this is an option. I'm not saying this is a… they don't… they don't need to. But, like, the… but as… as far as… The… the… to me, both… neither is internet appropriate. Like the beacon API is a DOS vector, it's just a clear and obvious DOS vector in a lot Anybody exposing it on the internet has to be doing some filtering, proxy, or caching. So… And the same would be true for the engine API. And, and no matter what kind of NJ they are. So I don't, I don't, I regard them as actually at the same level of sensitivity

Personally.

Marius van der Wijden: Yeah, I think it… It kind of makes sense to me, now that you're talking about it, because the… As far as I know, also, the… the… Where the validator node talks to the… to the, CL node is also via this Beacon API, right? Certainly.

Dustin Brody: Yes, yeah, yes, that is how that works, yeah.

Marius van der Wijden: Yeah, so it is, yeah, okay, then it's a, then it is an internal API.

Dustin Brody: Yes.

Marius van der Wijden: The question still to me is, like, how would we spec that? Like, it's fine for us to spec, like, okay. It should be exposed on XYZ port. But that would only work for unifieds. Binaries, yeah.

Dustin Brody: Bye.

Marius van der Wijden: Morning.

Dustin Brody: Whoa. Oh, I see.

Marius van der Wijden: Yeah, how would my server know that, hey, These routes, you don't have them in your thing, so you need to… Forward them to the… to the CL or something, like, you would need some kind of proxy in front.

Dustin Brody: I'm not sure I understand what you're getting at. No, I mean, there… the… I… I guess the port thing to me is just, like, I… I don't want to overemphasize that. Maybe it was a, you know, I don't know, to… to… I Foreground that too much except to say that it's an interesting, like, thing one might do. Obviously, I, most people, I mean the Nimbus Unified Client is not production-ready yet, so, like, borderline 0% of people are using Unified Client. No, no, but it works just as well separately, and that's… fine, but I also don't get… know what your talk… what you're getting at, I guess, with the, like, needing a proxy to get things from one to the other. This doesn't affect that either way.

Or, or are you, or do you mean the, the sync, the, the thing where it asks about the, the block that you would start syncing from? Which, which one? Because they're two different things.

Marius van der Wijden: Sorry, I didn't really quite understand this.

Dustin Brody: Whoa. Oh, okay, Sierra, I'm gonna… I'm gonna I have the first so so so a a a a written ex first a written explanation that from this is what Here. Okay. Reversed? Okay. Yeah, yeah, I understand, I understand what a reverse proxy… this is Gossack's comment, so this is where he summarizes it. I understand that the idea of reverse proxy, but I'm trying to think, why is this intrinsically… Yes, of course, you can use a reverse proxy to do things like make access to these things a little bit safer if you add filtering to it. This is, I assume, what some of the big providers for the API, et cetera, do. But that's sort of beside the point. I don't understand how the reverse proxy is coming up.

Either Marius from you or from FOCIL. Like, what is the… angle. Okay.

FOCIL: Is… is it, somehow obligating? I mean… Some people, some implementations can do so, or not do so, and… Yes, that's it.

Dustin Brody: Yeah, the point here is that there's an existing way. If you wanted to get a bit more abstractly or conceptually, there's a way we divide this namespace, this REST Namespace of services, of endpoints. And, and the Beacon API does this today.

FOCIL: Yeah, we just need isolation, yes, for this feature, and we need to account for that.

Dustin Brody: the isolation, but…

FOCIL: Namespace resolution, so REST,

Dustin Brody: Yes, yes, but it provides a systematic hierarchical way of doing this, which is consistent with Kind of namespace isolation we have today. Right. Yeah. And, and, and, and part of it is also, it comes bundled with sort of. practices that we found have worked pretty well in the, and this is not, per se, part of what Jacek wrote, but it's part of the same bundle of things that I don't… is that, like, to specify version on the Beacon API, we use headers. For example, as opposed to putting it on the path. Now, one can argue one way or the other, I suppose, but I, again, I actually think the header thing works pretty well for a number of

Of reasons, but also it's, it's, it's a kind of consistency. Oh. both on the client and server end. So we can talk about an Ethereum REST API as a unified concept, rather than having these completely disparate things.

Marius van der Wijden: Yeah, I have to think a bit more about it. What was your second point again that you were trying to make?

Dustin Brody: Okay, yeah, yeah, the second point is… This is what Jacek is calling the top-up sync, and he talked about this also, in a bit in Svalbard, for, for anybody who is Who is there? But in any case, so it's… the idea is that his, and he summarized it in the comment I linked as well, if people want to see the written form of that, but it's like. You know. he wants to treat the EL as largely a library. And this actually, by the way, yes, of course, he cares about the unified client thing, but this works just as well conceptually unified client or not unified client, it doesn't really matter. The idea being that the EL in this conception of things is at least capable of running without very much of its own peer-to-peer.

Now, there are… there are reasons… engineering reasons for this, there are aesthetic reasons for this. Like, right now, we often kind of duplicate. We think about getblobs and… and sort of the blobs gossip in… in CCL. There's a lot of duplication of this. kind of traffic and of course one can take careful steps to avoid it, but it's kind of tricky as a general principle. So if one moves all the gossip to one side, that is on average more efficient. So the number of general arguments, I don't want to belabor those here, but the point is that This is, this is where this is coming from. It's a desire to have all the CL do all of the gossip.

Or as much of it as possible. And the ELP, he'll phrase it as a library, but as some kind of local service, let's say. It could be via RPC, it could be within the same process, it doesn't really matter, that the CL drives. And one of the challenges here is that right now, this doesn't work very well because this EL… The optimistic sync protocol we have now relies on the EL ability to to pull its own blocks from the network, from W2P. And it is basically not — and the point here is it's not feasible in the current engine API to avoid that. Like, like the, the API support does not exist. There is, this is a point I will strongly defend. There is no sane way to use the current engine API.

As for anything but optimistic saying, I have tried. It does not work. It cannot work. So, that… It would be nice. What?

Marius van der Wijden: So, Why?

Dustin Brody: Yeah.

Marius van der Wijden: You can't, you can't just.

Dustin Brody: But… No, because you cannot get an unambiguous signal from the EL that tells you, it will tell you syncing, but syncing just means it doesn't have that state record.

Marius van der Wijden: No, no, like you can, you can just, you take, give it to the NSS, you give it block one, you give it block two, you give it block three, and it will always tell you.

Dustin Brody: If you start at Genesis, yes, but if you want to start at anything but Genesis, this doesn't work. So what you could imagine, what if you shut off your node for a while? a week or two, I don't know. Keep it within a good subjectivity period for this, right? So it's legitimate to kind of sync back up in that way. Then… the EL, in fact, is synced, but it's not synced from… we shouldn't have to go back to Genesis, that's… Inefficient. So… The idea is, right now, there is not, let's say an Engine API compatible way to read out the, like, as an NGINI API consistent way, across the ecosystem to read out the head block, or the head block, yeah, from which one should sync, up to, you know.

up to the tip. And part of the issue here is that like the ELs, it's the state versus block existence. The ELs typically will just report sinking unless they have an actual state, because it's meant for validating. Not syncing. So… But, yeah. That's… not going to be very useful as a general point. So…

Marius van der Wijden: I would…

Dustin Brody: Prefer for a synch So, yeah.

Marius van der Wijden: I don't know if that is… Correct for Guest. Like, correct, Guest tells you via each get block Latest, it will tell you the latest block that it has the state for. And so what you would do in this scenario would be, okay, like, Death Note is shut down for 2 weeks, it has I don't know, block A as its latest block, and then you start your CL node. And then, instead of giving it the newest block, which you would do right now, you would first ask the EL, hey, what's your current head? EL would tell you A. you would see, okay, I'm at F now. Or like the chain is at F, I need to provide B through the EL, I give it B, I do focus updated, EL chain advances, I give it…

C, I give it D, I give it E, and I give it F. And what CLs right now do is they give us F? And then they, they expect us to, to go to the network and, and find out, okay, F is the ancestor of, E, E is the ancestor of, D, E is the anc- no, is, is the child of, of D, E is the child of C, C is the child of B, E is the child of A, and A is the block that we have in the chain. And then we, we know, okay, this current head. connects to… or this head that the CL gives us connects to our EL head. And then, what we do is we fetch all of those blocks from the network, and then we execute them one by one.

And what you want to get rid of is. Which is a not a bad idea is to get rid of this. Having to fetch the block of the network, but… I don't… I don't really see… How this is not possible right now. At least for Geth.

Dustin Brody: So, the challenge with the… is… There's… oh, I guess there are… there's two things there… there's two gaps here. one of them is it's the existence of the blocks versus the existence of the states. So, for syncing purposes, it actually doesn't matter whether the state exists. It's nice, I guess, but, But what matters is whether the blocks are synced to this. So this is one. Now, I admit, actually, Jacek's message is not super clear, and I haven't actually talked to them lately, what he personally thinks. So this is, you know, my view is that, like, they are — the state is kind of too much of a requirement. For this. For this… for syncing purposes.

The second thing is that. When at least there's an ecosystem consistency point, which is that at least a couple of years ago when I last looked at this, yes, things change quickly and all the time, but there are also more ELs than there used to be. And there's no strong spec on this. In terms of, like, ETH, get latest block, you know, so… What one thing routinely I would see is it would be zero if the state didn't exist at all. So if, if, if I had been feeding this, the EL, the, the. Box, and it, for whatever reason, decided to not construct states on that. It would just tell me that it was zero, and that's… that is not useful for syncing.

Marius van der Wijden: Well, that's, I think it. You can spin the argument either way, whether like you can say, hey, the blocks are not useful for syncing or the state is not useful for syncing. Like if I have the state and you feed me the block plus like from, I don't have any blocks, I only have the state at point A and you feed me the block B. Then I can still verify it. If I don't have the block at state… if I don't have the state at block A, and you feed me block B, I have no idea, because my state might be A-15. So, then again, I have to go and execute from… because I have the blocks, I don't have to find them from the network, but I have to…

re-execute from a minus 10 to a. So… I I you can define it either way. I… Dude. I can understand that the the it's frustrating on the seal side to see block 0. But this is how we do it. We tell you the block that we have the current state for. And if we're not synced during snap sync, for example, we will tell you 0. I can see the advantage of saying, hey, I want to know the block height, because I can feed you more blocks. in if we're snap syncing but most of the time like we're not snap syncing right? And so this this example breaks down where where you have where you have a note that is shut off for 2, 2, 2 months, and then

you start syncing it again, because it will always force you to to full sync. You can never like you. We will never force you to snap sync. Anything, after you have been initially synced with. Because that would be in the tech vector.

Dustin Brody: Okay, so another… a scenario I would in general like to point out that, or sort of suggest, is… And we've discussed this, is it so that the Helvetica scenario, one of the actually, we found it very challenging. We Nimbus had a sinker, which was able on the CL side was actually able to navigate all those forks, somewhat adroitly, it mostly worked. maybe other CLs did too, I don't know. But the… And the thing is that the ELs often couldn't follow along. And so this is a case where, like, no matter what the CLs did, and the CLs would try to kind of go from fork to fork to find the canonical fork. And it didn't, and they would get stuck anyway.

And so this is… this is… the other advantage of this, this is a way of… so the… if the CL can get into… even with EPBS, like, because, yes, it's now separate, but it's still gossiped over… over the CL gossip channels, you'll… you'll get the same kind of, like. if the CL can follow the forks, then it can tell the EL how to follow the forks, too. And this is a particular chain liveness. Yeah. Challenge.

Marius van der Wijden: Yes, like we have. We, as in guest, have improved a lot of things there, like, for example, we can reorg 90,000 blocks or more than 90,000 blocks. Now, 2 weeks now, in I think, about 30 seconds, where it was like tens of minutes before. And, and we have also… improved our ability to fetch blocks from the network. The problem, yes, if you have a CL block that is connected to some CL chain and we don't have EL peers that have these blocks, then we cannot get them. And so, yeah, it… I agree in those cases, a unified stack makes sense, because, you on the CL made sure that you had these blocks, and then the ERL couldn't fight it.

Dustin Brody: Yeah, I mean, I… I would tend to say agree that a lot of cases people are broadly. Mostly, the existing syncing approach works well in a lot of situations. And obviously, it can continue to be used. Like, the goal here is not to prohibit it, or say you shouldn't use it, like what Guest or Nethermind or any of the yellows are doing. whether it's SnapSync or anything else, is to say that right now, the… there's a relatively easily filled gap In the, in the spec. that… I mean, sure, you've got the block height, or, that is… This makes it very difficult to do anything but this one style of syncing. And and the goal is to fill that gap.

Not not to force people to to not everyone to use that.

Marius van der Wijden: Yeah, I, I don't know if we need to do that via the REST SSZ API though. Like we could just do it via the normal JSON RPC API to say, Hey, we have. get blocked by number latest. And we have something like… most recently seen block or something. Or, but even even even that even then the like it gets kind of murky because like. I don't know, if someone feeds us a block with, I don't know, block number 1 million. And we have no state for it. We don't know if it's part of the canonical block chain or whatever, and we can just, like, return, hey. The highest block that we've seen is block 1 million.

1 million is not that high, actually, in today's blocks, but, like, 1 trillion, and so you would always get, like, the block 1 trillion, but the block 1 trillion isn't really the one that you that you wanted. We could give you the latest block that we marked as canonical. Probably, yeah. That might actually be an idea. Yeah. Get latest canonical block or something like this.

Dustin Brody: And there's also a middle ground of checking, like, contiguousness of the chain, so, like, block hash. And does it… is there a… Yeah, is there a contiguous chain to a unknown, whether it's Genesis or some other kind of So a pivot, a trusted pivot, whatever it is, that… You know, one can, without necessarily having to have a state. So… I do understand what you're saying, like, but I think the 1 trillion thing is pretty easy to… avoid. It's simply not valid if there's not some kind of lineage to a known To a known block. No, but that's my… the pivot is, in this case, trusting as functioning as an, to address FOCIL. A trusted… a block who's,

A canonicalness is trusted. Like, it's trusted that it's on the chain. Whether you have the state or not. Yeah, okay. Like, the idea is it's anchoring you to the chain that you think is real. Sure, that works too. We've previously gotten FCU for it. That, yeah, sure, because that's a CL saying this is the case, asserting that's the case. That's actually not a bad idea.

Marius van der Wijden: Yeah, yeah, this is, like, this is kind of what canonical means for us. It's like… to see how that's like the most recent. a block where the Cl. Said, this is the head. Or, like, this is the canonical chain, and all of those blocks in this chain, And. are thought of as, like, the canonical blocks. So something like ETH gets… Latest canonical block or something. would probably solve this. But then, like, Okay. I'm kind of hesitant to add this to the to the engine Api, because it doesn't really have any, doesn't have that much to do with the engine API, it's more of… yeah, another like a normal Jason Rpc. Api.

Dustin Brody: Well, this becomes a challenge, at least exactly that dichotomy or delineation. the Engine API has lived in its own world to some extent, and… and this… there's a couple of aspects here. One is that, at least with the JSON-RPC version of the Engine API, there is an explicit list of APIs, and it's in the spec, that is, like. of the ETH namespace APIs that are guaranteed to be there. I believe you have, like, ChainID and a few others, but it's… it is not the full Web3 API. I mean, some ELs may or may not choose to serve it on the same ports, or… sure, that's a different, you know… but… but from a spec perspective, from a CL,

compatibility with all, like, a spec following EL, they can only assume about a half dozen of these APIs. So even if, like, the very minimal version of this is Is something like it's, it's on this list in the in the engine… in… whether it's SSE or… or JSON-RPC engine API specs to say that, it's… it's available on the same… port, or as part of the same thing. The other part is, though, also, the having, sort of sharing, how to put it, just sharing the standards. for what counts as a full block. So… so the idea is, like, the Engine API is very specific about blocks being, like, the semantics of invalid blocks and, things like this.

Right? That the other parts of the ETH namespace APIs are not necessarily… they do not specify this. And if they do not specify this, one cannot rely on it across ELs. Whatever Geth happens to do. So… I mean, it doesn't have to be, and they… specifically in the sort of engine namespace, potentially, but it does need to be semantically linked in an explicit way, both to be present On the same sort of set of services. And that it shares a semantic definition of what counts as this, whether it's the latest block or… Final, or… yeah. Walk. So it can't just float unspecified.

Marius van der Wijden: Yeah, but the that is something that that the folks over at the normal Jason Rpc. Call have have been working on quite a lot to cut down these methods where where you have like. Different clients behave behaving differently. So it would be clear that if we add this method, then everyone has to. There's a spec that's test for it, and everyone has to behave the same.

Dustin Brody: Okay, but that solves… that would resolve half of what I'm saying, sure, but the other half is still this point about… that the Engine API support, it only specifies that, again, I think it's a half dozen to a dozen or so of these non-engine, endpoints exist. This is the JSON-RPC one. I think… I don't know that the SSZ1 specifies anything one way or the other, nor… I mean, hard to see… hard to see how it could, but… but for the… But yeah, so that's… so it means that a CL has to then be connecting to an EL on two different ports, and that's a configuration issue. That's… are the two ports even open? On both sides, CL and EL side, they… you can usually enable or disable them independently. So…

I mean that that that is the. And that is firmly an Engine API concern. That is not something that people.

Marius van der Wijden: More.

Dustin Brody: We're in the JSON R.

Marius van der Wijden: But for each… He's thinking, for example. We need to do that anyway.

Dustin Brody: To do what anyway?

Marius van der Wijden: Like connect to the normal. Rpc. Api. On a different port.

Dustin Brody: Hmm, okay.

Marius van der Wijden: No?

Dustin Brody: How, how.

Marius van der Wijden: Very cool.

Dustin Brody: No.

Marius van der Wijden: Are we serving it on the same port?

Dustin Brody: Oh, wait, serving… which endpoint do you mean? Like, I thought we could validate…

Marius van der Wijden: Thank you.

Dustin Brody: The steel can go.

Marius van der Wijden: I need…

Dustin Brody: Without.

Marius van der Wijden: No, I mean ETH.sinking. ETH.sinking.

Dustin Brody: Oh, oh.

Marius van der Wijden: Eastern.

Dustin Brody: Oh, that.

Marius van der Wijden: I'll Get receipts or something.

Dustin Brody: Oh, okay, well, those are two different things.

Marius van der Wijden: You too.

Dustin Brody: So.

Marius van der Wijden: Yeah, no, but those… Oh, we haven't… Ether syncing is is a is a bad example, but get receipts as something that you needed right in the past.

Dustin Brody: Yeah, I mean…

Marius van der Wijden: Me ne.

Dustin Brody: if… yeah. Yeah, yeah, yeah, to get the… it was a… the deposit… there was a… there was a log monitoring, ETHGAT logs, for the deposit monitoring. We don't… we don't need any more, but we used to.

Marius van der Wijden: Yeah, but this is served on a different port, right?

Dustin Brody: Well, so it… It varies here. I'll link to it in a moment, actually, because I just found it where this… in the spec. It's very specific about this, and here there's wait. Oh, where's my… Okay. This.

Marius van der Wijden: Yes.

Dustin Brody: So, so if you look at that, that, that's a link to, that's, that is in the Engine API specs today. And at least.

Marius van der Wijden: Mmh.

Dustin Brody: for specific things. And there are, yeah, I remember, so it's about 10, 9 or 10. And ETH syncing actually is there, it's on there.

Marius van der Wijden: I don'.

Dustin Brody: Also on there. That's why that worked, because this was explicit. So this was not a random chance.

Marius van der Wijden: And this is what I'm saying. Yeah, I get it. But yeah, but nothing really stops us from doing the same thing, right? With each get canonical. Yes.

Dustin Brody: Right, so that is absolutely a way of achieving a similar goal, or the same goal, yes, is to have it be standardized and specified by.

Marius van der Wijden: Okay.

Dustin Brody: another entity, and then incorporated by reference the way these things are here. That, that, that, that can work as well. Now, the challenge then becomes the JSON, the JSON RPC, the Web3 API, that brings back the two different ports, because this is a… it's REST versus… I don't know how ELs intend to serve this in general, but, like.

Marius van der Wijden: You know, like.

Dustin Brody: Thank you.

Marius van der Wijden: You're making, you're making a good, you're making a good point that this is something that the, the, the SSZ spec, right, the REST SSZ spec right now doesn't, doesn't have at all. Right?

Dustin Brody: Yeah, yeah, indeed.

Marius van der Wijden: This notion of these these calls, we we are also exposing the our namespace.

Dustin Brody: Y-yeah.

Marius van der Wijden: Like, this is something that we need to specify anyway. It's like, how are we getting these things?

Dustin Brody: Yes, that's a good point actually. Like this top up sync stuff aside entirely, we need a way to, now get logs has probably fallen out of use. I think we can safely say 6110 is not going to vanish tomorrow, but a lot of the others are like each chain ID is useful. for, obviously, checking compatibility with an EL, or are they CL and EL on the same chain? Obviously, e-syncing is useful, etc. So, yeah.

Marius van der Wijden: Yeah, I never, I never thought about it when, when I, when I started designing the, the REST SSZ API that, that we, that we still need these. I always thought that they, that you guys would just go to the different port where we expose those. I didn't know that they were, like, also exposed on the, on the, on the engine port. And on the, like, on the authentication port. Yeah, no, that makes sense. Yeah, yeah. That's a… yeah, that's a good to-do to figure out how we… How we do this? Probably it would make sense to move them to SSZ as well. Okay.

Dustin Brody: I think that makes… yeah, it should be a consistent encoding, and that's a point in general, by the way, that, like, to try to make sure that again, we have, aside from the namespace, you know, or using this sort of similar kind of, you know, or consistent namespace, also, like, the REST encoding, there's, like, these little differences in how, like. do, do numbers come with like zero X before them or like all sorts of just little, these, you know, between the, to the two different JSON encodings we have now. And it would be good if we had to really make sure consistent that the… the syntax was consistent. Of course, SSE is SSE, but there's all sorts of other choices that are semi-arbitrary, and to make the same semi-arbitrary choices as the Beacon API, unless otherwise…

like, pretty compelling.

Marius van der Wijden: Yep. Yeah, that makes sense. We have, like, we have the call recorded, right? And there's, like, a transcript or something.

Dustin Brody: I believe so, yeah.

Marius van der Wijden: Yeah, okay, I can make sure.

Dustin Brody: Magna would know. Sorry, go ahead, yeah.

Tamaghna Choudhuri: Yeah, so, like, yeah, the call's recorded, we'll have the transcript, and we'll also have the other podcast for everybody to maybe watch it later, so that's all good.

Marius van der Wijden: Amazing. Amazing. Yeah. So, yeah, I think it's it's a good it's a good to do to for us to figure out what what what we have to do there.

Dustin Brody: Yeah, and I think one of the first useful things is to go through and even scoping it because I'm looking at that and I can tell you about half of these have to be obvious utility from a CL, specifically engine type perspective. No. But some of them, I honestly don't know. Why is ETHGET code there? Personally, I can't say. I'm sure.

Marius van der Wijden: Anyway.

Dustin Brody: You know.

Marius van der Wijden: Yeah, probably to make sure that the… probably to make sure that the deposit contract is, is, It's deployed or something… Thanks.

Dustin Brody: Oh, that's good, that's a good point, yeah. That's probably… that's probably… oh, yeah, the other… oh, I know, right, because… hmm… it was… it was… yeah, so the… yeah, it was to find the deposit contract. I at least didn't… that's why… and I think Nimbus did something like this. I, I, I remember this code a long time ago, but I mean, where it would kind of scan for, it would scan for the logs, but it would also scan for the deposit contract. itself, and… okay, yes, okay.

Marius van der Wijden: You guys, you guys are just, yeah, you guys are just crazy. Sometimes. Right.

Dustin Brody: Sad. This necessity, in that particular case, it was the only way to do certain things. We're much happier with 6110. But get block by hash and by number are pretty useful. ETH call is kind of mysterious to me. I mean, I know what it is in general, but I know… Like, why?

Marius van der Wijden: Yeah, yeah.

Dustin Brody: An engine API would need it.

Marius van der Wijden: No idea. In any case, yeah, I will, I will, I will take care of it. I will make sure to, to get, to get this into ACDC, or, like, both ACD. And, and, and make sure, hey. We need input into what methods are still useful. And what method we can just remove. And so on.

Dustin Brody: Correct. Yeah, that makes sense. Yeah, and I think it's just as important not to add Things, because we'll have.

Marius van der Wijden: Yeah.

Dustin Brody: SSZ versions of them specially, like, they don't, like, just exist right now, to not add things just because they're here. If… if nobody needs Ethernet logs anymore, then don't add it for the sake of…

Marius van der Wijden: Yeah, no, that's clear. This should be as minimal as possible, anyway.

Dustin Brody: Yeah, exactly. Okay. Alright. Anyway, I think that that's… on what I wanted to say.

Tamaghna Choudhuri: Yeah, that was a long discussion, so, maybe, like, what I'd say is maybe from the transcript, maybe, and, like, also we can maybe get up a public document regarding this, because what I see, it would be good to also have, the clients which are not on the call, their opinion, because,

Marius van der Wijden: Yeah, dude.

Tamaghna Choudhuri: That's… that becomes important.

Marius van der Wijden: Yeah, I will, I will prepare a document explaining, What choices we need to make, why we made them in the past the way we did, and what things we could potentially get rid of. Yeah, yeah, and then I will, I will send it in the groups and then also discuss it on ACDE, to get, like, the opinions of the people that are not here yet.

Tamaghna Choudhuri: Yeah, that would be good. So, like, these discussions regarding what would we need, and also maybe, the explainer on the, thing that, the asset growth might also be a good point, so, like, that we can maybe have these two documents up, and maybe we can ask everyone to have a look. Yeah, so, like, other than that, is there any other thing that, let's say, we want to discuss today or right now? Or, like, would that be the end of it, and maybe we'd be… Giving it some time, and Maybe we can give it some time, and then meet on the next call, that's in 2 weeks, and also maybe drop this off in ACDEC. I guess it would be good to bring it up in both of the calls, because

We'll be getting more visibility then, but like, yeah.

Dustin Brody: Yeah, I mean, I think it would make sense to kind of bundle with what… Marius is talking about, putting together Jacek, you know, he has this, this, this markdown document, or that, or this HackMD document, I guess not, that, That, I think, explains actually pretty well, like the motivations for for this. So, it doesn't cover the chain foe in case I described. Doesn't — yeah, anyway. But it covers the mechanics he's looking for.

Tamaghna Choudhuri: Alright, then I guess then, yup, then maybe we can just add that change-following mechanism into this, one that Yasek already has, and, the new ones. Other than that, is there any other thing we'd like to talk about, or then maybe… we can maybe end the call. Maybe it's 10 minutes to spare.

Marius van der Wijden: Sounds like a no, I guess. See you guys next call.

Tamaghna Choudhuri: Yep, see you guys in the next call. Bye.

Dustin Brody: Yep.

Justin Traglia: I forgot.

Dustin Brody: Bye.

Tamaghna Choudhuri: Next Friday… next to next Friday. Bye, guys!

Transcript adapted from ethereum/pm, CC BY-SA 3.0.