Implementing Auction-based MEV Protocol on fast EVM Blockchain

Transcript

Hi everyone, thanks for joining my session and it's Louis from the Kaya labs and I'm currently taking a role of the core protocol engineer at the Kaya labs which is the high performance layer 1 blockchain based on the asha region mainly and today we I'd like to share our experience and the implementation of the building the auction based MAB protocol for the high performance blockchain which is the kaya for our case and uh we like to share our knowledge and insight and also discuss with you guys. So before deep diving into the our MAB implementation we first need to know the basic knowledge of the Kaya because the MAB protocol is really depending on its

own settlement I mean the base the blockchain itself for example Ethereum has its own MAB solutions and Solana and Aum recently they released the time boost and something like that. So the Kaya is the the basically the fully EVM compatible high performance blockchain and we support support any EVM tools like hard hard foundry or something like that and we are fast we've been over five years and we better tested better tested scalability the 4,000 practically and we marked the over 8,000 transaction per second in the real world and one second finality thanks to the BFT based consensus algorithm

And we also support various cast abstraction like the feed delegation natively and also we recently released the native cast abstraction that can be used for the many web two users who try to use the blockchain with the their own token like the air dropped mini token or the USDT recently we on board since the we on board the native USDT tether recently or something like that. So the thanks to the I think you guys are aware of the miniaps by the live miniabs or the recent kayas many the token gener in the events due thanks to the the live miniaps and the native st coin we expect the increases of the

onchain trading use which naturally leads to the the activity the increase of the m activity. So basically when the user send the I I I know you are all aware of the expert of the MAB but let me just briefly introduce the the simple example of the MAB. So when the user send the the the last swap transaction the DAX like the A token to B token then there can be the the price difference between the DAX or the pair. So other arbittors can capture the value and they can send the bank run transaction to extract the value which is the the MB.

So, so I know you you're aware of the ME but just like here the lead let box transaction is the usual transaction and if the arbitrageer or searcher found the transaction is profitable then they can make a bank run transaction or any other transaction that can extract the value from the user transaction and they can broadcast the M transaction to the M pool and the broadcast to network and can be mined and earn the reward profit from the user transaction. And there are typically three types. The first one is a bank running which which literally the run right after the user transaction. So red box is user transaction and the searcher will send

the transaction that will be executed right after the user transaction. And also there's the front learning which is which is executed right before the user transaction. And there is the combination of the bank running and front running which we call sandwich. And usually user will have some will suffer some the you know price changes due to the front learning and the bank running also get all together. So the issue of MAB per from the perspective of the layer one blockchain engineers lay one blockchain since the kaya is a layer one blockchain. So if this transaction have the same gas price, it's actually the first convers

and the searcher will send the tons of transactions to increase the chance of inclusion of their transaction because it's FCFS and the MAB profit is quite centralized to the searcher and the searcher usually requires lots of resource like the engineering resource or the node management or something like that. So am proof is quite centralized and we cannot also prevent the malicious action of the validator because validator will finally mine the blog and they can replace the searchers transaction to its own transaction.

So there can be two option first of all we can ban the amb activity which is not which is very the approach and invisible actually because we are public blockchain. Anyone can send the transaction and anyone can see the man pool. Anyone can check the transactions on the blockchain. But instead we can make the MABB more fair and transparent and profitable for all ecosystem users. And this is what we want to do. So our core idea is to introduce the public auction market of MB chances for the searchers and the distribute the tip I mean the bead from searcher to the all the ecosystem to enhance our the you

know something like the liquidity or we can use the the T for the our old ecosystem like the making some bond all like that. So before diving into the actual implementation, we first need to look the our requirement. So actually we are high performance event blockchains. We have only one second to make the all the bank run transactions and the transition into the block. So we need the first of all we need the stateless auction client which means the auction client is the the independent server that process this the beat from the searcher and select the winner and send it to the network.

But state list means that we can remove the state part from the auction client server. For example, if we need we need a state then we maybe we need to update our client itself. For example, modify the gas client in the Ethereum for example or modify the Solana client like the JO or something like that. But we do not want to that because we want to reduce the auction time and the auction time heavily relies on the verification itself. And if we can successfully introduce this stat list verification then we can reduce the auction time and we can have more auctions be from the searcher and we can reduce the latency of the user of course and uh also

stateless auctioneer will help the the client manager I mean operator who want to operate the cl the auction client which enhance the decentralization of the our m protocol And we also want to make this this as the sidecar feature not only consensus not affect to the our consensus and we we also need like to the minimize the node burden due to the this MAB protocol. We do not have make the our consensus to work due to the MAB processing the MAB transactions or so anything related to the MB.

So ideation is like the simple as I said before the we need the stateless auctioneer which is the basically the independent server that process the auction. So it process the auction from when there's a request from the searcher searcher will send the target transaction and the bid and the auctioneer will start the auction with the certain duration of time. We call it the auction in pool and send the auction result select after selecting the winner and to the send it the final result to network like the validator to recast the the inclusion of the beat regard into the block finally and we also need to verify if the CN I mean I'm sorry CN is the the terminology used in the Kaya

network sorry you can check the C you can understand CN as the validator the verified if the validator properly process the winner's bid. It means that the validator can still ignore the output result from the auctioneer they can replace the bid or they can ignore the bid or they can hide the hide the profit of transactions like that. So we need to capture we need to find monitor the any malicious action from the CN not just processing the auction and for the validator they need to obviously they need to process the auction region received from the auctioneer and they need to finally order and execute the bid transaction.

So yeah this is basic the the the idea of the they when the transaction enter to the network then the auction participant who is the actually searcher or arbitrageer they when once they found the the profit of transaction then they like to insert their transaction right after the user transition like the bank running case actually we do not explicitly allow the pronunning feature to reduce the any attack and any sufferers from the sufferer of the the the user.

Anyway, this is the overall structure. So you can check the the lead number and the green number. So even if we release the MEB protocol, there will be still some searchers who don't want to use our MEB because if they use our auctioneer, they need to pay the beat. It means they need to split their profit to the ecosystem. So they try to avoid using our protocol. So there will be some non auction searcher who will capture the transaction from the network and send the bankrun transaction. It is still possible because we are public blockchain. And also there is the auction searcher who want to use our

auctioneer system. They also capture the transaction. It is same but they send the bid to the auctioneer rather than sending them sending the bank run transaction into the network directly. So after the auctioneer receive the bid during the auction interval auctioneer will select the bid winner speed and send it to the network. I'm I'm sorry again the CN means the validator and you can ignore the P and EN some other they are you can just um understand it as just the some RPC node like that CN is the validator and the other is the just simple RPC client and after that we send the data to the auction wizard and check it for the

auction auctioneer monitor who verify the the action of the validator itself later but there's some problem. So as I said before we need the auction interval put to process the auction because we need to retry we need to you know accumulate some bead from the searcher to select the winner. So we cannot just send a result once we receive the one one of the searcher but we need to wait to get some searchers be enough speed and select the highest speed and send it to the network but we can think of this this situation. So non auction searcher will keep sending their transaction not

through the auctioneer but the auctioneer the auction searcher will send their bid to the auctioneer but they need to wait to wait until the auction interval. Then if the target transaction is the already included in the network and uh if the winner's bit arrived at the validator later then their bit is just discarded and no no searcher want to use our protocol. So we must solve this problem to make the searcher to use our protocol burst.

So to do this it's inevitable actually to introduce some delay. So we need some delay and for this example it it elaborates more about the problem I shared before. So there's a the some interval for example we have 1 second block time. So there's a zero millisecond to 1 second and the this time duration the transaction during this the time interval will be included in the right app right this the block. So if this transaction is profitable then the searcher will send a bit through the auctioneer and the auction result can be arrived at the validator before the mining.

But after some time if we if the searcher find find this transaction is the profitable and send some bit to the auctioneer then their bit wizard cannot be included in a block because they are lastm minute transaction just before the mining. So we need to solve this problem by introducing some delay buffer which we called it the early deadline. So as I as I explained before the it's inevitable to introduce the buffer delay which we call the early deadline. So the transactions arrived after the buffer they cannot be included in the this block but the next

block. To do this searchers can think that searchers can send a bid for this transaction for the not this block but the next block. So in the auctioneer's point of view the there are some the serial of the transaction on the user side and they will be broadcast to the network like the the EN which is the just RP client and they will send it to the another peer node and the auctioneer and they will finally arrive at the CN.

But as you only know that this transaction arrived after the early deadline will be included in the next next block. So searchers can we can guarantee to searcher that this transaction the beat for this transaction also will be included in a block with the target transaction not just the beat alone. And actually we there are some other challenges we faced. So we actually need to prevent some obusing from the searcher and the valator. So if the searcher for example since we select the winner and send the winner speed to the network then we can

think that the winner speed will take place the will take the slot of the the block in a block. For example, when once we send the winner speed to the network, then the the slot right after the target transaction is allocated to the that searcher. But what if the searcher can make the their bit transaction will be always reverted in the event transaction? Revert means there is not there nothing happens except the gossy and nonsense like that. So it means that the bankrunning opportunity is still alive even if we select the winner's speed. It means that if the searcher can

make their bid always reverted then they can send the alternative bankrun transaction not through the auctioneer to the network to to try to not pay the beat to the network. So this is the this can be happen to to ignore the our auction system try not to pay the bid. So due to this reason we cannot let the searcher do everything but we instead the some kind of the we borrow some idea from the EIP4 I'm 437 I will explain it later. So, oh, sorry. Give me give me a second.

It's really hot here. Anyway, we cannot let the searcher do everything, but instead we can make the valator to execute the bead on behalf of the searcher. It means that we can take control of the the transaction of the the beat from the searcher and uh we make the searcher always pay the beat and the gas refund if the given code data which contains the bank running logic from the searcher is successfully executed. The P the the gas means that since the valator is the message sender in the of the transaction, the B letter will pay the gas fee first and get the refund after the searcher transaction

and all these things will be executed automically which means the in the same one transaction and we can also check the if there can be there is possibility that the CN the validator can do some obusing for example they can replay the searchers searchers be to extract the beat from the searcher. They keep replaying it. But we can ignore we can avoid the situation by simple nonstings. And uh we also can imagine the situation like the CN can manipulate the bit and uh there are there can be the another searcher uh the auctioneer who mimic the original

auctioneer and send some beat to the network to interrupt the system. So we include the the signature of the auctioneer client to verify the beat is legit and the bit cannot be replaced. So to implement implement this we borrow the sum of concept from the EIP 437. So in the 4337 there's concept of the user operation which is signed by the user and the user send the user operation to the bundler and bundler will sign and will sign the transaction and send the transaction through the through the bundler. So we can think of the user as the searcher and the user operation like the beat and the final bundler is the

auctioneer client. So in here same same idea the bundler will pay the gas burst and get they get refunded in the single transaction in the au the entry point smart contract and there can be some concept of the pay master or something like that and we have we do have similar concept and we have the auction entry point which manage the searchers nons to rep to prevent the replay and to validate the bit transaction.

and execute the user's transaction searchers transaction like the user of in the EIP 4337 and we also have the auction deposit B which manage the searchers deposit and withdraw for the bead and the auction deposit B we take the bid from the searcher and gas fee also from the deposit. So in the auction entry point there it will call the auction depos when it want to when it it will take the beat and gas from the searcher and this is the whole this is the whole the diagram simple diagram. So first of all there's the uh uh the auction transaction call please

note that the the message sender is the valator. So first we do some basic validation like the block number or bid amount and auctioneer signature and EIP712 and searchers nons and after the verification passed and we start the bid processing we deduct the deposit from the searcher and take the bit to the the our fund and refund the gas to the the validator or something like that. check the validation and uh take the rear beat and the execution page is simply execute the call data with the call data from the searcher and finally we get the gas refund actually gas refund that happened

here. So if the any of the process other than the execution page failed we all reverted. So you you might have some question because the if the transition is reverted then the valid error will will you know ru some goss fee. So to to avoid this we introduce some core client changes but due to the time matter I will skip that part. So sorry for that. So we can re recap the auction process.

First of all, searcher need to deposit the some Kaya which is a native token on the Kaya network to the auction deposit contract and the auctioneer will detect the new deposit event and register the searcher's address as the valid searcher and at once the registration is done searcher will send can send the send beat and uh once selected as the winner will send the winners the beat to network and at the same time auctioneer will accumulate the datab data of the bit beat bit and the block produced by the validator to use as the fraud monitoring explorer bit explorer and graphana dashboard which means the

there's some some internal uses or the public information channel and uh we will step by we will look into this step by step. So the first of all as I said before the auctioneer subscribes the info of s searches from the smart contract in the event blockchain the we can subscribe the event of the the event occurred by the execution of smart contract. So there will be the the predefined event in the each smart contract and searcher

whenever searcher do something searcher interact with the smart contract auctioneer will event listen the all the activity on the network which happened by which occurred by the searcher. This is required since auctioneer is stateless. Auctioneer cannot directly query the state of the auction deposit board and auction entry point but rather it keeps the listening subscribing to the it's the peer net peer the node on the network and the auctioneer will keep recording the for example searcher one 300 kaya deposit and non 17 and so on so on

and after that the to enhance the transparency. For example, there is some node provider who want to hide the transaction to to you know get the all chance of arbitrage itself. It can hide it can pre it can you know it doesn't broadcast the transaction like that. So, but they will eventually arrive at the valator and we'd like to enhance the transparency and we want to give the equal chance to the searcher. So to do that we will listen the pending transactions which

there is a Q transaction pending transaction and the pending means the executable transaction that will be included in the right next block and the validator will send the pending transaction to the auctioneer and the auctioneer will also the broadcast the the pending transaction to the searcher and this is not mandatory. So if searcher have more information I think that is impossible but anyway searcher do not want to waste their computer resources to subscribe the pending transaction they can just you know the result from the auctioneer and their own manage their own node client like they watch their own man pool something like

that and uh once the profit of transaction is identified the searcher will send the bit start sending the bid to the auctioneer and the bid is the simple RIP encoded this the some series of the data there will be target transaction of calls and there will be long number sender n and two address and the call cost limit call data bount and so on so on and they will sign the this RP encoded data to to prove the to to prove the bit is really come from the searcher and Auctioneer will verify the block number, signature and nons from entry point and

bid amount like the they have the same nons as in the entry point and they have the enough deposit to pay the beat and the gas and once the after the auction in tobo we estimate auction in total like the 150 millisecond to the 250 or 300 millisecond we are testing it currently. Anyway, the after the auction interval, they will send the winners bid to the bell leaders and the result will be the some theories the the RP encoded data and the important part here is that it will be included the it will be include it will include the auctioneer signature

to prevent the validator to receive the bid from other auctioneer who mimic our original the verified auctioneer. So signature will be simple EIP 191 and this the validators will verify the block number searcher signature auctioner signature and nons from entry point and the bid amount and after the validator received the winner's bid and the target transaction it will start the ordering the transaction and the final order the final the order of the transaction and will execute the transaction. If the

validator is the proposer in that the view I mean the in round and the block number sequence which is the terminology using the the BFT. Anyway, they will order the if the bit transaction one has the it the target of the bit transaction one is the transaction two then this bit transaction one should be inserted right after the transaction two. If the validator insert the this bit transaction for example after transaction three then it will be detected by auctioneer and we can introduce some slash or we can kick out this from the validator set to to

monitor the auctioneers the the validators any malicious action and final bit will be the from is the proposer as I explained before and two is the auction entry point and the on other information. So we covered a lot of the topic today and I cannot put every details every single details in this slide due to time time limit but we actually covered a lot of things actually and first of all we look into the basic kaya architecture introduction and the basic MU concept and basic approach of MU solution from the perspective of the KA network itself

and we covered the implementation from the overall design to to the some key challenges we face like the early deadline to ensure the beat reser to be included in a block with the target transactions securely and also prevent the abusing from this consens the the validator and the searcher based on the thanks to the EIP I'm sorry 433748744 is the like the tank charging so like that and uh last of all we look into the step-by-step auction process And here are the references. So and uh we actually open source project. So you can check all the code here. And the

auctioneer code and smart contract will be public after the audit. And for if you have some um thoughts on having some arbitrage activity on the Kaya network. So we are actually pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl planning to provide some playground for the searchers to test the M protocol our auction based protocol and we also plan some bit refund event to reduce the risk of searchers. So if you're interested, please send us DM. You can contact us through the Louis encrypted which is my telegram handle or the Twitter or any other channel you can the you can have you can use and here is some the ad here. So uh some

of you guys may know that we are recently releasing the lime mini dabs. Actually the Kaya is the born merge of the the Clayton which is backed by the Kakao and the Finsia which is backed by the line. So we are recently releasing the mini and it makes us as the the most active e public blockchains on the network and we have the millions the 10 millions two 200 millions of the active users and uh we have so we are successfully onboard many builders users and we can provide some distribution channel with the qu with a verified user pool. So if you're interested in

building the mini dabs and have some you know have a if you want to on board the millions of users rather than spending billions of dollars on the web3 spaces please the join our movement together and you can register your ID or project on the web.kyo.io IO and also we recently released the Kaya stable coin and the tether USDT. They the we on board the native USDT on our network layer one blockchain and we also prepare many things for builders and

users to activate the stable coin the stable coin ecosystem on the Kaya network. So we are preparing the stablecoin summer hackathon. So if you're interested in the building the stablecoin the mini devs or stco coin things on the kaya network with the millions of users we have some builder support program for the builders. So please uh contact us if you're interested. And here's some the the link we have of course X and we have some de portal for the live mini devs and we have link tree link QR code for the link tree and the Kaya developers. So if you're interesting,

please check out the all the information here. And KA is the Aza super app chain and mobile first gateway to web three to many web two users onto the web three. And please join our movement together. And this is quite all from my presentation. So if you have questions, please let me know. Yeah. Thank you. No questions.

The current model, there's no way for users to get refunded for their value, right? Like for example, on mainet, you have math blocker and similar protocols that return the value back to users. I'm sorry, but could you repeat your question? Um, on mainet on Ethereum, you have multiple protocols that return value that they that users leak back to them. For example, in math blocker, when you do a bad swap, searchers will background it and refund the value to you. Is there any way to fit this into this model? Uh actually we we do not have the direct refund to the user who suffered the large slippers for example but we rather than the implic we rather than use the fund from the bead which is the actually the the loss of the user actually to the we want to accumulate

the be from be to the our own fund and we'd like we to try to deepen our liquidity using that fund or something like that to to enhance our our onchain defy. by the ecosystem. Yeah. Okay. Thank you. We can continue outside if you have more questions. Thank you.