Chữ ký BLS có mặt ở khắp nơi, từ sự đồng thuận của Ethereum đến EigenLayer. Nhưng thật dễ để sử dụng chúng sai cách. Chữ ký BLS là gì? Hãy cùng nói về cách sử dụng chúng đúng và sai:

Nhưng trước tiên, chữ ký BLS là gì? Chữ ký BLS là một nguyên lý mật mã được sử dụng để ký các thông điệp, giống như ECDSA. Dưới đây là cách mà toán học hoạt động. Nó được xây dựng dựa trên các cặp đường cong elliptic. Nhưng điều gì làm cho chúng trở nên đặc biệt? Tại sao lại sử dụng những cặp đường cong tinh vi này?

Tính năng nổi bật của BLS: tổng hợp chữ ký. Bạn có thể kết hợp nhiều chữ ký BLS thành một chữ ký duy nhất. Điều này cho phép bạn truyền tải và kiểm tra N chữ ký cùng một lúc, tiết kiệm không gian và thời gian hơn! Và trên chuỗi, các tối ưu hóa là cực kỳ quan trọng để tiết kiệm gas.

Để có cái nhìn sâu sắc về cách thức hoạt động của chữ ký BLS, cùng với quy trình xây dựng sự tổng hợp và chữ ký đa, hãy xem bài viết đầy đủ được liên kết ở cuối chủ đề này! Bây giờ, hãy xem cách chữ ký BLS có thể sai lầm, và cách EigenLayer sử dụng chúng (một cách đúng đắn, tránh những cạm bẫy này)!

EigenLayer là một lớp restaking cho Ethereum. Trong EigenLayer AVSes, các validator ký các kết quả của các phép tính xác thực của họ. Bộ tổng hợp thu thập tất cả các chữ ký này và đẩy chúng lên chuỗi. Các chữ ký đã được tổng hợp sẽ được xác minh trên chuỗi.

Nhiệm vụ chứa số khối khi nhiệm vụ được tạo và một ngưỡng chỉ ra tỷ lệ phần trăm xác thực của các nhà điều hành, điều này là cần thiết để xác thực nhiệm vụ. Các nhà điều hành đã chọn tham gia AVS có thể nhận những nhiệm vụ này để tính toán câu trả lời cho nhiệm vụ và sau đó nhà điều hành có thể gửi câu trả lời cùng với chữ ký BLS của nhiệm vụ đến người tổng hợp. Ngay khi ngưỡng của các câu trả lời giống nhau được đạt được, người tổng hợp sẽ hợp nhất tất cả các chữ ký BLS thành một chữ ký tổng hợp duy nhất và gửi lại cho hợp đồng AVS. Hợp đồng xác minh rằng chữ ký là chính xác và mở ra một khoảng thời gian thách thức khi một người thách thức có thể đưa ra bằng chứng rằng việc xác thực là không chính xác, và nếu vậy, các nhà điều hành vi phạm sẽ bị phạt.

Trong hợp đồng, việc xác minh diễn ra trong hàm `trySignatureAndApkVerification`:

Tuy nhiên, chữ ký đa chữ ký, nếu được sử dụng không đúng cách, sẽ gặp phải một vấn đề nghiêm trọng gọi là tấn công bằng khóa gian lận. Giả sử một người dùng trung thực có một khóa công khai, `pk_0`. Một kẻ tấn công đã từng thấy `pk_0` có thể chọn khóa công khai của mình là pk_1 = sk_1⋅G_1—pk_0. Kẻ tấn công sẽ không biết khóa riêng liên quan đến khóa công khai. Tuy nhiên, việc xác minh chữ ký đa chữ ký sẽ cho kết quả như sau:

Chỉ cần `sk_1` để ký một thông điệp dẫn đến một chữ ký đa chữ ký hợp lệ, mặc dù người dùng đầu tiên có thể không ký nó. Điều này dễ dàng được tổng quát hóa cho bất kỳ số lượng `r` người dùng trung thực nào bằng cách chọn khóa gian lận, là:

Đây là một mối đe dọa nguy hiểm vì, trong ví dụ AVS trước đó của chúng tôi, một trình tổng hợp độc hại đã từng đăng ký một khóa bất hợp pháp có thể gửi các chữ ký tổng hợp không được ký bởi các validator nhưng vẫn được hợp đồng chấp nhận. Điều này sẽ dẫn đến việc các validator bị phạt ngay cả khi họ không có hành vi sai trái.

Vì vậy, để ngăn chặn một cuộc tấn công bằng khóa giả, phương pháp phổ biến là yêu cầu người dùng chứng minh rằng họ biết khóa riêng tương ứng với khóa công khai của họ, được gọi là chứng minh quyền sở hữu. Do đó, trong bước đăng ký đầu tiên, người dùng được yêu cầu đăng ký khóa công khai của họ cùng với chứng minh quyền sở hữu π sao cho:

Cơ bản, người dùng được yêu cầu ký khóa công khai của họ hoặc bất kỳ thông điệp nhận dạng nào khác. Trong AVS, thông điệp là địa chỉ của nhà điều hành. Trong hợp đồng EigenLayer, chứng minh quyền sở hữu được xác minh bởi hàm `registerBLSPublicKey`:

Hàm `pubkeyRegistrationMessageHash` được sử dụng để băm bộ phân tách miền tùy chỉnh `PUBKEY_REGISTRATION_TYPEHASH` và địa chỉ của nhà điều hành.

Sau khi đăng ký, khóa công khai sẽ được thêm vào hợp đồng. Chúng ta có thể xác minh giá trị của nó bằng cách gọi hàm `getRegisteredPubkey`. Dưới đây là một ví dụ về khóa công khai BLS đã được đăng ký cho EigenDA AVS:

Chứng minh quyền sở hữu về cơ bản là một chữ ký BLS. Tuy nhiên, cũng không nên sử dụng chữ ký đa trong bước chứng minh quyền sở hữu, chẳng hạn như để đăng ký nhiều khóa công khai cho một người tham gia duy nhất. Nếu vậy, người tham gia sẽ đạt được một cuộc tấn công chia không. Trong trường hợp này, người tham gia có thể đăng ký các khóa mà khi cộng lại sẽ triệt tiêu lẫn nhau và có thể vượt qua chứng minh quyền sở hữu.

Chúng tôi đã thấy rằng chữ ký đa chữ ký BLS cung cấp một cơ hội tối ưu hóa đáng kể. Việc triển khai của EigenLayer chứng minh sức mạnh của chữ ký BLS và cũng làm nổi bật những phức tạp liên quan đến việc triển khai thực tế của chúng. Tuy nhiên, chữ ký đa chữ ký mang lại những rủi ro về bảo mật như các cuộc tấn công bằng khóa giả, điều này cần có các biện pháp bảo vệ như chứng minh quyền sở hữu. Nhưng với bản nâng cấp Pectra hỗ trợ BLS12-381, chúng ta có thể thấy thêm việc triển khai và cải tiến trong Solidity, và do đó chúng tôi hy vọng bài viết này sẽ giúp tránh những lỗi và lỗ hổng triển khai đã biết.

Để tìm hiểu sâu hơn về chữ ký BLS, xây dựng tổng hợp và chữ ký đa, hãy xem bài viết blog gần đây của chúng tôi bên dưới: