Hello, can you guys hear me? Can you guys give me some thumbs up? Can you guys hear me? Thank you.
All right, we're going to wait here for a friend, Richie to join, and then we will get started right at, right at 12 plus or minus.
All right, but she is on his way now. You'll start in about two, one, two, a minute here. But there he is. I think cat himself.
Hello, Richie. How's it going?
Okay, we'll wait another minute, but we will get started very very soon. Can you can you hear me okay, Richie? Anyway, I'm like a carpooled mess. I mean, yeah, it might just fine.
It's a bit long, but okay, that's just me, unfortunately. That's just, that's I'm just laughing. That's the problem.
All right, so we get started. Yes, okay. So yeah, let me just give like a quick intro to all of you guys. So obviously, if you're here already, many of you already know that what fire answers, but I'll give like the quick gist of it and richly can get
of a little bit more and then we'll talk a little bit about who we are and do a little bit of legal stuff. Let me just start off by saying fire answer is a new client for Salana built in collaboration with Salana Labs and the Salana Foundation built here at
that term crypto and it's almost entirely here in, built entirely in C. So targeting high performance, high reliability and, you know, as well as improving client diversity on Solana. So with that,
I kind of said who on our rich in I rich in our both engineers, you could probably touch a little bit more on that working on fire dancer and today we're going to probably, you know, we're going to largely stick to talking about the runtime, like I was mentioned in the rich in the post. But yeah, let me just quickly fire off a
quick disclaimer that anything that we have any opinions coming from me, Richie or anyone else who might speak today are not representations of jump or anyone associated at job boards, affiliates. It's all information
educational, and it's purely for entertainment and your education. So please, you know, this is not trading advice. We're not financial advisors, so talk to that person if you actually, you know, are thinking that, you know, what we talked about was really interesting.
But we are not financial advisors and make sure to do your own research. So that's that. So with that kind of out of the way, why don't we jump into, kind of, or I guess Richie, did you want to say anything about, like, you know, just give yourself a little intro?
That's fine. Thank you very much Liam. My first question is what exactly is the runtime? Do you want to give a quick interest in that? Sure. So the runtime is really inside of Salana, there are several big things. One of them is like how does data come in for other validators and other
and the network, there's stuff about how data gets out to other validators. That's kind of like turbine and all this stuff that you might have heard about before. But the runtime is really like how when new blocks or insulana really, how new slots when they're coming in, what do we do with them? How do we execute them?
And so that is really the whole intent of the runtime. So there's a few components there. There's the accounts database. There's the bank. And there are these things called the native programs. And there's the virtual machine that actually executes on chain programs or
So we can kind of start to dive into each one of those individually. But yeah, why don't we just start right now with the bank? Do you want to touch on some of that Richie? Yeah, thanks. So that might be the first one, but the runtime.
Basically, when you run a node, your current bank is going to be the latest state of the canonical chain. Because the blockchain can fall, that can also mean sometimes you have multiple of these banking states. But first simplicity, let's just only focus on one. This bank data structure will
all the implicit state of the chain such as which are the active validators and stakes as well as all the accounts in the database and this is kind of a neat separation where you can cross from runtime into consensus everything is going through a single identifier
called the bank hash which kind of commits to all of the accounts on the state and then can be used for consensus and for selection down the line. But without getting too technical, I think the three purposes of the bank in Salana are, it defines how you can apply new beats to the team.
you a bank has for your current state that you can use to check equality. And I think the way the bank has constructed is also quite different from other change such as Ethereum but more than later. And of course once you apply a blog, the bank is also going to create side effects which is right to different
accounts and special accounts called Sysvars. For example, if you have a block containing a token transaction that all goes through an interface called bank and then ends up in various other components which you'll cover later and at the end of the day they use it will then change into account after it goes through this bank process.
The major component, I think, the most interesting component in the back to me, actually not as several interesting components, but the accounts DB is kind of the most difficult technical component to come, I think. Of course, as the name implies, that contains all the accounts, the MD-Warner, maybe cover the accounts DB.
Sure, and actually before I jump right in that if you guys have questions, we're gonna try and leave some significant amount of time hopefully at the end to answer a few questions So if you do have one please leave it in the replies There should be a little button in a reply to the space. It should be a little button to do that
that little little Bob message problem. But yeah, let me talk a little about the accounts database. So the accounts, like the accounts database is this is quite straightforward when it's right in the name. It all it does is it takes the it contains all of the like accounts that they're most
It contains all the accounts and their associated metadata and the data itself. And the interesting thing about Salana's account database is it's got an intense, we'll talk a little bit about fire and answers in a little bit, but effectively what
they do is they have a slightly interesting customized database. And we can kind of get into that potentially, but basically
It gave us optimized for finding and fetching individual accounts and spread across a bunch of files. This has recently been in some of the recent Solana client work to reduce the number of actual open files they have to manage.
This kind of will hopefully we've done similar work and fired answer and again we'll get into that to actually reduce how many files have to be opened and how much memory is required to actually operate the account service because when you hear about Solana utilizing a lot of memory in many cases they're talking about
how the accounts database has this very specific cash income and that requires them. So then we have the native programs. So we talked about that before we continue on to them, sorry for interrupting. I quickly wanted to maybe compare the
So Lana comes database to other blockchain. I think that's really interesting. Both Solana and FireDancer is that pretty much all chains you look at use the general purpose database, such as Ellen DB, some even use like Postgres, Synormal SQL database.
or ROXDB. And while all of them have in common is they're not really optimized for the kind of rewrite patterns that a blockchain application has. One of them, for example, is the ability to go on deep forks when you, you know, commit a thousand transactions in a block and you know, you have to decide between two
4x which are each 3 blocks deep and now you have to potentially put 3000 transactions at a time. That's just something that RocksDB wouldn't be optimized for. So both Telana and Firelancer have made attempts at writing their own implementations. I think as Liam is a little too
And Solana is heavily reliant on Solana Labs rather heavily reliant on the Linux page cache. And that again is a generic general purpose algorithm. And when it doesn't work well, that means you require a lot of memory to keep the accounts database just to operate it.
To Lanhaps has made some really impressive strides in terms of increasing memory requirements, which is I think one of the most painful parts of running a valid data and fire dancer, which has almost completely purpose-built hash table-based database implementation.
I hope that we can see some significant reductions in memory there. So if I look silly for missing that said I'm not the engineer working on this component though. I hope we we have something cool to announce there very soon. Yeah, very sensibly interaction. Yeah, so.
I guess the next component of the runtime is really now we have this account database where we're storing all the metadata and data about the accounts. We've got the bank status structure where mutating the current head of the canonical state. The real question is that
And like, okay, well, now we have like a bunch of stuff we'd like to build a do on the blockchain. So like, really, what is that, what does that look like? And so, in order to do that, there's like a lot of these native programs that Salana has. And these native programs are kind of like doing fun
mental things within the actual validator point. So in particular, some of these data programs do things like consensus, like allowing people to vote on what is the current block that we should be finalized. What's the current block hash that
should be finalizing or things like managing the the stake for validators. So when you go in stake, so to a validator, you know, there's a native program that you execute on one side of that. And there's kind of like a whole bunch of other native programs as well, things like that you can like to
you know, do stuff to talk to the epoch schedule to talk to things like the internal clock that's being managed by all the validator set. And you know, the last really big one is like actually deploying and executing smart contracts itself.
or smart contracts or on-chain programs is actually its own native program as well. And so that kind of, we'll talk about in a few minutes what that actually means for fire to answer and how we're implementing those, but it kind of is a good segue.
having mentioned the points for our contracts to actually talk a little bit about the VM. I think some of the office set these native programs remind them of the exist because every one of them is really complicated in a different way.
complicated. It has very nuanced behavior. If you look at the code of the native programming right thing, well, I mean, it's, you know, it's a hundred lines. I can just plot that one by one. But the really annoying technical part about all of this is we have to be extremely determined.
like, you know, just deterministic and extremely compliant, which means, you know, if an attacker wants it to really have a fight answer and things that keep me up at night is what if we implement the most obscure edge case of a program from, for example, in the L-floater, which is
a pretty complex program, I think the program loader, whatever. If you align that data structure in the wrong way, one of them will pass it through, one of them will reject the input. You can exploit that pretty easily. And that's been actually happening in versions of Ethereum, I think,
There were some minor differences in the interpreter that could be used to mismatch two versions of GF against each other. By the way, don't need to call out GF in any way. This has happened to Solana also. I was just going to give an example, but anyway, I think that's why we consider them annoying and complicated because
because there has to go a lot of just very dry and almost academic proving of correctness of a program into it. And we've built a pretty decent security around that and we keep growing it. And so one of the important techniques in our repertoire
use to ensure correctness of these programs is differential fuzzing. I think that's been incredibly effective. So it's a really, you know, at a high level, really simple approach. You just take the Salana Labs implementation of one of these complex pieces and the FireDance one and then you just throw a lot of
So, you know, if you have some sort of, you know, heuristic that can sample things that elicits, you know, interesting behavior. There's some integration, the compiler that can maximize the amount of code coverage that you get through, throwing these random inputs at these programs. But anyway, so what we've seen is just after like,
tens of thousands of executions usually it would find one of these tiny edge cases where one bit is flipped but since everything has to be deterministic again it has to be one to one the same. So even a single bit flip in the execution between Salana Labs and FireDancer you know is something we need to desperately avoid.
And I think for now, our fastest has been running through literally billions of executions. We're going to deploy that on the large compute clusters at jump, which is I think, super exciting. So yeah, sorry for the technical round again. I keep getting correct into these. But one of the cool things we've also did
We've opened source the differential fuzzing infrastructure and really hope that when we can apply in here some of this tooling to bring this to other chains and just improve security of multi chain or sorry multi-client single chain operations in general. Okay. Yeah, let's talk about the BPF loader.
Let's talk about the VM a little bit. There's a lot of stuff that we realize we still need to talk about. It's just about how we implement all this stuff. Richie keeps teasing a little bit. Let me talk a little bit about the VM.
We'll call myself the principal engineer on the VM right now. So the virtual machine is the thing that's actually like executing a smart contract. So once like the native program responsible for deploying a smart contract actually deploys it and then someone comes along and places a transaction for example on open book or on radium or on
many of these other protocols on on on Solana, it actually has to be executed by the virtual machine. And in the case of and in the case of a. Solana, they use this thing called this.
this BM standard called DPS and in particular they've extended it to call it SPF. Or they call it SPF, we internally call it SPF. It's kind of a, it's an interesting choice of name that they have. We have chosen not to go with that name, but nonetheless,
What happens when an actual on-chain program comes into the VM, it's in this file form, it's called ELF. ELF is this very standardized format for organizing a program itself outside of just Salana.
And so Richie has built out this whole outloader. Again, that's really quite effective. It goes wrong. A lot of messy things will happen. Basically, programs will get executed right. Or there will be a discontinuity, a disconnect between what we think
state of the world is, first of all, the flannel lab is client and vice versa. Once you've loaded this elephant and you've reformatted everything and you've got it all sorted out, you now have pure SPF-like heard. What does that look like?
SPF, well I guess BPF originally stands for Berkeley packet filter, which is really kind of a terrible name. But what Berkeley packet filter is, is a device as a fast way to inside of the Linux operating
system, be able to do things like take incoming packets and filter them quite literally. So when things are coming in from the internet, you want to be able to decide whether this packet should go through the firewall or not, basically. And so BPF was devised.
BPS was devised for that exact purpose and it actually is a great fit for something like Splana because it's a really small virtual machine. Okay. And so because it's a really small virtual machine, it's actually quite easy to implement, but it's all these little edge cases that really have to be handled quite carefully. And so,
What's special about SBPF versus BPF? In particular, they have some extra features that normal BPF doesn't have, and those features can add a little bit of complexity. In particular, they also have a set
of what's called syscalls. So these are things that you can call out of the VM and go to other things. Okay. So that's kind of like a very, very quick overview of BPF and SPF. So what does the VM actually look like?
or how can you actually write some of these VMs? There's two ways. In particular, Slana has done both. One of them is you can use, you can interpret, so you just run each instruction individually as it exists. You can interpret the actual BPF code live or you
can what's called just in time compilates. You can turn your BKF code into code that you can just run directly on the hardware that you have right front of you. And so that there are kind of these two approaches. Fire to answer and we'll get into this a little bit. But like Fire to answer does right now is doing the former.
with the expectation that we'll do the latter as well. But we're really actually quite happy with the performance we're seeing from this interpreter. Again, we'll get into that a little bit more. Yeah, maybe, you know, does it make, Richie, should I get into the EDM versus SBPF stuff or do I miss anything with the VM?
Yeah, I mean, I think regarding the M since you mentioned the outloader, we can actually correctly load every deployed Solana programs so far. So that just means that you know, transforming the executable container file into bytecode ready for execution.
And I think, William, the interpreter, you made also executes all instructions fine. So we're pretty close. As you mentioned, it's called the native program, this take a while. And I think that's just due to the fact of the unique risks of unchained.
We, you know, that security program takes a while and I think at any time we get like, when FireDancer, when release, it's really hard to give an exact, the amount of them. But in terms of, you know, just throwing numbers around, I think probably like half of the programs are like dethrowering.
actions that are on actual maintenance can now be executed by the finance around time. But that doesn't mean that it makes sense to go to production. I think once we've got all the, you know, case that's covered out once we run a bounty program and have a bit of, you know, pen testing going on, test net.
We get much more confidence of actually running this stuff that we've produced so far. But certainly, I think we're progressing incredibly far. So also in a bunch of other milestones. But yeah, that's where you say I'm trying to. Yeah, you like EVM versus SBAF discussion. It's quite interesting.
think comes up about it. I know you've worked on both sides, right? Yes, yeah, I have. And I'm actually, yeah, so I've done a lot of thinking about this. And, and basically like so when you look at something like EVM, so EVM is what's used on Ethereum,
And many of the roll-ups like the ZK EVM on ZK Stink, Optimism, Arbitron, you name it, right? So there's all these other, there's all these other chains that are used, EVM. And when after having worked on both
virtual machines and various types. So both the SVM, the salon virtual machine, the Ethereum virtual machine, and its various incarnations. There's kind of a few fundamental differences that kind of after having worked on both, I realize now one is one is kind of not better, but one is a little
more efficient to execute. And in the sense, they are like what you could look at is, okay, so EVM has these 256-bit words, right? So whenever you have a piece of data in the EVM, it's always going to be 256-bit. That's 32 bytes. And that's kind of
So, you see this all over the place, right? And so, what does that mean?
What does that mean is that when you go and you actually execute a BFF instruction, it's like about, you could imagine it's like four times less expensive at times to execute versus 8 256 bitcoins.
you have, you know, you do the division, there's four 64 bit numbers inside of the turn to 56 but it doesn't really work out that way, but you can imagine it's a little bit more expensive. Now that's okay. There's reasons why the IBM has those turn to 56 but words. But also if you look at the
They also use a stack. They have a stack-based virtual machine versus a register file like the SPF for SVM users. What that means is that effectively, when you have this stack-based virtual machine, it means that every time you do an
you're removing or putting things onto this stack of items as opposed to in S/VM world where you have actually what's called a register file. You have 11 registers that you can put things into or read them from.
And why is that ladder one kind of a little bit more efficient? That ladder one is a little bit more efficient because when you store when you can actually map that to real hardware. So just like real computers, like the ones that are in your laptop that are in your phone, in the headphones that you're listening to this on are
all register file-based. So you could literally map, take an SVM program and kind of almost directs a map to real hardware and then run it that way. And the kind of the last big contrast there is the addressing. So in EVM world,
You have this huge amount of memory that you can access to, which makes certain operations really really easy. It's actually, it feels, it makes certain programming concepts
like you know very easy to implement. And that's really awesome. But in SVM world you have this really limited kind of well constrained space of memory that you can actually modify. And that refers to the
that memory is being addressed, but I think the actual addressable memory on both is fairly similar. They don't sell Anna might actually be cheaper, but the problem is, you know, your industry of memory range from 0 to 2 to the power of 256, which is more space than you ever have in a real
computer so therefore, Ethereum based data visit implementations have to do a lot of work to compress that into the actual space used. And I also want to, you know, I think a quick disclaimer with mentioning is that even though the SVM is technically more efficient
than the EVM on the interpreter/bycode level. That doesn't necessarily mean that it's currently the bottleneck. I mean, you know, better than the EM, but I think it could be argued that if you replace the Solana VM, so I mean, the only the byte could interpret the parts with the EVM and the architect
it right you could probably get to a single level of performance and that's due to the Solana database architecture just being much more you know close to real hardware whereas the theorem is much more you know theoretical I'm not even sure why the use of 256 bit registers and will provide addressing and was implemented
But I think it keeps them, you know, EVM engineer certainly makes it harder to, you know, achieve a good level of performance in my opinion. But again, I'm not an expert on this. Yeah, I tend to agree. Yeah, there's just like some kind of hard
just thought in decisions and even though the tallicus is kind of remarked on this as well that like, hey, there's then we'll come a day where he'd like to think about this problem then. And so, and that's not to say that there's nothing wrong with the Solon of the Solon of the M as well, but like that's why we have untimely two coming down the pipe from
that's for long a lap. So like, yeah, all these things are like constantly on the move and constantly changing. So there's all of that coming down the, coming down the pipe. So yeah, why don't we touch a little bit on kind of the, I don't think we really talked about it, but going back to the kind of the
account database and talk a little bit about what we have done over there. Do you want to talk a little bit about that, Richard? Yeah, sounds good. I'd like to start this from the protocol level, probably, before we type into the technical details. So the optimization with accounts updates that are alluded to
It's quite simple. So every other blockchain, I guess it kind of sucks that we keep comparing, but it's interesting for people who have existing background on these systems is that most blockchain is maintained a global mercury. So that means every single account, every single
balance is committed into a global data structure and due to the way that the cryptography in it, it's non-trivial to map that into database systems and usually that results in a lot of random accesses on your actual storage.
For NVMe, for example, these tend to be pretty good at random accesses, but if you use sequential addressing, you can go even faster. And that's what Salana is doing. So in Salana, it's not strictly a requirement to construct a global commitment over state.
Well, instead what Zalana does to be able to prove state transitions is they use a div-based data structure. So that means instead of committing every account at every block, Zalana just commits all of the accounts that have changed and there is some molecularized data structure.
It makes inclusion proofs a bit more interesting on Salana, but it really helps with maintaining a large throughput and a large amount of compared state accesses by removing some of the components that would force sequential access at some level.
sequential access, basically sequential dependencies, which would result in random accesses. So, sorry, and in one case I'm talking about execution, which is sequential dependent. In the other case, I'm talking about database accesses, which are random. All right.
Yeah, I think we covered the database architecture a bit. I'm not an expert on how exactly that is implemented in the file answer. Yeah, sure. I guess like so. Kind of we took this from a very
much like, okay, let's start at the very bottom. Let's understand the access pattern. How is it read from? When is it written to and what's being written and what is being read? It was pretty clear that this is a
It was pretty clear that the database would have to be some sort of hash table and that's effectively what we landed on. It is just a huge hash table that you can go in, you can basically read from it, you can write to it, and there's
a multi-versioning system so you can build up a whole commit, apply it, and even build a commit on top of another, build a transaction on top of another transaction into this database.
Although I am not the actual engineer on this, I worked with this database, this handcrafted purpose-built database on a daily basis. I am hoping that we get some really awesome GC details or blog post at some point from said engine
But yeah, it's really quite an impressive implementation. I will say. And I just wanted to mention again, if you guys are accumulating some questions in your head, please feel free to leave replies in to the space.
And or I guess you could probably also DM the fire and answer account if you do our question. So yeah, Richie, where should we go to next? I mean, that's a good thing for Craig, you know, that people come and
questions. I think we covered most of the interesting things. I also don't really want to bore people, but I just want to provide you with technical information. One thing I wanted to make is although Delana has had the luxury of not having to optimize on-chain programs as much, just by having enough compute capacity,
If we really strive to push for high performance, eventually I think that we'll also need collaboration with the community to optimize the programs. And ellipsis labs has done some great work specifically on Salana and while browsing repositories, I think the way they manage data structures in smart contracts is actually
So, we're drivingly similar to how we do it in FireDancer, just in terms of memory management and so on. Yeah. I don't see any questions, maybe I'm in the wrong account. That's like a few minutes, otherwise I think we can call it here.
So, yeah, but you did you want to give a little bit about the last milestone and just kind of. Oh, yeah, so I think in terms of milestones we've shipped, yeah, transaction just obviously that was kind of the old break point demo thing as well as high performance.
But since then, instead of doing milestones one by one, the team has grown to a point where a lot of these milestones are currently heavily in progress. Just trying to recall most of them obviously. The accounts database, a lot of the stuff that goes into runtime and replay.
Yeah, I think, yeah, do you know that you know the list of friends? Sorry, I'm a bit of a, so I know the list of what? Oh, yeah, so we've got what's going on right now? Well, we've got all sorts of things we just finished quick, which was a huge, which was a huge milestone that
you pushed through a richee with what was it? What were the numbers that we had? Yeah, I mean, you can find them in the finance account. The next one that we are probably going to release is going to be Turbine and ultra-affiscing rate Solomon.
And I think we're also starting to dive a bit into consensus because, you know, just by building the runtime components in the account database, implicitly since everything has to be forked well, we also already thinking about patterns for
You know voting services for selection potentially even remote signers that would make any promises there. So I think in short with with went from ultra focus on specific milestones to
a much more broad development approach that will get us quicker to being able to validate and replay Solana Mainhead as well as Pithnet. I'm excited and I think the cadence of the next Martins will improve.
I saw one question by seven layer thoughts are on adding more dedos resistance, violence and salano would generally think it's a really good question. So, um, yeah, I want to feel like another like, uh, uh, real
So a good way to handle DDoS is of course just handle more traffic, right? If someone throws a gigabit of spam at you and you're not prepared to handle it because you're climbing up the stairs.
usually runs lower, that could record your system. Whereas if you always strive for the highest performance, then that doesn't really make a difference if you, for example, can handle 10 gig. But obviously at some point hardware will be the limiting factor. So we've also looked into the network protocols without any specific
details to panofuse the network infrastructure itself to be more resistant against the NALO service and we are working in Salada Labs with kind of like Sada and on joint pan testing and just security research programs and I already found a couple interesting issues I think
It also connects to the next point of, no, the kind of underappreciated things about the file answer program is even though we haven't released a note yet. The research that we're doing I think will be useful for some other labs just to have more data points. And I think especially also on the security side.
We've already reported a few like low to medium severity, you know, issues. This is a good thing, right? Because otherwise they would have been unpatched and think the best way to generally audit a code base is to it right. And that's exactly what we're doing. It's probably going to be the most thorough audit that this a lot of protocol gets.
Thank you all my side. I can't do anything.
So before we cap off here and kind of just come in and close the bar. So before we kind of cap off here and kind of finish some final reflections, I just kind of wanted to touch on one of the things that I wanted to do.
I'm just going to leave the swings. There we go. So I just kind of wanted to touch on one final thing here that like a big part of the runtime development has been just hey, there's like a lot of, you know, most of the work is literally just hey, we have a black hash and this being
the block and almost all of it comes down to. We need to just make those two match for any case, for any possible scenario that will ever occur on Maynet, on Salana, and our client. And so you could imagine that's quite a
painful effort, but it's quite rewarding when two numbers start lining up for a huge series of blocks when we're running and testing. Really, it comes down to a lot of that. Even with the VM, it's like, okay, we ran a transaction. Does everything, is all the state match? Is everything match? There's a lot of that.
And I think the last, the other thing that I had and maybe Richard, you have some other stuff is like basically there's been a lot of hashing algorithms. There's not a signing algorithms. There's been a lot of kind of a numerous, as I said earlier, a numerations about every way you could possibly construct a
that has to be, you know, that's been, you know, if it can be done, it will be done in Salon. And so, you know, so, you know, there's been just kind of like a lot of that. It's kind of fun to kind of go and re-enplement some of those things, but I'm curious if you have any last thoughts for a few about some of the runtime. Now I think, yeah,#
It's called it day for year. Yeah, appreciate all dialing in and listening to our technical gibberish. I'm really used to these spaces, so I hope you could follow them. And if it wasn't, it wasn't good. I'll let us know and we'll try to be the next time. Emis, it was fun. Thank you all for tuning in.