Cuộc trò chuyện cùng ScaleBit: Những câu chuyện thú vị về kiểm toán an toàn Web3
Tuyển chọn TechFlowTuyển chọn TechFlow
Cuộc trò chuyện cùng ScaleBit: Những câu chuyện thú vị về kiểm toán an toàn Web3
Việc bảo mật Web3 và kiểm tra mã có thể thú vị hơn bạn nghĩ.
Chuyên sâu báo cáo Web3Người phỏng vấn: Faust, Vụ Nguyệt, Geeker Web3
Người được phỏng vấn: Luis, ScaleBit
Biên tập: Faust, Jomosis
Ngày 1 tháng 7, Geeker Web3 đã mời Luis, đồng sáng lập công ty kiểm toán an toàn Web3 ScaleBit, để giải đáp nhiều câu hỏi liên quan đến kiểm toán mã nguồn và an toàn Web3. Trong buổi trò chuyện, hai bên đã thảo luận từ góc độ thương mại và kỹ thuật về kiểm toán mã nguồn, an toàn Web3, cũng như các chủ đề như ZK, AI và hệ sinh thái Bitcoin. Các nội dung cụ thể bao gồm:
-
Tại sao ScaleBit ban đầu lại chọn định hướng an toàn Web3 và tập trung vào hệ sinh thái MOVE;
-
Logic kinh doanh trong ngành kiểm toán mã nguồn và phân tầng khách hàng;
-
Sự khác biệt và mối liên hệ giữa an toàn Web3 và Web2;
-
Điểm phức tạp trong việc kiểm toán mạch ZK là gì, Scalebit đã nỗ lực những gì;
-
Nhìn nhận về hệ sinh thái Bitcoin và lớp thứ hai (layer 2) từ góc độ vận hành và kỹ thuật;
-
Tác động và hỗ trợ của các công cụ AI như Chatgpt đối với ngành kiểm toán mã nguồn.
Bài viết này là bản ghi chép từ cuộc phỏng vấn trên, khoảng 7000 chữ. Trong đó, Luis đã chia sẻ khá chi tiết và thực tế về nhiều khía cạnh trong ngành an toàn Web3 dựa trên trải nghiệm cá nhân. Đối với những người chưa hiểu rõ về an toàn Web3 và lĩnh vực kiểm toán mã nguồn, đây sẽ là cơ hội tuyệt vời để tìm hiểu về các công ty kiểm toán – rất khuyến khích đọc, lưu lại và chia sẻ.
1. Faust: Câu hỏi đầu tiên tôi muốn đặt ra là về định hướng khởi nghiệp. Tại sao ScaleBit khi mới thành lập lại chọn theo hướng an toàn Web3?
Luis: Chúng tôi chọn hướng đi an toàn Web3 chủ yếu vì những lý do sau:
Thứ nhất, nhiều thành viên trong nhóm chúng tôi từng làm ở Thung lũng Silicon và bước chân vào lĩnh vực blockchain khá sớm, nên mong muốn tìm kiếm nhu cầu sử dụng lâu dài, ổn định. Mã nguồn kiểm toán chính là một mảng cơ bản và có khả năng tồn tại bền vững, vì vậy chúng tôi chọn con đường này, và hơn hết, chúng tôi mong muốn trở thành một công ty an toàn được cả ngành kính trọng.
Thứ hai, chúng tôi cho rằng an toàn Web3 vẫn đang ở giai đoạn sơ khai, nhưng trong Web3 thì vấn đề an toàn quan trọng hơn rất nhiều so với Internet truyền thống, bởi nó liên quan trực tiếp đến tài sản tài chính, do đó chắc chắn mang giá trị lớn hơn an toàn Internet truyền thống.
Mặc dù hiện nay có người cho rằng thị trường kiểm toán hợp đồng có giới hạn nhất định, nhưng thực tế ngoài kiểm toán hợp đồng, an toàn Web3 còn xuất hiện ngày càng nhiều dịch vụ mới và nhu cầu phát sinh liên tục, vì vậy chúng tôi vẫn đánh giá cao tiềm năng của lĩnh vực này.
Thứ ba, thành viên trong nhóm chúng tôi có nền tảng gắn liền với kiểm toán mã nguồn / an toàn blockchain. Chúng tôi có nhiều tích lũy trong ngành an toàn. Tôi trước đây là thành viên sáng lập của một công ty an toàn blockchain khác, giáo sư Chen Ting – nhà khoa học trưởng của chúng tôi – cũng luôn nghiên cứu về an toàn blockchain, là một giáo sư có bề dày kinh nghiệm trong lĩnh vực Web3. Các thành viên khác cũng có nền tảng về an toàn sàn giao dịch, xác minh hình thức (formal verification), phân tích tĩnh (static analysis).
Chính vì những lý do trên, cuối cùng chúng tôi quyết định chọn con đường an toàn Web3.
2. Faust: Nghe nói ban đầu ScaleBit có tên là MoveBit, sau đó nâng cấp thương hiệu thành ScaleBit. Anh có thể chia sẻ lý do ban đầu chọn hệ sinh thái Move và lý do đổi tên không?
Luis: Đây thực chất là quá trình nâng cấp thương hiệu, thương hiệu mẹ là BitsLab – chúng tôi đang sử dụng ba thương hiệu con là MoveBit, ScaleBit và TonBit, một chiến lược đa thương hiệu. Chúng tôi cũng mở rộng từ hệ sinh thái Move sang nhiều hệ sinh thái khác, tổng thể đều tập trung vào an toàn và hạ tầng trên các hệ sinh thái mới nổi.
Về lý do ban đầu chọn hệ sinh thái Move, có một câu chuyện nhỏ: vào khoảng năm 2022, khi bắt đầu tham gia lĩnh vực kiểm toán an toàn, chúng tôi dành ba tháng để nghiên cứu lĩnh vực chuyên sâu phù hợp nhất. Khi ấy, chúng tôi nhận thấy rằng nếu xây dựng một công ty an toàn đa dạng, sẽ rất khó cạnh tranh với các đối thủ hiện có trên thị trường, nên cần chọn một ngách riêng để đột phá.
Chúng tôi đã cân nhắc vài phương án: một là Move, hai là ZK, ngoài ra còn nghĩ tới việc tạo một thương hiệu kiểm toán chuyên biệt, ví dụ như chỉ tập trung vào GameFi hoặc một loại hình nghiệp vụ nhất định. Tổng thể là chiến lược đột phá điểm đơn. Sau khi cân nhắc nhiều yếu tố, chúng tôi chọn hệ sinh thái Move.
Lúc đó nhóm chỉ có khoảng bảy tám người, nhưng đã khá thành công trong hệ sinh thái Move. Trong top 20 dự án có TVL cao nhất hệ sinh thái Move, khoảng 80–90% đều do chúng tôi kiểm toán, đồng thời chúng tôi cũng đã kiểm toán các thành phần cốt lõi như MoveVM, Aptos Framework, và phát hiện nhiều lỗ hổng nghiêm trọng ở tầng底层. Do đó, chúng tôi chiếm thị phần rất lớn trong mảng Move.
Hiện tại chúng tôi vẫn nhận các dự án kiểm toán mã nguồn trong hệ sinh thái Move, chiếm khoảng 50% doanh thu và 40% khối lượng công việc. Vì khách hàng nước ngoài trong hệ sinh thái Move có nhu cầu kiểm toán nhiều hơn, nên đơn giá dịch vụ cao hơn.
Hiện nay, TonBit tập trung vào kiểm toán hệ sinh thái Ton, ScaleBit đảm nhiệm hệ sinh thái BTC Layer2, ZK và các hệ sinh thái mới khác. Tổng thể, định hướng của BitsLab là tập trung vào các hệ sinh thái mới nổi, đặc biệt chú ý đến những hệ sinh thái có tiềm năng áp dụng đại trà (Mass Adoption).
3. Faust: Tôi muốn hỏi thêm về ZK. Công việc kiểm toán liên quan đến ZK rất phức tạp; Vitalik trước đây từng nói rằng mạch của các hệ thống như zkEVM quá phức tạp, dù đã kiểm thử chức năng hay kiểm toán rồi thì vẫn không thể đảm bảo mạch không có lỗi. Anh có thể chia sẻ kinh nghiệm thực tế không?
Luis: Kiểm toán liên quan đến ZK bao gồm nhiều khía cạnh, chủ yếu chia thành kiểm toán mạch, kiểm toán ngôn ngữ nguồn và kiểm toán tính toán phổ quát. Trước tiên tôi sẽ nói về kiểm toán mạch.
Khó khăn lớn nhất trong kiểm toán mạch là mã mạch kém dễ đọc so với ngôn ngữ lập trình truyền thống; hơn nữa, hệ sinh thái mã mạch rất phân mảnh, hiện nay có thể có tới hơn mười loại ngôn ngữ và framework viết mạch, bao gồm Circom, Halo2, Artwork, Bellman,... Do đó, hiện tại việc viết mạch chưa có tiêu chuẩn thống nhất nào.
Rõ ràng, đối với bất kỳ tổ chức an toàn nào, việc thành thạo tất cả các ngôn ngữ mạch cùng lúc là gần như không thể. Vì vậy, chúng tôi đã lựa chọn có định hướng khi thâm nhập lĩnh vực ZK. Hiện tại, chúng tôi chủ yếu làm hai việc trong lĩnh vực ZK: một là phối hợp với Scroll, EthStorage và giáo sư Quách Vũ (Guo Yu) từ Anbi Lab tổ chức cuộc thi an toàn ZK (zkCTF), diễn ra khoảng một lần mỗi năm. Mục đích tổ chức sự kiện này là để đào tạo thêm nhân tài an toàn ZK.
Việc thứ hai là chúng tôi phát triển một công cụ phát hiện lỗ hổng – zkScanner, dùng phương pháp xác minh hình thức và phân tích tĩnh để quét lỗ hổng trên mạch ZK. zkScanner sẽ quét ban đầu để tìm ra các điểm nghi ngờ, sau đó chuyển cho con người xác minh lại, bổ trợ cho kiểm toán thủ công. Tất nhiên, công cụ kiểm toán tự động này chưa thể thay thế hoàn toàn con người, nhưng tương đối hiệu quả trong việc phát hiện các lỗi constraint (ràng buộc) ẩn sâu.
Vụ Nguyệt: Công cụ kiểm toán tự động mà anh vừa nhắc đến, có giống với công cụ phát hiện tĩnh mã thông báo ERC-20 không?
Luis: Có phần giống nhưng chưa thật chính xác. Điểm tương đồng là quy trình làm việc: quét mã tĩnh và đưa ra vị trí, nguyên nhân lỗ hổng. Khác biệt nằm ở chỗ lỗi mà mạch quan tâm chủ yếu chia thành hai loại: Under-Constrain (thiếu ràng buộc) và Over-Constrain (quá mức ràng buộc); đồng thời, phân tích cú pháp thông thường rất khó phát hiện các lỗi này.
Vụ Nguyệt: Nếu chỉ nói về "Constraint" thì hơi trừu tượng, anh có thể lấy ví dụ cụ thể không?
Luis: Tôi nghĩ có thể nhìn từ một góc độ khác, về bản chất, mạch thực chất là một dạng biểu đạt mang tính toán học cao hơn so với ngôn ngữ hợp đồng thông minh, cuối cùng nó phải được chuyển đổi thành R1CS, có thể hiểu là một biểu thức đa thức thuần túy. Vì vậy, một số lỗi thường gặp trong chương trình thông thường lại hiếm khi xảy ra trong mạch.
Bởi vì mạch về cơ bản "không sai", mỗi mạch đều cần input và output đúng để sinh proof tương ứng; nếu mạch có lỗi, nó sẽ không biên dịch được. Điều này đảm bảo kết quả tính toán của mạch luôn "đúng". Tuy nhiên, chỉ "đúng" là chưa đủ – mạch cần phải "đúng" trong mọi trường hợp, điều này dẫn đến hai vấn đề ràng buộc kể trên.
Nếu bị Over Constraint, sẽ có một số input hợp lệ không thể vượt qua mạch; nếu Under Constraint, những input không hợp lệ lại trở thành hợp lệ – cả hai đều là vấn đề nghiêm trọng.
Vụ Nguyệt: Vậy những lỗi này cũng là thứ mà trình biên dịch không phát hiện được, thuộc về các điều kiện tiền xử lý trước khi thiết kế mạch, tức là cách biểu đạt ban đầu đã có vấn đề, đúng không?
Luis: Đúng vậy, bởi vì những vấn đề này không hoàn toàn nằm ở cấp độ cú pháp, mà còn liên quan đến ý đồ của lập trình viên và một số chuẩn mực phổ biến trong mật mã học. Cụ thể, chúng thường cần dùng các công cụ hình thức như SMT-Solver để phát hiện.
4. Faust: Từ góc độ thương mại, anh nhìn nhận thế nào về mảng kiểm toán liên quan đến ZK?
Luis: Kiểm toán ZK là lĩnh vực đáng chú ý lâu dài. Chúng tôi luôn tích lũy kinh nghiệm trong mảng này. Việc sau này tham gia kiểm toán trong hệ sinh thái Bitcoin cũng vì nhận thấy sự kết hợp tốt giữa hệ sinh thái Bitcoin và ZK, trong khi chủ đề ZK Layer2 trên hệ sinh thái Ethereum đã phần nào lắng xuống, và làn sóng câu chuyện mới về ZK vẫn chưa thực sự đến, có thể liên quan đến FHE.
Dĩ nhiên, việc chúng tôi tham gia lĩnh vực kiểm toán ZK không quá sớm cũng không quá muộn, chủ yếu đang ở giai đoạn tích lũy dài hạn. Về mặt nghiệp vụ, chúng tôi duy trì hai hoạt động chính như đã nói: một là zkCTF, hai là zkScanner – công cụ phát hiện lỗ hổng mạch ZK.
Vụ Nguyệt: Anh có thể giới thiệu ngắn gọn về sự kiện zkCTF được không?
Luis: Đây là cuộc thi CTF (Capture The Flag) do chúng tôi khởi xướng, liên quan đến lĩnh vực ZK, tổ chức một lần mỗi năm, mời các nhà nghiên cứu an toàn hàng đầu trong ngành và các chuyên gia ZK tham gia. Chúng tôi phối hợp với Scroll, EthStorage và giáo sư Quách Vũ từ Anbi Lab để thiết lập đề bài cho thí sinh, và nhận được sự hỗ trợ mạnh mẽ từ các tổ chức như Ingonyama, zkMove, HashKey.
Danh sách thí sinh tham gia mà chúng tôi thống kê được đến từ khắp nơi trên thế giới, trình độ cũng rất cao, bao gồm:
OpenZepplin, Offside, Salus, Amber Group, Sec3, cũng như các nghiên cứu sinh tiến sĩ từ Georgia Tech và Berkeley chuyên về an toàn và ZK.
5. Faust: Tôi muốn hỏi thêm quan điểm của ScaleBit về hệ sinh thái Bitcoin. Nghe nói trước đây anh từng kiểm toán hơn 30 dự án trong hệ sinh thái Bitcoin, anh nhìn nhận thế nào về lớp thứ hai (Layer2) của Bitcoin?
Luis: Con số hơn 30 dự án hệ sinh thái Bitcoin nói trên bao gồm các dự án trên lớp thứ hai hoặc trong hệ sinh thái lớp thứ hai, ví dụ như UniSat, Arch Network, Merlin Chain, RGB++, B² Network,... cũng như các dự án liên quan đến inscription/rune như Liquidium, và phần lớn các dự án còn lại là các giao thức DeFi trong hệ sinh thái lớp thứ hai.
Về quan điểm đối với lớp thứ hai của Bitcoin, tôi khá đồng tình với quan điểm của đồng sáng lập Bitlayer Kevin He, ông ấy cho rằng cạnh tranh giữa các lớp thứ hai của Bitcoin sẽ trải qua ba giai đoạn: giai đoạn đầu cạnh tranh về TVL, giai đoạn hai thu hút nhà phát triển, giai đoạn ba mới là cạnh tranh về đường hướng công nghệ. Tôi cho rằng hiện tại chúng ta vừa kết thúc giai đoạn đầu, hoặc đang bắt đầu bước vào giai đoạn giành giật nhà phát triển và xây dựng hệ sinh thái.
Faust: Khi kiểm toán các dự án trong hệ sinh thái Bitcoin, anh chủ yếu xem xét ở những khía cạnh nào, hay theo chỉ số nào?
Luis: Nếu nói về lớp thứ hai của Bitcoin, chúng tôi chia thành nhiều chiều: một số cần kiểm tra script trên chuỗi Bitcoin, một số cần kiểm tra hợp đồng triển khai trên lớp thứ hai Bitcoin. Một số đối tượng kiểm toán là cầu nối xuyên chuỗi hoặc tầng底层, một số lớp thứ hai có thể không dùng EVM – tất cả các khía cạnh này đều cần được kiểm toán.
Chúng tôi chủ yếu xem xét các điểm tấn công (attack surface) trong mã nguồn của dự án, kiểm tra xem có lỗ hổng hay không từ nhiều khía cạnh, điều này thực sự rất phức tạp vì lớp thứ hai Bitcoin giống như một hệ thống chuỗi công. Tất cả các điểm mà ngành kiểm toán chuỗi công cần lưu ý, chúng tôi đều xem xét kỹ, ví dụ như dự án có bị tấn công double-spend, eclipse attack, Sybil attack, phụ thuộc bên ngoài có an toàn không, vấn đề tập trung hóa, man-in-the-middle attack… – nếu nói chi tiết thì rất dài, có thể dịp khác chúng ta sẽ bàn sâu hơn.
Năng lực kiểm toán chuỗi của ScaleBit có thể nói ít nhất là hàng đầu châu Á. Các thành viên nhóm từng phát hiện lỗ hổng trên các chuỗi công nổi tiếng như Sui, OKX Chain, GalaChain, Nervos, gần đây nhất còn phát hiện một lỗ hổng mức High và một mức Low trong cuộc thi kiểm toán công khai của Babylon.
6. Faust: Theo kinh nghiệm làm kiểm toán an toàn của anh, cầu nối xuyên chuỗi (cross-chain bridge) có phải là nơi dễ bị lỗi an toàn nhất không? Như tôi hiểu, nhiều cầu nối thực chất là mở rộng của DeFi, nên cũng dễ bị tấn công như các giao thức DeFi. Anh nghĩ sao về điều này?
Luis: Xét về tần suất, các khu vực liên quan đến DeFi dễ bị mất tiền nhất; nhưng xét về giá trị thiệt hại, các cầu nối khi bị tấn công thì tổn thất lớn nhất, một khi xảy ra vấn đề là sẽ thành sự cố nghiêm trọng. Dĩ nhiên khi tôi nói DeFi, chủ yếu là ở cấp độ hợp đồng – chỉ cần hợp đồng của giao thức DeFi có lỗi là có thể bị tấn công, biện pháp khắc phục cũng rất hạn chế.
Còn về cầu nối xuyên chuỗi, đúng là nơi dễ xảy ra sự cố nhất, vì bình thường cầu nối nắm giữ lượng tài sản lớn, hơn nữa nhiều cái dùng đa ký (multi-sig), rất dễ bị khai thác.
7. Faust: Anh nghĩ công cụ LLM như Chatgpt ảnh hưởng hay tác động đến công việc kiểm toán mã nguồn lớn đến đâu?
Luis: Thực tế hỗ trợ khá lớn, nhưng chủ yếu mang tính hỗ trợ. Đôi khi kiểm toán viên đọc mã nguồn, để nhanh chóng hiểu chức năng của đoạn mã, họ dùng Chatgpt để phân tích sơ bộ xem đoạn mã này làm gì, dĩ nhiên đây chỉ là hỗ trợ, cuối cùng vẫn cần con người xác định nhiều chi tiết.
Một phần khác là viết tài liệu và báo cáo kiểm toán, đặc biệt là viết tiếng Anh – một số kiểm toán viên tiếng Anh không tốt, họ nhờ Chatgpt chỉnh sửa văn bản, phần này giúp đỡ rất nhiều.
Tuy nhiên, xét từ góc độ kiểm toán, bên trong chúng tôi cũng đang huấn luyện một số LLM chuyên biệt, dùng các mô hình ngôn ngữ lớn mã nguồn mở để huấn luyện, nhưng hiện tại chỉ ở mức hỗ trợ, dù có thể tăng hiệu suất làm việc khoảng 20%, nhưng vẫn còn rất xa mới đến bước giảm mạnh số lượng kiểm toán viên.
Hiện tại LLM còn hai điểm yếu rõ rệt: một là bỏ sót (false negative), hai là cảnh báo sai (false positive). Chúng tôi có thể dùng LLM để đào lỗ hổng, nhưng phải chú ý tỷ lệ cảnh báo sai – nếu bạn dùng AI tìm lỗ hổng mã nguồn mà tỷ lệ sai rất cao, sẽ tốn rất nhiều thời gian, ngược lại thành gánh nặng. Nhưng chúng tôi sẽ tiếp tục theo dõi tiến triển của AI, ví dụ như liệu có thể đạt được hiệu quả cao trong việc phát hiện lỗ hổng ở tầng công cụ hay không – hiện tại vẫn còn rất mới mẻ, mọi người đều đang khám phá, nhưng chưa thấy tổ chức nào thực sự đạt được hiệu quả như vậy.
Vụ Nguyệt: Về kiểm toán mã nguồn tự động bằng AI, anh có nghĩ đây sẽ là trọng điểm trong tương lai không? Theo tôi hiểu, AI đọc mã gần như tức thì, kinh nghiệm tích lũy và trạng thái có thể vét cạn nhiều hơn con người rất nhiều – đây là lợi thế lớn của AI. Nếu một công ty an toàn đầu tư sâu vào mảng này, huấn luyện AI chuyên biệt để kiểm toán tự động, từ đó vượt qua đối thủ, anh nghĩ sao về điều này?
Luis: Chúng tôi luôn theo dõi hướng này, tôi nghĩ cần nhìn từ hai khía cạnh:
Khía cạnh thứ nhất, nếu cho rằng kiểm toán tự động bằng AI thực sự khả thi, thì sẽ dẫn đến một tình huống:
Lý thuyết mà nói, LLM có thể "hòa bình hóa" toàn bộ ngành kiểm toán mã nguồn, bởi nếu mọi người đều dùng LLM để sinh mã, và LLM đảm bảo mã sinh ra không có lỗi, thì bạn sẽ không cần kiểm toán nữa. Lúc đó nó không chỉ loại bỏ ngành kiểm toán, mà còn loại bỏ luôn cả lập trình viên. Nhưng để đạt được điều này, độ khó cực kỳ lớn.
Nếu cho rằng LLM có thể thay thế kiểm toán viên, thì độ khó chắc chắn còn cao hơn thay thế lập trình viên. So với việc đơn giản hiện thực mã đáp ứng yêu cầu, thì việc viết mã không có lỗ hổng khó hơn rất nhiều, vì vậy tôi cho rằng AI loại bỏ kiểm toán viên còn khó hơn thay thế lập trình viên.
Khía cạnh thứ hai là AI không thể trực tiếp quét sạch kiểm toán an toàn ngay lập tức, mà sẽ đột phá ở một số hướng trước. Ví dụ như đã nói, AI có thể giúp bạn đào lỗ hổng, dù không thể tìm hết mọi bug, nhưng có thể phát hiện một hai loại vấn đề mà kiểm toán thủ công dễ bỏ sót – những ứng dụng kiểu này chính là trọng tâm mà chúng tôi đang chú ý.
8. Faust: Tôi muốn hỏi thêm quan điểm của anh về công việc kiểm toán. Khi làm kiểm toán, quy trình cụ thể bao gồm những gì? Chắc không chỉ đơn giản là cấp một chứng chỉ thôi đúng không? Trong quá trình xem mã, có giúp tối ưu mã cho bên dự án luôn không?
Luis: Cái này tùy theo nhu cầu khách hàng, đôi khi chúng tôi giúp tối ưu mã gốc của khách hàng, ví dụ giúp một số thao tác DeFi tiết kiệm gas hơn.
Còn về quy trình kiểm toán, tôi xin giới thiệu sơ: chúng tôi thực hiện ít nhất hai vòng độc lập: kiểm toán sơ bộ và kiểm toán lại. Vòng sơ bộ do một nhóm người thực hiện riêng, sau đó bên dự án phải sửa mã theo phản hồi ban đầu; tiếp theo là vòng kiểm toán lại do một nhóm khác tiếp tục rà soát. Kết quả cuối cùng là ít nhất hai nhóm người sẽ kiểm tra chéo mã nguồn.
Nói về điểm khác biệt với các công ty kiểm toán khác, ScaleBit giỏi nhất ở kiểm toán các nghiệp vụ đổi mới, chúng tôi thích tuyển người có nền tảng CTF (cuộc thi an toàn) làm kiểm toán, vì họ học nhanh và am hiểu sâu về các hình thức tấn công.
Thêm nữa, chúng tôi khác biệt ở chỗ theo đuổi tuyến kiểm toán chất lượng cao, nếu phát hiện漏审漏洞 ở mức Major trở lên sau khi đã kiểm toán, chúng tôi sẽ hoàn lại 30–50% phí. Đây là điều mà các công ty kiểm toán khác không dám cam kết.
9. Faust: Có người cho rằng, kiểm toán an toàn thực chất dựa vào uy tín thương hiệu, giống như các tổ chức xếp hạng Phố Wall, hiệu ứng Matthew (Matthew Effect) rất mạnh – các công ty lâu đời như Slowmist có lợi thế tiên phong, hào sâu, các đối thủ mới rất khó cạnh tranh miếng bánh với họ. Anh nghĩ sao về điều này?
Luis: Tôi đồng ý một phần với quan điểm này, nhưng cũng cần xem xét từng trường hợp. Ví dụ, chúng tôi chia khách hàng theo nhu cầu kiểm toán thành ba loại: thấp, trung, cao. Dự án "dogshit" (rác) là loại thấp nhất, tiếp theo là loại trung bình – có thực lực nhất định nhưng chưa phải đội hình ngôi sao. Loại cao nhất là các đội hình ngôi sao, thực lực tài chính mạnh.
Trước tiên nói về nhóm khách hàng cao cấp, họ thường tìm 2–3 công ty kiểm toán trở lên, rất chú trọng chất lượng kiểm toán. Họ có thể tìm các tổ chức kiểm toán hàng đầu thế giới trước, nhưng các tổ chức này quá nhiều việc, có thể không ưu tiên đáp ứng nhu cầu của một số khách hàng nhất định, do đó nhiều đội ngũ dự án ngôi sao còn tìm thêm các tổ chức ít nổi tiếng hơn nhưng chất lượng kiểm toán tốt để cùng thẩm định.
Loại khách hàng nói trên là nhóm mà các công ty kiểm toán yêu thích nhất, vì họ giàu, nhưng cũng cực kỳ chú trọng chất lượng kiểm toán, nên thường tìm nhiều công ty kiểm toán – miễn là năng lực kiểm toán tốt, bạn đều có cơ hội tiếp cận họ. Đây cũng là một trong những nhóm khách hàng chính của chúng tôi.
Nhóm thứ hai là khách hàng tầm trung, "khá quan tâm đến chất lượng kiểm toán nhưng không nhất thiết có nhiều tiền", tuy nhiên có tiềm năng trở thành khách hàng đầu ngành trong tương lai. Họ mong muốn tìm các tổ chức kiểm toán nổi tiếng, nhưng có thể không đủ ngân sách.
Trong giới này, thực sự xứng danh "công ty an toàn hàng đầu" – kiểu OpenZeppelin, Trail of Bits – thì tối đa chỉ có khoảng 4–5 tổ chức. Mọi người đều biết họ rất giỏi, nhưng giá cũng rất đắt, có thể gấp 3–10 lần các công ty kiểm toán thông thường.
Khách hàng tầm trung tìm các tổ chức hàng đầu, có thể họ không nhận. Vì vậy đối với khách hàng tầm trung, thay vì dồn toàn bộ ngân sách để tìm một công ty kiểm toán đầu ngành, họ sẽ chia ngân sách cho các tổ chức kiểm toán chất lượng tốt, thậm chí thuê nhiều công ty kiểm toán. Đây là nhóm khách hàng lớn nhất của chúng tôi, và chúng tôi cũng mong muốn cùng họ phát triển.
Loại khách hàng cuối cùng là loại thấp nhất đã nói, các dự án "dogshit", họ chủ yếu tìm ai rẻ thì thuê, hoặc trả tiền để một tổ chức kiểm toán nổi tiếng kiểm tra hợp đồng.
Do đó, từ những điểm đã nói, quan điểm anh nêu có phần đúng về đánh giá ngành kiểm toán. Đối với các công ty kiểm toán có lịch sử tích lũy lâu dài, danh tiếng tốt, thực sự có hiệu ứng Matthew, nhưng bạn cũng thấy có một số công ty kiểm toán lâu đời, dù danh tiếng cao nhưng mấy năm gần đây cũng "bùng nổ" rất nhiều, liên tục dính sự cố.
Tuy nhiên, là một công ty kiểm toán mới nổi, nhất định phải có lợi thế khác biệt, vì vậy chiến lược của chúng tôi là đột phá điểm đơn:
Trước tiên đột nhập một ngách nhất định và chiếm ưu thế tuyệt đối. Ví dụ như trong hệ sinh thái Bitcoin Layer2, hiện tại tỷ lệ phủ sóng của chúng tôi đã vượt 50%; trong hệ sinh thái Move, tỷ lệ phủ sóng vượt 80%. Ngay cả các tổ chức kiểm toán hàng đầu như OpenZepplin cũng khó có thể cạnh tranh với chúng tôi ở các ngách nhỏ này. Vì vậy, "hiệu ứng Matthew" phụ thuộc vào bối cảnh cụ thể.
10. Faust: Từ góc độ cá nhân, sự khác biệt lớn nhất giữa an toàn Web2 và Web3 là gì? Anh có thể chia sẻ dựa trên trải nghiệm trước đây của mình.
Luis: Trước hết, tôi cho rằng an toàn Web3 xét về giai đoạn phát triển vẫn ở rất sớm, và thị trường an toàn Web3 chắc chắn lớn hơn Web2, vì Web3 đòi hỏi an toàn cao hơn nhiều.
Tôi kể một câu chuyện vui: trước đây có một quản lý người Hoa trong giới an toàn Thung lũng Silicon, từng làm đến cấp Phó Chủ tịch (VP) tại một công ty niêm yết. Ông ấy nói rằng trong giới an toàn Thung lũng Silicon chủ yếu là hai cộng đồng: người Hoa và người Do Thái. Tại sao người Hoa làm an toàn tốt vậy? Vì ngành an toàn điển hình là bình thường vô hình, một khi xảy ra sự cố thì phải chịu trách nhiệm – người Ấn Độ và người da trắng không muốn làm, nên người Hoa nổi lên – đây là đối với an toàn Web2;
Nhưng an toàn Web3 thì khác, vì blockchain trực tiếp liên quan đến tiền, nên sự hiện diện của an toàn Web3 lớn hơn nhiều cấp độ, hơn nữa trong lĩnh vực này, nhiều "chuyên gia an toàn" có thể trực tiếp kiếm lời – có người từng đùa rằng, người chuyển đổi thành công nhất từ Web2 sang Web3 chính là hacker.
Xét về kỹ thuật, an toàn Web3 bao gồm một phần nội dung của an toàn Web2, tái sử dụng nhiều công nghệ từ phía sau. Hiện nay nhiều hệ thống, ví dụ như nhiều ứng dụng DeFi có máy chủ và giao diện, chúng vẫn cần kiểm thử xâm nhập truyền thống, phòng chống DoS... – thực tế cũng là một phần của an toàn Web2.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@godrealmx
