Sáu thứ mà một phiên Citadel không bao giờ đưa lên onchain: khóa ví của bạn, giấy phép bạn đã dùng, khóa của người phát hành và dịch vụ, các thuộc tính đã ký, và đường dẫn Merkle proof. Điều được đưa lên onchain là một phiên. Công khai, có thể kiểm chứng, và… nhàm chán.
@Dusk xếp việc này vào nhóm “selective disclosure” (tiết lộ có chọn lọc), và nó không phải là một công tắc tăng quyền riêng tư. Một License Provider kiểm tra bạn ở ngoài chuỗi, ký các thuộc tính của bạn, công bố một giấy phép được mã hóa, và đăng ký nó trong một hợp đồng Citadel. Sau đó, bạn chứng minh bằng zero-knowledge rằng bạn sở hữu một giấy phép đã đăng ký. Không phải giấy phép nào. Chỉ là nó tồn tại. Hợp đồng xác minh, ghi lại một phiên, và bạn giao một cookie phiên cho dịch vụ.
Rồi tài liệu vạch ra một đường ranh giới, rất rõ ràng. Citadel chứng minh phiên hợp lệ về mặt mật mã. Nó không quyết định chính sách của dịch vụ. Dịch vụ vẫn là bên chọn các issuer mà nó tin tưởng, các thuộc tính mà nó chấp nhận, liệu phiên có bị thu hồi hay không, và liệu cookie đó có hoạt động hai lần.
Công việc của tôi là kiểm thử một ứng dụng giao dịch chứng khoán, và sự phân tách đó nghe y như thứ gì đó được chép từ bàn làm việc của tôi. Không ai ở đó thấy toàn bộ bức tranh, cố tình như vậy. Người dùng chỉ thấy lệnh của họ. Bộ phận back office thấy cả batch. Kho lưu trữ thấy chỉ dẫn thanh toán. Người giám sát rút một báo cáo theo yêu cầu. Bốn góc nhìn cho một giao dịch, được sắp xếp đâu ra đó từ rất lâu trước khi ai viết mạch tạo bằng chứng.
Quan điểm của tôi: phần có giá trị của Citadel không phải là mật mã, mà là sự từ chối. Một chuỗi mà quyết định tính đủ điều kiện của bạn là thứ mà không một venue nào có thể chấp nhận. Tính đủ điều kiện là vấn đề thẩm quyền pháp lý, điều khoản sản phẩm và khẩu vị rủi ro của issuer. Không cái nào trong đó cần phải dựa vào một hard fork.
Một ứng dụng trên Dusk có tuân thủ không? Không. Vẫn cần ai đó làm License Provider, chạy các kiểm tra ngoài chuỗi, và giải thích khi một lần kiểm tra là sai. Công cụ hiện tại: một thư viện Rust, hợp đồng giấy phép, một lệnh CLI cho ví, và một SDK JavaScript vẫn được ghi là sẽ ra mắt. $DUSK trả phí gas và bảo đảm mạng bằng cách staking.
Vậy ai nên giữ vai trò License Provider cho một tài sản được quản lý: venue, issuer, hay một bên thứ ba mà công việc duy nhất là kiểm tra? Tôi cứ quay lại với bên thứ ba, nhưng không có một lý do thật “sạch” để khẳng định.
#dusk
@Dusk xếp việc này vào nhóm “selective disclosure” (tiết lộ có chọn lọc), và nó không phải là một công tắc tăng quyền riêng tư. Một License Provider kiểm tra bạn ở ngoài chuỗi, ký các thuộc tính của bạn, công bố một giấy phép được mã hóa, và đăng ký nó trong một hợp đồng Citadel. Sau đó, bạn chứng minh bằng zero-knowledge rằng bạn sở hữu một giấy phép đã đăng ký. Không phải giấy phép nào. Chỉ là nó tồn tại. Hợp đồng xác minh, ghi lại một phiên, và bạn giao một cookie phiên cho dịch vụ.
Rồi tài liệu vạch ra một đường ranh giới, rất rõ ràng. Citadel chứng minh phiên hợp lệ về mặt mật mã. Nó không quyết định chính sách của dịch vụ. Dịch vụ vẫn là bên chọn các issuer mà nó tin tưởng, các thuộc tính mà nó chấp nhận, liệu phiên có bị thu hồi hay không, và liệu cookie đó có hoạt động hai lần.
Công việc của tôi là kiểm thử một ứng dụng giao dịch chứng khoán, và sự phân tách đó nghe y như thứ gì đó được chép từ bàn làm việc của tôi. Không ai ở đó thấy toàn bộ bức tranh, cố tình như vậy. Người dùng chỉ thấy lệnh của họ. Bộ phận back office thấy cả batch. Kho lưu trữ thấy chỉ dẫn thanh toán. Người giám sát rút một báo cáo theo yêu cầu. Bốn góc nhìn cho một giao dịch, được sắp xếp đâu ra đó từ rất lâu trước khi ai viết mạch tạo bằng chứng.
Quan điểm của tôi: phần có giá trị của Citadel không phải là mật mã, mà là sự từ chối. Một chuỗi mà quyết định tính đủ điều kiện của bạn là thứ mà không một venue nào có thể chấp nhận. Tính đủ điều kiện là vấn đề thẩm quyền pháp lý, điều khoản sản phẩm và khẩu vị rủi ro của issuer. Không cái nào trong đó cần phải dựa vào một hard fork.
Một ứng dụng trên Dusk có tuân thủ không? Không. Vẫn cần ai đó làm License Provider, chạy các kiểm tra ngoài chuỗi, và giải thích khi một lần kiểm tra là sai. Công cụ hiện tại: một thư viện Rust, hợp đồng giấy phép, một lệnh CLI cho ví, và một SDK JavaScript vẫn được ghi là sẽ ra mắt. $DUSK trả phí gas và bảo đảm mạng bằng cách staking.
Vậy ai nên giữ vai trò License Provider cho một tài sản được quản lý: venue, issuer, hay một bên thứ ba mà công việc duy nhất là kiểm tra? Tôi cứ quay lại với bên thứ ba, nhưng không có một lý do thật “sạch” để khẳng định.
#dusk