Tác Quyền Kép (Dual Authoring ) — Giải pháp của Loopring để giải quyết vấn đề “chạy trước”
Loopring là một giao thức để xây dựng các trao đổi phi tập trung. Trong bài này, chúng tôi sẽ nói ngắn gọn về vấn đề trước đó trong các sàn giao dịch phi tập trung, và sẽ giải thích cách chúng ta giải quyết nó bằng cách sử dụng giải pháp Tác Quyền Kép của Daniel.
Một phiên bản đầu đã được lưu trữ trong IPFS: QmX48qyrSUdcvrJ2rFVrmvPxk6dkdoYKTGVBMRHC3ahzMh (PDF).
Daniel Wang, người sáng lập của chúng tôi, đã nghiên cứu và phát triển một giải pháp nâng cao cho công tác phòng chống “chạy trước” được gọi là Tác Quyền Kép. Chúng tôi đã áp dụng để bảo vệ quyền phát minh và mã hoá giải pháp vào các hợp đồng thông minh của chúng tôi. Tính năng này sẽ được triển khai như là một phần của việc phát hành giao thức thuộc phiên bản 1.2. Chúng tôi tin rằng Tác Quyền Kép sẽ mang lại cho chúng tôi một lợi thế cạnh tranh rất tốt.
“Chạy trước” trong các trao đổi phi tập trung
“Chạy trước là hành vi bất hợp pháp của một nhà môi giới chứng khoán thực hiện các lệnh chứng khoán cho tài khoản riêng của mình trong khi tận dụng ưu thế hiểu biết trước các lệnh đang chờ (pending orders) từ khách hàng của mình.” [wikipedia]
Trong các trao đổi phi tập trung, chạy trước là khi ai đó cố gắng thực hiện các giao dịch của bản thân, trước khi thực hiện các giao dịch khác đã có trong hồ sơ giao dịch đang chờ xử lý (mempool). Điều này có thể xác định bằng cách xác định một khoảng phí giao dịch cao hơn (giá gas), và nếu người chạy trước là thợ đào, người đó có thể thực hiện các giao dịch đang chờ theo hướng có lợi cho bản thân.
Lược đồ chính của chạy trước trong Loopring (và bất cứ giao thức nào phù hợp) là các order-filch và ring-filch. Order-filch là khi một nhân vật phía trước đánh cắp một hoặc nhiều đơn đặt hàng từ một giao dịch thanh toán vòng giao dịch đang chờ xử lý; và ring-filch là khi một nhân vật phía trước đánh cắp toàn bộ vòng từ giao dịch đang chờ xử lý.
Trước khi tiếp tục, điều đáng nói đến ở đây là công nghệ phù với Loopring không thực hiện chế độ đến trước được phục vụ trước (thay vào đó là mô hình mua bán thẳng không thông qua bất kỳ sổ sách nào hay còn gọi là OTC), điều này có nghĩ là thời gian được đánh dấu của đơn hàng bị bỏ qua hoàn toàn. Điều này cũng có nghĩa rằng một giao dịch chạy trước không ảnh hưởng đến giá trị thực tế của giao dịch đó — Loopring chỉ hỗ trợ các lệnh giới hạn giá.
Phân tích lệnh và chu trình giao dịch trong Loopring 1.0 & 1.1
Các lệnh mua bán và chữ ký xác nhận
Lệnh trao đổi trong Loopring được tạo bởi ví và công cụ có thể giúp quản lý khóa riêng tư của người dùng. Lệnh trao đổi là một đoạn ngắn của mã JSON và được chuyển sang relay dưới dạng phần mềm dữ liệu JSON thông qua API. Đây là một ví dụ về một lệnh trong bản phát hành Loopring 1.0:
Vị trí owner đại diện cho owner_address của lệnh trao đổi, từ đó mã thông báo sẽ được chuyển sau khi lệnh trao đổi được điền. Lệnh trao đổi (bao gồm cả owner_address) phải được xác nhận bằng khóa cá nhân của owner_address. Lệnh này chỉ hợp lệ nếu order_signature (được biểu thị bằng r, v, và s) là hợp lệ.
Như sơ đồ minh hoạ dưới đây, order_signature đã được xác nhận với lệnh băm (hoặc order_hash), với đầu ra là hàm keccak256 của tất cả các trường hợp trừ r, v,và s.
Để tính toán order_hash mà sau đó được sử dụng để xác minh xem địa chỉ ký trong đơn hàng thực sự có phải là owner_address hay không rất dễ dàng. Rơ-le sẽ xác minh chữ ký của mỗi đơn đặt hàng mà nó nhận được; hợp đồng thông minh Giao thức Loopring cũng xác minh chữ ký đơn hàng khi 1) các đơn đặt hàng được gửi như là một phần của một vòng và 2) các đơn đặt hàng được yêu cầu hủy bỏ.
Các vòng giao dịch và chữ ký xác nhận
Các vòng giao dịch không có dạng JSON, thay vào đó, chúng được miêu tả bởi tất cả các tham số của hàm submitRing được cung cấp bởi Giao thức Loopring. Nhưng nếu chúng ta liên tưởng đến một cái vòng, nó sẽ trông giống như một cái gì đó bên dưới — nó đóng gói tất cả các dữ liệu của đơn đặt hàng (một vòng giao dịch sẽ chứa được 2 đến 10 đơn hàng). Thợ đào khai thác vòng giao dịch cũng sẽ ở tại địa chỉ đó (miner_address) và các tham số khai thác khác (hoặc tham số vòng) vào vòng sao cho hàm submitRing sẽ có hoạt động khác nhau dựa trên các tham số đầu vào.
Thợ đào cần ký băm của một vòng (ring_hash), cùng với tất cả tham số khai thác bằng khóa riêng của miner_address. ring_hash có thể được tính như là kết quả op XOR của tất cả các order_hash hoặc sử dụng các hàm băm khác.
Xin lưu ý rằng giao thức không yêu cầu msg.sender để ký bất cứ điều gì. Theo thứ tự từ, một vòng — như phần dữ liệu giao dịch submitRing — có thể được ký bởi một địa chỉ khai thác và bản thân giao dịch blockchain có thể được ký (và được truyền tin) bởi một địa chỉ giao dịch khác. Việc tách địa chỉ khai thác và địa chỉ giao dịch cung cấp thêm sự linh hoạt và tăng lợi thế bảo mật.
Sơ đồ dưới đây minh họa phần dữ liệu giao dịch (hoặc các tham số) của một giao dịch submitRing cho một vòng giao dịch gồm 3 đơn đặt hàng.
Tại sao thợ mỏ cần phải ký tên trên vòng? Chúng tôi cần đảm bảo tất cả các thống kê giao dịch được tính toán / cập nhật cho các thợ mỏ chính xác. Các số liệu thống kê này có thể được sử dụng bởi các thành viên trong tập đoàn chia sẻ thanh khoảng blockchain để tính toán sản lượng và mức tiêu dùng của mỗi thành viên nhằm củng cố các khoản thanh toán liên doanh.
Chạy Trước và Đánh Cắp Giao Dịch Trong Vòng
Như mô tả phần trên, khi một giao dịch submitRing không được xác nhận và vẫn còn trong nhóm giao dịch đang chờ xử lý, bất kỳ ai cũng có thể dễ dàng phát hiện giao dịch đó và thay thế miner_address bằng địa chỉ của chính mình (filcher_address), sau đó người đó có thể ký lại dữ liệu vận chuyển với filcher_address để thay thế chữ ký của vòng. Kẻ cắp có thể đặt giá gas cao hơn và gửi một giao dịch mới với hy vọng các thợ mỏ sẽ chọn giao dịch mới của mình vào khối tiếp theo thay vì giao dịch submitRing ban đầu.
Giải pháp trong phiên bản 1.0 và 1.1
Trong phiên bản v1.0 và 1.1, chúng tôi cho phép các thợ mỏ khai thác vòng gọi một trong hai chức năng batchSubmitRinghash hoặc submitRinghash để dự trữ băm vòng trước khi gửi các vòng thực sự. Khi một vòng được gửi, giao thức kiểm tra xem băm của vòng đã được gửi / được sở hữu bởi các thợ mỏ khác hay không, nếu có, giao thức sẽ từ chối vòng và giao dịch submitRing sẽ thất bại.
Có một số nhược điểm trong giải pháp này: nó đòi hỏi nhiều giao dịch hơn do đó tốn kém chi phí gas của các thợ mỏ; và phải mất ít nhất thời gian để giải gấp đôi để giải quyết một vòng giao dịch. Điều này là không thể chấp nhận..
Tác Quyền Kép — Giải Pháp Mới Của Chúng Tôi
Giải pháp mới của chúng tôi liên quan đến cơ chế thiết lập hai cấp ủy quyền cho các đơn đặt hàng: một để giải quyết và một cho khai thác. Chúng tôi gọi nó là Tác Quyền Kép.
Nó hoạt động như thế nào
Đây là cách Tác Quyền Kép hoạt động:
1. Với mỗi đơn đặt hàng, phần mềm ví sẽ thiết lập một cặp public-key/private-key ngẫu nghiên và và chèn cặp khoá đó vào đoạn mã đặt hàng JSON. (một cách khác là sử dụng địa chỉ được trích từ khóa công khai thay vì nguyên cả một khóa công khai để giảm kích thước byte. Chúng tôi sử dụng auth_address để đại diện cho một địa chỉ và auth_private_key để đại diện cho khóa cá nhân phù hợp của auth_addres).
2. Tất cả các trường theo thứ tự ngoại trừ auth_private_key đều được ký bằng cách sử dụng khóa cá nhân của owner_address (không phải auth_private_key) như trong hình dưới đây.
3. Các ví sẽ gửi theo thứ tự, cùng với auth_private_key đến các thợ đào (các rơ-le) tương ứng. Thợ đào sẽ xác minh rằng auth_private_key và auth_address là một cặp chính xác và chữ ký của đơn hàng có giá trị đối với owner_address.
4. Khi một vòng được xác định, thợ đào sẽ sử dụng auth_private_key của mỗi đơn đặt hàng để đánh dấu ring_hash, miner_address và tất cả các mining_parameters. Trong ví dụ dưới đây, vòng chứa 3 đơn đặt hàng, do đó sẽ có 3 chữ ký của 3 auth_private_keys. Chúng tôi gọi những chữ ký này là auth_signatures. Thợ đào cũng cần phải ký ring_hashcùng với tất cả tham số khai thác sử dụng khóa riêng của miner_address theo cách tương tự như trong giao thức v1.0 và 1.1.
5. Các thợ đào gọi hàm submitRing với tất cả các thông số trong v1.0 và v1.1, cũng như thêm 3 auth_signatures. Lưu ý rằng auth_private_keys KHÔNG phải là một phần của giao dịch trên chuỗi và do đó vẫn chưa được biết đến với những người khác ngoài chính relay đó, như trong hình dưới đây.
6. Giao thức Loopring bây giờ sẽ xác minh mỗi auth_signature đối với auth_address tương ứng theo đúng thứ tự, và từ chối vòng nếu bất kỳ auth_signature nào không hợp lệ.
Why It Works
Bây giờ một vòng không thể bị đánh cắp bởi bất cứ ai trừ khi anh ta có tất cả các auth_private_keys của tất cả các lệnh đính kèm. Điều này là do:
- Chữ ký của lệnh trao đổi (bằng khóa cá nhân của
ower_address) đảm bảo không thể sửa đổi đơn đặt hàng, bao gồm cảauth_address. - Chữ ký của thợ đào (bằng khóa cá nhân của
miner_address) đảm bảo không ai có thể sử dụng danh tính của mình để khai thác một vòng giao dịch nào cả. - Các
auth_signaturesđảm bảo toàn bộ vòng không thể được sửa đổi, bao gồm cảminer_address. Và kể từ khi các tên trộm vòng không có quyền truy cập vàoauth_private_keys, chúng không thể tạo lại một tập hợpauth_signaturesmới do đó không thể tạo ra một giao dịch bất hợp pháp.
Các Biến Thể Khác Của Tác Quyền Kép
Tác Quyền Kép một phần
Tác Quyền Kép yêu cầu chữ ký của tất cả các auth_private_keys trong một vòng. Một biến thể của Tác Quyền Kép là yêu cầu một hoặc chỉ một vài auth_signatures. Chương trình Tác Quyền Kép này cũng đảm bảo một vòng hoàn toàn không thể bị đánh cắp, nhưng nó vẫn còn tùy thuộc vào lệnh trao đổi, và kẻ cắp có thể sử dụng các lệnh bị đánh cắp trong một giao dịch thanh toán vòng được ủy quyền một phần khác của Tác Quyền Kép, nơi các đơn đặt hàng bị đánh cắp đều không yêu cầu auth_private_key.
Chia Sẻ Khoá Tác Quyền Kép
Một rơ-le có thể tạo ra một cặp auth_address /auth_private_key và yêu cầu tất cả các ví kết nối với nó để sử dụng cùng một auth_address chung cho tất cả các đơn đặt hàng (vì ví không có auth_private_key, trường hợp bị thiếu dữ liệu API JSON của đơn hàng). Lược đồ chia sẻ khoá Tác Quyền Kép này chỉ cho phép chuyển tiếp tới các trình tự nhỏ hơn mà nó tạo ra các cặp auth_address/auth_private_key. Do đó, ví không có tùy chọn chia sẻ đơn đặt hàng với các rơ-le khác.
Triển Khai
Việc cấp phép kép đã được triển khai trong kho lưu trữ giao thức của chúng tôi, pull request hiện đang được xem xét và các thử nghiệm sẽ sớm được cập nhật.
Kết Luận
Giải pháp Tác Quyền Kép của Daniel ngăn ngừa việc đánh cắp vòng giao dịch và thứ tự của lệnh trao đổi trong khi vẫn đảm bảo tính hợp pháp của các vòng có thể được thực hiện trong một giao dịch duy nhất. Ngoài ra, Tác Quyền Kép mở ra cánh cửa cho các relay để chia sẻ các đơn đặt hàng theo hai cách: chia sẻ không kết hợp và chia sẻ kết hợp.
Nếu bạn có thắc mắc hoặc gợi ý về Dual Authoring, hãy gửi email trực tiếp cho Daniel.
Cập nhật: Chúng tôi đã quyết định phát hành tính năng này như một phần của v1.1.
Bài viết này chính thức công bố bởi Daniel wang và được dịch sang tiếng việt bởi nhóm EVOLVE.
Để cập nhập thêm thông tin, tham gia với chúng tôi trên các kênh mạng xã hội dưới đây:
⭑ Twitter: twitter.com/loopring.org
⭑ Reddit: reddit.com/r/loopringorg/
⭑ Telegram: t.me/loopring_en
⭑ Telegram: t.me/loopringfans (Chinese)
