Chào mọi người, tôi là Marco López (Đại học Málaga / Phòng thí nghiệm NICS + An ninh mạng phi tập trung).
Chúng tôi vừa được chấp nhận một bài báo về các chiến lược di chuyển cho các EOA của Ethereum trong bối cảnh mối đe dọa từ máy tính lượng tử có liên quan đến mật mã (CRQC) trong tương lai đối với secp256k1/ECDSA .
Chúng tôi cố ý giới hạn phạm vi bài viết ở lớp thực thi (ủy quyền EOA, luồng giao dịch/chữ ký, v.v.). Chúng tôi không đề cập đến việc chuyển đổi PQ ở lớp đồng thuận (chữ ký của trình xác thực, BLS/KZG, ETC).
Tóm tắt ngắn gọn: Chúng tôi đang dựa trên những nghiên cứu xuất sắc trước đây của ethresearch.
Trước khi đăng bài, chúng tôi đã đọc qua một số Threads tuyệt vời đang thảo luận về chữ ký giao dịch PQ và các đánh đổi kỹ thuật thực tiễn. Xin chân thành cảm ơn những người đã dẫn dắt các cuộc thảo luận này, đặc biệt là asanso và seresistvanandras:
asanso (Phần 1): “Vậy bạn muốn chữ ký giao dịch Ethereum hậu lượng tử?”
asanso (Phần 2): “Falcon như một chữ ký giao dịch Ethereum: Những điều tốt, điều xấu và điều kỳ quặc”
asanso (Phần 3): “Con đường dẫn đến giao dịch Ethereum hậu lượng tử được lát bằng Account Abstraction (AA)”
seresistvanandras: “poqeth: Xác minh chữ ký hiệu quả, hậu lượng tử trên Ethereum” (+ điểm chuẩn + chế độ phản biện)
Bài viết này nhằm mục đích cung cấp một khảo sát sơ bộ đơn giản về các lộ trình di chuyển, nhưng tập trung nhiều hơn vào các sự cố về khả năng tương thích và bề mặt tấn công xuất hiện trong quá trình chuyển đổi.
Lý do tôi đăng bài ở đây (lời kêu gọi cộng đồng)
Đây là bản thảo đầu tiên (và được thiết kế đơn giản một cách có chủ ý) . Chúng tôi đã cố gắng lập bản đồ các lộ trình di chuyển chính mà mọi người thảo luận để làm cho EOA trở nên kiên cường hơn trước mối đe dọa CRQC, và để làm nổi bật những điểm có thể gặp trục trặc trong thực tế.
Mục tiêu của bài đăng này là thu thập ý kiến đóng góp từ cộng đồng và tập trung nỗ lực vào khía cạnh thực thi của vấn đề này:
Liệu chúng ta có đang bỏ sót các phương án giảm thiểu rủi ro/lộ trình di dời phù hợp không?
Những sự cố vi phạm tính tương thích nào khác (on-chain và Ngoài chuỗi) cần được chú ý?
Chúng ta đang đánh giá thấp những hành vi đối kháng / rủi ro MEV / rủi ro vận hành nào?
Chúng ta nên trích dẫn hoặc học hỏi từ những bài báo/kho lưu trữ/ Threads nào trước đây?
Còn ai khác đang tích cực tham gia vào dự án này, và việc hợp tác có thể mang lại hiệu quả ở những lĩnh vực nào?
Nếu bạn đang làm việc với ví điện tử, AA, cơ sở hạ tầng, nghiên cứu giao thức, kiểm toán hoặc hệ sinh thái L2, quan điểm của bạn sẽ vô cùng quý giá.
Nội dung bài báo đề cập (khảo sát các tuyến đường + sự đánh đổi)
Chúng tôi đã lập bản đồ các phương pháp chính được thảo luận về việc chuyển đổi EOA sang bảo mật hậu lượng tử, và cố gắng làm rõ các sự đánh đổi, đặc biệt là ở những điểm mà phương pháp này giao thoa với cơ sở hạ tầng và mô hình hợp đồng hiện nay.
Chữ ký PQ gốc (giao thức/ đường dẫn Máy ảo Ethereum (EVM) ): thay thế ECDSA bằng lược đồ PQ.
Về mặt lý thuyết thì khá đơn giản, nhưng chi phí xác minh và kích thước chữ ký/khóa lại khác nhau tùy thuộc vào từng phương thức, ảnh hưởng đến kích thước giao dịch, gas/hiệu năng, và đôi khi cả việc xác định địa chỉ. Quá trình triển khai ở cấp độ giao thức cũng chậm hơn.
Ghi chú về chữ ký dựa trên hàm băm (góc nhìn tối giản) : Chúng tôi dành thời gian thảo luận về chữ ký dựa trên hàm băm , bởi vì Ethereum đã dựa rất nhiều vào các hàm Hash như một thành phần cốt lõi. Việc sử dụng chữ ký dựa trên hàm băm có thể trông "tối giản về mặt mật mã" (bạn không đưa ra một giả định về độ khó hoàn toàn mới như cách mà các phương pháp dựa trên lưới/đồng cấu/ ETC. sẽ làm). Ngoài ra, nhiều cấu trúc dựa trên hàm băm có thể có "khóa công khai" rất nhỏ on-chain (thường chỉ là một Hash /cam kết gốc), điều này phù hợp với chủ đề "Khóa công khai lớn là điều không nên trong bối cảnh Ethereum" được nhấn mạnh trong poqeth. Tất nhiên, sự đánh đổi nằm ở những khía cạnh khác (kích thước chữ ký, trạng thái, ma sát UX/mempool), và đó chính là nơi chúng tôi muốn nhận được nhiều ý kiến đóng góp hơn từ cộng đồng.
Một điểm nhỏ cần lưu ý: chữ ký dựa trên hàm băm có trạng thái (ví dụ: XMSS/LMS ) có thể gây khó khăn trong các hệ thống nói chung vì chúng yêu cầu quản lý trạng thái, nhưng blockchain có khả năng quản lý trạng thái đó on-chain (giống như chỉ mục/số ngẫu nhiên). Đã có tiền lệ trong các hệ sinh thái khác (ví dụ: QRL sử dụng XMSS ).
Account Abstraction Yêu cầu bình luận Ethereum (ERC) -4337: có thể sử dụng ngay hôm nay; quá trình xác minh diễn ra bên trong hợp đồng tài khoản, do đó ví có thể yêu cầu chữ ký PQ để ủy quyền các hoạt động và giảm thiểu rủi ro trực tiếp cho người dùng trước các cuộc tấn công lượng tử dựa trên ECDSA.
Vấn đề mấu chốt (cũng được thảo luận trong loạt bài viết về Asanso) là trình gom nhóm vẫn đăng tải một giao dịch được ký bởi ECDSA , do đó quy trình từ đầu đến cuối không hoàn toàn chống lại được tấn công PQ. Nó cũng đưa thêm các thành phần chuyển động (cơ sở hạ tầng giống như mempool, phí, độ phức tạp trong vận hành).
Các đề xuất AA gốc (theo hướng RIP-7560 / Đề xuất cải tiến Ethereum (EIP)-7701): một mục tiêu cuối cùng rõ ràng về tính linh hoạt mật mã: các tài khoản được định nghĩa bằng logic xác minh đính kèm (xác minh PQ, đa chữ ký, khóa mật khẩu, ETC), loại bỏ các giả định ECDSA cố định ở cấp độ mô hình tài khoản.
Cần thay đổi sâu rộng quy trình; thời gian thực hiện và thiết kế cuối cùng vẫn chưa chắc chắn.
Ủy quyền Đề xuất cải tiến Ethereum (EIP)-7702: một cơ chế thực tiễn để gắn logic xác thực mới vào EOA/địa chỉ hiện có mà không cần chuyển đổi sang mô hình tài khoản mới. Điều này cho phép thử nghiệm xác thực dựa trên PQ và chính sách tài khoản trong khi vẫn giữ nguyên địa chỉ và các mối quan hệ hiện có.
Hạn chế chính: chừng nào giao thức vẫn chấp nhận khóa ECDSA của EOA, thì nó vẫn là "cơ quan gốc" (trong thiết lập CRQC, quyền hạn còn lại đó đặc biệt gây ra vấn đề).
Đề xuất cải tiến Ethereum (EIP)-7702 + các biến thể vô hiệu hóa khóa: đã thảo luận các ý tưởng để khép kín vòng lặp đó: sau khi ủy quyền, khóa ECDSA gốc có thể bị vô hiệu hóa (lý tưởng là vĩnh viễn), do đó các tuyến điều khiển chỉ đi qua logic được ủy quyền trong khi vẫn bảo toàn địa chỉ và các tài sản/mối quan hệ liên quan.
Chúng tôi coi đây là một phần của không gian thiết kế rộng hơn nhằm loại bỏ "quyền hạn gốc của ECDSA" một khi cơ chế xác thực linh hoạt hơn được thiết lập.
Trên tất cả các lộ trình, chúng tôi cố gắng giữ một góc nhìn thực tế: ECDSA vẫn còn tồn tại ở đâu , những giả định về cơ sở hạ tầng mới nào xuất hiện và những gián đoạn nào xảy ra trong hệ sinh thái trong quá trình chuyển đổi.
Các điểm nóng về khả năng tương thích/hỏng hóc ("vùng bẩn")
Nơi chúng ta dự đoán sẽ gặp phải hầu hết các thách thức:
Xác thực dựa trên
ecrecovertrong các hợp đồng đã triển khai (chữ ký như là định danh).Nhiều cơ chế xác thực on-chain thực chất là "chữ ký như là định danh" thông qua
ecrecover. Trong quá trình chuyển đổi PQ, việc ngừng sử dụng ECDSA ở lớp giao dịch là chưa đủ. Chừng nàoecrecovervẫn là một preccomp hợp lệ cho ECDSA, các hợp đồng hiện có vẫn có thể coi chữ ký ECDSA Ngoài chuỗi là có thẩm quyền. Vì vậy, bất kỳ quá trình chuyển đổi nghiêm túc nào cũng cần có lý do cho cách xử lý xác thực kiểuecrecovercủa ECDSA (và liệu nó có bị hạn chế, thay thế hay bổ sung bởi các đường dẫn xác thực mới hay không), nếu không, các chữ ký Ngoài chuỗi cũ có thể vẫn nắm giữ quyền lực bên trong các hợp đồng ngay cả sau khi EOA ngừng sử dụng ECDSA cho các giao dịch.(Liên quan: Như đã nêu trong chủ đề AA/Falcon của asanso, nhiều lược đồ PQ không hỗ trợ “khôi phục khóa”, ví dụ như Falcon “thông thường” không hỗ trợ khôi phục khóa công khai từ chữ ký, vì vậy các mẫu kiểu
ecrecoverkhông được chuyển đổi. Ví dựa trên Falcon thường cần xác minh dựa trên Khóa công khai. Cũng có một mô hình “có thể khôi phục” được thảo luận trong tài liệu Falcon (Mục 3.12, như Renaud Dubois đã chỉ ra) cho phép khôi phục khóa, nhưng nó làm tăng gấp đôi kích thước chữ ký , điều này rõ ràng có ảnh hưởng đến on-chain/trên chuỗi.)permitYêu cầu bình luận Ethereum (ERC)-2612 + các luồng ký Ngoài chuỗi rộng hơn (dữ liệu được phân loại, xác thực dành riêng cho ứng dụng, các mẫu giao dịch meta)Các giả định về
tx.origin(EOA so với định danh hợp đồng, logic ủy quyền dễ bị lỗi)L2s + sự trôi dạt xuyên chuỗi (ngữ nghĩa nhận dạng, miền phát lại, giả định bắc cầu)
MEV trong các cửa sổ di chuyển (thứ tự/tranh chấp xung quanh việc ủy quyền, thu hồi, thời điểm "chữ ký hợp lệ cuối cùng")
Một phần quan trọng trong những gì chúng tôi muốn nhận được từ cộng đồng là: còn điều gì khác nên có trong danh sách này, và điều gì thực sự gây hại nhất trong thực tế?
Hard fork cấp Quantum như một phương án dự phòng (song song)
Ngoài các lộ trình "di chuyển suôn sẻ", ý tưởng về hard-fork khẩn cấp lượng tử là một phần quan trọng của câu chuyện về khả năng phục hồi.
Bài đăng của Vitalik vào tháng 3 năm 2024 ( “Cách thực hiện hard-fork để cứu phần lớn tiền của người dùng trong trường hợp khẩn cấp lượng tử” ) đã đưa ra một giải pháp cuối cùng đáng tin cậy nếu khả năng lượng tử thực tế xuất hiện đột ngột và nạn trộm cắp quy mô lớn bắt đầu xảy ra: hoàn tác về trạng thái trước khi bị trộm, vô hiệu hóa các giao dịch EOA cũ và cung cấp lộ trình phục hồi chuyển quyền kiểm soát sang quá trình xác thực hợp đồng thông minh an toàn lượng tử.
Chúng tôi đề cập đến điều này không phải như một kế hoạch thúc đẩy chủ động (vì nó tốn kém và gây gánh nặng về mặt xã hội/vận hành), mà như một lời nhắc nhở rằng việc lập kế hoạch ứng phó khẩn cấp rất quan trọng, và song song đó, hệ sinh thái có thể (và có lẽ nên) tìm ra những lộ trình cho phép sự linh hoạt dần dần hơn trong lĩnh vực tiền điện tử để chúng ta không bị buộc phải rơi vào tình trạng "phá vỡ rào cản" ngay lập tức.
Điều chúng tôi đang yêu cầu một cách rõ ràng
Nếu bạn trả lời, việc cung cấp các liên kết đến Threads/bài viết/kho lưu trữ/nhóm sẽ vô cùng hữu ích.
Liệu có những lộ trình di chuyển/biện pháp giảm thiểu rủi ro nào mà chúng ta đang bỏ sót (ở lớp thực thi), hoặc những biến thể quan trọng nào mà chúng ta nên tích hợp?
Theo bạn, những lỗi tương thích nào (on-chain và Ngoài chuỗi) là cấp bách nhất hoặc có khả năng gây hại thực sự cho người dùng nhất? Rất mong nhận được những ví dụ cụ thể.
Những hành vi đối kháng / rủi ro MEV / rủi ro vận hành nào cần được xem xét trong quá trình chuyển đổi (tấn công trước/đua tranh, phá hoại, vấn đề "chữ ký hợp lệ cuối cùng", xâm phạm cơ sở hạ tầng, động lực giao dịch bị kẹt đối với các lược đồ một lần/có trạng thái, ETC)?
Có những loại hợp đồng hoặc mô hình ví nào mà các giả định về
ecrecover,permithoặctx.originkhiến quá trình chuyển đổi trở nên đặc biệt khó khăn không?Bạn có biết các phép đo/bộ dữ liệu/công cụ nào giúp định lượng mức độ phổ biến của các mô hình này (ví dụ: quét
ecrecover, mức độ sử dụng giấy phép trong thực tế,…)?Hiện tại còn ai đang tích cực làm việc về CRQC / khả năng thích ứng mã hóa cho EOA không? Nếu bạn đang tham gia (hoặc biết ai đó đang tham gia), chúng tôi rất muốn kết nối với bạn.
Chúng tôi tiếp cận vấn đề này như một nỗ lực vì lợi ích cộng đồng (UMA/NICS Lab + An ninh phi tập trung). Chúng tôi rất sẵn lòng xem xét, góp ý và hợp tác khi thấy phù hợp.
Kết thúc / sự kiện
Chúng tôi sẽ trình bày bài báo tại một hội nghị ở Đại học La Laguna (Tenerife, Tây Ban Nha) vào giữa tháng 3. Chúng tôi cũng đang hướng tới việc trình bày công trình nghiên cứu tiếp theo tại Hội thảo về Công cụ Mật mã cho Chuỗi khối ( CTB-26 ), liên kết với Eurocrypt ở Rome vào ngày 9 tháng 5 năm 2026.
Nếu bạn đang làm việc trong lĩnh vực này, chúng tôi rất vui được gặp bạn tại một trong hai sự kiện.
Nhân tiện, hạn chót nộp bài cho CBT26 là cuối tháng Hai, nên bạn vẫn còn thời gian.
Cảm ơn bạn!! Rất mong nhận được phản hồi của bạn.
