Intro

Vấn đề Commit-chain giải quyết là:

• Layer 2 không cần đồng thuận
• Hỗ trợ chuyển tiền zero-fee và ngay lập tức
• Không yêu cầu trung gian cần stake lượng tiền lớn như giải pháp Lightning
• Đáp ứng được hàng tỷ user

Trung gian tập trung tin cậy

Trung gian tập trung hay gọi là Operator có vai trò điều phối và phê duyệt các giao dịch. Các khoản thanh toán được kiểm duyệt hay kiểm toán bởi smart contract. Cần sự quan sát của user và kiểm toán định kỳ bằng smart contract ⇒ Operator không thể chiếm đoạt tiền của user

Overview

Thành phần:

• Parent Blockchain: Root of trust
• User
• Commit-Chain Smart Contract: Là thành phần giám sát và điều hành Operator, giải quyết các tranh chấp
• Commit-Chain Operator: hay Operator

Các khoảng giao dịch của người dùng được gọi là IOU (I OWN U, thuật ngữ kinh tế để chỉ giấy nợ được viết và công nhận bởi người vay và người cho vay)

1. Bob deposit tiền vào Smart Contract
2. Bob gửi một IOU đến Operator nội dung là từ Bob đến Alice 0.1 $
3. IOU được Operator gửi đến Alice
4. Alice đồng ý và ký một biên nhận cho IOU của BoB
5. Operator ký cả 2 trạng thái mới của Bob và Alice
6. Trạng thái mới được ký bởi Server tới Bob
7. Trạng thái mới được ký bởi Alice tới Bob
8. Operator tổng hợp các trạng thái của user và gửi đến parent chain
9. User kiểm tra tính toàn vẹn sau mỗi round

High-Level Operation

Tương tác

• Register: User đăng ký với Operator thông qua một tin nhắn off-chain
• Deposit: User lock một khoản coin vào smart contract. Sau đó, user có thể gửi chúng tới một user khác qua off-chain và luôn luôn có thể claim lại khoản tiền đó
• Transfer: user xác thực với Operator về số dư và người nhận. Số tiền ngay lập tức sẽ được chuyển đi
• Withdraw/Exit: User submit một yêu cầu off-chain đến Operator, Operator sẽ tạo lệnh để rút tiền từ smart contract. User cũng có thể rút ngay lập tức từ smart contract, đóng tài khoản ở L2 và refund toàn bộ balance
• Checkpoint: Tại mỗi round, Operator commit trạng thái cuối cùng của toàn bộ user mà họ quản lý lên smart contract. Trạng thái finalized là trạng thái tất cả các thay đổi đều đúng và vượt qua được giai đoạn tranh chấp (hay kiểm toán từ phía user)
• Challenge: Nếu Operator có sai phạm, user có thể đặt ra challenge ở smart contract cho Operator giải quyết, sẽ bảo vệ fund của user và phạt operator trong trường hợp sai phạm
• Recover: Nếu Operator bị phạt, smart contract bắt buộc chuyển sang trạng thái recovery. Smart contract sẽ không chấp nhận checkpoint mới. User có thể recover fund tại lần trao đổi checkpoint hợp lệ cuối cùng

Data strcuture - Merkleized Interval Tree

Lý do sử dụng cây MIT là xác minh toàn vẹn dữ liệu nhanh chóng và dễ dàng hơn.

Cấu trúc dữ liệu được dùng để lưu state người dùng ở Operator cũng như ở Smart Contract Ở Operator:

• $P_i$ - User thứ i
• $A_i(e)$ - balance ban đầu của $P_i$ cho round $e$
• $R_i(e)$ - tổng tiền nhận ở off-chain bởi $P_i$ trong suốt round $e$
• $S_i(e)$ - tổng tiền gửi đi ở off-chain bởi $P_i$ trong suốt round $e$
• $T_i(e)$ - set các tx off-chain được gửi và nhận bởi $P_i$ trong suốt round $e$ Ở Smart Contract:
• $D_i(e)$ - Tổng tiền được deaposit bởi $P_i$ trong suốt round $e$
• $W_i(e)$ - Tổng tiền được yêu cầu rút bởi $P_i$ trong suốt round $e$
• $X_i^b$ - Challenge bởi $P_i$ để chống lại sai phạm về balance
• $X_i^d$ - Challenge bởi $P_i$ để chống lại sai phạm về off-chain transfer delivery

Vậy có thể suy ra như sau: $A_i(e) = A_i(e-1)+D_i(e-1)+R_i(e-1)-W_i(e-1)-S_i(e-1)$

Node lá

Node $t_i(e)$ thể hiện thông tin của $P_i$ ở off-chain tại round e.

$t_i(e)=<offset_i(e), information_i(e), allotment_i(e)>$

Trong đó, offset và allotment là 2 numeric value và information là commitment đã được hash chứa thông tin của node:

• $allotment_i(e)=A_i(e)$
• $offset_i(e)=\sum\limits_{j<i} (allotment_j(e))$
• tổng allotment thứ tự trước user i
• $information_i(e)=Hash(address_i, update_i(e))$ - update thể hiện trạng thái cuối cùng ở off-chain của user $P_i$ tại round $e$

Node cha

Node cha $t_u(e)$ sẽ có 2 node con là $t_R(e)$ và $t_L(e)$:

$allotment_u(e) = allotment_L(e)+allotment_R(e)$

$offset_u(e)=offset_L(e)$

$information_u(e)=Hash(t_L(e), offset_R(e),t_R(e))$

Trường Update

$update_i(e)=Hash(T_i(e), S_i(e), R_i(e))$

$T_i(e)$ là cây merkel tree có node là là các transfer off-chain

$<e, sender, recipient, amount, nonce>$

Proof Of Exclusive Allotment

Mục tiêu là chứng minh User có sở hữu $allotment_i(e)$ trong pool vào thời điểm bắt đầu round. Proof chứa một hash của các node họ hàng trong đường đi từ root đến node lá. Ngoài ra, cần tiết lộ $offset_n(e)$ nếu $t_n(e)$ là Left child và $offset_n(e)+allotment_n(e)$ nếu $t_n(e)$ là Right child

Ref

• https://eprint.iacr.org/2018/642
• https://docs.liquidity.network