Điều khiến tôi dừng lại khi đọc qua kiến trúc của Dusk không phải là một tính năng nổi bật hay một lời hứa trong lộ trình. Đó là một giả định âm thầm được nhúng sâu vào hệ thống: rằng việc thanh toán không nên là điều mà bạn tranh cãi sau này.
Trong các hệ thống tài chính, việc thực hiện rất dễ để chứng minh. Việc thanh toán thì khó để biện minh. Sự phân biệt đó chỉ trở nên rõ ràng sau khi các hệ thống đã hoạt động đủ lâu để đối mặt với các cuộc kiểm toán, tranh chấp và căng thẳng trong hoạt động. Dusk dường như được thiết kế với khoảnh khắc đó trong tâm trí, không phải giai đoạn trình diễn.
Tại đáy của ngăn xếp là DuskDS. Lớp này cố ý nhàm chán theo cách mà hạ tầng nghiêm túc thường có. Nó không lưu trữ ứng dụng. Nó không khuyến khích thử nghiệm. Trách nhiệm của nó hẹp hơn và nghiêm ngặt hơn. DuskDS là nơi mà trạng thái không còn có thể thương lượng.
Nếu một chuyển đổi trạng thái đạt đến lớp này, nó được kỳ vọng đã thỏa mãn các quy tắc đủ điều kiện, quyền hạn và các ràng buộc giao thức. Không có giả định rằng tính chính xác có thể được tái tạo sau đó. Không có giai đoạn giải thích mềm. Thanh toán trên Dusk được coi là một đường mà bạn chỉ vượt qua khi sự không rõ ràng đã được loại bỏ.
Sự lựa chọn đó ngay lập tức tách Dusk khỏi nhiều hệ thống mà tôi đã quan sát trong nhiều năm. Không phải vì những hệ thống đó được thiết kế kém, mà vì chúng chấp nhận một sự đánh đổi khác. Chúng cho phép thực thi di chuyển nhanh và đẩy việc thực thi xuống dưới. Khi có điều gì đó bị hỏng, chúng dựa vào quản trị, phối hợp hoặc quy trình con người để khôi phục sự nhất quán.
DuskDS từ chối sự đánh đổi đó.
Bằng cách kiểm soát thanh toán, Dusk chuyển chi phí ra khỏi hoạt động và vào logic giao thức. Mỗi kết quả không rõ ràng mà không bao giờ vào sổ cái là một cuộc kiểm toán không bao giờ xảy ra. Mỗi chuyển đổi không hợp lệ bị loại trừ là một sự hòa giải không bao giờ cần phải được giải thích nhiều tháng sau. Đây không phải là tiến triển rõ ràng, nhưng là giảm thiểu rủi ro tích lũy.
Đây cũng là nơi DuskEVM phù hợp, và tại sao quyền hạn của nó được giới hạn một cách cố ý. DuskEVM tồn tại để làm cho thực thi dễ tiếp cận. Nó cung cấp cho các nhà phát triển công cụ quen thuộc và giảm ma sát tích hợp. Nhưng nó không được quyền định nghĩa thực tế một mình.
Thực thi trên DuskEVM tạo ra các kết quả ứng cử viên. Những kết quả đó chỉ trở thành trạng thái sau khi vượt qua các ràng buộc được thực thi tại ranh giới DuskDS. Sự tách biệt đó không phải là ngẫu nhiên. Nó cho phép thực thi phát triển mà không để phức tạp rò rỉ trực tiếp vào thanh toán.
Tôi đã thấy đủ hệ thống mà lỗi ứng dụng một cách lặng lẽ biến thành một vấn đề sổ cái vì thực thi và thanh toán quá chặt chẽ với nhau. Dusk có vẻ quyết tâm không lặp lại mô hình đó. Phức tạp được phép tồn tại, nhưng nó không được phép cứng lại mà không kiểm soát.
Thiết kế này cũng giải thích tại sao Dusk thường xuất hiện im lặng. Có ít sửa chữa rõ ràng hơn. Ít đảo ngược hơn. Ít khoảnh khắc mà hệ thống phải giải thích bản thân công khai. Không phải vì không có gì xảy ra, mà vì ít sai lầm tồn tại đủ lâu để quan trọng.
Từ bên ngoài, điều này có thể trông hạn chế. Từ bên trong, nó trông có kỷ luật.
Cơ sở hạ tầng tài chính hiếm khi thất bại vì quá trình thực thi chậm. Nó thất bại vì việc thanh toán không thể được bảo vệ sau đó dưới sự xem xét. DuskDS được xây dựng dựa trên thực tế đó. Nó coi thanh toán không phải là một điểm cuối, mà là một ranh giới bảo vệ mọi thứ bên dưới nó.
Nhiều hệ thống hỏi rằng chúng có thể hỗ trợ bao nhiêu thực thi. Dusk hỏi rằng lớp thanh toán của nó sẵn sàng hấp thụ bao nhiêu sự không rõ ràng.
Đó không phải là một câu hỏi thú vị. Nó không tạo ra tiếng ồn. Nhưng đó là loại câu hỏi xác định liệu cơ sở hạ tầng có sống sót qua áp lực, kiểm toán và thời gian hay không.
Và một khi ranh giới đó trở nên rõ ràng, phần còn lại của kiến trúc Dusk ngừng trông bảo thủ và bắt đầu trông có chủ ý.
