Tôi đã dành một thời gian để xem qua tài liệu của Sign Protocol cố gắng hiểu điều gì thực sự làm cho nó khác biệt so với các hệ thống chứng thực khác. Hầu hết các khía cạnh bề mặt đều dễ hiểu, các sơ đồ, chứng thực, lập chỉ mục omni-chain, bạn đã thấy lời chào đó trước đây. Nhưng có một phần khiến tôi dừng lại và đọc lại vài lần vì nó cảm thấy như đến từ một triết lý thiết kế hoàn toàn khác so với phần còn lại của cơ sở hạ tầng crypto.
Nếu bạn đã theo dõi Uniswap V4, có lẽ bạn đã biết khái niệm này. Hooks là logic tùy chỉnh chạy tự động tại các điểm cụ thể trong một quy trình. Trong trường hợp của Uniswap, chúng kích hoạt trước hoặc sau một lần hoán đổi, cho phép các nhà phát triển tiêm các quy tắc của riêng họ vào giao thức mà không cần phải fork nó. Đây là một vấn đề lớn khi họ công bố điều đó vì điều này có nghĩa là giao thức cốt lõi có thể giữ đơn giản trong khi các phần rìa trở nên có thể lập trình.
Sign Protocol đã áp dụng cùng một ý tưởng đó vào các chứng thực. Và thành thật mà nói, đó là phần tôi luôn quay lại.
Đây là lý do tại sao điều này quan trọng. Trong hầu hết các hệ thống chứng thực, quy trình khá tuyến tính. Ai đó tạo ra một yêu cầu, ai đó ký nó, nó được lưu trữ, và người khác có thể xác minh nó sau. Sạch sẽ và đơn giản. Nhưng vấn đề là trong thế giới thực, không phải mọi yêu cầu đều nên được chấp nhận chỉ vì nó có định dạng đúng. Đôi khi bạn cần kiểm tra xem người phát hành thực sự có quyền hạn hay không. Đôi khi bạn cần xác minh rằng một ngưỡng đã được đáp ứng. Đôi khi bạn cần đảm bảo rằng yêu cầu không vi phạm một điều kiện chỉ tồn tại trong bối cảnh của một ứng dụng cụ thể.
Nếu không có hooks, tất cả logic đó phải sống bên ngoài lớp chứng thực. Điều này có nghĩa là mỗi ứng dụng xây dựng xác minh riêng của nó ở trên, và bạn kết thúc với cùng một vấn đề phân mảnh mà các chứng thực đáng lẽ phải giải quyết ngay từ đầu. Bạn chỉ chuyển hỗn độn từ xác minh danh tính sang xác minh chứng thực.
Với các hooks, Sign cho phép các nhà phát triển đính kèm logic tùy chỉnh trực tiếp vào một sơ đồ. Vì vậy, khi ai đó cố gắng tạo một chứng thực dựa trên sơ đồ đó, hook chạy trước. Nó có thể kiểm tra bất cứ điều gì mà nhà phát triển đã lập trình, điều kiện whitelist, ngưỡng cân bằng, khoảng thời gian, dữ liệu oracle bên ngoài, bất cứ điều gì. Và nếu kiểm tra thất bại, giao dịch chỉ đơn giản là quay lại. Chứng thực không bao giờ được tạo ra. Không có gì xấu đi vào lớp chứng cứ.
Tôi nghĩ điều này quan trọng hơn vẻ bề ngoài.
Bởi vì nó có nghĩa là lớp chứng cứ giữ sạch sẽ. Không phải bằng cách tin tưởng vào mọi người chỉ gửi các yêu cầu hợp lệ, mà bằng cách thực thi xác minh một cách lập trình trước khi bất cứ điều gì được ghi lại. Đó là sự khác biệt giữa một cơ sở dữ liệu chấp nhận mọi thứ và lọc sau, so với một hệ thống từ chối các đầu vào không hợp lệ ngay tại cổng. Bất cứ ai đã làm việc với dữ liệu lộn xộn đều biết bạn muốn cái nào.
Và lựa chọn thiết kế của việc làm cho các hooks chạy tại thời điểm tạo thay vì thời điểm xác minh khiến tôi cảm thấy thú vị. Hầu hết các hệ thống tôi đã thấy thực hiện xác minh tại điểm sử dụng. Bạn có một chứng thực và khi ai đó cố gắng dựa vào nó, người xác minh sẽ kiểm tra xem nó còn hợp lệ hay không. Sign đảo ngược điều đó. Nó đẩy những quyết định khó khăn hơn về phía trước trong vòng đời. Khi một chứng thực tồn tại, nó đã sống sót qua các ràng buộc của sơ đồ và logic của hook. Vì vậy, các hệ thống phía dưới không cần phải nghi ngờ về nó. Họ chỉ cần đọc bằng chứng và hành động dựa trên đó.
Điều này làm tôi nhớ đến cách một số ngôn ngữ lập trình xử lý lỗi. Có cách tiếp cận mà bạn để mọi thứ đi qua và bắt lỗi sau với các khối try-catch ở khắp mọi nơi. Và sau đó có cách tiếp cận mà hệ thống loại ngăn chặn các trạng thái không hợp lệ tồn tại ngay từ đầu. Các hooks của Sign cảm thấy giống như cách tiếp cận thứ hai. Bạn không nhận được một "chứng thực không hợp lệ" nằm đâu đó. Bạn hoặc nhận được một chứng thực hợp lệ hoặc không nhận được gì cả.
Nhưng đây là nơi mà suy nghĩ của tôi trở nên thận trọng hơn.
Hooks thêm sức mạnh nhưng cũng làm tăng độ phức tạp. Nếu một nhà phát triển viết một hook có lỗi, nó có thể chặn các chứng thực hợp lệ không được tạo ra. Nếu một hook có lỗi logic tinh vi, nó có thể cho phép các yêu cầu không nên được thông qua. Và vì hooks chạy trên chuỗi như một phần của giao dịch, chi phí gas tăng lên với mỗi kiểm tra bổ sung. Đối với các trường hợp sử dụng đơn giản, điều này là ổn. Đối với các triển khai chủ quyền phức tạp với nhiều điều kiện, nó có thể trở nên đắt đỏ và khó kiểm toán.
Cũng có câu hỏi về tiêu chuẩn hóa. Nếu mỗi dự án viết các hooks của riêng mình với logic riêng, bạn có thể kết thúc với các hooks bị phân mảnh giống như các hệ thống xác thực mà chúng đáng lẽ phải thay thế. Các sơ đồ có thể được chia sẻ nhưng logic thi hành thì không. Và sau đó khả năng tương tác bắt đầu bị phá vỡ ở cấp độ hook thay vì cấp độ chứng thực.
Tôi cũng tự hỏi điều gì sẽ xảy ra khi một hook cần được cập nhật. Các sơ đồ được phiên bản hóa và không thể thay đổi một khi đã hoàn thành. Nhưng quy tắc thế giới thực thay đổi. Các tiêu chí đủ điều kiện cho một chương trình của chính phủ có thể thay đổi. Các yêu cầu tuân thủ được cập nhật. Nếu logic của hook được tích hợp vào việc triển khai sơ đồ, việc cập nhật nó mà không làm hỏng các chứng thực hiện có trở thành một thách thức thiết kế mà tôi chưa thấy được giải quyết hoàn toàn trong tài liệu.
Và sau đó có câu hỏi về tính minh bạch. Các hooks thực thi trên chuỗi nhưng logic bên trong chúng có thể không rõ ràng đối với người dùng cuối. Một người có thể biết rằng nỗ lực chứng thực của họ đã bị quay lại nhưng họ có thể không hiểu tại sao. Trong các hệ thống chủ quyền nơi các chứng thực kiểm soát quyền truy cập vào phúc lợi, xác minh danh tính, hoặc phân phối vốn, sự thiếu minh bạch đó có thể trở thành một vấn đề thực sự. Mọi người cần biết lý do tại sao họ bị từ chối, không chỉ rằng họ đã bị từ chối.
Tuy nhiên, bất chấp những lo ngại này, tôi vẫn nghĩ rằng ý tưởng cốt lõi là hợp lý. Đẩy xác minh sớm hơn trong vòng đời gần như luôn tốt hơn là dọn dẹp các rắc rối sau đó. Và việc cho phép các nhà phát triển tùy chỉnh việc thi hành mà không cần phải fork giao thức là loại khả năng mở rộng giúp cơ sở hạ tầng tồn tại lâu dài.
Sự so sánh với Uniswap V4 đáng để xem xét nghiêm túc. Hooks đã biến Uniswap từ một DEX thành một nền tảng. Nếu các hooks của Sign hoạt động như thiết kế, chúng có thể biến một giao thức chứng thực thành một thứ linh hoạt hơn nhiều so với chỉ là một lớp xác minh. Các cổng tin cậy có thể lập trình mà bất kỳ ai cũng có thể tùy chỉnh nhưng không ai cần phải xây dựng lại từ đầu.
Liệu tiềm năng đó có được hiện thực hóa hay không phụ thuộc vào việc các nhà phát triển có chấp nhận hay không. Và đó luôn là phần khó khăn nhất. Thiết kế tốt không đảm bảo việc sử dụng. Crypto có rất nhiều giao thức được thiết kế tốt mà không ai xây dựng trên đó vì hệ sinh thái đã chọn một cái gì đó đơn giản hơn hoặc quen thuộc hơn.
Vì vậy, tôi đang theo dõi điều này chặt chẽ nhưng chưa đưa ra bất kỳ quyết định nào. Kiến trúc hook là phần của Sign làm tôi ấn tượng nhất. Liệu nó có trở thành phần thực sự thúc đẩy việc chấp nhận hay không là một câu hỏi hoàn toàn khác.
Tôi đoán chúng ta sẽ thấy.
@SignOfficial #SignDigitalSovereignInfra $SIGN
