Tôi không khuyến nghị bất kỳ ai vội vã chuyển tiền của họ sang ví mới hôm nay. Nhưng chúng ta nên nghiêm túc xem xét các rủi ro đối với mật mã học từ toán học được tăng tốc bởi AI, và giảm thiểu mức độ tiếp xúc của chúng ta không chỉ với mật mã dễ bị tấn công bởi máy tính lượng tử, mà còn cả mật mã có thể bị AI phá vỡ. Lĩnh vực rủi ro mới cốt lõi từ góc nhìn này, tiếc là, chính là ML-DSA / FHE / lưới (lattices). (và đây cũng là một lý do khác, cùng với máy tính lượng tử, khiến ECDSA có thể sụp đổ nhanh hơn dự kiến, do đó khuyến nghị “địa chỉ mới”) Cho đến nay, đa số mọi người vẫn nghĩ theo hướng: “đường cong elliptic bị phá vỡ, hàm băm an toàn, lưới an toàn”. Nhưng khả năng cao là độ an toàn thực tế của lưới sẽ chịu những tổn thất nghiêm trọng từ toán học do AI thúc đẩy trong hai năm tới. Mô hình đe dọa cơ bản là: phân tích thừa số là việc mà về mặt ngây thơ mất thời gian 2^(n/2), nhưng qua nhiều thập kỷ, những người thông minh đã tìm ra và tối ưu hóa các phương pháp sàng trường số, làm giảm thời gian này xuống còn 2^O(n^(1/3)), chính vì vậy các khóa và chữ ký RSA cần dài khoảng 400 byte (không phải 64 byte). Vậy nếu tồn tại những “xương trắng” trong tủ quần áo tương tự như vậy, đối với cả đường cong elliptic lẫn lưới — mà chúng ta đơn giản chưa đủ thông minh để phát hiện — nhưng các bot sắp tới sẽ làm được? Đây là một phần lớn lý do vì sao trong năm qua, lộ trình gọn nhẹ của ethereum đã hướng tới “chỉ dùng hàm băm”: không dùng lưới, không ML-DSA, không Falcon, không cam kết dựa trên lưới trong các chứng minh ZK, v.v. Chữ ký trong ethereum gọn nhẹ đều dựa trên hàm băm, hoặc WOTS hoặc SPHINCS-. Đối với chữ ký và chứng minh, chúng ta đã biết cách đi theo hướng chỉ dùng hàm băm. Thách thức lớn hơn nằm ở *mã hóa khóa công khai* — và điều này vượt xa cả blockchain. Giao tiếp an toàn, các giao thức ẩn danh, rất nhiều thứ đều cần mã hóa khóa công khai. Và tiếc là, đã có những định lý toán học lâu đời chứng minh rằng mã hóa khóa công khai không thể thực hiện chỉ bằng hàm băm. Bạn buộc phải có một đối tượng “bẫy” nào đó mang ít nhất một dạng “cấu trúc” có thể sử dụng — hoặc lý thuyết nhóm (bao gồm isogenies), hoặc lưới, hoặc dựa trên mã, hoặc thậm chí trong tương lai có thể là những thứ mới mẻ và kỳ lạ hơn nữa (local mixing?). Nhưng với bất kỳ thứ gì có cấu trúc, bạn nên giả định rằng AI sẽ tạo ra ít nhất một số tiến bộ trong việc phá vỡ cấu trúc đó. Ở đây, một suy luận hợp lý là: nếu bạn muốn tạo ra một thứ có khả năng an toàn lâu dài, hãy nhân kích thước khóa lên 10 lần. Với tôi, đây là một thế giới rất hợp lý và không hề quá cực đoan để dự đoán. Nếu AI sẽ mang đến cho chúng ta 50 năm tiến bộ toán học trong 2 năm, thì 50 năm toán học đó rất có thể bao gồm một bước tiến mang tính “từ phân tích ngây thơ → GNFS” đối với khả năng phá vỡ lưới. Trong thế giới đó, lưới vẫn tồn tại, nhưng chúng sẽ phải lớn hơn đáng kể để đảm bảo mức độ an toàn tương đương. Và ở kích thước lớn hơn mới này, các cấu trúc dựa trên hàm băm sẽ vượt trội hơn các cấu trúc dựa trên lưới về hiệu suất thực tế trong mọi trường hợp sử dụng mà cấu trúc dựa trên hàm băm vẫn khả thi. Về mặt lý thuyết, tất nhiên cũng có khả năng hàm băm bị phá vỡ (ví dụ: P = NP sẽ ngụ ý điều đó). Nhưng tôi cho rằng P = NP là rất khó xảy ra. Và trực quan hơn, có vẻ khả thi hơn nhiều rằng một đối tượng toán học hoàn toàn không có cấu trúc khai thác được (như hàm băm được thiết kế để làm), so với việc một đối tượng toán học chỉ có đúng khoảng 3 dạng cấu trúc khai thác được (đối với đường cong elliptic: tính kết hợp, Schoof, cặp đôi) mà không có dạng cấu trúc bí mật thứ tư nào chưa được phát hiện khiến độ an toàn của nó suy giảm nghiêm trọng (đối với đường cong elliptic: ECDLP và độ an toàn của cặp đôi). Tương tự với LWE, SVP, RLWE và hàng loạt các bài toán lưới khác. Vì lý do này, chúng ta hiện chưa thấy bất kỳ lý do nào để lo lắng và bắt đầu tăng kích thước byte của hàm băm (nếu chúng ta bắt đầu lo lắng hơn, chúng ta sẽ tăng số vòng trước khi làm bất cứ điều gì với kích thước byte). Tóm tắt ngắn gọn theo quan điểm cá nhân của tôi: * Hàm băm > lưới, trong những tình huống mà hàm băm vẫn khả thi * Với bất kỳ thứ gì dựa trên lưới, hãy cực kỳ cảnh giác với kích thước tham số. Hãy nhớ rằng blockchain chỉ là một phần nhỏ trong câu chuyện mật mã học; điểm này vượt xa blockchain và áp dụng cho ví dụ: truy cập website, nhắn tin an toàn, Tor/VPN... * Đối với các giao thức bảo mật, hãy ưu tiên mạnh mẽ KHÔNG lưu trữ ghi chú đã mã hóa trênchain. Thay vào đó, hãy gửi chúng offchain thông qua cơ chế bên thứ ba. * Nếu không khó với bạn, việc giữ tiền của bạn trong các địa chỉ chưa từng được dùng để thực hiện giao dịch là một ý tưởng tốt. Nếu dễ dàng với bạn, hãy làm điều đó. **Nhưng hãy cẩn thận với việc di chuyển; cá nhân tôi đã mất nhiều tiền hơn do di chuyển sai sót so với tổng số tiền mất do mọi vụ hack cộng lại**. * Đối với ví đa chữ ký, xác nhận offchain tốt hơn onchain, vì cách này các chữ ký của ví người ký không bị phơi bày công khai — do đó nếu ECDSA sụp đổ nhanh hơn dự kiến do AI, ít nhất ví đa chữ ký sẽ “giảm cấp nhẹ nhàng” thành 1-of-1, trong đó “1” là người thu thập chữ ký — một vị trí tốt hơn nhiều so với “bất kỳ ai cũng có thể lấy tiền”. https://t.co/oVjwZog2lL