New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

What you need to know before deploying on L2s - Pietro Carta | ChainSecurity

ETH Belgrade CommunityMon, Oct 7, 2024, 12:00 AM

Transcript

[Applause] hello everybody I'm Petro from train security uh this talk is about uh know before you buil what is to look at when building on L2 uh in particular we're going to look at differences between ethereum and l2s so uh what is chain security we are a team of 20 blockchain security Engineers we have been doing um uh security research on blockchain since 20 17 uh we have a lot of audits with big clients and we do research on uh blockchain security so what is a L2 uh according to the l2b definition L2 be.com is a useful website to see the state of uh advancement of development of l2s it is a blockchain that uh relies on an L1 so on if for example for its security l2s can be more centralized without giving up any Security in the process so what are for example some l2s that we will talk about there is optimism uh and um consequently Baye and blast which are also based on the same Tech stack as optimism uh there is polygon ZK evm so uh this is uh if we go back optimism is a optimistic rollup it means there's a fraud proof mechanism or there will be in the future a fraud proof mechanism to uh avoid uh that the centralized sequencer can control the state of a blockchain uh ZK rollups uh depend on cryptographic proofs to prove that the state that is being uh uh defined on the blockchain and saved to L1 is the correct one arbitrum another optimistic rollup uh ZK sync era another Z ZK evm uh zero knowledge rollup and then uh there's a few more U and also some that are not shown here Linea and scroll are now pretty popular and there are also uh zero knowledge rollups so uh these are all uh evm uh l2s there are also non evm l2s that do not try to replicate the ethereum virtual machine and we've got different levels of uh evm compatibility in um in l2s so for example arbit room and optim ISM they just uh pretty much run the same nodes the same specification as ethereum and we could say they are mostly completely U uh compatible with ZK rollups it's a bit more complex and the four levels of compatibility have been defined uh and uh so it can be completely compatible this is level number one but it takes a long time to generate uh zero knowledge proofs it can be um slightly u u mostly compatible with some inaccuracies this is level two and 2.5 2.5 is compatible the same behavior but different gas costs uh it can be uh compatible but with some significant difference this is level number three uh for example maybe hash functions uh could not uh be used uh or pre- compiles are different this is because hash functions and cryptographic promiles are often the hardest things to implement in terms of ZK circuits or it can be uh if we go to level number four it can be uh compatible in the sense that you can compile Viper or solidity but uh it is not an actual evm uh it is another kind of virtual machine that emulat Ates uh uh the support of these languages so uh for uh ZK um evm from polygon and uh ZK sync these uh range between 2.5 and four as compatibility level so ZK sync uh is uh the most incompatible with a evm it adds op codes and you need to use a special compiler and ZK evm polygon uh can run uh evm op codes but it has some differences to ethereum so there are many aspects of l2s that uh differ from L1 uh for um in term of compatibility and assumptions that can be made so we are I'm going to talk mostly about uh uh execution layer uh differences but there are many other differences that uh we could talk about these are a sensorship resistance uh so um can I include a transaction in the blockchain or can I be prevented from doing so and this is important because if I'm bridging to L2 I want to be sure I'm able to bridge back to L1 uh there is liveness which means can the L2 completely stop for all users very uh Economic Security which means uh how how costly it is for somebody either a sequencer or another actor to cheat availability um will I be able to access the state of the L2 in a long time uh security so how reliable are the the basics and the exit time so how much time it takes me to go back to L1 uh if I'm I've bridged to L2 many more concerns uh also exist um we will concentrate on the execution level differences so this is now a long list of uh op codes that behave somehow differently or weirdly on l2s we start with origin and color or origin is in solidity TTX origin caller is message caller um you can message from L1 to L2 basically you send a transaction on L1 to a special uh inbox contract and a corresponding transaction is created on the L2 this transaction has a origin and a caller address which is the address on L1 but um allias this alliancing means you are adding a a constant offset to the address so for example if my address is I don't know uh 20 I will add 100 to 20 and my address on the L2 for transactions that come from L1 will be 120 and since addresses are generated as securely with a hashing functions uh you cannot uh create another private key that has the same uh allias address so uh what is important to know is that is allias address they can create transactions on L2 but maybe for example on L1 a contract is deployed at some address and um you bridge some uh um some tokens to L2 where the contract is not there uh you will not be able to uh send transactions from that cont truck address for example if it's a if it's a a safe a multisig uh because the the the transactions coming from that address will um uh will be allias as the as the address um also you can have transactions that originate from Smart contracts on L2 where origin is equal to color so this is an invariant that um for now on ethereum means that u a transaction is coming from an EA on L2 origin is equal to color um also if the transaction originates from a contract on L1 uh we've got self-destruct and sandel do we still need to talk about self-destruct now it's uh it's been uh removed from U from ethereum Main net in the s that uh when a contract is a contract is deployed uh if you call set the truct it will now Implement send all which means all the ethereum balance of that address will be sent to another address um this is uh only true if the contract is not currently deploying if it is currently deploying so if you are in the Constructor the the self-destruct still works as it as it W so it means the the contract will actually not be deployed uh uh no contract will be uh deployed at that address um this has some difference between different rollups so an optimistic rollups it's the same uh this is optimism and arbit room and on ZK rollups it was uh difficult to implement and ZK sync just has a compile time error when you try to to um uh use compile a program that has self-destruct and ZK evm implements sandal but it also implements sandal in in the Constructor uh so it is a slight difference between the two uh difficulty or prevend Dow so it used to be the difficulty of the mining and then it became the this this a random value um on l2s these values are often uh arbitrary and uh so the choice of different l2s differ on ZK Sync It's always this constant on arbitrum it's always constant one on polygon ZK evm is always zero and an optimism is a it's a random value chosen by the SE sequencer so the sequencer claims uh on optimis that it is uh pseudo randomly generated but actually it has freedom to choose whatever uh value uh they want so uh in general it is not a great uh feature to use on l2s if you need uh random values uh use an oracle for that number and time stamp so this is tricky and this is is uh maybe one of the source of um uh differences that actually matter on L1 number is just a sequential number of the of a block and uh it always increases by one uh between one block and the next one and time stamp is the uni time stamp or that slot of that um of that block and it must always be a multiple of 12 um um it's pretty much 12 time the block number uh except it's 12 times the slot number on the consensus chain um on l2s uh this has been implemented in different ways initially uh the what was returned was the L1 number and time that corresponded to a certain block on L2 which meant uh you could have different blocks uh with the same number and the same time um it's been changed now on most chains and what is returned is the L2 block number and the L2 block time uh which means uh it's not the time for example is not increasing by 12 it's going to be increasing by uh depending on the on the uh block generation frequency of L2 um an exception is arbitrum it keeps the L1 number which is an estimation of of the L1 number um that corresponds to the time this block is generated but the L2 time um why does this matter it matters a little bit when you're implementing mechanism that depend on time stamp and you rely for example on different blocks to have um different time stamps uh for uh for example uh time weighted average prices or stuff like that push zero uh nothing much to say it's just not implemented on linear block hash is weird so um on L1 what it does it Returns the the the the hash of of the block for the previous 256 blocks um on arbitrum it just Returns the hash of a block number so very different um on optimism uh it Returns the L2 block Cas for the last 256 blocks so pretty much the same behavior as L1 on polygon ZK AVM uh it Returns the L2 block hash for any block uh in uh in uh in history so not only the 256 last blocks and on ZK sync uh it Returns the L1 block hash not the L2 uh block it returns eared the the L1 block hash now the L2 block hash um this makes it hard to use on L2 unless you are targeting specifically a chain and you know what it what you need uh coinbase uh coinbase is uh is this address which is in the header of an ethereum block and U it used to uh tell uh who uh would receive a mining reward and when uh through of uh stake uh was deployed it became arbitrary and it's mostly used to like uh tip uh block Pro producers um on optimism it's undefined the sequencer can choose whatever as its value uh on arbitrum it depends uh it's a it's a fixed address if it's if it's produced by the sequencer uh if uh instead uh the block is created by on L1 directly by force inclusion of a transaction uh it can be it is the address of the of the transaction initiator on polygon uh it is the sequencer address uh and on uh ZK sync era um it is the address of a bootloader special contracts uh so there's not much point to use this uh jump destination so this is almost I mean nothing much with this uh a small uh peculiarity is that so when you deploy um when you run a contract uh a jump destination analysis is run which means uh if uh valid instructions are present in the body of in the payload of a push instruction you will not be able to run those because they are data and they're not uh code uh to do this uh the contract is analyzed from the beginning to the end every time a push instruction is uh is met uh those uh next data are skipped um and uh if a jump desk is uh is met outside of this uh data uh it is stored somewhere so uh if you're jumping to an address uh you will only be able to jump to an address which has a jump destination set and this jump destination must be outside of the data of a push uh instruction except on polygon ZK evm where you can jump inside the data of a push transaction this uh in practice doesn't make a difference unless you're doing very weird things uh with assembly and on ZK sync finally there are um a big uh there is a big big list of incompatibilities it's not targeting evm equivalents you have to use a special compiler and there are many instructions that differ um starting on how the uh the code uh is structured the the how U contracts are deployed uh at what addresses how contracts are called and and so on so uh also SO gas prices are widely uh different um when you uh need to spend gas on l2s two prices uh come into into into play so one is just the gas cost uh of executing the uh the computation on the sequencer and this is generally very low and then very a L1 cost which is associated with posting the transactions onto L1 to finalize them uh so the computation cost is generally low the L1 cost is higher it used to be much higher when uh it used cold data and now it used the blobs so it has been uh it has been going uh down a lot also uh but uh take into account this uh two di dimensional gu gas pricing for chains um polygon ZK evm has a has another mechanism for SP spam protection beside gas price uh which is uh some Oak codes they are uh limited on the number of time you can use them uh for a certain block so you should test against uh a uh an equivalent test net to know if uh for example your contract doesn't use too much of these op codes normally the limits are high enough that it shouldn't matter uh but uh recommendation is to use a realistic uh test net uh a nextra uh thing I will talk about is how block production happens on l2s so on L1 you've got M Pools and um the block producer then picks the transactions from the men pool or we've got private M Pools uh and Builders uh submit their blocks to the the block producers um in on l2s uh what you have in every case is that you have a centralized sequencer uh which uh receive transactions and in general post them in a in order way so actually optimism now also implements private me pools with a priority fee mechanism but for example arbitrum just has a fifo uh Quee for transactions um what does that mean so on L1 if you want to control U uh transactions over the uh over um block um block boundaries uh you would have to uh control the block producing of the second block mostly you can include the transaction at the end of the first block for example uh that's something you can uh easily do but then to be assured that you also can include a transaction in the next block uh you need to be the block producer of that block this matters for example in Oracle manipulations on chain uh because you want to be able for example to uh move the price a big amount in the first transaction and then move it back in the second transaction in another block when the time Su has incremented and U uh and uh this um this moves for example the Unis swap uh twap Oracle but it um it risks uh losing your uh manipulation Capital if you're not the producer of the next block on l2s what can happen is that because of this fiveo ordering of transactions you can just send your transactions back to back one with a manipulation in One Direction one the next one with a manipulation in the other direction and if you hit the timing right and you get the time when uh a new block with a new time stamp is produced uh you will be able to almost surely have these transactions in order U included before they are actually revealed to the rest of the word so nobody can Arbitrage them uh uh back uh before you do uh so it is a liability in terms of these onchain oracles that use uh the uh the time stamp so if you want to read more about this uh rollup codes is a very interesting resource and then uh every one of this chain has a page about all the tiny differences uh that are with respect to ethereum so thank you I'm Petro from chain security uh I will be talking also on Friday at the security Summit about Oracle manipulations thanks if we have any questions in the audience like feel free to raise your hand hand as usual but let's switch it up this time like raise your other hand yes thank you for raising your other hand by the way you had one slide saying uh that it's bad for tws can you just elaborate on the difference between the twap on L1 and L2 in that case okay so I think I had had it on the time stamp slide maybe not in any case so what I can say about tws is uh for Block production uh the twap uh if it's on chain uh It generally depends on the time stamp and time can increment as block on block boundaries basically uh and what you can have is at very low cost so you I mean you're paying for the transa for the transaction fee and for the uh pool fee but not for like for example on L1 if you want to control the twap you need to be the producer of a block so you're guaranteed to be able to undo your manipulation uh on l2s because of this five for ordering of transactions you can send two transactions back to back and one if you if you've got the timing right one will be included in one block and the next one will be included in the next block uh over a a time stamp uh transition and so uh this allows you to to control that that amount of a twap does that answer your question we have time for one more question so if there's any Okay then if anyone comes up with a question in the meantime Petro is going to be around don't be a stranger Petro is is more than glad to chat so once again please give it up for Petro thanks thanks

Automatic transcript — names and jargon may be misspelled.