Bài viết này nhằm mục đích giải thích các nguyên tắc cơ bản của bằng chứng trao đổi về sàn giao dịch và khám phá thêm nhiều khả năng hơn ở giữa CEX và DEX, hai đầu của phổ lưu ký tài sản.
Văn bản gốc: Có CEX an Safe : bằng chứng về khả năng thanh toán và hơn thế nữa (vitalik.ca)
Tác giả: Vitalik Buterin
Bản dịch: chi tiêu gấp đôi (@doublespending)
Người đánh giá: ECN
Ảnh bìa: Ảnh của Pawel Czerwinski trên Bapt
Đặc biệt cảm ơn Balaji Srinivasan và đội ngũ Coinbase, Kraken và Binance vì cuộc thảo luận.
Bất cứ khi nào một sàn giao dịch tập trung lớn gặp sự cố, một câu hỏi thường được đặt ra là liệu chúng ta có thể sử dụng crypto để giải quyết vấn đề hay không. Sàn giao dịch có thể tạo bằng chứng mật mã để chứng minh rằng số tiền nắm giữ trên Chuỗi của họ đủ để trả nợ cho người dùng, thay vì chỉ dựa vào các giải pháp "tiền tệ hợp pháp" như giấy phép của chính phủ, kiểm toán, điều tra quản trị doanh nghiệp và kiểm tra lại của pháp nhân sàn giao dịch.
Tham vọng hơn, sàn giao dịch có thể thiết lập một hệ thống trong đó tiền của người gửi không thể rút nếu không có sự đồng ý của họ. Chúng ta có thể cố gắng khám phá ranh giới giữa một CEX chuyên nghiệp “không làm điều ác” và một DEX trên Chuỗi kém hiệu quả “không thể làm điều ác” nhưng làm 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 làm cho CEX trở nên đáng tin cậy hơn, những hạn chế của công nghệ được sử dụng thay thế và một số phương pháp mạnh mẽ dựa trên các công nghệ tiên tiến như ZK-SNARK.
Bảng số dư và cây Merkle: bằng chứng truyền thống về khả năng thanh toán
Những nỗ lực sớm nhất của sàn giao dịch nhằm sử dụng mật mã để chứng minh rằng họ không lừa dối người dùng đã có từ rất lâu. Vào năm 2011, MtGox, sàn giao dịch Bitcoin lớn nhất vào thời điểm đó, đã chứng minh rằng họ sở hữu số tiền này bằng cách gửi một giao dịch chuyển 424.242 BTC đến một địa chỉ được thông báo trước. Vào năm 2013, các cuộc thảo luận đã bắt đầu về cách giải quyết mặt khác của vấn đề: chứng minh tổng quy mô tiền gửi của người dùng. Nếu bạn chứng minh private key số tiền gửi token người dùng tài sản thì sàn giao dịch đủ tiền để hoàn trả cho người gửi tiền.
Phương pháp dễ nhất để cung cấp bằng chứng gửi tiền là xuất bản một danh sách. Mỗi người dùng có thể kiểm tra số dư của mình trong danh sách và bất kỳ ai cũng có thể kiểm tra danh sách đầy đủ: (i) mỗi số dư không âm; (ii) tổng số tiền là số tiền được yêu cầu.
Tất nhiên, điều này vi phạm quyền riêng tư, vì vậy chúng tôi có thể thay đổi sơ đồ một chút: xuất bản danh sách và gửi riêng giá trị muối cho người dùng. Nhưng ngay cả điều này cũng sẽ làm rò rỉ số dư và sự phân phối của nó. Để bảo vệ quyền riêng tư, chúng tôi sử dụng công nghệ tiếp theo: công nghệ cây Merkle.
Màu xanh lá cây: Nút của Charlie . Màu xanh lam: Charlie nhận được nút để chứng minh. Màu vàng: nút, thông báo cho mọi người
Công nghệ cây Merkle sẽ đưa bảng số dư của người dùng vào cây tổng Merkle. Trong cây tổng Merkle, mỗi nút là một cặp. Nút lá bên dưới thể hiện số dư của mỗi người dùng và hàm băm muối của tên người dùng. Trong mỗi nút cấp cao hơn, số dư là tổng số dư của hai nút bên dưới và hàm băm là hàm băm của hai nút bên dưới. Bằng chứng tổng Merkle, giống như bằng chứng Merkle, là một "nhánh" bao gồm tất cả nút chị em trên đường dẫn từ nút lá đến nút .
Đầu tiên, sàn giao dịch sẽ gửi cho mỗi người dùng bằng chứng Merkle về số dư của họ. Sau đó, người dùng có thể chắc chắn rằng số dư của họ được tính chính xác vào tổng số. Mã ví dụ đơn giản có thể được tìm thấy ở đây.
# The function for computing a parent node given two child nodesdef combine_tree_nodes(L, R):L_hash, L_balance = LR_hash, R_balance = Rassert L_balance >= 0 and R_balance >= 0new_node_hash = hash(L_hash + L_balance.to_bytes(32, 'big') +R_hash + R_balance.to_bytes(32, 'big'))return (new_node_hash, L_balance + R_balance)# Xây dựng một cây Merkle đầy đủ Được lưu trữ ở dạng phẳng trong đó # nút i là cha của các nút 2i và 2i+1def build_merkle_sum_tree(user_table: "List[(username, salt, Balance)]"):tree_size = get_next_power_of_2(len(user_table))tree = ([None] * tree_size +[userdata_to_leaf(*user) cho người dùng trong user_table] +[EMPTY_LEAF for _ in range(tree_size - len(user_table))])for i in range(tree_size - 1, 0, -1):tree[i] = Combine_tree_nodes(tree[i*2], tree[i* 2+1])return tree# Root của cây được lưu trữ ở chỉ số 1 ở dạng phẳngdef get_root(tree):return tree[1]# Lấy bằng chứng cho một nút tại một chỉ mục cụ thểdef get_proof(tree, index):branch_length = log2(len(tree)) - 1# ^ = bitwise xor, x ^ 1 = nút chị em của xindex_in_tree = index + len(tree) // 2return [tree[(index_in_tree // 2**i) ^ 1] for i in range(branch_length)]# Xác minh bằng chứng (duh)def verify_proof(tên người dùng, muối, số dư, chỉ mục, user_table_size, root, proof):leaf = userdata_to_leaf(tên người dùng, muối, số dư)branch_length = log2(get_next_power_of_2(user_table_size) ) - 1for i in range(branch_length):if chỉ mục & (2**i):leaf = Combine_tree_nodes(proof[i], leaf)else:leaf = Combine_tree_nodes(leaf, proof[i])return leaf == root
Rò rỉ quyền riêng tư theo thiết kế này thấp hơn nhiều so với việc xuất bản bảng số dư hoàn chỉnh và rủi ro rò rỉ quyền riêng tư có thể giảm hơn nữa bằng cách làm gián đoạn từng nhánh lần root Merkle được phát hành, nhưng vẫn có một số vấn đề rò rỉ quyền riêng tư: Charlie biết điều đó ai đó Số dư của một người là 164 ETH, tổng số dư của hai người dùng nhất định là 70 ETH, v.v. Kẻ tấn công kiểm soát nhiều tài khoản vẫn có thể tìm hiểu lượng lớn về người dùng 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 số dư dư âm : nếu sàn giao dịch có số dư người dùng là 1390 ETH nhưng chỉ có khoản dự trữ 890 ETH cố gắng bù đắp bằng cách thêm số dư-500 ETH vào một tài khoản giả ở đâu đó trên cây thì sao? Tôi làm gì về sự khác biệt? Khả năng này thực sự không phá vỡ sơ đồ, đó là lý do tại sao chúng tôi đặc biệt sử dụng cây tổng Merkle thay vì cây Merkle thông thường. Giả sử Henry là một tài khoản giả do sàn giao dịch kiểm soát và sàn giao dịch đặt -500 ETH trên đó:
Xác minh của Greta sẽ không thành công: khi sàn giao dịch phải đưa cho cô ấy nút Henry với số dư -500 ETH, cô ấy sẽ từ chối nút không hợp lệ . Eve và Fred cũng sẽ không xác minh được vì số dư nút trung gian trên Henry là -230 ETH, do đó nút này cũng không hợp lệ! Để hành vi trộm cắp không bị phát hiện, sàn giao dịch chỉ có thể hy vọng rằng không có ai ở nửa bên phải của cây kiểm tra chứng chỉ số dư của nó.
Nếu sàn giao dịch có thể chọn ra những người dùng có 500 ETH mà không thèm kiểm tra bằng chứng số số dư hoặc những người không được tin tưởng khi họ phàn nàn về việc không nhận được bằng chứng số dư thì sàn giao dịch có thể thoát khỏi vấn đề đó. Tuy nhiên, sàn giao dịch cũng có thể đạt được hiệu quả tương tự bằng cách loại trừ những người dùng này khỏi cây tổng Merkle. Vì vậy, về mặt chứng minh nợ, công nghệ cây Merkle về cơ bản đáp ứng được nhu cầu. Nhưng các tính năng riêng tư của nó vẫn còn kém lý tưởng. Bạn có thể sử dụng cây Merkle một khéo léo hơn để cải thiện, chẳng hạn như satoshi hoặc wei như một nút lá độc lập. Tuy nhiên, thậm chí tốt hơn có thể được thực hiện bằng cách sử dụng công nghệ tiên tiến hơn.
Sử dụng ZK-SNARK để cải thiện quyền riêng tư và độ tin cậy
ZK-SNARK là một công nghệ mạnh mẽ. ZK-SNARK dùng để mã hóa giống như trí tuệ nhân tạo: một công nghệ đủ tổng quát để áp đảo sê-ri các kỹ thuật chuyên biệt được phát triển cách đây nhiều thập kỷ nhằm giải quyết sê-ri vấn đề. Vì vậy, chúng tôi chắc chắn có thể sử dụng ZK-SNARK để đơn giản hóa và cải thiện đáng kể quyền riêng tư trong các giao thức bằng chứng nợ.
Chúng ta có thể chỉ cần đặt tất cả tiền gửi của người dùng vào cây Merkle (hoặc cam kết KZG đơn giản hơn) và sử dụng ZK-SNARK để chứng minh rằng tất cả số dư trong cây đều không âm và cộng lại bằng một số giá trị được yêu cầu. Nếu chúng tôi thêm một lớp băm để đảm bảo quyền riêng tư thì nhánh Merkle (hoặc bằng chứng KZG) được cấp cho 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 phương pháp để tránh rò rỉ quyền riêng tư vì nó không yêu cầu cung cấp "nút chị em" làm bằng chứng và ZK-SNARK đơn giản có thể được sử dụng để chứng minh rằng số dư là không âm và mỗi số dư là không âm.
Chúng ta có thể chứng minh số dư số dư trong KZG ở trên và tính không âm của nó thông qua ZK-SNARK chuyên dụng. Đây là một ví dụ đơn giản. Chúng tôi giới thiệu một đa thức phụ trợ I(x) "xây dựng từng bit của số dư của người dùng " (vì ví dụ: giả sử số dư dưới 215), trong đó mỗi bit thứ 16 chỉ theo dõi sự khác biệt được đảm bảo nếu tổng thực tế là giống như đã xác nhận Giá trị sẽ chỉ bằng 0 nếu tổng số tiền bằng nhau. Nếu z là một nghiệm nguyên thủy cấp 128, chúng ta có thể chứng minh rằng phương trình đúng:
Bạn có thể tham khảo cách chuyển đổi các phương trình này thành đa thức và sau đó thành ZK-SNARK ở đây và ở những nơi khác trong bài viết của tôi về ZK-SNARK. Đây không phải là một giao thức tối ưu nhưng làm cho các bằng chứng mật mã này dễ hiểu hơn!
Chỉ với một vài phương trình bổ sung, hệ thống ràng buộc có thể được điều chỉnh phù hợp với các cài đặt phức tạp hơn. Ví dụ: trong hệ thống giao dịch có đòn bẩy, người dùng cá nhân có thể có số dư dư âm nhưng chỉ khi họ có đủ tài sản thế chấp để trang trải các khoản nợ của mình. SNARK có thể được sử dụng để chứng minh ràng buộc phức tạp hơn này, đảm bảo với người dùng rằng sàn giao dịch không thể bí mật miễn trừ một số người dùng nhất định và do đó gây nguy hiểm cho tài sản của người dùng.
Về lâu dài, việc sử dụng bằng chứng trách nhiệm pháp lý ZK này không chỉ giới hạn ở việc người dùng gửi tiền trên sàn giao dịch mà còn có thể được sử dụng trong nhiều tình huống cho vay hơn. Bất kỳ ai đi vay sẽ đặt bản ghi vào một đa thức hoặc một cây chứa khoản vay và gốc được xuất bản 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 Bằng chứng không tri thức cho người cho vay để chứng minh rằng họ chưa nhận được nhiều khoản vay khác. Cuối cùng, những đổi mới về pháp lý thậm chí có thể cho phép các khoản vay được cam kết theo cách này có mức độ ưu tiên cao hơn các khoản vay không được cam kết. Điều này trùng hợp với ý tưởng mà chúng tôi đã thảo luận trong " Xã hội phi tập trung: Tìm kiếm linh hồn của Web3": thông qua một số dạng "token buộc linh hồn", khái niệm về danh tiếng tiêu cực trên Chuỗi có thể thực hiện được.
Bằng chứng về tài sản
Phiên bản đơn giản nhất của Bằng chứng tài sản là giao thức mà chúng ta đã thấy ở trên: để chứng minh rằng bạn nắm giữ X token, bạn chỉ cần di chuyển X token vào một thời điểm định trước hoặc mang thông báo "số tiền này thuộc về Binance" trong giao dịch. Để tránh phải trả phí giao dịch, bạn có thể ký một tin nhắn ngoài Chuỗi. Cả Bitcoin và Ethereum đều có tiêu chuẩn cho các thông điệp chữ ký ngoài Chuỗi.
Có hai vấn đề thực tế với công nghệ chứng minh tài sản đơn giản này:
● Xử lý ví lạnh
● Tái sử dụng tài sản thế chấp
Vì lý do bảo mật, hầu hết sàn giao dịch đều lưu trữ phần lớn tiền của người dùng trong ví lạnh: trên máy tính ngoại tuyến, nơi các giao dịch cần được ký thủ công và đưa lên internet. Phương pháp này rất phổ biến: ví lạnh mà tôi sử dụng để lưu trữ tiền cá nhân của mình nằm trên một máy tính ngoại tuyến vĩnh viễn, tạo ra Mã QR Mã QR chứa các giao dịch đã ký, sau đó tôi sẽ quét bằng điện thoại của mình. Do lượng tiền lớn, các giao thức bảo mật được sàn giao dịch sử dụng sẽ phức tạp hơn, thường liên quan đến tính toán bên long trên nhiều thiết bị, nhằm giảm hơn nữa khả năng một thiết bị bị hack và gây rò rỉ khóa. Trong bối cảnh này, ngay cả việc tạo một thông báo bổ sung để chứng minh quyền kiểm soát một địa chỉ cũng là một hoạt động tốn kém!
Sàn giao dịch có thể sử dụng các phương pháp sau:
● Duy trì một số địa chỉ công cộng lâu dài. Sàn giao dịch tạo ra một số địa chỉ, chỉ đưa ra bằng chứng về quyền sở hữu của mỗi địa chỉ một lần và sau đó sử dụng lại các địa chỉ đó. Đây là giải pháp đơn giản nhất cho đến nay, mặc dù nó bổ sung một số hạn chế để bảo vệ tính bảo mật và quyền riêng tư.
● Giữ nhiều địa chỉ và sau đó chứng minh ngẫu nhiên một vài địa chỉ. Sàn giao dịch nắm giữ nhiều địa chỉ và mỗi địa chỉ thậm chí chỉ có thể được sử dụng một lần và không còn được sử dụng sau lần giao dịch. Trong trường hợp này, sàn giao dịch cần có một giao thức chọn ngẫu nhiên một số địa chỉ mà thỉnh thoảng sàn giao dịch phải “mở” để chứng minh quyền sở hữu. Một số sàn giao dịch đã thực hiện các hoạt động tương tự với kiểm toán, nhưng về nguyên tắc, công nghệ này có thể được chuyển đổi thành một quy trình hoàn toàn tự động.
● Phương pháp ZKP phức tạp hơn. Ví dụ: sàn giao dịch có thể thiết lập đa chữ ký 1/2 cho tất cả các địa chỉ của nó, trong đó một trong đó các địa chỉ có khóa khác và địa chỉ kia có cùng khóa theo một cách phức tạp nhưng an toàn nào đó (ví dụ: 12/16 đa chữ ký ) để lưu trữ các phiên bản mù dự phòng khẩn cấp quan trọng. Để bảo vệ quyền riêng tư và tránh rò rỉ địa chỉ đầy đủ của họ, sàn giao dịch thậm chí có thể chạy Bằng chứng không tri thức trên blockchain để chứng minh tổng số dư địa chỉ trên Chuỗi ở định dạng này.
Một vấn đề lớn khác là ngăn chặn việc tái sử dụng tài sản thế chấp. Sàn giao dịch thường dễ dàng di chuyển tài sản thế chấp qua lại với nhau để chứng minh nguồn dự trữ, khiến họ có thể thoát khỏi tình trạng mất khả năng thanh toán một cách hiệu quả. Lý tưởng nhất là bằng chứng về khả năng thanh toán phải được thực hiện trong thời gian thực, với bằng chứng được cập nhật sau mỗi khối. Nếu điều này không thực tế, điều tốt nhất tiếp theo là điều phối thời gian cố định giữa sàn giao dịch để kiểm chứng, chẳng hạn như kiểm chứng dự trữ vào Thứ Ba hàng tuần lúc 2 giờ chiều theo giờ UTC.
Câu hỏi cuối cùng là: Bằng chứng tài sản có thể được thực hiện bằng tiền hợp pháp không? Sàn giao dịch không chỉ nắm giữ crypto mà còn nắm giữ cả tiền pháp định trong hệ thống ngân hàng. Về vấn đề này, câu trả lời là có, nhưng một chương trình như vậy chắc chắn sẽ dựa vào mô hình ủy thác "fiat": bản thân ngân hàng có thể chứng nhận số dư, kiểm toán có thể chứng nhận bảng tài sản, v.v. Vì tiền tệ fiat không thể được xác minh bằng mật mã nên đây là giải pháp tốt nhất trong khuôn khổ và vẫn đáng thực hiện.
Một phương pháp khác là tách thực thể A và thực thể B. A chịu trách nhiệm điều hành sàn giao dịch và xử lý USDC , stablecoin được hỗ trợ bởi một số tài sản , trong khi B chịu trách nhiệm xử lý dòng tiền vào và các giao dịch giữa crypto và hệ thống ngân hàng truyền thống. dòng tiền chảy ra, trong trường hợp này B chính là USDC. Vì "nợ" của USDC chỉ là token ERC20 trên Chuỗi nên bằng chứng về trách nhiệm pháp lý có thể được "dễ dàng" lấy được và chúng ta chỉ cần giải quyết vấn đề về bằng chứng về tài sản.
Plasma và validium: Chúng tôi có thể triển khai CEX không được quản lý không?
Giả sử chúng tôi muốn tiến thêm một bước nữa: chúng tôi không muốn chỉ chứng minh rằng sàn giao dịch có đủ tiền để trả nợ cho người dùng. Thay vào đó, chúng tôi muốn ngăn chặn hoàn toàn các giao dịch lấy cắp tiền của người dùng.
Người đầu tiên thử điều này là Plasma, một giải pháp mở rộng quy mô đã trở nên phổ biến trong cộng đồng nghiên cứu Ethereum vào năm 2017 và 2018. Plasma hoạt động bằng cách chia số dư thành một tập hợp các "token" độc lập, với mỗi token được gán một chỉ mục và được đặt ở một vị trí cụ thể trong cây Merkle của khối Plasma. Để quá trình chuyển token hợp lệ diễn ra, giao dịch cần được đặt ở đúng vị trí trong cây và gốc của cây được xuất bản lên Chuỗi.
Sơ đồ tối giản của một phiên bản Plasma. Token được giữ trong một hợp đồng thông minh thực thi các quy tắc của giao thức Plasma khi rút tiền.
OmiseGo đã cố gắng tạo ra 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 những thứ khác – cũng như Plasma Group, với dự án optimistic rollup Optimism của họ.
Các cuộc thảo luận vào năm 2018 về những hạn chế của Plasma (chẳng hạn như chống phân mảnh bằng token) khiến mọi người về cơ bản nghi ngờ về tính khả thi của Plasma. Kể từ khi cuộc thảo luận về Plasma lên đến đỉnh điểm vào năm 2018, ZK-SNARK ngày càng trở nên khả thi đối với các trường hợp sử dụng liên quan đến mở rộng quy mô và như chúng tôi đã nói ở trên, ZK-SNARK thay đổi mọi thứ.
Phiên bản cập nhật của Plasma được Starkware gọi là validium: về cơ bản giống như ZK-rollup, ngoại trừ việc dữ liệu được giữ ngoài Chuỗi. Cấu trúc này phù hợp với nhiều trường hợp sử dụng và có thể áp dụng được cho bất kỳ tình huống nào mà máy chủ tập trung cần chứng minh rằng nó đang thực thi mã chính xác. Trong validium, nhà điều hành không thể lấy cắp tiền, nhưng tùy thuộc vào chi tiết triển khai, một số tiền của người dùng có thể bị kẹt nếu nhà điều hành biến mất.
Mọi thứ bây giờ có vẻ ổn: CEX và DEX còn lâu mới đạt được/hoặc, hóa ra, trong đó sê-ri lựa chọn, bao gồm nhiều hình thức tập trung kết hợp khác nhau, nơi bạn nhận được một số lợi ích, chẳng hạn như tính hiệu quả, nhưng vẫn có rất nhiều lợi ích. Bảo vệ học tập bằng tiền điện tử có thể ngăn chặn hầu hết các dạng hành vi nguy hiểm của các nhà khai thác tập trung.
Tuy nhiên, câu hỏi cơ bản còn lại đáng suy nghĩ: làm thế nào để xử lý lỗi của người dùng. Cho đến nay, loại lỗi quan trọng nhất là: Điều gì sẽ xảy ra nếu người dùng quên mật khẩu, mất thiết bị, bị hack hoặc mất quyền truy cập vào tài khoản của họ?
Sàn giao dịch có thể giải quyết vấn đề này: trước tiên hãy sử dụng tính năng khôi phục email và nếu điều đó không thành công, hãy tiến hành khôi phục phức tạp hơn thông qua KYC. Nhưng để giải quyết những vấn đề này, sàn giao dịch cần thực sự kiểm soát các token này. Để có thể thu hồi tiền của người dùng một cách hợp lý, sàn giao dịch cần có quyền hạn tương tự có thể được sử dụng để đánh cắp tiền của người dùng mà không cần lý do. Đây là một sự đánh đổi không thể tránh khỏi.
Giải pháp dài hạn lý tưởng là dựa vào tự lưu ký, nơi người dùng có thể dễ dàng sử dụng các công nghệ như ví đa chữ ký và ví phục hồi xã hội trong tương lai để giúp giải quyết các trường hợp khẩn cấp. Trong ngắn hạn, có hai lựa chọn thay thế rõ ràng với chi phí và lợi nhuận khác nhau:
Một vấn đề quan trọng khác là hỗ trợ xuyên Chuỗi: sàn giao dịch cần hỗ trợ nhiều Chuỗi khác nhau, các hệ thống như Plasma và validium cần được mã hóa bằng các ngôn ngữ khác nhau để hỗ trợ các nền tảng khác nhau và ở dạng hiện tại của chúng không thể được sử dụng trên một số nền tảng (đặc biệt là Bitcoin), điều này dự kiến sẽ được giải quyết thông qua nâng cấp và tiêu chuẩn hóa công nghệ; tuy nhiên, trong ngắn hạn, đây là một lý do khác để sàn giao dịch giám hộ ngày nay duy trì mô hình lưu ký.
Kết luận: Hướng tới một sàn giao dịch tốt hơn trong tương lai
Trong ngắn hạn, có hai 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 giám sát. Ngày nay, loại thứ hai là các DEX như Uniswap và trong tương lai, chúng ta cũng có thể thấy các CEX được quản lý bằng mật mã, trong đó tiền của người dùng được giữ theo cách tương tự như hợp đồng thông minh validium. Chúng ta cũng có thể thấy sàn giao dịch bán giám hộ, trong đó chúng ta tin tưởng vào việc họ xử lý tiền tệ truyền thống hơn là crypto.
Cả hai loại sàn giao dịch đều vẫn tồn tại và phương pháp tương thích ngược dễ dàng nhất để cải thiện tính bảo mật của sàn giao dịch giám sát là thêm bằng chứng dự phòng. Điều này bao gồm sự kết hợp giữa bằng chứng về tài sản và bằng chứng về trách nhiệm pháp lý. Vẫn còn một số thách thức trong việc thiết kế các giao thức tốt cho cả hai, nhưng chúng ta có thể và nên thúc đẩy cả hai loại công nghệ song hành với nhau cũng như các chương trình và phần mềm mã nguồn mở nếu có thể để tất cả sàn giao dịch đều có thể hưởng lợi.
Về lâu dài, tôi hy vọng chúng ta sẽ tiến tới một tình huống mà tất cả sàn giao dịch đều không bị giám sát, ít nhất là đối với crypto. Việc khôi phục ví sẽ tồn tại và có thể cần có các tùy chọn khôi phục tập trung cao độ cho người dùng mới với số tiền nhỏ và các tổ chức yêu cầu các thỏa thuận như vậy vì lý do pháp lý, nhưng điều này có thể được thực hiện ở lớp ví thay vì trong sàn giao dịch. Về tiền tệ fiat, sự chuyển động giữa hệ thống ngân hàng truyền thống và hệ sinh thái crypto có thể được hoàn thành thông qua quá trình dòng vốn vào và dòng tiền ra có nguồn gốc từ stablecoin được hỗ trợ tài sản như USDC. Tuy nhiên, chúng ta vẫn còn một chặng đường dài để đi.
[1] Ghi chú của người dịch:➤ Cứ 16 số đại diện cho một người dùng (15 số đầu tiên thể hiện số dư của người dùng, còn chữ số cuối thể hiện sự chênh lệch giữa tổng số dư người dùng đến thời điểm hiện tại và sao kê). Chúng ta có thể thấy rằng ví dụ trên đại diện cho hai người dùng (bạn đọc nên hiểu rõ hơn ở đây)
➤ Số dư người dùng trung bình được yêu cầu : 185
➤ Số dư của người dùng 1 : 20 -> 000 0000 0001 0100
Chênh lệch: 20 – 185 = -165
➤ Số dư của người dùng 2 : 50 -> 000 0101 0011 0010
Hiệu: -165 + 50 -185 = -300
➤ Sau khi duyệt xong tất cả người dùng, yêu cầu khác biệt của người dùng cuối cùng là 0
➤ Giải thích bốn phương trình
Phương trình 1: Giá trị ban đầu của đệ quy là 0
Phương trình 2: Số dư của mỗi người dùng cần tương ứng với cam kết của KZG
Công thức 3: Công thức đệ quy cho số dư của từng người dùng, số dư ràng buộc >= 0 và < 214
(Câu trên cho rằng số dư< 215 phải là lỗi văn thư, vì theo phương trình 3, công thức đệ quy chỉ có 14 giá trị, I(zi) < 214,
16 số tương ứng với: I(z{16x})=0| I(z{16x+1}) | I(z{16x+2}) |
Giá trị lớn nhất tương ứng với 16 số: 0 | 21 -1| 22 -1 … |
Phương trình 4: Ràng buộc tổng số dư của tất cả người dùng phải phù hợp với số dư sàn giao dịch khai báo
Đặc biệt cảm ơn tình nguyện viên dịch thuật cộng đồng ECN @doublespending vì sự đóng góp của anh ấy cho việc dịch bài viết này.
Tuyên bố miễn trừ trách nhiệm: Là một nền tảng thông tin blockchain, các bài viết được xuất bản trên trang này chỉ thể hiện quan điểm cá nhân của tác giả và khách và không liên quan gì đến quan điểm của Web3Caff. Thông tin trong bài viết chỉ tham khảo và không cấu thành bất kỳ lời khuyên hay đề nghị đầu tư nào. Vui lòng tuân thủ luật pháp và quy định có liên quan của quốc gia hoặc khu vực nơi bạn sinh sống.
