Cách tôi nhìn nhận về các validator đã thay đổi rất nhiều theo thời gian. Tôi từng đánh giá các mạng lưới dựa trên khả năng của các validator của họ. Logic thông minh hơn, hành vi thích ứng hơn, phối hợp nhanh hơn. Thật trực quan rằng các validator mạnh hơn có nghĩa là cơ sở hạ tầng mạnh hơn.

Sau khi xem đủ các sự cố sản xuất, tôi không còn nghĩ đó là chỉ số đúng.

Điều quan trọng hơn không phải là các validator có thể quyết định bao nhiêu, mà là họ được phép quyết định bao nhiêu khi có điều gì bất thường xảy ra.

Sự khác biệt đó nghe có vẻ nhỏ. Trong các hệ thống thanh toán, điều đó không phải vậy.

Trên nhiều chuỗi, các validator được kỳ vọng sẽ thực hiện phán đoán trong các điều kiện biên. Họ giải thích các quy tắc, phối hợp phản ứng, quyết định cách áp dụng các ràng buộc một cách nghiêm ngặt, đôi khi thậm chí dựa vào sự đồng thuận xã hội khi logic giao thức không còn rõ ràng. Sự linh hoạt đó thường được quảng bá như là khả năng phục hồi.

Trong thực tế, nó giới thiệu một lớp rủi ro thứ hai.

Khoảnh khắc mà các validator phải giải thích thay vì thực thi, việc giải quyết dừng lại không còn hoàn toàn cơ học. Kết quả bắt đầu phụ thuộc vào chất lượng phối hợp của con người, thời gian và động lực. Hai bộ validator với cùng một quy tắc có thể tạo ra kết quả thực tế khác nhau dưới áp lực chỉ vì họ lý luận khác nhau.

Đó là sự tùy ý của validator, và đó là một bề mặt rủi ro ẩn giấu.

Sự tùy ý của validator mở rộng bề mặt rủi ro giải quyết. Thực thi theo quy tắc nén biến thể kết quả.

Tôi bắt đầu chú ý đến Plasma vì nó dường như cố ý không thoải mái với bề mặt đó. Thiết kế đẩy trách nhiệm của validator về phía thực thi, không phải giải thích. Vai trò này hẹp hơn những gì nhiều nhà điều hành đã quen thuộc. Áp dụng quy tắc. Kiểm tra các chuyển đổi. Từ chối những gì không phù hợp. Tiến lên.

Không thông minh. Không thích nghi. Chỉ nhất quán.

Nhìn thoáng qua, điều này có thể cảm thấy như việc sử dụng không hết tiềm năng của các validator. Nếu bạn có những nhà điều hành có khả năng, tại sao không để họ giúp điều khiển hệ thống qua những điều kiện khó khăn. Tại sao không cho họ không gian để tối ưu hóa kết quả từng trường hợp một.

Bởi vì việc tối ưu hóa từng trường hợp một chính là nơi mà trách nhiệm bắt đầu trở nên mờ nhạt.

Khi các validator được trao quyền giải thích ý định, mọi cuộc giải quyết khó khăn trở thành một sự kiện quản trị một phần. Ngay cả khi không có cuộc bỏ phiếu nào diễn ra, sự phối hợp vẫn xảy ra. Các cuộc trò chuyện riêng tư, sự đồng thuận không chính thức, sở thích mềm mại. Từ bên ngoài, nó trông giống như giao thức đã hoạt động. Ẩn sau, con người đã thương lượng con đường.

Khoảng cách đó khó mô hình hóa và không thể định giá một cách sạch sẽ.

Cách tiếp cận của Plasma đọc khác với tôi. Nó xem sự tùy ý của validator như một điều cần phải giảm thiểu sớm, không phải để ăn mừng. Giao thức cố gắng trả lời hành vi biên trước thông qua thực thi bị ràng buộc và các con đường xác thực cố định, thay vì để lại không gian cho phán đoán trong thời gian thực.

Các con đường xác thực cố định loại bỏ việc giải thích trong thời gian thực, vì vậy áp lực không tạo ra các nhánh giải quyết mới.

Điều đó chuyển gánh nặng lên trên, vào thời gian thiết kế.

Bạn phải trả nhiều hơn ngay từ đầu về tính cứng nhắc. Bạn mất một số sự xử lý duyên dáng. Một số trường hợp biên sẽ cảm thấy khắc nghiệt vì hệ thống từ chối uốn cong. Những người xây dựng kỳ vọng sự đồng cảm của validator sẽ thấy điều đó thật khó chịu.

Nhưng bạn nhận được điều gì đó cấu trúc để đổi lấy.

Khi sự tùy ý của validator thấp, hành vi giải quyết trở nên rõ ràng hơn. Các bên tham gia không cần mô phỏng cây phản ứng xã hội trên các quy tắc giao thức. Có ít nhánh kịch bản xung quanh “những gì mà các nhà điều hành có thể làm.” Chủ yếu chỉ có những gì quy tắc nói.

Từ góc độ rủi ro, sự nén đó rất quan trọng.

Trong các hệ thống linh hoạt, thông số kỹ thuật chỉ là một nửa mô hình. Nửa còn lại là văn hóa validator và chất lượng phối hợp. Trong các hệ thống bị ràng buộc, nhiều phần của mô hình sống trực tiếp trong mã và ít hơn trong hành vi. Điều đó không loại bỏ rủi ro, nhưng nó di dời nó vào một hộp chặt chẽ hơn.

Tôi không xem điều này là vượt trội một cách phổ quát. Một số môi trường thực sự hưởng lợi từ phán đoán của nhà điều hành và sự phối hợp nhanh chóng. Các lớp thử nghiệm cao thường cần tự do đó. Nhưng cơ sở hạ tầng giải quyết có một mô tả công việc khác. Nó ít liên quan đến các kết quả tối ưu và nhiều hơn về các kết quả có thể lặp lại.

Tâm lý của riêng tôi bây giờ rất đơn giản. Càng nhiều giá trị mà một lớp được kỳ vọng sẽ giải quyết liên tục, tôi càng không muốn sự tùy ý của validator nằm trong con đường quan trọng của nó.

Plasma dường như đồng bộ với thiên kiến đó. Các validator không được định vị như những người giải quyết vấn đề dưới áp lực. Họ được định vị như những người thực thi quy tắc dưới sự ràng buộc. Đó là một lựa chọn triết học cũng như một lựa chọn kỹ thuật.

Nó sẽ không tạo ra hệ thống năng động nhất. Nó sẽ không chiến thắng trong các câu chuyện về khả năng thích nghi. Nhưng nó làm điều gì đó mà tôi đã học để tôn trọng trong cơ sở hạ tầng. Nó giảm số lượng quyết định của con người cần thiết trong khoảnh khắc tồi tệ nhất.

Trong việc giải quyết, ít quyết định hơn dưới áp lực thường là một đặc điểm, không phải một giới hạn.

@Plasma #plasma $XPL