Vitalik: Sàn giao dịch tập trung làm thế nào để chứng minh nguồn vốn?

Tác giả: Vitalik

Biên dịch: Đổng Nhất Minh, ChainCatcher

Mỗi khi một sàn giao dịch tập trung quan trọng gặp sự cố, một câu hỏi phổ biến được đặt ra là liệu chúng ta có thể sử dụng công nghệ mã hóa để giải quyết vấn đề này hay không. Sàn giao dịch có thể tạo ra chứng nhận mã hóa, cho thấy họ có đủ tiền trên chuỗi để thanh toán cho các khoản nợ của họ đối với người dùng, thay vì chỉ dựa vào các phương pháp "hợp pháp" như giấy phép của chính phủ, kiểm toán viên và kiểm tra nền tảng cá nhân của những người điều hành sàn giao dịch.

Sàn giao dịch có thể thiết lập một hệ thống mà không thể rút tiền của người gửi mà không có sự đồng ý của họ. Tiềm năng, chúng ta có thể khám phá toàn bộ phổ giữa CEX của những người tốt có tham vọng "không làm điều xấu" và DEX trên chuỗi "không thể làm điều xấu", nhưng hiện tại thì kém hiệu quả và rò rỉ quyền riêng tư. Bài viết này sẽ đi sâu vào những nỗ lực lịch sử nhằm đưa giao dịch gần hơn đến trạng thái không cần tin cậy, những hạn chế của các công nghệ này, cũng như một số ý tưởng cập nhật và mạnh mẽ hơn dựa vào ZK-SNARKs và các công nghệ tiên tiến khác.

Bảng cân đối kế toán và cây Merkle : Chứng minh khả năng thanh toán cổ điển

Sàn giao dịch đã cố gắng chứng minh rằng họ không lừa dối người dùng của mình bằng các phương pháp mật mã từ rất lâu trước đây. Năm 2011, sàn giao dịch Bitcoin lớn nhất lúc bấy giờ, MtGox, đã chứng minh họ có tiền bằng cách gửi một giao dịch chuyển 424242 BTC đến một địa chỉ đã công bố trước. Năm 2013, người ta bắt đầu thảo luận về một khía cạnh khác của vấn đề: chứng minh quy mô tổng thể của các khoản tiền gửi của khách hàng. Nếu bạn chứng minh rằng tổng số tiền gửi của khách hàng bằng X ("chứng minh nợ"), và chứng minh quyền sở hữu khóa riêng của X đồng coin ("chứng minh tài sản"), thì bạn đã có chứng minh khả năng thanh toán: bạn đã chứng minh rằng sàn giao dịch có đủ tiền để hoàn trả cho tất cả các người gửi tiền.

Cách đơn giản nhất để chứng minh tiền gửi là đơn giản công bố một danh sách các cặp (tên người dùng, số dư). Mỗi người dùng có thể kiểm tra xem số dư của họ có nằm trong danh sách hay không, bất kỳ ai cũng có thể kiểm tra danh sách đầy đủ để xem (i) mỗi số dư đều không âm, (ii) tổng số tiền bằng số tiền bồi thường. Tất nhiên, điều này đã phá vỡ quyền riêng tư, vì vậy chúng ta có thể thay đổi một chút kế hoạch: công bố một danh sách các cặp (băm(tên người dùng, muối), số dư) và gửi riêng cho mỗi người dùng giá trị muối của họ. Nhưng ngay cả như vậy, điều này cũng sẽ rò rỉ số dư và mô hình thay đổi số dư. Mong muốn bảo vệ quyền riêng tư đã dẫn chúng ta đến phát minh tiếp theo: công nghệ cây Merkle.

Màu xanh: nút Charlie. Màu xanh dương: nút David, cũng là nút mà Charlie sẽ nhận được, như một phần của chứng minh của anh ấy. Màu vàng: nút gốc, công khai cho mọi người.

Công nghệ cây Merkle là đưa bảng số dư của khách hàng vào cây tổng Merkle. Trong cây tổng Merkle, mỗi nút là một cặp (số dư, băm). Các nút lá ở dưới cùng đại diện cho số dư của từng khách hàng và băm tên người dùng đã được muối. Ở mỗi nút cao hơn, số dư là tổng của hai số dư bên dưới, trong khi băm là băm của hai nút bên dưới. Chứng minh tổng Merkle, giống như chứng minh Merkle, là một "nhánh" của cây, được tạo thành từ các nút chị em trên đường từ lá đến gốc.

Sàn giao dịch sẽ gửi chứng minh tổng Merkle cho mỗi người dùng để chứng minh số dư của họ. Sau đó, người dùng sẽ nhận được một đảm bảo rằng số dư của họ đã được bao gồm đúng trong tổng số. Một ví dụ mã đơn giản có thể được tìm thấy ++tại đây++.

Sự rò rỉ quyền riêng tư trong thiết kế này thấp hơn nhiều so với danh sách công khai hoàn toàn, và có thể được giảm thêm bằng cách xáo trộn các nhánh mỗi khi công bố gốc, nhưng một số rò rỉ quyền riêng tư vẫn tồn tại. Charlie có thể biết rằng số dư của ai đó là 164ETH, có hai người dùng có tổng số dư là 70ETH, v.v. Một kẻ tấn công kiểm soát nhiều tài khoản vẫn có khả năng biết được nhiều thông tin về người dùng của sàn giao dịch.

Một điểm tinh tế quan trọng của kế hoạch này là khả năng có số dư âm: nếu một sàn giao dịch có số dư khách hàng là 1390ETH nhưng chỉ có 890ETH dự trữ, thì làm thế nào để bù đắp sự chênh lệch bằng cách thêm một số dư -500ETH dưới một tài khoản giả nào đó trên cây? Thực tế cho thấy, khả năng này không phá vỡ kế hoạch, mặc dù đó là lý do tại sao chúng ta đặc biệt cần cây tổng Merkle thay vì cây Merkle thông thường. Giả sử Henry là tài khoản giả do sàn giao dịch kiểm soát, sàn giao dịch đã đặt -500ETH ở đó.

Chứng minh của Greta sẽ thất bại: sàn giao dịch sẽ phải cung cấp cho cô ấy nút -500 ETH của Henry, và cô ấy sẽ từ chối nút này vì nó không hợp lệ. Việc xác minh của Eve và Fred cũng sẽ thất bại vì tổng số ETH của nút trung gian phía trên Henry là -230, vì vậy cũng không hợp lệ! Để thoát khỏi việc bị đánh cắp, sàn giao dịch sẽ phải hy vọng rằng không ai kiểm tra chứng minh số dư của họ ở nửa bên phải của toàn bộ cây.

Nếu sàn giao dịch có thể xác định được những người dùng có giá trị 500ETH mà họ tin rằng những người dùng này sẽ không bận tâm kiểm tra chứng minh, hoặc sẽ không được tin tưởng khi phàn nàn rằng họ chưa bao giờ nhận được chứng minh, thì họ sẽ tự tin thoát khỏi hình phạt của việc đánh cắp. Tuy nhiên, sàn giao dịch cũng có thể loại bỏ những người dùng này khỏi cây, đạt được hiệu quả tương tự.

Do đó, nếu chỉ để đạt được mục tiêu chứng minh nợ, công nghệ cây Merkle về cơ bản cũng tốt như kế hoạch chứng minh nợ (proof-of-liabilities). Nhưng thuộc tính quyền riêng tư của nó vẫn không lý tưởng. Bạn có thể sử dụng cây Merkle theo cách tinh vi hơn, chẳng hạn như ++để mỗi satoshi hoặc wei trở thành một lá riêng biệt++, nhưng cuối cùng với các công nghệ hiện đại hơn, vẫn có những cách tốt hơn để làm điều này.

Cải thiện quyền riêng tư và độ bền với ZK-SNARKs

ZK-SNARKs là một công nghệ mạnh mẽ. Vai trò của ZK-SNARKs trong mật mã có thể giống như vai trò của transformer trong trí tuệ nhân tạo: nó là một công nghệ tổng quát mạnh mẽ đến mức nó sẽ hoàn toàn nghiền nát một loạt các vấn đề trong các công nghệ ứng dụng cụ thể được phát triển hàng chục năm trước. Do đó, tất nhiên, chúng ta có thể sử dụng ZK-SNARKs để đơn giản hóa và cải thiện đáng kể quyền riêng tư trong giao thức chứng minh trách nhiệm.

Điều đơn giản nhất mà chúng ta có thể làm là đưa tất cả các khoản tiền gửi của người dùng vào một cây Merkle (hoặc đơn giản hơn, một ++cam kết KZG++), và sử dụng ZK-SNARK để chứng minh rằng tất cả các số dư trong cây đều không âm và tổng cộng bằng một giá trị được tuyên bố nào đó. Nếu chúng ta thêm một lớp băm cho quyền riêng tư, nhánh Merkle (hoặc chứng minh KZG) của mỗi người dùng sẽ không tiết lộ số dư của bất kỳ người dùng nào khác.

Sử dụng cam kết KZG là một cách để tránh rò rỉ quyền riêng tư, vì không cần cung cấp "nút chị em" làm chứng minh, một ZK-SNARK đơn giản có thể được sử dụng để chứng minh tổng số dư và rằng mỗi số dư đều không âm.

Chúng ta có thể sử dụng một ZK-SNARK chuyên dụng để chứng minh tổng số dư trong KZG trên và tính không âm. Đây là một ví dụ đơn giản có thể làm được điều này. Chúng ta giới thiệu một đa thức phụ, nó "xây dựng vị trí của mỗi số dư" (để lấy ví dụ, chúng ta giả định số dư là), và theo dõi một tổng chạy có độ lệch cho mỗi 16 vị trí, vì vậy tổng của nó chỉ bằng không khi tổng thực tế khớp với tổng được tuyên bố. Nếu z là căn bậc 128 của đơn vị, chúng ta có thể chứng minh phương trình sau.

Giá trị đầu tiên của thiết lập hợp lệ là 0 0 0 0 0 0 0 0 0 0 1 2 5 10 20 -165 0 0 0 0 0 0 0 0 1 3 6 12 25 50 -300 …

Về cách chuyển đổi một phương trình như vậy thành kiểm tra đa thức, sau đó chuyển đổi thành ZK-SNARK, hãy xem phần giải thích thêm của tôi trong ++bài viết về ZK-SNARK++ ở ++đây++ và ++đây++. Đây không phải là một giao thức tối ưu, nhưng nó thực sự cho thấy rằng những loại chứng minh mật mã này không còn quá kỳ lạ nữa!

Chỉ với một vài công thức bổ sung, một hệ thống ràng buộc như vậy có thể thích ứng với các môi trường phức tạp hơn. Ví dụ, trong một hệ thống giao dịch đòn bẩy, việc người dùng cá nhân có số dư âm là chấp nhận được, nhưng với điều kiện họ có đủ tài sản khác để bù đắp cho số tiền có một số tài sản thế chấp. Một SNARK có thể được sử dụng để chứng minh ràng buộc phức tạp hơn này, giúp người dùng yên tâm rằng sàn giao dịch sẽ không gây rủi ro cho tiền của họ thông qua ++các quy tắc miễn trừ++ ++khác++.

Trong tương lai xa hơn, chứng minh nợ ZK này có thể không chỉ được sử dụng cho các khoản tiền gửi của khách hàng tại sàn giao dịch, mà còn cho các khoản vay rộng rãi hơn. Bất kỳ ai khi vay tiền sẽ đưa một bản ghi vào một đa thức hoặc cây chứa khoản vay đó, và gốc của cấu trúc đó sẽ được công bố trên chuỗi. Điều này sẽ cho phép bất kỳ ai đang tìm kiếm khoản vay cung cấp cho người cho vay chứng minh ZK rằng họ chưa vay quá nhiều khoản vay khác. Cuối cùng, đổi mới pháp lý thậm chí có thể khiến các khoản vay đã được cam kết theo cách này có ưu tiên cao hơn so với các khoản vay chưa được cam kết. Điều này dẫn chúng ta đến một hướng hoàn toàn tương tự với ý tưởng được thảo luận trong ++"Xã hội phi tập trung++ ++:++ ++Tìm kiếm linh hồn của Web3"++: thiết lập một khái niệm về danh tiếng tiêu cực hoặc tài sản thế chấp trên chuỗi thông qua một dạng "token gắn liền với linh hồn" (soulbound token).

Chứng minh tài sản

Phiên bản đơn giản nhất của chứng minh tài sản là giao thức mà chúng ta đã thấy ở trên: để chứng minh bạn nắm giữ X đồng coin, bạn chỉ cần chuyển X đồng coin trong một giao dịch vào một thời điểm đã thỏa thuận trước hoặc trong một giao dịch có trường dữ liệu chứa "các quỹ này thuộc về Binance". Để tránh phải trả phí giao dịch, bạn có thể ký một thông tin ngoài chuỗi thay thế; cả Bitcoin và Ethereum đều có tiêu chuẩn cho thông tin chữ ký ngoài chuỗi.

Công nghệ chứng minh tài sản đơn giản này có hai vấn đề thực tiễn.

• Xử lý "kho lạnh"
• Sử dụng kép tài sản thế chấp

Vì lý do an ninh, hầu hết các sàn giao dịch giữ phần lớn tiền của khách hàng trong "kho lạnh": trên máy tính ngoại tuyến, giao dịch cần được ký tay và chuyển lên internet. Tôi đã từng sử dụng một kho lạnh cho tiền cá nhân của mình, liên quan đến một máy tính hoàn toàn ngoại tuyến, nó sẽ tạo ra một mã QR chứa giao dịch đã ký mà tôi có thể quét bằng điện thoại của mình. Các giao thức trao đổi hiện đại phức tạp hơn nhiều, thường liên quan đến tính toán đa bên giữa một vài thiết bị. Với thiết lập này, ngay cả một thông tin bổ sung để chứng minh quyền kiểm soát một địa chỉ cũng là một thao tác tốn kém!

Một giao dịch có thể đi theo một số con đường sau:

• Giữ một số địa chỉ công khai lâu dài. Sàn giao dịch sẽ tạo ra một số địa chỉ, công bố một chứng minh cho mỗi địa chỉ để chứng minh quyền sở hữu, sau đó tái sử dụng những địa chỉ này. Đây là kế hoạch đơn giản nhất cho đến nay, mặc dù nó thực sự đã tăng thêm một số hạn chế về cách bảo vệ an ninh và quyền riêng tư.
• Thiết lập nhiều địa chỉ, ngẫu nhiên chứng minh một số. Sàn giao dịch sẽ có nhiều địa chỉ, có thể thậm chí mỗi địa chỉ chỉ sử dụng một lần, và sẽ bị loại bỏ sau một giao dịch. Trong trường hợp này, sàn giao dịch có thể có một giao thức ngẫu nhiên chọn một số địa chỉ, phải "mở" để chứng minh quyền sở hữu. Một số sàn giao dịch đã làm điều tương tự với kiểm toán viên, nhưng về nguyên tắc, công nghệ này có thể trở thành một chương trình hoàn toàn tự động.
• Tùy chọn ZKP phức tạp hơn. Ví dụ, một sàn giao dịch có thể thiết lập tất cả các địa chỉ của mình thành chữ ký đa chữ ký 1/2, trong đó mỗi địa chỉ có khóa khác nhau, khóa khác là một bản sao mù của một khóa sao lưu "quan trọng", được lưu trữ theo cách phức tạp nhưng rất an toàn, chẳng hạn như chữ ký đa chữ ký 12/16. Để bảo vệ quyền riêng tư và tránh tiết lộ toàn bộ tập hợp địa chỉ của mình, sàn giao dịch thậm chí có thể chạy một chứng minh không biết trên chuỗi, chứng minh tổng số dư của tất cả các địa chỉ có định dạng này trên chuỗi.

Một vấn đề chính khác là ngăn chặn việc sử dụng kép tài sản thế chấp. Sàn giao dịch có thể dễ dàng chuyển tài sản thế chấp qua lại giữa nhau để chứng minh dự trữ, điều này sẽ khiến họ giả vờ có khả năng thanh toán khi thực tế không có. Lý tưởng nhất, chứng minh khả năng thanh toán được thực hiện theo thời gian thực, được cập nhật sau mỗi khối. Nếu điều này không thực tế, lựa chọn thứ hai là phối hợp một lịch trình cố định giữa các sàn giao dịch khác nhau, chẳng hạn như chứng minh dự trữ vào mỗi thứ Ba lúc 14 giờ UTC.

Câu hỏi cuối cùng là: Có thể chứng minh tài sản bằng tiền pháp định không? Sàn giao dịch không chỉ giữ tiền mã hóa, họ còn giữ tiền pháp định trong hệ thống ngân hàng. Ở đây, câu trả lời là: có, nhưng quy trình như vậy sẽ không thể tránh khỏi phụ thuộc vào mô hình tin tưởng "tiền pháp định": ngân hàng tự nó có thể chứng minh số dư, kiểm toán viên có thể chứng minh bảng cân đối kế toán, v.v. Với việc tiền pháp định không thể được xác minh bằng mã hóa, đây là điều tốt nhất có thể làm trong khuôn khổ đó, nhưng vẫn đáng để thực hiện.

Một cách khác là tách biệt một thực thể điều hành sàn giao dịch và xử lý các stablecoin được hỗ trợ bởi tài sản như USDC và một thực thể xử lý tiền mặt di chuyển vào và ra giữa tiền mã hóa và hệ thống ngân hàng truyền thống (chính USDC). Bởi vì "nợ" của USDC chỉ là token ERC20 trên chuỗi, chứng minh nợ là "miễn phí", chỉ cần chứng minh tài sản.

Plasma và validium: Chúng ta có thể làm cho CEX không bị ràng buộc không?

Giả sử chúng ta muốn tiến xa hơn: chúng ta không chỉ muốn chứng minh rằng sàn giao dịch có đủ tiền để hoàn trả tiền của người dùng. Ngược lại, chúng ta muốn hoàn toàn ngăn chặn sàn giao dịch đánh cắp tiền của người dùng.

Nỗ lực lớn đầu tiên trong lĩnh vực này là Plasma, một giải pháp mở rộng phổ biến trong cộng đồng nghiên cứu Ethereum vào năm 2017 và 2018. Cách Plasma hoạt động là chia số dư thành một tập hợp các "đồng coin" riêng biệt, mỗi đồng coin được gán một chỉ số và nằm ở một vị trí cụ thể trong cây Merkle của khối Plasma. Để chuyển nhượng một đồng coin một cách hợp lệ, cần phải đặt giao dịch vào vị trí đúng trong cây, và gốc của cây sẽ được công bố trên chuỗi.

Hình minh họa đơn giản hóa quá mức của một phiên bản Plasma. Các đồng coin được lưu trữ trong hợp đồng thông minh, và khi rút tiền, các quy tắc của giao thức Plasma sẽ được thực thi.

OmiseGo đã cố gắng xây dựng một sàn giao dịch phi tập trung dựa trên giao thức này, nhưng kể từ đó, họ đã chuyển sang các ý tưởng khác - và Plasma Group cũng vậy, hiện đang là một dự án rollup EVM lạc quan ++Optimism++.

Các giới hạn kỹ thuật của Plasma được hình dung vào năm 2018 (ví dụ, ++chứng minh phân mảnh đồng coin++) không đáng để xem xét. Kể từ đỉnh cao của luận văn Plasma vào năm 2018, ZK-SNARKs đã trở nên khả thi hơn trong các trường hợp sử dụng liên quan đến mở rộng, như chúng ta đã nói ở trên, ZK-SNARKs đã thay đổi mọi thứ.

Phiên bản hiện đại hơn của ý tưởng Plasma là cái gọi là ++validium++: về cơ bản giống như ZK-rollup, chỉ khác là dữ liệu được lưu trữ ngoài chuỗi. Cấu trúc này có thể được sử dụng cho nhiều trường hợp sử dụng, có thể tưởng tượng bất kỳ máy chủ tập trung nào cần chạy một số mã và chứng minh rằng nó đã thực hiện mã một cách chính xác. Trong một validium, nhà điều hành không có cách nào để đánh cắp tiền, mặc dù tùy thuộc vào chi tiết thực hiện, nếu nhà điều hành biến mất, một số lượng tiền của người dùng có thể bị kẹt lại.

Tất cả điều này thực sự rất tốt: CEX và DEX không phải là một mối quan hệ nhị phân, thực tế cho thấy, nó có một loạt các lựa chọn, bao gồm nhiều hình thức tập trung hỗn hợp, bạn có thể nhận được một số lợi ích như hiệu quả, nhưng vẫn có nhiều hàng rào mã hóa để ngăn chặn các nhà điều hành tập trung tham gia vào hầu hết các hình thức lạm dụng.

Tuy nhiên, ở nửa bên phải của không gian thiết kế này, chúng ta vẫn cần thảo luận về một vấn đề cơ bản nhất: Xử lý lỗi của người dùng. Đến nay, loại lỗi quan trọng nhất là: nếu người dùng quên mật khẩu của họ, mất thiết bị của họ, bị tấn công, hoặc bằng cách nào đó mất quyền truy cập vào tài khoản của họ, thì phải làm gì?

Sàn giao dịch có thể giải quyết vấn đề này: đầu tiên là phục hồi qua email, nếu điều này cũng thất bại, có thể phục hồi theo hình thức phức tạp hơn thông qua KYC. Tuy nhiên, để có thể giải quyết vấn đề như vậy, sàn giao dịch cần thực sự kiểm soát đồng coin. Để có khả năng phục hồi tiền của người dùng với lý do chính đáng, sàn giao dịch cần có quyền lực, điều này cũng có thể được sử dụng để đánh cắp tiền của người dùng với lý do xấu. Đây là một sự đánh đổi không thể tránh khỏi.

Giải pháp lý tưởng lâu dài là dựa vào tự quản lý, và được hỗ trợ bởi ++chữ ký đa++ ++và ví phục hồi xã hội++ và các công nghệ khác, giúp người dùng xử lý tình huống khẩn cấp. Nhưng trong ngắn hạn, có hai lựa chọn thay thế rõ ràng với chi phí và lợi ích khác nhau rõ rệt.

Kết luận: Sàn giao dịch tốt hơn trong tương lai

Trong ngắn hạn, có hai "thể loại" sàn giao dịch rõ ràng: sàn giao dịch có quản lý và sàn giao dịch không có quản lý. Ngày nay, thể loại sau chỉ là các DEX, như Uniswap, trong tương lai, chúng ta cũng có thể thấy các CEX "bị ràng buộc" về mặt mã hóa, tiền của người dùng được giữ trong một thứ gì đó giống như hợp đồng thông minh validium. Chúng ta cũng có thể thấy các sàn giao dịch bán quản lý, nơi chúng ta tin tưởng họ bằng tiền pháp định thay vì tiền mã hóa.

Cả hai loại sàn giao dịch này sẽ tiếp tục tồn tại, và cách đơn giản nhất để cải thiện an ninh cho sàn giao dịch có quản lý là tăng cường chứng minh dự trữ. Điều này bao gồm sự kết hợp giữa chứng minh tài sản và chứng minh nợ. Việc phát triển các giao thức tốt cho cả hai điều này có những thách thức kỹ thuật, nhưng chúng ta cũng nên tiến bộ trong cả hai lĩnh vực này càng nhiều càng tốt và mở mã phần mềm và quy trình để tất cả các sàn giao dịch đều có thể hưởng lợi.

Trong tương lai xa hơn, tôi hy vọng rằng chúng ta sẽ ngày càng gần hơn đến việc tất cả các sàn giao dịch đều không có quản lý, ít nhất là về mặt tiền mã hóa. Việc phục hồi ví sẽ tồn tại, đối với những người dùng mới xử lý các khoản tiền nhỏ, cũng như các tổ chức cần sắp xếp như vậy vì lý do pháp lý, có thể cần có các tùy chọn phục hồi tập trung cao, nhưng điều này có thể được thực hiện ở cấp độ ví thay vì trong chính sàn giao dịch. Cách tương tác của ++magic.link++ với ++Polymarket++ là một ví dụ về phương pháp này. Về mặt tiền pháp định, dòng chảy giữa hệ thống ngân hàng truyền thống và hệ sinh thái tiền mã hóa có thể được thực hiện thông qua quy trình dòng tiền vào/ra địa phương của các stablecoin được hỗ trợ bởi tài sản (như USDC). Tuy nhiên, sẽ cần một thời gian trước khi chúng ta hoàn toàn đạt được mục tiêu này.

Đặc biệt cảm ơn Balaji Srinivasan, cũng như các cuộc thảo luận với nhân viên của Coinbase, Kraken và Binance.