#dusk $DUSK @Dusk
Tôi bắt đầu đếm các tuyến đường độc lập vào DuskEVM và, thật là nhanh—danh sách đã ngắn lại. Tài liệu DUSK chỉ người dùng tới một RPC, một trình khám phá (explorer), một luồng cầu nối Web Wallet, và bộ sắp xếp (sequencer) ở dạng duy nhất.
DuskDS vẫn có thể kết toán các lô (batches) thông qua đồng thuận phi tập trung. Nhưng nếu một sequencer sắp xếp giao dịch, một endpoint mặc định nhận các lần gửi, và một giao diện chính thức cho người dùng biết khi nào việc rút qua cầu (bridge withdrawals) sẵn sàng, thì phía trên lớp đồng thuận tồn tại một lớp phối hợp (coordination). Lớp này có thể không viết lại trạng thái cuối cùng. Nhưng nó vẫn có thể làm chậm, lọc hoặc biến mất.
Điều đó quan trọng đối với DUSK vì nhu cầu gas và thanh khoản trên cầu phụ thuộc vào việc người dùng có thể đạt tới giai đoạn thực thi (execution), chứ không phải việc các bộ cung cấp tiếp tục hoàn tất phía dưới. Thiết kế phân tán việc kết toán; con đường thực tế có thể tập trung việc truy cập thông qua hạ tầng chính thức. Một điều khác.
Hầu hết mọi người nhầm lẫn giữa kết toán đã được xác thực (verified settlement) và truy cập trung lập (neutral access). Chúng không phải là như nhau. Cùng một bài kiểm tra lẽ ra phải bao phủ cả các cụm ngang hàng (peer clusters), các nhà phát hành chứng chỉ của Citadel và quy tắc nạp thêm 90/10: mười bộ cung cấp (provisioners) được lưu trữ cùng nhau không phải là mười miền thất bại (failure domains) độc lập.
Nỗi lo thầm lặng của tôi là dữ liệu còn thiếu. Tôi không thể tìm thấy các phần chia lưu lượng RPC công khai, số lượng peers trung vị, chi tiết chuyển đổi failover của sequencer hay các ngưỡng điều khiển cầu (bridge-control). Cho tới khi DUSK công bố chúng, việc phi tập trung mô tả lớp kết toán một cách chắc chắn hơn so với toàn bộ hành trình của người dùng.
Tôi bắt đầu đếm các tuyến đường độc lập vào DuskEVM và, thật là nhanh—danh sách đã ngắn lại. Tài liệu DUSK chỉ người dùng tới một RPC, một trình khám phá (explorer), một luồng cầu nối Web Wallet, và bộ sắp xếp (sequencer) ở dạng duy nhất.
DuskDS vẫn có thể kết toán các lô (batches) thông qua đồng thuận phi tập trung. Nhưng nếu một sequencer sắp xếp giao dịch, một endpoint mặc định nhận các lần gửi, và một giao diện chính thức cho người dùng biết khi nào việc rút qua cầu (bridge withdrawals) sẵn sàng, thì phía trên lớp đồng thuận tồn tại một lớp phối hợp (coordination). Lớp này có thể không viết lại trạng thái cuối cùng. Nhưng nó vẫn có thể làm chậm, lọc hoặc biến mất.
Điều đó quan trọng đối với DUSK vì nhu cầu gas và thanh khoản trên cầu phụ thuộc vào việc người dùng có thể đạt tới giai đoạn thực thi (execution), chứ không phải việc các bộ cung cấp tiếp tục hoàn tất phía dưới. Thiết kế phân tán việc kết toán; con đường thực tế có thể tập trung việc truy cập thông qua hạ tầng chính thức. Một điều khác.
Hầu hết mọi người nhầm lẫn giữa kết toán đã được xác thực (verified settlement) và truy cập trung lập (neutral access). Chúng không phải là như nhau. Cùng một bài kiểm tra lẽ ra phải bao phủ cả các cụm ngang hàng (peer clusters), các nhà phát hành chứng chỉ của Citadel và quy tắc nạp thêm 90/10: mười bộ cung cấp (provisioners) được lưu trữ cùng nhau không phải là mười miền thất bại (failure domains) độc lập.
Nỗi lo thầm lặng của tôi là dữ liệu còn thiếu. Tôi không thể tìm thấy các phần chia lưu lượng RPC công khai, số lượng peers trung vị, chi tiết chuyển đổi failover của sequencer hay các ngưỡng điều khiển cầu (bridge-control). Cho tới khi DUSK công bố chúng, việc phi tập trung mô tả lớp kết toán một cách chắc chắn hơn so với toàn bộ hành trình của người dùng.