Tôi lại xem kiến trúc module của Dusk và sơ đồ trở nên dễ hiểu hơn khi bạn ngừng nhìn nó như ba chuỗi tách rời.
Thực ra đó là ba công việc khác nhau được chia ra theo từng lớp.
1. DuskDS — lớp nền tảng
Đây là phần cơ sở.
DuskDS chịu trách nhiệm cho các chức năng mạng nền tảng xung quanh:
* đồng thuận
* sẵn có dữ liệu
* quyết toán
Vì vậy, thay vì dồn mọi trách nhiệm thực thi vào lớp nền, DuskDS tập trung vào việc giữ cho hệ thống nền tảng được phối hợp và được quyết toán.
2. DuskEVM — lớp tương thích
Đây là nơi việc thực thi EVM xuất hiện.
Phần thú vị không chỉ đơn giản là “Dusk hỗ trợ EVM”.
Mà là việc thực thi EVM được đặt trong một lớp riêng của kiến trúc module, tạo cho các nhà phát triển một môi trường quen thuộc hơn trong khi vẫn tách biệt lớp DuskDS nền tảng.
Sự tách biệt đó có thể giảm lượng công việc tích hợp cần thiết khi xây dựng ứng dụng.
3. DuskVM — lớp thực thi chú trọng quyền riêng tư
Sau đó là DuskVM.
Vai trò của nó lại khác lần nữa: thực thi tập trung vào quyền riêng tư.
Vì vậy, kiến trúc không ép việc thực thi kiểu công khai và việc thực thi định hướng quyền riêng tư phải diễn ra đúng trong cùng một môi trường.
Chúng được tách ra thành các đường thực thi riêng.
Và sau đó còn có hai phần kết nối toàn bộ thiết kế.
4. Một DUSK xuyên suốt toàn stack
Kiến trúc giữ một token DUSK duy nhất trên các lớp.
Điều này quan trọng vì thực thi module không tự động đồng nghĩa với việc kinh tế bị phân mảnh.
Các môi trường thực thi có thể được tách biệt trong khi nền kinh tế token vẫn thống nhất.
5. Cầu nối native giữa DuskDS và DuskEVM
Các lớp cũng không được phép hoạt động như những hòn đảo tách rời.
Kiến trúc mô tả khái niệm một cầu nối native giữa DuskDS và DuskEVM, giúp lớp thực thi có đường quay trở lại hệ thống Dusk nền tảng.
Đó là phần tôi thấy thú vị hơn chính bản sơ đồ.
Nói ngắn gọn, kiến trúc đang muốn nói rằng:
DuskDS lo phần nền tảng.
DuskEVM lo phần thực thi EVM.
DuskVM lo phần thực thi tập trung vào quyền riêng tư.
$DUSK #dusk @Dusk
Thực ra đó là ba công việc khác nhau được chia ra theo từng lớp.
1. DuskDS — lớp nền tảng
Đây là phần cơ sở.
DuskDS chịu trách nhiệm cho các chức năng mạng nền tảng xung quanh:
* đồng thuận
* sẵn có dữ liệu
* quyết toán
Vì vậy, thay vì dồn mọi trách nhiệm thực thi vào lớp nền, DuskDS tập trung vào việc giữ cho hệ thống nền tảng được phối hợp và được quyết toán.
2. DuskEVM — lớp tương thích
Đây là nơi việc thực thi EVM xuất hiện.
Phần thú vị không chỉ đơn giản là “Dusk hỗ trợ EVM”.
Mà là việc thực thi EVM được đặt trong một lớp riêng của kiến trúc module, tạo cho các nhà phát triển một môi trường quen thuộc hơn trong khi vẫn tách biệt lớp DuskDS nền tảng.
Sự tách biệt đó có thể giảm lượng công việc tích hợp cần thiết khi xây dựng ứng dụng.
3. DuskVM — lớp thực thi chú trọng quyền riêng tư
Sau đó là DuskVM.
Vai trò của nó lại khác lần nữa: thực thi tập trung vào quyền riêng tư.
Vì vậy, kiến trúc không ép việc thực thi kiểu công khai và việc thực thi định hướng quyền riêng tư phải diễn ra đúng trong cùng một môi trường.
Chúng được tách ra thành các đường thực thi riêng.
Và sau đó còn có hai phần kết nối toàn bộ thiết kế.
4. Một DUSK xuyên suốt toàn stack
Kiến trúc giữ một token DUSK duy nhất trên các lớp.
Điều này quan trọng vì thực thi module không tự động đồng nghĩa với việc kinh tế bị phân mảnh.
Các môi trường thực thi có thể được tách biệt trong khi nền kinh tế token vẫn thống nhất.
5. Cầu nối native giữa DuskDS và DuskEVM
Các lớp cũng không được phép hoạt động như những hòn đảo tách rời.
Kiến trúc mô tả khái niệm một cầu nối native giữa DuskDS và DuskEVM, giúp lớp thực thi có đường quay trở lại hệ thống Dusk nền tảng.
Đó là phần tôi thấy thú vị hơn chính bản sơ đồ.
Nói ngắn gọn, kiến trúc đang muốn nói rằng:
DuskDS lo phần nền tảng.
DuskEVM lo phần thực thi EVM.
DuskVM lo phần thực thi tập trung vào quyền riêng tư.
$DUSK #dusk @Dusk