Mở rộng công nghệ: Tổng quan về nguyên lý và các trường hợp ứng dụng tiềm năng của zkTLS
Tuyển chọn TechFlowTuyển chọn TechFlow
Mở rộng công nghệ: Tổng quan về nguyên lý và các trường hợp ứng dụng tiềm năng của zkTLS
Lợi ích lớn nhất của zkTLS là giảm chi phí để đạt được khả năng sử dụng các tài nguyên HTTPS Web2.
Chuyên sâu báo cáo Web3Tác giả:@Web3_Mario
Tóm tắt：Gần đây tôi đang tìm kiếm các hướng dự án mới, khi thiết kế sản phẩm đã gặp phải một stack công nghệ trước đó chưa từng tiếp xúc, nên đã tiến hành nghiên cứu và tổng hợp lại những hiểu biết thu được, xin chia sẻ cùng mọi người.
Nhìn chung, zkTLS là một công nghệ mới kết hợp giữa bằng chứng kiến thức không (ZKP) và giao thức TLS (giao thức bảo mật tầng truyền tải), chủ yếu được dùng trong lĩnh vực Web3 để xác minh tính xác thực của dữ liệu HTTPS bên ngoài chuỗi do một môi trường máy ảo trên chuỗi cung cấp mà không cần tin tưởng bên thứ ba. Tính xác thực ở đây bao gồm ba khía cạnh: nguồn dữ liệu thực sự đến từ một tài nguyên HTTPS nhất định, dữ liệu trả về chưa bị thay đổi và tính cập nhật của dữ liệu có thể được đảm bảo.
Thông qua cơ chế mật mã học này, hợp đồng thông minh trên chuỗi có khả năng truy cập đáng tin cậy vào tài nguyên Web2 HTTPS bên ngoài chuỗi, phá vỡ hiện tượng "đảo dữ liệu".
Protocol TLS là gì
Để hiểu sâu sắc hơn giá trị của công nghệ zkTLS, cần tóm tắt sơ lược về giao thức TLS. Trước hết, TLS (giao thức bảo mật tầng truyền tải) được dùng để cung cấp mã hóa, xác thực và toàn vẹn dữ liệu trong truyền thông mạng, đảm bảo việc truyền tải dữ liệu an toàn giữa phía khách hàng (ví dụ trình duyệt) và máy chủ (ví dụ website). Những bạn không chuyên về phát triển mạng có thể nhận thấy khi truy cập website, một số tên miền bắt đầu bằng tiền tố https, một số khác thì dùng http. Khi truy cập vào loại sau, các trình duyệt chính đều cảnh báo là không an toàn. Loại trước thì thường gặp thông báo như “Kết nối của bạn không riêng tư” hoặc lỗi chứng chỉ HTTPS. Nguyên nhân của những cảnh báo này nằm ở tính khả dụng của giao thức TLS.
Cụ thể, giao thức HTTPS thực chất là giao thức HTTP sử dụng TLS để đảm bảo tính riêng tư và toàn vẹn của thông tin truyền tải, đồng thời làm cho tính xác thực của phía máy chủ trở nên có thể kiểm chứng. Chúng ta biết rằng, giao thức HTTP là giao thức truyền tải văn bản rõ, và không thể xác minh tính xác thực của phía máy chủ, điều này dẫn đến một vài vấn đề an ninh:
1. Thông tin truyền giữa bạn và máy chủ có thể bị bên thứ ba nghe lén, gây rò rỉ thông tin cá nhân;
2. Bạn không thể xác minh tính xác thực của máy chủ, nghĩa là yêu cầu của bạn có thể bị một nút độc hại nào đó đánh cắp và trả về thông tin ác ý;
3. Bạn không thể xác minh tính toàn vẹn của thông tin trả về, tức là có khả năng dữ liệu bị mất do vấn đề mạng;
Mà giao thức TLS chính là được thiết kế để giải quyết những vấn đề này. Xin giải thích thêm, một số bạn có thể biết giao thức SSL, thực ra TLS là phiên bản phát triển từ SSL 3.1, chỉ vì một số lý do thương mại mà đổi tên, nhưng thực chất là kế thừa trực tiếp. Do đó, đôi khi trong một số ngữ cảnh, hai thuật ngữ này có thể dùng thay thế nhau.
Ý tưởng chính để TLS giải quyết các vấn đề trên là:
1. Mã hóa truyền thông: sử dụng mã hóa đối xứng (AES, ChaCha20) để bảo vệ dữ liệu, ngăn chặn việc nghe lén.
2. Xác thực danh tính: thông qua chứng chỉ số do bên thứ ba cấp cho tổ chức cụ thể (như chứng chỉ X.509) để xác minh danh tính máy chủ, ngăn chặn tấn công trung gian (MITM).
3. Toàn vẹn dữ liệu: sử dụng HMAC (mã xác thực tin nhắn băm) hoặc AEAD (mã hóa xác thực) để đảm bảo dữ liệu chưa bị thay đổi.
Chúng ta sẽ giải thích ngắn gọn chi tiết kỹ thuật của giao thức HTTPS dựa trên TLS trong quá trình trao đổi dữ liệu. Cả quá trình gồm hai giai đoạn: trước tiên là giai đoạn bắt tay (Handshake), tức là phía khách hàng và máy chủ thỏa thuận các tham số bảo mật và thiết lập phiên mã hóa. Thứ hai là giai đoạn truyền dữ liệu, tức là sử dụng khóa phiên để truyền thông được mã hóa. Quá trình cụ thể gồm bốn bước:
1. Phía khách hàng gửi ClientHello:
Phía khách hàng (ví dụ trình duyệt) gửi tin nhắn ClientHello đến máy chủ, nội dung bao gồm:
l Phiên bản TLS hỗ trợ (ví dụ TLS 1.3)
l Các thuật toán mã hóa hỗ trợ (Cipher Suites, ví dụ AES-GCM, ChaCha20)
l Số ngẫu nhiên (Client Random) (dùng để tạo khóa)
l Tham số chia sẻ khóa (ví dụ khóa công khai ECDHE)
l SNI (chỉ thị tên máy chủ) (tùy chọn, dùng để hỗ trợ HTTPS đa tên miền)
Mục đích là để máy chủ biết được khả năng mã hóa của phía khách hàng và chuẩn bị các tham số bảo mật.
2. Máy chủ gửi ServerHello:
Máy chủ phản hồi bằng tin nhắn ServerHello, nội dung bao gồm:
l Thuật toán mã hóa được chọn
l Số ngẫu nhiên máy chủ (Server Random)
l Chứng chỉ máy chủ (chứng chỉ X.509)
l Tham số chia sẻ khóa máy chủ (ví dụ khóa công khai ECDHE)
l Tin nhắn Finished (dùng để xác nhận hoàn tất bắt tay)
Mục đích là để phía khách hàng biết danh tính máy chủ và xác nhận các tham số bảo mật.
3. Phía khách hàng xác minh máy chủ:
Phía khách hàng thực hiện các thao tác sau:
l Xác minh chứng chỉ máy chủ: đảm bảo chứng chỉ do CA (tổ chức cấp chứng chỉ) tin cậy cấp, đồng thời kiểm tra chứng chỉ có hết hạn hay bị thu hồi không;
l Tính toán khóa chia sẻ: sử dụng khóa công khai ECDHE của mình và máy chủ để tính ra khóa phiên (Session Key), khóa này dùng cho mã hóa đối xứng (ví dụ AES-GCM) trong truyền thông sau này.
l Gửi tin nhắn Finished: chứng minh tính toàn vẹn dữ liệu bắt tay, ngăn chặn tấn công trung gian (MITM).
Mục đích là đảm bảo máy chủ đáng tin cậy và tạo ra khóa phiên.
4. Bắt đầu truyền thông được mã hóa:
Phía khách hàng và máy chủ hiện tại sử dụng khóa phiên đã thỏa thuận để truyền thông được mã hóa.
l Sử dụng mã hóa đối xứng (ví dụ AES-GCM, ChaCha20) để mã hóa dữ liệu, nâng cao tốc độ và độ an toàn.
l Bảo vệ tính toàn vẹn dữ liệu: sử dụng AEAD (ví dụ AES-GCM) để ngăn chặn việc thay đổi.
Vì vậy, sau bốn bước này, có thể hiệu quả giải quyết các vấn đề của giao thức HTTP. Tuy nhiên, công nghệ nền tảng này vốn phổ biến trong mạng Web2 lại gây khó khăn cho việc phát triển ứng dụng Web3, đặc biệt khi hợp đồng thông minh trên chuỗi muốn truy cập một số dữ liệu bên ngoài chuỗi, do vấn đề khả dụng dữ liệu, máy ảo trên chuỗi sẽ không mở chức năng gọi dữ liệu bên ngoài nhằm đảm bảo khả năng truy xuất mọi dữ liệu, từ đó đảm bảo an toàn cơ chế đồng thuận.
Tuy nhiên, sau một loạt cải tiến, các nhà phát triển nhận thấy DApp vẫn có nhu cầu về dữ liệu bên ngoài chuỗi, do đó một loạt dự án Oracle (dự báo) xuất hiện, ví dụ Chainlink và Pyth. Họ đóng vai trò cầu nối trung chuyển giữa dữ liệu trên chuỗi và bên ngoài chuỗi, phá vỡ hiện tượng "đảo dữ liệu". Đồng thời để đảm bảo tính khả dụng của dữ liệu trung chuyển, các Oracle này thường sử dụng cơ chế đồng thuận PoS, khiến chi phí hành vi sai trái của nút trung chuyển cao hơn lợi ích, từ góc độ kinh tế họ sẽ không cung cấp thông tin sai lên chuỗi. Ví dụ, nếu chúng ta muốn truy cập giá trung bình trọng số của BTC trên các sàn giao dịch tập trung như Binance, Coinbase trong hợp đồng thông minh, thì cần nhờ các Oracle này truy cập, tổng hợp dữ liệu bên ngoài chuỗi rồi truyền lên lưu trữ trong hợp đồng thông minh trên chuỗi mới sử dụng được.
zkTLS giải quyết vấn đề gì
Tuy nhiên, người ta nhận thấy phương án lấy dữ liệu dựa trên Oracle này tồn tại hai vấn đề:
1. Chi phí quá cao: để đảm bảo dữ liệu Oracle truyền lên chuỗi là dữ liệu thật, chưa bị thay đổi, cần đảm bảo bằng cơ chế đồng thuận PoS. Nhưng tính an toàn của cơ chế PoS dựa trên lượng tiền ký quỹ, điều này gây ra chi phí duy trì. Hơn nữa, trong cơ chế PoS thường tồn tại lượng lớn dư thừa tương tác dữ liệu, vì khi tập dữ liệu cần được truyền, tính toán, tổng hợp lặp lại nhiều lần trong mạng mới đạt được đồng thuận, điều này làm tăng chi phí sử dụng dữ liệu. Vì vậy, thường thì các dự án Oracle để thu hút khách hàng chỉ miễn phí duy trì một số dữ liệu chủ đạo nhất, ví dụ giá tài sản chủ đạo như BTC. Còn với nhu cầu riêng biệt thì cần trả phí. Điều này cản trở đổi mới ứng dụng, đặc biệt với các nhu cầu đuôi dài, tùy chỉnh.
2. Hiệu suất quá thấp: thông thường, đồng thuận cơ chế PoS cần một khoảng thời gian nhất định, gây ra độ trễ dữ liệu trên chuỗi, điều này bất lợi cho các tình huống sử dụng truy cập tần suất cao, vì dữ liệu trên chuỗi nhận được có độ trễ lớn so với dữ liệu thật bên ngoài chuỗi.
Để giải quyết các vấn đề trên, công nghệ zkTLS ra đời. Ý tưởng chính là thông qua việc đưa vào thuật toán ZKP (bằng chứng kiến thức không), cho phép hợp đồng thông minh trên chuỗi đóng vai trò bên thứ ba trực tiếp xác minh dữ liệu do một nút cung cấp thực sự là dữ liệu trả về sau khi truy cập một tài nguyên HTTPS nào đó và chưa bị thay đổi, từ đó tránh được chi phí sử dụng cao do cơ chế đồng thuận của Oracle truyền thống gây ra.
Một số bạn có thể hỏi tại sao không tích hợp trực tiếp khả năng gọi API Web2 vào môi trường VM trên chuỗi. Câu trả lời là không thể, bởi vì lý do môi trường trên chuỗi cần giữ dữ liệu khép kín là để đảm bảo khả năng truy xuất mọi dữ liệu, tức là trong quá trình đồng thuận, mọi nút đều có logic đánh giá thống nhất về tính chính xác của một dữ liệu hay kết quả thực thi nào đó, nói cách khác là một logic xác minh khách quan. Điều này đảm bảo trong môi trường hoàn toàn không tin tưởng, đa số nút thiện chí có thể dựa vào phán đoán dư thừa dữ liệu của riêng mình để trực tiếp xác định đúng sai. Nhưng với dữ liệu Web2, rất khó xây dựng logic đánh giá thống nhất này, vì có thể do một số nguyên nhân trễ mạng, các nút khác nhau truy cập tài nguyên HTTPS Web2 thu được kết quả khác nhau, điều này làm khó cho đồng thuận, đặc biệt trong các lĩnh vực dữ liệu tần suất cao. Ngoài ra, một vấn đề then chốt khác là tính an toàn của giao thức TLS phụ thuộc vào số ngẫu nhiên do phía khách hàng tạo (Client Random) (dùng để tạo khóa) và tham số chia sẻ khóa, nhằm đàm phán khóa mã hóa với phía máy chủ. Nhưng chúng ta biết môi trường trên chuỗi là công khai minh bạch, nếu để hợp đồng thông minh quản lý số ngẫu nhiên và tham số chia sẻ khóa, dữ liệu quan trọng sẽ bị lộ, làm tổn hại đến tính riêng tư dữ liệu.
zkTLS sử dụng một phương pháp khác, ý tưởng là thông qua bảo vệ mật mã học thay thế chi phí cao để đạt tính khả dụng dữ liệu của Oracle truyền thống dựa trên cơ chế đồng thuận, tương tự như ZK-Rollup tối ưu OP-Rollup trong L2. Cụ thể, bằng cách đưa vào ZKP (bằng chứng kiến thức không), tính toán Proof từ tài nguyên HTTPS mà nút trung chuyển bên ngoài chuỗi yêu cầu, thông tin xác minh chứng chỉ CA liên quan, bằng chứng tuần tự và bằng chứng toàn vẹn dữ liệu dựa trên HMAC hoặc AEAD, đồng thời duy trì trên chuỗi các thông tin xác minh cần thiết cùng thuật toán xác minh, cho phép hợp đồng thông minh xác minh tính xác thực, tính cập nhật và độ tin cậy nguồn dữ liệu mà không làm lộ thông tin quan trọng. Chi tiết thuật toán cụ thể ở đây không bàn luận, bạn nào quan tâm có thể tự nghiên cứu sâu hơn.
Lợi ích lớn nhất của phương án công nghệ này là giảm chi phí để đạt tính khả dụng của tài nguyên HTTPS Web2. Điều này khơi dậy nhiều nhu cầu mới, đặc biệt trong việc giảm chi phí lấy giá tài sản đuôi dài trên chuỗi, sử dụng các website uy tín trong thế giới Web2 để thực hiện KYC trên chuỗi, từ đó tối ưu hóa thiết kế kiến trúc công nghệ DID, Web3 Game... Tất nhiên, chúng ta cũng thấy rằng zkTLS gây ảnh hưởng nhất định đến các doanh nghiệp Web3 hiện tại, đặc biệt với các dự án Oracle chủ đạo hiện nay. Vì vậy, để đối phó với ảnh hưởng này, các ông lớn ngành như Chainlink, Pyth tích cực theo dõi nghiên cứu liên quan, cố gắng duy trì vị thế dẫn đầu trong quá trình cải tiến công nghệ, đồng thời thúc đẩy hình thành mô hình kinh doanh mới, ví dụ chuyển từ thu phí theo thời gian sang thu phí theo mức sử dụng, Compute as a service... Tất nhiên điểm khó ở đây giống như phần lớn các dự án ZK, vẫn là làm sao giảm chi phí tính toán để đạt giá trị thương mại.
Tóm lại, khi các bạn thiết kế sản phẩm, cũng có thể chú ý động thái phát triển của zkTLS và tích hợp stack công nghệ này ở những khía cạnh phù hợp, có thể tìm thấy một số hướng mới trong đổi mới kinh doanh và kiến trúc công nghệ.
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
@web3_mario
