Vitalik: Đâu là chìa khóa cho giai đoạn tiếp theo của Ethereum?

Tác giả: Vitalik Buterin

Dịch bởi: Jiahua, ChainCatcher

Xin chân thành cảm ơn Yoichi Hirai, Justin Drake, Nadim Kobeissi và Alex Hicks vì những phản hồi và nhận xét của họ.

Trong vài tháng gần đây, một mô hình lập trình mới đã nhanh chóng được ưa chuộng trong giới phát triển Ethereum và nhiều lĩnh vực khác của điện toán: viết mã trực tiếp bằng các ngôn ngữ cấp thấp (như mã bytecode EVM, ngôn ngữ assembly) hoặc Lean, và sử dụng các bằng chứng toán học có thể tự động kiểm chứng được viết bằng Lean để xác thực tính đúng đắn của nó.

Nếu thực hiện đúng cách, phương pháp này không chỉ có tiềm năng tạo ra mã nguồn cực kỳ hiệu quả mà còn an toàn hơn nhiều so với các phương pháp lập trình trước đây. Yoichi Hirai gọi đây là "hình thức phát triển phần mềm tối ưu".

Bài viết này sẽ cố gắng làm sáng tỏ các nguyên tắc cơ bản, khám phá những gì mà việc xác thực chính thức phần mềm có thể đạt được, và xác định những điểm yếu và hạn chế của nó trong Ethereum và các lĩnh vực khác.

Kiểm chứng hình thức là gì?

Kiểm chứng hình thức đề cập đến quá trình viết các chứng minh cho các định lý toán học theo cách có thể được kiểm tra tự động. Để đưa ra một ví dụ tương đối đơn giản nhưng thú vị, hãy xem xét một định lý cơ bản về dãy Fibonacci: cứ ba số thì có một số chẵn, còn các số khác là lẻ.

1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 …

Một cách đơn giản để chứng minh điều này là thông qua phép quy nạp toán học, tiến lên ba bước một lần.

Đầu tiên là trường hợp cơ bản. Giả sử F1 = F2 = 1, F3 = 2. Quan sát cho thấy, mệnh đề ("Fi là số chẵn khi i là bội số của 3, nếu không thì là số lẻ") đúng trước khi x = 3.

Tiếp theo là trường hợp quy nạp. Giả sử mệnh đề đúng trước 3k+3, nghĩa là chúng ta đã biết tính chẵn lẻ của F3k+1, F3k+2 và F3k+3 lần lượt là lẻ, lẻ và chẵn. Chúng ta có thể tính tính chẵn lẻ của nhóm ba số tiếp theo:

F3k+4 = F3k+2 + F3k+3 = lẻ + chẵn = lẻ

F3k+5 = F3k+3 + F3k+4 = chẵn + lẻ = lẻ

F3k+6 = F3k+4 + F3k+5 = lẻ + lẻ = chẵn

Như vậy, từ việc biết rằng mệnh đề đúng trước 3k+3, ta suy ra rằng mệnh đề cũng đúng trước 3k+6. Ta có thể lặp lại lập luận này, đảm bảo rằng quy tắc này đúng với mọi số nguyên.

Lập luận này đủ để thuyết phục con người. Tuy nhiên, nếu bạn muốn chứng minh một điều gì đó phức tạp hơn gấp trăm lần, và bạn muốn chắc chắn tuyệt đối rằng mình không mắc sai lầm? Bạn có thể đưa ra một bằng chứng mà máy tính cũng có thể bị thuyết phục.

Cách trình bày như sau:

-- Dãy Fibonacci với fib 0 = 0, fib 1 = 1, fib 2 = 1 (các chỉ số lệch nhau 1 đơn vị)

def fib : Nat → Nat

| 0 => 0

| 1 => 1

| n + 2 => fib (n + 1) + fib n

-- Khẳng định: Fibonacci (3k+1) là số lẻ, Fibonacci (3k+2) là số lẻ, Fibonacci (3k+3) là số chẵn.

-- Tương đương: cứ ba số Fibonacci một, bắt đầu từ dãy Fibonacci 3, thì có một số chẵn.

-- Chúng ta chứng minh cả ba cùng một lúc bằng quy nạp theo k, vì mỗi trường hợp

-- Khối tiếp theo được xây dựng từ khối trước đó.

định lý fib_triple (k : Nat) :

fib (3 * k + 1) % 2 = 1 ∧

fib (3 * k + 2) % 2 = 1 ∧

fib (3 * k + 3) % 2 = 0 := bởi

cảm ứng k với

| số không => quyết định

| succ k ih =>

-- Viết lại các chỉ số mới dưới dạng (cái gì đó) + 2 để dãy Fibonacci được khai triển.

tinh chỉnh ⟨?_, ?_, ?_⟩

· hiển thị (fib (3 * k + 3) + fib (3 * k + 2)) % 2 = 1

omega

· hiển thị (fib (3 * k + 3) + fib (3 * k + 2) + fib (3 * k + 3)) % 2 = 1

omega

· hiển thị (fib (3 * k + 3) + fib (3 * k + 2) + fib (3 * k + 3)

+ (fib(3 * k + 3) + fib(3 * k + 2))) % 2 = 0

omega

Đây là cùng một logic lập luận, nhưng được thể hiện bằng ngôn ngữ Lean. Lean là một ngôn ngữ lập trình thường được sử dụng để viết và kiểm chứng các chứng minh toán học.

Điều này trông khác với bằng chứng "con người" được đưa ra ở trên vì lý do chính đáng: những gì trực quan đối với máy tính (theo nghĩa truyền thống của "máy tính," tức là một chương trình "xác định" được cấu tạo từ các câu lệnh if/then, chứ không phải các mô hình ngôn ngữ lớn) về cơ bản khác với những gì trực quan đối với con người.

Trong chứng minh trên, bạn không nhấn mạnh thực tế rằng fib(3k+4) = fib(3k+3) + fib(3k+2), mà lại nhấn mạnh rằng fib(3k+3) + fib(3k+2) là số lẻ, trong khi một chiến lược trong Lean có tên là omega tự động kết hợp điều này với kiến thức về định nghĩa của fib(3k+4).

Trong các chứng minh phức tạp hơn, đôi khi bạn phải nêu rõ định luật toán học nào cho phép bạn thực hiện bước hiện tại, và đôi khi bạn phải sử dụng những tên gọi khó hiểu như Prod.mk.inj.

Mặt khác, bạn có thể khai triển các biểu thức đa thức khổng lồ chỉ trong một bước và chứng minh tính đúng đắn của chúng chỉ bằng một dòng biểu thức đơn giản như "omega" hoặc "ring".

Bản chất không trực quan và rườm rà này phần lớn giải thích tại sao, mặc dù các bằng chứng có thể kiểm chứng bằng máy móc đã tồn tại gần 60 năm, lĩnh vực này vẫn còn là một lĩnh vực chuyên biệt. Tuy nhiên, mặt khác, nhờ sự phát triển nhanh chóng của trí tuệ nhân tạo, nhiều điều trước đây không thể thực hiện được nay đang nhanh chóng trở nên khả thi.

Khi các chứng minh toán học bắt đầu bảo vệ mã nguồn

Đến đây, có lẽ bạn đang nghĩ: máy tính có thể kiểm chứng các định lý toán học, vậy nên cuối cùng chúng ta có thể xác định được những kết luận mới lạ nào về số nguyên tố là đúng và những kết luận nào chỉ là lỗi trong các bài báo PDF dài hàng trăm trang.

Biết đâu chúng ta còn có thể tìm ra liệu quan điểm của Shinichi Mochizuki về giả thuyết ABC có đúng hay không!

Nhưng tạm gác sự tò mò sang một bên, thì sao chứ?

Có nhiều câu trả lời khả thi. Nhưng một câu trả lời rất quan trọng đối với tôi là xác minh tính chính xác của các chương trình máy tính, đặc biệt là những chương trình thực hiện các tác vụ mã hóa hoặc liên quan đến bảo mật.

Xét cho cùng, các chương trình máy tính là các đối tượng toán học, vì vậy việc chứng minh một chương trình máy tính hoạt động theo một cách nhất định chính là một định lý toán học.

Ví dụ, giả sử bạn muốn chứng minh liệu phần mềm liên lạc mã hóa như Signal có thực sự an toàn hay không. Bạn có thể viết ra ý nghĩa của "an toàn" về mặt toán học trong ngữ cảnh này.

Ở mức độ tổng quát, điều bạn đang chứng minh là, giả sử một số giả định mật mã nhất định là đúng, chỉ những người sở hữu khóa riêng mới có thể biết bất kỳ thông tin nào về nội dung của thông điệp. Trên thực tế, có rất nhiều thuộc tính bảo mật khác nhau rất quan trọng.

Hóa ra quả thực có một nhóm đang cố gắng tìm ra lời giải cho vấn đề này! Một trong những định lý bảo mật của họ trông như thế này:

định lý bí mật thụ động_le_ddh

(g : G)

(adv : PassiveAdversary G SK) :

passiveSecurityAdvantage (F := F) g adv ≤

ProbComp.boolDistAdvantage

(DiffieHellman.ddhExpReal (F := F) g (ddhReduction adv))

(DiffieHellman.ddhExpRand (F := F) g (ddhReduction adv))

Dưới đây là bản tóm tắt ý nghĩa của nó theo Leanstral:

Định lý passivesecrecyle_ddh là một phép quy giản gọn gàng cho thấy rằng tính bảo mật thông điệp thụ động của X3DH khó bảo mật ít nhất cũng bằng giả định DDH trong mô hình oracle ngẫu nhiên. Nếu kẻ thù có thể phá vỡ tính bảo mật thông điệp thụ động của X3DH, thì chúng cũng có thể phá vỡ DDH.

Vì ta giả định rằng DDH khó bị phá vỡ, nên X3DH cũng an toàn trước các cuộc tấn công thụ động. Định lý này chứng minh rằng nếu kẻ thù có thể quan sát thụ động các thông điệp trao đổi khóa của Signal, chúng không thể phân biệt được khóa phiên mà Signal tạo ra với một khóa ngẫu nhiên với xác suất tốt hơn mức không đáng kể.

Nếu kết hợp điều này với bằng chứng chính xác về việc triển khai mã hóa AES, bạn sẽ có được bằng chứng cho thấy mã hóa của giao thức Signal an toàn trước các kẻ tấn công thụ động.

Các dự án tương tự cũng đã chứng minh rằng việc triển khai TLS và các phần khác của mật mã nội bộ trình duyệt là an toàn.

Nếu bạn thực hiện xác minh hình thức hoàn chỉnh từ đầu đến cuối, bạn không chỉ chứng minh rằng một số mô tả lý thuyết về giao thức là an toàn, mà còn chứng minh rằng mã cụ thể do người dùng chạy cũng an toàn trong thực tế.

Từ góc nhìn của người dùng, điều này giúp tăng cường đáng kể tính trung thực: để hoàn toàn tin tưởng vào mã nguồn, bạn không cần phải kiểm tra toàn bộ mã nguồn; bạn chỉ cần kiểm tra những câu lệnh về nó đã được chứng minh.

Tuy nhiên, cần lưu ý một số điểm quan trọng, đặc biệt là về ý nghĩa thực sự của từ "an toàn".

Thật dễ dàng quên mất việc chứng minh những tuyên bố thực sự quan trọng đó. Thật dễ dàng nhận thấy rằng đôi khi những tuyên bố cần chứng minh lại khó mô tả hơn chính đoạn mã lập trình.

Rất dễ vô tình đưa ra những giả định không đúng trong quá trình chứng minh. Cũng rất dễ quyết định rằng chỉ cần chứng minh một phần của hệ thống một cách chính thức, nhưng lại phát hiện ra những lỗ hổng nghiêm trọng ở các phần khác (thậm chí cả phần cứng).

Ngay cả quá trình triển khai Lean cũng có thể gặp lỗi. Nhưng trước khi bàn luận về tất cả những chi tiết khó chịu này, chúng ta hãy cùng tìm hiểu về viễn cảnh lý tưởng có thể đạt được nếu hoàn thành việc xác minh chính thức một cách chính xác và lý tưởng.

Xác minh chính thức được sinh ra vì mục đích bảo mật

Lỗi trong mã máy tính thật đáng sợ.

Khi bạn đưa tiền điện tử vào các hợp đồng thông minh trên chuỗi khối bất biến, và Triều Tiên có thể tự động rút hết tiền của bạn khi một lỗi xuất hiện trong mã lập trình mà bạn không có cách nào khắc phục, thì các lỗi trong mã lập trình trở nên đáng sợ hơn bao giờ hết.

Khi tất cả điều này được bao bọc bởi bằng chứng không tiết lộ thông tin, các lỗi bảo mật trở nên đáng sợ hơn nữa vì nếu ai đó tìm cách xâm nhập vào hệ thống bằng chứng không tiết lộ thông tin, họ có thể lấy đi toàn bộ tiền và chúng ta không hề biết chuyện gì đã xảy ra (tệ hơn nữa, chúng ta thậm chí không biết khi nào thì sự cố xảy ra).

Khi chúng ta có những mô hình AI mạnh mẽ, như Claude Mythos trong hai năm tới, có thể tự động phát hiện ra những lỗi này, thì lỗi trong mã lập trình sẽ trở nên đáng sợ hơn nhiều.

Một số người phản ứng trước thực tế này bằng cách ủng hộ việc từ bỏ ý tưởng cơ bản về hợp đồng thông minh, thậm chí tin rằng internet không thể là một lĩnh vực mà bên phòng thủ có thể có lợi thế bất đối xứng so với bên tấn công.

Một số câu trích dẫn:

Để tăng cường bảo mật cho hệ thống, bạn cần chi tiêu nhiều token hơn số token mà kẻ tấn công sử dụng để khai thác các lỗ hổng.

Và:

Ngành công nghiệp của chúng ta được xây dựng dựa trên mã lập trình có tính xác định. Viết mã, kiểm thử, triển khai, và tự tin rằng nó hoạt động, nhưng theo kinh nghiệm của tôi, hợp đồng này đang bị phá vỡ.

Đối với các nhà điều hành hàng đầu của những công ty thực sự chuyên về trí tuệ nhân tạo, mã nguồn đã trở thành thứ mà bạn "tin tưởng" để vận hành, và bạn không còn có thể xác định chính xác xác suất thành công của nó nữa.

Tệ hơn nữa, một số người tin rằng giải pháp duy nhất là từ bỏ mã nguồn mở.

Đối với an ninh mạng, đây sẽ là một tương lai ảm đạm. Đặc biệt đối với những người trong chúng ta quan tâm đến sự phi tập trung và tự do của internet, đây là một viễn cảnh cực kỳ bi quan.

Toàn bộ tinh thần của phong trào cypherpunk về cơ bản được xây dựng trên ý tưởng rằng trên internet, bên phòng thủ có lợi thế, và việc xây dựng một "lâu đài" kỹ thuật số (cho dù thông qua mã hóa, chữ ký điện tử hay bằng chứng) dễ dàng hơn nhiều so với việc phá hủy một lâu đài như vậy.

Nếu chúng ta đánh mất điều này, thì an ninh mạng chỉ có thể đến từ lợi thế quy mô, từ việc truy lùng những kẻ tấn công tiềm năng trên toàn thế giới, và, rộng hơn, chỉ có thể là sự lựa chọn giữa thống trị và hủy diệt.

Tôi không đồng ý; tôi có một cái nhìn lạc quan hơn về tương lai của an ninh mạng.

Tôi tin rằng những thách thức do khả năng tìm kiếm lỗ hổng bảo mật mạnh mẽ của AI đặt ra là rất nghiêm trọng, nhưng đó chỉ là thách thức trong giai đoạn chuyển tiếp. Khi mọi thứ ổn định và chúng ta đạt được trạng thái cân bằng mới, môi trường bảo mật sẽ thuận lợi hơn cho các nhà bảo vệ so với trước đây.

Mozilla đồng ý với quan điểm của tôi. Trích dẫn lời họ:

Bạn có thể cần phải điều chỉnh lại thứ tự ưu tiên của mọi việc khác và dành toàn bộ năng lượng tập trung cho nhiệm vụ này, nhưng chắc chắn sẽ có ánh sáng ở cuối đường hầm.

Chúng tôi rất tự hào về cách đội ngũ của mình đang vượt qua thử thách này, và những người khác cũng sẽ như vậy. Công việc của chúng tôi chưa hoàn thành, nhưng chúng tôi đã vượt qua được cơn bão và có thể nhìn thấy một tương lai không chỉ đáp ứng được kỳ vọng mà còn tốt đẹp hơn nhiều.

Cuối cùng thì những người phòng thủ cũng có cơ hội giành chiến thắng quyết định. … Các lỗi rất hạn chế, và chúng ta đang bước vào một thế giới nơi cuối cùng chúng ta có thể tìm ra tất cả chúng.

Giờ đây, nếu bạn tìm kiếm các từ "chính thức" và "xác minh" trong bài đăng của Mozilla bằng Ctrl+F, bạn sẽ không tìm thấy kết quả nào. Tương lai tươi sáng của an ninh mạng không hoàn toàn phụ thuộc vào xác minh chính thức hay bất kỳ công nghệ đơn lẻ nào khác.

Nó phụ thuộc vào điều gì? Về cơ bản, đó là biểu đồ này:

Xu hướng các lỗ hổng CVE theo thời gian

Trong nhiều thập kỷ qua, nhiều công nghệ đã góp phần làm giảm số lượng lỗ hổng bảo mật:

Hệ thống kiểu

Ngôn ngữ an toàn cho bộ nhớ

Những cải tiến trong kiến trúc phần mềm (bao gồm cả việc sử dụng hộp cát, kiểm soát quyền truy cập và phân biệt rõ hơn giữa "nền tảng điện toán đáng tin cậy" với "mã nguồn khác")

Các phương pháp kiểm tra tốt hơn

Một kho kiến thức không ngừng mở rộng về các mô hình lập trình an toàn và không an toàn.

Số lượng thư viện phần mềm được viết sẵn và kiểm định ngày càng tăng.

Việc xác minh chính thức có sự hỗ trợ của trí tuệ nhân tạo không nên được xem là một mô hình hoàn toàn mới, mà đúng hơn là một động lực mạnh mẽ thúc đẩy các xu hướng và mô hình đang phát triển.

Xác minh hình thức không phải là thuốc chữa bách bệnh. Nhưng nó đặc biệt phù hợp với những tình huống mà mục tiêu đơn giản hơn nhiều so với việc triển khai. Điều này đặc biệt đúng với một số công nghệ cực kỳ phức tạp và khó khăn mà chúng ta sẽ cần triển khai trong phiên bản chính tiếp theo của Ethereum: chữ ký chống lượng tử, STARK, thuật toán đồng thuận và ZK-EVM.

STARK là một phần mềm rất phức tạp. Nhưng các thuộc tính bảo mật cốt lõi mà nó triển khai rất dễ hiểu và chính thức hóa: nếu bạn thấy một hàm băm H trỏ đến chương trình P, đầu vào là x và đầu ra là y, thì hoặc (i) thuật toán băm được sử dụng trong STARK đã bị phá vỡ, hoặc (ii) P(x) = y.

Do đó, chúng ta có dự án Arklib, đang cố gắng tạo ra một triển khai STARK được xác thực chính thức đầy đủ (xem VCV-io, cung cấp cơ sở hạ tầng điện toán oracle nền tảng cho việc xác thực chính thức nhiều giao thức mật mã khác nhau, nhiều trong số đó là các phụ thuộc của STARK).

Tham vọng hơn nữa là dự án evm-asm: một dự án nhằm xây dựng một hệ thống triển khai EVM hoàn chỉnh và được kiểm chứng chính thức đầy đủ.

Các đặc tính bảo mật ở đây không đơn giản như vậy: về cơ bản, mục tiêu là chứng minh tính tương đương của nó với một triển khai EVM khác được viết bằng Lean, mặc dù triển khai đó có thể được viết để tối đa hóa tính trực quan và dễ đọc mà không cần xem xét hiệu quả thời gian chạy cụ thể.

Có khả năng chúng ta sẽ có mười phiên bản EVM khác nhau, tất cả đều được chứng minh là tương đương, và tất cả chúng đều chứa cùng một lỗ hổng nghiêm trọng cho phép kẻ tấn công rút hết ETH từ các địa chỉ mà chúng không được phép truy cập.

Nhưng điều này ít có khả năng xảy ra hơn so với khả năng tồn tại những lỗi như vậy trong một số triển khai EVM hiện tại. Một thuộc tính bảo mật khác mà chúng ta chỉ nhận ra tầm quan trọng sau những bài học đau thương, đó là khả năng chống lại các cuộc tấn công DoS, cũng rất dễ dàng để định lượng.

Hai lĩnh vực quan trọng khác là:

Cơ chế đồng thuận chịu lỗi Byzantine. Ở đây, việc chính thức hóa tất cả các thuộc tính bảo mật dự kiến đều khó khăn như nhau, nhưng xét đến mức độ phổ biến của các lỗi, việc thử nghiệm là đáng giá. Do đó, chúng tôi đang tiếp tục triển khai Lean và chứng minh các giao thức đồng thuận trong Lean.

Ngôn ngữ lập trình hợp đồng thông minh: xem xác thực hình thức trong Vyper và Verity.

Trong tất cả các trường hợp này, một trong những giá trị gia tăng to lớn mà việc xác minh hình thức mang lại là các bằng chứng này thực sự là toàn diện từ đầu đến cuối. Thông thường, những lỗi khó chịu nhất là các lỗi tương tác ẩn náu ở giao diện của hai hệ thống con được xem xét độc lập.

Đối với con người, việc suy luận về toàn bộ hệ thống từ đầu đến cuối là quá khó. Nhưng các hệ thống kiểm tra quy tắc tự động có thể làm được điều đó.

Xác minh chính thức được sinh ra để đạt hiệu quả cao.

Hãy cùng xem xét lại evm-asm. Đây là một bản triển khai EVM. Nhưng đây là bản triển khai EVM được viết trực tiếp bằng ngôn ngữ assembly RISC-V.

Thành thật.

Đây là mã lệnh ADD:

import EvmAsm.Rv64.Program

không gian tên EvmAsm.Evm64

mở EvmAsm.Rv64

/-- EVM 256-bit ADD: nhị phân, lấy ra 2, đẩy vào 1.

Chi 0: LD, LD, ADD, SLTU (mang theo), SD (5 lệnh).

Các nhánh 1-3: LD, LD, ADD, SLTU (mang 1), ADD (mang vào), SLTU (mang 2), OR (mang ra), SD (8 mỗi nhánh).

Sau đó ADDI sp, sp, 32.

Các thanh ghi: x12=sp, x7=acc, x6=toán hạng, x5=carry, x11=carry1. -/

def evm_add : Program :=

-- Chi 0 (5 lệnh)

LD .x7 .x12 0 ;; LD .x6 .x12 32 ;;

ADD .x7 .x7 .x6 ;; SLTU .x5 .x7 .x6 ;; SD .x12 .x7 32 ;;

-- Chi 1 (8 hướng dẫn)

LD .x7 .x12 8 ;; LD .x6 .x12 40 ;;

ADD .x7 .x7 .x6 ;; SLTU .x11 .x7 .x6 ;;

ADD .x7 .x7 .x5 ;; SLTU .x6 .x7 .x5 ;;

OR' .x5 .x11 .x6 ;; SD .x12 .x7 40 ;;

-- Chi nhánh 2 (8 hướng dẫn)

LD .x7 .x12 16 ;; LD .x6 .x12 48 ;;

ADD .x7 .x7 .x6 ;; SLTU .x11 .x7 .x6 ;;

ADD .x7 .x7 .x5 ;; SLTU .x6 .x7 .x5 ;;

OR' .x5 .x11 .x6 ;; SD .x12 .x7 48 ;;

-- Chi nhánh 3 (8 hướng dẫn)

LD .x7 .x12 24 ;; LD .x6 .x12 56 ;;

ADD .x7 .x7 .x6 ;; SLTU .x11 .x7 .x6 ;;

ADD .x7 .x7 .x5 ;; SLTU .x6 .x7 .x5 ;;

OR' .x5 .x11 .x6 ;; SD .x12 .x7 56 ;;

-- điều chỉnh sp

ADDI .x12 .x12 32

kết thúc EvmAsm.Evm64

Việc lựa chọn RISC-V là vì các trình chứng minh ZK-EVM đang được xây dựng thường hoạt động bằng cách chứng minh RISC-V và biên dịch các máy khách Ethereum sang RISC-V. Do đó, nếu bạn có một triển khai EVM được viết trực tiếp bằng RISC-V, đây sẽ là triển khai nhanh nhất mà bạn có thể có được.

RISC-V cũng có thể được mô phỏng rất hiệu quả trên các máy tính thông thường (và hiện có các loại máy tính xách tay RISC-V trên thị trường).

Tất nhiên, để thực sự đạt được tính toàn diện, bạn phải chính thức xác minh việc triển khai của RISC-V (hoặc phép toán của trình chứng minh), nhưng đừng lo lắng, công việc trong lĩnh vực này đã có sẵn.

Viết mã trực tiếp bằng ngôn ngữ assembly là điều chúng ta từng làm cách đây năm mươi năm. Kể từ đó, chúng ta đã từ bỏ phương pháp này và chuyển sang viết mã bằng các ngôn ngữ lập trình bậc cao.

Các ngôn ngữ lập trình bậc cao thường đánh đổi hiệu quả, nhưng bù lại, chúng cho phép lập trình nhanh hơn nhiều và quan trọng hơn, hiểu mã của người khác nhanh hơn nhiều, điều này rất cần thiết cho bảo mật.

Với sự kết hợp giữa xác minh chính thức và trí tuệ nhân tạo, chúng ta có cơ hội "quay trở lại tương lai".

Cụ thể hơn, chúng ta có thể sử dụng trí tuệ nhân tạo để viết mã hợp ngữ, sau đó viết một bằng chứng chính thức để xác minh rằng mã hợp ngữ đó có các thuộc tính mong muốn.

Tối thiểu, các thuộc tính mong muốn chỉ cần tương đương hoàn hảo với một bản triển khai đã được tối ưu hóa về khả năng đọc hiểu và được viết bằng một ngôn ngữ cấp cao thân thiện với người dùng.

Chúng ta không còn cần một đối tượng mã duy nhất để cân bằng giữa khả năng đọc hiểu và hiệu quả; thay vào đó, chúng ta có hai đối tượng độc lập: một (phần triển khai bằng ngôn ngữ assembly) được tối ưu hóa hoàn toàn về hiệu quả trong khi vẫn xem xét các yêu cầu của môi trường thực thi cụ thể; đối tượng còn lại (câu lệnh bảo mật hoặc phần triển khai bằng ngôn ngữ cấp cao) được tối ưu hóa hoàn toàn về khả năng đọc hiểu, và sau đó chúng ta chứng minh sự tương đương giữa hai đối tượng này thông qua chứng minh toán học.

Người dùng có thể (tự động) xác minh bằng chứng đó một lần, và từ đó trở đi, họ chỉ cần chạy phiên bản nhanh.

Phương pháp này vô cùng hiệu quả, và đó là lý do Yoichi Hirai gọi nó là "hình thức phát triển phần mềm tối ưu".

Xác minh chính thức không phải là giải pháp thần kỳ.

Trong lĩnh vực mật mã học và khoa học máy tính, có một truyền thống gần như lâu đời như chính lịch sử của các phương pháp hình thức: truyền thống phê phán các phương pháp hình thức (hay nói rộng hơn, sự phụ thuộc vào "bằng chứng").

Những bài viết này chứa đầy các trường hợp thực tiễn. Chúng ta hãy bắt đầu với các bằng chứng viết tay từ thời kỳ mật mã đơn giản ban đầu, trích dẫn những lời chỉ trích của Menezes và Koblitz từ năm 2004:

Năm 1979, Rabin đề xuất một hàm mật mã được "chứng minh" là an toàn theo một nghĩa nào đó, tức là nó có thuộc tính an toàn theo phương pháp giản lược.

Tuyên bố về tính bảo mật theo phương pháp giản lược cho thấy rằng bất kỳ ai có thể tìm ra thông điệp m từ bản mã y cũng phải có khả năng phân tích n thành thừa số nguyên tố. … Ngay sau khi Rabin đề xuất sơ đồ mã hóa của mình, Rivest đã chỉ ra rằng, trớ trêu thay, chính đặc điểm này, vốn mang lại tính bảo mật bổ sung, lại có thể dẫn đến sự sụp đổ hoàn toàn nếu đối mặt với kẻ tấn công được gọi là "bản mã được chọn".

Tức là, nếu kẻ tấn công bằng cách nào đó có thể lừa Alice giải mã được đoạn mã mà chúng đã chọn, thì kẻ tấn công có thể thực hiện các bước tương tự như Sam đã sử dụng trong đoạn trước để phân tích thừa số n.

Menezes và Koblitz sau đó đã cung cấp thêm các ví dụ. Điểm chung là các thiết kế nhằm mục đích làm cho các giao thức mã hóa trở nên "có thể chứng minh được" thường khiến chúng trở nên kém "tự nhiên" hơn, làm tăng khả năng thất bại theo những cách mà người thiết kế thậm chí chưa từng nghĩ đến.

Giờ, chúng ta hãy quay lại với các bằng chứng và mã có thể kiểm chứng bằng máy. Dưới đây là một bài báo năm 2011 đã phát hiện ra các lỗ hổng trong một trình biên dịch C được kiểm chứng chính thức: bài báo:

Vấn đề CompCert thứ hai mà chúng tôi tìm thấy thể hiện ở hai lỗi dẫn đến việc tạo ra mã sau: stwu r1, -44432(r1) trong đó một khung ngăn xếp PowerPC lớn đang được phân bổ.

Vấn đề là trường dịch chuyển 16 bit bị tràn. Ngữ nghĩa PPC của CompCert không quy định giới hạn về độ rộng của giá trị tức thời này; họ cho rằng trình biên dịch hợp ngữ sẽ bắt được các giá trị nằm ngoài phạm vi.

Ngoài ra còn có một bài báo năm 2022:

Trong CompCert-KVX, bản cập nhật e2618b31 đã sửa một lỗi: lệnh "nand" được in thành "and"; "nand" chỉ được sử dụng trong mẫu hiếm gặp ~ (a & b). Lỗi này được phát hiện bằng cách biên dịch các chương trình được tạo ngẫu nhiên.

Và hôm nay, năm 2026, đây là cách Nadim Kobeissi mô tả các lỗ hổng trong phần mềm đã được kiểm chứng chính thức trong Cryspen:

Vào tháng 11 năm 2025, Filippo Valsorda đã độc lập báo cáo rằng libcrux-ml-dsa v0.0.3 tạo ra các khóa công khai và chữ ký khác nhau trên các nền tảng khác nhau khi sử dụng cùng một dữ liệu đầu vào xác định.

Lỗi nằm ở hàm đóng gói nội bộ vxarqu64, hàm này thực hiện phép toán XAR được sử dụng trong phép hoán vị Keccak-f của SHA-3. Cơ chế dự phòng đã truyền các tham số không chính xác cho phép toán dịch chuyển, làm hỏng kết quả băm SHA-3 trên các nền tảng ARM64 không hỗ trợ phần cứng SHA-3.

Đây là lỗi loại I: chức năng nội bộ đã được đánh dấu, nhưng toàn bộ hệ thống phụ trợ NEON không hoàn thành quá trình chứng minh tính an toàn hoặc tính chính xác khi chạy.

Và:

Thư viện libcrux-psq triển khai giao thức khóa chia sẻ trước hậu lượng tử. Trong phương thức decrypt_out, đường dẫn giải mã AES-GCM 128 gọi phương thức .unwrap() trên kết quả giải mã thay vì truyền lỗi. Văn bản mã hóa bị lỗi có thể làm sập tiến trình.

Cả bốn vấn đề này đều thuộc một trong hai loại sau:

Có những trường hợp chỉ một phần mã được xác minh (vì việc xác minh phần còn lại quá khó), dẫn đến việc phát hiện ra rằng phần mã chưa được xác minh có nhiều lỗ hổng hơn so với dự đoán của tác giả (và theo những cách nguy hiểm hơn).

Các trường hợp tác giả quên không nêu rõ các thuộc tính quan trọng cần được chứng minh.

Bài viết của Nadim bao gồm phân loại các kiểu lỗi trong xác minh hình thức; ông cũng đưa ra các loại kiểu lỗi khác (ví dụ, một trường hợp chính khác là "bản đặc tả hình thức tự nó đã sai, hoặc bằng chứng chứa các tuyên bố sai được hệ thống xây dựng chấp nhận một cách âm thầm").

Cuối cùng, chúng ta có thể xem xét những thất bại của quá trình xác thực hình thức tại ranh giới giữa phần mềm và phần cứng. Một vấn đề phổ biến ở đây là xác minh khả năng chống lại các cuộc tấn công kênh phụ.

Ngay cả khi bạn có các phương thức mã hóa hoàn toàn an toàn để bảo vệ tin nhắn của mình, nếu ai đó cách đó vài mét có thể nắm bắt được sự dao động trong tín hiệu điện và trích xuất khóa riêng tư của bạn sau hàng trăm nghìn lần mã hóa, thì bạn vẫn không an toàn.

Đây là một bài viết về "phân tích công suất khác biệt", một ví dụ dễ hiểu về các kỹ thuật như vậy: bài viết.

Phân tích công suất chênh lệch là một loại tấn công kênh phụ phổ biến. Nguồn: Wikipedia

Từ trước đến nay, luôn có những nỗ lực để chứng minh tính bảo mật trước những kẻ tấn công như vậy. Tuy nhiên, bất kỳ bằng chứng nào như vậy đều đòi hỏi một mô hình toán học nào đó về kẻ tấn công, cho phép bạn chứng minh tính bảo mật chống lại nó.

Đôi khi người ta sử dụng "mô hình dò tìm d": chúng ta giả định rằng số lượng vị trí mà kẻ tấn công có thể truy vấn trong mạch có một giới hạn đã biết. Tuy nhiên, một số dạng rò rỉ không được mô hình này nắm bắt.

Như đã đề cập trong bài viết này, một vấn đề phổ biến là rò rỉ tạm thời: nếu bạn có thể quan sát một tín hiệu phụ thuộc không chỉ vào giá trị tại một vị trí nhất định mà còn vào cách giá trị đó thay đổi, thì điều này thường đủ để khôi phục thông tin bạn cần từ hai giá trị (giá trị cũ và giá trị mới) thay vì chỉ một giá trị.

Bài viết này cung cấp phân loại các dạng rò rỉ khác.

Trong nhiều thập kỷ, những lời chỉ trích đối với việc xác minh chính thức đã giúp cải thiện quá trình xác minh chính thức. So với trước đây, chúng ta hiện nay đã tốt hơn trong việc phòng ngừa những vấn đề như vậy. Nhưng ngay cả ngày nay, nó vẫn chưa hoàn hảo.

Nhìn vào bức tranh tổng thể, có một điểm chung xuyên suốt. Xác minh chính thức là một công cụ mạnh mẽ.

Nhưng cho dù các thuật ngữ tiếp thị có khiến việc xác minh chính thức nghe có vẻ như mang lại "tính đúng đắn có thể chứng minh được", thì cái gọi là "tính đúng đắn có thể chứng minh được" về cơ bản không chứng minh rằng phần mềm (hoặc phần cứng) là "chính xác".

Theo cách hiểu của hầu hết mọi người, "đúng" có nghĩa là: "hành vi của sự vật phù hợp với sự hiểu biết của người dùng về ý định của nhà phát triển."

Và "an toàn" có nghĩa là: "hành vi của mọi thứ không vi phạm kỳ vọng của người dùng và không gây hại đến lợi ích của người dùng."

Trong cả hai trường hợp, tính chính xác và tính bảo mật đều quy về sự so sánh giữa các đối tượng toán học và ý định hoặc kỳ vọng của con người.

Ý định và kỳ vọng của con người tự bản thân chúng đã là những đối tượng phức tạp về mặt toán học; xét cho cùng, bộ não con người là một phần của vũ trụ, tuân theo các định luật vật lý có thể được mô phỏng nếu bạn có đủ sức mạnh tính toán.

Nhưng chúng là những đối tượng toán học vô cùng phức tạp mà cả máy tính lẫn chúng ta đều không thể hiểu hay thậm chí đọc được.

Về cơ bản, chúng giống như những chiếc hộp đen; chúng ta chỉ hiểu được ý định và kỳ vọng của mình bởi vì mỗi người đều có nhiều năm kinh nghiệm quan sát suy nghĩ của bản thân và suy luận suy nghĩ của người khác.

Và bởi vì chúng ta không thể nhồi nhét những ý định thô sơ của con người vào máy tính, nên việc xác minh chính thức không thể chứng minh sự so sánh với ý định của con người.

Do đó, "tính đúng đắn có thể chứng minh được" và "tính an toàn có thể chứng minh được" thực chất không chứng minh được "tính đúng đắn" và "tính an toàn" mà con người chúng ta hiểu. Không gì có thể làm được điều đó trừ khi chúng ta có thể mô phỏng hoàn toàn bộ não con người.

Vậy nó có ích lợi gì?

Tôi có xu hướng xem các bộ kiểm thử, hệ thống kiểu và xác minh hình thức như những cách triển khai khác nhau của cùng một phương pháp cơ bản để đảm bảo an toàn cho ngôn ngữ lập trình (và đây cũng có thể là phương pháp duy nhất hợp lý).

Về cơ bản, chúng đều xoay quanh việc lặp lại việc xác định ý định của chúng ta theo nhiều cách khác nhau, rồi tự động kiểm tra xem các xác định khác nhau này có tương thích với nhau hay không.

Hãy xem đoạn mã Python này làm ví dụ:

def fib(n: int) -> int:

nếu n < 0:

raise Exception("Giá trị âm không được hỗ trợ")

elif 0 <= n < 2:

trả về n

khác:

trả về fib(n-1) + fib(n-2)

nếu __name__ == '__main__':

assert [fib(i) for i in range(10)] == [0, 1, 1, 2, 3, 5, 8, 13, 21, 34]

khẳng định fib(15) == 610

Ở đây, bạn thể hiện ý định của mình theo ba cách khác nhau:

Cụ thể hơn, bằng cách triển khai công thức Fibonacci trong mã lập trình.

Một cách ngầm định, thông qua hệ thống kiểu dữ liệu (quy định rằng đầu vào, đầu ra và các bước trung gian trong đệ quy đều là số nguyên)

Thông qua phương pháp "gói mẫu": các trường hợp thử nghiệm

Chạy tập tin sẽ kiểm tra công thức so với các mẫu. Trình kiểm tra kiểu dữ liệu có thể xác minh xem các kiểu dữ liệu có tương thích hay không: cộng hai số nguyên là một phép toán hợp lệ và sẽ tạo ra một số nguyên khác.

Hệ thống kiểu dữ liệu thường là một cách tốt để kiểm tra kết quả trong vật lý: nếu bạn tính gia tốc nhưng lại nhận được kết quả tính bằng mét/giây thay vì mét/giây², bạn biết mình đã mắc lỗi.

Và các trường hợp thử nghiệm là một ví dụ về định nghĩa "gói mẫu", thường là cách tiếp cận tự nhiên hơn đối với con người khi xử lý các khái niệm so với các định nghĩa trực tiếp, rõ ràng.

Càng có nhiều cách diễn đạt khác nhau về ý định của bạn, lý tưởng nhất là theo những cách đòi hỏi bạn phải suy nghĩ khác đi về vấn đề, thì bạn càng có nhiều khả năng thực sự bày tỏ được điều mình muốn một khi tất cả những cách diễn đạt đó được chứng minh là tương thích với nhau.

Lập trình an toàn là việc thể hiện ý định của bạn theo nhiều cách khác nhau và sau đó tự động xác minh xem tất cả các cách thể hiện này có tương thích với nhau hay không.

Xác minh hình thức cho phép bạn mở rộng phương pháp này hơn nữa. Thông qua xác minh hình thức, bạn có thể chỉ định ý định của mình theo vô số cách khác nhau và dư thừa, và chương trình chỉ có thể được xác thực nếu tất cả chúng đều tương thích.

Bạn có thể chỉ định một phiên bản được tối ưu hóa cao và một phiên bản kém hiệu quả nhưng dễ đọc đối với con người, rồi kiểm tra xem chúng có khớp nhau hay không. Bạn có thể yêu cầu mười người bạn của mình cung cấp một danh sách các thuộc tính toán học mà họ cho rằng chương trình của bạn nên có, rồi kiểm tra xem chương trình có đáp ứng tất cả các thuộc tính đó hay không.

Nếu không đạt yêu cầu, hãy tìm hiểu xem chương trình có lỗi hay các thuộc tính toán học được chỉ định không chính xác. Và bạn có thể sử dụng trí tuệ nhân tạo để thực hiện tất cả các thao tác này một cách cực kỳ hiệu quả.

Vậy tôi nên bắt đầu như thế nào?

Trên thực tế, bạn sẽ không tự mình viết các chứng minh đâu. Lý do các phương pháp hình thức chưa bao giờ phổ biến là vì hầu hết mọi người không thể hiểu cách viết những thứ khó hiểu này. Bạn có thể cho tôi biết đoạn mã sau có nghĩa là gì không?

/-- Trợ giúp: phép toán ≤ từng điểm ở cấp độ foldl với một bộ tích lũy. -/

định lý riêng tư foldl_acc_le (ds1 ds2 : Danh sách Nat) (w : Nat) (ab : Nat) (hAcc : a ≤ b)

(hLE : Forall₂ (· ≤ ·) ds1 ds2) :

List.foldl (λ acc d => acc * w + d) a ds1 ≤

List.foldl (λ acc d => acc * w + d) b ds2 := by

khớp ds1, ds2, hLE với

| [], [], .nil => hAcc chính xác

| d1::ds1', d2::ds2', .cons hd htl =>

simp [List.foldl]

refine foldl_acc_le ds1' ds2' w (a * w + d1) (b * w + d2) ?_ htl

chính xác Nat.add_le_add (Nat.mul_le_mul hAcc (Nat.le_refl _)) hd

(Nếu bạn thắc mắc, đây là một trong nhiều định lý phụ trong bằng chứng về một tuyên bố bảo mật cụ thể cho một biến thể của chữ ký SPHINCS.)

Cụ thể, tuyên bố đó là: trừ khi xảy ra xung đột băm (hash collision), chữ ký của một thông điệp được tạo ra từ một bản tóm tắt băm (dig1) sẽ yêu cầu một giá trị cao hơn ít nhất ở một vị trí nào đó trên thang băm so với chữ ký của bất kỳ thông điệp nào khác, do đó chứa thông tin không thể tính toán được từ chữ ký khác đó.

Bạn không cần phải tự tay viết mã và chứng minh; bạn chỉ cần để AI viết chương trình cho bạn (trực tiếp bằng Lean hoặc để tăng tốc bằng ngôn ngữ assembly) và chứng minh bất kỳ thuộc tính nào mong muốn trong quá trình đó.

Ưu điểm của nhiệm vụ này là nó tự xác thực, vì vậy bạn không cần giám sát; bạn chỉ cần để AI chạy liên tục trong vài giờ.

Kết quả tệ nhất là nó cứ mãi dậm chân tại chỗ mà không có tiến triển gì (hoặc, như trường hợp của con leanstral của tôi trước đây, nó thay thế câu nói mà nó được yêu cầu chứng minh để giảm bớt khối lượng công việc).

Cuối cùng, điều duy nhất bạn cần kiểm tra là liệu những thông tin được chứng minh có đáp ứng yêu cầu của bạn hay không.

Đối với biến thể chữ ký SPHINCS, đây là tuyên bố cuối cùng:

định lý wots_fullDigits_incomparable

{dig1 dig2 : Danh sách Nat} {w l1 l2 : Nat}

(hw : 0 < w)

(hLen1 : dig1.length = l1) (hLen2 : dig2.length = l1)

(hBound1 : ∀ d ∈ dig1, d < w) (hBound2 : ∀ d ∈ dig2, d < w)

(hL2suff : l1 * (w - 1) < w ^ l2)

(hNeq : dig1 ≠ dig2) :

¬ Forall₂ (· ≤ ·) (wotsFullDigits dig1 w l1 l2) (wotsFullDigits dig2 w l1 l2) ∧

¬ Forall₂ (· ≤ ·) (wotsFullDigits dig2 w l1 l2) (wotsFullDigits dig1 w l1 l2)

Thực tế thì đoạn văn này gần như không thể đọc được:

Nếu các số được tạo ra từ một bản tóm tắt băm (dig1) không bằng với các số được tạo ra từ một bản tóm tắt băm khác (dig2)

Khi đó, cả hai điều kiện sau đều không đúng:

Với mọi số, các số từ dig1 <= các số từ dig2.

Với mọi số, các số từ dig2 <= các số từ dig1.

Trong "các số mở rộng" (wotsFullDigits) được tạo ra bằng cách cộng các tổng kiểm tra. Tức là, trong phần mở rộng của dig1, chắc chắn sẽ có những chỗ các số lớn hơn, trong khi ở những chỗ khác, các số trong phần mở rộng của dig2 sẽ lớn hơn.

Về việc sử dụng các mô hình ngôn ngữ lớn để viết chứng minh, tôi thấy cả Claude và Deepseek 4 Pro đều có khả năng. Leanstral là một mô hình trọng lượng mã nguồn mở nhỏ hơn, được tinh chỉnh đặc biệt để viết Lean, và nó là một lựa chọn thay thế đầy hứa hẹn.

Nó có 119 tỷ tham số, kích hoạt 6 tỷ tham số cho mỗi token, và bạn có thể chạy nó cục bộ, mặc dù tốc độ chậm hơn (khoảng 15 token/giây trên máy tính xách tay của tôi). Theo các bài kiểm tra hiệu năng, Leanstral vượt trội hơn nhiều so với các mô hình tổng quát lớn hơn:

Dựa trên kinh nghiệm cá nhân hiện tại của tôi, nó hiệu quả hơn một chút so với Deepseek 4 Pro nhưng vẫn rất hiệu quả.

Việc xác minh chính thức không thể giải quyết tất cả các vấn đề của chúng ta.

Tuy nhiên, nếu chúng ta muốn mô hình an ninh mạng không còn dựa trên việc tin tưởng một vài tổ chức quyền lực, chúng ta phải chuyển sang tin tưởng vào mã nguồn, bao gồm cả việc tin tưởng vào mã nguồn ngay cả khi đối mặt với những đối thủ AI hùng mạnh.

Xác minh chính thức có sự hỗ trợ của trí tuệ nhân tạo đã đưa chúng ta tiến một bước vững chắc hướng tới mục tiêu này.

Giống như blockchain và ZK-SNARKs, trí tuệ nhân tạo và xác minh chính thức cũng là những công nghệ bổ sung cho nhau rất tốt.

Công nghệ Blockchain mang lại cho bạn khả năng xác minh công khai và khả năng chống kiểm duyệt với cái giá là sự riêng tư và khả năng mở rộng, trong khi ZK-SNARKs trả lại cho bạn sự riêng tư và khả năng mở rộng (thậm chí còn tốt hơn trước đây).

Trí tuệ nhân tạo cho phép bạn viết một lượng lớn mã lập trình nhưng phải đánh đổi bằng độ chính xác, trong khi xác thực hình thức mang lại độ chính xác cao hơn (thậm chí còn cao hơn trước đây).

Theo mặc định, AI sẽ tạo ra một lượng lớn mã được viết rất vội vàng, và số lượng lỗi sẽ tăng lên.

Trên thực tế, trong một số trường hợp, chấp nhận việc gia tăng lỗi là sự đánh đổi hợp lý: nếu các lỗi đó nhỏ, thì phần mềm có lỗi vẫn tốt hơn là không có phần mềm nào cả.

Nhưng ở đây, an ninh mạng có một tương lai đầy lạc quan: phần mềm sẽ (tiếp tục) được chia thành các "phần biên không an toàn" xung quanh một "lõi an toàn".

Các thành phần không an toàn sẽ chạy trong môi trường biệt lập, chỉ được cấp các quyền tối thiểu cần thiết để hoàn thành nhiệm vụ của chúng.

Lõi bảo mật sẽ quản lý mọi thứ. Nếu lõi bảo mật gặp sự cố, mọi thứ sẽ sụp đổ, bao gồm dữ liệu cá nhân, tiền bạc của bạn, v.v. Nhưng nếu một phần không an toàn ở biên mạng gặp sự cố, lõi bảo mật vẫn có thể bảo vệ bạn.

Đối với lõi bảo mật, chúng ta không thể cho phép mã lỗi lan tràn. Chúng ta sẽ thực hiện các biện pháp quyết liệt để giữ cho lõi bảo mật nhỏ gọn, thậm chí thu nhỏ nó hơn nữa.

Thay vào đó, chúng tôi sẽ đầu tư toàn bộ hiệu năng bổ sung mà AI mang lại vào việc tăng cường bảo mật cho lõi hệ thống, giúp nó đáp ứng được gánh nặng tin cậy cực kỳ cao mà chúng ta đặt lên nó trong một xã hội số hóa cao.

Nhân hệ điều hành (hoặc ít nhất là một phần của nó) sẽ trở thành lõi bảo mật như vậy.

Ethereum sẽ là một ví dụ khác.

Hy vọng rằng, ít nhất đối với tất cả các phép tính không đòi hỏi hiệu năng cao, phần cứng bạn sử dụng sẽ trở thành một phần của yếu tố thứ ba.

Các hệ thống liên quan đến Internet vạn vật sẽ là hệ thống thứ tư.

Ít nhất trong số các lõi bảo mật này, câu ngạn ngữ cũ "lỗi là điều không thể tránh khỏi; bạn chỉ có thể cố gắng tìm ra chúng trước khi kẻ tấn công tìm thấy" sẽ bị bác bỏ, thay thế bằng một thế giới lạc quan hơn, nơi bạn sẽ đạt được sự bảo mật thực sự.

Nhưng nếu bạn sẵn lòng giao phó tài sản và dữ liệu của mình cho một phần mềm được viết kém chất lượng và có thể vô tình nuốt chửng chúng vào một hố đen, thì bạn hoàn toàn có quyền tự do đó.