Giải mã Cốc Thánh: Thách thức và giải pháp cho mã hóa đồng cấu toàn phần trên chuỗi
Tuyển chọn TechFlowTuyển chọn TechFlow
Giải mã Cốc Thánh: Thách thức và giải pháp cho mã hóa đồng cấu toàn phần trên chuỗi
Mã hóa đồng dạng toàn phần (FHE) được mệnh danh là "chiếc cốc thánh của mật mã học", nhưng hiện tại việc ứng dụng nó bị hạn chế bởi hiệu suất, trải nghiệm phát triển và các vấn đề về bảo mật.
Chuyên sâu báo cáo Web3Tác giả: Jeffrey Hu, Arnav Pagidyala
Quan điểm cốt lõi
· Toàn bộ mật mã hóa đồng hình (FHE) được mệnh danh là “chiếc chén thánh của mật mã học”, nhưng hiện tại ứng dụng của nó bị giới hạn bởi hiệu suất, trải nghiệm phát triển và các vấn đề về bảo mật.
· Như hình trên, để xây dựng một hệ thống trạng thái chia sẻ thực sự bảo mật và an toàn, cần kết hợp FHE với bằng chứng không kiến thức (ZKPs) và tính toán đa phương (MPC).
· FHE đang phát triển nhanh chóng; việc phát triển các trình biên dịch mới, thư viện, phần cứng và R&D từ các công ty Web2 (như Intel, Google, DARPA...) đã thúc đẩy mạnh mẽ sự tiến bộ của FHE.
· Khi FHE và hệ sinh thái xung quanh ngày càng trưởng thành, chúng ta kỳ vọng “FHE có thể xác minh” sẽ trở thành tiêu chuẩn. Các ứng dụng phi tập trung (DApps)/rollup có thể lựa chọn thuê ngoài tính toán và xác minh cho các bộ xử lý phụ FHE.
· Một giới hạn cơ bản của FHE trên chuỗi là “ai nắm giữ khóa giải mã”. Giải mã ngưỡng (Threshold decryption) và MPC cung cấp giải pháp cho giới hạn này, nhưng thường phải đánh đổi giữa hiệu suất và độ an toàn.
Mở đầu
Tính minh bạch của blockchain là con dao hai lưỡi. Mặc dù tính mở và khả năng quan sát rất hấp dẫn, đây cũng chính là điều khiến doanh nghiệp e ngại khi áp dụng công nghệ blockchain.
Bảo mật trên chuỗi luôn là một trong những thách thức lớn nhất trong lĩnh vực tiền mã hóa suốt gần một thập kỷ qua. Dù nhiều nhóm đang xây dựng các hệ thống dựa trên bằng chứng không kiến thức (ZKP) để đạt được tính riêng tư trên chuỗi, nhưng họ không thể hỗ trợ trạng thái mã hóa chia sẻ. Lý do là các giải pháp này là các hàm ZKP tuần tự, nên không thể áp dụng logic tùy ý lên trạng thái hiện tại. Điều đó có nghĩa là chúng ta không thể chỉ dùng ZKP để xây dựng các ứng dụng trạng thái chia sẻ mã hóa (ví dụ như Uniswap riêng tư).
Tuy nhiên, các đột phá công nghệ gần đây cho thấy rằng kết hợp ZKP với Toàn bộ mật mã hóa đồng hình (FHE) có thể tạo ra tài chính phi tập trung (DeFi) hoàn toàn tổng quát và được mã hóa. Làm thế nào để đạt được điều này? FHE là một lĩnh vực mật mã học mới nổi, cho phép thực hiện mọi phép tính trên dữ liệu đã mã hóa. Như hình trên, ZKP có thể chứng minh tính toàn vẹn của đầu vào người dùng và phép tính, còn FHE xử lý chính quá trình tính toán.
Mặc dù FHE được gọi là “chiếc chén thánh của mật mã học”, bài viết này sẽ cố gắng đưa ra phân tích khách quan về lĩnh vực này cùng các thách thức và giải pháp tiềm năng. Báo cáo kỹ thuật này sẽ đề cập đến các chủ đề FHE trên chuỗi sau:
1. Các sơ đồ, thư viện và trình biên dịch FHE (FHE Schemes, Libraries and Compilers)
2. Giải mã ngưỡng an toàn (Secure Threshold Decryption)
3. ZKP cho đầu vào người dùng và bên tính toán (ZKPs for User Inputs + Computing Party)
4. Lớp khả dụng dữ liệu (DA) có thể lập trình và mở rộng (Programmable, Scalable DA Layer)
5. Phần cứng FHE (FHE Hardware)
Các sơ đồ, thư viện và trình biên dịch FHE
Thách thức: Các sơ đồ, thư viện và trình biên dịch FHE mới nổi
Nút cổ chai cơ bản của FHE trên chuỗi nằm ở sự chậm trễ của công cụ phát triển và hạ tầng. Khác với bằng chứng không kiến thức (ZKP) hay tính toán đa phương (MPC), FHE phát triển ngắn hơn kể từ năm 2009 nên mức độ trưởng thành thấp hơn.
Các giới hạn chính về trải nghiệm phát triển FHE bao gồm:
· Thiếu ngôn ngữ frontend dễ sử dụng, giúp nhà phát triển lập trình mà không cần hiểu sâu về mật mã học nền tảng.
· Thiếu trình biên dịch FHE đầy đủ chức năng, có thể xử lý mọi tác vụ phức tạp (như chọn tham số, tối ưu SIMD cho BGV/BFV và tối ưu song song).
· Các sơ đồ FHE hiện tại (đặc biệt TFHE) chậm khoảng 1000 lần so với tính toán thông thường.
Để thực sự hiểu được độ phức tạp khi tích hợp FHE, hãy xem xét quy trình mà nhà phát triển phải trải qua:
Bước đầu tiên khi tích hợp FHE vào ứng dụng là chọn một sơ đồ FHE. Bảng dưới giải thích các sơ đồ chính:
Như bảng trên, các mạch Boolean (như FHEW và TFHE) có tốc độ bootstrapping nhanh nhất, tránh được quá trình chọn tham số phức tạp và có thể dùng cho tính toán bất kỳ/tổng quát, nhưng tương đối chậm; trong khi BGV/BFV phù hợp với các ứng dụng DeFi nói chung vì hiệu quả hơn trong tính toán số học độ chính cao, nhưng nhà phát triển phải biết trước độ sâu mạch để thiết lập tất cả tham số. Mặt khác, CKKS hỗ trợ phép nhân đồng hình, cho phép sai số độ chính, phù hợp với các trường hợp không cần độ chính xác như học máy.
Là nhà phát triển, bạn cần lựa chọn cẩn thận sơ đồ FHE vì nó ảnh hưởng đến mọi quyết định thiết kế khác và hiệu suất trong tương lai. Ngoài ra, có vài tham số then chốt quan trọng để thiết lập đúng sơ đồ FHE, ví dụ như kích thước modulus và vai trò của bậc đa thức.
Tiếp theo, ta thảo luận về các thư viện. Bảng sau hiển thị chức năng và khả năng của các thư viện FHE phổ biến hiện nay:
Tuy nhiên, mối liên hệ giữa các thư viện này với các sơ đồ FHE và trình biên dịch cũng khác nhau, như hình dưới:
Sau khi chọn sơ đồ FHE, nhà phát triển cần thiết lập tham số. Việc chọn tham số đúng sẽ ảnh hưởng lớn đến hiệu suất của sơ đồ FHE. Điều khó khăn là việc này đòi hỏi hiểu biết về đại số trừu tượng, các thao tác đặc thù FHE (như tái tuyến tính hóa và chuyển đổi modulus) và mạch số học hoặc nhị phân. Cuối cùng, để chọn tham số hiệu quả, cần hiểu rõ khái niệm cách chúng ảnh hưởng đến sơ đồ FHE.
Lúc này, nhà phát triển có thể đặt câu hỏi:
Không gian văn bản rõ (plaintext) cần lớn bao nhiêu? Có thể chấp nhận kích thước văn bản mã hóa (ciphertext) bao nhiêu? Tôi có thể tính toán song song ở đâu? v.v…
Hơn nữa, mặc dù FHE hỗ trợ mọi tính toán, nhà phát triển cần thay đổi tư duy khi viết chương trình FHE. Ví dụ, không thể viết rẽ nhánh (if-else) dựa trên biến trong chương trình, vì chương trình không thể coi biến là dữ liệu bình thường để so sánh trực tiếp. Thay vào đó, nhà phát triển cần chuyển đổi mã từ rẽ nhánh sang dạng tính toán chứa mọi điều kiện. Tương tự, điều này cũng ngăn nhà phát triển viết vòng lặp trong mã nguồn.
Tóm lại, đối với nhà phát triển chưa quen thuộc với FHE, việc tích hợp FHE vào ứng dụng gần như là bất khả thi. Cần có công cụ và hạ tầng phát triển đáng kể để trừu tượng hóa độ phức tạp mà FHE mang lại.
Giải pháp:
1. Trình biên dịch FHE chuyên biệt cho Web3
Mặc dù đã có các trình biên dịch FHE do Google và Microsoft xây dựng, nhưng chúng:
· Không được thiết kế hướng tới hiệu suất, gây thêm chi phí "overhead" gấp 1000 lần so với việc viết mạch trực tiếp
· Được tối ưu cho CKKS (tức ML), ít hữu ích cho BFV/BGV cần cho DeFi
· Không được xây dựng cho Web3. Không hỗ trợ tương thích với các sơ đồ ZKP, blockchain có thể lập trình, v.v.
Cho đến khi xuất hiện trình biên dịch Sunscreen FHE. Đây là trình biên dịch gốc Web3, cung cấp hiệu suất hàng đầu cho các thao tác số học (ví dụ DeFi), mà không cần bộ gia tốc phần cứng. Như đã nói, việc chọn tham số có thể là phần khó nhất khi triển khai sơ đồ FHE. Sunscreen không chỉ tự động hóa việc chọn tham số, mà còn thực hiện mã hóa dữ liệu, chọn khóa, triển khai tái tuyến tính hóa và chuyển đổi modulus, thiết lập mạch và thực hiện thao tác SIMD.
Với sự tiến bộ liên tục của công nghệ, chúng ta kỳ vọng sẽ thấy không chỉ Sunscreen mà các đội ngũ khác cũng xây dựng trình biên dịch riêng, hỗ trợ thêm các ngôn ngữ cao cấp và tối ưu hóa sâu hơn.
2. Thư viện FHE mới
Trong khi các nhà nghiên cứu không ngừng khám phá các sơ đồ hiệu quả mới, thì các thư viện FHE cũng giúp nhiều nhà phát triển tích hợp FHE hơn.
Lấy ví dụ về hợp đồng thông minh FHE. Mặc dù việc chọn giữa các thư viện FHE khác nhau có thể khó khăn, nhưng khi nói đến FHE trên chuỗi, lựa chọn trở nên dễ dàng hơn vì trong Web3 chỉ có vài ngôn ngữ lập trình chủ đạo.
Ví dụ, fhEVM của Zama tích hợp thư viện mã nguồn mở TFHE-rs của Zama vào EVM điển hình, công bố các thao tác đồng hình như hợp đồng tiền biên dịch. Nhờ vậy, nhà phát triển có thể sử dụng dữ liệu mã hóa trong hợp đồng mà không cần thay đổi công cụ biên dịch.
Đối với các trường hợp đặc thù khác, có thể cần hạ tầng bổ sung. Ví dụ, thư viện TFHE viết bằng C++ được duy trì kém hơn phiên bản Rust. Mặc dù TFHE-rs có thể xuất ra C/C++, nếu nhà phát triển C++ muốn tương thích và hiệu suất tốt hơn, họ phải tự viết phiên bản thư viện TFHE riêng.
Cuối cùng, một lý do cốt lõi khiến thị trường thiếu hạ tầng FHE là chúng ta chưa có cách hiệu quả để xây dựng FHE-RAM. Một hướng giải quyết khả dĩ là nghiên cứu FHE-EVM không có một số opcode nhất định.
Giải mã ngưỡng an toàn (Secure Threshold Decryption)
Thách thức: Giải mã ngưỡng không an toàn/tập trung
Mọi hệ thống trạng thái chia sẻ bảo mật đều dựa trên khóa mã hóa và giải mã. Vì không thể tin tưởng bất kỳ bên nào đơn lẻ, nên khóa giải mã được chia nhỏ (shard) giữa các người tham gia mạng qua tính toán đa phương (MPC).
Một trong những khía cạnh thách thức nhất của FHE trên chuỗi là xây dựng giao thức giải mã ngưỡng an toàn và hiệu suất cao. Có hai nút cổ chai chính:
(1) Tính toán dựa trên FHE gây ra "overhead" đáng kể, do đó cần các nút hiệu suất cao, điều này về bản chất làm giảm quy mô tiềm năng của tập hợp bộ xác thực;
(2) Khi số lượng nút tham gia giao thức giải mã tăng lên, độ trễ cũng tăng theo.
Ít nhất cho đến nay, các giao thức FHE phụ thuộc vào đa số trung thực (honesty majority) của bộ xác thực, nhưng như đã nói, FHE trên chuỗi đồng nghĩa với tập hợp bộ xác thực nhỏ hơn, do đó nguy cơ cấu kết và hành vi độc hại cao hơn.
Nếu các nút ngưỡng cấu kết thì sao? Chúng có thể bỏ qua giao thức, về cơ bản giải mã mọi thứ, bao gồm cả đầu vào người dùng và mọi dữ liệu trên chuỗi. Hơn nữa, đáng lo ngại hơn là trong các hệ thống hiện tại, giao thức giải mã có thể diễn ra âm thầm (tức “tấn công im lặng”).
Giải pháp: Cải tiến giải mã ngưỡng hoặc MPC động
Có một vài phương pháp khả dĩ để giải quyết các điểm yếu của giải mã ngưỡng.
(1) Kích hoạt ngưỡng n/2, điều này sẽ làm cho việc cấu kết khó khăn hơn;
(2) Chạy giao thức giải mã ngưỡng bên trong mô-đun bảo mật phần cứng (HSM);
(3) Sử dụng mạng giải mã ngưỡng dựa trên môi trường thực thi đáng tin cậy (TEE), được kiểm soát bởi chuỗi phi tập trung, cho phép quản lý khóa linh hoạt.
Thay vì tận dụng giải mã ngưỡng, khả năng cao hơn là sử dụng MPC. Một ví dụ đột phá về giao thức MPC có thể dùng trong FHE trên chuỗi: Odsy với 2PC-MPC mới, đây là thuật toán MPC phi cấu kết và phi tập trung quy mô lớn đầu tiên.
Một cách tiếp cận khác có thể là chỉ dùng khóa công khai của người dùng để mã hóa dữ liệu. Sau đó, các bộ xác thực xử lý các thao tác đồng hình, và khi cần, người dùng tự giải mã kết quả. Mặc dù cách này chỉ phù hợp với một số trường hợp sử dụng cụ thể, nhưng ta hoàn toàn có thể tránh được giả định ngưỡng.
Tóm lại, FHE trên chuỗi cần một triển khai MPC hiệu quả, với các đặc điểm sau:
(1) Hoạt động ngay cả khi có kẻ tấn công ác ý;
(2) Gây ra độ trễ tối thiểu;
(3) Cho phép các nút tham gia linh hoạt/không cần giấy phép.
ZKP cho đầu vào người dùng và bên tính toán
Thách thức: Khả năng xác minh đầu vào người dùng và tính toán:
Trong thế giới Web2, khi yêu cầu thực hiện một tác vụ tính toán, chúng ta hoàn toàn tin tưởng một công ty sẽ vận hành tác vụ đó phía sau hậu trường như cam kết. Trong Web3, mô hình này hoàn toàn đảo ngược. Chúng ta không còn dựa vào uy tín công ty và đơn giản tin rằng họ sẽ hành xử trung thực, mà hoạt động trong môi trường không cần tin tưởng, nghĩa là người dùng không nên cần tin tưởng bất kỳ ai.
Mặc dù toàn bộ mật mã hóa đồng hình (FHE) cho phép xử lý dữ liệu mã hóa, nhưng nó không thể xác minh tính đúng đắn của đầu vào người dùng hay phép tính. Nếu không có khả năng xác minh, FHE hầu như vô dụng trong bối cảnh blockchain.
Giải pháp: ZKP cho đầu vào người dùng và bên tính toán:
Mặc dù FHE cho phép bất kỳ ai thực hiện mọi phép tính trên dữ liệu mã hóa, nhưng ZKP cho phép mọi người chứng minh một điều là đúng mà không tiết lộ thông tin cơ bản. Vậy chúng liên quan như thế nào?
FHE và ZKP kết hợp với nhau theo ba cách then chốt:
1. Người dùng cần gửi một bằng chứng rằng văn bản mã hóa đầu vào của họ có định dạng đúng. Điều này có nghĩa là văn bản mã hóa đáp ứng yêu cầu của sơ đồ mã hóa, chứ không phải chỉ là chuỗi dữ liệu tùy ý.
2. Người dùng cần gửi một bằng chứng rằng văn bản rõ đầu vào của họ thỏa mãn điều kiện cho ứng dụng nhất định. Ví dụ, số dư tài khoản lớn hơn số tiền chuyển.
3. Các nút xác thực (tức bên tính toán) cần chứng minh họ đã thực hiện đúng phép tính FHE. Điều này được gọi là “FHE có thể xác minh”, có thể xem như tương tự ZKP mà rollup cần.
Để khám phá sâu hơn về ứng dụng ZKP:
1. ZKP cho văn bản mã hóa
FHE dựa trên mật mã học dựa trên lưới (lattice-based), nghĩa là các nguyên thủy mã hóa được xây dựng từ các lưới (lattice), vốn an toàn trước máy tính lượng tử. Trái lại, các ZKP phổ biến như SNARKs, STARKs và Bulletproofs không dựa trên mật mã học dựa trên lưới.
Để chứng minh định dạng văn bản mã hóa FHE của người dùng là đúng, chúng ta cần chứng minh nó thỏa mãn một phương trình ma trận-véc-tơ với các phần tử từ vành (rings), và các giá trị này là nhỏ. Về bản chất, chúng ta cần một hệ thống chứng minh được thiết kế để xử lý các quan hệ dựa trên lưới, có chi phí xác minh trên chuỗi hiệu quả — đây là một lĩnh vực nghiên cứu mở.
2. ZKP cho đầu vào văn bản rõ
Ngoài việc chứng minh văn bản mã hóa đúng định dạng, người dùng còn cần chứng minh văn bản rõ đầu vào của họ thỏa mãn yêu cầu ứng dụng. May mắn thay, khác với bước trước, chúng ta có thể tận dụng SNARKs phổ quát để chứng minh tính hợp lệ của đầu vào người dùng, giúp nhà phát triển tận dụng các sơ đồ, thư viện và hạ tầng ZKP hiện có.
Tuy nhiên, thách thức nằm ở chỗ chúng ta cần “kết nối” hai hệ thống chứng minh này. Kết nối nghĩa là chúng ta cần đảm bảo người dùng sử dụng cùng một đầu vào cho cả hai hệ thống chứng minh. Nếu không, người dùng độc hại có thể lừa gạt giao thức. Một lần nữa, đây là một kỳ công mật mã cực kỳ khó và là lĩnh vực nghiên cứu sơ khai mở.
Sunscreen đã đặt nền móng cho việc này, trình biên dịch ZKP của họ hỗ trợ Bulletproofs vì dễ kết nối nhất với SDLP. Nghiên cứu kết nối trình biên dịch FHE và ZKP cũng đang được đẩy mạnh.
Mind Network luôn đi đầu trong việc tích hợp ZKP nhằm đảm bảo đầu vào và đầu ra không cần tin tưởng, đồng thời tận dụng FHE cho tính toán an toàn.
3. ZKP cho tính toán đúng đắn
FHE chạy trên phần cứng hiện tại cực kỳ kém hiệu quả và tốn kém. Như đã thấy trước đây trong biểu hiện động của nghịch lý mở rộng, các mạng yêu cầu tài nguyên nút cao không thể mở rộng đến mức phi tập trung đủ. Một giải pháp khả dĩ là quá trình “FHE có thể xác minh”, nơi bên tính toán (bộ xác thực) gửi một ZKP để chứng minh việc thực thi giao dịch trung thực.
Một nguyên mẫu FHE có thể xác minh sớm có thể được minh họa qua dự án SherLOCKED. Về bản chất, phép tính FHE được tải vào zkVM Bonsai của Risc ZERO, zkVM xử lý tính toán trên dữ liệu mã hóa ngoài chuỗi, trả về kết quả kèm ZKP và cập nhật trạng thái trên chuỗi.
Lấy một ví dụ gần đây về việc sử dụng bộ xử lý phụ FHE: bản demo đấu giá trên chuỗi của Aztec. Như đã thảo luận trước đó, các chuỗi FHE hiện tại dùng khóa ngưỡng để mã hóa toàn bộ trạng thái, nghĩa là sức mạnh của hệ thống chỉ phụ thuộc vào ủy ban ngưỡng. Ngược lại, trong Aztec, người dùng sở hữu dữ liệu của riêng họ, do đó không bị ràng buộc bởi giả định an toàn ngưỡng.
Cuối cùng, điều quan trọng là hiểu nhà phát triển có thể xây dựng ứng dụng FHE ở đâu đầu tiên. Nhà phát triển có thể xây dựng ứng dụng trên L1 hỗ trợ FHE, rollup FHE hoặc trên bất kỳ chuỗi EVM nào và tận dụng bộ xử lý phụ FHE. Mỗi thiết kế đều có điểm đánh đổi riêng, nhưng chúng tôi nghiêng về các rollup FHE được thiết kế tốt (do Fhenix khởi xướng) hoặc bộ xử lý phụ FHE, vì chúng kế thừa an toàn từ Ethereum và các lợi ích khác.
Cho đến gần đây, việc thực hiện bằng chứng gian lận trên dữ liệu mã hóa FHE vẫn còn phức tạp, nhưng mới đây đội ngũ Fhenix.io đã chứng minh cách sử dụng ngăn xếp Arbitrum Nitro kết hợp logic FHE biên dịch sang WebAssembly để thực hiện bằng chứng gian lận.
Lớp khả dụng dữ liệu (DA) cho FHE
Thách thức: Thiếu tính tùy chỉnh và thông lượng
Mặc dù trong Web2 “lưu trữ” đã trở thành mặt hàng thông thường, nhưng trong Web3 thì không. Xét rằng toàn bộ mật mã hóa đồng hình (FHE) duy trì độ phình dữ liệu vượt quá 10.000 lần, chúng ta cần xác định lưu trữ khối lượng lớn văn bản mã hóa FHE ở đâu. Nếu mỗi nhà điều hành nút trong lớp DA nhất định phải tải xuống và lưu trữ mọi dữ liệu chuỗi FHE, thì chỉ các tổ chức mới theo kịp nhu cầu, từ đó gia tăng rủi ro tập trung.
Về thông lượng, tốc độ cao nhất của Celestia là 6,7 MB/s, nếu muốn chạy bất kỳ dạng FHEML nào, chúng ta sẽ cần băng thông vài GB mỗi giây. Theo dữ liệu gần đây do 1k(x) chia sẻ, các lớp DA hiện tại không thể hỗ trợ FHE do các quyết định thiết kế giới hạn thông lượng (một cách cố ý).
Giải pháp: Mở rộng ngang + Tùy chỉnh
Chúng ta cần một lớp DA có thể hỗ trợ mở rộng ngang. Kiến trúc DA hiện tại truyền mọi dữ liệu đến từng nút trong mạng, đây là giới hạn lớn về khả năng mở rộng. Ngược lại, khi nhiều nút DA gia nhập hệ thống, mở rộng ngang nghĩa là lượng dữ liệu mỗi nút lưu trữ giảm, nhờ đó hiệu suất và chi phí được cải thiện khi có thêm không gian khối.
Hơn nữa, xét đến kích thước lớn của dữ liệu liên quan đến FHE, việc cung cấp mức độ tùy chỉnh cao hơn cho ngưỡng mã xóa nhiễu (erasure coding thresholds) là hợp lý. Nói cách khác, nhà phát triển cảm thấy thoải mái đến đâu với các đảm bảo từ hệ thống DA? Là trọng số theo cổ phần hay trọng số theo mức độ phi tập trung.
Kiến trúc EigenDA có thể làm nền tảng cho khả năng của lớp DA hỗ trợ FHE. Các thuộc tính như mở rộng ngang, giảm chi phí cấu trúc, tách biệt DA và đồng thuận... đều mở đường cho mức độ mở rộng có thể hỗ trợ FHE.
Cuối cùng, một ý tưởng ở mức độ cao hơn có thể là xây dựng khe lưu trữ được tối ưu cho việc lưu trữ văn bản mã hóa FHE, vì văn bản mã hóa tuân theo sơ đồ mã hóa cụ thể, nên việc có khe lưu trữ tối ưu có thể giúp sử dụng bộ nhớ hiệu quả và truy xuất nhanh hơn.
Phần cứng FHE
Thách thức: Phần cứng FHE hiệu suất thấp
Một vấn đề chính trong việc phổ biến ứng dụng FHE trên chuỗi là độ trễ đáng kể do chi phí tính toán, khiến việc chạy FHE trên bất kỳ phần cứng xử lý tiêu chuẩn nào trở nên không thực tế. Giới hạn này bắt nguồn từ sự tương tác lớn với bộ nhớ, do bộ xử lý cần xử lý khối lượng dữ liệu khổng lồ. Ngoài tương tác bộ nhớ, các phép tính đa thức phức tạp và các thao tác duy trì văn bản mã hóa tốn thời gian cũng gây ra chi phí lớn.
Để hiểu sâu hơn về trạng thái bộ gia tốc FHE, chúng ta cần vén bức màn về thiết kế cụ thể bên trong: bộ gia tốc FHE chuyên dụng theo ứng dụng và bộ gia tốc FHE tổng quát.
Độ phức tạp tính toán của FHE và thiết kế phần cứng luôn gắn liền với số lượng phép nhân cần thiết cho ứng dụng nhất định, gọi là “độ sâu thao tác đồng hình”. Trong trường hợp ứng dụng cụ thể, độ sâu là biết trước, do đó tham số hệ thống và tính toán liên quan là cố định. Vì vậy, thiết kế phần cứng chuyên dụng sẽ dễ dàng hơn và thường có thể tối ưu để đạt hiệu suất tốt hơn so với thiết kế bộ gia tốc tổng quát. Trong trường hợp tổng quát, nếu FHE cần hỗ trợ số lượng phép nhân tùy ý, cần đưa vào kỹ thuật bootstrap để loại bỏ phần nhiễu tích tụ trong thao tác đồng hình. Kỹ thuật bootstrap tốn kém, cần nhiều tài nguyên phần cứng, bao gồm bộ nhớ chip, băng thông bộ nhớ và tính toán, nghĩa là thiết kế phần cứng sẽ rất khác so với thiết kế chuyên dụng. Do đó, mặc dù các bên đóng vai trò quan trọng như Intel, Duality, SRI, DARPA trong thiết kế GPU và ASIC không nghi ngờ gì đã nâng cao giới hạn, nhưng họ có thể không thể áp dụng trực tiếp cho các kịch bản blockchain.
Về chi phí phát triển, phần cứng tổng quát cần nhiều vốn hơn để thiết kế và sản xuất so với phần cứng chuyên dụng, nhưng tính linh hoạt cho phép phần cứng được dùng trong phạm vi ứng dụng rộng hơn. Mặt khác, với thiết kế chuyên dụng, nếu nhu cầu ứng dụng thay đổi và cần hỗ trợ tính toán đồng hình sâu hơn, cần kết hợp phần cứng chuyên dụng với một số kỹ thuật phần mềm (như MPC) để đạt được mục đích giống như phần cứng tổng quát.
Đáng chú ý, việc gia tốc FHE trên chuỗi khó hơn nhiều so với các trường hợp chuyên dụng (ví dụ FHEML), vì nó cần xử lý tính toán tổng quát hơn, chứ không phải tập hợp cụ thể hơn. Ví dụ, mạng phát triển fhEVM hiện tại bị giới hạn ở tốc độ xử lý giao dịch chỉ một chữ số TPS.
Xét rằng chúng ta cần bộ gia tốc FHE được tùy chỉnh cho blockchain, một yếu tố khác cần cân nhắc là: khả năng chuyển giao từ phần cứng ZKP sang phần cứng FHE đến đâu?
ZKP và FHE có một số mô-đun chung, ví dụ như biến đổi số học (NTT) và các thao tác đa thức cơ bản. Tuy nhiên, độ rộng bit (bit width) của NTT dùng trong hai trường hợp khác nhau. Trong ZKP, phần cứng cần hỗ trợ nhiều độ rộng bit cho NTT, ví dụ 64 bit và 256 bit, trong khi trong FHE, do sử dụng hệ thống số dư, toán hạng NTT ngắn hơn. Thứ hai, bậc NTT xử lý trong ZKP thường cao hơn FHE. Vì hai lý do này, việc thiết kế một mô-đun NTT đạt hiệu suất hài lòng cho cả ZKP và FHE không hề dễ dàng. Ngoài NTT, FHE còn có một số nút cổ chai tính toán khác như tự đẳng cấu (automorphism), không tồn tại trong ZKP. Một cách đơn giản để chuyển phần cứng ZKP sang thiết lập FHE là tải nhiệm vụ tính NTT lên phần cứng ZKP, và dùng CPU hoặc phần cứng khác xử lý các phép tính còn lại trong FHE.
Tóm lại các thách thức, việc dùng FHE để tính toán trên dữ liệu mã hóa từng chậm hơn 100.000 lần so với dữ liệu rõ. Tuy nhiên, nhờ các sơ đồ mã hóa mới hơn và tiến bộ gần đây về phần cứng FHE, hiệu suất hiện tại đã cải thiện đáng kể, chỉ còn chậm khoảng 100 lần so với dữ liệu rõ.
Giải pháp:
1. Cải tiến phần cứng FHE
Nhiều đội ngũ đang tích cực xây dựng bộ gia tốc FHE, nhưng họ chưa tập trung vào bộ gia tốc FHE dành riêng cho tính toán blockchain tổng quát (ví dụ TFHE). Một ví dụ về bộ gia tốc phần cứng chuyên biệt cho blockchain là FPT, một bộ gia tốc FPGA điểm cố định. FPT là bộ gia tốc phần cứng đầu tiên tận dụng triệt để nhiễu vốn có trong tính toán FHE, thực hiện bootstrap TFHE hoàn toàn bằng số học điểm cố định gần đúng. Một dự án khác có thể hữu ích cho FHE là BASALISC, một loạt kiến trúc bộ gia tốc phần cứng nhằm tăng tốc mạnh mẽ tính toán FHE trên đám mây.
Như đã đề cập trước đó, một nút cổ chai chính trong thiết kế phần cứng FHE là tương tác lớn với bộ nhớ. Để vượt qua trở ngại này, một giải pháp tiềm năng là giảm thiểu tương tác với bộ nhớ càng nhiều càng tốt. Bộ xử lý trong bộ nhớ (PIM) hoặc tính toán gần bộ nhớ (near memory computation) có thể hữu ích trong trường hợp này. PIM là giải pháp hứa hẹn để đối phó với thách thức “tường bộ nhớ (memory wall)” trong các hệ thống máy tính tương lai, cho phép bộ nhớ đồng thời đảm nhận chức năng tính toán và lưu trữ, hứa hẹn cải cách căn bản mối quan hệ tính toán - bộ nhớ. Trong thập kỷ qua, đã có tiến bộ lớn trong việc thiết kế bộ nhớ không bay hơi giải quyết vấn đề này, ví dụ RAM điện trở, RAM từ tính chuyển giao mô-men xoắn và bộ nhớ thay đổi pha. Sử dụng loại bộ nhớ đặc biệt này, các nghiên cứu đã cho thấy cải thiện đáng kể hiệu suất tính toán trong học máy và mã hóa khóa công khai dựa trên lưới.
2. Phần mềm và phần cứng được tối ưu
Trong các phát triển gần đây, phần mềm được công nhận là thành phần then chốt trong quá trình gia tốc phần cứng. Ví dụ các bộ gia tốc FHE nổi tiếng như F1 và CraterLake sử dụng trình biên dịch cho thiết kế đồng phần mềm-phần cứng (co-design).
Khi lĩnh vực này phát triển, chúng ta có thể kỳ vọng các trình biên dịch đầy đủ chức năng được thiết kế đồng bộ với trình biên dịch FHE dành riêng cho blockchain. Trình biên dịch FHE có thể tối ưu chương trình FHE theo mô hình chi phí của sơ đồ FHE tương ứng. Những trình biên dịch FHE này có thể tích hợp với trình biên dịch bộ gia tốc FHE, kết hợp mô hình chi phí ở cấp độ phần cứng để cải thiện hiệu suất đầu cuối.
3. Bộ gia tốc mạng FHE: Từ mở rộng dọc sang mở rộng ngang
Các nỗ lực gia tốc phần cứng FHE hiện tại chủ yếu tập trung vào “mở rộng dọc”, tức tập trung cải tiến dọc theo một bộ gia tốc đơn lẻ. Mặt khác, “mở rộng ngang” tập trung vào việc nối ngang nhiều bộ gia tốc FHE qua mạng, điều này có thể nâng cao hiệu suất đáng kể, tương tự như việc tạo bằng chứng song song trong bằng chứng không kiến thức (ZKPs).
Một khó khăn chính của việc gia tốc FHE là vấn đề phình dữ liệu: chỉ sự gia tăng đáng kể về kích thước dữ liệu xảy ra trong quá trình mã hóa và tính toán, gây thách thức cho việc truyền dữ liệu hiệu quả giữa bộ nhớ trong chip và ngoài chip.
Sự phình dữ liệu tạo ra thách thức lớn đối với việc nối ngang nhiều bộ gia tốc FHE qua mạng. Do đó, thiết kế đồng bộ phần cứng FHE và mạng sẽ là một hướng nghiên cứu đầy hứa hẹn trong tương lai. Ví dụ, định tuyến mạng thích ứng cho bộ gia tốc FHE: thực hiện cơ chế định tuyến điều chỉnh động đường đi dữ liệu giữa các bộ gia tốc FHE dựa trên tải tính toán và lưu lượng mạng theo thời gian thực. Điều này sẽ đảm bảo tốc độ truyền dữ liệu tối ưu và sử dụng tài nguyên hiệu quả.
Kết luận
FHE sẽ cơ bản tái cấu trúc cách chúng ta bảo vệ dữ liệu trên mọi nền tảng, mở đường cho một kỷ nguyên riêng tư chưa từng có. Xây dựng một hệ thống như vậy sẽ đòi hỏi tiến bộ lớn trong FHE, bằng chứng không kiến thức (ZKPs) và tính toán đa phương (MPC).
Khi bước vào lĩnh vực mới này, nỗ lực hợp tác giữa các nhà mật mã học, kỹ sư phần mềm và chuyên gia phần cứng sẽ là điều thiết yếu. Chưa kể đến các nhà làm luật, cơ quan quản lý, vì tuân thủ là con đường duy nhất để đạt được sự chấp nhận đại trà.
Tất cả đều dẫn đến một kết luận: FHE sẽ đứng đầu làn sóng biến đổi chủ quyền số, báo hiệu một tương lai nơi quyền riêng tư và an toàn dữ liệu không còn loại trừ lẫn nhau mà trở thành gắn bó mật thiết.
Ghi nhận đặc biệt
Cảm ơn sâu sắc Mason Song (Mind Network), Guy Itzhaki (Fhenix), Leo Fan (Cysic), Kurt Pan, Xiang Xie (PADO), Nitanshu Lokhande (BananaHQ) đã duyệt bài. Chúng tôi hy vọng độc giả sẽ tìm hiểu về những công việc và nỗ lực ấn tượng mà những người này đang thực hiện trong lĩnh vực này!
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
