Giải thích chi tiết về những điểm tương đồng và khác biệt của kế hoạch đặt cược thanh khoản Ethereum 2.0

Lưu ý của biên tập viên: Bài viết này đến từChặn nhịp BlockBeats (ID: BlockBeats), được in lại bởi Odaily với sự cho phép.

Lưu ý của biên tập viên: Bài viết này đến từ

Chặn nhịp BlockBeats (ID: BlockBeats)

Chặn nhịp BlockBeats (ID: BlockBeats)

, được in lại bởi Odaily với sự cho phép.

Kể từ khi ra mắt chuỗi báo hiệu Ethereum 2.0 chỉ trong hơn một tháng, số dư của địa chỉ thế chấp Ethereum 2.0 đã vượt quá 2,4 triệu Ethereum. Đồng thời, một số lượng lớn nền tảng đặt cược của bên thứ ba đã được ra mắt, bao gồm nền tảng giao dịch tập trung Binance và các dự án DeFi phi tập trung như Rocket Pool và Lido.

Bất chấp sự khác biệt của chúng, chúng có một điểm chung: tất cả các dự án đều đưa ra giải pháp cho những xung đột không thể tránh khỏi mà việc đặt cược Ethereum tạo ra. Vì vậy, những ma sát này chính xác là gì?

Đầu tiên, sự phức tạp về mặt kỹ thuật của việc đặt cược Ethereum 2.0 nằm ngoài tầm với của người dùng thông thường. Với giá Ethereum tăng nhanh ($1040 tại thời điểm biên soạn bài viết này), yêu cầu tiền gửi tối thiểu là 32 ETH ngày càng trở nên ngoài tầm với của người dùng trung bình. Cuối cùng, để cho phép chuyển đổi sang Ethereum 2.0 một cách an toàn và được kiểm soát, việc đặt cược có thời gian khóa thanh khoản kém từ 18-24 tháng.

Kết hợp lại với nhau, những hạn chế này có thể ngăn những người dùng kém tinh vi hơn tham gia vào thị trường đặt cược Ethereum 2.0 “béo bở”.

Làm thế nào để staking pool giải quyết vấn đề này?

Đây là nơi các nhóm đặt cược Ethereum 2.0 xuất hiện. Họ mua Ethereum từ nhiều người dùng và thay mặt người dùng đặt cược Ethereum 2.0, cho phép bất kỳ người tham gia nào kiếm được phần thưởng đặt cược bất kể trình độ kỹ năng hoặc quy mô tiền gửi của họ.

Ngoài ra, họ đã cố gắng giảm bớt các yêu cầu thanh khoản kéo dài bằng cách phát hành mã thông báo mạng chính Ethereum đại diện cho tiền gửi và phần thưởng mà người dùng kiếm được trên chuỗi Ethereum 2.0. Các mã thông báo được cam kết này cung cấp cho chủ sở hữu cơ hội mở khóa tính thanh khoản, cho phép người dùng giao dịch mã thông báo được cam kết Ethereum 2.0 lấy mã thông báo gốc Ethereum trên các thị trường thứ cấp như Uniswap để thoát khỏi cam kết sớm, cũng như sử dụng mã thông báo đã cam kết của họ Khả năng tham gia vào DeFi (ví dụ: làm tài sản thế chấp tại Aave).

Nói tóm lại, có nhiều sự khác biệt trong cơ chế mã thông báo từ các nhóm đặt cược khác nhau có thể dẫn đến nhầm lẫn với những hậu quả không mong muốn cho người dùng cuối. Tuy nhiên, những khác biệt này có thể được phân loại và đánh giá để khám phá điểm mạnh và điểm yếu của các nhóm đặt cược tương ứng. Hơn nữa, phân tích so sánh này có thể chứng minh hiệu quả về giá của các mã thông báo đặt cược Ethereum 2.0 khác nhau.

Thiết kế mã thông báo đơn

Trong bài viết này, tôi sẽ làm sáng tỏ các nguyên tắc của mã thông báo Ethereum 2.0 và đưa ra các ví dụ về cách hoạt động của mã thông báo của các nhóm cam kết khác nhau.

Mô hình mã thông báo đặt cược

Theo phân loại cấu trúc mã thông báo, có thể phân biệt hai cấu trúc khác nhau: một là thiết kế mã thông báo duy nhất, nhằm mục đích nhận được khoản tiền gửi ban đầu và thu nhập được gửi vào một mã thông báo cùng một lúc; cấu trúc còn lại là thiết kế mã thông báo kép, kết hợp tiền gửi cam kết và Phần thưởng được trao riêng dưới dạng hai mã thông báo khác nhau.

Thiết kế mã thông báo đơn

Cấu trúc mã thông báo duy nhất dựa trên khái niệm tái cân bằng hoặc định giá lại mã thông báo. Đây là thiết kế phổ biến nhất và hầu hết các nhóm đặt cược đều sử dụng chiến lược này, có lẽ vì tính đơn giản của nó. Bằng cách phát hành một mã thông báo duy nhất khi người dùng gửi tiền, nhóm đặt cược tìm cách thực hiện trách nhiệm giải trình phần thưởng và hình phạt trong cùng một mã thông báo. Điều này có thể đạt được theo hai cách:

1. Thay đổi số lượng: Phần thưởng và hình phạt trong hợp đồng cam kết Ethereum 2.0 được phản ánh bằng cách thay đổi số dư mã thông báo. Trong giai đoạn lưu thông mã thông báo 1.5, mỗi mã thông báo được cam kết sẽ nằm trong nhóm theo tỷ lệ 1:1 Chuyển đổi thành ETH;

2. Thay đổi giá: Phần thưởng và hình phạt trong hợp đồng cam kết Ethereum 2.0 được phản ánh trong giá của mã thông báo. Trong giai đoạn lưu thông mã thông báo 1.5, số tiền mua lại của mỗi mã thông báo cam kết được thưởng bởi nhóm cam kết dao động.

Hiểu với một sơ đồ đơn giản:

1. Cách đổi số lượng token, dự án tiêu biểu là: Lido và Binance.

2. Thay đổi cách thể hiện giá, Rocket Pool, Cream, StaFi và Stkr.

Trong khi sử dụng các cơ chế khác nhau để phản ánh việc tích lũy phần thưởng, các thiết kế mã thông báo đơn lẻ có một điểm chung: gộp các khoản tiền gửi và phần thưởng trong cùng một mã thông báo. Điều này có nghĩa là bất cứ khi nào bạn mua hoặc bán mã thông báo trên thị trường hoặc nhận mã thông báo từ người gửi tiền, bạn sẽ nhận/bán cả tiền gửi và bất kỳ phần thưởng nào đã được tích lũy vào nhóm trong quá khứ.

Thiết kế mã thông báo kép

Thay vào đó, cấu trúc mã thông báo kép dựa trên khái niệm về hai mã thông báo tái cân bằng tương ứng phản ánh tiền gửi và phần thưởng.

Ngược lại, cấu trúc mã thông báo kép dựa trên khái niệm về hai mã thông báo tái cân bằng phản ánh tiền gửi và phần thưởng tương ứng. Lấy mã thông báo stakewise làm ví dụ, mã thông báo gửi và trả lại lần lượt là stETH và reETH.

Khi nắm giữ các mã thông báo được cam kết với thiết kế mã thông báo kép, mã thông báo stETH đại diện cho Ethereum đã cam kết sẽ không tăng trưởng, trong khi mã thông báo rwETH (ETH được thưởng) tích lũy phần thưởng theo tỷ lệ 1:1 sẽ phản ánh phần doanh thu trong nhóm cam kết. tăng. Cùng với nhau, tổng của các mã thông báo này tạo thành trạng thái lợi nhuận tổng thể và có thể được chuyển tự do giữa mạng Ethereum và được sử dụng trong các hợp đồng thông minh theo cách tương tự như các mã thông báo riêng lẻ.

Nó tích lũy mã thông báo phần thưởng miễn là mã thông báo đã đặt cọc được giữ. Khi nhóm phần thưởng tăng lên, số dư của mã thông báo Ethereum stETH đại diện cho khoản tiền gửi vẫn giữ nguyên, nhưng các địa chỉ nắm giữ được thưởng bằng mã thông báo phần thưởng reETH.

Tổng số mã thông báo Ethereum được gửi và thưởng luôn bằng với số lượng Ethereum trong nhóm; tỷ giá hối đoái của hai mã thông báo vẫn ở mức 1

Cấu trúc mã thông báo kép cho phép tạo ra một mô hình kết hợp mới năng động tương tự như trái phiếu, nhưng khác ở chỗ nó chia khoản cam kết thành hai đợt với các giá trị tích lũy và kỳ vọng dòng tiền khác nhau (tiền gốc và tiền lãi), cho phép quản lý đặt cược cá nhân nhiều hơn một cách hiệu quả và linh hoạt.

Chi tiết về mã thông báo đã đặt cược

Khi nói đến cốt lõi của cách hoạt động của mã thông báo đặt cược Ethereum 2.0, các lựa chọn thiết kế của các nhóm khác nhau trở nên tinh tế hơn, nhưng vẫn có thể tạo ra sự khác biệt đáng kể.

Nhà tiên tri ngoài chuỗi

Để trở thành một giải pháp hiệu quả cho thanh khoản trì trệ, mã thông báo phải phản ánh chính xác giá trị của các mã thông báo đặt cược được giữ. Điều này yêu cầu đặt đúng số lượng Ethereum vào nhóm đặt cược để hỗ trợ các mã thông báo được cam kết tương ứng. Để làm điều này, các nhóm đặt cược cần theo dõi số dư nút của họ trong Chuỗi Beacon và phát hành mã thông báo cho họ.

Nhưng điều bạn cần biết là hợp đồng chịu trách nhiệm phát hành mã thông báo và số dư của nút xác minh không nằm trên cùng một chuỗi khối (Ethereum 1.0 VS Ethereum 2.0).

Thật không may, hợp đồng ERC-20 chịu trách nhiệm phát hành mã thông báo không nằm trên cùng một chuỗi với số dư của nút (ETH1 so với ETH2). Hợp đồng mã thông báo trên chuỗi Ethereum 1.0 không thể đồng bộ hóa trực tiếp số dư từ trình xác thực chuỗi đèn hiệu. Các nhóm đặt cược cần phải khắc phục hạn chế này bằng cách sử dụng các oracle ngoài chuỗi, hoạt động theo nguyên tắc tương tự như Chainlink phổ biến hiện nay.

Các nhà tiên tri ngoài chuỗi có thể lấy dữ liệu chuỗi đèn hiệu theo các cách sau: Đầu tiên, một nút tính toán tiên tri phải chạy cả hai nút Ethereum 1.0 và Ethereum 2.0 để tương tác với cả hai chuỗi cùng một lúc. Khi cả hai nút đều hoạt động, nhà tiên tri sẽ thu thập thông tin từ chuỗi đèn hiệu về các trình xác thực thuộc về một nhóm đặt cược cụ thể và chuyển thông tin đó sang hợp đồng thông minh ERC-20 trên chuỗi Ethereum 1.0. Sau khi thông tin của chuỗi đèn hiệu được gửi tới hợp đồng ERC-20, số lượng mã thông báo sẽ được cập nhật (hoặc tỷ giá hối đoái sẽ được thay đổi để phát hành mã thông báo mới) theo sự thay đổi của số dư trình xác thực. Thay đổi này có thể tăng hoặc giảm, tùy thuộc vào việc số dư tăng (tức là kiếm được phần thưởng) hay giảm (tức là phải chịu phạt/).

Thật không may, các nhà tiên tri ngoài chuỗi đưa ra một nhược điểm: thực thể kiểm soát nhà tiên tri kiểm soát hiệu quả việc đổi mới mã thông báo. Để giảm bớt vấn đề này, nhóm đặt cược yêu cầu nhiều nhà tiên tri gửi cùng một thông tin cùng một lúc, để cập nhật thông tin mã thông báo thông qua cơ chế đồng thuận và phân bổ các nhà tiên tri để đạt được một mức độ phân cấp nhất định.

Tốc độ làm mới số dư mã thông báo đã cam kết

Tuy nhiên, trong những trường hợp chém hàng loạt, cập nhật hàng ngày có thể là không đủ. "Chém" xảy ra bất cứ khi nào người xác thực mắc lỗi gây ra sự chặt chém, dẫn đến việc người xác nhận mất tiền trong vòng vài phút. Nếu số dư được cập nhật ít thường xuyên hơn 24 giờ, thì đó sẽ là một thảm họa.

tóm tắt

Vấn đề ở đây là bất kỳ người dùng nào cũng có thể theo dõi theo các kỷ nguyên (thông qua trình khám phá chuỗi beacon) lượng Ether trong trình xác thực giám sát nhóm đặt cược và "biết" rằng số dư của họ sẽ giảm trước khi mã thông báo cập nhật số dư. Khi người dùng nhận ra tổn thất tiềm ẩn sắp xảy ra, họ sẽ thực hiện trước hợp đồng thông minh ERC-20, bán mã thông báo trên thị trường thứ cấp để giảm tổn thất và khiến nhà cung cấp thanh khoản không nghi ngờ bị lỗ vĩnh viễn và bị phạt một khoản tiền lớn. số lượng vị trí được tổ chức trong nhóm cam kết.

Để tránh tình trạng này, nhóm cam kết có thể điều chỉnh tần suất làm mới hợp đồng ERC-20 của mình thành tần suất cao hơn, tăng chi phí phí ​​Gas để ngăn ngừa rủi ro số dư không khớp trong quá trình cắt giảm. Tuy nhiên, trên thực tế, không có khả năng nhóm đặt cược sẽ cập nhật số dư mã thông báo thường xuyên hơn (chứ đừng nói đến mỗi kỷ nguyên). Thay vào đó, họ muốn giảm rủi ro bị chặt chém bằng cách cải thiện các quy trình bảo mật hoặc chỉ sẵn sàng tăng tần suất cập nhật nếu xảy ra sự kiện chặt chém.