FHE là bước tiếp theo của ZK, công nghệ mã hóa nói như vậy
Tuyển chọn TechFlowTuyển chọn TechFlow
FHE là bước tiếp theo của ZK, công nghệ mã hóa nói như vậy
Ứng dụng thực tiễn và triển khai là điểm đột phá để FHE trở thành cơ sở hạ tầng của blockchain.
Chuyên sâu báo cáo Web3Tác giả: Tả Gia
Dòng phát triển chính của tiền mã hóa cực kỳ rõ ràng: Bitcoin tạo ra tiền mã hóa, Ethereum tạo ra chuỗi công khai, công ty Tether tạo ra stablecoin, BitMEX tạo ra hợp đồng vĩnh viễn. Bốn sáng tạo này giống như những nguyên lý mật mã học, xây dựng nên một thị trường trị giá hàng nghìn tỷ đô la, vô số huyền thoại làm giàu nhanh chóng, hoặc giấc mộng phi tập trung luôn được khắc ghi trong lòng người.
Tuy nhiên, lộ trình phát triển công nghệ mã hóa lại không rõ ràng bằng. Các loại thuật toán đồng thuận và thiết kế tinh xảo khác đều thua kém hệ thống stake và đa ký (multi-sig), trong khi chính hai yếu tố sau mới là trụ cột thực sự duy trì hoạt động của hệ thống mã hóa. Ví dụ, nếu bỏ WBTC với cơ chế stake phi tập trung, phần lớn các lớp L2 của BTC sẽ không thể tồn tại. Babylon với cơ chế stake gốc là một khám phá theo hướng này — một nỗ lực trị giá 70 triệu đô la Mỹ.
Trong bài viết này, tôi cố gắng phác họa một lịch sử phát triển công nghệ mã hóa, khác biệt so với quá trình biến đổi kỹ thuật thông thường trong ngành mã hóa, ví dụ như mối quan hệ giữa FHE, ZK và MPC. Xét về trình tự ứng dụng sơ lược, MPC dùng để khởi đầu, FHE có thể dùng cho quá trình tính toán trung gian, còn ZK dùng để chứng minh cuối cùng. Về thứ tự thời gian ứng dụng, ZK là công nghệ sớm được triển khai nhất, tiếp đó là khái niệm ví AA bùng nổ, MPC dần được chú ý như một giải pháp kỹ thuật và phát triển nhanh hơn, riêng FHE dù đã được thần linh "tiên tri" từ năm 2020 nhưng mãi đến năm 2024 mới bắt đầu nóng lên.
MPC/FHE/ZKP
Khác với ZK và MPC, FHE thậm chí còn khác biệt với mọi thuật toán mã hóa hiện tại. Ngoài FHE, tất cả các hệ thống mã hóa đối xứng hay bất đối xứng đều nhằm mục đích tạo ra một “hệ thống mật mã khó hoặc không thể giải mã” để đạt được an toàn tuyệt đối. Nhưng mục tiêu của FHE là để văn bản mã hóa phát huy tác dụng — tức là việc mã hóa và giải mã rất quan trọng, song nội dung sau khi mã hóa nhưng trước khi giải mã cũng không nên bị lãng phí.
Lý thuyết đầy đủ, Web2 triển khai trước Web3
FHE là một công nghệ nền tảng, đã hoàn thành nghiên cứu lý thuyết trong giới học thuật. Các ông lớn Web2 đóng góp rất nhiều, ví dụ như Microsoft, Intel, IBM và Duality được DARPA hỗ trợ đã tiến hành chuẩn bị phần cứng-phần mềm và công cụ phát triển.
Có một tin tốt là ngay cả các ông lớn Web2 cũng chưa biết rõ nên dùng FHE vào việc gì, do đó Web3 bắt đầu từ bây giờ vẫn chưa muộn. Nhưng cũng có tin xấu là khả năng thích nghi của Web3 gần như bằng 0; các hệ thống chủ đạo như Bitcoin và Ethereum không thể tương thích nguyên bản với thuật toán FHE. Mặc dù Ethereum được gọi là máy tính toàn cầu, nhưng tính toán FHE "thô" trên đó có lẽ phải kéo dài tới ngày tận thế.
Chúng ta tập trung chủ yếu vào các khám phá trong Web3, chỉ cần nhớ rằng các ông lớn Web2 cực kỳ nhiệt huyết với FHE và đã thực hiện rất nhiều công việc nền tảng.
Lý do là vì Vitalik từ năm 2020 đến 2024 đều tập trung vào ZK.
Ở đây cần đơn giản lý giải nguyên nhân ZK bùng nổ theo góc nhìn của tôi: Sau khi Ethereum xác định lộ trình mở rộng quy mô thông qua Rollup, chức năng nén trạng thái của ZK có thể giảm đáng kể kích thước dữ liệu truyền từ L2 lên L1, mang lại giá trị kinh tế to lớn. Tất nhiên, đây mới chỉ là lý thuyết. Sự phân mảnh của L2, vấn đề bộ sắp xếp (sequencer), hay thậm chí một số L2/Rollup thu phí giao dịch của người dùng, đều là những vấn đề mới xuất hiện trong quá trình phát triển, chỉ có thể giải quyết bằng cách tiếp tục phát triển.
Tóm gọn lại, Ethereum cần mở rộng quy mô, xác lập tuyến đường phát triển Layer 2, các Rollup dòng ZK/OP đua nhau tỏa sáng, hình thành sự đồng thuận trong ngành rằng ngắn hạn là OP, dài hạn là ZK, từ đó tạo nên bốn gã khổng lồ ARB/OP/zkSync/StarkNet.
Tính hiệu quả về mặt kinh tế là lý do quan trọng — thậm chí là duy nhất — khiến ZK được thế giới mã hóa, đặc biệt là hệ sinh thái Ethereum chấp nhận. Do đó, ở phần sau, tôi sẽ không đi sâu vào đặc điểm kỹ thuật của FHE, mà tập trung tìm hiểu FHE có thể cải thiện hiệu suất vận hành Web3 hay giảm chi phí vận hành Web3 ở những phương diện nào. Giảm chi phí hay tăng hiệu quả, ít nhất phải đạt được một trong hai điều này.
Lịch sử phát triển ngắn gọn và thành quả của FHE
Đầu tiên cần phân biệt mã hóa đồng dạng (homomorphic encryption) và mã hóa đồng dạng toàn phần (fully homomorphic encryption). Theo nghĩa nghiêm ngặt, mã hóa đồng dạng toàn phần là một trường hợp đặc biệt của loại trước. Mã hóa đồng dạng nghĩa là “việc tính toán cộng hoặc nhân trên văn bản mã hóa tương đương với cộng hoặc nhân trên văn bản gốc”, tức là:
Lúc này, c và E(c), d và E(d) có thể coi là tương đương về giá trị, nhưng cần lưu ý rằng ở đây có hai khó khăn:
-
Sự tương đương giữa văn bản gốc và mã hóa thực chất là thêm nhiễu vào văn bản gốc rồi thực hiện phép toán để tạo thành văn bản mã hóa. Nếu sai lệch do văn bản mã gây ra quá lớn sẽ dẫn đến thất bại tính toán, do đó then chốt nằm ở các thuật toán kiểm soát nhiễu;
-
Chi phí cho phép cộng và nhân rất cao, tính toán trên văn bản mã hóa có thể tốn kém gấp 10.000 đến 1 triệu lần trở lên so với tính toán trên văn bản gốc. Chỉ khi nào thực hiện được vô hạn phép cộng và nhân trên văn bản mã hóa thì mới được gọi là mã hóa đồng dạng toàn phần. Dù vậy, mỗi loại mã hóa đồng dạng đều có giá trị riêng trong lĩnh vực của nó. Căn cứ mức độ thực hiện, có thể phân loại như sau:
-
Mã hóa đồng dạng từng phần (Partially homomorphic encryption): chỉ cho phép thực hiện một tập thao tác giới hạn trên dữ liệu được mã hóa, như cộng hoặc nhân. Mã hóa đồng dạng một phần (Somewhat homomorphic encryption): cho phép số lượng giới hạn các phép cộng và nhân.
-
Mã hóa đồng dạng toàn phần (Fully homomorphic encryption): cho phép vô hạn phép cộng và nhân, từ đó thực hiện mọi tính toán trên dữ liệu được mã hóa.
Lịch sử phát triển của mã hóa đồng dạng toàn phần (FHE) có thể truy ngược về năm 2009, khi Craig Gentry lần đầu tiên đề xuất thuật toán FHE dựa trên lưới lý tưởng. Lưới lý tưởng là một cấu trúc toán học cho phép người dùng định nghĩa một tập các điểm trong không gian đa chiều, trong đó các điểm này thỏa mãn các quan hệ tuyến tính cụ thể.
Trong phương án của Gentry, lưới lý tưởng được dùng để biểu diễn khóa và dữ liệu mã hóa, nhờ đó dữ liệu mã hóa có thể giữ được quyền riêng tư, đồng thời dùng kỹ thuật bootstrap để giảm nhiễu. Bootstrap có thể hiểu nôm na là “tự giật dây giày mình lên”, thực tế là mã hóa lại một lần nữa văn bản mã đã được FHE mã hóa để giảm nhiễu và duy trì bảo mật, từ đó hỗ trợ các thao tác tính toán phức tạp.
(Bootstrap là bước tiến kỹ thuật rất quan trọng giúp FHE trở nên thực tiễn, nhưng kiến thức toán học sẽ không đi sâu thêm)
Thuật toán này là cột mốc của FHE, lần đầu tiên chứng minh khả thi về mặt kỹ thuật của FHE, nhưng chi phí rất lớn, thậm chí cần ba mươi phút mới thực hiện được một bước tính toán, hầu như không thể ứng dụng thực tế.
Sau khi giải quyết bài toán từ 0 đến 1, phần còn lại chỉ là hiện thực hóa quy mô lớn, cũng có thể hiểu là dựa trên các giả định toán học khác nhau để thiết kế thuật toán tương ứng. Ngoài lưới lý tưởng, LWE (Learning with Errors) và các biến thể của nó cũng được dùng làm giả định an toàn, hiện nay là phương án phổ biến nhất.
Năm 2012, Zvika Brakerski, Craig Gentry và Vinod Vaikuntanathan đưa ra phương án BGV, một trong những phương án FHE thế hệ thứ hai. Đóng góp quan trọng nhất là kỹ thuật chuyển đổi modulo, giúp kiểm soát hiệu quả sự gia tăng nhiễu trong tính toán đồng dạng, từ đó xây dựng Leveled FHE — tức là FHE loại này có thể thực hiện nhiệm vụ tính toán đồng dạng với độ sâu tính toán xác định trước.
Tương tự còn có các phương án BFV và CKKS, đặc biệt CKKS hỗ trợ tính toán dấu phẩy động, nhưng càng làm tăng tiêu thụ tài nguyên xử lý, vẫn cần những phương án tốt hơn.
Cuối cùng là các phương án TFHE và FHEW, đặc biệt TFHE là thuật toán ưu tiên của Zama, chúng ta sẽ giới thiệu sơ lược. Nói đơn giản, vấn đề nhiễu của FHE có thể được giảm bởi kỹ thuật bootstrap do Gentry lần đầu áp dụng, còn TFHE có thể thực hiện bootstrap hiệu quả và đảm bảo độ chính xác, do đó có điểm kết nối tốt với lĩnh vực blockchain.
Chúng tôi chỉ giới thiệu sơ qua các phương án, thực tế sự khác biệt giữa chúng không phải là tốt hay xấu, mà chủ yếu là phù hợp với các tình huống khác nhau. Tuy nhiên, cơ bản đều cần phần cứng-phần mềm mạnh mẽ hỗ trợ. Ngay cả với phương án TFHE, vẫn cần giải quyết vấn đề phần cứng mới có thể ứng dụng quy mô lớn, về cơ bản không thể đi theo con đường "thuật toán và phần mềm đi trước, phần cứng và mô-đun hóa theo sau" như trong lĩnh vực ZK. Nghĩa là ngay từ đầu, FHE phải phát triển đồng bộ với phần cứng, ít nhất trong lĩnh vực mã hóa thì chắc chắn như vậy.
Web2 OpenFHE vs Web3 Zama
Như đã nói, các ông lớn Web2 đang tích cực khám phá và đã tạo ra một số thành quả thực tiễn. Dưới đây là tổng kết và dẫn dắt vào ứng dụng trong Web3.
Loại bỏ rườm rà, IBM đóng góp thư viện Helib, chủ yếu hỗ trợ BGV và CKKS; thư viện SEAL của Microsoft chủ yếu hỗ trợ CKKS và BFV. Đáng chú ý, Song Yongsoo, một trong các tác giả CKKS, đã tham gia thiết kế và phát triển SEAL. OpenFHE là dự án tổng hợp đầy đủ nhất, do Duality được DARPA hỗ trợ phát triển, hiện nay hỗ trợ các thuật toán chính thống như BGV, BFV, CKKS, TFHE và FHEW, có lẽ là thư viện FHE hiện có đầy đủ nhất trên thị trường.
Hơn nữa, OpenFHE cũng từng thử hợp tác với thư viện tăng tốc CPU của Intel và gọi giao diện CUDA của NVIDIA để hỗ trợ tăng tốc GPU, tuy nhiên hỗ trợ CUDA cho FHE gần nhất dừng ở năm 2018, hiện chưa thấy cập nhật mới. Nếu có sai sót, mong được chỉ giáo.
OpenFHE hỗ trợ hai ngôn ngữ C++ và Python, API Rust đang được phát triển, đồng thời nỗ lực cung cấp khả năng mô-đun hóa đơn giản, toàn diện và đa nền tảng. Nếu bạn là nhà phát triển Web2, đây là lựa chọn dễ dùng nhất kiểu "mở hộp là chạy".
Nếu là nhà phát triển Web3 thì độ khó tăng lên vài bậc.
Do năng lực xử lý yếu ớt, phần lớn các chuỗi công khai không thể thực thi thuật toán FHE. Thứ hai, hệ sinh thái Bitcoin và Ethereum hiện thiếu "nhu cầu kinh tế" đối với FHE. Nhấn mạnh lại: chính vì có nhu cầu truyền dữ liệu hiệu quả từ L2 lên L1 nên mới thúc đẩy ứng dụng thuật toán ZK, chứ không thể làm FHE chỉ vì FHE — giống như cầm búa đi tìm đinh, ép buộc ghép nối chỉ làm tăng chi phí triển khai.
Nguyên lý hoạt động FHE+EVM
Phần sau sẽ trình bày chi tiết những khó khăn hiện tại và các kịch bản triển khai tiềm năng. Ở đây chủ yếu nhằm củng cố niềm tin cho các nhà phát triển Web3.
Năm 2024, Zama nhận được khoản tài trợ lớn nhất trong lĩnh vực mã hóa liên quan đến khái niệm FHE: 73 triệu USD do Multicoin dẫn dắt. Hiện tại Zama chủ yếu có thư viện dựa trên thuật toán TFHE, ngoài ra còn có fhEVM hỗ trợ phát triển chuỗi tương thích EVM có chức năng FHE.
Thứ hai là vấn đề hiệu suất. Điều này chỉ có thể giải quyết bằng hợp tác phần mềm-phần cứng. Một là EVM không thể trực tiếp chạy hợp đồng FHE, nhưng điều này không mâu thuẫn với phương án fhEVM của Zama. Zama tự xây dựng một chuỗi, có thể tích hợp sẵn chức năng FHE từ đầu. Ví dụ Shiba Inu cũng sẽ xây dựng Layer 3 dựa trên giải pháp Zama. Việc tạo chuỗi mới hỗ trợ FHE không khó, khó là EVM của Ethereum làm sao có khả năng triển khai hợp đồng FHE. Việc này cần sự hỗ trợ Opcode (mã vận hành) từ Ethereum. Tin tốt là Fair Math và OpenFHE đã tổ chức cuộc thi FHERMA, khuyến khích các nhà phát triển sửa đổi Opcode của EVM, đang tích cực khám phá khả năng kết hợp.
Một vấn đề khác là tăng tốc phần cứng. Có thể nói rằng, ngay cả các chuỗi công khai hiệu suất cao như Solana có hỗ trợ triển khai hợp đồng FHE, cũng sẽ làm sập các nút của nó. Phần cứng FHE gốc chủ yếu gồm 3PU™ (đơn vị xử lý bảo vệ quyền riêng tư) của Chain Reaction, thuộc loại ASIC; ngoài ra Zama hoặc Inco cũng đang khám phá khả năng tăng tốc phần cứng. Ví dụ hiện tại TPS của Zama khoảng 5, Inco đạt 10 TPS, và Inco cho rằng dùng FPGA tăng tốc phần cứng có thể nâng TPS lên khoảng 100-1000.
Tuy nhiên cũng không cần quá lo lắng về vấn đề tốc độ. Về lý thuyết, các giải pháp tăng tốc phần cứng ZK hiện có đều có thể được điều chỉnh để phù hợp với FHE. Do đó, trong phần thảo luận sau đây sẽ không quá chú trọng thiết kế tốc độ, mà chủ yếu tìm kiếm kịch bản và giải quyết vấn đề tương thích EVM.
Bể giao dịch tối đã tan, tương lai FHE X Crypto vẫn đáng kỳ vọng
Multicoin từng tuyên bố hùng hồn khi dẫn dắt tài trợ Zama rằng ZKP đã là quá khứ, tương lai thuộc về FHE. Liệu tương lai này có thành hiện thực? Thực tế luôn gian nan. Sau Zama, Inco Network và Fhenix đã hình thành liên minh vô hình cho hệ sinh thái fhEVM, mỗi bên tập trung vào hướng khác nhau nhưng con đường cơ bản giống nhau: cam kết kết hợp FHE với hệ sinh thái EVM.
Làm sớm không bằng đến đúng lúc, hãy bắt đầu bằng một gáo nước lạnh.
Năm 2024 có thể là năm bùng nổ của FHE, nhưng Elusiv khởi động từ năm 2022 đã ngừng hoạt động. Elusiv ban đầu là giao thức "bể giao dịch tối" trên Solana, hiện nay cả kho mã nguồn lẫn tài liệu đều đã bị xóa.
Tóm lại, FHE dù là một thành phần kỹ thuật, vẫn cần được sử dụng cùng các công nghệ như MPC/ZKP. Chúng ta cần khảo sát xem FHE thực sự có thể thay đổi khuôn mẫu hiện tại của blockchain ở những phương diện nào.
Trước hết cần thừa nhận rằng, cho rằng đơn thuần FHE tăng cường quyền riêng tư nên có giá trị kinh tế là không chính xác. Nhìn lại thực tiễn quá khứ, người dùng Web3 hay trên chuỗi không quá quan tâm đến quyền riêng tư. Họ chỉ sử dụng các công cụ liên quan khi quyền riêng tư mang lại giá trị kinh tế. Ví dụ, tin tặc chỉ dùng Tornado Cash để che giấu tiền ăn cắp, còn người dùng bình thường chỉ dùng Uniswap, vì dùng Tornado Cash phải trả thêm chi phí thời gian hoặc kinh tế.
Chi phí mã hóa của FHE bản thân nó đã là sự tra tấn thêm đối với hiệu suất vận hành vốn đã yếu ớt trên chuỗi. Chỉ khi việc tăng chi phí này mang lại lợi ích nổi bật hơn thì việc bảo vệ quyền riêng tư mới có khả năng lan rộng quy mô lớn, ví dụ như phát hành và giao dịch trái phiếu trong hướng RWA. Chẳng hạn tháng 6 năm 2023, BOC International thông qua UBS đã phát hành "giấy tờ cấu trúc kỹ thuật số trên blockchain" cho khách hàng châu Á - Thái Bình Dương tại Hồng Kông, và trong bản tin của UBS nêu rõ là thực hiện qua Ethereum. Nhưng kỳ lạ là không thể tìm thấy địa chỉ hợp đồng và địa chỉ phân phối của giao dịch này. Nếu ai tìm được, xin bổ sung thông tin.
Ví dụ này có thể minh họa rõ tầm quan trọng của FHE: Đối với khách hàng cấp tổ chức, họ có nhu cầu sử dụng blockchain hay chuỗi công khai, nhưng không phù hợp hoặc không muốn công khai toàn bộ thông tin. Trong trường hợp này, đặc tính của FHE — hiển thị dưới dạng văn bản mã hóa nhưng vẫn có thể trực tiếp thực hiện các thao tác mua bán — sẽ phù hợp hơn ZKP.
Còn đối với nhà đầu tư cá nhân nhỏ lẻ, FHE hiện vẫn là hạ tầng nền tảng khá xa vời. Tôi có thể liệt kê vài hướng như chống MEV, giao dịch riêng tư, mạng an toàn hơn, ngăn chặn bên thứ ba dò xét... nhưng rõ ràng đây không phải nhu cầu cấp thiết. Hơn nữa, hiện tại dùng FHE thực sự làm chậm mạng, nên nói thẳng ra là thời điểm FHE làm chủ chưa đến.
Tóm lại, quyền riêng tư là nhu cầu không đau không ngứa. Là dịch vụ công cộng, rất ít người sẵn sàng trả phí cao hơn cho quyền riêng tư. Chúng ta cần tìm những kịch bản mà đặc tính dữ liệu có thể tính toán sau khi mã hóa bằng FHE có thể tiết kiệm chi phí hoặc nâng cao hiệu quả giao dịch, từ đó tạo ra lực đẩy tự phát từ thị trường. Ví dụ có nhiều giải pháp chống MEV, chẳng hạn nút tập trung thực ra có thể giải quyết, FHE không thể chạm đúng vào điểm đau của kịch bản.
Một vấn đề khác là hiệu suất tính toán. Nhìn bề ngoài đây là vấn đề kỹ thuật cần tăng tốc phần cứng hoặc tối ưu thuật toán, nhưng bản chất là thị trường chưa có nhu cầu lớn, các dự án không có động lực cạnh tranh. Hiệu suất tính toán rốt cuộc đều do cạnh tranh mà ra. Lấy ZK làm ví dụ: dưới sức ép nhu cầu thị trường sôi động, các tuyến SNARK và STARK đua nhau, các ZK Rollup từ ngôn ngữ lập trình đến tính tương thích thi nhau "卷" (căng sức), sự phát triển của ZK dưới tác động của dòng tiền nóng thật sự nhanh như tên bay.
Ứng dụng thực tế và triển khai là điểm đột phá để FHE trở thành hạ tầng blockchain. Nếu không迈过这一步 (vượt qua bước này), FHE sẽ mãi không thể tạo thế lực trong ngành mã hóa, các dự án chỉ có thể gõ trống bên lề, tự vui vẻ trong mảnh đất ba phần sào của mình.
Từ thực tiễn của Zama và những người bạn, một sự đồng thuận là xây chuỗi mới bên ngoài Ethereum, tái sử dụng các thành phần kỹ thuật và tiêu chuẩn như ERC-20 lên đó, tạo thành giải pháp mã hóa FHE L1/L2 kết nối với Ethereum. Lợi thế của phương án này là có thể thí điểm trước, xây dựng các thành phần nền tảng FHE. Nhược điểm là nếu bản thân Ethereum không hỗ trợ thuật toán FHE, các phương án ngoài chuỗi sẽ luôn ở trong tình thế khá ngại ngùng.
Zama cũng nhận thức được vấn đề này, ngoài các thư viện liên quan FHE đã nhắc đến, còn sáng lập tổ chức FHE.org và tài trợ các hội nghị liên quan, hy vọng chuyển đổi nhiều thành quả học thuật hơn thành ứng dụng kỹ thuật.
Hướng phát triển của Inco Network là "lớp tính toán riêng tư tổng quát", về bản chất là mô hình nhà cung cấp dịch vụ tính toán thuê ngoài. Dựa trên Zama, họ xây dựng mạng FHE EVM L1. Một khám phá thú vị là hợp tác với giao thức tin nhắn xuyên chuỗi Hyperlane, có thể triển khai cơ chế trò chơi từ một chuỗi EVM tương thích khác lên Inco. Khi trò chơi cần tính toán FHE, thông qua Hyperlane gọi năng lực tính toán của Inco, sau đó chỉ gửi kết quả về chuỗi gốc.
Để hiện thực hóa các kịch bản như mong đợi của Inco, cần đáp ứng hai điều kiện: chuỗi EVM tương thích phải tin tưởng vào uy tín của Inco, và bản thân năng lực tính toán của Inco phải đủ mạnh. Với yêu cầu đồng thời cao và độ trễ thấp trong game trên chuỗi, liệu có thể vận hành tốt thực sự là một thách thức lớn.
Từ đó mở rộng ra, một số zkVM thực ra cũng có thể đảm nhận vai trò nhà cung cấp tính toán FHE, ví dụ RISC Zero đã có khả năng này. Những va chạm tiếp theo giữa sản phẩm dòng ZK và FHE có thể bùng nổ thêm nhiều tia lửa.
Hơn nữa, một số dự án hy vọng có thể tiến gần hơn tới Ethereum, ít nhất là theo hướng trở thành một phần của Ethereum. Nếu Inco có thể dùng giải pháp Zama để tạo L1, thì Fhenix có thể dùng giải pháp Zama để tạo EVM L2. Dự án này vẫn đang phát triển, dường như muốn làm nhiều hướng, chưa biết sản phẩm cuối cùng sẽ là gì, có lẽ là một L2 chuyên về khả năng FHE.
Ngoài ra còn có cuộc thi FHERMA đã nhắc đến, các lập trình viên am hiểu phát triển Ethereum có thể thử sức, vừa giúp FHE triển khai vừa có thưởng.
Ngoài ra còn có hai dự án khá kỳ lạ là Sunscreen và Mind Network. Sunscreen chủ yếu do Ravital vận hành một mình, hướng đi là dùng thuật toán BFV để tạo trình biên dịch phù hợp FHE, nhưng lâu nay chỉ ở trạng thái thử nghiệm, còn cách sản phẩm thực tế hóa một khoảng thời gian.
Cuối cùng, hướng đi của Mind Network tập trung chủ yếu vào việc kết hợp FHE với các kịch bản hiện có như re-staking, nhưng cụ thể thực hiện ra sao còn cần thời gian kiểm chứng.
Cuối cùng cùng, quay lại phần mở đầu của mục này: Elusiv hiện nay đổi tên thành Arcium, còn nhận được tài trợ mới, chuyển hướng thành giải pháp "FHE song song", đây là nỗ lực cải thiện hiệu suất thực thi FHE.
Kết luận
Bài viết này thoạt nhìn là nói về lý luận và thực tiễn của FHE, nhưng ẩn tuyến là làm rõ lịch sử phát triển riêng của công nghệ mã hóa, không hoàn toàn đồng nghĩa với công nghệ dùng trong tiền mã hóa. ZKP và FHE có nhiều điểm tương đồng, một trong số đó là đều nỗ lực để blockchain ngoài đặc tính công khai còn có thiết kế riêng tư. Trong khi giải pháp riêng tư ZKP hướng đến giảm chi phí kinh tế tương tác giữa L2 và L1, thì FHE vẫn đang tìm kiếm kịch bản tốt nhất cho chính mình.
Phân loại các giải pháp
Đường còn dài và gian nan, FHE vẫn đang miệt mài tìm kiếm. Có thể chia thành ba dạng theo mức độ liên kết với Ethereum:
-
Dạng 1: Vương quốc độc lập, giao tiếp với Ethereum. Đại diện là Zama/Fhenix/Inco network, chủ yếu cung cấp các thành phần phát triển nền tảng, khuyến khích tự xây FHE L1/L2, phù hợp với một số lĩnh vực chuyên biệt;
-
Dạng 2: Phụ kiện gắn ngoài, hòa nhập vào Ethereum. Đại diện là Fair Math/Mind Network, tuy giữ một mức độ độc lập nhất định nhưng tư duy tổng thể là tích hợp sâu hơn với Ethereum.
-
Dạng 3: Cùng tiến bước, cải tạo Ethereum. Nếu Ethereum không thể hỗ trợ nguyên bản chức năng FHE, cần khám phá ở tầng hợp đồng, phát tán chức năng FHE đến các chuỗi tương thích EVM. Hiện chưa có giải pháp nào thực sự phù hợp tiêu chuẩn này.
Khác với ZK chỉ đến giai đoạn sau mới xuất hiện giải pháp "tạo chuỗi một cú nhấp" và tăng tốc phần cứng thực tế hóa, FHE đang đứng trên vai người khổng lồ ZK. Hiện tại tạo một chuỗi FHE có lẽ là việc đơn giản nhất, nhưng khó nhất là làm sao giao tiếp với Ethereum.
Hằng ngày tự vấn ba điều, tìm tọa độ tương lai của FHE trong thế giới blockchain:
-
Kịch bản nào buộc phải mã hóa, không thể dùng văn bản rõ?
-
Kịch bản nào cần mã hóa FHE, không thể dùng phương pháp mã hóa khác?
-
Kịch bản nào sau khi dùng mã hóa FHE, người dùng cảm thấy hài lòng, sẵn sàng trả phí cao hơn?
Câu chuyện chưa kết thúc, tôi sẽ tiếp tục theo dõi FHE!
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
@zuoyeweb3
