The Gap Between 'Included' and 'Executed' - A Preconf Deep Dive - Kumar Satyarth

Transcript

Hi everyone. I am Kumar Satyart. Uh I am smart contract developer at Puffer Finance. Sorry for the trouble. Some glitch right you know technical issues. Since this is a lightning talk, I won't be able to cover everything the technical perspective and everything. But this should be enough to give you the motivation and the idea about the preconfusion and execution. Right? So next 10 minutes are about one idea. When whenever someone says like rollup has preconfirmation uh what are they actually talking about? So I'll show you there are two different kinds and one of them is the actually that should matter to the users. So base rollups have a very beautiful property.

So they use role Ethereum's own validator instead of centralized sequencer like similar how arbitum or Solana use. So you don't trust a centralized sequencer and but you trust the same set which is uh already running on the L1 but you have to pay the price for L1 which is the clock that is the 12 seconds problem. So 12 seconds per block. So 12 seconds is fine for if you're sending let's say ETH to your friend but it's a disaster for a trader arbitrageer or liquidator or let's say very importantly crosschain solvers. So in 12 seconds price drift market can move uh before the execution lands. Uh so bots competes against each other and

waste gas. And importantly the crosschain solvers can't uh simply like commit to fulfilling the intent because they don't know like what the state is going to be u at the end right so the real question is can we make based rollup feel fast without giving up the decentralization that is the interesting uh at the first place so yeah the answer is pre-confirmation so but this is the place where most people get it wrong because they don't know what are the kinds so there are two kinds of preconf so you can see inclusion preconf and execution preconf so inclusion is simple it says hey I will include your transaction in some block that's it

that's inclusion execution says hey I will include your transaction in the block that's for sure but I will guarantee that I will produce exact state what you asked for exact balance this exact price fill and this exact output so the think way uh I I think in a way is like inclusion is more like hey I will deliver this envelope but execution is hey I will deliver this envelope and I will make sure that the check inside will clear for the right amount. So but for uh you know but for the user who is just interacting with the wallet it just says confirm he doesn't need to know any of these. So but why inclusion alone uh is not

enough. So let me make that more concrete. So let's say you swap one ETH for let's say 3,000 USDC. You get an inclusion preconf wlet says hey the transaction is confirmed right but that between that promise and the actual block uh somebody's else swap lands ahead uh of your uh transaction. So the price of the pool moves and your the your demand uh get fs at let's say 2 uh 29450 right so you basically lost $50 here so inclusion was honored because it says hey I have already included your transaction in the block that's it is but it doesn't guaranteed that hey you

will get your uh 3,000 ETH exactly in your wallet so with inclusion you can see uh there are three key limitations so which is like ordering execution and outcome. So in exe inclusion me and sandwich attacks are very possible and uh the crosschain solvers can't uh price the risk of let's say releasing your funds on the destination chain because they don't know right because they don't know what will be the state on the source so they can't promise. So that's the gap between exeu uh inclusion and execution which we are talking. So how does this execution preconf.

So there's a piece of infrastructure that is called gateway. So if you know if you have heard of gataga. So gataga is the most public example. And here's the flow how it works. So basically user submits intent. Hey I want to swap this much of ETH which with this much of USDC. So transaction signed and execution requirements are given. Second, the proposer delegates. So the gateway has a delegation from whoever L1 proposer is for this slot. So it's not an auction, right? So the proposer basically hands over the key for that slot. Uh the gateway signs on the behalf of the proposer. So gateway is the one who is doing all the all the heavy work.

So the three is the the gateway basically simulates the transaction and signs the execution commitment. So hey this is the transaction and I have signed it and give the signature precon signature back to the user and the wallet basically shows you hey this is final done. So the fourth is like block lands on L1 if L1 doesn't match what gateway promised. So yeah anyone in the room can go and hey submit a relic proof to slashing contract and anyone can do uh and slash the proposal or gateway. So but the gateway doesn't make you wait 12 seconds. Where does that 12 seconds go?

Right? you are still getting the confirmation in milliseconds. So to find out what happens so while it's building the block the gateway is building the block it sends you tiny pieces of it every mill 10 seconds. So it's right now we the research is going on and decreasing the time but yeah each piece is signed and they are called frags. Frags are like basically fragmentation blocks. So as a user you feel like you are interacting with just a centralized exchange uh updates you get updates in the real time and you are not sitting there and keeping hitting the refresh button every time. So when the full block lands on L1 12 seconds later because obviously it is going to be settled on L1. So it's all just those all those frags or pieces stitched

together. So yeah this is how it works but none of these works without consequences. So gateway has the skin in the game. They have put the ETH in uh rested ETH on layer. So if you know layer is a resting protocol. So if they break execution preconf gets burned right and the way anybody can prove uh that they broke the pro uh is with uh with relic protocol. So this relic protocol basically uh generates onchain proof and um yeah so anyone can do uh in this room can submit basically the subroof and you don't need any referee or central entity to uh to

decide whose fault is this. So basically the math is the one who is deciding and the slashing contract is the one which is deciding. So promises are only strong as the bond behind them. So it's like uh playing a good key feature in the economic security because you are holding the ETH right. So that's the whole point and there are two ways the gateway can fail. So gateway can also fail. So there are two uh types uh uh ways. One is the liveless uh fault. So let's say you promise your transaction will be included but you didn't deliver right. So it's annoying you retry but you are still getting slashed but very small uh slash. Uh second is the safety fault. This is the big one. So you

included your transaction. They included your transaction but the state is not what they guaranteed. So now they are breaking the promise here, right? It's not they are not including it's they are breaking the promise. So that's the worst way you want to witness. So you thought like you will get $3,000 instead of for let's say one ETH but now you are getting 2950. So bic basically you are getting like less amount. So safety faults carry much heavier slash. So in this case this gateway will be slashed heavier. So slash also has to be uh hurt more than gateway can ever gain by me and basically they want to cheat. They can't

because they have to put more E3 restricted. So yeah we have to make sure that the me upside is used and the if the bond is small and me upside is used. So they are going to cheat. So they we need to make sure that the e the collateral is used right. So basically what this provide for u actual users how what do you get? So first is swapping on deck. Let's say you are doing a trade. So you get exactly the price what you have promised. So gateway signs it uh money is on the line because they have already restrict other protocols can still uh be there around like swapping and doing stuff but your fill is locked.

If it is guaranteed you will get 3,000 USDC you are going to receive it right and the second one is important one which is for crosschain solver bridge right so for them speed is everything so with execution precon uh basically you get the sign proof of what is going to happen on uh source chain in milliseconds not uh 12 seconds so I think this is a good use case for crosschain solvers and bridges so yep and uh But this this comes as a honest trade-off. So uh let's say be honest what you are trading. So you are putting a trusted role the gateway inside it and back into the system where you designed to remove the trusted role right. So you

are still putting a central entity gateway inside it. So what execution precons give you is a gateway whose trust uh is bounded by economic slashing. So you are getting economic security and not by reputation or hope. So that's not like L1 trust model and that's also not a centralized sequencer right you are actually getting a economic security here. So it's a third thing and it's the only design I have seen in the let's say uh that gets a D5 level speed and the L1 security guarantee with economic security. So next time someone tells you that hey our rollup has got pre-confirmation. So don't stop there please ask and find out what kind what is the on stake what is

the bond and what is the mechanism of slashing and with what proof system. So find out what is get slashed when they are wrong. Right? So lastly I would say ask the question that actually matters. So do you promise the block or do you promise the state? Thank you.