Gần đây tôi đang suy nghĩ một vấn đề: vì sao đa số blockchain công khai lại nhấn mạnh tính tương thích, trong khi rất ít người thảo luận “các tài sản khác nhau có cần logic thực thi khác nhau hay không”? Khi tìm hiểu kiến trúc kỹ thuật của Dusk, tôi nhận ra nó không đi theo hướng “một máy ảo dùng cho mọi thứ”. DuskEVM cung cấp cho các nhà phát triển Solidity một môi trường quen thuộc, DuskVM cho phép các hợp đồng Rust chạy trực tiếp trên L1, còn Transfer Contract sẽ phân phối theo các đường xác thực tương ứng dựa trên các loại dữ liệu tải của giao dịch—thiết kế này không phải để khoe kỹ thuật, mà là để đáp ứng một thực tế: khi các tài sản phức tạp như cổ phần quỹ tư nhân và trái phiếu doanh nghiệp được đưa lên chuỗi, quy tắc thực thi mà chúng cần hoàn toàn khác so với các token thông thường.
Mối rắc rối của tài sản truyền thống không nằm ở khâu phát hành, mà nằm ở khâu sử dụng. Một chứng chỉ quỹ tư nhân có thể dùng làm tài sản thế chấp không? Nếu được thì khi thanh lý, tài sản thế chấp sẽ chuyển cho ai? Danh tính nhà đầu tư đủ điều kiện được xác minh như thế nào? Những quy tắc này nếu chỉ tồn tại trên các giao thức ngoài chuỗi hoặc bị giới hạn bởi front-end thì sẽ bị lách qua; còn nếu “đóng cứng” vào trong hợp đồng thì lại phải đánh đổi lấy tính linh hoạt.
Cách Dusk làm là đưa logic xác minh lên phía trước trong môi trường thực thi. Phoenix xử lý các giao dịch cần che giấu số tiền, Moonlight xử lý các tình huống cần công khai minh bạch; hai thành phần này dùng chung một tầng kết toán. Điều này có nghĩa thuộc tính của tài sản không dựa vào sự tự giác của bên phát hành, mà được cưỡng chế thực thi bởi kiến trúc tầng nền.
Tuy nhiên, việc phân lớp này cũng tạo ra chi phí nhận thức. Lập trình viên cần hiểu khi nào nên dùng máy ảo nào, người dùng cần nắm rõ giao dịch của mình đang đi theo đường nào. Nếu phần lớn mọi người lâu nay chỉ dùng lớp tương thích với EVM thì năng lực nguyên bản của DuskVM và Phoenix chỉ là lợi thế mang tính lý thuyết.
Vì vậy, điều tôi quan tâm không phải Dusk hỗ trợ được bao nhiêu loại tài sản, mà là liệu các tài sản đó có thực sự được dùng đến những năng lực khác biệt mà nó được thiết kế hay không. Giá trị của kiến trúc kỹ thuật cuối cùng phải được kiểm chứng qua các kịch bản sử dụng thực tế.
#dusk @Dusk $DUSK
Mối rắc rối của tài sản truyền thống không nằm ở khâu phát hành, mà nằm ở khâu sử dụng. Một chứng chỉ quỹ tư nhân có thể dùng làm tài sản thế chấp không? Nếu được thì khi thanh lý, tài sản thế chấp sẽ chuyển cho ai? Danh tính nhà đầu tư đủ điều kiện được xác minh như thế nào? Những quy tắc này nếu chỉ tồn tại trên các giao thức ngoài chuỗi hoặc bị giới hạn bởi front-end thì sẽ bị lách qua; còn nếu “đóng cứng” vào trong hợp đồng thì lại phải đánh đổi lấy tính linh hoạt.
Cách Dusk làm là đưa logic xác minh lên phía trước trong môi trường thực thi. Phoenix xử lý các giao dịch cần che giấu số tiền, Moonlight xử lý các tình huống cần công khai minh bạch; hai thành phần này dùng chung một tầng kết toán. Điều này có nghĩa thuộc tính của tài sản không dựa vào sự tự giác của bên phát hành, mà được cưỡng chế thực thi bởi kiến trúc tầng nền.
Tuy nhiên, việc phân lớp này cũng tạo ra chi phí nhận thức. Lập trình viên cần hiểu khi nào nên dùng máy ảo nào, người dùng cần nắm rõ giao dịch của mình đang đi theo đường nào. Nếu phần lớn mọi người lâu nay chỉ dùng lớp tương thích với EVM thì năng lực nguyên bản của DuskVM và Phoenix chỉ là lợi thế mang tính lý thuyết.
Vì vậy, điều tôi quan tâm không phải Dusk hỗ trợ được bao nhiêu loại tài sản, mà là liệu các tài sản đó có thực sự được dùng đến những năng lực khác biệt mà nó được thiết kế hay không. Giá trị của kiến trúc kỹ thuật cuối cùng phải được kiểm chứng qua các kịch bản sử dụng thực tế.
#dusk @Dusk $DUSK