1- Tổng quan về Restaking
1.1- Restaking là gì ?
Restaking, hiểu đơn giản, là tái sử dụng phần stake (Re-stake) vào một giao thức nào đó. Do đó, công nghệ này chỉ khả dụng trên các dự án Proof of Stake (PoS).
Staking là hình thức để đảm bảo tính bảo mật (Security), đây là một “tài sản” quý giá của bất kỳ một blockchain nào. Restaking giúp chia sẻ “tài sản” này đến các blockchain, Dapps khác.
Restaking là gì ? Mô tả đơn giản quá trình Staking & Restaking
Hiện Restaking chưa có bất kỳ một mô hình mẫu hay một nghiên cứu khoa học nào làm nền tảng để phân tích. Chúng ta sẽ tạm thời sử dụng mô hình của dự án EigenLayer làm cơ sở để xem xét. EigenLayer là dự án khởi nguồn cho xu hướng Restaking nổi lên và hiện mảng này đã lọt vào TOP 5 mảng có TVL cao nhất trên thị trường DeFi theo thống kê của DeFiLlama.
1.2- Ý tưởng
EigenLayer được xây dựng để kết nối tính bảo mật (Security) của blockchain Ethereum đến các actively validated services (“AVS”) – theo cách gọi của EigenLayer. Bản chất các AVS ở đây có thể hiểu như một giao thức riêng biệt, nằm ngoài Ethereum.
Các AVS này có thể là một cơ chế đồng thuận mới, một oracles, bridges, data availability layer, EVM,…
Các AVS này cũng có cơ chế đồng thuận, có token riêng nhưng gặp vấn đề trong việc đảm bảo tính bảo mật.
1.3- Các vấn đề của AVS
- Khởi chạy hệ thống: các AVS cần một hệ thống nodes tối thiểu để vận hành hệ thống. Đây là vấn đề nan giải cho bất kỳ dự án nào muốn khởi chạy được blockchain của mình, vì để đạt được một số lượng tối thiểu operator trung thực và đảm bảo được tính decentralized của hệ thống yêu cầu rất nhiều nguồn lực và thời gian.
- Rò rỉ giá trị: khi người dùng sử dụng các AVS này họ sẽ trả phí cho các AVS thay vì hệ thống Ethereum. Đồng nghĩa, giá trị từ Ethereum bị rò rỉ sang các hệ thống khác.
- Chi phí vốn: người vận hành nodes cho các AVS sẽ cân nhắc chi phí và lợi ích với mô hình của AVS. Chi phí vốn này vượt xa các các chi phi vận hành hệ thống khác.
- Kém tin cậy hơn Layer 1: chi phí để tấn công một AVS sẽ ít hơn nhiều chi phí để tấn công một blockchain layer 1.
1.4- Ý tưởng của EigenLayer
- Pool security via restaking: EigenLayer sẽ cung cấp một cơ chế cho phép tạo ra security pool (pool bảo mật) dựa trên re-stake ETH của người dùng. Người dùng gán chứng nhận stake ETH của mình vào smart contracts của EigenLayer và lựa chọn mô-đun AVS muốn vận hành, nhận thưởng từ việc xác thực và chịu phạt khi vi phạm.
- Open marketplace: EigenLayer cung cấp một thị trường mở, có thể hiểu như sàn giao dịch, nơi các validator đã restake trên EigenLayer để tạo security pool ở trên, có thể lựa chọn AVS nào họ sẽ cung cấp security pool dựa trên việc so sánh tương quan giữa lợi ích và rủi ro slashing (phạt) của cơ chế.
EigenLayer kết hợp 2 ý tưởng này, tận dụng “tài sản” quý giá trên Ethereum là các validator, cung cấp tính bảo mật cho các AVS.
1.5- Các vấn đề của AVS sẽ được giải quyết
Khởi chạy hệ thống: các AVS có thể thừa hưởng “tài sản” bảo mật từ Ethereum khi xây dựng các mô-đun trên EigenLayer.
- Chi phí vốn: người dùng re-stake lại ETH nên chi phí vốn gần như = 0, nếu không bị slashing.
- Cộng hưởng niềm tin: niềm tin lúc này với hệ thống sẽ là cộng hưởng của cả 2 thực thể, Ethereum và các AVS. Nói một cách đơn giản, chi phí tấn công hệ thống lúc này bao gồm cả việc phải tấn công cùng lúc Ethereum và AVS.
- Tích luỹ giá trị: người tham gia restake sẽ nhận được nhiều lợi ích từ hệ sinh thái của EigenLayer.
2- Cơ chế hoạt động
2.1- Mô hình restaking trên EigenLayer
Ngắn gọn là người dùng có thể dùng ETH, Liquid staking token ( LST là token đại diện nhận được từ các giao thức Liquid Staking),Liquidity Provisioning (LP) token hoặc cặp LST-LP token để restake vào EigenLayer.
2.2- Mô hình uỷ thác (Delegation)
- Solo staking
- Solo stake như một AVS trên EigenLayer (setup full node)
- Uỷ thác vào một operator trên EigenLayer (chỉ cần setup 1 bản light node)
- Delegation: uỷ thác hoàn toàn vào 1 operator (must-trust)
2.3- Mô hình phí
Operator xác định cơ chế phí trong smart-contract với người uỷ thác. Người uỷ thác sẽ nhận được một tỷ lệ nhất định từ operator, được quy định rõ trong smart contract.
2.4- Quản lý rủi ro
Note: Chỉ xem xét rủi ro cục bộ trên nền tảng EigenLayer
Operator collusion (thông đồng giữa các người vận hành)
Xem xét tương quan giữa Cost of Corruption (CoC) và Profit from Corruption (PfC). Khi lợi nhuận của việc đánh sập hệ thống lớn hơn chi phí cho viêc này, hệ thống được xem là có rủi ro bị tấn công do sự thông đồng giữa các người vận hành.
Phương án của EigenLayer là sẽ có một dashboard (bảng điều khiển) tổng hợp thông tin về các operator đang vận hành, đưa ra các thông tin về có hay không nguy cơ tấn công vào hệ thống.
Unintended slashing (phạt ngoài dự tính)
Hình thức mà operator bị slashing mà không xuất phát từ chủ ý gây hại cho hệ thống, ví dụ như lỗi lập trình trên hệ thống. (có thể so sánh thêm về slashing của các dự án khác để thấy hướng đi của igenlayer là sự cải tiến hay bình thường)
EigenLayer đề xuất 2 luồng để bảo vệ các operator khỏi các trường hợp này
- Kiểm thử AVS: sẽ có các bước để kiểm tra code của các AVS nhằm bảo vệ người restake và người vận hành node.
- Phủ quyết slashing: EigenLayer sẽ có 1 layer cho việc quản trị, cộng đồng có thể bỏ phiếu để đưa ra quyết định slashing.
2.5- Quản trị (Governance)
EigenLayer xây dựng một Uỷ ban quản trị dựa trên những người có uy tín trong cộng đồng Ethereum và EigenLayer. Uỷ ban này chịu trách nhiệm cho các nâng cấp của EigenLayer smart contracts, xem xét và phủ quyết các sự kiện slashing, cũng như kiểm nghiệm các AVS mới mong muốn xây dựng trên EigenLayer.
2.6- Cơ chế đa token
Một AVS trên EigenLayer có thể phát hành token của riêng họ, cùng việc ra điều kiện về việc restake số ETH kèm một lượng token nhất định của AVS đó, cơ bản có thể hiểu là lượng ETH restake sẽ là back-asset cho token của AVS này.
3- Công nghệ cốt lõi
3.1- Thiết kế Mô-đun trên EigenLayer
Hai ràng buộc cần được quan tâm
- Liệu lợi nhuận kỳ vọng của AVS lớn hơn chi phí vận hành của operator?
- Operator có đủ nguồn lực tính toán (phần cứng) để đáp ứng việc xác thực các AVSs?
EigenLayer đề xuất 2 thành phần để giải quyết
- Hyperscale AVS: Mở rộng theo chiều ngang, tổng khối lượng tính toán sẽ được chia đều giữa các node vận hành, nhằm ngăn chặn khả năng hệ thống ngày càng tập trung hoá.
- Lightweight: sẽ có các lightweight AVS (AVS bản light node – node nhẹ) đảm nhận các tác vụ đơn giản như oracles, vận hành light node, xác thực zk proof.
3.2- Tiềm năng của EigenLayer
Thúc đẩy các ứng dụng mới qua việc sử dụng 2 nguồn lực Hyperscale AVS và Lightweight
- Hyperscale Data Availability Layer (Hyperscale AVS): sử dụng Hyperscale AVS xây dựng lớp dữ liệu khả dụng, bao gồm công nghệ Danksharding.
- Decentralized Sequencers (Lightweight / hyperscale AVS): xây dựng trình sắp xếp phi tập trung.
- Light-Node Bridges (Lightweight AVS): xây dựng một cầu nối nhẹ giữa EigenLayer và Ethereum.
- Fast-Mode Bridges for Rollups (Lightweight AVS): xây dựng cầu nối nhanh giữa EigenLayer và Ethereum để xác thực các rollups.
- Oracles (Lightweight AVS): sử dụng Lightweight AVS để xây dựng các Oracles.
- Opt-in Event-Driven Activation (Lightweight AVS): kích hoạt các hoạt động như chuyển các khoản thế chấp, hoặc thanh lý.
- Opt-In MEV Management: quản lý việc tham gia các máy ảo EVM.
- Settlement Chains with Ultra-Low Latency: xây dựng chuỗi ổn định với độ trễ siêu thấp.
- Single-Slot Finality (Lightweight AVS): hoàn tất khối từng slot, thay vì chờ một epoch (32 slot)
Hiện đã có hơn 50 dự án xây dựng AVS, operator (vận hành node), hoặc vận hành cùng lúc đa dịch vụ trên nền tảng EigenLayer.
Một số dự án nổi bật: Puffer Finance, KelpDAO, EigenDA, Mantle, AltLayer, Omni,…
4- Các khía cạnh cần nhìn nhận cẩn trọng
- Đây không phải công nghệ đột phá, mô hình chung để đưa ra ý tưởng đã có ở các dự án trước đây (IBC trên Cosmos, cấu trúc của Polkadot/Kusama, Superfluid staking của Osmosis). Mô hình của EigenLayer là tinh chỉnh lại cho phù hợp với cấu trúc sẵn có của Ethereum và xem Restaking là cơ chế vận hành chính.
- Mô hình restake chi tiết trên chính EigenLayer thì chưa có thông tin cụ thể vì dự án còn chưa hoàn tất mainnet (hiện đã hoàn thành 1 trên 3 giai đoạn của mainnet). Ngoài việc lợi ích về việc nhận phần thưởng của nhiều bên, cần tỉnh táo nhìn nhận là người dùng cũng sẽ cùng lúc phải cân nhắc rủi ro về giao thức hoạt động của từng đó bên. Việc sử dụng EigenLayer không xoá đi những rủi ro này.
Ví dụ: người dùng stake stake vào các pool lớn (Lido, Rocket,…) sẽ trực tiếp ảnh hưởng đến tính decentralized của Layer 1, dùng LSD token stake vào DeFi exchange sẽ có rủi ro (gần nhất là Curve bị tấn công), trước khi xét đến của rủi ro restake trên EigenLayer.
- Mô hình delegation theo whitepaper là người dùng phải must-trust vào operator, việc này đi ngược lại nên tảng căn bản của blockchain là permissionless. Phương án sử dụng một dashboard để kiểm soát rất mơ hồ. Bước cảnh báo và loại bỏ sẽ vận hành thế nào? Tập trung hay phi tập trung? Tốt hơn là một giao thức được xây dựng tự động hoá để loại bỏ operator không thành thật ra khỏi hệ thống.
- Cách thức slashing nếu xảy ra sẽ dần ăn mòn phần restake, kể cả phần token (EigenLayer, AVS) do giao thức trên EigenLayer quy định. Slashing là hình thức để che đậy cho sự yếu kém về mặt hạ tầng kỹ thuật ban đầu khi đã lock token thì token không thể thanh khoản và người restake buộc phải tin tưởng bên mà họ uỷ thác. Giao thức nên được xây dựng theo hướng hành xử đúng nhận được phần thưởng, không hành xử đúng không nhận được thưởng.
- Khía cạnh quản trị: ý tưởng về một Uỷ ban là cần thiết, tuy nhiên, Uỷ ban này nên được lựa chọn thông qua voting giữa operator (đảm bảo decentralized) hơn là dựa vào một yếu tố định tính (uy tín) của những operator, rủi ro về sự thông đồng, mua chuộc giữa các thành viên trong Uỷ ban là có thể xảy ra.
- Sử dụng stake ETH để restake sẽ là rủi ro cho token của EigenLayer (nếu có), tiếp theo là tokenomics của dự án. Động lực của người restake sẽ là sử dụng ETH hơn là token của EigenLayer, thật khó để xác định tác dụng của token EigenLayer trong hệ sinh thái.
- Rủi ro về smart contracts (audit)
- Rủi ro với lượng ETH restake
- Phương án chặn việc unstake ETH khi đã restake vào EigenLayer.
- Cách quản lý lượng restake an toàn.
- Mô hình đa token tiềm ẩn rủi ro: khi giá token của một AVS biến động, đồng nghĩa chi phí bỏ ra để sử dụng các AVS này cũng tăng-giảm theo đó (chi phí sử dụng có thật sự bị ảnh hưởng bởi giá?, bên cạnh đó việc token lên xuống là không thể tránh khỏi). Với bất kỳ một người sử dụng dịch vụ nào, nhu cầu về biết trước về phí, nói cách khác, cần chi phí ổn định là tất yếu và cần được đáp ứng. Bên cạnh ảnh hưởng trực tiếp đến operator.
Có thể bạn quan tâm: