Các giới hạn của mempool mã hóa

Giá trị tối đa có thể trích xuất thông qua việc lựa chọn, loại bỏ hoặc sắp xếp lại các giao dịch trong một khối được gọi là “giá trị trích xuất tối đa” (MEV). MEV xuất hiện phổ biến trên hầu hết các blockchain và là chủ đề được cộng đồng thảo luận rộng rãi.

Lưu ý: Bài viết này giả định độc giả đã hiểu cơ bản về MEV. Nếu bạn chưa rõ, hãy tham khảo bài giải thích về MEV của chúng tôi trước khi đọc tiếp.

Nhiều nhà nghiên cứu, khi quan sát hiện trạng MEV, đã đặt câu hỏi: Liệu mật mã học có thể giải quyết được vấn đề này? Một số đề xuất đưa ra phương án xây dựng mempool mã hóa, nơi người dùng phát sóng các giao dịch được mã hóa và chỉ được giải mã sau khi đã định thứ tự. Như vậy, giao thức đồng thuận buộc phải cam kết thứ tự giao dịch mà không biết nội dung, về lý thuyết sẽ ngăn được hành vi trục lợi từ cơ hội MEV trong quá trình sắp xếp thứ tự.

Thực tế, cả ở góc độ lý thuyết lẫn thực tiễn, chúng tôi nhận thấy mempool mã hóa không phải là giải pháp vạn năng cho MEV. Dưới đây là các khó khăn và những suy nghĩ về thiết kế mempool mã hóa.

Mempool mã hóa hoạt động như thế nào?

Có nhiều phương án đề xuất cho mempool mã hóa, nhưng khung tổng quát của chúng như sau:

1. Người dùng phát sóng giao dịch đã mã hóa.
2. Các giao dịch mã hóa được ghi nhận lên blockchain (một số phương án mã hóa sau khi xáo trộn ngẫu nhiên có chứng minh).
3. Sau khi khối cam kết được xác nhận hoàn tất, các giao dịch được giải mã.
4. Các giao dịch sẽ được thực thi.

Bước 3 (giải mã giao dịch) đặt ra vấn đề trọng yếu: Ai sẽ giải mã, và chuyện gì xảy ra nếu không ai giải mã? Một giải pháp đơn giản là để người dùng tự giải mã giao dịch của mình (như vậy thậm chí không cần mã hóa, chỉ cần giấu cam kết). Tuy nhiên, phương án này dễ bị khai thác: Kẻ tấn công có thể thực hiện MEV đầu cơ.

Với MEV đầu cơ, kẻ tấn công đoán rằng một giao dịch mã hóa sẽ tạo ra MEV, rồi mã hóa giao dịch của mình với hy vọng được xếp vào vị trí thuận lợi (ví dụ ngay trước hoặc sau giao dịch mục tiêu). Nếu giao dịch được sắp đúng thứ tự, kẻ tấn công sẽ giải mã và hưởng MEV. Nếu không, họ từ chối giải mã, giao dịch sẽ bị loại khỏi chuỗi chính.

Có thể áp dụng hình phạt cho hành vi không giải mã, nhưng việc triển khai gặp nhiều khó khăn. Mức phạt phải đồng nhất với mọi giao dịch mã hóa (do tính ẩn danh), đồng thời đủ lớn để ngăn cản MEV đầu cơ, kể cả với các mục tiêu giá trị cao. Điều này đòi hỏi phải phong tỏa nhiều vốn, đồng thời vẫn giữ được sự ẩn danh (tránh tiết lộ ai gửi giao dịch nào). Nếu hệ thống gặp bug hoặc lỗi mạng khiến người dùng hợp lệ không giải mã được, họ vẫn bị phạt.

Vì vậy, đa số đề xuất cho rằng nên thiết kế sao cho giao dịch được mã hóa có thể giải mã nhất định trong tương lai – kể cả nếu người dùng offline hay không hợp tác. Có một số cách để thực hiện:

TEEs: Người dùng mã hóa giao dịch bằng khóa do Môi trường thực thi tin cậy (TEE) nắm giữ. Ở các phiên bản cơ bản, TEE dùng để giải mã giao dịch sau thời hạn quy định (để được vậy cần có khái niệm về thời gian trong TEE). Các mô hình cao cấp hơn sử dụng TEE để giải mã, xây dựng thứ tự các giao dịch dựa trên tiêu chí như thời điểm đến hoặc phí. Ưu điểm nổi bật của TEE là khả năng xử lý giao dịch dạng plaintext, giúp loại bỏ các giao dịch sẽ thất bại và giảm spam on-chain. Tuy nhiên, phương án này phụ thuộc vào sự tin cậy với phần cứng.

Mã hóa ngưỡng và chia sẻ bí mật (threshold encryption): Phương án này cho phép người dùng mã hóa giao dịch bằng khóa được chia sẻ cho một hội đồng (thường là một phần các validator). Phải đạt một ngưỡng (ví dụ, 2/3 hội đồng) mới có thể giải mã.

Phương án đơn giản là mỗi vòng (mỗi khối hoặc mỗi epoch trên Ethereum) dùng khóa mới, hội đồng sẽ tái tạo và công bố khóa sau khi giao dịch đã định thứ tự trong khối đã xác nhận. Phương án này dùng kỹ thuật chia sẻ bí mật cơ bản, nhưng nhược điểm là toàn bộ giao dịch trong mempool đều bị lộ (kể cả giao dịch không được xác nhận vào khối), đồng thời mỗi vòng cần tạo khóa phân tán mới (DKG).

Giải pháp an toàn hơn là chỉ giải mã các giao dịch thực sự đã được đưa vào khối, có thể thực hiện bằng mã hóa ngưỡng. Cách này giúp giảm chi phí DKG, bằng cách sử dụng cùng một khóa cho nhiều khối, hội đồng sẽ giải mã ngưỡng giao dịch sau khi chúng được định thứ tự trong khối xác nhận. Thách thức là hội đồng phải giải mã nhiều hơn, khối lượng công việc tăng theo số lượng giao dịch, dù gần đây nghiên cứumới đã đề xuất phương án giải mã theo lô hiệu quả hơn.

Với mã hóa ngưỡng, niềm tin được chuyển từ phần cứng sang hội đồng. Lý do là đa số giao thức đã giả định “đa số validator trung thực”, nên ta có thể giả định đa số hội đồng sẽ không giải mã giao dịch sớm. Tuy nhiên, cần lưu ý: đây không phải giả định giống nhau. Lỗi đồng thuận như forking đều có thể quan sát công khai (niềm tin yếu), trong khi nếu hội đồng độc hại giải mã sớm giao dịch thì không tạo ra bằng chứng công khai, tức không thể phát hiện hay xử phạt (niềm tin mạnh). Do đó, dù lý thuyết giả định hai bên có vẻ giống nhau, thực tế việc tin tưởng hội đồng không thông đồng lẫn nhau khó chắc chắn.

Mã hóa khóa thời gian (time-lock) và mã hóa trì hoãn (delay encryption): Thay vì mã hóa ngưỡng, có thể dùng mã hóa trì hoãn. Theo đó, người dùng mã hóa giao dịch cho một khóa công khai mà khóa bí mật được ẩn bên trong “câu đố khóa thời gian”. Câu đố này chỉ giải được sau một khoảng thời gian nhất định bằng tính toán tuần tự, không song song hóa. Lúc đó, bất kỳ ai cũng có thể giải đố để lấy khóa giải mã, nhưng chỉ làm được sau khi đã mất thời gian tính toán đủ lâu để bảo đảm giao dịch không bị giải mã trước khi khối đã xác nhận. Phiên bản mạnh nhất sử dụng delay encryption để tạo công khai câu đố. Hoặc có thể lập hội đồng tin cậy để tính toán câu đố theo cách mã hóa khóa thời gian, nhưng ưu điểm khi đó không rõ vượt trội phương án ngưỡng.

Dù dùng mã hóa trì hoãn hay hội đồng tính toán, đều xuất hiện một số khó khăn thực tiễn. Thứ nhất, rất khó đảm bảo chính xác thời điểm giải mã do trễ là bản chất tính toán. Thứ hai, các mô hình này cần có bên sở hữu phần cứng mạnh để giải đố hiệu quả; dù bất kỳ ai cũng có thể tham gia, khó xác định biện pháp thúc đẩy họ làm việc đó. Cuối cùng, mọi giao dịch phát sóng đều bị giải mã, kể cả giao dịch không được xác nhận vào block. Các phương án dựa trên ngưỡng (hoặc mã hóa witness) có thể chỉ giải mã các giao dịch thực sự được ghi vào khối.

Mã hóa witness: Cuối cùng, phương án mật mã tiên tiến nhất sử dụng witness encryption. Về lý thuyết, witness encryption cho phép mã hóa dữ liệu cho bất kỳ ai có “witness” cho một quan hệ NP cụ thể: ví dụ, người biết lời giải Sudoku hoặc có preimage của một hash sẽ giải mã được.

SNARK cũng hỗ trợ mọi quan hệ NP, có thể hiểu witness encryption là mã hóa dữ liệu cho bất kỳ ai chứng minh được (bằng SNARK) điều kiện mong muốn. Ứng dụng vào mempool mã hóa, ví dụ, chỉ khi khối đã xác nhận, giao dịch mới được giải mã.

Đây là một nguyên thủy mật mã mạnh về mặt lý thuyết, là trường hợp tổng quát cho cả phương án hội đồng và trì hoãn. Tuy nhiên, hiện chưa có áp dụng thực tế cho witness encryption. Ngay cả nếu có, cũng khó đảm bảo hiệu quả so với phương án hội đồng trên chuỗi Proof-of-Stake. Bởi nếu witness encryption thiết lập sao cho chỉ giải mã được khi khối xác nhận, hội đồng độc hại vẫn có thể mô phỏng đồng thuận riêng, xác nhận giao dịch trên chain riêng và dùng nó làm witness để giải mã. Lúc này, dùng mã hóa ngưỡng với cùng hội đồng vừa an toàn hơn, vừa đơn giản.

Witness encryption thực sự nổi bật ở những chuỗi Proof-of-Work, bởi hội đồng độc hại hoàn toàn không thể tự ý đào thêm nhiều block trên chain riêng để mô phỏng tính xác nhận.

Thách thức kỹ thuật đối với mempool mã hóa

Nhiều thách thức thực tế quan trọng hạn chế khả năng chống MEV của mempool mã hóa. Về cơ bản, bảo mật thông tin là rất khó. Đáng chú ý là mã hóa rất ít được ứng dụng trong web3, dù chúng ta đã có hàng chục năm kinh nghiệm triển khai mã hóa trên web (TLS/HTTPS) hay bảo mật thông tin cá nhân (PGP, các trang nhắn tin mã hóa hiện đại như Signal hoặc Whatsapp). Mã hóa giúp bảo vệ thông tin, nhưng không tuyệt đối đảm bảo bí mật.

Chẳng hạn, có thể có bên tiếp cận trực tiếp với nội dung giao dịch gốc. Thông thường, người dùng sẽ nhờ ví thực hiện mã hóa, như vậy ví truy cập được transaction plaintext và có thể dùng hoặc bán thông tin này để trích xuất MEV. Khả năng bảo vệ của mã hóa không vượt quá phạm vi những bên giữ khóa giải mã.

Thách thức lớn nhất nằm ở metadata – dữ liệu bao quanh giao dịch được mã hóa, vốn không được bảo vệ. Các searcher sử dụng metadata này để dự đoán mục đích giao dịch, rồi thực hiện MEV đầu cơ. Họ không cần phải hiểu hoàn toàn giao dịch, cũng không cần đoán đúng mọi trường hợp – chỉ cần xác suất hợp lý, ví dụ đoán giao dịch là lệnh mua từ một DEX cụ thể.

Một số loại metadata, cả kinh điển lẫn đặc thù mempool mã hóa, có thể kể đến:

• Kích thước giao dịch: Mã hóa không giúp che giấu kích thước dữ liệu gốc. (Định nghĩa bảo mật ngữ nghĩa truyền thống còn loại trừ việc che giấu kích thước plaintext.) Đây là lỗ hổng phổ biến. (Ví dụ nổi tiếng: kẻ nghe lén vẫn biết được video nào đang xem trên Netflix bằng cách đo kích thước gói dữ liệu.) Với mempool mã hóa, một số loại giao dịch sẽ có kích thước đặc trưng lộ thông tin.

• Thời điểm phát sóng: Mã hóa không che được thời gian giao dịch, một kênh tấn công cổ điển. Trong web3, một số nhà giao dịch có thể phát lệnh theo chu kỳ, hoặc thời điểm giao dịch trùng với các sự kiện bên ngoài như tin tức, hoạt động sàn tập trung. Thậm chí, searcher có thể lợi dụng độ trễ này để arbitrage CEX/DEX, bằng cách chèn lệnh càng muộn càng có lợi về giá, hoặc loại giao dịch được broadcast sau một thời điểm nhất định để chỉ mình hưởng lợi thông tin giá mới nhất.

• Địa chỉ IP nguồn: Searcher có thể xác định danh tính người gửi bằng cách soi mạng ngang hàng và kiểm tra IP xuất phát. Vấn đề này đã được nhận diện từ thời đầu Bitcoin. Nếu người gửi có hành vi đặc trưng, việc biết địa chỉ này giúp liên kết các giao dịch mã hóa với các giao dịch từng giải mã trước đây.

• Địa chỉ gửi và thông tin phí/gas: Cuối cùng, phí giao dịch là loại metadata riêng biệt của mempool mã hóa. Đặc biệt trên Ethereum, giao dịch sẽ lưu cả địa chỉ sender, mức gas tối đa, đơn giá gas – tất cả đều giúp liên kết các giao dịch với thực thể ngoài chuỗi hoặc đoán mục đích giao dịch (ví dụ, tương tác với một DEX cụ thể đòi hỏi lượng gas nhất định).

Các searcher tinh vi có thể tổng hợp mọi loại metadata trên để dự đoán nội dung giao dịch.

Về lý thuyết, hoàn toàn có thể che giấu toàn bộ thông tin này, nhưng cái giá là phí xử lý lớn và phức tạp. Ví dụ, padding giao dịch lên kích thước chuẩn giấu được kích cỡ nhưng làm tốn tài nguyên hệ thống; thêm delay gửi giấu thời gian nhưng làm tăng độ trễ; phát sóng qua mạng ẩn danh như Tor giấu IP nhưng gặp khó khăn riêng.

Metadata khó che giấu nhất là khoản phí giao dịch. Nếu mã hóa dữ liệu phí, builder gặp nhiều vấn đề. Thứ nhất là spam: bất kỳ ai cũng có thể broadcast giao dịch mã hóa không hợp lệ, được xếp vào block nhưng không đủ tiền trả phí. Khi giải mã, hệ thống không thể phạt ai do thiếu thông tin. Có thể xử lý bằng SNARK chứng minh giao dịch hợp lệ và có tiền, nhưng chi phí cực kỳ cao.

Vấn đề thứ hai là xây dựng block hiệu quả và đấu giá phí. Builder cần thông tin phí để chọn giao dịch mang lại lợi nhuận cao nhất, hình thành giá thị trường on-chain. Mã hóa phí cản trở điều này. Có thể chọn mức phí cố định cho mỗi block, nhưng như vậy lại phi hiệu quả kinh tế và tạo ra thị trường thứ cấp cho ưu tiên giao dịch, vô tình phá vỡ mục đích mempool mã hóa. Đấu giá phí bằng mã hóa đa bên hoặc phần cứng tin cậy là khả thi nhưng đều đắt đỏ.

Cuối cùng, mempool mã hóa làm tăng tải cho hệ thống: tăng độ trễ, tính toán, tiêu tốn băng thông. Việc tích hợp với các công nghệ như sharding hoặc thực thi song song – mục tiêu phát triển chủ đạo – còn nhiều trở ngại. Ngoài ra, còn làm tăng rủi ro ngừng hoạt động (ví dụ, hội đồng giải mã hoặc solver hàm trì hoãn). Tất nhiên, việc thiết kế và triển khai cũng phức tạp hơn rất nhiều.

Nhiều vấn đề của mempool mã hóa cũng xuất hiện ở các blockchain bảo mật giao dịch như Zcash, Monero. Điểm sáng là nếu giải quyết được những thách thức này cho mục tiêu hạn chế MEV, thì các vấn đề bảo mật quyền riêng tư giao dịch cũng sẽ tự động được cải thiện đáng kể.

Thách thức kinh tế đối với mempool mã hóa

Mempool mã hóa còn đối mặt thách thức kinh tế. Khác với vấn đề kỹ thuật có thể giải quyết bằng công nghệ, hạn chế kinh tế mang tính bản chất và rất khó thay đổi.

MEV nảy sinh do bất cân xứng thông tin giữa người dùng tạo giao dịch với các searcher, builder săn cơ hội MEV. Người dùng thường không biết giao dịch của mình sẽ bị trích xuất bao nhiêu MEV. Do vậy, dù mempool mã hóa hoàn hảo, người dùng vẫn có thể bị builder khuyến khích tiết lộ khóa giải mã để nhận khoản thanh toán thấp hơn giá trị thực bị trích xuất. Đây gọi là “giải mã có động lực” (incentivized decryption).

Mô hình này không mới, ví dụ MEV Share đã tồn tại. MEV Share là sàn đấu giá order flow, cho phép người dùng chọn tiết lộ dữ liệu cho pool, searcher sẽ đấu giá quyền khai thác MEV; searcher thắng sẽ chia sẻ lại một phần lợi nhuận cho người dùng (toàn bộ hoặc một phần giá trị bid).

Mô hình này hoàn toàn có thể triển khai với mempool mã hóa, chỉ cần người dùng tiết lộ khóa giải mã hoặc một phần thông tin để tham gia. Đa số người dùng sẽ không ý thức được cái giá cơ hội, chỉ nhìn thấy phần thưởng nhận về nên sẵn sàng bán thông tin. Trong tài chính truyền thống, cũng có trường hợp tương tự (dịch vụ giao dịch không phí như Robinhood) bán order flow cho bên thứ ba theo mô hình “thanh toán đổi lấy luồng lệnh”.

Kịch bản khác là builder lớn buộc người dùng tiết lộ giao dịch hoặc một phần dữ liệu để đáp ứng kiểm duyệt. Độ chống kiểm duyệt là vấn đề nóng của web3, nhưng nếu builder/proposer lớn phải tuân thủ danh sách kiểm duyệt (ví dụ OFAC), họ sẽ từ chối sắp xếp mọi giao dịch mã hóa. Về mặt kỹ thuật có thể giải quyết bằng zero-knowledge proof chứng minh giao dịch hợp lệ với danh sách kiểm duyệt, nhưng chi phí phức tạp tăng mạnh. Ngay cả khi blockchain có khả năng chống kiểm duyệt cao, builder vẫn sẽ ưu tiên thứ tự giao dịch plaintext lên đầu block, đẩy giao dịch mã hóa xuống cuối. Như vậy, giao dịch yêu cầu bảo đảm thứ tự vẫn buộc phải tiết lộ nội dung cho builder.

Những thách thức hiệu quả khác

Mempool mã hóa làm tăng chi phí xử lý cho hệ thống: người dùng phải mã hóa giao dịch, mạng lưới phải giải mã. Điều này kéo theo chi phí tính toán, tăng kích thước giao dịch. Vấn đề metadata càng làm chi phí này nặng thêm. Tuy nhiên, còn có chi phí hiệu quả ít được nhận ra hơn. Trong thị trường tài chính, giá hiệu quả phản ánh đầy đủ thông tin; còn mọi độ trễ, bất cân xứng thông tin đều làm thị trường kém hiệu quả – điều mà mempool mã hóa khiến xảy ra một cách tự nhiên.

Hệ lụy trực tiếp là bất ổn giá tăng lên do độ trễ bổ sung khi dùng mempool mã hóa. Điều này khiến số lượng giao dịch thất bại do vượt ngưỡng trượt giá tăng lên, làm lãng phí tài nguyên blockchain.

Bên cạnh đó, sự bất ổn giá này còn kích thích hành vi MEV đầu cơ nhằm khai thác arbitrage on-chain. Đặc biệt, các cơ hội này sẽ xuất hiện nhiều hơn khi triển khai mempool mã hóa, bởi càng khó xác định trạng thái DEX tại thời điểm thực thi càng dễ tạo ra chênh lệch giá giữa các sàn. Những giao dịch MEV đầu cơ này phần lớn sẽ thất bại và cũng chiếm dụng không gian block.

Bài viết này nhằm điểm lại các thách thức của mempool mã hóa để cộng đồng lập trình hướng tới giải pháp khác, nhưng mempool mã hóa vẫn có thể là một phần của giải pháp tổng thể MEV.

Một lối đi khả thi là thiết kế lai: một số giao dịch sẽ được sắp xếp mù bằng mempool mã hóa, số khác dùng phương án khác. Đối với lệnh mua/bán khối lượng lớn, đối tượng tổ chức có thể mã hóa hoặc padding cẩn thận, chấp nhận trả phí cao để tránh MEV, thiết kế lai là lựa chọn phù hợp. Cách này cũng lý tưởng cho những giao dịch nhạy cảm như vá lỗi hợp đồng bảo mật.

Tuy nhiên, do hạn chế công nghệ, phức tạp khi triển khai và chi phí hiệu suất, mempool mã hóa khó có thể trở thành giải pháp hoàn hảo cho MEV như một số người kỳ vọng. Cộng đồng cần phát triển các phương án khác như đấu giá MEV, phòng vệ ở tầng ứng dụng, rút ngắn thời gian xác nhận khối. MEV sẽ còn là bài toán dài hạn và việc cân nhắc các giải pháp kết hợp là cần thiết để kiểm soát rủi ro phát sinh.

Pranav Garimidi là nghiên cứu viên tại a16z Crypto, chuyên về thiết kế cơ chế và lý thuyết trò chơi thuật toán ứng dụng blockchain, đặc biệt tập trung phân tích động lực giữa các lớp trong kiến trúc blockchain. Trước khi gia nhập a16z, Pranav học và tốt nghiệp ngành Khoa học Máy tính tại Đại học Columbia.

Joseph Bonneau là phó giáo sư ngành Khoa học Máy tính, Viện Courant – Đại học New York, đồng thời là cố vấn kỹ thuật cho a16z crypto. Ông tập trung nghiên cứu mật mã ứng dụng và bảo mật blockchain. Joseph từng giảng dạy môn tiền mã hóa tại Đại học Melbourne, NYU, Stanford, Princeton; nhận bằng Tiến sĩ tại Đại học Cambridge và bằng cử nhân, thạc sĩ tại Stanford.

Lioba Heimbach là nghiên cứu sinh năm thứ tư, dưới sự hướng dẫn của GS. Roger Wattenhofer tại nhóm Distributed Computing (Disco), ETH Zurich. Lioba chuyên nghiên cứu giao thức blockchain với trọng tâm DeFi, hướng tới việc xây dựng hệ sinh thái blockchain và DeFi phi tập trung, công bằng và hiệu quả. Cô từng thực tập nghiên cứu tại a16z crypto mùa hè 2024.

Những quan điểm thể hiện ở đây là ý kiến cá nhân của thành viên AH Capital Management, L.L.C. (“a16z”) được trích dẫn, không phải quan điểm chính thức của a16z hoặc các đơn vị liên quan. Một số thông tin lấy từ nguồn bên thứ ba (bao gồm doanh nghiệp thuộc danh mục đầu tư các quỹ do a16z quản lý). Dù nguồn tin được xem là đáng tin cậy, a16z chưa kiểm chứng độc lập và không bảo đảm tính chính xác, phù hợp trong từng trường hợp. Ngoài ra, bài viết có thể chứa quảng cáo bên thứ ba; a16z chưa thẩm định và không xác nhận bất kỳ nội dung quảng cáo nào được đề cập.

Nội dung trên chỉ nhằm mục đích tham khảo, không phải là tư vấn pháp lý, kinh doanh, đầu tư, thuế. Vui lòng tham khảo chuyên gia của bạn về những vấn đề này. Việc đề cập chứng khoán hay tài sản số chỉ nhằm minh họa, không phải lời khuyên đầu tư hay chào bán sản phẩm tư vấn đầu tư. Ngoài ra, nội dung này không dành cho (và không được sử dụng làm căn cứ đầu tư vào) bất kỳ quỹ nào của a16z. (Chỉ có bản công bố phát hành riêng, hợp đồng đăng ký hoặc tài liệu chính thức của quỹ mới là tài liệu hợp lệ cho quyết định đầu tư.) Danh mục đầu tư nêu trong bài không đại diện toàn bộ các khoản đầu tư của Andreessen Horowitz, không có đảm bảo về lợi nhuận hoặc đặc điểm tương tự cho đầu tư hiện tại và tương lai. Danh sách khoản đầu tư (trừ phần chưa công bố hoặc tài sản số chưa niêm yết) cập nhật tại https://a16z.com/investments/.

Nội dung chỉ có giá trị tại thời điểm công bố. Mọi nhận định, dự báo, ước tính trong tài liệu này đều có thể thay đổi mà không cần báo trước và có thể trái với nhận định khác. Vui lòng xem thêm tại https://a16z.com/disclosures.

Tuyên bố miễn trừ trách nhiệm:

1. Bài viết được đăng lại từ [a16zcrypto], mọi bản quyền thuộc về tác giả gốc [Pranav GarimidiJoseph BonneauLioba Heimbach]. Nếu có ý kiến về việc tái đăng, vui lòng liên hệ đội ngũ Gate Learn để xử lý.
2. Tuyên bố miễn trừ: Quan điểm trong bài thuộc về tác giả, không mang ý nghĩa khuyến nghị đầu tư.
3. Bản dịch do đội ngũ Gate Learn thực hiện. Nếu không có thông báo khác, nghiêm cấm sao chép, phát tán, đạo văn bản dịch này.