Nói thật thì, bây giờ khi tôi xem SIGN, điều đầu tiên xuất hiện trong đầu không phải là “chứng nhận này có thể phát ra không”, mà là một loạt câu hỏi cụ thể hơn: nó sẽ hết hạn khi nào, ai có thể thu hồi, nếu hết hạn thì phải làm sao, sau khi gia hạn thì phiên bản cũ còn được tính không, hệ thống sau này sẽ công nhận phiên bản nào.
Nhiều người khi nói về chứng nhận, bằng cấp, chứng từ, thường mặc định chỉ xem “có hay không”. Nhưng tôi ngày càng cảm thấy rằng, hệ thống phức tạp thực sự khó khăn, không phải chỉ là phát hành một lần, mà là chứng nhận này từ khi có hiệu lực đến khi hết hạn, từ khi bị thu hồi đến khi cập nhật, từ phiên bản cũ đến phiên bản mới, toàn bộ vòng đời có thể được hệ thống tiếp nhận hay không. Bởi vì trong thực tế, chứng nhận không bao giờ chỉ là một hình chụp xong là hết. Một số bằng cấp sẽ hết hạn, một số quyền hạn sẽ bị thu hồi, một số tuyên bố chỉ có hiệu lực trong thời gian nhất định, một số thông tin danh tính sau khi cập nhật có thể không còn được sử dụng chứng nhận cũ. Nếu bạn chỉ coi chứng nhận như “kết quả được tạo ra một lần”, thì việc phân phối, quyền hạn, đánh giá bằng cấp sau đó rất dễ bị ô nhiễm bởi trạng thái cũ.
Vì vậy, giờ tôi ngày càng không thích những dự án viết chứng nhận một cách quá nhẹ nhàng. Dường như chỉ cần có chứng nhận, có credential, có một lần xác nhận, thì mọi chuyện đã kết thúc. Nhưng điều thực sự khó khăn ở cấp độ sản phẩm không phải là "phát ra", mà là "sống sót". Chứng nhận này hiện tại có còn hiệu lực không? Đối tượng phát ra dưới schema này, liệu có thể được tra cứu, thu hồi, gia hạn, tái trích dẫn hay không? Sau khi phiên bản này hết hạn, hệ thống có tự động loại bỏ trạng thái cũ khỏi quy trình tiếp theo không? Nếu không có ai xử lý những vấn đề này, thì cái gọi là "chứng nhận có thể xác thực" nhiều lúc chỉ là ảnh chụp trên chuỗi, không phải là đối tượng quy trình.
Đây cũng là điều tôi đang suy nghĩ sâu sắc hơn khi xem xét Sign Protocol. Trong mắt tôi, chứng nhận không phải chỉ để lại một dấu vết tạm thời, mà nên là một đối tượng động có thể tra cứu, được trích dẫn, có thể thu hồi, có thể hết hạn và có thể gia hạn; giá trị của schema không chỉ là định nghĩa trường mà còn là giúp cho loại đối tượng này có cấu trúc ổn định, để hệ thống sau này biết cách nhìn, cách xem phiên bản, cách theo dõi sự thay đổi trạng thái. Nói cách khác, hệ thống không xử lý "có chứng nhận hay không", mà là "chứng nhận này hiện đang ở trạng thái nào". Hai điều này trông có vẻ chỉ khác nhau một câu, nhưng thực tế khác nhau ở độ trưởng thành của toàn bộ chuỗi sản phẩm.
Ý nghĩa của TokenTable ở đây sẽ bị nhiều người hiểu nông. Nó không chỉ là một "công cụ phát coin" hay "bảng phân phối", mà là liệu vòng đời chứng nhận có thể thực sự đi vào phân phối và thực thi quyền hạn hay không. Nếu chứng nhận đủ điều kiện trước đó đã hết hạn, đã bị thu hồi, hoặc đã bị thay thế bởi phiên bản mới, thì các logic về quyền sở hữu, mở khóa, nhận sẽ có thể được cập nhật theo không? Nếu không, thì mọi tuyên bố có thể xác thực mà bạn đã thực hiện trước đó, về bản chất chỉ dừng lại ở trên chuỗi, mà không thực sự vào hệ thống. Nhiều người viết dự án dễ dàng chỉ viết "chứng nhận đã tồn tại", nhưng giờ tôi quan tâm hơn đến: sau khi tồn tại, nó sẽ sống như thế nào, thay đổi ra sao, chết như thế nào, và sau khi chết, hệ thống có biết nó đã chết hay không.
Tại sao tôi lại đặc biệt quan tâm đến vấn đề này? Bởi vì tôi càng ngày càng cảm thấy, quy trình thực tế sẽ không tự nhiên biến thành một thế giới tĩnh một lần chỉ vì bạn đưa nó lên chuỗi. Ngược lại, càng đi về phía thực tế, vòng đời của chứng nhận càng dài, quản lý phiên bản càng phức tạp, trạng thái quyền hạn càng dễ thay đổi. Bạn hôm nay có đủ điều kiện, không có nghĩa là tháng sau bạn vẫn có; hôm nay bạn được cấp quyền, không có nghĩa là quyền sẽ không bao giờ bị thu hồi; hôm nay tuyên bố này có thể được trích dẫn, không có nghĩa là sau nửa năm vẫn tuân theo cùng một bộ quy tắc. Hệ thống phức tạp sợ nhất không phải là không có chứng nhận, mà là cầm chứng nhận đã hết hạn tiếp tục chạy về phía trước. Bề ngoài có đối tượng, có hồ sơ, có trạng thái, nhưng thực tế toàn bộ quy trình tiếp theo đều bị kéo bởi phiên bản cũ.
Từ góc độ của một nhà nghiên cứu sản phẩm, tôi cảm thấy những thứ này không phải là sôi nổi, nhưng một khi nó được đưa vào nhiều quy trình trên chuỗi hơn, độ bám dính sẽ rất mạnh. Bởi vì một khi bạn bắt đầu xử lý nghiêm túc vòng đời của chứng nhận, tất cả các quyền, quyền hạn, phân phối, và tiếp nhận sẽ trở nên ổn định hơn. Ngược lại, nếu bạn cứ coi chứng nhận như là một kết quả tĩnh một lần, thì tất cả những khả năng xác thực trông rất đẹp, cuối cùng có thể bị vấn đề "cập nhật trạng thái" thực tế nhất đập lại. Thị trường ngắn hạn không nhất thiết sẽ hiểu ngay giá trị này, vì nó không phải là kiểu kể chuyện có thể nhanh chóng tạo ra điểm bùng nổ cảm xúc. Nhưng từ góc độ sâu về sản phẩm, nó quan trọng hơn nhiều so với "đã phát bao nhiêu chứng nhận".
Vậy nên giờ tôi nhìn vào $SIGN , không chỉ quan tâm xem nó có thể phát thêm bao nhiêu chứng nhận, mà tôi muốn xem liệu nó có thể làm cho chuỗi "từ khi tạo ra đến khi hết hạn" trở thành một cấu trúc thực sự hay không. Liệu hệ thống có thể nhận biết được chứng nhận này là mới hay cũ, còn sống hay đã chết, có thể sử dụng hay không, có nên tiếp tục được quy trình sau đó hay không. Bởi vì nhiều dự án coi chứng nhận như ảnh chụp màn hình, nhưng cái khó khăn thực sự là chứng nhận cũng có vòng đời của nó. Ai có thể biến vòng đời này thành một sản phẩm, không chỉ đơn giản là thêm một chức năng, mà là gần gũi hơn với quy trình logic thực tế sẽ thay đổi, hết hạn, và được cập nhật.