Enhancing Protocol Security With ZK-Oracles

Transcript

okay awesome move that way all right folks hello um today we'll talk about the enhancing the protocol security with zero knowledge oracles and um my name is Victor I'm a Lia protocol contributor and my co-speaker today Eun he will tell you about the technical details about the ZK Oracle in the part but before that let me set the stage for that and explain the problem and uh set the solution framework um in the beginning just a few words about the ligher in case you don't really know about

sorry that's yeah um so it's a middleware connecting the users with is to the node operators it's more than 9 million e at the liquid staking for this protocol there are some important properties of lier like the erc20 fible token we have also um um in lier there is also a permissionless withdrawals uh so everything that St could be uh withdrawn if it's needed and also there is a

um flexible Stak in rotor which allows to set different um validators subsets and the most important thing it's uh Dow voting because every change to the protocol actually have go through the um the voting and um so the problem statement uh for the protocol it's needed to have some external data to proper count the um the value of the STI token and uh to distribute the rewards across the um stakers and the essence of the problem

is this external reported data should be minimized the trust to this data should be minimized or it's better completely removed and um to explain you the implementation for that I need to talk about two main things it's a li accounting oracles committee and oracles report on Checker the first thing it's a committee so the stiff rebase happens uh every day with the Oracle report Oracle brings the values like a consensus layer validators balance withdraw World Balance some other data and it's recalculate the value of the token um it's kind of protected uh with a committee of nine independent oracles

and only if there's five identical reports received from five different Oracles this data can come through but not really yet because there is a sci Checker in between because um there are some checks to basically tie hands uh for this system if there is a kind of abnormal or abrupt balance change coming let prevent some possible attack vectors however in the previous implementation of the sanity Checker there is a problem that's the negative rebase parameters was too limited it was about like setting x% negative3 base per day that is not

really enough so the solution is described in uh ligher Improvement proposal number 23 um and it consists of two main parts the first the strictor Checker so basically we decreased the limit of 5% of the consensus lators uh to 3.4 over an 18 days window it's a major Improvement because it's limiting the possible negative re bases but the most interesting part that's the pluggable second opinion Oracle and based on the suin slaps DK Oracle implementation uh based on the sp1 DK VM

it provides this trustless verification um POS this data it's calculated uh data from the external and provides the zero knowledge proof for that data as well and uh this kind of guarantee are the better results because we can consult the second opinion before we can do the rease so basically now I'm passing the mic to Eugen to explain you the technical details about the Z Oracle thanks Victor um folks um I guess I'm the last thing between you and lunch so I'll try to not take too much of your time um so yeah let's Dive Right In so just a quick update of uh how the

problem translates to the technical part um basically like ethereum have two layers as you all know and they're pretty much isolated right so there's like only like a few windows from execution layer to consensus layer and in the opposite Direction and that actually brings a challenge because all of the data that's needed for the Oracle report uh needs to be existing in execution layer but all of the data is on a consensus layer and normal solution is you know as as Victor mentioned there's a li Oracle and a committee that brings that data from from the uh consensus layer to execution layer and it's a pool Oracle and everything is

fine except you know it's still requires building and when you build an oracle there's still some challenges right because majority based majority V based oracles still have this uh like attack vectors one is a simply Brute Force you can still overtake five entities and then put whatever report your you would like uh the second one could be like slightly more subtle called the supply chain attack because practically your Oracle is still an executable code it has dependency and if some of the dependencies is compromised um your Oracle could be compromised as well so if you remember that famous thing about left pad on mpm

if the guy just didn't just R quit and deleted it but put some malicious code into it pretty much like entire internet would be infected and obviously there's still uh implementation risks right everyone's like all of so far all developers are humans and humans make mistakes and if one of the mistakes is slip in that would open an additional attack Vector for compromising an Oracle and here's where zero knowledge Proof come um technically all of that data is publicly available so like completely onchain solution is possible the only problem is that you would need to like put entire Beacon

state which is the like the data structure that captures everything on a on a uh consensus layer you would need to put it on execution layer and last time I checked it was something like 230 megabytes U SS serialized and it's probably would be even even bigger ebi encoded and like run hashing like um shot 256 hashing over like to produce Merkle roots for all of the validators that alone would take something like 3 million uh hashes so basically like over over over sorry overall this is not feasible because it will exceed any reasonable gas

limits and ZK actually helps with that because like straightforward use of ZK Solutions is to kind conceal some knowledge and produce a proof that you have it okay like the oppos the thing is that this knowledge does not have to be private it could be like publicly available it's just you don't want to push all that data to the verifier to do the thing so instead we can just push the report itself plus a proof that the report was computed honestly and consistently and and that reduces the amount of data and amount of computation that we need to do on execution layer a few orders of magnitude if not like

millions of times um okay so charting course on the on the technical approach so as I mentioned producing report uh starts with like actual like correct algorithm right in order to produce a report you fix how this uh raw data that we have on a beacon State converts into a report and this is actually like an exerpt of of the actual code we have most of the complexi is hidden behind um how's this behind this prepare input thing but other than that it's just basically this uh and correctness and honestly requirements

for producing the report is guaranteed by the uh ZK infrastructure itself uh and we'll touch about uh on this uh slight later the second part of the equation is actually having the correct data pushed into the uh both proof and and uh verifier contract on chain the the tricky part here is that the this kind like integrity is not like cannot be provided by the ZK Solutions alone and um sorry yeah and practically when we're like pushing final report and approv to the execution layer we need to like compare something in the report

with something on a block blockchain that we can use to like uh like confidently uh check that the report was computed correctly and we'll touch on what that something is uh in a few slides and finally if we have like correct algorithm and correct data uh like that that guarantees that the ex like actual execution report actual report would be correct yeah and the tricky part is that like when we're talking about this like in ZK uh circuit or ZK program 95% of the time actually spent on like proving all the data that we can actually ladder up

to something on a blockchain that we can verify against uh literally like the algorithm for Lio report is like for all validators if validator withrawal withrawal credentials is not Lio skip it if it's Lio add the balance uh increase the counter that's it this is your report so practically like 15 lines at most but proving the data is kind of like oh we'll get into it so uh here's thing we need to prove a lot of data about validators their balances um activation exit Appo etc etc uh but on the execution layer we the only thing we have is the beacon block

hash and this is actually was added I'm not sure in Capella or denb but pretty recently so there was like EIP 4788 that brought this pre-compile contract that keeps track of the beacon block hashes on the execution layer and down it goes so the next layer is that like beacon block hash is produced from parent root State rooot and body root and a few other fields that are like in a beacon block header and then State root is um Merkel tree H root of the beacon State data structure that has like something like uh 30ish Fields uh basically this is like entire Beacon State uh beacon

beacon uh consensus layer state and the most important for us is validators rout this one is kind of tricky because uh we'll touch about on on this in the later slides but it's kind like a Merkle tree of a variable list that actually have two to the power of 40 elements only like 1.6 million elements are actually used but there's a trick that makes it important and then for validators Route like that route is computed V from a Merkle hashes of every validator and Merkle hash of every validator is actually produced from mer like merizing uh all of the fields of that

validator and that that's how how it comes to be and then there's also balances route because like we're practically reporting on a uh consensus layer balance for all of the validators and for balances it's slightly different because they are packed uh in ssz Spec uh they like balances are eight bites and they're packed four items together into like packed balance and then this forms a leaves of the Merle root of the mirle tree and if you look at it this whole thing looks like this and if you don't don't know who this guy is he's a baron Housen a fiction book character like main character in the fiction book and he was telling like cool stories

like once he was traveling and got into a swamp and he pulled himself out of the swamp by his hair including M themselves and a horse and so on so forth and in fiction book you can do pretty much anything uh in reality we're Bound by some laws of physics and Mathematics and it wouldn't be possible but there's a like a hook that we can use later uh that allow us to perform tricks like this uh just to touch on the technology side of things so this whole thing is built on the sixin labs uh sp1 sp1 stands for sixin processor um and and like this is the slide from their initial announcement half a year ago in in April or something

obviously the benchmarking uh values might have changed since then but like the part that talks about like developer productivity I can literally like I can definitely get behind this uh 100% like 100 times maybe even even bigger because the the best part of it is that it allows writing ZK circuits in Rust and it's like a plain rust everything is supported even like third party Lang uh packages with some tricks that uh with some cavas that I'll talk about later and thing that I love the most about it is that both uh Oracle like offchain code and uh ZK circuit can actually share code that allows for like a lot

faster iteration you don't have to fire your um z zkm uh emulator every time to test everything you can actually do a lot of unit testing a lot of integration testing um and that that speeds up the development a lot yeah and one thing worthy of mentioning is that there's like a bunch of like performant pre-compiled for pretty much well at least main uh crypto Primitives like sha kak etc etc that actually makes it run a lot faster even on on Z KVM itself cool so initial solution I put a little bit of code on my slides uh I

think it should be readable but you know uh if anything I'll still talk through it so this is basically entire code of the Oracle except like it you know hides some complexity in the library codes so basically what like what Oracle is doing is that it reads the consensus data and it orchestrates creating a proof and submitting it to uh sp1 prover Network where sp1 prover if you're running locally and finally just submits the report and uh and proof to the contract on chain uh this is also like the almost like a full listing of ZK program I just remove the parts that are not not really

interesting so again it's written in Rust uh and compiled into elf I forgot how it's de abbreviated executable linkable file or something uh for a risk v32 virtual machine and like running this Elf on the on a virtual machine produces the I air algebraic intermediate representation air Trace that is later compact like compressed into into a proof and this part like provides part of the correctness guarantee right so this like encodes the algorithm and not 100% sure how it happens but practically like the actually like the code in in your

solution is part of the verification key that will be later used for verifying everything and even if like single bite change you get a new verification key and you've got to redeploy your contracts or update or like do some stuff and that's kind like part of the protection from malicious attackers that only the like like bless verified uh algorithm can actually produce proofs that uh we'll be passing on on the when we do verification um yeah and as I've said major advantage is that almost any Ras code can be used and I guess we'll touch on it in a few slides so final kind like uh piece in the grand architecture is

the contract itself that accepts reports and verifies them so the like the most important part of what it is doing is kind like anchoring the data uh that we're sending to a block uh to a blockchain state so most of the thing in as I've mentioned most of the operations that the ZK is providing is kind like taking beacon block hash and proving that okay we had actual uh State root from like this given slot on on a blockchain then okay we have state root let's prove that we had like validator hashes we have validator hashes let's prove that we had all of the validators and like all of the data is correct below that and but finally this kind like this this whole

tree like anchors on the beacon block hash and that provide us the like the the hook that we need to pull ourselves out of the swamp and second part is that it just verifies the proof um so contract literally just send it to a onchain verifier that can uh verify the proof rerun those mathematical AR Trace uh algebraic intermediate representation rerun it and confirm that yes yes all the constraints match uh all the data that was passed in it matches what we expect to see everything's fine and this kind like provides the second part of the

correctness guarantee and and kind like cements the the solution altogether and finally just stores the report nothing fancy just you know recorded into a mapping and make it available for uh later consumption by the protocol uh a couple of challenges and I think we're running up of time so I'll run really quickly one of the thing was that like Risk v32 is a 32-bit machine and N like if you remember number of validators in the beacon state is actually 2 to the 40th and two to the 40 is actually like if you if you try to convert it into uh unsigned in 32 it will

overflow and one of the crates uh I used to to build the tree hashing this is actually tree hash not sure if it's from Lighthouse from Sigma prime or one of the derived ones uh by the way kudos to uh Sigma Prime for Outsource open sourcing all that stuff uh it will just basically overflow at some point and everything will crash so to kind of overcome this I had to do a conditional execution conditional compilation so this is like for your normally uh x64 uh machine and then this is like equivalent implementation on risk v32 that doesn't hit that problem there's a little bit of uh tradeoff that we're

like artificially limiting the number of uh validators to two to the power of 29 but that kind like will sustain us for like 40 years from now taking into account the current uh validator account growth so should be fine more less and the second second part was that like like naively generating the proof was extremely expensive in terms of like Risk V cycles and that that impacts the cost of the proof and that impacts the time that takes to generate the proof overall it was kind like uh something like it would took one hour for 10,000 validators and was kind like scaling linearly so for like 20,000 validators would be two hours and like for 1.6

million validators would be like a couple of weeks and that's obviously not practical so what we had to do is to like uh do some caching uh and there was like like two options one option was to leverage the recru uh proofs that sp1 provides and can like store them somewhere and if nothing has changed in that part of the part of the tree of of the recursive proof just reuse them without regenerating the second approach that we took is actually storing uh this light of validator State structure uh on like on chain through Merkle route as well and kind like only recomputing

something that's changed that is basically this validator Delta Co final slide uh at this point we are we have deployed to sepolia we've run very extensive uh user acceptance test um verify that it works correctly for happy cases uh verify that it rejects the the proofs for a lot of like data tempering attempts and anything I could uh think of putting my hacker mindset um things left to before we can launch isbc to complete the lap 23 compatibility there's like a couple of things that we had to uh push back a little and perform out it and basically

like put it for a dow voting uh on Lio and future enhancements there's like multiple things we can support with like multiple with thr credentials we can support like we should support pectra at some point and all the future updates uh precise validator match there's like a few hortic that were employing and you know coast and performance optimizations and yeah I guess we're done here thank you all for coming we can take questions if you have oh sure all right thank you folks thank you all

[Applause]