)

Ý tưởng cốt lõi:

1. FHE hứa hẹn sẽ là “Chén thánh về mật mã”, tuy nhiên có nhiều lo ngại về hiệu suất, kinh nghiệm của nhà phát triển và bảo mật đã hạn chế việc áp dụng nó hiện tại.

2. Như được hiển thị trong hình trên, FHE sẽ cần được sử dụng cùng với ZKP và MPC để xây dựng một hệ thống trạng thái chia sẻ, thực sự bí mật và an toàn.

3.FHE đang phát triển nhanh chóng; Sự phát triển của các trình biên dịch, thư viện, phần cứng mới, v.v. Chưa kể, FHE được hưởng lợi rất nhiều từ hoạt động R&D của các công ty Web2 (Intel, Google, DARPA, v.v.).

4.Khi FHE và hệ sinh thái xung quanh nó trưởng thành, chúng tôi hy vọng sẽ thấy “FHE có thể kiểm chứng” trở thành tiêu chuẩn. Các ứng dụng của FHE có thể chọn thuê ngoài tính toán và xác minh cho các bộ đồng xử lý của FHE.

5.Một hạn chế cơ bản của FHE onchain là “ai giữ khóa giải mã?” Giải mã ngưỡng và MPC cung cấp các giải pháp, tuy nhiên, chúng thường bị ràng buộc bởi sự cân bằng giữa hiệu suất và bảo mật.

Giới thiệu:

Bản chất minh bạch của blockchain là con dao hai lưỡi; mặc dù có vẻ đẹp ở tính cởi mở và khả năng quan sát của nó nhưng nó lại là trở ngại cơ bản cho việc áp dụng của doanh nghiệp.

Quyền riêng tư trên chuỗi là một trong những vấn đề thách thức nhất đối với tiền điện tử trong gần một thập kỷ. Mặc dù có nhiều nhóm xây dựng hệ thống dựa trên ZK để đạt được quyền riêng tư trên chuỗi; họ không thể hỗ trợ trạng thái được chia sẻ, mã hóa. Tại sao? Câu trả lời ngắn gọn là vì các chương trình này là chức năng của một loạt ZKP và do đó, không ai có thể áp dụng logic tùy ý cho trạng thái hiện tại. Điều đó có nghĩa là gì? Về cơ bản, chúng tôi không thể xây dựng các ứng dụng trạng thái chia sẻ bí mật (hãy nghĩ đến Uniswap riêng tư) chỉ bằng ZKP.

Tuy nhiên, những đột phá gần đây đã chỉ ra rằng việc kết hợp ZKP với Mã hóa hoàn toàn đồng hình (FHE) có thể đạt được DeFi bí mật, có thể khái quát hóa hoàn toàn. Làm sao? FHE là một lĩnh vực mật mã đang phát triển cho phép tính toán tùy ý trên dữ liệu được mã hóa (nghe có vẻ điên rồ phải không?!) Như được hiển thị trong hình trên, ZKP có thể chứng minh tính toàn vẹn của dữ liệu đầu vào và tính toán của người dùng và FHE có thể tự xử lý tính toán.

Mặc dù FHE hứa hẹn sẽ là “Chén Thánh của Mật mã học”, nhưng chúng tôi cố gắng đưa ra phân tích khách quan về lĩnh vực này cũng như các thách thức khác nhau và các giải pháp khả thi của nó. Chúng tôi đề cập đến các chủ đề FHE onchain sau:

• Lược đồ, thư viện và trình biên dịch FHE
• Giải mã ngưỡng an toàn
• ZKP cho đầu vào của người dùng + nhóm máy tính
• Lớp DA có thể lập trình, có thể mở rộng
• Phần cứng FHE

Lược đồ, thư viện và trình biên dịch FHE

Thách thức: Các lược đồ, thư viện và trình biên dịch FHE mới ra đời

Nút thắt cơ bản của FHE onchain nằm ở cơ sở hạ tầng/công cụ dành cho nhà phát triển đang bị tụt hậu. Không giống như ZKP hay MPC, FHE chỉ mới xuất hiện từ năm 2009 và do đó có thời gian trưởng thành ngắn hơn nhiều.

Những hạn chế chính trong FHE DevEx là:

• Một ngôn ngữ giao diện người dùng dễ sử dụng dành cho các nhà phát triển viết mã mà không cần nhiều kiến thức về mật mã phụ trợ
• Trình biên dịch FHE đầy đủ chức năng có thể xử lý tất cả các công việc bẩn thỉu. (Lựa chọn tham số, tối ưu hóa SIMD cho BGV/BFV và tối ưu hóa song song)
• Các sơ đồ FHE hiện tại (đặc biệt là TFHE) chậm hơn khoảng 1000 lần so với tính toán đơn giản

Để thực sự hiểu được sự phức tạp của việc tích hợp FHE, hãy cùng tìm hiểu hành trình của nhà phát triển:

Bước đầu tiên để tích hợp FHE vào ứng dụng của bạn là chọn sơ đồ FHE để sử dụng. Biểu đồ sau đây giải thích các sơ đồ chính:

Như được hiển thị trong bảng trên, các mạch boolean như FHEW & TFHE có tốc độ khởi động nhanh nhất và có thể tránh được quy trình chọn tham số khá phức tạp và chúng có thể được sử dụng trong các phép tính tùy ý/chung nhưng tương đối chậm; Mặc dù BGV/BFV có thể phù hợp với DeFi nói chung vì chúng hiệu quả hơn trong việc tính toán số học có độ chính xác cao, nhưng các nhà phát triển phải biết trước độ sâu của mạch để thiết lập tất cả các tham số của sơ đồ. Ở đầu bên kia của quang phổ, CKKS hỗ trợ phép nhân đồng cấu trong đó cho phép sai số chính xác, giúp nó trở nên tối ưu cho các trường hợp sử dụng không chính xác như ML.

Là nhà phát triển, bạn cần chọn giải pháp FHE thật cẩn thận vì nó sẽ ảnh hưởng đến tất cả các quyết định thiết kế khác và hiệu suất trong tương lai. Ngoài ra, có một số tham số chính rất quan trọng để thiết lập chính xác sơ đồ FHE, chẳng hạn như lựa chọn kích thước mô-đun và vai trò của bậc đa thức.

Chuyển sang các thư viện, bạn có thể xem các tính năng và khả năng của các thư viện FHE phổ biến từ bảng bên dưới:

Nhưng các thư viện cũng có mối quan hệ khác nhau với các lược đồ và trình biên dịch như dưới đây:

Sau khi lựa chọn giải pháp FHE, nhà phát triển cần thiết lập các thông số. Việc lựa chọn đúng các tham số sẽ có tác động rất lớn đến hiệu suất của sơ đồ FHE. Khó khăn hơn, điều này đòi hỏi một số hiểu biết về đại số trừu tượng, các phép toán dành riêng cho FHE như tái tuyến tính hóa và chuyển đổi tương tự sang số cũng như các mạch số học hoặc nhị phân. Cuối cùng, để lựa chọn tham số hiệu quả, cần có sự hiểu biết khái niệm về cách chúng ảnh hưởng đến sơ đồ FHE.

Tại thời điểm này, các nhà phát triển có thể hỏi:

Không gian bản rõ của tôi cần phải lớn đến mức nào? Độ lớn của bản mã có thể được chấp nhận? Tôi có thể tính toán song song ở đâu? Và nhiều cái khác…

Ngoài ra, mặc dù FHE có thể hỗ trợ tính toán tùy ý nhưng các nhà phát triển cần thay đổi tư duy khi viết chương trình FHE. Ví dụ: người ta không thể viết nhánh (if-else) tùy thuộc vào một biến trong chương trình, vì chương trình không thể so sánh trực tiếp các biến như dữ liệu thuần túy. Thay vào đó, các nhà phát triển cần thay đổi mã của họ từ các nhánh sang một loại tính toán nào đó có thể kết hợp các điều kiện của tất cả các nhánh. Tương tự, điều này ngăn cản các nhà phát triển viết các vòng lặp trong mã của họ.

Nói tóm lại, đối với một nhà phát triển chưa quen với FHE, gần như không thể tích hợp FHE vào ứng dụng của họ. Nó sẽ yêu cầu công cụ/cơ sở hạ tầng dành cho nhà phát triển đáng kể để loại bỏ sự phức tạp do FHE trình bày.

Giải pháp:

1. Trình biên dịch FHE cụ thể của Web3

Mặc dù đã tồn tại các trình biên dịch FHE được xây dựng bởi Google và Microsoft, nhưng chúng là:

• Không được thiết kế chú trọng đến hiệu suất, tăng thêm chi phí gấp 1000 lần so với việc viết mạch trực tiếp
• Được tối ưu hóa cho CKKS (còn gọi là ML) và không có lợi cho BFV/BGV cần thiết cho DeFi
• Không được xây dựng cho Web3. Không hỗ trợ khả năng tương thích với các sơ đồ ZKP, chuỗi chương trình, v.v.

Đó là cho đến khi trình biên dịch Kem chống nắng FHE. Nó là trình biên dịch gốc Web3 cung cấp một số hiệu suất tốt nhất cho các phép tính số học (ví dụ như DeFi) mà không cần bộ tăng tốc phần cứng. Như đã thảo luận ở trên, việc lựa chọn tham số được cho là phần khó khăn nhất khi triển khai sơ đồ FHE; Kem chống nắng không chỉ tự động lựa chọn tham số mà còn mã hóa dữ liệu, chọn khóa, thực hiện tái tuyến tính hóa và chuyển đổi mô đun, thiết lập các mạch và thực hiện các hoạt động kiểu SIMD.

Khi hướng tới tương lai, chúng tôi hy vọng sẽ thấy những cải tiến hơn nữa không chỉ trong trình biên dịch Sunscreen mà còn các nhóm khác đang xây dựng các triển khai của riêng họ để hỗ trợ các ngôn ngữ cấp cao khác.

1. Thư viện FHE mới

Trong khi các nhà nghiên cứu tiếp tục khám phá các chương trình mạnh mẽ mới, các thư viện FHE có thể cho phép nhiều nhà phát triển hơn tích hợp FHE.

Hãy lấy hợp đồng thông minh của FHE làm ví dụ. Mặc dù có thể khó chọn từ các thư viện FHE khác nhau, nhưng sẽ dễ dàng hơn khi chúng ta nói về FHE trên chuỗi vì chỉ có một số ngôn ngữ lập trình thống trị trên Web3.

Ví dụ: fhEVM của Zama tích hợp thư viện nguồn mở TFHE-rs của Zama vào một EVM điển hình, hiển thị các hoạt động đồng hình dưới dạng hợp đồng được biên dịch trước. Cho phép các nhà phát triển sử dụng dữ liệu được mã hóa trong hợp đồng của họ một cách hiệu quả mà không có bất kỳ thay đổi nào đối với các công cụ biên dịch.

Đối với các kịch bản cụ thể khác, một số cơ sở hạ tầng khác có thể được yêu cầu. Ví dụ: thư viện TFHE viết bằng C++ không được bảo trì tốt như phiên bản Rust. Mặc dù TFHE-rs có thể hỗ trợ xuất cho C/C++, nhưng nếu các nhà phát triển C++ muốn có khả năng tương thích và hiệu suất tốt hơn, họ phải viết phiên bản thư viện TFHE của riêng họ.

Cuối cùng, lý do cốt lõi cho việc thiếu cơ sở hạ tầng FHE trên thị trường là do chúng tôi thiếu những cách hiệu quả để xây dựng FHE-RAM. Một giải pháp khả thi là làm việc trên FHE-EVM mà không cần một số opcode nhất định.

Giải mã ngưỡng an toàn

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í mật đều được xác định dựa trên khóa mã hóa/giải mã. Không một bên nào có thể được tin cậy, do đó khóa giải mã được phân chia giữa những người tham gia mạng.

Một trong những khía cạnh thách thức nhất của FHE trên chuỗi (Threshold FHE) là xây dựng một giao thức giải mã ngưỡng an toàn và hiệu quả. Có hai điểm nghẽn chính: (1) Tính toán dựa trên FHE gây ra chi phí đáng kể, do đó yêu cầu các nút có hiệu suất cao vốn làm giảm kích thước tiềm năng của bộ trình 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 lên.

Ít nhất là hiện tại, các giao thức FHE dựa vào đa số trung thực trong số những người xác thực, tuy nhiên như đã nêu ở trên, Ngưỡng FHE hàm ý một bộ trình xác thực nhỏ hơn và do đó, xác suất thông đồng và hành vi độc hại cao hơn.

Điều gì sẽ xảy ra nếu các nút ngưỡng thông đồng với nhau? Họ sẽ có thể bỏ qua giao thức và về cơ bản giải mã mọi thứ, từ thông tin đầu vào của người dùng đến bất kỳ dữ liệu onchain nào. Ngoài ra, điều quan trọng cần lưu ý là giao thức giải mã có thể diễn ra mà không bị phát hiện trong các hệ thống hiện tại (còn gọi là “tấn công thầm lặng”).

Giải pháp: Giải mã ngưỡng được cải thiện hoặc MPC động

Có một số cách có thể giải quyết những thiếu sót của việc giải mã ngưỡng. (1) Kích hoạt ngưỡng n/2, điều này sẽ khiến việc thông đồng trở nên khó khăn hơn (2) Chạy giao thức giải mã ngưỡng bên trong HSM (3) Sử dụng mạng giải mã ngưỡng dựa trên TEE được kiểm soát bởi chuỗi phi tập trung để xác thực cho phép động quản lý chìa khóa.

Thay vì tận dụng việc giải mã ngưỡng, bạn có thể sử dụng MPC. Một ví dụ về giao thức MPC có thể được sử dụng trong FHE onchain bao gồm 2PC-MPC mới của Odsy, thuật toán MPC phi tập trung và không thông đồng đầu tiên.

Một cách tiếp cận khác có thể là chỉ sử dụng khóa chung của người dùng để mã hóa dữ liệu. Sau đó, người xác thực sẽ xử lý các hoạt động đồng hình và chính người dùng có thể giải mã kết quả nếu cần. Mặc dù chỉ khả thi đối với các trường hợp sử dụng thích hợp, nhưng chúng tôi hoàn toàn có thể tránh được giả định về ngưỡng.

Tóm lại, FHE onchain cần triển khai MPC hiệu quả: (1) Hoạt động ngay cả khi có tác nhân độc hại (2) Giới thiệu độ trễ tối thiểu (3) Cho phép nhập các nút linh hoạt/không cần cấp phép.

Bằng chứng không có kiến thức (ZKP) dành cho bên tính toán và đầu vào của người dùng

Thách thức: Khả năng xác minh thông tin đầu vào của người dùng + Tính toán:

Trong web2, khi chúng tôi yêu cầu thực hiện một nhiệm vụ tính toán, chúng tôi hoàn toàn tin tưởng một công ty nhất định sẽ thực hiện nhiệm vụ đó chính xác như những gì họ đã hứa ở hậu trường. Trong web3, mô hình bị đảo lộn hoàn toàn; thay vì dựa vào danh tiếng của một công ty và chỉ tin tưởng rằng họ sẽ hành động trung thực, chúng tôi hiện đang hoạt động trong một môi trường không đáng tin cậy, nghĩa là người dùng không cần phải tin tưởng bất kỳ ai.

Mặc dù FHE cho phép xử lý dữ liệu được mã hóa nhưng nó không thể xác minh tính chính xác của dữ liệu đầu vào hoặc tính toán của người dùng. Nếu không có khả năng kiểm tra, FHE hầu như không hữu ích trong bối cảnh blockchain.

Giải pháp: ZKP cho Đầu vào của Người dùng + Bên Máy tính:

Trong khi FHE cho phép mọi người thực hiện tính toán tùy ý trên dữ liệu được mã hóa thì ZKP cho phép người ta chứng minh điều gì đó là đúng mà không tiết lộ thông tin cơ bản. Vậy họ có mối quan hệ như thế nào?

Có ba cách chính mà FHE và ZKP phù hợp với nhau:

1. Người dùng cần gửi bằng chứng cho thấy văn bản mã hóa đầu vào của họ được định dạng đúng. Có nghĩa là văn bản mã hóa đáp ứng các yêu cầu của sơ đồ mã hóa và không chỉ là các chuỗi dữ liệu tùy ý.
2. Người dùng cần gửi bằng chứng cho thấy bản rõ đầu vào của họ đáp ứng các điều kiện của ứng dụng nhất định. Bán tại. số tiền_số dư > số tiền_chuyển khoản
3. Nút xác thực (còn gọi là bên tính toán) cần chứng minh rằng họ đã thực hiện chính xác phép tính FHE. Điều này được gọi là “FHE có thể xác minh” và có thể được coi là tương tự như ZKP cần thiết cho quá trình tổng hợp.

Để khám phá thêm các ứng dụng của ZKP:

1. ZKP của bản mã

FHE được xây dựng trên mật mã dựa trên mạng, nghĩa là việc xây dựng mật mã nguyên thủy bao gồm các mạng, có độ bảo mật PQ (hậu lượng tử). Ngược lại, các ZKP phổ biến như SNARKS, STARKS và Bulletproofs không dựa vào mật mã dựa trên mạng tinh thể.

Để chứng minh rằng bản mã FHE của người dùng là đúng định dạng, chúng ta cần chứng minh rằng nó thỏa mãn một số phương trình vectơ ma trận với các mục từ các vòng và giá trị số của các phần tử này là nhỏ. Về cơ bản, chúng ta cần một hệ thống chứng minh xác minh trên chuỗi có hiệu quả về mặt chi phí được thiết kế để xử lý các mối quan hệ dựa trên mạng lưới, đây là một lĩnh vực nghiên cứu mở.

1. ZKP của đầu vào bản rõ

Ngoài việc chứng minh một bản mã được định dạng đúng, người dùng cần chứng minh bản rõ đầu vào của họ đáp ứng các yêu cầu của ứng dụng. May mắn thay, không giống như bước trước, chúng tôi có thể sử dụng SNARK chung để chứng minh tính hợp lệ dựa trên thông tin đầu vào của người dùng, do đó cho phép các nhà phát triển tận dụng các sơ đồ, thư viện và cơ sở hạ tầng ZKP hiện có.

Tuy nhiên, phần thử thách là chúng ta cần “kết nối” hai hệ thống chứng minh. Kết nối vì chúng tôi 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 thì người dùng độc hại có thể gian lận giao thức. Một lần nữa, đây là một kỳ công mật mã cực kỳ khó khăn và là một lĩnh vực nghiên cứu mở đầu.

Kem chống nắng cũng đã đặt nền móng cho trình biên dịch ZKP của họ cung cấp hỗ trợ cho Bulletproofs vì nó kết nối dễ dàng nhất với SDLP. Sự phát triển trong tương lai đang được thực hiện để “liên kết” trình biên dịch FHE và ZKP.

Mind Network đã đi tiên phong trong việc tích hợp ZKP để đảm bảo đầu vào và đầu ra không tin cậy cùng với việc tận dụng FHE để tính toán an toàn.

1. ZKP tính toán chính xác

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ư chúng ta đã thấy tính năng động của bộ ba bất khả thi về khả năng mở rộng diễn ra trước đây, các mạng có yêu cầu tài nguyên nút cao hơn không thể mở rộng đến mức phân cấp đủ. Một giải pháp khả thi có thể là một quy trình được gọi là “FHE có thể xác minh”, một quy trình trong đó bên tính toán (người xác thực) gửi ZKP để chứng minh việc thực hiện giao dịch một cách trung thực.

Một nguyên mẫu ban đầu của FHE có thể kiểm chứng được có thể được hiển thị bởi một dự án có tên SherLOCKED. Về cơ bản, tính toán FHE được chuyển sang Bonsai của Risc ZERO, xử lý tính toán trên chuỗi dữ liệu được mã hóa và trả về kết quả bằng ZKP và cập nhật trạng thái trên chuỗi.

Có thể thấy một ví dụ gần đây về việc tận dụng bộ đồng xử lý FHE trong bản demo đấu giá trực tuyến của Aztec. Như chúng tôi đã đề cập trước đó, chuỗi FHE hiện tại mã hóa toàn bộ trạng thái bằng khóa ngưỡng, nghĩa là hệ thống chỉ mạnh bằng ủy ban ngưỡng của nó. Ngược lại, ở Aztec, người dùng sở hữu dữ liệu của riêng họ và do đó không phải tuân theo giả định về ngưỡng bảo mật.

Cuối cùng, điều quan trọng là phải đề cập đến nơi nhà phát triển có thể xây dựng ứng dụng FHE ngay từ đầu. Các nhà phát triển có thể xây dựng ứng dụng của họ trên L1 được hỗ trợ bởi FHE, bản tổng hợp FHE hoặc xây dựng trên bất kỳ chuỗi EVM nào và tận dụng bộ đồng xử lý FHE. Mỗi thiết kế đều có những điểm cân bằng riêng, tuy nhiên, chúng tôi thiên về các bản tổng hợp FHE được thiết kế tốt (do Fhenix tiên phong) hoặc bộ đồng xử lý FHE vì chúng kế thừa khả năng bảo mật từ Ethereum cùng với các lợi ích khác.

Cho đến gần đây, việc đạt được bằng chứng gian lận trên dữ liệu được mã hóa FHE rất phức tạp, nhưng gần đây nhóm tại Fhenix.io đã trình diễn cách đạt được bằng chứng gian lận bằng cách sử dụng ngăn xếp Arbitrum Nitro kết hợp với quá trình biên dịch logic FHE cho WebAssembly.

Lớp sẵn có dữ liệu (DA) của FHE

Thách thức: Thiếu khả năng tùy chỉnh và thông lượng

Mặc dù việc lưu trữ đã được phổ biến hóa trong web2 nhưng điều này không còn đúng trong Web3. Do FHE duy trì lượng dữ liệu lớn hơn 10.000 lần, chúng ta cần tìm ra nơi lưu trữ các bản mã FHE lớn. Nếu mọi nhà điều hành nút trong một lớp DA nhất định đều tải xuống và lưu trữ mọi dữ liệu của chuỗi FHE thì chỉ những nhà điều hành tổ chức mới có thể theo kịp nhu cầu, gây rủi ro cho việc tập trung hóa.

Về thông lượng, Celestia đạt tốc độ cao nhất là 6,7mb/s, nếu chúng tôi muốn chạy bất kỳ dạng FHEML nào, chúng tôi sẽ dễ dàng cần n GBs+/giây. Theo dữ liệu gần đây được chia sẻ bởi 1k(x), các lớp DA hiện tại không thể hỗ trợ FHE do các quyết định thiết kế hạn chế thông lượng (có chủ ý).

Giải pháp: Chia tỷ lệ theo chiều ngang + Khả năng tùy chỉnh

Chúng ta cần một lớp DA có thể hỗ trợ khả năng mở rộng theo chiều ngang. Kiến trúc DA hiện tại truyền tất cả dữ liệu đến mọi nút trong mạng, đây là hạn chế lớn đối với khả năng mở rộng. Ngược lại, với khả năng mở rộng theo chiều ngang, khi có nhiều nút DA hơn vào hệ thống, mỗi nút sẽ lưu trữ 1/n dữ liệu, cải thiện hiệu suất và chi phí khi có nhiều không gian khối hơn.

Riêng biệt, với kích thước dữ liệu đáng kể được liên kết với FHE, sẽ rất hợp lý nếu cung cấp cho các nhà phát triển mức độ tùy chỉnh cao hơn xung quanh các ngưỡng mã hóa xóa. I E Bạn cảm thấy thoải mái khi được đảm bảo bao nhiêu phần trăm của hệ thống DA? Cho dù trọng số dựa trên cổ phần hay trọng số dựa trên phân cấp.

Kiến trúc của EigenDA đóng vai trò là nền tảng cho hình thức của lớp DA cho FHE. Đó là các đặc tính của quy mô theo chiều ngang, giảm chi phí cấu trúc, tách rời DA và đồng thuận, v.v., tất cả đều nhường chỗ cho mức độ mở rộng mà một ngày nào đó có thể hỗ trợ FHE.

Cuối cùng, một ý tưởng cấp cao có thể là xây dựng các khe lưu trữ được tối ưu hóa để lưu trữ bản mã FHE vì các bản mã tuân theo một sơ đồ mã hóa cụ thể, do đó, việc có các khe lưu trữ được tối ưu hóa có thể giúp sử dụng hiệu quả bộ nhớ và truy xuất nhanh hơn.

Phần cứng mã hóa hoàn toàn đồng hình (FHE)

Thách thức: Phần cứng FHE hiệu suất thấp

Trong quá trình quảng bá các ứng dụng mã hóa đồng hình hoàn toàn (FHE) trên chuỗi, một vấn đề chính là độ trễ đáng kể do chi phí tính toán, khiến việc chạy FHE không thực tế trên bất kỳ phần cứng xử lý tiêu chuẩn nào. Hạn chế này xuất phát từ lượng tương tác lớn với bộ nhớ do lượng dữ liệu khổng lồ mà bộ xử lý cần xử lý. Ngoài các tương tác bộ nhớ, các phép tính đa thức phức tạp và các hoạt động duy trì bản mã tốn nhiều thời gian cũng mang lại nhiều chi phí.

Để hiểu rõ hơn về trạng thái của máy gia tốc FHE, chúng ta cần khám phá không gian thiết kế: Máy gia tốc FHE dành riêng cho ứng dụng so với máy gia tốc FHE tổng quát.

Mấu chốt của độ phức tạp tính toán và thiết kế phần cứng cho FHE luôn liên quan đến số phép nhân cần thiết cho một ứng dụng nhất định, được gọi là “độ sâu của hoạt động đồng hình”. Trong trường hợp ứng dụng cụ thể, độ sâu đã biết nên các tham số hệ thống và tính toán liên quan là cố định. Do đó, thiết kế phần cứng cho trường hợp dành riêng cho ứng dụng này sẽ dễ dàng hơn và thường có thể được tối ưu hóa để có hiệu suất tốt hơn so với thiết kế bộ tăng tốc tổng quát. Trong trường hợp tổng quát, khi FHE được yêu cầu hỗ trợ một số phép nhân tùy ý, thì việc khởi động là cần thiết để loại bỏ một phần nhiễu tích lũy trong các phép toán đồng cấu. Quá trình khởi động rất tốn kém và yêu cầu tài nguyên phần cứng đáng kể bao gồm bộ nhớ trên chip, băng thông bộ nhớ và khả năng tính toán, điều đó có nghĩa là thiết kế phần cứng sẽ rất khác so với thiết kế dành riêng cho ứng dụng. Do đó, mặc dù công việc được thực hiện bởi những công ty lớn trong lĩnh vực này, bao gồm cả Intel, Duality, SRI, DARPA và nhiều công ty khác chắc chắn đang vượt qua các giới hạn với thiết kế dựa trên GPU và ASIC của họ, nhưng chúng có thể không áp dụng được 1:1 cho hỗ trợ các trường hợp sử dụng blockchain.

Về chi phí phát triển: Phần cứng có tính phổ quát đòi hỏi nhiều vốn hơn để thiết kế và sản xuất so với phần cứng dành riêng cho ứng dụng, nhưng tính linh hoạt của nó cho phép phần cứng được sử dụng trong phạm vi ứng dụng rộng hơn. Mặt khác, với thiết kế dành riêng cho ứng dụng, nếu nhu cầu của ứng dụng thay đổi và yêu cầu hỗ trợ tính toán đồng cấu sâu hơn thì phần cứng dành riêng cho ứng dụng sẽ cần được kết hợp với một số kỹ thuật phần mềm, chẳng hạn như MPC, để đạt được mục đích tương tự như phần cứng có thể khái quát hóa.

Điều quan trọng cần lưu ý là FHE onchain khó tăng tốc hơn nhiều so với các trường hợp sử dụng dành riêng cho ứng dụng (ví dụ: FHEML) vì nó yêu cầu khả năng xử lý các tính toán tổng quát hơn so với một tập hợp thích hợp hơn. Để minh họa, fhEVM devnet hiện bị hạn chế ở TPS một chữ số.

Do chúng ta cần một công cụ tăng tốc FHE được điều chỉnh cho phù hợp với blockchain, một điều cần cân nhắc khác là khả năng chuyển đổi công việc từ phần cứng ZKP sang phần cứng FHE như thế nào?

Có một số mô-đun chung giữa ZKP và FHE, chẳng hạn như phép biến đổi lý thuyết số (NTT) và các phép toán đa thức cơ bản. Tuy nhiên, độ rộng bit của NTT được sử dụng trong hai trường hợp này là khác nhau. Trong ZKP, phần cứng cần hỗ trợ nhiều độ rộng bit cho NTT, chẳng hạn như 64 bit và 256 bit, trong khi ở FHE, toán hạng cho NTT ngắn hơn do được biểu thị trong hệ thống số dư. Thứ hai, mức độ NTT được xử lý trong ZKP nhìn chung cao hơn so với trường hợp FHE. Vì hai lý do này, việc thiết kế một mô-đun NTT đạt được hiệu suất thỏa mãn cho cả ZKP và FHE là điều không hề đơn giản. Ngoài NTT, còn có một số điểm nghẽn máy tính khác trong FHE, chẳng hạn như tính tự động cấu hình, không có trong ZKP. Một cách đơn giản để chuyển phần cứng ZKP sang cài đặt FHE là giảm tải tác vụ tính toán NTT sang phần cứng ZKP và sử dụng CPU hoặc phần cứng khác để xử lý phần còn lại của tính toán trong FHE.

Để giải quyết những thách thức, việc tính toán trên dữ liệu được mã hóa bằng FHE từng chậm hơn 100.000 lần so với dữ liệu văn bản gốc. Tuy nhiên, nhờ các sơ đồ mã hóa mới hơn và những phát triển gần đây về phần cứng FHE, hiệu suất hiện tại đã được cải thiện đáng kể, chậm hơn khoảng 100 lần so với dữ liệu văn bản gốc.

Các giải pháp:

1. Cải thiện phần cứng FHE

Có nhiều nhóm đang tích cực xây dựng các máy gia tốc FHE, tuy nhiên, họ không làm việc trên các máy 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ề trình tăng tốc phần cứng dành riêng cho blockchain là FPT, trình tăng tốc FPGA điểm cố định. FPT là công cụ tăng tốc phần cứng đầu tiên khai thác triệt để tiếng ồn vốn có trong tính toán FHE bằng cách triển khai hoàn toàn quá trình khởi động TFHE với 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 họ kiến trúc gồm các bộ tăng tốc phần cứng nhằm mục đích tăng tốc đáng kể các tính toán FHE trên đám mây.

Như đã trình bày trước đó, một trong những điểm nghẽn chính trong thiết kế phần cứng FHE là sự tương tác lớn với bộ nhớ. Để vượt qua rào cản này, một giải pháp tiềm năng là giảm sự tương tác với bộ nhớ càng nhiều càng tốt. Tính toán xử lý trong bộ nhớ (PIM) hoặc gần bộ nhớ có thể hữu ích trong trường hợp này. PIM là một giải pháp đầy hứa hẹn để giải quyết các thách thức về “bức tường bộ nhớ” cho các hệ thống máy tính trong tương lai, cho phép bộ nhớ phục vụ cả chức năng tính toán và bộ nhớ, hứa hẹn một sự đổi mới căn bản về mối quan hệ giữa tính toán và bộ nhớ. Trong thập kỷ qua, người ta đã đạt được tiến bộ to lớn trong việc thiết kế các bộ nhớ bất biến cho mục đích này, chẳng hạn như RAM điện trở, RAM từ tính mô-men xoắn truyền spin và bộ nhớ thay đổi pha. Bằng cách sử dụng bộ nhớ đặc biệt này, đã có công trình cho thấy sự cải thiện đáng kể về tính toán trong học máy và mã hóa khóa công khai dựa trên mạng.

1. Tối ưu hóa phần mềm và phần cứng

Trong những phát triển gần đây, phần mềm đã được thừa nhận là một thành phần quan trọng trong quá trình tăng tốc phần cứng. Ví dụ, các máy gia tốc FHE nổi bật như F1 và CraterLake sử dụng trình biên dịch cho phương pháp đồng thiết kế phần mềm/phần cứng lai.

Khi không gian tiến bộ, chúng ta có thể mong đợi các trình biên dịch đầy đủ chức năng sẽ được đồng thiết kế với các 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 hóa các chương trình FHE dựa trên mô hình chi phí của sơ đồ FHE tương ứng. Các trình biên dịch FHE này có thể được tích hợp với các trình biên dịch tăng tốc FHE để cải thiện hiệu suất từ đầu đến cuối bằng cách kết hợp mô hình chi phí từ khía cạnh cấp độ phần cứng.

1. Máy gia tốc FHE kết nối mạng: Sự chuyển đổi từ mở rộng quy mô sang mở rộng quy mô

Những nỗ lực tăng tốc phần cứng FHE hiện tại chủ yếu tập trung vào “mở rộng quy mô”, nghĩa là tập trung vào việc cải thiện một bộ tăng tốc duy nhất theo chiều dọc. Mặt khác, các địa điểm “mở rộng quy mô” tập trung vào việc kết nối nhiều máy gia tốc FHE bằng cách kết nối mạng theo chiều ngang, điều này có thể cải thiện đáng kể hiệu suất, giống như tạo bằng chứng song song với ZKP.

Một trong những khó khăn chính khi tăng tốc FHE là vấn đề lạm phát dữ liệu: Đề cập đến 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, đặt ra những thách thức cho việc di chuyển dữ liệu hiệu quả giữa bộ nhớ trên chip và bộ nhớ ngoài chip.

Lạm phát dữ liệu đặt ra thách thức đáng kể trong việc kết nối nhiều máy gia tốc FHE thông qua kết nối mạng theo chiều ngang. Vì vậy, việc đồng thiết kế phần cứng và mạng của FHE sẽ là một hướng nghiên cứu đầy hứa hẹn trong tương lai. Một ví dụ có thể bao gồm định tuyến mạng thích ứng cho máy gia tốc FHE: Triển khai cơ chế định tuyến điều chỉnh động các đường dẫn dữ liệu giữa các máy gia tốc FHE dựa trên tải tính toán thời gian thực và lưu lượng mạng. Đ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ả.

Phần kết luận

Về cơ bản, FHE sẽ hình dung lại cách chúng ta bảo mật dữ liệu trên các nền tảng, mở đường cho một kỷ nguyên mới về quyề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 những tiến bộ đáng kể không chỉ ở FHE mà còn ở ZKP và MPC.

Khi chúng ta dấn thân 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ã, kỹ sư phần mềm và chuyên gia phần cứng sẽ là điều bắt buộc. Chưa kể các nhà lập pháp, chính trị gia, v.v. vì việc tuân thủ quy định là con đường duy nhất để được áp dụng rộng rãi.

Cuối cùng, FHE sẽ đi đầu trong làn sóng biến đổi về chủ quyền kỹ thuật số, báo trước một tương lai nơi quyền riêng tư và bảo mật dữ liệu không còn loại trừ lẫn nhau mà thống nhất chặt chẽ.

Cảm tạ:

Xin chân thành cảm ơn Mason Song (Mind Network), Guy Itzhaki (Fhenix), Leo Fan (Cysic), Kurt Pan, Xiang Xie (PADO), Nitanshu Lokhande (BananaHQ) đã đánh giá. Chúng tôi mong muốn được đọc về công việc và nỗ lực ấn tượng mà những cá nhân này đang làm trong lĩnh vực này!

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được in lại từ [HashKey Capital]. Mọi bản quyền thuộc về tác giả gốc [Jeffrey Hu、Arnav Pagidyala]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch đều bị cấm.