Kick out the EVM: How we hit 42 million payments/s on a purpose-built L2

Transcript

[music] [music] Hello folks. So I'm Mad Gupta. I'm the CTO at Polygon Labs and today we'll be talking about scaling blockchains. So I'll talk about like how you can scale the blockchains. I'll talk about what we did uh to achieve the scale of 42 million payments per second. uh what are the trade-offs and and so on. So first uh like why the number 42 million payments per second few reasons number one 42 is the answer to everything. So that and also too so uh folks over at uh

another blockchain company did their whole presentation with confetti and so on because they hit 41 million so I was like okay I'll do 42 then uh but in reality the benchmarks I ran came uh out to be 45 million transactions per second payments per second which is uh even more interesting and the best thing about the architecture is that it scales linearly. This is just an arbitrary number that I decided to benchmark at. Uh the hardest part is generating the load. Imagine generating 45 million transactions every second to send uh to the server. Like it's it's not easy.

That was the hardest part. Um it scales linearly which means I can just add another server and I'll have more throughput. So I did the benchmark at one device, at 11, at 25, um, at 100 and it just scales linearly like it's almost perfectly linear and if you need more throughput, you can just add more servers, you will have more throughput. How can we achieve this? That's the hardest question because it it breaks a lot of assumptions in blockchains. Uh, and the only way to get to this was to specialize. So what we uh like first let's talk about why this scale where this can be useful an example is like if

you want every API call to be a payment rather than billing people at the end of the month what if like you want to use something like x42 to charge the person just at the time of the call this would let AI agents very freely pay for things and this is like the future of agentic payments that agents just pay for what they need when they need um rather than worrying about signing up for postpaid billing, providing their details, ID and and so on. Like I just I make a call to the server, I pay for it, I'm done. Um and for that you need scale. So Cloudflare for example um has basically said on a podcast that the moment they want to enable this they are going to

offer this um like X42 over u to their customers they were just blocked by scale they couldn't find anyone doing 10 million TPS which is the bare minimum they need um so they were blocked by this um obviously like I heard that we built this and it it's it's so much better than what uh they were imagining and so uh uh they will release something like this very soon basically more or less the same thing but they'll base on base because they have an partnership there but uh basically the same thing it's it's it's it's the architect the this architecture is the future um and I'll talk about why that is the case so first like how the architecture

architecture actually works the agent sends requests to facilitator uh the facil export to facil forwards it to the hub and the payment is done. Um this takes 20 microsconds in the benchmark like across multiple machines. It was not a local thing. Um 20 microsconds it's like you you take uh you can blink multiple times like hundreds of times in this. Um so it's like you can blink 100 times uh and the payment uh like in in the time the payment takes the settlement is batched so you don't uh the costs are super low uh mentioned briefly before but the costs are for this as low as $0.15 per billion transactions. So like it's

zero essentially zero. It's just the hardware server cost. It's you you can for all practical purposes zero cost free transaction you can have as many as you want. Um so how we got there is by deletion. So we like I started looking the whole stack of payments and blockchains from ground up and basically said like I I don't need any of these like we we should just keep the bare minimum stuff that we actually need um and kick out rest of the things that are the bottlenecks. So uh the first thing to basically understand is like this is specialized for payments. this stack pay channels does nothing but payments like

it cannot do D5 for you it's not built for that it's not a generalpurpose EVM and not making it general purpose is how I was able to achieve the skill so the first thing I did was to kick out EVM itself that's the that's the biggest thing the interpreter gas measuring global state uh state roots like like everything's gone the everything that consume time it's gone it it only uh has what the payments need and we also minimized what every payment needs um to [clears throat] basically get to the scale to get into more details um like the first thing to unblock uh like if you want high throughput you basically

have to make sure nothing wait in line uh there is no queue if you're processing things serially if you're processing things in or in order if you're processing things by a nons that nons three must come uh before nons 4 you will never hit this level of scale you will never have parallelism at this level of scale so we got rid of global ordering there is no transaction order ordering here um you can it's just data the transaction can be like the uh first transaction or the last transaction it would not matter the end state would be the same this is not possible in a general purpose EVM but how did we do it so for payments what did was we created

state by uh payer merchant uh payer in the sense that the state is stored as let's say there is Alice Bob um and Charlie in the system if Alice pays Bob $10 first transaction Alice signs is $10 to Bob uh now Alice wants to pay $20 more to uh Bob so Alice will not sign $20 to Bob Alice will sign $30 to Bob. Why? 10 + 20. It's the cumulative amount. So, what does this do for you?

It eliminates the need of ordering the transaction. It does not matter if the $10 transaction comes first or the $30 transaction comes first. The end state will always be $30. And that that's the like it's it just eliminates ordering. You can get transactions in whatever order, process them first come, first serve. uh you you don't need to batch them into blocks. You don't need to have consensus over what goes next. You don't need to have a mempool that orders transaction by gas pricing. You don't need gas metering. It just gets rid of rid of so many things. So it it's a big advantage that you just kick out ordering. You kick out all cues. You

have maximal parallelism. Whatever comes in gets processed. The end state is consistent. It does not matter which order things came in. There are no global order. There is no blocks. There are no mempools. There are no nons. Anyone who has worked on Ethereum or any blockchain development, they know like managing nons especially for high throughput things is a nightmare. Like there are it's just really a nightmare if you have built anything uh with high throughput. We we got rid all of that. There is no gas payment per uh transaction. All of that is gone. that that's how we achieve maximal parallelism. Um and it's very helpful in scaling. Um while we were at it, we

kicked out a bunch more things. So like uh people did something similar earlier in the times with payment channels. Um I call our product pay channels as well because people understand it but it's more of an specialized L2. So the biggest limiting factor of channels was that it's a short time thing. a bunch of parties need to coordinate together to open something. They need to u like have some trust and and they need to close it to get payments and so on. Here none of that. It's essentially like a specialized L2. There is a hub. There is a sequencer that is always online.

Anyone can use it anytime and it just works. So, uh there's no re there's no need to open channels, close channel and so on. All of that is simplified. U wallet pop-ups we replace by session keys. A wallet can just delegate a session key of any cryptography type uh to basically do transactions on their behalf. So a user doesn't need to like open wallet click there enter their password to make sense. It just helps with u with crypto uh with UX a lot. Um we also made the crypto swappable to be ready for the uh for the uh quantum computing future like right now uh ECDSA

curve and so on are not safe by quantum uh computing but there are quantum safe uh crypto techniques. So here we with our specialized architecture because it's an isolated component the signature verification you can swap out at any time with a uh with a component which is quantum safe and you'll be fine. So it's uh it's it's very uh very modular that way. We kicked out public state as well like we realized payments don't need a public state. Uh it's private by default. um it's can be made public because like if if I want to make my private state public I can always make it public but it's not public by default it's private by default and then uh made public by choice.

Um the main thing when building any system in the blockchain space is don't trust verify. So what did we do about security? What were the security trade-offs we had to do to reach the scale of hundreds of millions of payments per second? The short answer is almost no trade-offs. But there are things uh worth knowing. So in the cheapest form uh of this where you are only paying 0.15 per billion transactions um the security is um is sort of like deviant based in layer zero. That is like you have a bunch of verifiers. You can have three, you can have five, you can have 11, whatever you feel comfortable with. That will verify

each and every payment and uh sign off on it and only then would it be uh deemed valid and will be withdrawable on on the on the chain. So this level of security is the practically right choice for most applications. It's practically secure. It's all it also the good thing about this is it lets third parties be sure that their payments are safe. For example, if um let's say Visa comes to us and says I want to do a billion transactions per second here but I cannot trust if the validator run by you and Mastercard is safe. What can I do?

You can run a validator as well and we'll make it a mandatory validator. Now a transaction will only go through when Visa themselves are verifying that it is true. So it means that uh no one needs to trust someone else. They can just join the verifier queue and uh they would have trust that if they are right then the thing is right. They don't need to delegate trust on anyone else. The operator cannot steal funds in this. It's verified by the smart contracts that the signatures are valid and the verifiers have also ver verified it. You can always withdraw as well. Uh there is like you can always withdraw at the chain level. Uh it's an L2. So it's an L2 to Polygon. You can always withdraw funds directly from Polygon. If for

whatever reason the operator of this specialized L2, whoever it might be is trying to censor you, you can rage quit. You can run away. You can do your transaction on Polygon and be safe. Uh if you want even more security, you can add ZK proofs to it. So we benchmarked some of it. Um they are real they're still very cheap. They're more expensive than not having ZK proofs. Um if you assume like so ZK proofs are verified per pair merchant pair in this because as I said in our architecture it doesn't matter like what transactions you are doing between a pair only the last one only the final one because it's a

cumulative amount is the one that matters. So we only need to generate the zk proof for the final transaction. uh if I assume there are thousand transactions done in this you come to a cost of $3 per billion transactions which is again next to zero um if you assume that uh every merchant pair is a unique transaction then it would be about uh it would be $3 per million transaction not billion but $3 per million transactions is almost zero as well and this is already possible with ZK it's only going to get better um to put things in context like every credit card payment has a minimum of like 20

cents 30 cents we are doing a million transactions in in that amount almost u so yeah very cheap even if you add zk once you add zk you don't need verifiers although you can add verifiers as well this would all be verified by the chain to be correct and the security will be of the polygon validators uh and the cryptography employed by zk Okay. Uh not buy a bunch of verifiers even though verifiers are practically secure. Uh so the lessons here is stop making every workload look alike. Try to specialize. Uh we specialize for payments. This is why we hit the scale.

You cannot do DeFi on this. That's the limiting factor. But that's not what it built for. So look at your application and decide what you are actually doing and if you can specialize for that workload to get advantage uh of it. So another example of an application that did this very well is lighter. It specialized their ZQ rollup for um for just uh a per exchange. It has custom circuits. It has no VM. Uh every trade step is proven. It's it it's much more complex than what we have. So, it's harder to explain and understand, but it's the same idea. It's it's a specialized uh rollup specialized for trading and it does a phenomenal job at

it. Like out of all per exchanges, it is the one to look at for at least on the technical side. I don't know the other aspects. um Hyperlquid might have a lead in metrics and other aspects but just technically speaking from an engineers perspective lighter is the best one out there. So huge shout out to those folks. Um now you nothing comes without trade-offs. You have to uh choose what you want and you have to give up things and only then you can specialize. So with what we did we went for high throughput zero fees we got privacy uh we can add compliance there the operators and verifier can add u like uh compliance checks and so on we had

modular crypto and so on uh what we give up was uh synchronous composibility in this in other words D5 you cannot do D5 on pay channels like you have to uh withdraw the funds first only then you can put them in a you can't do a while you are within pay channels. Um we gave up operator livveness in the it's a minor thing because it's like almost every L2 has this issue um including arbitum optimism base that if the sequencer goes down you can't do transactions directly on the L2. This is the same thing with our model. If our sequencer goes down you will not be able to do transactions directly but we added a rage quit feature. So even if we are

down, you can get your funds, move out and be happy. And this is much better protection for our use case because in our chain there is no defy where you can be liquidated and things like that. It's just money that you can transfer around. If you can withdraw your funds, then it's as good as like there's no harm, there's no loss. You just withdraw your funds, you deposit elsewhere, you make transfers elsewhere, and you're still fine. So general purpose versus specialized uh it's small comparison table general purpose obviously you can run any program specialized it's built for one purpose and only that purpose if you change your mind later it would be very hard to change your product so only

build this when you are very sure what you want to do ordering uh is global in general purpose EVM in specialized essentially there is no ordering uh per hub is basically the servers we are adding ing uh the servers need to um like basically order within themselves when they post the proof but um there is no global ordering it's all maximal parallelism uh for confirmations it's for blockchains it's per block that's the fastest you will only get the confirmation right now it's the fastest actually I have something we are building at polygon where you can get confirmation even before a block is created but ignoring that the general consensus is that you get transaction confirmation when the block is mined can

be a fraction of second but it's that uh with our specialized thing you have almost instant confirmation as soon as the hub says I got your transaction that's it it's finalized there's no roll back there is no um like reorgge there's nothing like that because there doesn't need to be there is no ordering change that needs to happen uh ever because there is no ordering it's like as soon as your transaction enters the system it's done it's finalized it's happening um it scales linearly. Uh this is the biggest advantage of this architecture um that I can just add more and more and more servers and I can scale my throughput more and more and more. Uh with blockchains you the more validators you are add the slower you will get.

It's the opposite. Uh cost for payment obviously a big difference that's why we build this uh crypto in general purpose even chains mostly it's fixed although you can do heavy uh changes to swap this. We built this ground up as a modular thing where you can swap the crypto protocol at any moment and be quantum safe for example. So basically what's the learning the one learning you you should take away is basically kick out what you don't need and this applies across the software industry. Doesn't matter if you are building a blockchain or a simple computer program. Like if you care about performance, if you care about minimizing your attack surface, if you

care about simplicity, if you just care about general hygiene, kick out everything you don't need. Uh don't build things that you don't need. Keep it simple. You will build faster software. You will build safer software. And it's the way forward. So now we'll do some Q&As's. Uh let's see if anyone has any questions about scalability, about polygon, about anything else. Okay, thank you Mund. Uh let's take some questions.

So the first question is beyond TPS, uh what still makes blockchain payments harder than traditional banking systems? >> Yeah, for sure. So uh banking system is like so for payments in general it's all about the reach basically like if I want to pay you and you do not accept my blockchain or my bank uh payment method or whatever then it's pointless like I it's like both people both parties need to agree uh the medium they want to receive funds this is the whole purpose Visa and Mastercard is so big because the merchant and the payer both agree to use Visa or Mastercard. Um, so this is

the hardest part for blockchain still like you as the consumer might want to pay with blockchains but the receiver might not accept it. So we need to uh spread awareness around that as well. We need both parties to be accepting blockchains. Okay. So the next question I think you addressed this uh towards the end uh can the confirmation of a payment succeed and then it's not settled because of low balance. So it can never um happen if um [snorts] so it really depends on um basically like the confirmation initial confirmation that is happening by the hub. uh if you trust the hub and the

verifier it will you will only get the confirmation when there is enough balance. There will never be a scenario where there is not enough balance um at the time of settlement. The hub will simply not accept a cumulative voucher of that sense. This is basically an advantage of using cumulative vouchers that the hub or whoever is accepting the payment doesn't need to track record of every individual payment. It just tracks record of the highest amount being approved. Um and that's that's what you uh basically verify as well like this is the maximum amount I'm receiving and it is uh fulfilled. You can verify um that u like the hub signs it the verifier signs it in terms uh and you will be fine. Obviously there is this livveness

risk in between that if the hub is malicious then the confirmation is uh if the hub and the verifier is malicious then the confirmation is not worth uh its dollar but uh you have to trust the verifier and the hubs on that. >> So the next question is uh as you add more servers to increase the throughput does it also require more coordination among the servers? You can do round robin. You can do whatever. Like if my address starts with 0x max then I will always go to hub A. If my address starts with 0x uh uh like 0 D A whatever I will always go to hub B. This can be

deterministically at the client side be decided and uh traffic can be routed in this way. Um that it is uh like like every individual server only serving a limited set of customers uh a limited set of throughput that it can handle. There is no cross state dependency here. Uh state of um like balance of user A is is on hub A. It does not matter what the state is on hub B. That is why we can have this level of parallelism. >> Okay. Uh let's take one more question.

Um so is it fair to say that you traded throughput in exchange for less decentralization? So it's less decentralization for the settlement time like if I'm settling every block on polygon I and I can do that because it's the settlement is just updating a Merkel route on on polygon. I can make this a primitive of the polygon validators themselves that they must update the state route uh of this hub every block. Uh this means that yes, I'm trading off decentralization till this state route is updated. That's just fast finality. That that is preconfirmation. Um that that's the

common term. Once the state route is there, it's all on polygon. It's secured by polygon validators. Um there is no trade-off in terms of decentralization once the state route is there. >> Okay. Uh that's all for the questions. Uh let's thank the speaker again. [music]