Trong cuộc phỏng vấn độc quyền này, được thực hiện trong Hội nghị Hack Seasons, Alp Bassa, Nhà khoa học nghiên cứu tại Veridise, chia sẻ những hiểu biết sâu sắc về các công cụ đổi mới của Veridise, sự phức tạp của việc kiểm tra bằng chứng không có kiến thức và tương lai của bảo mật chuỗi khối. Trong cuộc thảo luận, chúng ta sẽ khám phá sự giao thoa giữa toán học, mật mã và công nghệ chuỗi khối qua con mắt của một trong những chuyên gia hàng đầu trong ngành.
Nhiều doanh nhân bị thu hút bởi lĩnh vực của họ bởi một thời điểm hoặc sự kiện cụ thể. Hành trình đến với Web3 của bạn là gì?
Tôi đến từ một nền tảng học thuật. Tôi là một nhà toán học đang nghiên cứu lý thuyết số, tập trung vào các đường cong trên trường hữu hạn, đường cong elip và ứng dụng của chúng trong lý thuyết mã hóa và mật mã. Những công cụ này được sử dụng nhiều, đặc biệt là hiện nay với mật mã không kiến thức có ảnh hưởng lớn hơn trong không gian Web3.
Tôi thấy ở đó có rất nhiều điều thú vị. Sau đó, tôi bắt đầu làm việc tại Veridise, nơi họ thực hiện kiểm tra bảo mật và đặc biệt chuyên về miền ZK, lĩnh vực chuyên môn của tôi rất phù hợp.
Tại sao chúng ta thậm chí cần kiểm tra bảo mật? Các nhà phát triển có thể hoạt động mà không có chúng không hay chúng là bắt buộc?
Tính bảo mật của hệ thống đòi hỏi một tư duy khác mà bạn phải áp dụng ở giai đoạn phát triển. Không phải tất cả các nhà phát triển đều có thể tập trung đồng thời vào tất cả các khía cạnh của quá trình phát triển – đảm bảo các thông số kỹ thuật, hành vi, hiệu quả, tích hợp vào một thiết lập lớn hơn và bảo mật phù hợp. Hầu hết thời gian, bảo mật là một khía cạnh không được đề cập đầy đủ trong suốt quá trình phát triển.
Nhà phát triển gần như không thể đủ tự tin với nhiều công cụ phức tạp khác nhau để đảm bảo chúng được sử dụng đúng cách và không có lỗ hổng bảo mật. Đó chỉ là một tư duy khác cần được áp dụng. Đó là lý do tại sao kiểm toán lại hữu ích.
Bạn có thể giải thích chi tiết hơn về các công cụ nội bộ mà Veridise đã phát triển và cách chúng nâng cao chất lượng kiểm toán không?
Có rất nhiều công cụ có thể được sử dụng. Một số nguyên thủy hơn nhưng không yêu cầu quá nhiều nền tảng và có thể truy cập dễ dàng, chẳng hạn như bộ làm mờ. Một số nằm ở giữa, giống như các công cụ phân tích tĩnh. Chúng khá nhanh nhưng không quá chính xác – chúng có thể đưa ra một số kết quả dương tính giả.
Sau đó, có những công cụ được hỗ trợ rất nhiều bởi toán học, dựa trên bộ giải SMT và nền tảng toán học khác. Đây là những kết quả rất chính xác nhưng nặng về mặt tính toán. Chúng tôi sử dụng kết hợp tất cả các công cụ này, mỗi công cụ đều có ưu và nhược điểm riêng để phát hiện lỗi và lỗ hổng bảo mật.
Một số cân nhắc bảo mật duy nhất mà Veridise giải quyết cho các giao thức DeFi là gì?
Đối với các giao thức DeFi, chúng tôi có một công cụ phân tích tĩnh trong đó bạn cho hệ thống biết trước loại lỗ hổng nào cần tìm hoặc cấu trúc nào cần nhắm tới. Có rất nhiều trong số họ. Ví dụ: các cuộc tấn công reentrancy là nguyên nhân gây ra vụ hack DAO năm 2016. Các cuộc tấn công cho vay flash đã bị khai thác trong cuộc tấn công vào Cream Finance, khiến khoảng 130 triệu đô la bị đánh cắp.
Qua kinh nghiệm kiểm tra qua nhiều năm, chúng tôi có cái nhìn tổng quan rõ ràng về các lỗ hổng bảo mật và các công cụ của chúng tôi được tạo ra để kiểm tra tất cả những lỗ hổng này. Trong quá trình kiểm toán, chúng tôi xem xét từng vấn đề một cách chi tiết để xem liệu những rủi ro đó có xuất hiện hay không.
Vui lòng giải thích thêm về cách bạn sử dụng công nghệ ZK và tại sao kiểm toán ZK lại là ưu tiên chính của bạn?
ZK đặc biệt thú vị từ góc độ xác minh chính thức vì nó chuyển dịch rất tốt sang việc sử dụng các công cụ. Chúng tôi có các công cụ đặc biệt nhằm mục đích kiểm tra các ứng dụng ZK. Bởi vì nó rất phù hợp với phương pháp của chúng tôi nên đó là lĩnh vực chúng tôi tập trung rất nhiều.
Chúng tôi đã xác định được các lỗ hổng nghiêm trọng trong thư viện mạch lõi. Nhóm của chúng tôi rất mạnh trong lĩnh vực đó, vì vậy chúng tôi quyết định có mặt và đi đầu trong lĩnh vực kiểm toán ZK. Hầu hết nghiên cứu của chúng tôi cũng được thúc đẩy bởi nhu cầu và yêu cầu từ quan điểm của kiểm toán viên về lĩnh vực ZK.
Chuyên môn của bạn về mạch ZK khác biệt như thế nào so với các công ty khác?
Tôi có thể nói rằng các công cụ của chúng tôi là thứ khiến chúng tôi khác biệt rất nhiều vì chúng tôi có nền tảng xác minh chính thức. Chúng tôi có những công cụ rất mạnh và hiện tại, quy mô của các dự án đã trở nên lớn đến mức nỗ lực của con người thôi là không thực sự đủ để có được phạm vi bao quát tốt về cơ sở mã. Nó cần thiết, nhưng tự nó thì chưa đủ.
Veridise cân bằng việc xem xét mã thủ công với công cụ phân tích tự động trong quy trình kiểm tra như thế nào?
Có nhu cầu cho cả hai. Chúng tôi cũng nhận thấy điều đó trong các cuộc kiểm toán. Hầu hết, khi chúng tôi thực hiện kiểm tra con người rất nghiêm ngặt và sau đó chạy các công cụ trên cơ sở mã, chúng tôi tìm thấy một số lỗ hổng mà chúng tôi không chú ý. Đôi khi, chúng tôi chạy công cụ trước nhưng công cụ chỉ có thể phát hiện một số loại cấu trúc nhất định.
Vì có rất nhiều lớp phức tạp và trừu tượng trong các hệ thống này nên chỉ dựa vào các công cụ thôi là chưa đủ. Tôi cảm thấy như bạn không thể làm gì nếu không có một trong hai thứ đó và tôi không nghĩ điều đó sẽ thay đổi trong tương lai.
Các tính năng chính của công cụ Vanguard của Veridise là gì và nó cải thiện tính bảo mật của hợp đồng thông minh như thế nào?
Vanguard là một trong những công cụ chính của chúng tôi. Nó được sử dụng để phân tích tĩnh. Trong phân tích tĩnh, bạn cung cấp một đặc điểm kỹ thuật nhất định về hành vi dự định và sau đó kiểm tra xem điều đó có thỏa mãn hay không – liệu các thuộc tính nhất định có giữ nguyên mà không chạy mã hay không. Nó không năng động; bạn không thực thi mã, nhưng bạn cố gắng đánh giá một cách tĩnh xem liệu có một số mẫu nhất định có thể gây ra lỗ hổng hay không.
Vanguard có nhiều hương vị. Chúng tôi có các phần của nó khá tốt để cải thiện tính bảo mật của hợp đồng thông minh và các phần tập trung vào các ứng dụng zk.
Bạn có thể nói rõ hơn về các lỗ hổng bạn gặp phải trong hợp đồng thông minh và mạch ZK không?
Trong các mạch ZK mà tôi nghiên cứu nhiều hơn, một trong những lỗ hổng thường gặp nhất là các mạch bị ràng buộc dưới mức. Trong ứng dụng ZK, cơ sở mã của bạn bao gồm hai phần: chính chương trình (thực thi thông thường) và các ràng buộc. Bạn yêu cầu các ràng buộc phản ánh hành vi thực hiện chương trình theo cách một-một.
Theo một bài báo gần đây, khoảng 95% tất cả các lỗ hổng trong mạch ZK là do các mạch bị ràng buộc dưới mức gây ra. Chúng tôi có các công cụ, chẳng hạn như PICUS, đặc biệt nhằm mục đích phát hiện các mạch bị giới hạn dưới mức đó.
Veridise tiếp cận quy trình công bố các lỗ hổng được phát hiện trong quá trình kiểm tra như thế nào?
Tất nhiên, chúng tôi không công khai các lỗ hổng vào bất kỳ thời điểm nào vì người khác có thể khai thác lỗi trước khi nó được sửa, đặc biệt nếu cơ sở mã đã được sử dụng. Khi kết thúc quá trình kiểm tra, chúng tôi cung cấp báo cáo kiểm tra, trong đó chúng tôi cung cấp cho khách hàng danh sách tất cả các lỗi và lỗ hổng bảo mật mà chúng tôi đã phát hiện.
Chúng tôi cho khách hàng một khoảng thời gian để khắc phục những vấn đề đó, sau đó họ gửi cho chúng tôi các bản sửa lỗi mà chúng tôi xem xét để kiểm tra xem liệu chúng có thực sự giải quyết được tất cả các vấn đề mà chúng tôi đã nêu ra hay không. Chúng tôi tập hợp tất cả lại trong một báo cáo cuối cùng. Báo cáo là tài sản của khách hàng. Chúng tôi không công khai trừ khi khách hàng đồng ý.
Nếu truy cập trang web Veridise, bạn có thể thấy danh sách tất cả các báo cáo kiểm tra mà khách hàng đã đồng ý công khai. Trong hầu hết các trường hợp, họ đồng ý để chúng tôi công khai thông tin đó. Trên thực tế, họ muốn nó như một chứng chỉ cho thấy mã đã được kiểm tra và không có lỗi sau khi kiểm tra.
Veridise điều chỉnh quy trình kiểm tra của mình như thế nào cho phù hợp với các nền tảng và ngôn ngữ blockchain khác nhau?
Như bạn đã biết, lĩnh vực này rất sôi động và mỗi ngày đều có những chuỗi mới, ngôn ngữ mới và cách thể hiện mạch ZK mới. Chúng tôi cũng thấy điều đó với các dự án sắp tới và các yêu cầu kiểm tra dựa trên các môi trường hoặc ngôn ngữ khác nhau. Chúng tôi đi theo dòng chảy, xem các yêu cầu đến từ đâu và dự đoán lĩnh vực này sẽ phát triển theo hướng nào trong tương lai gần.
Chúng tôi cố gắng điều chỉnh các công cụ của mình để đáp ứng nhu cầu của cộng đồng. Điều này sẽ tiếp tục trong tương lai, nơi chúng tôi sẽ thay đổi mọi thứ một cách linh hoạt tùy theo sự phát triển của lĩnh vực này.
Bạn có thể giải thích thêm về các công cụ bạn dự định triển khai trong tương lai không?
Một hướng mà các công cụ sẽ thay đổi trong tương lai gần là chúng tôi sẽ cung cấp dịch vụ bảo mật. Nó được gọi là nền tảng SaaS của chúng tôi, nơi chúng tôi sẽ cung cấp các công cụ cho mọi người sử dụng trong quá trình phát triển.
Thay vì hoàn thành toàn bộ dự án trước rồi thực hiện kiểm tra, chúng tôi sẽ làm cho các công cụ của mình trở nên hữu ích trong quá trình thiết lập nơi các nhà phát triển có thể sử dụng chúng trong khi phát triển để đảm bảo rằng mã họ đang phát triển được an toàn và không chứa bất kỳ lỗ hổng nào. SaaS sẽ có sẵn trong tương lai gần.
Bài đăng Bẻ khóa các lỗ hổng DeFi: Đi sâu vào bảo mật hợp đồng thông minh của Alp Bassa xuất hiện đầu tiên trên Metaverse Post.
