Tác giả | Vitalik Buterin
Tác giả | Vitalik Buterin
Giả sử chúng ta có hai giải pháp tổng số A và B và Alice muốn trao đổi một số lượng mã thông báo nhất định trên tổng số A lấy cùng một mã thông báo trên tổng số B. Ai đó đã đề xuất giải pháp cho vấn đề này.Nếu cả danh sách A và B đều hỗ trợ đầy đủ hợp đồng thông minh, thì giả định này có thể được thực hiện theo cách phi tập trung. Tuy nhiên, bài viết này đề xuất cách thực hiện chuyển giao cuộn chéo khi chỉ cuộn B hỗ trợ đầy đủ hợp đồng thông minh (và cuộn A chỉ có thể xử lý các giao dịch đơn giản).
đề xuất
đề xuất
Giả sử chúng ta có một trung gian trao đổi là Ivan (có nhiều trung gian để lựa chọn khi thực hiện). Ivan sở hữu một (tài khoản do anh ta kiểm soát hoàn toàn) IVAN_A trong tổng số A. Đồng thời, Ivan cũng gửi một số tiền vào hợp đồng thông minh IVAN_B của rollup B.
Hợp đồng thông minh IVAN_B có các quy tắc sau:
➤ Nếu bất kỳ người dùng nào gửi giao dịch (gửi giá trị giao dịch mã thông báo TRADE_VALUE đến tài khoản IVAN_A), (địa chỉ đích B DESTINATION cũng được đính kèm dưới dạng ghi chú trong giao dịch), sau thời gian trễ hoàn trả tối thiểu MIN_REDEMPTION_DELAY khối, người dùng A giao dịch có thể được trả lại vào tài khoản IVAN_B (bao gồm cả bằng chứng chuyển khoản trước đó), và sau đó giao dịch sẽ được xếp hàng để rút tiền đến địa chỉ DESTINATION.
➤ Sau khi đợi một độ trễ nhất định (ví dụ: một ngày), việc rút tiền được xử lý theo lô và thứ tự chỉ mục trong đó các lần chuyển được đóng gói thành cuộn A.
➤ Khi Ivan phát hiện ra rằng tài khoản IVAN_A của mình đã nhận được tiền, anh ấy có thể tự mình gửi mã thông báo TRADE_VALUE * (1 - phí) đến DESTINATION. Anh ta có thể làm điều này bằng cách gửi giao dịch bằng phương pháp IVAN_B, phương thức này sẽ lưu giữ bản ghi và ngăn điều khoản gửi tự động trong hợp đồng kích hoạt giao dịch.
Hành vi mong đợi rất đơn giản:
➤ Alice gửi giao dịch đến tài khoản IVAN_A (chứa N token và ghi chú ALICE_B)
➤ Ivan gửi mã thông báo TRADE_VALUE * (1 - phí) tới ALICE_B qua IVAN_B
Giao dịch thứ hai xảy ra ngay sau giao dịch đầu tiên. Nếu Ivan có thể chứng minh rằng sự khác biệt về dấu thời gian giữa giao dịch đầu tiên và giao dịch thứ hai là rất nhỏ, thì hợp đồng thậm chí còn có các quy tắc cho phép tăng phí.
tiêu đề cấp đầu tiên
chi phí vốn
Hạn chế chính của sơ đồ này là IVAN_B cần phải giữ một số tiền lớn để đảm bảo rằng tất cả những người gửi giao dịch đều được thanh toán. Cụ thể, giả sử tình huống sau đây xảy ra:
➤ Chúng tôi đặt giới hạn giao dịch thành TRADE_LIMIT (vì vậy khi giao dịch được gửi tới IVAN_A vượt quá giá trị giới hạn > TRADE_LIMIT thì giao dịch đó không hợp lệ)
➤ Mỗi đợt tổng số có thể chứa tối đa giao dịch TXS_PER_BATCH
Alice có thể tự kiểm tra xem còn lại bao nhiêu giao dịch chưa được xử lý trước khi đợt giao dịch tiếp theo của tổng số A cần được xử lý, trừ tổng giá trị của các giao dịch này khỏi quỹ của cô ấy trong hợp đồng IVAN_B và kiểm tra xem số tiền còn lại có đủ hay không. Vì việc rút tiền được xử lý tuần tự (là mục đích của cơ chế xếp hàng được mô tả ở trên), nên Alice không cần phải lo lắng về việc hợp đồng xử lý các yêu cầu rút tiền khác trước khi xử lý yêu cầu giao dịch rút tiền của mình.
Quy mô giao dịch tối đa trong mỗi đợt là TRADE_LIMIT * TXS_PER_BATCH , do đó, ít nhất cần có lượng ETH này trong hợp đồng IVAN_B, cộng với số tiền bổ sung được yêu cầu để bao gồm các giao dịch để xử lý. Ví dụ: giả sử giới hạn giao dịch là 0,1 ETH TRADE_LIMIT = 0,1 ETH (giới hạn giao dịch có thể được đặt thấp hơn vì một giao dịch lớn có thể được chia thành nhiều giao dịch nhỏ) và mỗi lô có thể xử lý 1000 giao dịch TXS_PER_BATCH = 1000 . Sau đó, hợp đồng IVAN_B cần giữ 100 ETH.
Lưu ý rằng cũng có một khoản phí ẩn trong thiết kế này, vì bất kỳ người dùng nào giao dịch nhiều hơn 0,1 ETH đều cần lãng phí dung lượng khối. Điều này được cân nhắc so với yêu cầu về vốn, tức là nếu người dùng sử dụng một nửa dung lượng khối, thì yêu cầu về vốn của họ sẽ tăng gấp đôi và ngược lại. Nếu một người muốn đạt được sự cân bằng phù hợp, phí ngụ ý sẽ ít hơn nhiều lần so với phí rõ ràng trên thị trường.
tiêu đề cấp đầu tiên
Nhận xét
Thiết kế trên dựa trên một giả định: giao dịch trên Rollup A có trường nhận xét, qua đó Alice có thể chỉ định ALICE_B làm địa chỉ đích để cô ấy nhận mã thông báo. Nếu rollup không có tính năng này, thì chúng ta có thể sử dụng giải pháp sau. Alice có thể đăng ký tài khoản ALICE_B trên một hợp đồng được đăng ký tuần tự trên tổng số B và nhận ID được chỉ định tuần tự (vì vậy ID của Alice bằng với số người dùng đã đăng ký trước cô ấy).
tiêu đề cấp đầu tiên
Giao dịch từ Rollup B sang Rollup A
Nếu Alice chuyển mã thông báo từ Tổng số B sang Tổng số A, cô ấy có thể sử dụng cơ chế tương tự, nhưng với vai trò đảo ngược:
➤ Alice gửi token tới IVAN_B
➤ Sau một thời gian trì hoãn, cô ấy sẽ được quyền lấy lại mã thông báo của mình
Công việc dịch thuật của ECN nhằm mục đích cung cấp thông tin và tài nguyên học tập chất lượng cao cho cộng đồng Ethereum Trung Quốc. Bản quyền của bài viết thuộc về tác giả gốc và phải ghi rõ nguồn của văn bản gốc cũng như trang web ETH Trung Quốc khi in lại. Để tái bản dài hạn, vui lòng liên hệ với eth@ecn.co để được ủy quyền.
Click "Đọc nguyên văn" để lấy link nội bộ của bài viết!
Liên kết gốc:https://ethresear.ch/
Công việc dịch thuật của ECN nhằm mục đích cung cấp thông tin và tài nguyên học tập chất lượng cao cho cộng đồng Ethereum Trung Quốc. Bản quyền của bài viết thuộc về tác giả gốc và phải ghi rõ nguồn của văn bản gốc cũng như trang web ETH Trung Quốc khi in lại. Để tái bản dài hạn, vui lòng liên hệ với eth@ecn.co để được ủy quyền.
IOS
Android