 Hey everyone and welcome to blockchain village So in our talk, we will be covering about sandwich attacks and Will cover how we can prevent them with recurrent and recursive zero knowledge proofs So starting with the agenda So this is how it looks like for our talk So giving you a quick speaker's introduction Meet Mr. Gokul Alex my partner for this talk is a cryptographer and cryptologist He is a blockchain security architect researcher on DDoS attacks. He has co-founded many projects organizations so Popular of them are giga mesh garages semi-art systems and quantum kick sort is also advisor at Red Team Hacker Academy and and Red Team cyber security labs if you want to meet him you can visit his Twitter account Twitter handle at Gokul Gees Next is me. My name is DJ Suresh Togi So I'm a penetration tester a blockchain security searcher Currently a smart contract already died co-audits. I've also Founded a razor sec, which is an open source Community of security searchers who come together and discuss on their security topics and help everyone to learn and grow I'm also a creator at Cypher Shastra, which is a CDF platform where anyone and everyone can come and practice some smart contract challenges and also Some cryptography exploitation challenges as well might be in future I'm also a malware analyst and Adversarial ML researcher if you want to connect with me you can visit my Twitter handle at razor to eat So starting our Presentation let's take a quick refresher over some topics starting with front running attacks So like what is a front running attack so front running attack is something when an Adversary having the knowledge of Q transactions Places this transaction and which gets executed prior to a genuine transaction Thus impacting it So like how does this happen? So it happens because By tricking the transaction selection process So as we know that Blockchain is a public decentralized ledger Meaning all the data flowing in the network is publicly accessible So when a transaction is signed and submitted on to the network, it is broadcasted into the entire network so every node gets the information about it and they all get a story into the mempool or memory pool and Firstly, they are marked as pending Because like there are a lot of other transactions flowing into the network. So I Transaction just entered into the network Will take some time and will be first stored into the map pool and will be picked up by a miner So miners pick up a transaction to add into a blog and they are incentivized for the block creation But here comes an important factor which is the gas price now the miners typically pick and order the transactions and Descending order of the gas prices, which are associated with the transactions So they do that to extract as much profit as possible from the block creation So here you can see a visual representation of that. There are Multiple transactions like T1, T2, T3 and T4 All of them have different gas fees associated with them they will all go to a mempool and Miner will pick up T4 first because it has the highest gas fees associated with it and following with the T3, T2 and then the lowest one, which is the T1 so This means that typically transactions are ordered on the basis of gas price and not as first come first sub basis, right So that hacker can take advantage of it and send a transaction with a higher gas fees Than the victim transaction. So what will be our result for that? The result will be attacker's transaction will be picked up first impacting the victim So there are multiple variants of versions of front-running attack Some of them are displacement attack. So As the name says displacement says when an adversary displaces the victim's transaction with its own and with the same values which leaves the victim's transaction with no meaningful or Effect or in some cases, they are completely orphaned example can be like consider a smart contract which accepts a secret number and Gives a lottery to the user whoever calls it first Now the transactions after it Will either be discarded or won't be making any money So a genuine user like the scenario so a genuine user find the secret number and Summits the transaction and Adversary gets the info of the spendage transaction from the mempool It places this transaction with the same secret number But with a higher gas fee so as a result it gets picked up by the miner first and Adversary wins the lottery Which leaves the genuine transaction meaningless so Another example can be which is a popular one as domain name registration So imagine like a victim or user trying to register a particular domain So an adversary sees the spending transaction with the registration request of that particular domain the adversary can front-run And buy the domain prior to the victim and can sell it afterwards with a higher price So this is something called a displacement attack Moving on to there is an insertion attack insertion is where Adversive places to transactions Before and after the victim transaction that's making a sandwich By inserting the victim transaction in between office to transaction And sandwich attack Sandwich attack can be a thought of a kind of insertion attack So we'll come to it later as this is the main aim of our talk So next is the suppression attack again. This is a popular Attack so here the sole purpose of this attack is to Delay the victim transaction How does they do that? Like by filling the block gas limit so they so that they can delay the victim transaction for a certain amount of time so When this happens after that the victim transaction again becomes meaningless or it doesn't matter much because as the adversary have as the adversary has already Achieved its purpose now. So it can be thought of kind of a denial of service for the users as Adversaries want to maximize their profit per block So this is also called as a block stuffing. So here of a mean focus on the insertion attack, so a Insertion attack or a sandwich attack. So moving on to before jumping into our sandwich attacks We have to discuss something about automated market makers as well so What are really these automated market makers in DeFi? now Unlike traditional finances where the price of an asset is decided by buyers and sellers trading that asset This is called an order book method or order book approach but in AMMs or automated market makers like Uniswap They works on a con they work on a constant product algorithm So for example Uniswap works on X multiplied by a Y equals to K curve where X and Y denotes the token results respectively and K denotes the constant product and The trade happens on a liquidity pool in AMM Instead of instead of like Stop between buyers and sellers in order book approach. So here there's a liquidity pool So anyone can sell tokens and buy tokens from the liquidity pool So at Uniswap like this Mathematical formula So if you are trying to swap a token X for token Y It will be calculated as a formula on your screen like Y multiplied by 0.997 multiplied by DX Over X plus 0.997 multiplied by DX So what is DX here DX is the amount of token X that you are selling So if you are selling token X It will increase the amount of token X of reserve So the output amount of token Y can be calculated with this mathematical formula So this is the curve right a bad drawing So it's something like X multiplied by Y equal to K so assume This was the initial value of Y and X token results So for example, if I'm selling some value as DX of token X For example this much So now the output amount or what I'll be getting is something Right here, right? So this will be that dy So this much amount I'll be getting from here from this trade selling so similarly if I'm Selling some Y token it will increase the token Y result for example here and What I'll be getting As DX here this much amount of DX So as you can see The curve flattens as we go ahead both on the X and Y axis meaning less the token the lesser token reserve will be the more expensive it will become to buy that asset So for example, its supply of token Y goes less then it will become very expensive to buy it and We have to sell a lot of token X into the pool to purchase token Y So this is what something adversaries utilize to make profit Alright, and the important factor is the slippage So what is slippage? So as we know that the market stays in a continuous state of change So the prices for sets move up and down now The execution price of trade also differs from the expected price. So this is called as slippage Now slippage happens when traders have to settle for a different price Then they initially requested Because of a movement in price in the market so this difference come because the market Price was different at the time order enters the market and at the execution of a trade So there's there are two types of slippage first is positive and negative so positive is when The actual executed price is lower than the expected price for buy order So by by positive slippage the trader gets a better rate for his trade Then what it has initially expected, right? Then there's a negative one where the executed price is higher than the expected price So here the trader gets a bad price for the trade Now moving on to the slippage tolerance Now how we can calculate the slippage because there's no sweet point There is advantage and disadvantage for setting it too high or setting it too low so How much like it depends on how much slippage tolerance is variable for a trader or How much movement in price I can live with so UNISO app gives this option to us by default it is predefined and then in the UI you can select the slippage Which you are considering so We can adjust that as well. So what it is it is a percentage value for the slippage that we are That we want to set for our trade So that will be converted into a minimum amount Which we are willing to accept for our trade so if there's a huge price shift in the market and Output amount for a trade is less than the slit set slippage the transaction will be reverted So I can keep my tokens, but I'll have to pay the gas fees So the knocker the now the question is How much tolerance should be set too high or too low both of them have the advantage and disadvantages So if he set the slippage too low the trade won't be able to adjust with the market price and Although I can keep my tokens, but I will lose the transaction fee or I have to pay the transaction fee But if I set it too high then it will open the door for front-running attacks like sandwich attacks Because I as a user am willing to accept less tokens for my trade So what will happen? Attacker will front-run my trade for that same asset which I am buying which I'm trying to buy and thereby increases my price Increases the price of my transaction by making that said more expensive to buy and then That was revealed background my transaction by selling that asset at a higher rate and Extracting profit from the slippage Or from the market shift that it had made So there's no sweet spot for the slippage tolerance. So that's what the reason it Gives birth to sandwich attacks Now let's just talk over to the main topic of scene sandwich attacks So here you can see a nice visual representation Covering what are sandwich attacks? so here you can see that victim sends a transaction as TV from the node it gets broadcasted to the 3dm network and gets stored into the mempool as the blockchain is Public and decentralized the information is distributed to all the nodes and Everyone can see that now adversary has already set a spy node into the network. So it's see the transaction from the victim and it observed it and Try to find out whether it is profitable to front-run it or not And by profitable, I mean like it is profitable I Is it having a high enough slippage? so if it Or what it will do it releases to Transaction as the a1 and t2 t2 by adjusting the gas price according to the victim transaction so as to make it a sandwich and Some is to the network so these transactions are broadcasted again and again stored into the mempool now the miner as is typically ordering the transactions according to the higher gas prices So what it does or how it picks the transaction? It picks the ta1 that occurs first transaction Then the victims transaction and then that take a second transaction. That's making it a sandwich and That's how sandwich attack looks like moving on to Different variants of the sandwich attack so sandwich attack can be performed by both the liquidity takers and liquidity Providers so these are two popular versions of sandwich attacks So Yeah, you can see the first one is liquidity taker attacking the taker So yeah, you can see the attacker sees a pending transaction from TV a Trade of X tokens for Y tokens so adversary observe this pending transaction and Try to find out whether it is profitable to make it a sandwich out of it or not Once it find out that a yes, it is profitable and then it releases to transaction with appropriate gas fees In order to be picked up according to the decent descending gas fees inserting victim transactions so as to make a sandwich So the first transaction ta1 from adversary Will be the transaction trading the same asset as victim Transact X for Y which you can see so because adversary knows that the victim transaction Is trading a large amount of an asset which will be Increasing the price of the token eventually so adversary does the same trade prior to it Here by increasing the price of the asset which is which the victim trying to buy and As the victim transaction as a high-slip asset it will result the victim into a worse trade as Now its transaction is running on a modified price by the adversary and The adversary state has made token Y more expensive to buy by buying it beforehand Before the victim transaction So the victim transaction will result into a least amount possible And afterwards it will back around the victim transaction By selling the white token at a higher price with transaction e2 ta2 So what he it's doing is selling the white tokens for X to get his X tokens back And here by ending profit and X tokens So which will more than which will more which will be more than what it initially had And that all will come from the victim's trade Moving on there's another variant called Performed by liquidity provider so sandwich attack can be made by providers at well So again the motive is same from front running and back running a victim transaction So how it's done here so again adversary sees Transaction and observe the profitability out of it The liquidity provider releases three transactions here Firstly in the adversary front turns the victim transaction with ta1 by removing the liquidity So what will happen? It will increase the unexpected slippage for the victim and then at Enter in transaction ta2 It restores back the liquidity by adding the liquidity into the pool By back running the victim transaction and then finally it transact to Y again to get his tokens how to get X tokens To make the To make its X tokens equal to what it had prior to the attack So again a very simple trick to make a sandwich out of victim transaction and unprofit So now we know that sandwich attacks or what sandwich attacks are and how are they executed now? Let's just talk about how we can prevent them. So let's just take a quick intro to zero knowledge proofs We'll try to understand these zero knowledge proofs in a very simple example with a very simple example So Actually, what are zero knowledge proofs? So you can take them as like our way to tell someone that you know something without actually sharing any information about that thing Yeah So let's take a very public example to understand it Considering there are two users user A and user B User A wants to sell two boss to user B But the condition is he wants to reveal the boss to only that person who will actually buy the boss and Doesn't want to share any information about them to any other buyer because a buyer can cancel that trade in between but Will also get the info about the balls So on the other hand the user B wants to buy two balls, but the condition is she want them to be of different color So here in the scenario What user A will try it will try to sell the two balls without sharing any for me information about them But it's still making user B believe that they are They are actually of different color So he will put a blindfold on our eyes and get the boss to her Now user B wants to verify whether they are actually of different color or not or user is just bluffing or Lying about it So what she does she put the balls one in each hand put our hands back behind the back And now she can decide whether to shuffle them or not So if the balls are actually of different color then user A will be in a position To find out whether she has shuffled her hands or not So let's assume This first time user A correctly find out whether she has shuffled the balls or not or shuffled her hands or not But there's a chance that user A just bluffing or just making a wild guess out of it Because yes, it is possible. They are just two balls and the probability of Making a wild guess here a wild guess here is just one by two or half of it So but user for the first time user A correctly finds out that whether user B Sheffold the boss or not but user B is not satisfied yet because as I just told her she as I just told her user A can Make a wild guess out of it. So what she does she repeats the process one more time now the probability of making a wild guess for user A will be one by four So user B can repeat this process as many times as she wants until she gets satisfied Because we know that after an n number of times The probability of guessing or making a wild guess will become so small that it will become almost impossible to make a wild guess for user A Now user B has verified after a certain number of attempts that what user A is saying is right and he can't make wild guesses these many times and Hence the balls are actually of different color and now she can buy the balls and trade will be successful So this way user A has sold the balls without even sharing any information about them So this is a very simple example of zero-knowledge proofs So zero-knowledge proofs are of two types interactive and non-interactive. So the one example you are seeing Which I have just given is an interactive one where the proof The proof of user A and verify user B both are interactive with each other. There's also a non-interactive proofs Sphere a proof of sense the proof and the verify I can verify itself so Moving on to the next slide There are three important parameters for zero-knowledge proofs or mandatory parameters for zero-knowledge proofs to satisfy the first is completeness where It if a statement is true Then the verify will be convinced that proverb possesses the correct input Second is the soundness. So here if a statement is false Then no dishonest prove or can convince verify that they have the correct input Thirdly the zero-knowledge parameter So if a statement is true Then no verify learns anything other than the fact that the statement is true, which we have just seen The user B while making the trade just had an idea that whatever user A is saying is true Without getting any other information about those balls So this is what your knowledge proofs are now I'll ask my partner Mr. Google Alex to share more about zero-knowledge proofs Zika snugs and How we can use recommend and recursive proofs to prevent these sandwich attacks over to you, sir Thank You Tejas for setting the context of The sandwich attack the front-running attacks and how the problem is becoming a really a big challenge for the decent place finance protocols on Ethereum and other Led ledger systems now we are going to deep dive into the system of zero-knowledge proofs and understand how we can address or try to address the problem of front-running and back-running and the sandwich attacks through zero-knowledge systems This paradigm of zero-knowledge proofs were invented by three brilliant researchers in MIT Massachusetts Institute of Technology Professor Silvio Micali, Shafi Goldwasser and Rackoff and All the three they came together with a groundbreaking conceptualization about probabilistic proof systems Which was in infancy till 1980s So when we look at the history of zero-knowledge proofs 1985 is the time when this concept was proposed but the it was written in a Seems it was published in a scientific journal like scientific American and By 1992 We could see that the research on zero-knowledge proofs have grown has rise in exponentially and We got something known as succinct zero-knowledge proofs or space-efficient zero-knowledge proofs and Earlier there were two paradigms of zero-knowledge proofs the initial initial architectures were about interactive proof systems but in the interactive proof systems are not feasible in all the situations and thus a non-interactive system Argument system has its own merit when we look at a distributed system setting. That's when that so initially non-interactive proofs came into emergence and then by 1992 Succinct zero-knowledge proofs came into existence ever since 1992 We are we have seen a lot of research into the Various ways in which we can realize non-interactive zero-knowledge proofs and Pinocchio Which was invented or which which was conceptualized in? 2013 has it's a milestone. It's a It's a breakthrough real breakthrough because this Has first time in the history of the probabilistic proof systems made Non-interactive proof systems as Really practically possible like you know, she was something Pinocchio was something that we can realize and in 2016 growth 16 based Pairing the the growth 16 is all about Pairing based cryptographic system elliptical curve based Non-interactive zero-knowledge proof system and it it really opened up the way for Introducing the zero-knowledge proofs into blockchain platform and that has been the dawn of Zero-knowledge proof cryptography in in blockchain systems and then the size of the proofs and Need for trusted setup these were two Constraints in all the zero-knowledge proof systems and that's what that's the challenge which is addressed by ZK stocks in 2018 by Professor Ben Ali Sassoon and his team now when we Look at the zero-knowledge proof system closely How is it a radical change from the status quo? It can be seen as a transition from Client server architecture to prove a very fair architecture Hence we can say that This is more I know more of an objective ontology for web Worldwide web and internet because client server architecture is Something at the root of it. It says service oriented architecture looking at web as a collection of services But web has gone beyond just services web is now web connecting Systems of meaning systems of engagement systems of Truth systems of trust and hence we need something more than a client server system and that's where the prover very fair Paradigm becomes very very prominent and relevant Before we deep dive into zero-knowledge proof systems further we should understand that these are not the only Privacy-preserving paradigm or privacy technology that is being used in blockchain systems Since we are talking about block village Presentings proof systems in block village our focus would be on What are the ways in which these recursive and recurrent proof systems? revolutionize or have the potential to revolutionize the the privacy-preserving paradigms along with ZK Snarks ZK Snarks is the zero-knowledge proof system used in Zcash and many other protocols along with it we have Protocols other privacy technologies like coin join ring signatures and nimble-wimble You can see which all projects have implemented these privacy-preserving technology coin join being used first time in dash ring signature another Milestone and the revolutionary privacy-preserving technology that is used in Monero and Mimble-wimble used in green and beam When we say privacy-preserving technology this There are two major Priorities or the purpose for using privacy-preserving technology either to hide amount or hide the addresses when we look at the Zero-knowledge proof system now we need to understand zero-knowledge proof systems in a little bit more closely and now when we try to do that we can see that zero-knowledge proof systems work through initial trusted setup that is If I tell you broadly zero-knowledge proof systems can be classified into systems which require trusted setup We call it a ceremony or the zero-knowledge proof system which doesn't require trusted setup and There is another classification Uh, what is it a contextual snark or universal snark? snark stands for succinct non-interactive arguments of knowledge as you see in this diagram When you look at the life cycle initially we set the Parameters for the ceremony and the trusted setup Then we do the key generation There where we have some residue toxic. It's called as toxic waste and which has to be removed and After that there will be a common reference string which is which Is produced by the witness and then there is an arithmetic circuit The so there we should understand that there is a Transformation of proof from an argument of knowledge into an arithmetic circuit That happens in zk snark system This is very important any arbitrary program any argument of knowledge could be converted to an arithmetic circuit This is the kind of transpilation a transformative compilation that happens which which helps us to digitize the arguments of knowledge That is what makes it very relevant in a Blockchain like system or any other digital decentralized distributed ledger While we look at zero knowledge proof as at the data level there is subtle difference between the zero knowledge proofs and the utxos in bitcoin In the utxo, it's something about the input that you give and the output that you generate And the output of the previous transaction becomes the input of the next transaction whereas There is an aggregation of inputs The what you see is inputs are Transformed to output and then you generate a proof So the proof is an intermediary step Then this proof connects adjacent transactions This is the very simplistic explanation of the difference between utxobase ledgers like bitcoin And others and zero knowledge proof systems When you look at the construction of a snark What is very important is This here we are seeing The succinct non-interactive arguments of knowledge snark being used for a Circued sat is a kind of NP heart problem which is used in which is used for Proving the difficulty of a lot of algorithms. So this is a circuit sat problem. So you have to convert a circuit into Quadratic arithmetic program. This is the codification happening So this kind of a NP heart problem can be solved using The the binary sat problems. There are different kind of sat problems. These binary sat problems Can be solved using the construction of a snark And snark this is this here we deal with a snark where there is a common reference string You can see that the sat is the sat is sat stands for satisfiability, right? So A binary circuit is codified into A expression a mathematical expression. This is known as a quadratic arithmetic program expression And that is the one powerful possibility from zero knowledge proof. So any circuit any kind of a Circuit system arithmetic circuit can be converted into an expression A cryptographic expression or NP heart problem This is a more detailed view of such a circuit. So on the left side, you are seeing a circuit system Where we have different points of multiplication and addition in a circuit and we are seeing how we are converting This circuit into A A kind of A kind of logical expression. So this is where We can say that zero knowledge proof systems convert Initially, they convert an arbitrary program into arithmetic circuit and from arithmetic circuits. It becomes a probabilistic proof A probabilistic logic a logical proof expression What are the components of zk snark? see the what you see in the previous slide is Eventually when you depict it in a matrix representation, it is called as rank one constraint system are one systems. That is a specific kind of matrix Matrix representation. So we have Initially an arithmetic arbitrary program is converted to an arithmetic circuit and from there we generate R1 CS rank one constraint systems and from this rank one constraint systems, we can produce quadratic arithmetic programs and we can produce linear proofs So initially there is a Computation at the hardware level where you could use FPGAs a six or any kind of GPUs for this computation From the computation, you are producing an algebraic circuit Which is converted into a rank one constraint system Which gets transformed to a quadratic arithmetic program Which gets converted into linear probabilistically checkable proof that is called pcp. This linearity is very important because we look at these every replicated state machine in blockchain as a linear state machine. If it is a non-linear state machine like a chaotic cryptographic system, then it would be a different paradigm altogether. So the use of R1 CS and quadratic arithmetic program is very important and we should get linear probabilistic checkable proofs and linear interactive proofs which eventually becomes the zero knowledge succinct non-interactive arguments of knowledge. So finally, the the initial part is done by the prover and the witness and finally we have the verifier The verifier verify whether it's a zk snark. This is about zk snark systems So what let's now reflect on this life cycle of zk snark It transforms arguments of knowledge into arithmetic circuits and it's a transpilation of circuits into R1 CS and the quadratic arithmetic programs. This diagram on the right side shows it a little bit more in a very simple manner. When we have an expression we need to prove. For example, we want to prove that the two is a even number or we want to prove that seven is a prime number. We have to convert that into an arithmetic circuit from that we are synthesizing a rankable constraint system which gets using inverse fft, inverse Fourier transform which gets convert to quadratic arithmetic program and then it is fed to the prover. Prover generate the proof and send it to the verifier. Verifier verifies it. The same quadratic program when we have a trusted setup we generate the parameters. The parameters the way that there are two keys verifier key and the prover key. Both prover and verifier work with their respective keys. So this is completely an asynchronous computing, asynchronous computation that's the power of it. It gives great security in an asynchronous setting which is very very strong requirement for various distributed systems like digital identity systems, various voting systems or various kind of financial and non-financial use cases. Now we have to think about the what is the how zk snots and generally zero knowledge proofs are relevant to cryptocurrencies. First we start with an expression, an argument of knowledge like we want to prove that we have to check the legality of a transaction. For example we want to verify if this escrow contract is legal. First we have to flatten the escrow logic or the escrow expression into a circuit that gets converted into a rank one constraint system and then through inverse Fourier transform it gets converted to a quadratic arithmetic program and then it we send it to the prover. First prover creates a transaction, off-chain transaction. Prover is an infinitely powerful Turing machine and the verifier is a finite Turing machine with limited power because verifiers most of the times in the cryptocurrency settings verifier would be a smart contract or a particular system running on a replicated state machine in a blockchain. So that was a good introduction, that was just an introduction to the zero knowledge proofs. Now we have to see the larger spectrum, this has been a Cambrian explosion of zero knowledge proof in the, if I use the words of Professor Elibin Sazon. So there are different kind of snark compilers, pre-processing snarks where we pre-process some of the proofs and then there is a dark compiler, then there is a normal snark compiler. Snark compiler could be linear proof or linear encoding. Then we use different kind of fields and groups for creating commitments. The commitments can be different kind of commitments, it can be polynomial commitments of different type such as Pedersen commitment or recently there is a new commitment which is being introduced in Ethereum and the proofs can be algebraic. So algebraic proofs are used in pre-processing snarks, linear proofs are also used and in systems like Stark cryptographic hash functions and random polynomials have a lot of importance. There are three types of groups we can use, groups of unknown order, generic groups and bilinear groups. Bilinear groups are commonly used in linear encoding systems and groups of unknown order are used mainly with dark compiler. So we can also classify proof systems into the proof systems which use common reference string and the proof systems which use structured reference string. So common referencing is the simple implementation and right now there are a lot of innovations coming up. We measure the performance of the systems based on the proof size and the verification time. So there are a lot of them as you see in this diagram. Prominent CRS based systems are Hallow, Bulletproof, Fractral and Aurora. Recently new things are coming up like Spartan Supersonic which are very fast. The slower ones are like bulletproof systems, Aurora, Ligero etc. Aurora Lite has been introduced with a structured reference string and the elliptical curve that we use that's also a differentiator. Growth 16 has been one of the most popular one and BTCV and MNT are also some other elliptical curves being used. Okay now let's proceed to the next slide. Before moving I just moved a little faster. So the next slide what we need to in this particular presentation our focus is on recursive and recurrent proofs. How they are very useful for addressing sandwich attacks in DeFi systems. This is our proposal. Recursive logic has been implemented or recursive proofs have been implemented in a lot of systems, zero knowledge proof systems like Hallow. Hallow is one of the most popular examples of recursive proofs. We will deep dive, we will see the recursive proof systems in a little bit detail here and then we would like to propose two other set of logics based on incrementally verifiable computation which is another white paper published by an MIT researcher. So we would like to propose identity logic in space and time along with the inductive and iterative logic of recursive proofs. Moving on to the next slide. This diagram, so I just want to show you briefly what is the how the an example of a recursive proof. Recursive proofs, eerily recursive proof systems were constructed using trusted setups and cycles of expensive pairing friendly curves. This is an example of a recursive proof and if you look at an example of a recursive proof construction, this shows how do we generate one proof which becomes the input to the another proof system and there where how do we do recursion. So these two are based on MNT4 curve. One is based on MNT4 curve, other one is based on MNT6. These are two different kind of elliptical curve systems used in MINAP protocol which was earlier known as CODA protocol. Here we can see the example of recursion. So elements of a recursive proof system are the mainly incrementally verifiable computation is at the heart of recursive proof systems. So this is at the heart. We can use them to the use cases are to verify the sequence of order of transactions. The one core concept of recursive proof systems is proof carrying data which can be extended to obtain verifiable distributed computation. Hallow is a very popular example for a recursive proof system which has been proposed for various voting systems. Voting can be considered as a recursive proof activity because we you do the same operations in a hierarchy in a recursive way. You vote across the for example you do the same voting across countries in countries they do voting is in different states continue that in districts or smaller local governance units. So Hallow and Hallow 2 are two proof systems with a lot of recursive features. Now let's move to the next slide. Now we are we are just trying to understand the Hallow proof system. Hallow proof system consists of a polynomial commitments scheme which we mentioned earlier and it uses inner product as the arguments are based on the inner product systems. We know outer product and inner product in sets groups and rings. Here it's based on inner product arguments and it is a polynomial commitment scheme. It also uses a cycle of elliptical curve. The here is an important point the cycle of elliptical curve with proofs constructed on one curve that verify the proof constructed on the other. This relationship is very very important for recursion and which is very very useful for reflexive proofs and recurrent proofs. This makes our proposition a real possibility recurrent proof system. Recurrent proof system we are highlighting the importance of time the dimensions of time and space together because that is the only way we can prevent attacks from the attacks like the front running attack and the back running attack. Time transitivity of proof carrying data will be a metric and then time is truncated because proofs have ability to condense, compress the data. The time transitivity and time truncation capability of PCD, proof carrying data is harnessed here and then so the time variable time becomes a dynamic variable here that any changes in the linear metric of time will be considered as a time turbulence. We are introducing a time turbulence verification between the different actors in the NEM pool. That is what we are proposing in recurrent proof systems and recurrent proof systems will be composable. We want to use it in a multi-party computation setting and then it will be made portable through interoperability between the proof system. That is the long-term road map. Initial road map is to achieve time transitivity in proof carrying data and then time truncation and time turbulence verification. This will become clear to you when you see the solution architecture. So we want to give little bit details about time truncated proof systems. As we have mentioned about probabilistically checkable proofs, PCP. PCP is a vast area in photography. PCP theorem is something everyone should refer if they are working on zero knowledge proof systems. PCP systems enable proofs to be verified in time polylog arithmetic in length of a card classical proof. This is why PCP theorem is at the heart of zero knowledge proof systems. The main equivalence is proof of knowledge is equivalent to time-space complexity. This equivalence is leveraged or harnessed in building time truncated proof systems. So you know from earlier introduction by Tejasway you know that the soundness, completeness and the zero knowledge property, these are three properties. So soundness is very important. Computational soundness is very important for probabilistically checkable proofs and that helps to shorten the length of the transmitted proof. So transmission of proof is very important. We have to we have to understand the proofs are transmitted between different actors in a probabilistic proof system. That is the benefit we are leveraging to create time truncated proof systems. Moving on to the next slide. So let me show the next slide. The recurrent proofs are the proof systems where prover uses space polynomial in the space of classical prover and time. So recurrent proofs will be a kind of metamorphosis between the space variables and time variables. That is why the prover becomes the time in which prover act on the proof is used to generate a time sensitive space polynomial. And it is the assumption is that this polynomial will be a linear polynomial. And when verifier verifies it, it will be a constant. That's how we are able to achieve it in a I mean, we don't get into a NP hard situation because the very fair verification happens in a constant time. So we would like to leverage this part and proof system for this recurrent proof construction. Moving on to the next slide. Let us show you the solution summary. The main thing is as you have seen, the crux or the fulcrum of the attack on the sandwich attack happens on the mem pool. So the access control to the mem pool will be through proof of order and proof of hierarchical access because we are using recursive recurrent proof. We will be able to generate proof of order of transactions and proof of hierarchical access because in the near future, Ethereum is going into use incremental different Merkle trees called Verkle tree that will be launched in the near future by the Ethereum engineering. So our prover will be time optimal transaction prover using Spartan proof system and we will leverage the recursive proof system of hello to the proof carrying data at the will be used for storing the contract execution order on zk snark and transaction ordering will be done through a new cryptographic library that we will create called triangular time loss. Triangular time log will be a new constraint system which will be built using the zk stark of stark where so this we are trying to we are trying to propose a system a hybrid of zk snark and zk stark where there will be triangular time logs. We will detail the anatomy of triangular time logs in one of in our roadmap while we are working on it. Currently we are working on triangular time logs. We have extensively worked on verifiable random functions and verifiable delay functions so but this time this is a triangular time lock will be a time lock which is dynamically created at a particular space time trust instance. So this will be very useful for sharded distributed ledges which are sharded so triangular time logs we are introducing for sharded systems for initially we will come up with this contract smart contract based deployment and later we will apply this into our proof system. So this is one of the first system with hybrid hierarchy of zk snark for access control and zk stark for the transaction ordering. So recursion for recursion we are leveraging zk snark and for time locking we use the zk stark because that's more faster even though the proof size is bigger but when you look at it time is a time stamp or any time property in a distributed ledger this is not big in size so that's why we are confidently using zk stark system and stark where zk stark it has been the best performing stark system in the recent times. So the second one is this will be the first integration between the vdf triangular time logs vdf and zk starts the zk stark already they have an integration start pair but we will the this will be one of the first hybrid hierarchy of zk snark and zk stark and this will be one of the first system where the the vdf will be integrated with the triangular time lock and let me quickly take you to the diagram the architecture diagram of our proposal so this diagram shows you how the how we are going to leverage recursive proof and redundant proof recurrent proofs one on one side we are doing transaction ordering second side we are doing transaction timing this helps us to create a very versatile prover which can make sure that the transaction that comes is coming from the the real node not from a spy node or adversarial node and then it can be verified by the a very fair so this is where we the all our changes are happening in the provers not in the very fair side hence we are expecting that this will be an interoperable system for multiple kind of zk snark and zk stark but this is our uh the research early research we have a lot more to work on this area and we we are really happy to get this opportunity to present this in devcon and thank you so much for giving this opportunity to devcon 29 block village and thank you all for listening to us you can we will share the presentation with more details with the block village team