Web3 security and code audit may be more interesting than you think.

Interviewer: Faust, Yuyue, Geek Web3

Interviewee: Luis, ScaleBit

Editors: Faust, Jomosis

On July 1st, Geek Web3 invited Luis, co-founder of the Web3 security audit company ScaleBit, to answer many questions about code audit and Web3 security. During the interview, they discussed various aspects of code audit and Web3 security, as well as ZK, AI, and the Bitcoin ecosystem from both business and technical perspectives. The topics included:

• Why ScaleBit initially chose the Web3 security direction and rooted in the MOVE ecosystem;
• The business logic and customer level division of the code audit industry;
• The differences and connections between Web3 security and Web2 security;
• The complexity of ZK circuit audit and the efforts made by ScaleBit;
• Comparisons of the Bitcoin ecosystem and Layer 2 from operational and technical perspectives;
• The impact and assistance of AI tools such as Chatgpt on the code audit industry;

This article is a textual summary of the interview, approximately 7000 words long. During the interview, Luis provided a detailed explanation of various aspects of the Web3 security industry based on his own experience. For those unfamiliar with the Web3 security and code audit industry, this article will be an excellent opportunity to understand audit institutions, and it is strongly recommended to read, collect, and share.

1. Faust: The first question I want to ask is about the direction of entrepreneurship. Why did ScaleBit choose the Web3 security direction at the beginning?

Luis: The main reasons why we chose the Web3 security direction at the beginning are as follows:

First, many members of our team entered the blockchain industry from Silicon Valley early on and hoped to find long-term and stable user demand. Code audit is a fundamental and long-lasting track, so we chose this direction. We also hope to become a respected security company in the industry.

Second, we believe that Web3 security is still in its early stages, but security issues in Web3 are much more important than traditional Internet security because they are directly related to financial assets, making them more valuable than traditional Internet security.

Although some people now believe that the business ceiling related to contract audit is limited, in addition to contract audit, there are many new businesses emerging in Web3 security, and various new demands will continue to emerge. Therefore, we believe that the Web3 security / code audit track is still very promising.

Third, many members of our team have a background in code audit and blockchain security. We have accumulated a lot in the security industry. I was a founding member of another blockchain security company, and our chief scientist, Professor Chen Ting, has been doing research related to blockchain security and has a lot of experience in the Web3 security field. Other members also have backgrounds in exchange security, formal verification, and static analysis.

Based on these reasons, we ultimately chose the Web3 security track.

2. Faust: I heard that ScaleBit was originally called MoveBit, and later the brand was upgraded to ScaleBit. Can you talk about why you initially chose the Move ecosystem and why you changed the name later?

Luis: This was actually our brand upgrade. The parent brand is BitsLab, and we are using three sub-brands: MoveBit, ScaleBit, and TonBit. It is a multi-brand strategy, and we have expanded from the Move ecosystem to more ecosystems, positioning ourselves in security and infrastructure in emerging ecosystems.

Regarding why we initially chose the Move ecosystem, there is a little story: around 2022, when we entered the field of security audit, we spent three months researching the most suitable niche field for deep cultivation. At that time, we believed that it would be difficult to compete with the existing competitors if we were to establish a full-category security company, so we needed to find a specific track to enter.

We discussed several directions, one was Move, and then ZK. In addition, we also conceived of creating a vertical, such as focusing on GameFi or a certain type of business for audit branding. In short, the strategy was to make a breakthrough in a single point. Later, we considered various factors and chose the Move ecosystem.

At that time, we only had about seven or eight people, and we were quite successful in the Move ecosystem. We audited the top 20 TVL projects in the Move ecosystem, accounting for about 80% to 90%, and audited important underlying components such as MoveVM and Aptos Framework, and discovered many underlying vulnerabilities. So in the Move track, we have a high market share.

We are still doing code audit business in the Move ecosystem. Currently, this accounts for about 50% of our revenue, and the audit workload accounts for about 40% of our business. Because there are more overseas clients with code audit needs in the Move ecosystem, the unit price for this type of business is higher.

Currently, TonBit mainly audits the Ton ecosystem, ScaleBit audits the BTC Layer2 ecosystem, ZK, and other new ecosystems. Our overall positioning in BitsLab is to focus on emerging ecosystems and pay attention to ecosystems with the potential for mass adoption.

3. Faust: I would like to ask about ZK. The audit work related to ZK is very troublesome. Vitalik previously said that systems like zkEVM have circuits that are too complex, and even with functional testing or audits, it is still impossible to guarantee that the circuit will not have problems. Can you talk about this based on your own experience?

Luis: ZK-related audits are divided into many aspects, mainly including circuit audits, source language audits, and general computation audits. Let me first talk about circuit audits.

One of the major difficulties in circuit audits is that the readability of circuit code is very poor compared to traditional programming languages. In addition, the ecosystem related to circuit languages is very fragmented. Currently, there may be more than a dozen languages and frameworks for writing circuits, including Circom, Halo2, Artwork, Bellman, and so on. Therefore, there is no unified standard for circuit writing at present.

Obviously, it is almost impossible for any security institution to be proficient in all circuit languages at the same time. Therefore, we made a choice to enter the field of ZK. Currently, in the ZK track, we have mainly done two things. One is to jointly hold a ZK security capture-the-flag (zkCTF) competition with Scroll, EthStorage, and Professor Guo Yu from AnBi Lab. This competition is held approximately once a year. The purpose of organizing this competition is mainly to cultivate more ZK security talents.

The other thing is that we have developed a vulnerability detection tool called zkScanner, which mainly uses formal and static analysis methods to scan for vulnerabilities in ZK circuits. After the initial scan, zkScanner will find some suspicious points, which are then confirmed manually and can serve as a supplement to manual audits. Of course, this kind of automated audit tool cannot completely replace manual audits yet, but it is quite effective in finding some more concealed constraints.

Yuyue: The automated audit tool you mentioned, is it similar to static detection tools for detecting ERC-20 Tokens?

Luis: It's somewhat similar but not quite appropriate. They are similar in terms of workflow: scanning static code and providing the location and reasons for vulnerabilities. The difference is that circuit-related errors are mainly divided into two categories: Under-Constrain and Over-Constrain. At the same time, ordinary lexical analysis is difficult to find these errors.

Yuyue: If we only talk about constraints, it's a bit abstract. Can you give an example of what it looks like?

Luis: I think we can look at this issue from a different perspective. Essentially, circuits are more of a mathematical expression than smart contract languages. They ultimately need to be converted into R1CS, which can be understood as a pure polynomial expression. Therefore, some issues that may occur in conventional programs are relatively rare in circuits.

Because circuits essentially "cannot be wrong," each circuit needs to generate the corresponding proof with the correct input and output. If there is an error in the circuit, it cannot be compiled. This ensures that the result of the circuit computation is "correct." However, being "correct" is not enough for the circuit; it needs to be "correct" in all cases, which leads to the issues of over-constraint and under-constraint.

If there is an over-constraint, some inputs that meet the requirements cannot pass through the circuit; if it is under-constrained, it will make inputs that do not meet the requirements meet them, which are both fatal problems.

Yuyue: So these issues cannot be discovered by the compiler, they are the preconditions set by the developer when designing the circuit, and there are problems with its expression, is that correct?

Luis: Yes, because these issues are not entirely at the syntax level; they also involve the developer's intent and some common cryptographic specifications. Specifically, these issues often require the use of formal tools, such as SMT-Solver, to discover them.

4. Faust: From a business perspective, how do you view the audit business related to ZK?

Luis: The audit business related to ZK is worth long-term attention, and we have been continuously accumulating in the field of ZK audits. This includes our later audits in the Bitcoin ecosystem, which was due to the discovery of a good combination between the Bitcoin ecosystem and ZK. The narrative of ZK Layer2 in the Ethereum ecosystem has already receded, and the next wave of narratives in the ZK track has not yet officially arrived, perhaps it will be related to FHE.

Although we did not enter the ZK audit field early or late, it is more about long-term attention and accumulation. We have been continuously focusing on zkCTF and zkScanner, as mentioned earlier, which is the ZK circuit vulnerability detection tool.

Yuyue: Can you briefly introduce the zkCTF event?

Luis: This is a CTF (Capture The Flag) event related to the ZK field that we initiated, held once a year. We invite top security researchers and ZK researchers in the industry to participate. We will set up challenges for participants in collaboration with Scroll, EthStorage, and Professor Guo Yu from AnBi Lab, and have received strong support from institutions such as Ingonyama, zkMove, and HashKey.

We have compiled a list of participants, who come from all over the world and are quite top-notch, including:

OpenZepplin, Offside, Salus, Amber Group, Sec3, as well as some security and ZK-oriented doctoral students from Georgia Tech and Berkeley.

5. Faust: I want to ask about ScaleBit's view on the Bitcoin ecosystem. I heard that you have audited over 30 projects in the Bitcoin ecosystem. How do you view Bitcoin Layer 2?

Luis: The 30+ projects in the Bitcoin ecosystem include Layer 2 or projects within Layer 2 ecosystems, such as UniSat, Arch Network, Merlin Chain, RGB++, B² Network, as well as projects related to runes and inscriptions like Liquidium. Many other projects are DeFi protocols within the Layer 2 ecosystem.

Regarding Bitcoin Layer 2, I agree more with the views of Kevin He, co-founder of Bitlayer, who believes that the competition in Bitcoin Layer 2 will be divided into three stages: the first stage is to attract TVL, the second stage is to attract developers, and the third stage is the competition of technical routes. I think we are still in the early stages of the first phase, or just starting to attract developers and build ecosystems.

Faust: When auditing projects in the Bitcoin ecosystem, what aspects or criteria do you mainly focus on?

Luis: If it is related to Bitcoin Layer 2, we consider several dimensions. For example, some projects need to be audited for their scripts on the Bitcoin chain, while others need to be audited for the contracts deployed on Bitcoin Layer 2. Some audit targets are cross-chain bridges or underlying chains, and some Layer 2 projects may not use EVM, so there is audit work to be done at these levels.

We mainly look at the attack surfaces in the code of these projects and assess for vulnerabilities from various dimensions. This is actually quite complex because Bitcoin Layer 2 is similar to a public chain system. We need to consider the points that need to be examined when auditing a public chain, such as whether the project is vulnerable to double-spending attacks, eclipse attacks, witch attacks, external dependency security, centralization issues, and man-in-the-middle attacks. It's quite detailed, and we can discuss this topic specifically another time.

Our chain audit capabilities at ScaleBit are at least top-notch in Asia. Team members have discovered vulnerabilities in well-known public chains such as Sui, OKX Chain, GalaChain, and Nervos, and recently found a high and a low-level vulnerability in the public audit competition of Babylon.

6. Faust: Based on your experience in security audits, is the most vulnerable area the cross-chain bridge? From my understanding, many cross-chain bridges are essentially extensions of DeFi, so they are as susceptible to attacks as DeFi protocols. How do you view this?

Luis: In terms of frequency, areas related to DeFi are the most likely to lose money, but in terms of amount, the losses after an attack on cross-chain bridges are the largest, and when there is a problem, it becomes a big problem. Of course, when I mention DeFi, I am mainly referring to the contract level. As long as there is a problem with the DeFi protocol's contract, it can be attacked, and there are relatively few remedial measures.

Cross-chain bridges are indeed the most vulnerable because they often involve large amounts of funds and many use multi-signatures, making them easy targets for exploitation.

7. Faust: How much do you think AI tools like Chatgpt help or impact the work of code audits?

Luis: Actually, they are quite helpful, but more in an auxiliary capacity. Sometimes, audit personnel use Chatgpt to quickly understand the purpose of some code, but this is only an aid, and many details still need to be confirmed by humans.

Another aspect is writing documents and audit reports, especially in English. Some audit personnel are not native English speakers, so they use Chatgpt to polish these documents, which is quite helpful.

But from the audit perspective, we are also training some specific LLM internally, using some open-source large language models for training, but currently, it is only auxiliary. Although it can improve work efficiency, it absolutely cannot rely solely on AI for audits. It may only improve efficiency by about 20%, and it is still far from reducing the number of audit personnel on a large scale.

There are still two obvious shortcomings of LLM. The first is the issue of missed reports, and the second is false reports. We can use LLM for some vulnerability discovery, but we need to be mindful of the false positive rate. If you use AI to help you find code vulnerabilities and it has a high false positive rate, it will waste your time and become a burden. But we will continue to monitor the progress of AI, such as whether it can achieve efficient vulnerability discovery at the tool level. This area is still quite cutting-edge, and everyone is still exploring, but we have not seen any company claiming to truly achieve the above effects.

Yuyue: Regarding AI automated code audits, do you think this will be a focus in the future? From my understanding, AI reading code is almost instantaneous, and it has accumulated more experience and can enumerate more states than humans, which is a great advantage. If a security company deeply deploys in this area, trains specialized AI for automated code audits, and surpasses its competitors, how do you view this?

Luis: We have been paying attention to this direction, and I think it should be viewed from two aspects:

First, if you believe that AI automated auditing can really be established, a situation will arise:

In theory, LLM can harmonize the entire code auditing industry, because if everyone uses LLM to generate code and LLM can ensure that the generated code is problem-free and bug-free, then there would be no need for auditing. At this point, it would not only eliminate the auditing industry but also affect programmers. However, achieving this effect is very difficult.

If we believe that LLM can eliminate auditors, it will definitely be more difficult than eliminating developers. Writing code without vulnerabilities is much more difficult than simply implementing code that meets requirements, so I believe that AI eliminating auditors is even more difficult than replacing programmers.

On the other hand, AI will not directly eliminate security audits but will make breakthroughs in certain areas first. As mentioned earlier, AI can help with vulnerability discovery. Although it cannot find all bugs, it can help uncover one or two types of issues that manual audits may overlook. These are the types of applications that we are focusing on.

8. Faust: I would like to ask about your views on the audit work itself. What does the specific audit workflow include when you conduct audits? It's not just as simple as issuing a certificate, right? During the code review process, do you also help optimize the code for the project?

Luis: This depends on the client's needs. Sometimes we help optimize the client's original code, such as reducing gas consumption for certain operations in DeFi.

As for the audit process, let me briefly explain. We conduct at least two independent rounds of auditing: the initial review and the re-review. During the initial review, a team conducts a separate audit, and at this point, the project team needs to make modifications to the initial code. Then, it moves on to the re-review, where another team continues to check the code. The ultimate goal is to have at least two teams cross-auditing the code.

In terms of differentiation from other audit companies, ScaleBit excels in innovative business audits. We like to recruit people with a background in CTF (Capture The Flag) to conduct audits because they have strong learning abilities and a deep understanding of various attack methods.

Additionally, we differ from other audit companies in that we lean towards a boutique audit route. If the code we audited misses major or higher-level vulnerabilities, we will refund 30% to 50% of the fee. This is a commitment that other audit companies do not dare to make.

9. Faust: Some people believe that security audits are actually about brand endorsements, similar to the rating agencies on Wall Street. The Matthew effect is very strong in this area, and established companies like SlowMist have a first-mover advantage and a strong moat, making it difficult for newcomers to compete with established players like SlowMist. How do you view this?

Luis: I partially agree with this viewpoint, but it also depends on different situations. For example, we categorize clients into three types based on audit requirements: low, medium, and high. The lowest tier includes projects with limited resources, followed by medium-tier projects, which have some strength but are not considered star teams. The highest tier consists of star teams with strong financial resources.

Let's start with the highest tier clients. These clients usually engage with 2 to 3 or more audit companies and pay close attention to the quality of code audits. They may initially seek out the world's top audit firms, but these firms may have too much business to prioritize certain clients' needs. Therefore, many star project teams also seek out less well-known but high-quality audit firms to provide additional oversight.

These types of clients are the most favored by audit companies because they have significant financial resources and are very concerned about the quality of audits. They generally engage multiple audit companies, so as long as your audit capabilities are strong, there is an opportunity to reach these clients. Therefore, these clients are one of our main client groups.

The second tier consists of clients who are "concerned about audit quality but may not have a lot of money" and have the potential to become top-tier clients in the future. Although they hope to engage with top audit firms, they may not be able to afford the cost.

In this industry, there are truly "top security companies," such as OpenZeppelin and Trail of Bits, with a maximum of about 4 to 5 companies at this level. Everyone knows that these companies are very powerful, but their prices are also very high, possibly 3 to 10 times higher than those of conventional audit companies.

Second-tier clients may not be able to engage the top audit firms. Therefore, for second-tier clients, instead of allocating their budget to engage a top-tier audit company, it is better to allocate the budget to a high-quality audit firm and engage multiple audit companies. These clients form our largest group, and we hope to grow together with them.

The last type of client is the lowest tier, as mentioned earlier. These clients basically go for whoever is cheaper or pay a well-known audit firm to audit their contracts.

So, based on the points mentioned above, the assessment of the audit industry you mentioned has some merit. For audit companies with more historical accumulation and good reputation, there is indeed a Matthew effect. However, you can see that some well-known audit companies have experienced significant problems in recent years, despite their high reputation.

However, as a rising audit company, it is essential to have differentiated advantages. Our strategy is to achieve breakthroughs in specific areas:

First, we enter a specific niche and establish an absolute advantage. For example, in the Bitcoin Layer2 ecosystem, our current coverage exceeds 50%, and our coverage in the Move ecosystem exceeds 80%. Even top audit firms like OpenZeppelin may not necessarily be able to compete with us in these specific niches. So, the so-called "Matthew effect" depends on the environment in which it operates.

10. Faust: From your personal perspective, what is the biggest difference in security between Web2 and Web3? Can you discuss this based on your past experiences?

Luis: First of all, I believe that Web3 security is in a very early stage of development, and Web3 security requirements are definitely greater than those of the Web2 security market.

Here's a story: there was a Chinese executive in the Silicon Valley security circle who had reached the level of VP at a publicly listed company in Silicon Valley. He said that the main groups involved in security in Silicon Valley are the Chinese and Jewish communities. Why are the Chinese so good at security? Because the security industry is a typical industry where there is no presence until something happens and then someone has to take the blame. Indians and Caucasians are not willing to do this, so the Chinese have emerged. This is for Web2 security companies.

However, Web3 security is different because blockchain directly deals with money, so the presence of Web3 security is significantly higher by many orders of magnitude. In this field, many "security practitioners" can directly monetize their skills. It has been joked that the most successful transition from Web2 to Web3 is made by hackers.

From a technical perspective, Web3 security includes parts of Web2 security and reuses many of its technologies. Many systems now, such as many DeFi applications, have servers and interfaces, and they also require traditional penetration testing, DoS defense, and so on, which are actually part of Web2 security.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。