Tiêu đề ban đầu: "Having a safe CEX: proof of solvency and beyond》
Tiêu đề ban đầu: "
Tác giả gốc: Vitalik Buterin
Biên dịch nguyên văn: Double Spending (@doublespending)
Đặc biệt cảm ơn Balaji Srinivasan và các nhóm tại Coinbase, Kraken và Binance vì những cuộc thảo luận của họ.
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 mã hóa để giải quyết vấn đề này hay không. Sàn giao dịch có thể chứng minh rằng số tiền được giữ trên chuỗi của nó đủ để hoàn trả cho người dùng bằng cách tạo bằng chứng mã hóa, thay vì chỉ dựa vào giấy phép của chính phủ, kiểm toán viên, điều tra về quản trị doanh nghiệp và các chương trình “tiền tệ hợp pháp” chẳng hạn như truy ngược lại pháp nhân.
Tham vọng hơn, một sàn giao dịch có thể tạo ra một hệ thống mà tiền của người gửi tiền không thể bị rút mà không có sự đồng ý của họ. Chúng ta có thể cố gắng khám phá ranh giới giữa CEX chuyên nghiệp "không làm điều ác" và DEX trên chuỗi không hiệu quả "không thể làm điều ác" nhưng rò rỉ quyền riêng tư. Bài đăng này sẽ đi sâu vào các 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ủa họ và một số phương tiện mạnh mẽ dựa vào các kỹ thuật tiên tiến như ZK-SNARK.
Bảng cân đối và cây Merkle: Bằng chứng hoàn trả truyền thống
Những nỗ lực sớm nhất của các 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ừ 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 bằng cách gửi một giao dịch chuyển 424.242 BTC đến một địa chỉ được công bố 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 rằng khoản tiền gửi của người dùng bằng X (bằng chứng về trách nhiệm pháp lý) và chứng minh rằng bạn có khóa riêng cho mã thông báo X (bằng chứng về tài sản), thì bạn cung cấp bằng chứng về khả năng thanh toán: bạn chứng minh sàn giao dịch có đủ tiền để hoàn trả người gửi tiền.
Cách dễ nhất để cung cấp bằng chứng về khoản tiền gửi là xuất bản một danh sách. Mọi người dùng đều 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ư đều không âm; (ii) tổng số tiền là số tiền đã khai báo.
list và gửi giá trị muối một cách riêng tư cho người dùng. Nhưng ngay cả điều này cũng làm rò rỉ số dư và phân phối của nó. Để bảo vệ quyền riêng tư, chúng tôi đã áp dụng một công nghệ tiếp theo: Công nghệ cây Merkle.
Màu xanh lá cây: Nút của Charlie. Xanh da trời: Charlie đã nhận được một nút để chứng thực. Màu vàng: nút gốc, 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. Các nút lá bên dưới đại diện cho số dư người dùng cá nhân và 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ả các nút chị em trên đường dẫn từ nút lá đến nút gốc.
# The function for computing a parent node given two child nodes
def combine_tree_nodes(L, R):
L_hash, L_balance = L
R_hash, R_balance = R
assert L_balance >= 0 and R_balance >= 0
new_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)
# Builds a full Merkle tree. Stored in flattened form where
# node i is the parent of nodes 2 i and 2 i+ 1
def 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) for user in 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 of a tree is stored at index 1 in the flattened form
def get_root(tree):
return tree[ 1 ]
# Gets a proof for a node at a particular index
def get_proof(tree, index):
branch_length = log 2(len(tree)) - 1
# ^ = bitwise xor, x ^ 1 = sister node of x
index_in_tree = index + len(tree) // 2
return [tree[(index_in_tree // 2**i) ^ 1 ] for i in range(branch_length)]
# Verifies a proof (duh)
def verify_proof(username, salt, balance, index, user_table_size, root, proof):
leaf = userdata_to_leaf(username, salt, balance)
branch_length = log 2(get_next_power_of_ 2(user_table_size)) - 1
for i in range(branch_length):
if index & ( 2**i):
leaf = combine_tree_nodes(proof[i], leaf)
else:
leaf = combine_tree_nodes(leaf, proof[i])
return leaf == root
Đầu tiên, sàn giao dịch gửi cho mỗi người dùng một bằng chứng tổ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 mình đã được tính chính xác như một phần của tổng số. Mã mẫu đơn giản có thể được tìm thấy ở đây.
Rò rỉ quyền riêng tư theo thiết kế này thấp hơn nhiều so với việc tiết lộ bảng cân đối kế toán hoàn chỉnh và mỗi nhánh có thể bị gián đoạn mỗi khi Merkle root được phát hành để giảm hơn nữa nguy cơ rò rỉ quyền riêng tư, nhưng vẫn có một số vấn đề về rò rỉ quyền riêng tư: Charlie biết rằng một người nào đó có số dư là 164 ETH, tổng của hai số dư người dùng là 70 ETH, v.v. Kẻ tấn công kiểm soát nhiều tài khoản vẫn có thể biết được nhiều điều về người dùng của một 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 xảy ra số dư âm: nếu một sàn giao dịch có số dư người dùng là 1390 ETH nhưng chỉ có 890 ETH dự trữ cố gắng bù đắp bằng cách thêm số dư -500 ETH dưới một tài khoản giả ở đâu đó trong cây. sự khác biệt, tôi nên làm gì? Khả năng này không thực sự phá vỡ sơ đồ, đó là lý do tại sao chúng tôi chủ ý 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 vào đó:
Xác minh của Greta sẽ không vượt qua: khi sàn giao dịch phải cung cấp cho cô ấy nút của 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ì nút trung gian phía trên Henry có số dư là -230 ETH, vì vậy nút này cũng không hợp lệ! Để việc biển thủ không bị phát hiện, sàn giao dịch chỉ có thể hy vọng rằng nửa bên phải của cây không bị kiểm tra để làm bằng chứng về số dư.
Nếu sàn giao dịch có thể chọn ra những người dùng có 500 ETH không thèm kiểm tra bằng chứng số dư hoặc những người không tin họ 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ể xử lý nó. Tuy nhiên, các 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, nếu chỉ xét về khía cạnh chứng minh trách nhiệm pháp lý thì công nghệ Merkle tree 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 chưa lý tưởng. Bạn có thể sử dụng cây Merkle một cách tinh vi hơn để cải thiện, chẳng hạn như sử dụng satoshi hoặc wei làm nút lá độc lập. Tuy nhiên, bằng cách sử dụng công nghệ tiên tiến hơn, nó có thể được thực hiện tốt hơn nữa.
Sử dụng ZK-SNARK để cải thiện quyền riêng tư và độ bền
ZK-SNARK là một công nghệ mạnh mẽ. Những gì ZK-SNARK làm đối với mật mã tương tự như trí tuệ nhân tạo: một công nghệ có mục đích chung có thể lấn át một loạt các kỹ thuật chuyên biệt được phát triển từ nhiều thập kỷ trước để giải quyết một loạt vấn đề. Vì vậy, tất nhiên chúng ta 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 chứng minh nợ.
Chúng tôi 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 là không âm và cộng với một số giá trị được yêu cầu. Nếu chúng tôi thêm một lớp băm để bảo mật, thì ngã ba Merkle (hoặc bằng chứng KZG) được gửi tới từng người dùng sẽ không tiết lộ bất kỳ số dư nào của người dùng 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 bằng chứng và có thể sử dụng ZK-SNARK đơn giản để chứng minh tổng số dư và mỗi số dư đều không âm.
Chúng ta có thể chứng minh tổng các 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í dụ, giả sử số dư nhỏ hơn 2 15 ), trong đó mọi vị trí thứ 16 theo dõi sự khác biệt được đảm bảo rằng chỉ khi thực tế tổng bằng với Khẳng định rằng tổng bằng với giá trị sẽ bằng 0. Nếu z là một nghiệm nguyên thủy của bậc 128, chúng ta có thể chứng minh rằng phương trình đúng:
[ 1 ] Ghi chú của người dịch: Giải thích phương trình đa thức này.
Cách chuyển các phương trình này thành đa thức hiệu chỉnh rồi chuyển thành ZK-SNARK các bạn có thể tham khảo bài viết về ZK-SNARK của tôi tại đây và một số nơi khác. Đâ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 trở nên dễ hiểu!
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 một hệ thống giao dịch có đòn bẩy, người dùng cá nhân có thể chấp nhận số 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 một sàn giao dịch không thể bí mật miễn trừ một số người dùng khỏi các quy tắc, do đó gây nguy hiểm cho tài sản của người dùng.Về lâu dài, tính hữu ích của bằng chứng trách nhiệm pháp lý ZK này không chỉ giới hạn đối với tiền gửi của người dùng trong các 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 vay tiền đều đặ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 biết gì cho người cho vay rằng họ đã không thực hiện quá nhiều khoản vay khác. Cuối cùng, những đổi mới pháp lý thậm chí có thể cho phép các khoản vay cam kết theo cách này được ưu tiên cao hơn các khoản vay không cam kết. đây là với chúng tôi trong"Xã hội phi tập trung: Tìm kiếm linh hồn của Web3"
Một ý tưởng trùng khớp với ý tưởng được thảo luận trong: khái niệm về danh tiếng tiêu cực trên chuỗi có thể thực hiện được thông qua một số dạng "mã thông báo gắn liền với linh hồn".
Giấy tờ chứng minh tài sản
Phiên bản đơn giản nhất của Proof of Assets 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 tin nhắn chữ ký ngoài chuỗi.
Có hai vấn đề thực tế với kỹ thuật 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 các sàn giao dịch lưu trữ phần lớn tiền của người dùng trong ví lạnh: trên các máy tính ngoại tuyến, các giao dịch cần được ký thủ công và chuyển sang internet. Cách tiếp cận này là phổ biến: ví lạnh mà tôi đã sử dụng để lưu trữ tiền cá nhân của mình trên một máy tính ngoại tuyến vĩnh viễn sẽ tạo mã QR chứa các giao dịch đã ký, sau đó tôi sẽ quét mã này bằng điện thoại của mình. Do số tiền khổng lồ, giao thức bảo mật mà 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 của nhiều bên giữa nhiều thiết bị, để giảm hơn nữa khả năng rò rỉ khóa do một thiết bị bị tấn công. 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 địa chỉ cũng là một hoạt động tốn kém!
Trao đổi có thể sử dụng các phương pháp sau:
● Duy trì một số địa chỉ công khai dài hạn. Sàn giao dịch tạo một số địa chỉ, chỉ cấp bằng chứng về quyền sở hữu của từng địa chỉ một lần và sử dụng lại các địa chỉ này. Cho đến nay, đây là giải pháp dễ dàng nhất, mặc dù nó có thêm một số hạn chế về bảo mật và quyền riêng tư.
● Giữ nhiều địa chỉ, sau đó chứng minh ngẫu nhiên một vài địa chỉ. Các sàn giao dịch nắm giữ nhiều địa chỉ và thậm chí chỉ có thể sử dụng mỗi địa chỉ một lần và không sử dụng địa chỉ đó sau một giao dịch. Trong trường hợp này, sàn giao dịch sẽ cần phải có một thỏa thuận rằng thỉnh thoảng một số địa chỉ sẽ được chọn ngẫu nhiên, sàn giao dịch sẽ phải "mở" để chứng minh quyền sở hữu. Một số sàn giao dịch đã sử dụng kiểm toán viên cho các hoạt động tương tự, nhưng về nguyên tắc, kỹ thuật này có thể được chuyển thành một quy trình hoàn toàn tự động.
● Cách tiếp cận ZKP phức tạp hơn. Ví dụ: một 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 mình, một trong số các địa chỉ này có các khóa khác nhau và địa chỉ kia có cùng khóa theo một cách phức tạp nhưng an toàn (ví dụ: đa chữ ký 12/16) để lưu trữ một bản mù dự phòng khẩn cấp quan trọng. Để bảo vệ quyền riêng tư và tránh tiết lộ địa chỉ đầy đủ của họ, một sàn giao dịch thậm chí có thể chạy bằng chứng không có kiến thức trên chuỗi khối để chứng minh tổng số dư địa chỉ trên chuỗi ở định dạng đó.
Một mối quan tâm lớn khác là ngăn chặn tái sử dụng tài sản thế chấp. Chuyển tài sản thế chấp qua lại giữa nhau để chứng minh dự trữ thường dễ dàng đối với các sàn giao dịch, cho phép một người 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 đó không thực tế, thì điều tốt nhất tiếp theo là điều phối thời gian cố định giữa các sàn giao dịch để chứng thực, chẳng hạn như chứng thực dự trữ vào mỗi Thứ Ba lúc 2 giờ chiều UTC.
Câu hỏi cuối cùng là: Tài sản có được chứng nhận hợp pháp không? Các sàn giao dịch không chỉ nắm giữ tiền điện tử mà còn cả tiền tệ pháp định trong hệ thống ngân hàng. Về vấn đề đó, 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 "tiền tệ định danh": bản thân các ngân hàng có thể xác nhận số dư, kiểm toán viên có thể xác nhận bảng cân đối kế toán, v.v. Cho rằng các loại tiền tệ fiat không thể được xác minh bằng mật mã, đây là giải pháp tốt nhất trong khuôn khổ này và vẫn đáng làm.
Một cách tiếp cận khác là tách Thực thể A khỏi Thực thể B, trong đó A điều hành sàn giao dịch và xử lý USDC, một stablecoin được hỗ trợ bởi một tài sản; Quá trình rút tiền, trong trường hợp này B là chính USDC. Vì "trách nhiệm pháp lý" của USDC chỉ là mã thông báo ERC 20 trên chuỗi, nên bằng chứng về trách nhiệm pháp lý có thể được lấy "dễ dàng" và chúng tôi chỉ cần giải quyết vấn đề bằng chứng tài sản.
Plasma và hợp lệ: chúng ta có thể đạt được CEX không được quản lý không?
Giả sử chúng ta muốn tiến thêm một bước: chúng ta không chỉ muốn chứng minh rằng sàn giao dịch có đủ tiền để trả lại tiề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 ăn cắp tiền của người dùng.
Một trong những ứng dụng sớm đầu tiên ở đây là Plasma, một giải pháp mở rộng đã 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, mỗi token được gán một chỉ mục và đặt ở một vị trí cụ thể trong cây Merkle của khối Plasma. Để chuyển mã thông báo 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. Mã thông báo đượ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 - và vì vấn đề đó, Tập đoàn Plasma, với dự án tổng hợp lạc quan của họ là Optimism.
Các cuộc thảo luận vào năm 2018 về những hạn chế của Plasma (ví dụ: phân mảnh mã thông báo bằng chứng) đã đặt ra những nghi ngờ cơ bản về khả năng tồn tại của Plasma. Kể từ khi cuộc thảo luận về Plasma đạt đến đỉnh điểm vào năm 2018, ZK-SNARK ngày càng trở nên khả thi hơn cho các trường hợp sử dụng liên quan đến mở rộng. Như chúng tôi đã nói ở trên, ZK-SNARK đã thay đổi mọi thứ.
Phiên bản mới hơn của Plasma được Starkware gọi là validium: về cơ bản giống như ZK-rollup, ngoại trừ dữ liệu được giữ ngoài chuỗi. Cấu trúc này có thể áp dụng cho nhiều trường hợp sử dụng và có thể hình dung nó có thể áp dụng 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ó đã thực thi mã chính xác. Trong hợp lệ, nhà điều hành không thể đánh cắp tiền, nhưng tùy thuộc vào chi tiết triển khai cụ thể, 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.
Bây giờ có vẻ tuyệt vời: CEX và DEX đều khác xa, hóa ra có nhiều 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ư hiệu quả, nhưng vẫn còn nhiều loại tiền điện tử Đảm bảo học thuậ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ũng đáng suy nghĩ về câu hỏi cơ bản còn lại: cách xử lý lỗi 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ị tấn công hoặc mất quyền truy cập vào tài khoản của họ?
Các sàn giao dịch có thể giải quyết vấn đề này bằng cách tận dụng khôi phục email trước và nếu không thành công, 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, các sàn giao dịch cần thực sự kiểm soát các mã thông báo này. Để có thể thu hồi tiền của người dùng một cách hợp lý, các sàn giao dịch cần phải có cùng quyền hạn 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 lâu dài lý tưởng là dựa vào quyền tự giám sát và 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 ích khác nhau:
Một vấn đề quan trọng khác là hỗ trợ chuỗi chéo: trao đổi cần hỗ trợ nhiều chuỗi khác nhau, các hệ thống như Plasma và hợp lệ 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), dự kiến sẽ được giải quyết thông qua nâng cấp kỹ thuật và tiêu chuẩn hóa; tuy nhiên, trong ngắn hạn, đây là một lý do khác khiến các sàn giao dịch lưu ký vẫn bị giam giữ cho đến ngày nay.
Kết luận: Tìm kiếm một sàn giao dịch tốt hơn trong tương lai
Trong ngắn hạn, có hai loại trao đổi rõ ràng: trao đổi lưu ký và trao đổi không lưu ký. Ngày nay, danh mục thứ hai là một DEX giống như Uniswap và trong tương lai, chúng ta cũng có thể thấy các CEX bị hạn chế bởi mật mã, nơi tiền của người dùng sẽ được giữ theo cách tương tự như hợp đồng thông minh hợp lệ. Chúng tôi cũng có thể thấy các sàn giao dịch bán lưu ký nơi chúng tôi tin tưởng vào việc họ xử lý các loại tiền tệ fiat hơn là tiền điện tử.
Cả hai loại trao đổi đều tồn tại ở đây và cách dễ nhất để cải thiện khả năng tương thích ngược để bảo mật các trao đổi lưu ký là thêm bằng chứng dự trữ. Đ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 để 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 công nghệ song hành với nhau, đồng thời phần mềm và chương trình nguồn mở càng nhiều càng tốt để tất cả cá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 hướng mà tất cả các sàn giao dịch đều không bị giam giữ, ít nhất là khi nói đến tiền điện tử. Khôi phục ví sẽ tồn tại và có thể yêu cầu 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 sắp xếp 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 các sàn giao dịch. Về tiền tệ pháp định, sự di chuyển giữa hệ thống ngân hàng truyền thống và hệ sinh thái tiền điện tử có thể được hoàn thành thông qua quy trình vào và ra quỹ gốc của các stablecoin được hỗ trợ bằng 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] Chú thích của người dịch:
➤ Cứ 16 chữ số đại diện cho một người dùng (15 chữ số đầu tiên đại diện cho số dư của người dùng và chữ số cuối cùng đại diện cho sự khác biệt giữa tổng số dư của người dùng và sao kê cho đến nay). 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 cần có cái nhìn sâu sắc ở đâ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
Chênh lệch: -165 + 50 -185 = -300
➤ Sau khi vượt qua tất cả người dùng, yêu cầu số dư của người dùng cuối cùng là 0
➤ Giải tứ phương trình
Phương trình 1: Giá trị ban đầu của đệ quy là 0
Phương trình 2: Mỗi số dư người dùng cần tương ứng với cam kết KZGPhương trình 3: Công thức đệ quy cho số dư của mỗi người dùng, số dư ràng buộc là >= 0 và< 2 14 ，
< 2 14 (Có ý kiến cho rằng số dư < 2 15 chắc là lỗi văn tự, vì theo phương trình 3, công thức đệ quy chỉ có 14 giá trị, I(zi)
liên kết gốc
IOS
Android