Vấn đề phối hợp trong restakingSo với staking, restaking đã giới thiệu một bên thứ ba vào sự đồng thuận PoS — AVSes, tăng số lượng các tác nhân trong quy trình lên hơn hai. Và tất cả họ cần phải hoạt động trong sự hài hòa hoàn hảo với nhau để tối đa hóa lợi ích từ quy trình. Trong âm nhạc, ngay cả những dàn nhạc nhỏ cũng cần có nhạc trưởng để đồng bộ và tạo ra âm thanh tuyệt vời, và đối với restaking của CambrianOL, một trong những nhạc trưởng đó sẽ là. Hãy chỉ ra những vấn đề mà mỗi bên gặp phải trong restaking, và cố gắng tìm một cách giải quyết mô-đun thống nhất cho chúng.Huyền thoại restaking bởi @galaxyhq1⃣ Trước tiên, hãy xem xét các restaker. Họ muốn tối ưu hóa số tiền stake của mình theo một hoặc nhiều tham số, chẳng hạn như hồ sơ rủi ro hoặc lợi nhuận trên mỗi stake, hoặc họ muốn ủng hộ các nút cụ thể thực hiện một số nhiệm vụ nhất định. Tất cả những gì bạn có thể làm bây giờ là phân bổ stake của mình một cách thủ công hoặc sử dụng các kho lưu trữ được chọn lọc như những gì @mellowprotocol cung cấp. Dù cách nào đi nữa, những giải pháp này đều không rất linh hoạt và yêu cầu nhiều sự chú ý, từ người thu hồi chúng hoặc từ một người quản lý kho lưu trữ (hoặc cả hai, nếu bạn muốn chuyển kho lưu trữ). Một giải pháp rõ ràng khác là @symbioticfi, cũng hoạt động với các kho lưu trữ như một lớp phối hợp cho restaking. Hơn nữa, việc triển khai những giải pháp này trên Solana khác biệt rất nhiều so với các giải pháp dựa trên EVM.2⃣ Tiếp theo là AVSes. Những bên này có một số linh hoạt trong việc chọn các nút mà họ thực hiện nhiệm vụ, nhưng ngay cả những điều này cũng không rất linh hoạt. Và nếu không có đủ nút trong lớp restaking mà họ dự định chạy ban đầu? Nếu họ muốn thay đổi yêu cầu của mình một cách linh hoạt để phù hợp với khối lượng công việc hoặc các yếu tố khác? Một lần nữa, điều này không thể được thực hiện một cách hiệu quả vì đơn giản là không có công cụ để làm điều đó.3⃣ Cuối cùng nhưng không kém phần quan trọng — các nút công nhân. Điều này có vẻ đơn giản, nhưng thực sự không phải vậy. Hãy tưởng tượng bạn đã thiết lập nút của mình, chọn AVSes để chạy, đặt một stake cho chính mình hoặc thu hút stake từ một restaker khác, nhưng nút của bạn không bao giờ được chọn để thực hiện nhiệm vụ. Bạn không bao giờ biết tại sao, và điều đó thực sự gây thất vọng. Do đó, một số công cụ thống kê và mô phỏng chắc chắn sẽ rất hữu ích, cũng như một số công cụ mô phỏng khác.Hơn nữa, một giải pháp như vậy sẽ cho phép tương tác với các cấp độ khác nhau của restaking trên Solana như @Picasso_Network, @solayer_labs, @jito_labs và những người khác, cả về phía các restaker và phía các nhà điều hành.Chắc chắn rằng, một loại nhạc trưởng nào đó là cần thiết để làm cho dàn nhạc này chơi hòa quyện hoàn hảo.Rõ ràng, các giải pháp cho tất cả những vấn đề này phụ thuộc vào các tham số của các nút, điều này khiến một giải pháp giám sát tốt trở nên cần thiết. Chúng ta cần thu thập càng nhiều dữ liệu càng tốt để đưa ra quyết định tốt nhất về quỹ restaking hoặc phân công công việc cho một nút nhất định, cũng như xây dựng phân tích và mô phỏng cho việc chọn nút.Tiếp theo, có thể giả định rằng tất cả các giải pháp đều yêu cầu cùng một dữ liệu từ tất cả các nút. Dữ liệu này cũng có thể chứa một số giá trị tổng hợp, chẳng hạn như tổng số bet giữa một số nút nhất định, vị trí của nút hiện tại trong danh sách các nút có nhiều bet nhất, v.v. Chúng ta có thể coi chúng như là kết quả của một truy vấn SQL (xin lỗi về các vấn đề kỹ thuật, điều này sẽ xảy ra lại sau)Khi chúng ta có những kết quả truy vấn này cho tất cả các nút trong hệ thống tại một thời điểm nhất định, chúng ta cần tìm phân phối cần thiết của các triển khai và công việc trên các nút này. Nhật ký của phân phối này sau đó có thể được sử dụng như một công cụ phân tích cho các nút.Như chúng ta đã tìm hiểu, một nút công nhân có thể được mô tả đầy đủ bằng một tập hợp các giá trị mà chúng ta thu thập từ nó trong quá trình hoạt động của hệ thống. Khái niệm phối hợp là khá đơn giản: chúng ta giới thiệu một chức năng đặc biệt nhận tập hợp các tham số này và trả về tỷ lệ triển khai cho nút đã cho, hoặc 0/1, để xem liệu một công việc có nên được thực hiện trên một nút hay không. Hiện tại, bạn có thể coi chức năng này như một chương trình Solana.Nhưng làm sao chúng ta biết khi nào nên gọi chức năng này?Chúng tôi sẽ tính toán lại phân phối dựa trên các sự kiện kích hoạt. Những sự kiện này có thể là những thay đổi quan trọng trong các tham số của nút, thay đổi trong các công việc AVS, bộ đếm thời gian và các sự kiện người dùng chung. Tất cả các sự kiện kích hoạt này được đặt trong một hàng đợi bất đồng bộ, sau đó được xử lý bởi quản lý sự kiện, quản lý tốc độ và nhóm tất cả các sự kiện kích hoạt nhằm giảm thiểu khối lượng công việc và gửi tín hiệu đến việc điều phối AVS để thực hiện các tính toán cần thiết.Tiếp theo, AVS này thực hiện tất cả các công việc nặng nhọc cần thiết, được xác thực và các kết quả lại được đưa vào một hàng đợi bất đồng bộ khác để được xử lý bởi quản lý thay đổi. Chương trình này nhận kết quả từ các phép tính điều phối và chuyển đổi chúng thành các lệnh API thô để thay đổi trạng thái của các lớp restaking nhằm phù hợp với trạng thái yêu cầu.Đây là cái nhìn tổng quan về giải pháp điều phối. Và chủ đề này cần nghiên cứu sâu hơn và tìm kiếm câu trả lời cho các câu hỏi sau:🟨 Chức năng điều phối nên được thực hiện như thế nào. Chúng có phải là các chương trình Solana thực sự hay nên được viết bằng một loại DSL nào đó và chỉ được lưu trữ trên chuỗi?🟨 Những hàng đợi bất đồng bộ mà chúng tôi sử dụng cho các phép tính là gì? Có phải là chính blockchain, hay là một cái gì đó giống như Kafka hoặc Zmq?🟨 Chúng tôi lưu trữ thông tin telemetry của các nút ở đâu và như thế nào? Trên chuỗi hay ngoài chuỗi? Nếu ngoài chuỗi thì chúng tôi chứng minh tính hợp lệ và xác thực của nó như thế nào?📚 Đọc toàn bộ bài viết trên Substack của chúng tôi: https://t.co/r9M3xc8rCs
graphprotocol