BlockSec CEO Andy Zhou was invited to participate in the Spraping Bits podcast, and discuss the topic regarding how the BlockSec team identifies and mitigates potential security vulnerabilities in the tumultuous and intricate environment of Web3. Below is the curated collection of fascinating content we have compiled. To listen to the full version of the podcast, click here.
Andy Zhou 00:00
We have a system running in our team, which can detect the attack contract even before the hackers send the attack transactions. That's because they need to deploy an attack contract and then send the transactions to attack the protocol. So even before the attack transactions, when the hackers deploy an attack smart contract, our AI-based engine can precisely identify the malicious contract.
Andy Zhou 00:53
Thank you, DeGatchi. I'm also very honored to be here.
Honored. Thank you so much. Just for the people that aren't familiar with you, who are you and what do you do?
Andy Zhou 01:02
My name is Andy. I'm the CEO of BlockSec, and I'm also a professor in Zhejiang University, a top university in China. I have more than 10 years of experience in the cybersecurity area. Previously, I was working in the smartphone security area, then I switched to smart contract security for a couple of years.
What were your early days in smart contract security? Were you doing manual auditing, or did you skip straight to automation? Kind of like what I did.
Andy Zhou 01:30
For smart contract security, in the company and in our research team, we do both the static one and the dynamic one. For the static one, we have developed a couple of different techniques to enhance the static analysis of the smart contract. That's because most of the tools currently available in the community have some common issues, because they have too many false positives. For example, if you want to use the tool to detect reentrancy issues, you throw a simple smart contract into the tool, it may report many reentrancy issues or many other issues. But when you manually check this report, you will find most of them are false positives. So we find that false positives are the main issue with the current static analysis tools.
Andy Zhou 02:20
The fundamental reason for such false positives is a lack of understanding of the smart contract's semantics. Semantics refers to the meaning behind the variables and their relationships within the contract. For instance, if you have an ERC-20 token, it has variables representing the balance of each owner and the approved value, indicating who approved what amount to transfer to whom. To improve the precision of static analysis, it is essential to accurately identify which variables correspond to the balance and which variables relate to approvals and other specific functionalities. By doing so, we can achieve much better precision in static analysis.
Andy Zhou 03:00
One insight we have obtained from our experience in developing the static analysis tool is the need for a robust taint analysis engine to establish correlations between variables. Data flow analysis, a fundamental technique employed by static analysis tools, plays a crucial role. It involves modeling memories and storages, as well as how to precisely and efficiently leverage the taint analysis techniques within the static analysis tool. These two key techniques, taint analysis and data flow analysis, have proven highly effective in enhancing the capabilities of our static analysis tool.
Andy Zhou 03:48
In our research team, we developed and deployed this static analysis tool, and we analyze each new smart contract created on the blockchain. We will report the zero-day vulnerabilities we have identified to the developers. Unfortunately, some of the developers do not care about the vulnerability. And we even do not find the efficient channels to report to them. That's very sad.
Andy Zhou 04:13
If you want a very effective static analysis tool, you need to have the semantics, and you need to have a taint analysis engine. This is our experience with the static analysis tool. And aside from the static analysis tool, we also have a dynamic analysis tool in our research team. That's because besides the vulnerable smart contracts, we also want to identify malicious transactions, right?
Andy Zhou 04:31
It's not just about analyzing vulnerable smart contracts but also about detecting any transactions that may be attacking protocols or other smart contracts. To achieve this, we have a customized virtual machine with the capabilities of instrumentation. This allows us to write our own detection rule that can easily be hooked into the virtual machine or execution environment of any given smart contract. We capture various signals to determine whether a transaction is malicious or not. For example, we examine if the sender of the transaction has a history of performing attacks or if the funds come from suspicious sources. By combining different signals, we assess the risk associated with each transaction. Our team deployed this detection engine, enabling us to quickly capture and identify attack transactions.
Yeah, that's interesting. I've done the same thing with my static analyzers. The taint analysis is basically essential, but then use whatever you do with the static analyzer. You transfer all that data into a fuzzer, right? I was building my fuzzer as well. And it's really interesting to see how people approach it. But there are very interesting solutions. People think very sequentially within this space, and there are a lot of dimensions to think of, so sequentially is not the right answer.
Let's talk about the dimensions. Suppose you have the calldata of a transaction, right? You also have functions and the contracts. And then you also have the other dimension, which is the stage. So it's very context-dependent. And so now you have all these four different variables, dimensions, and they all impact each other with just the slightest tweak. So for example, you could have contract A, contract B, all of their functions. Now you have to order them in all these different ways, but there are not just the single one of function A and function B, function B and function A. You also have the ability to do function A, function B, function B, function B, function A. It's a really tough problem.
And I think what you've been doing with your stuff is quite interesting. I know you've advanced Phalcon recently to now include transaction detection. So it's more like a generalized frontrunner, but for hacks. And in doing that, it's very thought-provoking. And the front-running game is dominated by these dedicated MEV teams, right? And they do front-running, sandwiching, back-running, etc. And they have dedicated infrastructure, high-frequency trading stuff where the latency is very small, and they're partnering with each other, block builders, relays, all this stuff. So the question is, how are you able to front-run these transactions instead of these MEV teams?
Andy Zhou 07:24
Yeah, that's a very good question. Basically, the main target of our system is not to front-run the MEV Bots but to protect the protocols, and we're targeting the hackers.
But, like, when the hacker submits a transaction to a public Mempool, it, if it's private, nobody can get that. But if it's a public Mempool, then all the other generalized front runners are going to see that as well. So you've got to go to them. So how are you beating them? How are you beating them?
Andy Zhou 07:51
Yeah, we always say that security is an arm race between the good guys and the bad guys. It's easy in the early days because the bad guys do not know the existence of our team and the MEV Bot. At that time, it depends on how you pay the gas fee or how you pay the bribe to the validators. That's much easier in early times, but nowadays, the hackers use some technique to protect them from being frontrun. For instance, we saw a very interesting technique deployed by the hackers to prevent their transactions from being frontrun by the MEV Bot. Basically, in their transactions, they will first check some values, like fetching a certain value from another smart contract to check whether this certain value equals to the initial value of this variable. When performing the attack, the hackers will first send a transaction to set up the variable in another smart contract to satisfy that check, and use the second transaction to actually perform the hack. Because most of the common technique used by the MEV Bot is to simulate one single transaction. If you only simulate the second transaction, you will fail because the condition does not satisfy. That's because the condition is set up by the first attack transaction. Because of this tricky part, some MEV Bots cannot handle it. We can handle that because we have a technique to analyze the correlation of different transactions.
Yeah, you'd have to do multiples. You can't just do one because if you're just doing generalized front-running, the standard is to just replace the addresses, or if it's like multiple addresses, you have to replace them all, and you have to try every option basically.
Andy Zhou 09:52
If they're doing the multi-contract stuff with the setup, well, then they would do the contract deployment, and then they'd call a function in that setup contract set up to the new thing, and then they'd use that in the exploit contracts. But the way that you would fix that is basically like simulating again, but you would have to actually just check the state of what's being called. And so if that doesn't match the deployment state of the original contract, then you have to set that somehow, find that function like a CFG, find whatever that was, and then modify that exploit contract to set that as well, or even just remove it completely. So that is quite difficult, but it's crazy that you've actually done this and now it's working.
Andy Zhou 10:33
Yeah, it's working, but you need to make many development efforts to do that. And you also need to have a very good and efficient analysis engine for that.
It's very impressive. You guys have prevented 20 hacks and around $15 million in losses already. And that was within six months before you launched.
Andy Zhou 10:51
The prevention of hacks has been done for the past one and a half years. So it's not in one month or two months. It's a continuous effort over one and a half years.
But still, there's no one else doing this. It's a really great thing, and I think everyone should at least have it because it's an important thing. And even though it might not be 100% savior for everyone because they have to sign up, maybe there are some barely obfuscation techniques that would be different. It's still better than nothing, right? Like you save stuff, getting hacked is like the downfall of the entire company, all the users, all the reputation—it's just gone. So it is a very important thing. How did you guys build this? Were you guys using AI at all? Or it, there's no way it can be completely heuristic.
Andy Zhou 11:41
Basically, we combine different techniques together. For the detection of hacks, we combine the AI-based solution with the behavior analysis one. For the AI-based solution, we use the AI technique, the machine learning technique, to detect the attack contract. We have a system running in our team that can detect the attack contract even before the hacker sends the attack transactions. That's because they need to deploy an attack contract and then send the transactions to attack the protocol. So even before the attack transactions, when the hackers deploy the attack smart contract, our AI-based engine can precisely identify the malicious contract. I'm not saying that we do not have false positives, but the false positives are pretty low. So even in this stage, before the hack transactions, we can detect the attack smart contract. The problem is that when you identify and attack Smart Contract, you may not know the actual victim of this hack. That's because sometimes the destination address is not hardcoded in the smart contract. They can be passed as parameters. You need to have some fuzzing technique to trigger that. But if all the target smart contract addresses are passed from the parameters, then even the fuzzing cannot help.
Andy Zhou 13:05
So for these complicated ones, we cannot identify the attack smart contracts at this stage, we need to deal with them in the attack transaction detection stage. For the attack transactions, we use some behavior-based solutions to detect the hack transactions. The high-level idea is that every hacker wants to make a profit. So you need to be precise to get the profit from the transactions. And after detecting these attack transactions, we will automatically synthesize a similar attack transition like the MEV Bot does, replace the profit address, and put this on the chain. This is basically how the system originally worked before we launched Phalcon Block.
With the AI stuff, I can't imagine it being a supervised learning model. I feel like it would have to be reinforcement learning because there's just not a lot of hacks, right? So it's not enough data to really do that.
Andy Zhou 14:08
I think you mention that very good point for machine learning. For malicious smart contract detection, because we do not have many samples to train the model, it's not effective. In this case, the key insight into how to make these things work is that you need to extract the key features inside a smart contract. Someone just uses the sequence of the bytecode to train the model. That doesn't work because the sequence of the bytecode is too general and too common for the smart contract. You need to extract the distinct features of the smart contract. So what we're currently using, including the control photograph, the data flow relationship between the key functions, and we also use some address labels or the property of the creator for the smart contract together to train the model, It proves to be very effective.
So you basically extract key features. So, for example, let's say hard-coded addresses or addresses passed in as call data. Maybe they're doing a masking if they're doing a Solidity. That's pretty common in Solidity. But if it's a custom high-code contract, there's going to be a pretty sophisticated hacker, first of all. But the sophisticated hackers, ones that are really strictly planned, would 100% be using private transactions of custom bytecode and maybe even swarms of transactions to obfuscate. This was something I was studying, and I was very interested in this stuff. It proved to be effective. Actually, I've never seen anyone use the kind of techniques I found. I might even write an article on it, actually, because I would never use them. But it was interesting.
Andy Zhou 15:46
Yeah, before doing this research project, I also did not think it worked. But after six months, we proved it's very effective.
Yeah, yeah, it's crazy. I think it's such a remarkable step in the right direction, and there needs to be more tools like this. But this also begs the question; you know that you're using AI. How do you kind of see how much AI is going to impact, first of all, your business? And what will be obsolete because of AI, and what can someone do to prepare today for this revolution?
Andy Zhou 16:23
Yeah, honestly, I'm not an AI expert. We are just applying AI to our research area to detect the malicious smart contract. I think the potential of AI in the security area has not been fully explored. And one reason is that, for applying AI to the security area, I think you need to have a very deep understanding of the problem you're solving. Because if you have a very deep understanding of the problem you're solving, you can extract very good features. I think the feature is very important, right? So even for the same contract or for the same transactions, if you do not have a very good feature for the training, then the result will be totally different. From my perspective, I think the potential of the AI has not been fully explored because you need to have a combination of a very good AI person and a very domain expert to extract the features.
I agree. It's very different. It's a combination of two fields, two domains. First of all, being good at AI is hard. And then it takes time to learn the stuff as well. Like you gotta know math, you gotta know everything to do with AI. Like you don't know the packages, libraries, and then you gotta be inside of the crypto space as well with another domain, which is bytecode and also cyber, that also takes time. But I think people that merge from pure AI to crypto, it wouldn't be as hard as going from crypto to AI, I believe, because it is way more difficult in pure AI to get into that just because like the math you need and the total understanding, I guess, of current architecture and how all works.
But it's super interesting, I think. What do you think would be obsolete? Because AI is obviously going to change everything. And I think if you're not using AI, you would not have an edge over other people in all these businesses because it's hard to compete. I was doing the same thing with the fuzzer and stack analyzer, but I know people who do AI. And it makes sense because, if you're thinking about this infinite action space, you can't just brute force that. You need some kind of intuition to filter out all the actions and know what to actually target. So you need AI for this. You need something that can learn over repeated instances, especially if you're running something on all these protocols—all the contracts, millions of instances, or runs, right? It needs to be able to, like, learn intuition. Otherwise, you're building that intuition into yourself. And that's very time-consuming and also very flawed because you can't think in all those dimensions, and you don't know what you don't know at the end of the day. I think, personally, if you're not into it, you should get into it, regardless. I don't even know math, and I'm getting into it. So if I can do it, anyone can do it. So we'll see. But it's a big dedication.
Andy Zhou 19:36
Exactly. I can share a recent experiment on AI. As I said, we have a fuzzing system for the smart contract to find the vulnerabilities; we have an internal system to do that. We can use the AI to generate the seed inputs for the fuzzing, and it turns out to be very effective. So how do we do that? For example, we have five smart contracts to be fuzzed. We first input these smart contracts into the ChatGPT, and we can summarize the key functionalities of each function by telling the GPT, saying, "This function, the main functionality is doing this, another function is doing that." Then after that, I will ask GPT to say, "Please generate 50 different inputs for these functions." And it turns out to be very effective. And we use this as a seed input, you know, to fuzz smart contracts.
Interesting. I think LLMs are actually quite good. The best we have in terms of understanding embeddings I don't know too much more apart from it, but it is like the best effort at the moment. So it makes sense. I think a lot of people are using ChatGPT, but that seems like a really good use case. I know some people like that are doing it to kind of explain the contracts to them. So it kind of removes all the understanding; it quickly helps you get up to speed instead of trying to understand the entire code base. Because it could be like a thousand-line code base, right? Or multi-contracts, multiple thousands of lines. It's really difficult to see the relationship between everything and the dependencies.
But I did want to ask: since you have done this new transaction blocking, now you have the transaction blocking, but why would you take it a step further and actually try and find all the zero days and all the contracts? Because if you think about it, if they're a sophisticated hacker and they actually know what they're doing and they kind of target someone, and let's say it's like a $600 million hack like Ronin or something, or maybe something more realistic like a $200 million or $20 million on a protocol, they would just send a private transaction and you wouldn't be able to block them. Why wouldn't you go fully invested into the zero days preventing all of them? Because if you find it, you just do a private transaction, and you save everything to begin with.
Andy Zhou 22:02
Yeah, a very good question. We actually have some offers for projects inside BlockSec. Currently for the Phalcon Block, we can detect the malicious transactions on the chain or in the Mempool. But for the private transactions, we cannot see that. This is the current stage. We also want to push our efforts a little further to detect the vulnerabilities of the smart contract, even before the hackers. As I just said, we have the fuzzing systems to do that, but currently we are still improving our fuzzing system to detect the security vulnerabilities of the smart contract deployed on the blockchain.
Andy Zhou 22:55
I believe there are a few challenges when conducting fuzzing for smart contracts to identify vulnerabilities. One of the challenges in fuzzing smart contracts is generating inputs, specifically transactions, for the target contract. Moreover, for the smart contract, you need to generate a serial sequence of transactions to trigger the vulnerabilities not a single one. And sometimes the sequence of the transactions, they have dependency on each other. You need to have first transaction and the second and the third, and only the complete sequence of these three transactions can trigger the vulnerabilities. You need to generate the sequence of a couple of transactions, and you need to understand the dependency of these transactions. This is pretty much hard currently. It's the challenge one. And for the second challenge is that you need to have an oracle to determine whether there is a vulnerability. Let's say you send a transaction to a smart contract, then how you determine you have triggered the vulnerabilities? Of course, we can use the similar technique to calculate the profit. If this transaction triggers a very high profit or causes the health factor of some lending protocol to be abnormal, then we'll see there is a vulnerability. But you need to have different types of oracles summarized for the fuzzers. This is the second challenge.
That's the second part. It's quite interesting because if you have a new protocol come out and it has a token, it doesn't have any liquidity pools with big tokens. It might be with another token. You can't even price it, right? So it's a giant hurdle. Have you ever thought of how you would approach that with that kind of oracle?
Andy Zhou 24:57
Yeah, exactly. So this is another challenge because you need to prepare the environment for the fuzzers and the DEX pools. You need to prepare different tokens, and you need to feed the price of each token into a system. You need to prepare different kinds of things for the fuzzers. It's very complicated. For simple vulnerabilities like reentracy ones, it's very easy to trigger for the fuzzers. But for some complicated ones, like price manipulation, it's hard. We're still working on a system, but we still need some time. But you're right, we're working in this direction.
Yeah, it's not a trivial task at all. It requires a lot of complexity, right? And you need to account for a lot of things that depend on other things. So it's like you ask a question and you just get two more questions, and now they relate to each other, and it's just continuously going down. But that oracle thing is probably one of the hardest things. And it's also one of the most important because oracle manipulation is probably the biggest attack factor. Everything kind of relies on that. And in whatever way it could be like an internal exchange rate, it could be an external one versus an internal one.
So like some kind of arbitrage that they haven't accounted for, there are bugs in everything because human error is just certain. And the number of interactions is not going to be accounted for. New protocols come out every day. Your current protocol can now interact with it. It could be a sequence of five different protocols in that regard.
And it's not easy. I think you need AI because you have to think spatially of all these different functions in different contracts that are vulnerable, you can't figure them sequentially because there's just so many possibilities, right? So I think I was talking to someone before early this year about this, and I was talking to him about the Pickle Finance exploit. And that's a really interesting one because it has eight vulnerabilities in it. And if you missed one of them, you wouldn't have the exploit and it had to be in a specific sequence. And this exploit actually consisted of five custom contracts. So it was five custom contracts to basically build out the context in which these sequences of vulnerable functions could be used in a specific way.
And another part of it was understanding that through in Athena's insulator, you have an address and bytes 20, they both mean the same thing. And people overlook this because you do need to know what these types mean. But basically what they were doing, which I found it was really fascinating, was they created these contracts, which were like a fake underlying token. And the fake underlying token dot balance of returned an address, it didn't return an actual amount. And that's not true because an actual amount is just bytes 32 and address is bytes 20. So you can pass in the address as you went to 2,5,6, because it is technically that, right? And so that actually depended, that actually created this entire chain because it created like a delegate code situation where it was being used. And that's how it kind of happened. But it was really interesting. You know, you have to generate contracts that do specific things which enable new sequences. And this is not trivial at all to be able to generate contracts, to enable an exploit of five of them at least. It's an extremely fascinating problem, and I think it is very stimulating. And I think there's nothing better to do in this kind of stuff. I love it so much.
But this kind of stuff is really hard. And have you thought about all of this stuff? Like, what are the kinds of techniques that you're looking into now? Obviously, I just said spatially, looking into isolated functions and seeing how they interact with each other. The relationship is definitely one of the hardest parts, depending on how you tackle it. Because of taint analysis, it's frankly not enough.
Andy Zhou 29:26
Yeah, so for the relationship between different smart contracts, we're currently doing a very interesting thing. We manually collect the top DeFi protocols' smart contracts. Then we perform the manual analysis to draw a figure of the relationship between different smart contracts. For instance, if the wstETH can be used as collateral in a protocol, say ABC, we will draw a line between these protocols. If one token can be used as the underlying token of another smart contract, then we will connect these protocols together.
Andy Zhou 30:02
So basically, we manually use some scripts to get a whole picture of the relationship between different top protocols. And we will use these insights to guard against static analysis and fuzzing techniques.
Andy Zhou 30:15
This is one thing we are currently working on. It's still in an early stage, but the relationships we generate are sometimes helpful for the static analysis and for the fuzzy systems. Another work we are currently doing is for type inference. We want to infer the type of the input data, e.g., the call data inside a smart contract call. For instance, from byte 0 to byte 20 of the calldata, we can infer the type is an address. and from another segment of the input, the type is another one. This would be very helpful in fuzzing. We try to leverage the static analysis to perform the type inference.
Interesting. Yeah, the relationship between the above stuff is kind of like a graph. What you are doing is difficult. Because, let's say, these are a few techniques as well. If you have a contract and it has references to other contracts in it, let's say hard-coded addresses, right? That is quite simple. That means you know the kind of space you can access and how they all connect in that relationship. But there are also contracts that don't even directly reference each other. You can reference them with calldata, or you can create a pool that now references a new contract. I think it was called the Iron Vault or something. It was in the other ecosystem.
Andy Zhou 31:33
Yeah, it's not easy, but we can leverage the onchain transactions to connect them because the onchain transactions can reveal the interactions between different smart contracts.
But the flow with that is that you're looking at the normal sequences of functions, right? And to find a zero day, you have to break the norm and do something different. Well, I think it's good to identify what the normal is, and now you know what not to do and how to break it, which is good. Interesting. So what are your plans with the fuzzer? Are you going to pair it up to do some kind of neural network fuzzing? That's Trail of Bits' attempt. It's not worth it, but quite frankly, it is just not being implemented correctly. And so what's your kind of plan over the fuzzer? Are you going to do neuro-network fuzzing-assisted or completely AI? What's the kind of place to go now?
Andy Zhou 32:23
For the fuzzing, first we try to have a very good type of inference system to facilitate the generation of the seed inputs and the mutation of the inputs for the fuzzer. We also leverage AI to help us generate the seed inputs. We also try to speed up the fuzzing process because we want to have a very efficient one to quickly identify vulnerabilities. There are three different parts of works we're trying to improve the fuzzers.
Okay, interesting. There is something that is a bit different from this tooling conversation when we think about space, right? And you're a professor, so you know about this stuff.
A lot of people are explaining how to become a top-tier auditor. The people like leading security research at Spearbit or Trail of Bits—anything, even just solo auditors—are doing really well with the influx of new auditors, right? How do you aim to really differentiate yourself from these new players coming in and other firms and other people that I want to have the skills? Obviously, there aren't a lot of them, but they're still coming in. And as they come in, these smarter people come in, maybe even with AI. I know people like and testify are doing AI exploit generation. I'm sure you've heard of them. And what are you doing to really differentiate yourself from these people as new auditors come in and new players come into the space?
Andy Zhou 33:55
Yeah, well, that's a very challenging question. I think from my perspective, you need to have a good understanding of the trend of this particular area, e.g., the DeFi protocol security area. There are different attack vectors and new types of vulnerabilities. And you need to have very good motivation or skills to try to study these new things. How to quickly learn these new things and how to quickly digest new knowledge are my advantages. And of course, there are many smart people who will come into this field. But I would say that because I have been trained as a PhD, I know how to quickly go into a new area, how to quickly understand the state-of-the-art, how to quickly find a good problem to work on, and how to borrow techniques from another area into this area to solve this problem. I think that's what differentiates me from others.
Hundred percent. I think if you're thinking about a group of people and they're all smart and capable, the main difference is just to creativity; that seems like if you're all on a plant-level field, which is never true or just like smart equally. And the biggest thing is creativity, right? We all think differently and have different views. So I think that is a main thing, like truly believing in yourself and believing when others don't believe that you can do something and no one else is really doing that, and you believe that it can be done and you might not know how it can be done, but as long as you keep pushing and have the passion to find that, it's really the main thing. Being able to identify new trends and capitalize on them is the main thing. And it happens so often; you just have to be prepared with the knowledge to capitalize on it and bounce on the opportunity.
Unfortunately, I haven't, because I don't know AI. It's all about being in the right place at the right time with the right skills. I think AI is truly the next frontier, and anyone not upscale into it, I think, is going to be left behind. Mind if in developer worlds you have domain knowledge and also AI, but if you combine them, you're not making a world of difference because you have knowledge of both areas. And so you can think of better problem solutions versus sectioned-off knowledge. I guess a good example is understanding math. You look at the world differently than someone who doesn't understand it. And if you combine that with different things, like the financial sector, then you can think of ways to build really efficient algorithmic trading systems, right? And gain an insane edge here for the competition. I think that's this guy actually on AVAX that captured, I think, 90% of all arbitrages because he just had a math edge. That's what I mean. If you have just two domains, you can really capture a lot of opportunities. because it's just hard to learn this stuff. And the more domains you know it can combine, the less competition there is; it just gets called away.
So where do you see yourself and BlockSec in the future? How do you see yourself progressing in your career and in the company itself? And where do you see the industry going, and where should it be going?
Andy Zhou 37:05
I think for the industry, because Web3 is a very new area and we're still in the early stages of this new field. From my perspective, the industry is moving very fast. At the same time, there are so many security issues that have not been addressed by the industry. We are trying to use our own solutions to help the ecosystem move fast but also move securely. We have the products and protocols to protect their assets. This is one thing. We also see in the future that there will be a couple of different Web3 users in this field. The users also need security protection because it's a little complicated for them to use the Web3 products currently. They need to have a very good method to protect their private keys and their assets, because most of the users do not understand the approval process of ERC20 tokens. They just approved all the tokens in the malicious contract.
Andy Zhou 38:10
So we need to have a very good protection system for DeFi users, which has not been addressed by the current industry. Of course, there are some companies who are doing this, but there are better ways to protect users.
I think on top of the fuzzer, you can expand into something like a wallet when you're talking about protecting users. I mean, there's two different ways or three different ways. It's like the pending transactions, which aren't 100 percent certain. So you have to go a bit granular. And that could be like finding the zero days themselves. But if that's not an option, then just having the ability to embed the analysis in the wallet itself might be good, even if it's like a quick one, right? They're going to be doing tokens or whatever they dig into. But if you can perform some analysis before they do the transaction, and I think someone's done this before.
Andy Zhou 39:01
There are a couple companies doing that to simulate the transactions and to tell the users the consequences of a transaction if they sign it.
I think that's really smart, and I think it's an easy progression into the company or anything that does security, which I think is a really great way. So directly give it to them. I think it was fire or something. I can't remember. But yeah, those are really good, the simulations, but I think they're kind of flawed because you're doing like a transaction into an LP, for example. People would do custom bytecode and do conditional functionality. Let's say those 100 kinds of LPs switch to doing something else. So the initial simulation of when it has their money or whatever it is wouldn't come up unless you actually tested everything, every single function pathway. That's something I was thinking of. But also, there's so many difficult problems. You gotta pick your poison. What are you excited for in the future of cyber, cybersec, and AI combining? I'm sure you're going to use a lot more. What are your kind of plans, and how do you see yourself going down that road?
Andy Zhou 40:06
Yeah, as for my plan, I think we want to, you know, combine these new techniques together to better protect the community and the users. We will continue to invest our resources in AI, since AI combined with Web3 security scenes will produce better products. We want to push things further to have a better attack-detecting system, a better fuzzing system, and better solutions to protect users' assets. So this is our current plan inside BlockSec.
Interesting. Okay. I am sure that it gets way better and you're able to do a lot more. You're already doing a lot to prevent all these hacks. But I think there's so much wiggle room for more innovation, and it's only just getting started. I think once people start getting wind of it and you prevent more hacks, it's going to become much more prominent and there will be a lot more competition, which is great. Healthy competition to prevent hacks and actually expand the ecosystem. Because the end goal is to kind of replace CeFi, right? You don't want to wait four months to get money out of your bank accounts. It's pretty ridiculous. Efforts in the information sector are actually underappreciated for retail and existing protocols. They only really know it until they get hacked. I believe this is actually how a few people go into it. But man, I'm super excited for what you guys are building, and I'm really optimistic about the future with cyber and crypto. But man, I really appreciate you coming on. I'm super glad I got to be the first podcast you jumped on. Yeah, I really appreciate your time, Andy. It's been a great chat.
Andy Zhou 41:38
Yeah, it's an honor to be here. Thanks, DeGatchi.