Tôi đã cho rằng nếu tôi muốn thực hiện ba việc trên-chain—approve, swap, rồi stake—thì chain sẽ coi đó là một việc xảy ra hoặc không xảy ra. Một issue mở trong repository Rusk của chính Dusk nói rằng không phải như vậy hiện nay.
Giao dịch của Dusk ngày nay mang một thao tác tùy chọn duy nhất: một lệnh gọi contract, một deploy, hoặc một memo, với một giá trị, một người nhận, một nonce và một chữ ký. Vì vậy, approve, swap và stake trở thành ba giao dịch tách rời, mỗi giao dịch độc lập được đưa vào hoặc bị loại bỏ. Issue của Dusk nêu thẳng rằng: không có cam kết atomicity giữa chúng. Thực hiện approve và swap nhưng không stake, và bạn sẽ bị kẹt giữa luồng mà không có cơ chế rollback ở cấp giao thức.
Vấn đề không chỉ là các luồng nhiều bước có thể dừng giữa chừng. Việc khắc phục điều đó sẽ thay đổi ai phải gánh chi phí tương thích.
Một contract batcher có thể làm toàn bộ chuỗi thao tác trở nên atomic, vì khi một sub-call thất bại thì toàn bộ giao dịch bên ngoài sẽ bị revert. Nhưng một contract đích kiểm tra xem ai đang gọi trực tiếp nó sẽ thấy batcher chứ không thấy bạn, trừ khi contract đó đã được viết để nhìn vượt qua người gọi ngay lập tức. Còn một batch transaction ở cấp giao thức giữ bạn là người gọi ở mọi bước, nhưng nó không thể “xuất xưởng” nếu không có một định dạng giao dịch mới, các thay đổi consensus, một hard-fork và tất cả các wallet SDK kịp cập nhật.
Thêm batching không loại bỏ sự đánh đổi. Nó quyết định liệu gánh nặng tương thích nằm ở phần ủy quyền trong ứng dụng hay trong ngăn xếp giao thức.
"Sửa atomicity không loại bỏ sự đánh đổi; nó quyết định gánh nặng tương thích và ranh giới tin cậy sẽ dịch chuyển đến đâu."
Thứ tôi thực sự muốn theo dõi: Dusk có chọn batcher ở cấp ứng dụng hay transaction ở cấp giao thức, và lựa chọn đó buộc các giả định hiện có về ủy quyền phải thay đổi như thế nào đối với các nhà phát triển.
#dusk $DUSK @Dusk
Giao dịch của Dusk ngày nay mang một thao tác tùy chọn duy nhất: một lệnh gọi contract, một deploy, hoặc một memo, với một giá trị, một người nhận, một nonce và một chữ ký. Vì vậy, approve, swap và stake trở thành ba giao dịch tách rời, mỗi giao dịch độc lập được đưa vào hoặc bị loại bỏ. Issue của Dusk nêu thẳng rằng: không có cam kết atomicity giữa chúng. Thực hiện approve và swap nhưng không stake, và bạn sẽ bị kẹt giữa luồng mà không có cơ chế rollback ở cấp giao thức.
Vấn đề không chỉ là các luồng nhiều bước có thể dừng giữa chừng. Việc khắc phục điều đó sẽ thay đổi ai phải gánh chi phí tương thích.
Một contract batcher có thể làm toàn bộ chuỗi thao tác trở nên atomic, vì khi một sub-call thất bại thì toàn bộ giao dịch bên ngoài sẽ bị revert. Nhưng một contract đích kiểm tra xem ai đang gọi trực tiếp nó sẽ thấy batcher chứ không thấy bạn, trừ khi contract đó đã được viết để nhìn vượt qua người gọi ngay lập tức. Còn một batch transaction ở cấp giao thức giữ bạn là người gọi ở mọi bước, nhưng nó không thể “xuất xưởng” nếu không có một định dạng giao dịch mới, các thay đổi consensus, một hard-fork và tất cả các wallet SDK kịp cập nhật.
Thêm batching không loại bỏ sự đánh đổi. Nó quyết định liệu gánh nặng tương thích nằm ở phần ủy quyền trong ứng dụng hay trong ngăn xếp giao thức.
"Sửa atomicity không loại bỏ sự đánh đổi; nó quyết định gánh nặng tương thích và ranh giới tin cậy sẽ dịch chuyển đến đâu."
Thứ tôi thực sự muốn theo dõi: Dusk có chọn batcher ở cấp ứng dụng hay transaction ở cấp giao thức, và lựa chọn đó buộc các giả định hiện có về ủy quyền phải thay đổi như thế nào đối với các nhà phát triển.
#dusk $DUSK @Dusk
