+1

Commit chain - Giải pháp L2 không cần đồng thuận

Mayfest2023

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:

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

Vậy có thể suy ra như sau: Ai(e)=Ai(e1)+Di(e1)+Ri(e1)Wi(e1)Si(e1)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 ti(e)t_i(e) thể hiện thông tin của PiP_i ở off-chain tại round e.

ti(e)=<offseti(e),informationi(e),allotmenti(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:

  • allotmenti(e)=Ai(e)allotment_i(e)=A_i(e)
  • offseti(e)=j<i(allotmentj(e))offset_i(e)=\sum\limits_{j<i} (allotment_j(e))
  • tổng allotment thứ tự trước user i
  • informationi(e)=Hash(addressi,updatei(e))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 PiP_i tại round ee

Node cha

Node cha tu(e)t_u(e) sẽ có 2 node con là tR(e)t_R(e)tL(e)t_L(e):

allotmentu(e)=allotmentL(e)+allotmentR(e)allotment_u(e) = allotment_L(e)+allotment_R(e)

offsetu(e)=offsetL(e)offset_u(e)=offset_L(e)

informationu(e)=Hash(tL(e),offsetR(e),tR(e))information_u(e)=Hash(t_L(e), offset_R(e),t_R(e))

Trường Update

updatei(e)=Hash(Ti(e),Si(e),Ri(e))update_i(e)=Hash(T_i(e), S_i(e), R_i(e))

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

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

Proof Of Exclusive Allotment

Mục tiêu là chứng minh User có sở hữu allotmenti(e)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ộ offsetn(e)offset_n(e) nếu tn(e)t_n(e) là Left child và offsetn(e)+allotmentn(e)offset_n(e)+allotment_n(e) nếu tn(e)t_n(e) là Right child

Ref


All rights reserved

Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí