Quasar vs Pinocchio [Solana Tutorial] - Apr 28th '26

本站添加: 2026-05-13

[00:00:00]Ever since I made that video on Quasar, people are asking me, "What's the difference between Pinocchio and Quasar?"

[00:00:08]Hello and welcome to another Solana tutorial. Today, we're going to talk about the differences between Pinocchio and Quasar cuz they're both Solana programming frameworks and they both focus on efficiency in terms of compute usage and in terms of compiled binary size. So, what's the difference? When do you want to use which one? Or is one clearly better than the other? Those are questions I want to answer today. So, what I'm going to do is I'm going to write programs that do the same thing once in Pinocchio and once in Quasar.

[00:00:38]And then we compare. And hopefully that way we can figure out where the differences really lie. Here's what we know already. Pinocchio has been around for longer. It hasn't been there from the beginning. It's an improvement over the Solana program SDK. Quasar was developed while Pinocchio was still around. So, you can assume that Quasar is adding something that Pinocchio didn't have. Otherwise, they wouldn't have developed it as a separate framework. So, clearly in one way Quasar must be better than Pinocchio. And I think that it's just more efficient. And I don't know how much Pinocchio is using zero copy. Maybe there's a difference.

[00:01:14]But yeah, my assumption would be that Quasar is the more efficient one. And another thing we can note about Pinocchio is that it has been battle tested. I mean, P token was developed using Pinocchio. And P token will replace the token program, which is basically the most important program on Solana after system program. You can watch my video on P token here. So, yeah, Pinocchio has been audited. Quasar hasn't. So, in that sense, Pinocchio is safe to use where Quasar is more like use at your own risk. But I do think that Quasar is the more efficient one. I have no idea. I haven't tested it yet.

[00:01:52]And I have been wrong before. I mean, watch my previous video. So, who knows?

[00:01:57]But let's figure it out. Let's actually compare Pinocchio and Quasar. Here we go. Let's do a Pinocchio bench and the Quasar bench. So, we'll do cargo in it a lip and cargo at Pinocchio. No account resizing, no CPIs. So, we're in Pinocchio 0.11.1. And I already forgot how Quasar works. Quasar in it. So, the other one, Quasar in it. Quasar bench.

[00:02:22]Yeah, let's do a full template. Let's go. Good. So, those are our two projects. I'm going to open them individually. I'm going to start with a simple Pinocchio program, no logging.

[00:02:32]Okay. The first thing we're going to do is an empty program. That's going to be our first benchmark. Just return. We don't do anything in our custom program logic. We just do the things that the entry point does. Not going to be using any of it. Let's see. I need to, of course, Okay. Let's see if we can build this. We can. Cool. This guy already gave me a full program, which I will use later. So, we already see the first big difference here. Quasar is way more Anchor-like than Pinocchio. So, Quasar maybe adds this user-friendliness aspect because we're again working with this context.

[00:03:18]We can write the instructions like this, and it's already difficult to have a program with no instructions. I mean, that would look like this, right? We just don't have instructions. But then, there's nothing that we can call, and it doesn't allow fallbacks, probably. So, it already seems difficult to write a Quasar program that does nothing, which is a good thing cuz user-friendliness.

[00:03:45]It's a question of what do you need?

[00:03:47]What do you want? So, it would also be fun to compare that with Anchor, and more specifically with anchor inversion two, but also that is not that officially released. It may be in a different video. Today we just want to see the differences between Quasar and Pinocchio. Let's see with that build.

[00:04:04]Can I have no instructions? I guess not.

[00:04:08]It's red. Program rules expect All discriminators in a program must have the same byte length. No duplicates. But it doesn't seem to allow me to do zero length discriminators because then I would only have one instruction and that's not what it supports. Therefore, I guess we got to do an instruction even if it's a do nothing that does nothing like the initialize does but without accounts. So I'm just going to put this here a context for doing nothing with no accounts. Interesting. So it would expect discriminator zero.

[00:04:41]This way now hopefully this compiles.

[00:04:43]There we go. 1.7 kilobytes. That's a fairly decently small program compared with Pinocchio where we have 3 kilobytes for a program that looks like this that's supposed to do nothing. But yeah, that all comes from the entry point. So I'm actually curious now like which program is going to be more efficient in doing nothing. I'm going to get you keys. One for Pinocchio Pin V and one for Quasar Quasar 7 and then one for myself.

[00:05:17]Andy. Wow, I should keep that for when I do something with CK proofs. And we're going to set this as my key pair. I drop myself some SOL using the faucet. Cool.

[00:05:28]So let's Solana program deploy the Pinocchio program to the address that I wanted. Pinocchio program deployed and then same thing here. In Quasar I also need to tell it what the program address of itself is. So I got to rebuild this and then I can Quasar deploy. There we go. Both programs are deployed. Let's call them. Going to use yet another instance here. We're going to say we have our Pinocchio program and and we're going to do for each program I could call it program address. For each program we create this instruction and then we create a transaction, sign it, send it. I can't await in for each. Or can I async for each this? Yeah, cool I can. So that should just send two transactions. Maybe we should send and confirm. There we go. We send and confirm and then print the signature.

[00:06:17]Okay, let's see. Can I call both programs?

[00:06:21]Yes, I can. Look at that. For one Pinocchio which consumed four compute units. Wow, I don't think it can be any more efficient than that actually. Four compute units? It did essentially nothing. Nothing at all. Like completely nothing. Even though I'm using the regular entry point, not even the lazy entry point. But I have no accounts. So, yeah. Four compute units. Damn. Wow.

[00:06:50]Instruction one, four compute units.

[00:06:53]Holy [ __ ] Compare with our Quasar program which took six compute Wow, that's also crazy. Six compute units.

[00:07:03]That's also nothing essentially. Wow.

[00:07:07]And the explorer is being annoying.

[00:07:08]Jonas, can you fix that or can you find out why that is? That would be cool.

[00:07:13]Otherwise, I will go and attempt to fix that. Maybe in a future video. Okay. So they're both pretty good if I don't give them anything. That's basically no difference. Maybe Quasar checks if there's an instruction or whatever, but like wow. I'm impressed by how efficiently they both do nothing. Cuz if I would do an anchor program that does the same thing, then it would be like a thousand compute units. Anyway, okay, cool. Whatever. Let's give them something to work with. Let's see what happens if I add accounts. Where did I do the thing with get random accounts?

[00:07:48]When we talked about SIMD 296 with a larger transaction sizes, and there's the video. I got those nice functions to get random accounts and data. Going to use that again to get 10 random accounts. There. So, we just put in random addresses as read-only accounts.

[00:08:06]Let's see what that changes. Call both programs again and compare. So, we see some random accounts. This time Quasar transaction was faster. I'm doing async execution, so whatever. We're looking at this first. And Quasar again used six compute units. It ignored all of the accounts as it should. Wonderful. And also, it didn't seem to bother. It could get to the instruction data to figure out what instruction it was with those six compute units.

[00:08:36]And it jumped over all the accounts.

[00:08:39]Great. How about if Pinocchio do? I would expect similar results. No.

[00:08:44]Pinocchio actually does something for each account. We have 84 compute units now. But this is with a normal entry point. I could do a lazy entry point.

[00:08:55]Then it would look like this. There we go, with the right imports. Build again.

[00:08:59]This time it only has 1.3 kilobytes. So, now this is even smaller than the Quasar one. And if we deploy this, I'm going to add some logging of program address.

[00:09:11]Just so I know which program I'm calling. So, we have Quasar and Pinocchio. This is the one I'm interested in now. With the lazy entry point, Pinocchio would use two compute units.

[00:09:24]It's doing legit nothing.

[00:09:28]Yeah, I'm recognizing that you called me. Goodbye. Like, I mean, it doesn't get more efficient than that, does it?

[00:09:35]So, that's interesting. Okay. we can also make Pinocchio ignore the accounts and instruction data. Okay, but what if I want to do something? What if I want to change something in an account or initialize an account? Let's do something. Discriminator one. And admittedly, it's a bit unfair to compare this because we would need to really do the same checks as well for the accounts. And here's the thing. Now, either I do state like this and then it also checks the account with that discriminator or I do an unchecked account with no validation. Quasar has a Pinocchio vault example and an anchor vault and an upstream vault and a vault.

[00:10:15]Is that to compare different frameworks?

[00:10:18]Maybe I should look at that. Vault unchecked account. So, you don't do any lifetime for this. Okay, just an unchecked account. Okay, so that's how you do it. And then in the do something, this account, what can I do with you?

[00:10:30]Doesn't seem like I can do much with this account. And all the zero copy logic only comes in if I actually use state like this. So, let's use that. In the do something, let's use a my account cuz then I can access this value, which is a pod U64. Watch my alignment video if you don't know what that is. And I can set it to a new value, classic counter, and then we did something. But for that to work, we will need an initialize that has payer system program and the account. How do we do an initialize? Payers payer, maybe I need to say that. Nope, you're in general unhappy. Why do you have lifetimes? You don't seem to need this. No lifetimes.

[00:11:09]There you go. Screw lifetimes. Will it build? Okay, that's for Quasar. If you wanted to do the same thing with Pinocchio, should have vibe coded this.

[00:11:17]Let's quickly vibe code this.

[00:11:20]Boop. Okay, here's Quasar's idea. It'll take the next account and it will get the program ID, which it is at the very end. Then it will check, as I told it, that we have that program ID because Quasar is doing the same. If I have something like this or here something like this, then it does check that account is owned by the program and in general it's good to have owner checks.

[00:11:42]So, I'll let you do an owner check. Then we get the data, we check the discriminator, we check that we have enough data and then we add one. Sounds safe. Let's go. Let me check if it builds. It does build. You can go again.

[00:11:56]Okay, so let's redeploy this and redeploy this. And then we need to call them, but this time we need to add logic for initialization. So, let's do init instructions for Quasar. We said it's instruction number 10 just because I wrote discriminator 10 here that it calls to initialize and the initialize will do the rest with this init and it will do a CPI to the system program and the accounts it needs is number one, the payer, number two, the system program, which I will need to import soon anyway.

[00:12:31]Here I can get the system program. There we go. So, system program role read only. And then the actual account. And this one, well, let's get two accounts.

[00:12:42]Get a key pair signer for you and a key pair signer for you. Get that Quasar account address here and then I will need to add signer to instruction. This Quasar account is actually needs to be a writable signer then. I could add the payer here as well as a signer, but this one will be a signer because of the fee paying anyway, so it's not so important.

[00:13:04]So, this to this. There we go. That's what that looks like. That's the initialize instruction for Quasar. And I can in the same transaction also do the initialize for Pinocchio where I get create account instruction from the system program. So, I'll manually create it because Pinocchio doesn't have this need in it where it has a CPI so I just create an account with discriminator zero, which is not how you should do it, but such that it's being treated the same, I'm going to say it has discriminator zero because that's the default. Anyway, so new account will be the Pinocchio account, payer will be the payer, program address, so that's the owning program, that will be my Pinocchio program. I should make constants for that. Space, let's say two bytes. Or what did we say with the other one? Oh, with the other one I actually used the U64, which makes it more complicated. So, to have a fair comparison, let's just do a U8 here as well. And then I just use two bytes also for Pinocchio because it doesn't need more. And Lamports, doesn't really matter, but let's do it correctly.

[00:14:15]Cool. That should initialize those two accounts. And once that's confirmed, we can call both of the programs again, this time with discriminator one, although I'm not checking that in Pinocchio anyway. And then with specific accounts, oh [ __ ] now I also need the specific accounts for uh well, that's what you get, double arrays. So, we'll do program address and data accounts.

[00:14:41]There we go. That's how we do it for each program with the account, and then we get the data account, which we can put in here as the only account writable. You think that's going to work? I don't think so. I'm pretty sure I made a mistake somewhere, but let's try. Call both programs with init. Does init work? Init does work. All of that works. Look. So, the init transaction created those two accounts, which take the same rent, have the same size, just that the one for Quasar already has something written there because that does a proper init. That's also why it takes the majority of compute units here with a thousand something. I don't know why that's so expensive doing the init with a system program, But, that's fine.

[00:15:23]That's not what we're comparing. The other one is just a system program instruction with 150. That's just default. This is not reflecting actual compute usage. It's just any system program instruction will have that. Fun fact. And then for the actual transactions, let's check Quasar first.

[00:15:41]Quasar takes this account and modifies this account with 57 compute units. 57. And the result is that the counter is up to one. Great.

[00:15:55]Pinocchio needed 43 compute units and also put that counter up to one. We ignored that discriminator.

[00:16:04]Discriminator, it's not a discriminator.

[00:16:06]It's just a byte that we check for zero.

[00:16:08]So, Pinocchio was slightly more efficient in that, but that's not really a fair comparison because I'm just doing the most basic checks and Quasar probably does more checks on that account. So, we can just take this as a baseline. And it has to check the discriminator as well to do the right instruction. And so, it's like it's not a direct comparison. So, that doesn't mean anything. They're both super efficient in doing that. But, let's see if anything changes if I have bigger accounts. What if here I don't just have this one byte, but I have a bunch of bytes. Let's say I have 99 bytes of padding. Or let's say 999 bytes. I can afford that. So, that's byte number 1,001 because we also have one byte for the discriminator. That's for Quasar. And for Pinocchio, we just change that number and that number. And then we build and deploy. Now, we also need to change our calling script.

[00:17:09]Actually, for Quasar, it should be nothing should change. And for Pinocchio, we just need to say we need more bytes. And then all of that should also work. No, doesn't work. Simulation failed. Oh, wait, did I only change one number? I only changed one number.

[00:17:24]There, we also need to change this.

[00:17:26]Yeah, well, that's cuz that's the same.

[00:17:28]So, try again. That's why I use constants. There you go, now it works.

[00:17:32]500. [snorts] Quasar, again nothing super special here. And again, 57 compute units, that did not change a single thing, which is nice. That's a good thing to note. It doesn't matter how much padding is in that account, just ignore that.

[00:17:47]Pinocchio, also, again 43, also ignores the size of the account. We're just writing to that one byte. We are not deserializing anything, especially not that padding. Okay, so that doesn't change anything, and I think that's enough for me to come to a conclusion here. Because once again, I was wrong.

[00:18:07]Quasar isn't more efficient than Pinocchio, neither is it trying to be.

[00:18:13]Quasar is more developer-friendly than Pinocchio. They're aiming for being able to write programs quickly and easily, like you would with Anchor, but still keeping that high efficiency that you're used from Pinocchio. With Pinocchio, you still have more control because you can design everything yourself, but it also means that you need to design everything yourself, and that's just more difficult than if you have this nice layout that we're used to from Anchor that Quasar brings to the table, while still supporting zero copy per default. And I hope with this video it's now more clear to you what the real difference is between those two frameworks are. One is focusing purely on efficiency, and the other one is mainly focusing on dev X, while trying to stay as efficient as Pinocchio. I'm glad I made that video because doing so made that obvious for me. Just by looking at this, it's very clear what the main differences are. This is more like what you're used to from the Solana SDK, and this is more what you're used to from Anchor, but both of them are using zero copy, and I just way more efficient. And I think that's good enough for me. If you want to dig deeper, I can recommend that you check out those examples in the Quasar repository, where there's a vault implementation with Quasar, and there's also Pinocchio and Anchor implementations of the same program, so that you can compare them. It's pretty simple programs. And also what we can see here in Pinocchio is just more code and more complicated-looking code. But therefore, it's potentially more efficient. Actually, should we look at that? No, I'll leave that as homework for you. If you're really interested, try it out yourself. Don't worry, I'll do everything for you. Still not your mom. Do your homework. Okay, good. Let's conclude. So, my conclusion is it depends on what you want to do. I actually really like Quasar for building a quick program. We saw with Pinocchio, it's way more effort because we need to do more low-level programming. Low-level in the sense of Quasar just abstracts more away, which brings us on a higher level, where we think about instructions and accounts. Whereas with Pinocchio, we think about instruction data and account data, and the owner field. Yeah, it's lower level. We need to implement the owner checks ourselves. We need to implement the signer checks ourselves.

[00:20:44]It's easier to get stuff wrong. But therefore, you have full control and you can do whatever you want. With Quasar, if you're like, "Oh, what I would like a program that doesn't check for any discriminator?" That's just not what it's made for, and therefore, it's difficult to do that, or pretty much impossible. So, yeah, it depends on what you want to do. Write a quick program that is efficient, use Quasar. Go really on the byte level optimizations, use Pinocchio. Also, as I said in the beginning, Pinocchio is battle tested, Quasar's still in beta and not audited, so use at your own risk. And it's going to be interesting how Quasar compares to Anchor in version two, cuz Anchor in version two will also bring a lot of optimizations and is built on Pinocchio.

[00:21:36]So, we will see how those two compare.

[00:21:39]Maybe that's the more interesting comparison video that we should do, Quasar versus Anchor in version two.

[00:21:47]But, that's a video for another time.

[00:21:50]Until then, you can watch those. Maybe you're living in a future where I already made that video and it might be here. Give this one a like if you enjoyed it. Subscribe if you have not done that already. Thank you for watching. I'll see you in the next video. Let me know if I should compare Quasar and Anchor. I might do that.