a16z: Luận về tính bất khả thi của "blockchain không trạng thái"
Tuyển chọn TechFlowTuyển chọn TechFlow
a16z: Luận về tính bất khả thi của "blockchain không trạng thái"
Trạng thái không biến mất, mà được chuyển ra khỏi tay người xác thực và đẩy tới người dùng dưới dạng các bản cập nhật chứng nhận thường xuyên.
Chuyên sâu báo cáo Web3Tác giả: Miranda Christ, Joseph Bonneau
Biên dịch: TechFlow
Khi blockchain hỗ trợ ngày càng nhiều người dùng và giao dịch thường xuyên hơn, lượng thông tin mà các bộ xác thực cần lưu trữ để kiểm tra giao dịch (tức là “trạng thái”) cũng tăng lên. Ví dụ, trong Bitcoin, trạng thái bao gồm tập hợp các đầu ra giao dịch chưa được chi tiêu (UTXO). Trong Ethereum, trạng thái bao gồm số dư tài khoản của từng người dùng cùng với mã và dữ liệu lưu trữ của mỗi hợp đồng thông minh.
Khi blockchain phát triển đủ lớn để hỗ trợ một phần đáng kể các giao dịch hàng ngày thực sự trong dân số, gánh nặng lưu trữ này sẽ trở nên khó kiểm soát, khiến việc trở thành bộ xác thực trở nên khó khăn và đe dọa đến tính phi tập trung. Một giải pháp hấp dẫn là chuyển sang sử dụng mật mã học, nơi các công cụ như cây Merkle và bằng chứng không kiến thức giúp chúng ta đạt được những điều trước đây tưởng chừng không thể.
Đây chính là mục tiêu của “blockchain không trạng thái”. Tuy nhiên, dù đã có rất nhiều nghiên cứu, các hệ thống này vẫn còn xa mới đạt được tính khả thi trong thực tế. Nhưng hóa ra, sự chậm trễ này là bản chất cố hữu — khoảng cách giữa xây dựng và tính khả dụng sẽ luôn tồn tại mãi mãi. Công trình gần đây của chúng tôi cho thấy rằng nếu không có các biện pháp bổ sung để quản lý trạng thái, mọi phương án blockchain không trạng thái, dù thông minh đến đâu, đều không khả thi. Tuy nhiên, như chúng tôi sẽ chỉ ra ở cuối bài viết, kết quả bất khả thi này không nên làm nản lòng.
Không trạng thái
Ngày nay, trạng thái tuy lớn nhưng vẫn kiểm soát được. Ví dụ, một nút Bitcoin lưu trữ khoảng 7 GB dữ liệu, trong khi một nút Ethereum lưu trữ khoảng 650 GB. Tuy nhiên, gánh nặng lưu trữ của nút đầy đủ tăng xấp xỉ tuyến tính theo thông lượng của chuỗi (số giao dịch mỗi giây hay TPS), trong khi thông lượng hiện tại vẫn chưa chấp nhận được. Theo thiết kế hiện tại, trạng thái cần thiết để thực sự hỗ trợ các giao dịch hàng ngày (vài chục nghìn đến vài trăm nghìn TPS) sẽ trở nên khó kiểm soát, đòi hỏi dung lượng lưu trữ lên tới gigabyte hoặc thậm chí petabyte.
Điều này thúc đẩy việc tìm kiếm các giải pháp kỹ thuật nhằm giảm đáng kể lượng trạng thái mà các bộ xác thực cần lưu trữ. Mấu chốt là đạt được blockchain không trạng thái, nghĩa là yêu cầu các bộ xác thực chỉ cần lưu trữ một lượng trạng thái có kích thước hằng định, bất kể thông lượng giao dịch (thực tế, thuật ngữ này hơi sai lệch: vẫn tồn tại trạng thái, nhưng nhỏ đến mức có thể duy trì tính thực tiễn ở mọi thông lượng tương lai — thường là kích thước cố định). Yêu cầu lưu trữ nhẹ nhàng như vậy sẽ khiến việc vận hành nút xác thực dễ dàng hơn nhiều; lạc quan hơn, mọi người đều có thể chạy một nút trên điện thoại di động của mình. Vì tăng số lượng bộ xác thực sẽ nâng cao độ an toàn của chuỗi, nên hạ thấp rào cản tham gia là rất quan trọng.
Mặc dù đã có rất nhiều nghiên cứu về blockchain không trạng thái (ví dụ, các công trình bởi Todd, Buterin, Boneh và cộng sự, Srinivasan và cộng sự), nhưng chúng vẫn còn rất xa so với thực tiễn, và theo hiểu biết của chúng tôi, chưa có hệ thống nào được triển khai. Vấn đề cốt lõi của mọi blockchain không trạng thái đã biết là chúng yêu cầu người dùng lưu trữ dữ liệu phụ trợ gọi là "bằng chứng" (witness), để giúp các bộ xác thực kiểm tra các giao dịch liên quan đến tài khoản của họ. Ví dụ, bằng chứng này có thể là một chứng minh bao hàm Merkle, cho thấy tài khoản và số dư của người dùng nằm trong lời hứa trạng thái toàn cục. Khi người dùng thực hiện giao dịch, họ gửi kèm bằng chứng này cho bộ xác thực để chứng minh tài khoản của họ có đủ số dư.
Khác với việc lưu trữ khóa riêng — thứ không bao giờ cần thay đổi — các bằng chứng này thay đổi thường xuyên, ngay cả với những người dùng không thực hiện giao dịch, gây ra gánh nặng không thực tế cho người dùng. Tương tự như việc bạn phải liên tục theo dõi tất cả các giao dịch thẻ tín dụng khác trên toàn thế giới và cập nhật dữ liệu cục bộ để có thể sử dụng thẻ của mình. Để blockchain trở nên thực dụng, người dùng phải có thể ngoại tuyến và chỉ tương tác với blockchain khi gửi giao dịch. Trong nhiều trường hợp, ví dụ như ví phần cứng, việc cập nhật bằng chứng không chỉ bất tiện mà còn hoàn toàn không thể.
Điều này dẫn chúng tôi đến một câu hỏi nghiên cứu tự nhiên: Liệu có thể xây dựng một blockchain không trạng thái mà người dùng không cần cập nhật bằng chứng thường xuyên (hoặc chỉ cần rất ít lần)? Để trả lời câu hỏi này, chúng tôi phát triển một khuôn khổ lý thuyết mới (hệ thống bằng chứng có thể thu hồi), tổng quát hóa blockchain không trạng thái. Sử dụng khuôn khổ này, chúng tôi chứng minh một kết quả bất khả thi: sự đánh đổi giữa trạng thái toàn cục ngắn gọn và việc cập nhật bằng chứng thường xuyên về bản chất là cực kỳ khó điều hòa. Kỹ thuật chứng minh của chúng tôi mang tính lý thuyết thông tin, nghĩa là ngay cả máy tính tương lai cũng không đủ sức giải quyết vấn đề này: khoảng cách giữa cấu trúc blockchain không trạng thái và tính khả dụng sẽ mãi mãi không thể thu hẹp.
Bối cảnh nghiên cứu của chúng tôi
Để giúp hiểu rõ kết quả bất khả thi của chúng tôi, trước tiên chúng tôi mô tả một phương pháp tự nhiên nhưng kém hiệu quả để xây dựng blockchain không trạng thái bằng cây Merkle. Mục tiêu là cho phép các bộ xác thực xác định được giao dịch do người dùng gửi có hợp lệ hay không — ví dụ, người dùng có đủ số dư tài khoản để thực hiện giao dịch hay không. Trong một phương án blockchain không trạng thái, các bộ xác thực lưu trữ một trạng thái có kích thước hằng định. Khi người dùng thực hiện giao dịch, họ phải đưa bằng chứng vào giao dịch. Các bộ xác thực có thể sử dụng trạng thái hiện tại và cặp (giao dịch, bằng chứng) do người dùng gửi để kiểm tra xem người dùng có đủ số dư hay không.
Trước tiên, chúng tôi xây dựng một cây Merkle, trong đó mỗi cặp (ID tài khoản, số dư) (a, b) được đưa vào dưới dạng nút lá. Trạng thái cố định V mà các bộ xác thực lưu trữ chính là gốc của cây này, đóng vai trò là lời hứa về tập hợp các cặp số dư tài khoản. Mỗi người dùng duy trì bằng chứng của mình dưới dạng chứng minh bao hàm Merkle. Chứng minh bao hàm Merkle của một nút lá (a, b) bao gồm các nút anh em trên đường đi từ nút lá đến gốc cây (v1, ..., vk). Với một giao dịch do tài khoản a thực hiện và tuyên bố số dư b, bộ xác thực có thể kiểm tra xem b có đúng là số dư hiện tại của tài khoản a hay không bằng cách xác minh chứng minh (v1, ..., vk) với trạng thái hiện tại V. Nếu đúng, bộ xác thực thực hiện giao dịch và cập nhật số dư tương ứng. Một thuộc tính thuận tiện của cây Merkle là, với chứng minh bao hàm của một nút lá, việc tính toán gốc mới sau khi nút lá thay đổi là rất dễ dàng. Nói cách khác, bộ xác thực có thể dễ dàng tính ra trạng thái mới V', phản ánh số dư mới của tài khoản a sau giao dịch.
Phương án cây Merkle này có hai nhược điểm chính. Thứ nhất, bằng chứng của người dùng tương đối lớn, tăng theo logarit của tổng số tài khoản trong hệ thống. Trong lý tưởng, chúng nên có kích thước hằng định, và điều này có thể đạt được bằng các sơ đồ như bộ tích lũy RSA.
Nhược điểm thứ hai khó tránh hơn: mỗi khi người dùng khác thực hiện giao dịch, chứng minh cho cặp số dư tài khoản sẽ thay đổi. Nhắc lại rằng chứng minh của một nút lá bao gồm các nút anh em trên đường đi từ nút lá đến gốc. Nếu một nút lá khác thay đổi, một trong các nút anh em này cũng sẽ thay đổi, gây ra vấn đề thực tế. Hầu hết người dùng blockchain mong muốn bị động lưu giữ tiền trong ví, chỉ kết nối khi muốn thực hiện giao dịch. Tuy nhiên, trong blockchain không trạng thái kiểu này, người dùng phải liên tục theo dõi giao dịch của người khác để giữ bằng chứng của mình luôn cập nhật. Dù bên thứ ba có thể thay mặt người dùng làm việc này, nhưng điều đó đi lệch khỏi mô hình blockchain không trạng thái chuẩn. Trên thực tế, đây là một thách thức không thể vượt qua đối với blockchain không trạng thái, đặt gánh nặng nặng nề lên người dùng.
Kết luận của chúng tôi: Không trạng thái là không thể
Hiện tượng này không chỉ xảy ra với cấu trúc cây Merkle này — mọi phương án blockchain không trạng thái đã biết đều yêu cầu người dùng cập nhật bằng chứng thường xuyên, và chúng tôi chứng minh điều đó tại đây. Chính xác hơn, chúng tôi chỉ ra rằng số lượng người dùng phải cập nhật bằng chứng của họ tăng xấp xỉ tuyến tính theo tổng số giao dịch do tất cả người dùng thực hiện.
Điều này có nghĩa là ngay cả khi người dùng Alice không thực hiện bất kỳ giao dịch nào, bằng chứng của cô ấy vẫn có thể cần thay đổi do giao dịch của người dùng khác. Miễn là trạng thái ngắn gọn mà bộ xác thực lưu trữ quá nhỏ để nắm bắt toàn bộ trạng thái (tức là tập hợp tất cả số dư tài khoản), thì việc tăng kích thước trạng thái ngắn gọn cũng không giúp ích nhiều. Chúng tôi minh họa mối quan hệ này trong biểu đồ dưới đây dựa trên định lý của mình, cùng với số lần thay đổi bằng chứng cần thiết mỗi ngày cho các blockchain có thông lượng khác nhau. Các biểu đồ này cho thấy số lần thay đổi bằng chứng tối thiểu cần thiết ngay cả với blockchain không trạng thái tốt nhất. Ở đây, “vũ trụ dữ liệu” đề cập đến tổng số tài khoản trong mô hình tài khoản hoặc tổng số UTXO trong mô hình UTXO.
Cốt lõi chứng minh của chúng tôi là một lập luận mang tính lý thuyết thông tin. Một nguyên lý cốt lõi của lý thuyết thông tin, do Claude Shannon hình thức hóa, là nếu Alice chọn ngẫu nhiên một đối tượng từ một tập hợp có kích thước 2n và muốn nói cho Bob biết cô ấy đã chọn đối tượng nào, cô ấy phải gửi ít nhất n bit cho anh ta. Nếu tồn tại một phương án blockchain không trạng thái mà người dùng hiếm khi cập nhật bằng chứng, thì Alice có thể truyền thông tin cho Bob bằng ít hơn n bit — điều này là không thể, như Shannon đã chứng minh. Do đó, một blockchain không trạng thái như vậy không tồn tại.
Để đơn giản, chúng tôi mô tả tại đây một phiên bản yếu hơn một chút của chứng minh: không tồn tại blockchain không trạng thái mà người dùng không bao giờ cần cập nhật bằng chứng. Mấu chốt là Alice sử dụng phương án blockchain không trạng thái để mã hóa thông điệp gửi cho Bob. Ban đầu, Alice và Bob đều biết tập hợp đầy đủ gồm n cặp số dư tài khoản. Giả sử mỗi tài khoản có ít nhất một đồng tiền. Alice và Bob cũng biết trạng thái ngắn gọn V của blockchain không trạng thái và bằng chứng wi cho mỗi cặp (ai, bi). Họ cũng thỏa thuận trước một ánh xạ giữa thông điệp và tập hợp tài khoản. Alice sẽ chọn một tập hợp tài khoản A tương ứng với thông điệp của mình, rồi cô sẽ chi tiêu tiền từ các tài khoản này. Cô sẽ sử dụng blockchain không trạng thái để truyền đạt tập hợp đã chọn cho Bob, và Bob sẽ suy ra thông điệp từ tập hợp đó.
Mã hóa: Alice chi tiêu một đồng từ mỗi tài khoản trong A. Sử dụng phương án blockchain không trạng thái, Alice tính ra trạng thái mới V' và gửi cho Bob.
Giải mã: Với mỗi i, Bob kiểm tra xem Verify(wi, (ai, bi)) có đúng hay không. Bob xuất ra tập hợp tài khoản B sao cho Verify(wi, (ai, bi)) = false.
Bob thành công trong việc xuất ra đúng tập hợp A mà Alice đã chọn: B = A. Trước hết, quan sát rằng nếu Alice đã chi tiêu một đồng từ tài khoản ai, thì bằng chứng cũ của tài khoản đó không nên còn được chấp nhận — nếu không, Alice có thể thực hiện chi tiêu kép. Do đó, với mỗi tài khoản ai trong A, Verify(wi, (ai, bi)) = false, nên Bob sẽ đưa tài khoản đó vào B. Mặt khác, Bob sẽ không bao giờ đưa vào B những tài khoản mà Alice không chi tiêu, vì số dư của chúng không đổi, và (như đã nhắc, trong phiên bản suy rộng này) bằng chứng của chúng không bao giờ thay đổi. Vậy nên, B chính xác bằng A.
Cuối cùng, chúng tôi tạo ra mâu thuẫn bằng cách tính số bit Alice phải gửi cho Bob. Cô ấy có thể chọn từ 2^n tập con, nên theo định luật Shannon, cô ấy cần gửi ít nhất n bit cho Bob. Tuy nhiên, cô ấy chỉ gửi trạng thái V' có kích thước hằng định — ngắn hơn rất nhiều so với n bit.
Mặc dù chúng tôi mô tả chứng minh bằng blockchain không trạng thái, Alice và Bob có thể sử dụng nhiều cấu trúc dữ liệu được xác thực khác để thực hiện giao tiếp hiệu quả tương tự, bao gồm bộ tích lũy, cam kết vector và từ điển được xác thực. Chúng tôi hình thức hóa lớp cấu trúc này thông qua một khái niệm trừu tượng mới gọi là hệ thống bằng chứng có thể thu hồi.
Ảnh hưởng của kết quả
Kết quả của chúng tôi cho thấy bạn không thể “loại bỏ trạng thái bằng mật mã học”, không có một lời hứa kỳ diệu nào cho phép xây dựng blockchain không trạng thái mà người dùng không bao giờ phải cập nhật bằng chứng. Trạng thái không biến mất, mà chỉ được chuyển từ bộ xác thực sang người dùng dưới dạng yêu cầu cập nhật bằng chứng thường xuyên.
Cũng tồn tại một số giải pháp hứa hẹn khác, đi lệch khỏi mô hình blockchain không trạng thái nghiêm ngặt. Một cách nới lỏng tự nhiên là cho phép một bên thứ ba (không phải người dùng hay bộ xác thực) chịu trách nhiệm lưu trữ toàn bộ trạng thái. Bên thứ ba này, gọi là nút dịch vụ chứng minh, sử dụng trạng thái đầy đủ để tạo bằng chứng cập nhật cho người dùng. Người dùng sau đó có thể dùng các bằng chứng này để giao dịch như trong blockchain không trạng thái thông thường, trong khi bộ xác thực vẫn chỉ lưu trữ trạng thái ngắn gọn. Cơ chế khuyến khích cho hệ thống này, đặc biệt là cách người dùng bồi thường cho nút dịch vụ chứng minh, là một hướng nghiên cứu mở thú vị.
Mặc dù đến nay chúng tôi tập trung vào blockchain L1, kết quả của chúng tôi cũng ảnh hưởng đến các hệ thống L2 (như máy chủ Rollup). Rollup (dù là Optimistic hay ZK) thường lưu một lời hứa về trạng thái lớn trên L1 với kích thước nhỏ. Trạng thái này bao gồm tài khoản của từng người dùng trên L2. Chúng tôi mong muốn người dùng có thể trực tiếp rút tiền từ L1 (mà không cần sự hợp tác của máy chủ L2), bằng cách đăng tải bằng chứng về số dư tài khoản hiện tại của họ. Cấu hình này cũng là một ví dụ về hệ thống bằng chứng có thể thu hồi trong mô hình của chúng tôi. Thực tế, có thể nói blockchain không trạng thái đã được hiện thực hóa trong thực tiễn dưới dạng Rollup L2.
Tuy nhiên, đáng tiếc là điều này có nghĩa là kết quả bất khả thi của chúng tôi áp dụng trực tiếp. Bằng chứng rút tiền từ Rollup của người dùng phải thay đổi thường xuyên, nếu không gần như toàn bộ trạng thái L2 phải được ghi vào L1. Do đó, các Rollup hiện nay thường giả định sự tồn tại của một ủy ban đảm bảo tính sẵn sàng dữ liệu (đôi khi gọi là “validium”), tương tự như “nút dịch vụ chứng minh”, giúp người dùng tính toán bằng chứng mới khi chuẩn bị rút tiền. Kết quả của chúng tôi cho thấy cảnh báo dành cho người dùng trong tài liệu Ethereum: “Nếu không có dữ liệu giao dịch, người dùng không thể tính toán chứng minh Merkle để chứng minh quyền sở hữu tiền và thực hiện rút tiền” sẽ luôn luôn đúng.
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
a16z
