Hai hàm gửi trong các smart contract của Dusk đã thu hút sự chú ý của tôi: caller() và public_sender().
Chúng nghe như hai cách trả lời cho cùng một câu hỏi — ai đã khởi tạo hành động này — nhưng chúng có thể chỉ đến các chủ thể khác nhau. Sự phân biệt này quan trọng khi Dusk hướng tới việc đưa thị trường tài chính lên onchain với các tổ chức được cấp phép tại EU, nơi việc ủy quyền phải tồn tại qua các tương tác hợp đồng phức tạp hơn mà không bị mất dấu chủ thể khởi đầu. caller() xác định contract thực hiện lời gọi ngay lập tức, trong khi public_sender() vẫn có thể trỏ ngược về tài khoản Moonlight đã bắt đầu giao dịch.
Điều tôi chưa biết là liệu các contract của Dusk có luôn ủy quyền người dùng thực sự đã khởi tạo hành động hay không, hay việc thêm các contract trung gian có thể âm thầm thay đổi định danh mà logic ủy quyền nhìn thấy. Các cơ chế đáng theo dõi thì khá rõ ràng: khi contract dựa vào caller(), khi contract dựa vào public_sender(), và điều gì xảy ra khi các batcher hoặc forwarder đứng ở giữa.
Một giao dịch thực thi thành công là chưa đủ để trả lời điều đó. Thử nghiệm mạnh hơn là liệu các quy tắc ủy quyền tương tự vẫn trỏ về đúng chủ thể mong muốn ngay cả khi đường đi thực thi thay đổi.
Tôi quan tâm ít hơn đến việc một hành động đi qua bao nhiêu contract trung gian, mà quan tâm nhiều hơn liệu việc ủy quyền vẫn phân giải tới đúng chủ thể đã thực sự khởi tạo hành động đó hay không.
Điều này quan trọng vì việc thêm một trung gian có thể làm một contract “nhìn thấy” ai khác mà không làm thay đổi người thực sự đã ủy quyền hành động.
Câu hỏi là liệu Dusk có thể thêm nhiều đường thực thi mang tính kết hợp (composable) hơn mà không khiến việc ủy quyền phụ thuộc vào contract nào tình cờ nằm ở giữa.
Tôi đang theo dõi cách caller() và public_sender() được sử dụng khi các mẫu này phát triển.
@Dusk $DUSK #dusk
Chúng nghe như hai cách trả lời cho cùng một câu hỏi — ai đã khởi tạo hành động này — nhưng chúng có thể chỉ đến các chủ thể khác nhau. Sự phân biệt này quan trọng khi Dusk hướng tới việc đưa thị trường tài chính lên onchain với các tổ chức được cấp phép tại EU, nơi việc ủy quyền phải tồn tại qua các tương tác hợp đồng phức tạp hơn mà không bị mất dấu chủ thể khởi đầu. caller() xác định contract thực hiện lời gọi ngay lập tức, trong khi public_sender() vẫn có thể trỏ ngược về tài khoản Moonlight đã bắt đầu giao dịch.
Điều tôi chưa biết là liệu các contract của Dusk có luôn ủy quyền người dùng thực sự đã khởi tạo hành động hay không, hay việc thêm các contract trung gian có thể âm thầm thay đổi định danh mà logic ủy quyền nhìn thấy. Các cơ chế đáng theo dõi thì khá rõ ràng: khi contract dựa vào caller(), khi contract dựa vào public_sender(), và điều gì xảy ra khi các batcher hoặc forwarder đứng ở giữa.
Một giao dịch thực thi thành công là chưa đủ để trả lời điều đó. Thử nghiệm mạnh hơn là liệu các quy tắc ủy quyền tương tự vẫn trỏ về đúng chủ thể mong muốn ngay cả khi đường đi thực thi thay đổi.
Tôi quan tâm ít hơn đến việc một hành động đi qua bao nhiêu contract trung gian, mà quan tâm nhiều hơn liệu việc ủy quyền vẫn phân giải tới đúng chủ thể đã thực sự khởi tạo hành động đó hay không.
Điều này quan trọng vì việc thêm một trung gian có thể làm một contract “nhìn thấy” ai khác mà không làm thay đổi người thực sự đã ủy quyền hành động.
Câu hỏi là liệu Dusk có thể thêm nhiều đường thực thi mang tính kết hợp (composable) hơn mà không khiến việc ủy quyền phụ thuộc vào contract nào tình cờ nằm ở giữa.
Tôi đang theo dõi cách caller() và public_sender() được sử dụng khi các mẫu này phát triển.
@Dusk $DUSK #dusk
