Mô hình EIGEN token - Nhiên liệu cho hệ thống kiểm duyệt onchain

Tổng quan về Eigen Layer và EIGEN token

EigenLayer cho phép các dự án có thể tận dụng lại số lượng ETH đã được stake (Restaking) trong việc tham gia bảo mật trên chính protocol của mình. Trong hệ thống của EigenLayer bao gồm 3 vai trò chính:

• Restaker: các cá nhân có ETH hay staked ETH muốn tham gia đóng góp vào nền kinh tế bảo mật của Eigen Layer. Ngược lại, họ sẽ nhận được yield cho việc trên.
• AVS (Actively Validated Services): Các protocol hay Dapp muốn nhận sự bảo mật từ số lượng restaked ETH trên EigenLayer. Các AVS sẽ trả một khoản phí được xem là yield cho các restaker.
• Operator: các cá nhân vận hành trong hệ thống của EigenLayer. Họ sẽ được restaker uỷ quyền (delegate) số lượng ETH/staked ETH nhằm phân phối cho các AVS có nhu cầu. Operator cũng sẽ nhận một khoản phí trung gian cho công việc trên.

Có thể thấy token ETH được EigenLayer tái sử dụng trong việc bảo mật các AVS. Tuy nhiên, giới hạn của ETH chỉ cung cấp bảo mật trên môi trường máy ảo Ethereum (EVM) trong bối cảnh có các AVS được phát triển bên ngoài không gian blockchain (chi tiết ở bên dưới). Vì vậy, token EIGEN ra mắt giúp bổ trợ những thiếu sót mà token ETH không thể làm được.

Vào ngày 29/04 vừa qua, EigenLayer chính thức ra mắt EIGEN token với tổng cung 1.67 tỷ token với tên gọi The Universal Intersubjective Work Token. Tỉ lệ phân bổ EIGEN token như sau:

Hãy cùng Coin98 Insights tìm hiểu ý nghĩa đằng sau cái tên này ở phần bên dưới.

Vai trò của EIGEN token trong mô hình EigenLayer

Giải quyết tranh chấp bên ngoài môi trường máy ảo blockchain

Trước tiên, hãy cùng tìm hiểu hai loại tranh chấp chính xảy ra trên không gian Internet, cụ thể là bên trên không gian blockchain.

• Objective Faults: bao gồm các lỗi diễn ra trên không gian Internet có thể dễ dàng quy kết thông qua những chứng cứ rõ ràng dựa trên logic về mặt toán học hay mật mã học (cryptography).

Trong môi trường blockchain hay VM, các lỗi này có thể giải quyết dựa trên smart contract. Một số objective faults phổ biến như double-signing hay thực thi sai một txs (invalid execution). Đối với Ethereum, cơ chế đồng thuận PoS sẽ đứng giải quyết các tranh chấp Objective Faults thông việc slashing số lượng staked ETH của các validator.

• Intersubjective Faults: bao gồm các lỗi quan sát được nhưng không thể quy kết thông qua smart contract do xảy ra bên ngoài môi trường VM. Ví dụ như sai lệch giá oracle, tính toàn vẹn của dữ liệu ở lớp DA, sai lệch lớn trong inference của các decentralized AI model,...

Hiện tại, các objective faults có thể được xử lý thông qua vai trò của token ETH. Cụ thể, cơ chế PoS cho phép ETH đóng vai cung cấp bảo mật thông qua cơ chế staking và slashing trong hệ sinh thái (specific task).

Mô hình Restaking của EigenLayer cho phép token này được ứng dụng rộng rãi cho việc cung cấp bảo mật cho AVS (Universal Task). Vì vậy, ta có thể gọi restaked ETH trên Eigen là Universal Objective Work Token, trong đó work token ám chỉ token có utility.

Tìm hiểu thêm: Cơ chế slashing trong Crypto.

Tuy nhiên, không phải tất cả các AVS đều được xây dựng trên môi trường VM với các tranh chấp có thể dễ dàng giải quyết thông qua smart contract (Objective Faults). Lấy ví dụ như các Oracle, DA protcol hay decentralized AI như ở trên cần phải giải quyết các tranh chấp bên ngoài môi trường blockchain (Intersubjective Faults). Lúc này, token EIGEN sẽ đóng vai trò tương đương ETH trong việc giải quyết các tranh chấp trên. Vì vậy, EIGEN có tên gọi là Universal Intersubjective Work token.

Theo EigenLayers, thông thường các tranh chấp liên quan tới Intersubjective Faults sẽ được xử lý thông qua hai cơ chế chính:

• Penalize (Slash): cắt đi một số lượng staked fund của các node nhỏ với kết quả khác với số đông.
• Cơ chế hội đồng (Committee Mechanism): Tạo ra một nhóm hội đồng quyết định tính đúng sai của vấn đề.

Tuy nhiên câu hỏi đặt ra là làm sao đảm bảo được số đông luôn làm đúng? Làm sao để ngăn cản các cá nhân, hội đồng này hợp tác và gian lận (tyranny of majority)?

Câu hỏi trả lời là dựa trên social consensus.

Giảm tải cho Ethereum Social Consensus

Trong bối cảnh của Ethereum, khi lớp economic security (51% attack) của chain bị phá vỡ, lớp bảo vệ thứ hai bao gồm sự đồng thuận của các cá nhân nhỏ lẻ, bao gồm developer, project builder và user sẽ quyết định tính đúng sai của một block tiếp theo. Sự đồng thuận được gọi là social consensus.

Trường hợp xấu nhất, Ethereum sẽ folk ra một chain riêng (canonical chain) cho community của mình và một chain riêng của nhóm tấn công. Trong quá khứ, Ethereum đã từng split ra hai chain bao gồm Ethereum hiện tại (ETH) và Ethereum Classic (ETC).

Có thể thấy, social consensus với việc folking chain là một những cách giải quyết những tranh chấp liên quan tới Intersubjective Faults. Tuy nhiên, không thể sử dụng mô hình áp dụng vào các tranh chấp trên EigenLayer do nó làm trầm trọng hay quá tải lớp consensus của Ethereum. Vì vậy, thay vì folking chain, EIGEN quyết định sử dụng mô hình folking token với EigenLayer Consensus.

Đọc thêm: Vitalik đã từng cảnh bảo không được lạm dụng social consensus của Ethereum.

Mô hình hoạt động của EIGEN token

Tiền đề cho mô hình Folk Token

Mô hình Folk Token đã được giới thiệu và áp dụng bởi Augur Protocol với token REP - một prediction market ra đời vào 2019. Cụ thể, khi có tranh chấp (Intersubjective Fault) trong kết quả của một event (vd: VN 2 - 1 Thailand nhưng protocol ghi nhận 2-2), người bị thiệt sẽ stake token REP để tái hiện lại kết quả của trận đầu trên protocol. Quá trình này gọi là Folking Event.

Khi đó, token REP sẽ được tách làm 2 token đại diện cho hai kết quả:

• REP 1: (VN 2 - 1 TL)
• REP 2: (VN 2 - 2 TL)

Các REP holder, các cá nhân bên ngoài protocol đều có thể tham gia lựa chọn đâu là kết quả đúng với sự kiện ngoài đời (Augur Social Consensus) thông việc chọn token REP1 hay REP2. Nếu đa số chọn REP 1, giá trị của token REP ban đầu sẽ chuyển sang REP1 và giá trị của REP2 sẽ về 0.

Mô hình trên của Augur là một những tiền đề giúp một protocol bên trong blockchain tham gia giải quyết các tranh chấp bên ngoài thế giới thực. Tuy nhiên, cách thiết kế của Augur vẫn còn một số hạn chế như:

• Chỉ áp dụng cho prediction market (Specific Task).
• Tất cả REP token holder phải chuyển đổi sang REP1 sau quá trình folking event, kể cả khi họ tham gia vào việc giải quyết tranh chấp.

Những hạn chế này đã tạo tiền đề cho việc thiết kế token EIGEN hiện tại với 4 đặc điểm chính:

• Universality: Sử dụng cho nhiều mục đích, cụ thể là trên các AVS khác nhau (Universal Task).

• Isolation: Thiết kế tách bạch giữa token tham gia tranh chấp (bEIGEN) và token thông thường (EIGEN). Chi tiết ở phần Dual Token bên dưới.

• Metering: Tính toán được lợi ích và chi phí khi giải quyết được các Intersubjective Faults. Khi một cá nhân độc hại (malicious actor) bị phát hiện sẽ đốt toàn bộ lượng stake EIGEN ra khỏi nguồn cung giúp tăng giá trị cho token EIGEN.
• Compensation: Đảm bảo quyền lợi cho user bị thiệt hại từ các intersubjective faults thay vì chỉ xử phạt các cá nhân sai phạm.

Dual Token Design

Nhằm đảm bảo cho hệ thống hoạt động bị không chồng chéo lên nhau cũng tách biệt các nhiệm vụ (Isolation), mô hình Dual Token được Eigen giới thiệu với:

• Token EIGEN: Sử dụng cho các ứng dụng DeFi hay mục đích giao dịch.
• Token bEIGEN: Folk Token giải quyết các tranh chấp liên quan tới Intersubjective Faults.

Người dùng muốn tham gia đóng góp vào bảo mật cho các AVS có các tranh chấp liên quan tới Intersubjective Faults sẽ stake token EIGEN để biến thành bEIGEN.

Chi tiết cách hoạt động của bEIGEN

Các AVS muốn sử dụng bEIGEN cần phải thông qua hai giai đoạn:

Giai đoạn chuẩn bị (Setup phase): AVS cần chỉ ra các điều kiện cho việc folk token. Một số metric cần chú ý như:

• Deflation-per-fork (DPF): số lượng token EIGEN bị burnt khi tham gia vào xử lý tranh chấp. Đây là cái giá cho các cá nhân/ node sai phạm.
• Commitment-per-folk (CPF): số lượng token EIGEN bị burnt trong trường hợp không chứng minh được lỗi sai. Lúc này token vẫn sẽ như cũ (không bị folk). Chi phí này (CPF) thường cho các challenger (người raise yêu cầu folk token) nhằm tránh trường hợp liên tục tạo challenge.

Sau khi chuẩn xong điều kiện và các thông số, EigenLayer sẽ tiến hành folk token. Ví dụ token bEIGEN1 sẽ đại diện cho token trước khi folk và bEIGEN2 sẽ đại diện sau khi folk. Sau quá trình xem xét nếu có sai phạm thật sự, toàn bộ token bEIGEN1 sẽ chuẩn sang bEIGEN2. Chi tiết với hai trường hợp:

a) Có sai phạm. bEIGEN2 đại diện cho token sau khi bị folk (nếu có sai phạm xảy ra và được xử lý). Lúc này, người sai phạm sẽ bị đốt số lượng token bEIGEN2 với giá trị bằng DPF cho việc đền bù sai phạm.

b) Không sai phạm. bEIGEN1 đại diện cho token ban đầu (không folk). Người raise challenge sẽ bị đốt số lượng bEIGEN1 bằng giá trị CPF do nghi ngờ sai và đền bù cho toàn bộ mạng lưới do tổn thất do

Giai đoạn thực thi (Execution phrase): Giả sử khi có nghi ngờ có sai phạm xảy ra, protocol sẽ tiếp tục quá tình tìm hiểu và thực thi các biện pháp xử phạt.

Trước tiên, challenger phải đặt cọc một lượng token EIGEN (CPF) trong trường hợp không có sai phạm.

Sau đó, challenger sẽ có nhiệm vụ tạo ra:

• Một token EIGEN mới (vd: bEIGEN2).
• Một challenge contract mới cho token bEIGEN2 - sử dụng cho folking trong tương lai khi có những sai phạm tiếp theo
• Một smart contract gọi là folk distributor (FD) bao gồm: địa chỉ ví của sai phạm, contract token cũ (bEIGEN1) và phần thưởng cho challenger là bao nhiêu.

Sau khi challenge thành công, EIGEN holder sẽ đợi một khoản thời gian để đổi sang token mới (vd: EIGEN-> EIGEN2), các bên tham gia challenge (staker và challenger) cũng sẽ unstake từ bEIGEN2 -> EIGEN2. Riêng sai phạm sẽ bị slash số lượng bEIGEN2 bằng cách không thể convert về EIGEN2.

Hiện tại, EigenLayer vẫn đang thử nghiệm với token EIGEN với phiên bản V1 với các thông số như CPF, DPF, thời gian burn, redeem vẫn đang được tính toán. Dưới đây là chi tiết về mô hình V1 và V2 của EigenLayer với việc áp dụng token EIGEN vào quá trình xử lý Intersubjective Faults.

Tạm Kết

Sự ra đời token EIGEN với thiết kế Dual Token đang đem tới một làn gió mới cho thị trường trong bối cảnh các thiết kế token trước đây đang chững lại. Token Folk với bEIGEN sẽ giải quyết những hạn chế trong không gian blockchain, từ đó mở ra những sáng tạo mới trong kiến trúc của các protocol/ AVS.

Đọc thêm: Toàn cảnh về hệ sinh thái EigenLayer.