robo

Tối qua tôi đã xem lại tài liệu cho các mô hình giao dịch @Dusk và dành vài giờ chỉ để cố gắng lập bản đồ cách Moonlight và Phoenix thực sự ghép lại với nhau.

Ban đầu sự khác biệt trông có vẻ rõ ràng. Moonlight là phần minh bạch, dựa trên tài khoản: mỗi tài khoản duy trì một trạng thái công khai ghi lại số dư và nonce của nó. Phoenix là phần được “che chắn” dựa trên note: một note được cấu trúc quanh khóa công khai của người nhận, một giá trị v, và một vài số vô hướng ngẫu nhiên bổ sung; các note được lập chỉ mục bên trong một cây Merkle để người chi tiêu có thể chứng minh sự tồn tại (inclusion) mà không tiết lộ chính note đó. Việc chi tiêu yêu cầu một bằng chứng không kiến thức (zero-knowledge proof) và việc công bố một nullifier để mạng có thể từ chối các giao dịch chi tiêu lặp (double-spends). Tài liệu cũng nêu rằng giá trị của note được giới hạn bởi 2^{64}-1.

Các đường chuyển đổi giữa hai mô hình (gửi vào các note Phoenix, rút về lại các tài khoản Moonlight) được mô tả, nhưng tôi cứ bị kẹt ở những giả định bảo mật chính xác được duy trì trong các bước “bàn giao” đó. Người ta nói rằng các mạch (circuits) đảm bảo tính đúng đắn (validity), nhưng tôi không tìm thấy một tuyên bố rõ ràng về việc liệu một lần chuyển đổi bị tạo sai (malformed) duy nhất có thể ảnh hưởng đến tập hợp nullifier toàn cục hay đến các số dư minh bạch mà các smart contract dựa vào hay không.

Điều đó đã đặt ra cho tôi một câu hỏi rộng hơn về phi tập trung (decentralization): nếu phần lớn giá trị cuối cùng nằm trong các note Phoenix, thì quyền quản trị (governance) thực tiễn còn lại với lớp tài khoản minh bạch—lớp mà các contract và oracle thực sự nhìn thấy—còn được bao nhiêu?

Thiết kế mạch hiện tại và giới hạn giá trị 2^{64}-1 được xem là “chốt” chưa, hay vẫn còn các tham số mở liên quan đến việc tạo note, độ sâu cây Merkle và tính duy nhất của nullifier mà cộng đồng vẫn đang tiếp tục thảo luận/cải tiến?

Rất mong nhận được bất kỳ gợi ý nào từ những người đã đi sâu vào các phần chứng minh (proofs).

#dusk $DUSK