Everything EOS EOS Node Operator Round Table, 15 Feb 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Node Operator Roundtable - February 15th, 2023

Description

Welcome to the EOS Node Operator Roundtable! In this recorded episode, our panel of experts updates the community on software development and continues their technical discussion on special purpose nodes, the classification of different nodes, and what purposes they serve. Get ready to gain valuable insights into the world of node operation, as our knowledgeable experts share their expertise and experience. Tune in weekly to stay up-to-date on the latest developments!

00:00:00 Start
00:00:02 Welcome to the Node Operators Roundtable
00:00:35 Software Development
00:01:15 Node types
00:10:41 Push API node
00:18:55 Chain API node
00:31:10 State API node
00:36:18 Developer node
00:37:55 History API node
00:38:48 Snapshot provider
00:41:25 Transaction estimator
00:45:33 Trace API node
00:55:12 End

The EOS Network Foundation coordinates financial and non-financial support to encourage the growth and development of the EOS Network. We’re harnessing the power of decentralization to chart a coordinated future for the EOS Network as a force for positive global change.

// EOS Network Foundation //
https://www.eosnetwork.com
https://twitter.com/EosNFoundation
https://www.linkedin.com/company/eos-network-foundation
https://t.me/EOSNetworkFoundation
https://discord.gg/eos-network
info@eosnetwork.com
#EOS #Web3

A

All right welcome everybody. February 15th We are continuing the discussion today on special purpose um nodes. Last week we talked about mostly BP notes. We focused on today I believe we're going to get into the API notes, um so the document has been shared. Thank you. Brian in the chat, I've got it up on the screen. This is where we've been capturing the conversation uh before we get into that as we do. Maybe I can turn it to Steven on here to give any anything to share. On these.

A

Last week we um we mentioned that there was potential code freeze on the horizon for leap 4.0, any progress there or anything else to share.

B

Yeah, the headline just remains that it is uh still in the coming weeks. We've had some great discussion internally and I. Think we've got some good ideas about when we'll be zeroing in on that could freeze uh just not fully equipped with the information we need just yet to say definitively to everybody here. But weeks is the answer.

A

Cool at any questions, all right in that case I think we can hand it over to Brian to continue the discussion on special purpose nodes.

C

Thank you, Daniel all right, so uh last last week we spent most of our time going kind of deep with block producer, and we started talking about um the block and transaction relay nodes.

C

um I'd like to change up format a little this week and kind of just go breadth first to just take the instead of getting into the best practices, um which is what we were kind of working on for those last time um for each of these nodes, which which will be a next step, um just making sure that our list and definition for each uh is agreeable and accurate right.

C

um So this could get into you know some well actually I think those should be combined because X, you know or well actually I think that should be split into separate things, because why right, um which is good but I, will make an effort to sort of cut off um overly detailed technical discussion to to come back to it at a at a future time.

C

um You know if there's a quick sort of offhand comment about um best practices. I'll I'll make an effort to capture it, um but uh I'm gonna try not to go deep on that. At this point, um and the reason for that is just because uh it is, it is valuable and we will come back to it, but it's also a lengthy discussion because uh it gets into the um sort of node operator sharing notes right because it might not be. um uh It might be that different noon.

C

Operators are are handling things in different ways, so that's valuable to capture and to compare notes, um but it's time consuming so we'll come back to it once we've got the full list, all right with that in mind, um I'm gonna actually start with the relay nodes bit because, even though we kind of talked about them last time because there was discussion uh last week as to um whether they are indeed separate, node types um and so I just want to do a confirmation.

C

Originally I had block relay node transaction relay node and, like a I, don't remember what I called it, but like a combined relay node that that did both I think what we, the suggestion, was that really a transaction relay relay node is a combined relay node, because it's it acts as a block relay node and also uh accepts transactions from its peers. Passing them onward to its peers.

C

After validating and filtering you know: subjective billing blacklists Etc um so before moving on I just wanted to confirm that um that really those are the only two types of relay nodes: there's a blocks only relay node and a you know: blocks and transactions. Relayed node.

A

See Matthew giving a thumbs up.

D

And gets debatable depending on how you want to classify things simply because then you could say well. An API node is also a blocks and a transaction relay node.

C

Right well, I think, that's so just to repeat, and we might have a repeating Smith match. I, don't know um I'm saying the two types would be blocks: only relay nodes and blocks and transactions relay nodes.

D

Right but I guess it's for what it the purpose it is deployed for, like we specifically have nodes that yeah they relay blocks, but their purpose is to be kind of private and for transactions, so I mean if it's. If it's function over purpose, then yeah functionally they do both. If it's purpose, then they are distinct. Things.

C

Good point I see what you're saying so so really I think it would be fair to say that what we're capturing here are the the primary purpose of a node um well or.

E

Specifically related to its peer-to-peer functionality, I mean, in my opinion, because Aaron's right, you can have an API node. That is just for read only so. It only needs block so many type of thing, but you know we think API mode and we think of push transactions, but fundamentally at least how we were kind of discussing it was in any of those scenarios. It may be a public period of view or private peer-to-peer, BP API ship snapshot.

E

Fundamentally, we've come down, so there's cut two ways: you can figure them. One to just say, look give me the good data or two specular data. You know, I mean which is transactions and relay, and all of that so I mean yeah. It's absolutely correct. I mean you have different configurations of those types of peer-to-peer handlings which then go into whatever the nodes do yeah that fair Aaron I mean yeah and isolated from the peer-to-peer functionality, even though it may tie into the API role.

D

Yeah and I guess, if we're just defining like this, is the way you can configure nodios, then. Yes, there are two, but if we're talking about this is how you deploy a network, then there may be three. So it's kind of that. What's the third option.

D

Well, I just mentioned the fact that you, if you're, deploying a network, you may deploy a blocks and transaction node that is specifically to hook to apis, and so it's purpose is for transactions.

D

It does blocks, but like I guess, maybe that's just a private peer at this point, I don't know. I was just in my brain, justifying like okay. What are we classifying these things by yeah.

C

I think that's fair, so so let me what I've captured under like the ver, the sort of very top description for nude types um is I think this is a bit of a meta definition right, so these categories are defined by the primary purpose of a given. Node is: does that seem fair.

E

Yeah I don't know if I'd leave it open, like that I'd say the peer-to-peer functionality, the peer-to-peer relaying functionality, because again it ties into all the different types of nodes, every single one of them on that list. Ultimately, we make a decision. Are we configuring it to only care about blocks, or are we configuring it to also care about speculative transactions either in or out or whatever.

C

Well, so sorry I just to try to clarify I'm talking about for the entire list of all the node types. What we're saying is the the category definition would be based on the primary purpose of.

B

C

Node so an example of this is like we would Define um a quote-unquote developer, node um or some better name, and why would we Define that? Well because the the developer node is probably doing um kind of all of these things, because you know they're just trying to have a single node that they can. You know build against, or something like that right.

C

um Does that I don't know if that's a good example, but does that make sense.

E

I'm fine with it I mean I, think I have some different definitions, but we can move back.

C

Yeah, okay I mean, and we can revisit if, if it turns out not not to be a helpful way to look at it, okay um and and actually.

C

um I mean Aaron's Point kind of goes into the next one, but let's first read um reread these definitions for blocks only relay node and make sure that it is accurate and then blocks and transactions. So we're saying blocks only relay node um receives blocks from its peers and passes them onward to the rest of its peers after validating block headers.

C

C

Okay, blocks and transactions relay node acts as a block block relay node and also accepts transactions from its peers, passing them onward to its peers after validating and filtering, and then examples of that are subjective. Billing blacklists Etc.

C

Okay and then there's some like categorizations within that that might further subdivide it which are like. Is it accepting them from from the public? Is it accepting uh only from a defined list of peers um and is it accepting pending transactions.

C

All right moving on to push API node, so um a concept here and again. What we're doing is like validate that this is an indeed a node type that that would exists to serve this primary purpose right um and whether the definition is accurate, so push API, node accepts transactions from clients, validates them and attempts to apply them to the blockchain.

E

um We passed them down the line to be applied to the blockchain okay, because it's got a lot of hops and potentially a lot of gates to go through before it actually hits the blockchain from the outside yeah.

D

Every push API applies them locally, like that's, why we have speculative billing and which.

C

To that point, I was going to ask: is this one in the same as a Sentry node, as we've called it.

E

Now that the century nodes are the ones that end up eating them between the push API nodes and the block producer, but Aaron does have a point. They do hit the chain on the speculative side of things. So I mean they are getting passed around, but they're not actually you'll get transactions pushed to the push API node and they just disappear into La La Land because they go through the Sentry nodes, get mixed and then never show up anywhere.

E

You got a successful push, but no action in the back end because it ended up getting speculative build or whatever does that make sense.

C

Yep, so is this actually just a blocks and transactions relay node where that accepts that accepts transactions from public clients via VIA http.

E

Any clients, public or private I mean we push our own transactions claim scripts stuff like that, but it definitely has to accept API transactions, or you know whatever and then also be connected to the mesh to relay more than just blocks, because it has to also relay the speculative side of it.

E

It doesn't have to receive transactions from the network.

C

E

Interesting right, you need to push them, but it doesn't have to receive.

C

Okay, yeah because it would just receive the blocks yeah and then it would receive transactions from the yeah.

C

F

I realized I, wouldn't necessarily have to run um the HTTP RPC either like um those plugins would be disabled. We could just run PDP. Okay,.

E

Unless you want to monitor it, but that's a separate conversation, get infos hooked into a uh the web. Plugin.

C

So see starting at the top. Is this indeed a like a node type that you would have a node that serves this primary purpose?

C

Okay, does anyone want to take a stab at a better definition uh like sort of sentence for this.

E

I mean, in my opinion, the way I see it is it's that V1 chain push transaction or I. Think there's now push transaction too right, I mean I. Think most people will take that and Route them, respectively to a node, that's dedicated to ingest, because that gets hammered horn because the the like argbots they're, just smashing it until the contract accepts it. That's the node, that's 500 500 500 500, so people tend to kind of isolate that at all, because it's what really this is that front line of smash it till it works.

G

I'm not quite sure, our our end goal for here, but I mean. Certainly there is a distinction for a push API I know of whether you allow uh PDP transactions to come through it or not. uh Typically, I think you know for um busy change and and ones that are providing multiple nodes for for multiple reasons.

G

I would think the typical uh configuration would be to not uh not effectively execute P2P transactions through a push API note, but in in that sort of the the definition that you're looking for like the common uh configuration or maybe the optimal configuration for a push. Api note.

C

Ultimately, that that's the goal, um but at the moment I'm just trying to stay at at the higher level of is this. Indeed a a type of node that we would want to document configuration best practices for right.

C

Is the next step, but.

G

Yeah I think I think for this particular type would be to not uh relate P2P uh transaction and only um except HTTP push API transaction yeah. Okay,.

C

Okay, so it would be.

C

Accepts P2P blocks.

C

Does not accept.

E

Well, I mean every note on the network except speed of your law.

C

Well, I, guess that's a good yeah, so that's redundant but does not accept peer-to-peer transactions.

C

All right, let me try to read this accepts transactions via HTTP clients and acts as an outgoing transaction relay, does not accept incoming peer-to-peer transactions.

G

Yeah I think that's proper and then we would say if someone's configured it also relay P2P transactions and I, think we would say that that's that node uh fulfilling two of your configuration, node types in that case but in general I, would think that an API node would not, um as the definition would not perform, that function.

E

I think most people probably do run their P2P and their eight uh apis all together from a public side yeah. It's you try to in the trim them down, but we do good just to not get them to run their block producers as a public apis, so typically what they would do.

G

Both right but I, think that's. The point of this whole exercise ride is to help the community know that hey you know here is the optimal configuration if.

C

So, okay, um that's also acting as a push Pi nude.

C

All right so I've also modified the prior definition a bit uh to mirror this out. Okay accepts transactions via HTTP clients um and acts, as an outgoing transaction relay, does not accept incoming PDP transactions unless also acting as a blocks and transactions relay node and then the way I changed. The previous one is basically mirroring this, but the opposite does not accept transactions via HTTP unless also acting as a push API node.

C

All right so node, API, node I, don't know if this is a thing or not, um but it's a thing that came up in in conversation that, like some nodes are, you know providing metadata about themselves, but obviously that can't really be the primary purpose of the node. Otherwise, what's it doing right, it's just Naval gazing or something. So maybe this isn't a node type by the definition of um you know the primary purpose of the node. Would we agree with that.

E

I, have it routed I, don't use it much I think it's one of those that maybe anchor call. That said what are the supported, endpoints or whatever? Isn't that the one that lives on node but yeah, you know I, like I, generate a whole fake response for that.

E

Well, that's what I was just about to say is technically because the way most of us run it it is almost worthless to us, because you have to hijack it and really marry all of your farm back together, because this node says no I'm only doing this yeah and Senator there's a bunch of apis that I hide so I don't want this to show those either.

C

Right, so what I've done instead is I've moved into the sort of traits section, a question that says: does the node provide access to metadata about itself publicly privately right, so I think it's not a node type, it's just a characteristic that we could capture for a given type. Does that seem right? Well,.

E

Or maybe it is or maybe it isn't because like ours is a static HTTP file that just gets served from like disk, so it's it's a node type of Flac file.

E

You can do it, however, you want. You know. That's actually, however,.

C

Right, so it's so, it is actually running as its own. Unquote. Node is what you're saying. Well, it's not node us or.

E

See I built another program that emulates the API I, see the hijacked the response and that's ultimately, what we kind of do because, like you've, got all these layer 2 solutions that have kind of replaced layer, one per se, not like in a production based scenario- is running some sort of load: balancer ha proxy nginx traffic, whatever yep right. So it's up to that layer to provide that response, not the individual nodes that happen it's bounds. If you want it to be accurate and usable like a monitor.

E

Well, then, okay, yeah, if anger, asks my node. What I have my notes going to say: I, don't have history because there's no way you can add history in node OS, but yet Hyperion if you hit V1 or B2. Yes, we do support that, but anyway, so that's kind of it's almost as useless as a public stat. It's helpful internally yeah, but unless you can override it and marry it all back together or have it be like a static Json file that you can provide, that may be more useful.

E

I complained when the API was added.

E

I would say: it's not really no tight, it's more under. Is it useful and why do you use it yeah, it's not really. No type. I agree.

C

Okay, cool moving on chain, API node, uh so what I have here is um provides access to metadata, representing blockchain Primitives like chain blocks transactions, contracts, protocol features and producers, um starting with the title like first well, starting with the concept. First is this: would you have a node running to fulfill this primary purpose.

E

Yeah blocks is very heavy, yeah I was just gonna say, but maybe not to get locked part because I know Aaron has a different solution for that.

D

Yeah good, though I mean maybe it provides a subset of blocks it. It generally will provide blocks to just might not be all alone.

C

Yep, okay, so next is the name. The right name.

D

Matches the namespace of the API calls.

E

It's fine I think it.

C

Yep and as the description, accurate and useful.

E

Yes, but like say you can actually that does divide that a little bit more, at least in its current state, because you tend to take every everything's like get blocks or things that need full block.

E

Loan Matthew keeps asking me for Block one, so I have to have an ad I know that I'll get blocked, has a block one for him, but guess what most of my apis don't actually have to happen to pull kit blog because they're just accepting transactions or whatever, but so we just do or could split it up more, even within the chain. Namespace. Does that.

C

Make sense, yeah so you're saying that there might be like a subdivided concept. That's like a blocks provider or something like that. If.

E

You look at it from the namespace side, I mean going all the way down to the end point not even just completely grouping it under the chain API, although it is a very effective group and logistically makes sense, because everything's tucked up underneath there, but some people or some heavier chains will actually slice that up a little a little more because some of those things require different heavier burdens than many other chain. Endpoints.

E

Well, I. Guess I really want to discuss whether we do doing either API forget law. So I added a comment in the ongoing discussion about the performance improvements of git block. You know it should be under V1 chain as a function or really. This is a history thing, so it should really be under B1 history and let the display Solutions handle get blocked and then we just get rid of gitlock and then Michael doesn't need to keep around.

E

The first block is then Matthew won't care about. It well eliminate the need to further divide that chain, space yeah exactly so get rid of the different types of nodes by getting rid of the function. Yeah.

C

Or moving it yeah, moving it to a different uh responsibility: that's yeah, yeah and um yeah Matt Matthew provided some context to me sort of offline on that. That's interesting so separate thread though, but yeah that's a good point.

C

E

I can I just address Michael's comment that Matthew requires him to keep block one there. I I think that's an interesting discussion that we should have about how many blocks does an API now really need to keep you know. So the code was written back in whatever year. We started this chain. uh You know for some plus years ago, which you know at the time it was reasonable to be blocked one. uh Maybe you know another 300 million blocks in that doesn't make sense anymore.

E

So maybe we should have a discussion about API nodes should keep you know a million blocks and that's it I mean I. Think that's a provider decision, though, and most of the Mechanics, for that I think are there. You have I just didn't make a decision, but this would. This is a discussion about what is the best practices or what are the things that we should do or when, oh so how we were avoid. It.

C

Like obviously, as an operator.

E

I, don't know what docs need so gear daps, please tell me, do you need get walked from a million ago? If you don't then um yeah, let's just get rid of it. We'll simplified yeah.

C

And arguably, depending on the history solution, there could be an argument that, like actually nodes generally, don't need anything prior to last irreversible right.

E

I, don't know maybe a little farther than that I remember, Aaron actually I mean it was years and years ago, but they did some analysis on because I mean everybody uses gray Mass nodes. So you want to know what everybody's using oh Parts they're locked yeah and it was like you know: hey 80, the 80 20 rule or whatever. What's that Aaron? Does that still kind of stand? True in the excited.

D

Looked recently but I imagine it would most people are moving away from git block too so.

C

Well, and to be clear, I'm, not even I'm, not saying that going back into history, isn't valuable I'm. Just saying like to to Matthew's point it. It might be a separate need that could be handled separately right.

D

um And it's at scale, you're right, yeah,.

C

Okay, um so good good news, sorry.

F

uh Just um history has such a different set of user requirements compared to just sort of pushing transactions, and things like that. That probably should be analyzed as kind of like a separate um case. Yeah.

C

um Yeah I'm going to capture that point too history as a different.

E

The other thing in your description, you you're talking about uh representing what metadata I'm, not sure what metadata is there, but it's like you're reading transactions right you're, not writing. Translations. In this description.

C

Yeah I guess it would just be provides access to blockchain Primitives like right.

E

Yeah and get transaction not push transaction yeah.

C

To read blockchain Primitives like um and then I also we're talking about whether blocks become sort of crossed out on this and separated into another thing, but I guess that's not true. There would always. This would always need to provide blocks. That's what's what's sort of being debated is how many blocks right like? Is it serving a history purpose or not right? Well,.

E

I mean they can get blocks and saying that's more of a heavier historical function. They're for it chain. Api is more kind of current state. If you will versus you want to go back to block one okay, I mean that's kind of a historical type of request. Isn't it.

C

Yeah, like maybe there becomes a separate, separate calls that aren't arbitrary, get blocks they're, just more like you know, get head or get lib.

E

If you remove the blocks from the chain API, it really helps slim I, think all of those. Well, why would you have different chain API nodes? Well, no, you have chain API nodes and blocks is no longer a reason to slice it up. Anymore, I, don't think. There's any other reasons. Many people slice up the chain API other than get there. Well, there's just three parts: just right: there's all there's get blocks, there's push transaction or send transaction to send transaction to and then there's the rest correct that that's what I say.

E

So you know because we have these.

D

Are the problem before, uh like we have in the past split things like git table from get account balance because we had services that would just Hammer get account balance because the API is kind of unoptimized.

D

um So it's a matter of just kind of where the heaviest traffic flows on these I mean there's a reason to divide them. But we already have a note that says we can divide it further. So I think that's kind of addressed. Yep.

C

All right, cool, I'm, gonna, yeah, so moving on to State, API node um uh and then what I've got here is provides access to point in time. State data such as accounts permissions balances, contract code, uh apis contract tables, um so I guess. The first question is conceptually is this? uh Is this a node type? Would you have a node for this Express purpose.

E

I'm not sure what even splits out separate I mean. I know there are some other name spaces, but there's not many I, don't think in Mama's ship at it right. Oh.

C

Yeah I'm I'm, no there's a state of this particular solution, so monetary websocket, oh.

G

Maybe it's not just let ship this is talking about yeah.

E

B1 state right, I, mean I, know, there's a few of them. I, don't really use them much, but I'm. Also not the programmer Aaron.

D

I was just reading the above definition about chain apis and thinking that we were also talking about state apis. So.

E

F

Well, that's what I thought too.

E

Well, there's not a state API plug-in I mean it's part of the HTTP. It's just a different name: change, API yeah. Do you uh I mean I? Guess in my mind, do you ever split your B1 chain different than your B1 State, unless you're doing like get tables or whatnot I? Think of them, as kind of together.

D

I think that's what I was just describing on the last point of the chain. Api node section is like we. We do and have divided up those things in the past, um based on with a reloading code or balances or accounts or whatever it may be.

D

E

I think of it as part of the chain, API namespace that may get sliced up versus it truly being a separate namespace. Is that a valid statement.

E

Or make sense Brian I guess.

C

uh Yeah, it makes sense what you're saying I think this might fall into the category of so so what I'm hearing is I'm hearing one thing and I'm also thinking another thing celery. What I'm hearing is that practically speaking pragmatically chain API, this is redundant to chain API I would move some of this stuff.

C

I would move some of this description into chain API and get rid of State API node, so before I go into what I'm thinking is. That is.

E

In my opinion, how I look at it as a service provider and kind of routing yet because, like Aaron, said you're, either kind of yeah it's chain and state or oh, my god, I've got to do all sorts of crazy level with you know, routing of all the individual main spaces out there needed, but it it it's the same thought process you either splitting it up or minus blocks. It's probably all kind of together. Maybe Aaron is that fair.

C

Yeah does everybody else sort of agree with that.

E

C

So then, uh and so I'll move that in um and then what I was thinking just to sort of get explore this, for a second is um conceptually is this: is this filling an entirely separate need, or not right? So, and and this you know this is a question asked from ignorance right. Is this something where you know like a a Dap, for example, is more likely to need these functions, then the functions defined uh in the chain, API node right because they're looking at like you, know, App, State and stuff, like that, yeah.

D

I would think so and I think that the state API is a candidate for kind of a layer, two solution, um whereas the chain API, if we move blocks out of it, really isn't that's that can stay native so I, maybe that's a good distinction, but with the with the line item under chain API about how this may divide further, that kind of encompasses the state API division as well.

C

Yeah so there might be a sort of a layer, two solutions, uh discussion as well, but.

E

It it is history, API, yeah,.

C

Exactly okay, so then I'm going to get rid of State API for now um and instead so now, chain API becomes provides access to read, blockchain Primitives like chain blocks transactions, contracts, protocol features and producers, and then um also it provides access to State data such as accounts, permissions balances, contract code and apis contract tables, yep, okay, and then we get rid of State API, yeah, okay, moving on developer node.

C

um So this is, you know this is actually not a um a network node if you will um so much as a a different Express purpose. So the concept here is runs a single node Network, fulfilling all roles defined above on a developer's local device for the purpose of locally testing contract code or app integration.

C

Is that a thing.

E

I would say: yeah I mean it basically runs the full setup whenever the features are above the only way it really might make a difference is I know there were some discussions about like a block producer, a block, reducing node kind of automatically trying to disable chain, API requests or something like that right.

E

So if you start to try to enforce some best practices to say, hey, don't do API pushes to your BP a developer, node type flag to override that, or does that make sense or automatically turn on all the features you know run the developer plug-in and it just hey, you know said: do everything in a single note mode, equal node mode, but that that's just a little bit back to some of the previous conversations but yeah everything all at one node is a developer node.

B

C

All right any other thoughts on this one.

C

All right um now we get into Layer Two solution, stuff um and some of the things below might might not actually be Layer Two Solutions, so we can move them up by just introduced the sort of heading of layer, two solutions based on what uh Aaron had just said. So all right, history, API node, uh I hadn't, been even written a description uh for this one. Yet anybody care to take a stab at it.

E

Might be easier because history can be a whole nother ball of wax snapshot. Provider is probably an easier thing to pick off if you want to squeeze it in the next 15 minutes, because yeah, that's very in the whole snapshots is easy.

C

Yeah, maybe we come back to his if you.

E

Want to talk about about node type, I mean, in my opinion, I do think. That's an effective node type yep.

C

Okay, uh snapshot provider now I know from discussion that, like this, isn't really a node type today. So maybe this goes away. um There is well.

E

I think it is there other nodes for it and then, if you use any of your other nodes for this, It ultimately breaks it. So it really almost needs it's a dedicated node. The way it works, but.

C

That's nice! So maybe it's it's not so much a provider as like a A capturer or something yeah.

E

Bing, it's the really only true effect of well I, don't want to say only, but some the most mainstream form of backups and recovery and anything along that line. The first thing any assist admin wants to do is back up the dagum chain, because, if it breaks, how do you recover it yep and when you trigger a snapshot it freezes it and I mean it takes like 30 minutes on black and what I mean people I, see it all the time for new people they find snapshot.

E

They're like, of course, I need to take a backup. Let me back up my block producer. It's the most critical I need to back up boom. It freezes for three minutes and misses rounds every day on the hour yeah when I started. That's what I did it even makes it I'm not a lot producer because is not busy doing anything else. Good.

G

And if it's got to be the best source of truth right, oh because.

E

You have to freeze the chain State and basically shut out the rest of the world and it gets longer and longer and longer and walking.

B

E

I say I in my opinion, I do classify that as a node time. Yeah.

C

Okay, that makes sense um and then of course, I'll also acknowledge that there is a ball of wax to discuss here in a future discussion.

C

um You know, for example, Aaron's topic, suggestion around snapshot, Services trust and distribution, um and then you know I think it is the same discussion, but we've also been talking about sort of verifiability of a snapshot and all that kind of stuff.

E

um So it might fit into that P2P conversation. You know, because it's kind of tied into getting a note going and who do you, trust? Who do you sing? In my opinion,.

D

It's probably also layer one, just as a quick note.

E

Cool yeah not under Layer Two, Solutions, sorry, uh but yeah.

C

uh I guess the same would be said about transaction estimator yeah this one um I don't actually understand yet, like I understand what it's doing. I don't understand how it's uh why it would be a different thing than something else, but first, let me just read it so um accepts transactions from clients validates them applies them locally, but does not relay them to the rest of the network.

E

I'm a little lost too, but Aaron's smarter than me.

C

So um why why does this happen? Why did why would you do this.

D

So we've been doing this for a long time with, like a hacked version, essentially a patched version of notios and in I. Don't three one I think it was when the compute transaction API endpoint came out brought this feature in natively. Not many people run this yet, but the reason you do this is that you can submit a transaction. That's not signed to basically see if it's going to succeed or if it needs something to succeed um so like in the banker side of things.

D

We do this on fuel and in the future, we're going to be doing this with Wharf and the new sdks, where we will actually be testing the validity of a transaction before it is submitted to a push, call to make sure that when it's pushed it succeeds and that should reduce some of the pressure on those push nodes like a lot of the stuff that we're getting hammered with is going to fail. So this is kind of a.

E

Almost looking at spec uh speculative type of building before it gets approached, not speculative billing.

D

But yeah and before the end user signs it like where you know it might need to be modified, maybe the user needs to buy Ram or something what that this is roll under.

E

A possible a piece of kind of an overall chain endpoint, although obviously you may have carve about dedicated nodes for it, but I mean that's kind of a general API that if more developers were, you know, probably aware of it, they would just you would hit it estimate. It Yep looks like it's going to be good and send it down the line, or is it truly a separate node like you would you have to you had to run a modified version of it now that it's native I guess.

D

I think it's it's going to be separate for the same reason as the push transaction API might be secret, separate at scale. It's going to be the end point that gets hammered all right, because it's going to take part of that load from push. That's also getting hammered.

E

Is it maybe enrolled under the pushy if you have rolled in valid point to think about it from that aspect that find.

D

The work in like a production environment, it's going to be separate from push because you don't like the goal, is to put to relieve pressure on the push API node.

E

And they work in tandem, I! Guess that's what I meant yeah.

F

E

Directly, yes, you, we will still probably split them up, but it's part of that kind of other side of it that says: hey. You won't have to smash my push API, which has to be isolated. If you can smash on this and get a little better idea of it, I don't even realize that it's.

D

Just I mean I think. The reason that it's separate is is I believe still well this. While people are hitting this API, it is a block and call if it's hammered enough. It's going to impact other queries as well. So in that, like really robust production, environment, you're going to have dedicated push you're going to have dedicated estimation and then you're going to have chain apis like where people are retrieving data from so yeah. It's just a mitigation strategy to prevent that blocking of reading, essentially yep.

C

Okay, that makes sense.

C

um Okay, another thing that wouldn't be layered, two I think is um Trace API node.

E

Is no clue, that's all Aaron. Okay,.

C

Aaron yeah so I think what Aaron had written I think he's the one that suggested: This, Record, partial historical transaction, Trace information to local disk for clients to access via API.

D

Yeah, it's basically a way to get history.

D

um It would be alongside uh a ship. Node like ship and Trace are kind of the two origins of history. From a nodio's perspective that then layer, two's read so like I use, the trace API regularly I will I used it the other day. To do some analysis.

D

um It's it's just kind of a different approach than State history. One.

E

Thing that was interesting to me when somebody put it why exchanges and I think it was written, float, coinbase or somebody originally. Is that because V1 history's, deprecated and State history is a websocket serialized, it requires a layer two.

E

It became what they kind of generalized as the only effective native plug-in that could get them access without having to run some other Layer Two such as L.A perion or momenta or Chronicle, or whatever it is, but and again, I. Don't know a lot about it. They we haven't had a need for it. Personally, so I haven't had to break it, but that was an interesting way that the light bulb went off because you're right, you don't have any real native way without bolting on somebody's open silverslayer to code of of ingesting exchange deposit date.

E

Is that accurate? You guys there no probably wouldn't manage.

C

I have a proposal here: I think that there are potentially competing solutions for the same thing and I also think that this might actually can be qualified as a layer, two solution, um and so my proposal would be.

E

That it's a layer, two feeder I, would say yeah along the lines of State history. I, don't know where you. Where would you put State history? Well,.

C

But what I was going with this is that like so, um this could also be potentially satisfied with fire hose um right like so. It's almost like the goal is history capture is that there.

E

Are several layer, two solutions that can do similar things? This is the only native plugin that can get it into that type of data. Websockets. Do it serialized and streaming Trace API with manual efforts, can get it out into I. Think it's like a Json or something isn't it. You know what I mean, but the point is: is you you defuse Layer Two Chronicle, Layer, Two, Hyperion, Layer Two and from our state history? That makes sense, but it's I do think it's important.

E

It's the only core history style, theater and I kind of rolled Trace history and State history into the two buckets of not really a public, not really designed to do much on its own. It's designed to get data out of the blockchain into a channel that can be used and state history is really not ideal. When.

F

E

You suit it to be native.

C

So trying to get to the the core purpose of this is it? Is it more about providing the stream of data or recording the stream of data both.

E

What's the difference.

C

Well, the recording potentially becomes a layer, two thing the providing might.

E

Not you have to use it, I mean so like I, say: Trace API on its own isn't helpful, because API has an API right.

D

Yeah we can there the reason that exchanges use. It is because you can use it Standalone. It requires a different methodology like it's different kind of History than I. Think most people think um it's a way that you can follow history block by block and then interpret it on your own raw.

E

Data without an extra layer too right, yeah and it supports git transaction- it's really inefficient, but it.

D

Does support transaction the trace API does not the trace? Api only offers a new form of git block.

G

It goes in the latest code. It has like get right. There.

C

It is, it does recording actually relevant to this, but there's no index so the search.

E

Is all the blocks that looks pretty interesting, all right so for your birthday.

G

It's fine for the developer, um you know and if you're looking for reset transactions, it's fine but yeah, it's not it's not set up for um at it or production.

C

So is this: what am I trying to ask? um Is the recording piece of this actually directly relevant to the purpose of this node, or is it just? Are we really just saying a node that provides access to the trace API.

F

Yeah but you can't separate it so.

D

Okay, yeah I mean in real time it records like every block. It's recording data on disk of what happened in that block like very extensive information about what happened, and then the API component serves it out from what it records I.

C

See this is just a lack of knowledge on how that part works. So like inherently, if you're running the trace API it is, it is recording it's correct. Okay, there we go that's what I was missing. Okay, so yes, I, think Aaron's definition here makes uh makes sense. Okay, cool.

E

um I wrote another API endpoint. It is like the fireballs.

C

Yeah so too bad and I added a a I.

E

Mean it is an API type right, because you need to turn on the DM log, a big option and that it dumps log messages out at you right, bad Bill, doing anything with it. It just dumps it up for you to do something.

D

Getting the nodio's context, the deepmind logger is probably the layer one solution and then fire hose is the layer two that feeds off of it. I.

C

E

Right so that's all I can say you almost get into the extra theater.

E

What feeds Layer Two and it's Trace I had forgotten about these mind, although I'm getting more familiar with it and I consider State history, but those are all three core components of the no but really they're always designed to feed the chain data out in some manner that can be ingested.

C

All right, so it sounds like I'm missing a layer, one node type, which is State.

E

History, node right in my opinion, which is by far well most people I, would say, have used up to this point. It it's an inefficient baseball bat. But thank you. If you want to classify the usage right, you can say like Trace. Api is a few exchanges plus Aaron deepmind logger is es Nation. The name is the diffuse. Whatever right and State.

E

History is everybody else as a just subject to change yeah application, but at the moment that's kind of what the ecosystem and that's only because State history was really kind of the only I you want it. uh Neither trace or deepmind existed for the first three years. You know or I guess: deepmind did right. A few guys. Canada wrote that yeah all.

C

Right it is uh it's 9 59, so I'm we're not going to go into any of the other types right now. um I I did capture a few potential new things to get into next time: deepmind logger, node, State, history, node, history, capture, service, history, API node, maybe that's provider, node I, don't know.

E

And, to be honest, I think that's a good classification, because that's kind of the next level of conversation, the layer, two feeders and then getting into what all is used. But it's also a lot of custom packages. So.

C

All right with that, we'll we'll end this discussion for now and I'll hand it back to Daniel.

A

All right, thank you, Brian. Thank you. Everyone for the engaging conversation looking forward to getting more into the history and history feeders next week, um so until then see y'all then have a great week thanks Daniel thanks. Everyone thanks.

D

B