eODS (Phân tách người ủy quyền điều hành được ghi nhận): đề xuất mô hình ủy quyền

Xin chân thành cảm ơn Barnabé Monnot, Vlladin, Michail Kalinin, Alex Stokes và Potuz đã hỗ trợ hiệu quả
Các cuộc thảo luận trong năm qua (đây không phải là sự chứng thực). Mặc dù các ý kiến và quan điểm được trình bày trong bài viết sau đây bắt nguồn từ lộ trình và diễn ngôn R&D của giao thức trong 18 tháng qua, nhưng chúng không nhất thiết đại diện cho quan điểm của những người đánh giá và những người phụ trách giao thức đã đóng góp ý kiến cho dự án này. Trong phần tiếp theo, tôi đề xuất một mô hình ủy quyền cho các khuôn khổ staking rộng hơn như Rainbowstaking , phác thảo logic, cấu trúc và lộ trình triển khai của nó. Bài viết này được đính kèm với Pyspec của tính năng này, trong khi Pytest và POC sau này sẽ thúc đẩy mô hình này đến giai đoạn hoàn thiện.

0. Tóm tắt

Ủy quyền—quá trình giao quyền đặt cược hoặc quyền quản trị cho bên thứ ba—là
là nền tảng cơ bản trong nhiều hệ sinh thái blockchain. Tuy nhiên, Ethereum thiếu hỗ trợ ủy quyền nội bộ ở cấp độ giao thức, thay vào đó dựa vào các dịch vụ đặt cược dựa trên hợp đồng. Mặc dù các dịch vụ này đã hiệu quả trong việc thu hút vốn, nhưng chúng lại tiềm ẩn rủi ro tập trung hóa và thách thức quản trị, làm suy yếu đáng kể tính trung lập đáng tin cậy của giao thức.

1. Tình trạng hiện tại của phái đoàn

Trong Ethereum, việc ủy quyền chủ yếu là không chính thức và ngoài chuỗi. Trình xác thực trừu tượng của dịch vụ đặt cược
trách nhiệm, cung cấp token đặt cược thanh khoản (LST) cho người dùng. Điều này dẫn đến sự phân chia tự nhiên
đặt cược vào hai lớp người tham gia, bên ngoài cấp độ giao thức :

• Người vận hành nút : Quản lý các trình xác thực thực thi giao thức và đảm bảo an ninh mạng
• Người ủy quyền : Cung cấp vốn nhưng có ảnh hưởng hạn chế đến việc lựa chọn hoặc quản lý người xác thực

Ngược lại, các hệ sinh thái khác như Cosmos, Solana và Tezos kết hợp việc ủy quyền trực tiếp vào
giao thức, cho phép người ủy quyền đặt cược với người xác thực và tham gia vào quản trị, bao gồm
chia sẻ rủi ro cắt giảm (trong Cosmos và Solana).

2. Các thành phần hiệu quả trong các mô hình hiện có

Đây là những yếu tố từ Ethereum và các hệ sinh thái PoS khác đã chứng minh được tiện ích có thể đo lường được hoặc kết quả phù hợp với giao thức. Thành công của chúng có thể là nhờ những cải thiện rõ rệt về khả năng sử dụng, hiệu quả vốn hoặc sự phù hợp với thiết kế giao thức.

• Trừu tượng hóa việc đặt cược : trừu tượng hóa các cơ chế đặt cược thông qua phần mềm trung gian — phổ biến nhất
  giao thức đặt cược thanh khoản (LSP) — đã giảm đáng kể rào cản tham gia.
• Khả năng kết hợp LST : các mã thông báo đặt cược thanh khoản (LST) như stETH hoặc rETH là ERC-20
  biểu diễn của ETH được đặt cược có thể được sử dụng làm tài sản thế chấp hoặc thanh khoản trong các hệ thống DeFi trong khi vẫn tích lũy phần thưởng đặt cược.
• Hợp nhất trình xác thực (EIP-7251) : Bản nâng cấp Pectra của Ethereum đã giới thiệu EIP-7251,
  cho phép người xác thực giữ số dư lên tới 2048 ETH — vượt xa mức tối đa 32 ETH trước đây.
• Trách nhiệm giải trình ở cấp độ giao thức : Các chuỗi như Cosmos và Tezos triển khai ủy quyền và theo dõi phần thưởng trong giao thức. Các mối quan hệ ủy quyền được hiển thị trực tiếp với giao thức đồng thuận, cho phép lựa chọn người xác thực, theo dõi hiệu suất và cắt giảm được thực thi trực tiếp tại lớp cơ sở. Cấu trúc này dường như đã chứng minh được hiệu quả trong việc điều chỉnh các ưu đãi cho người ủy quyền và duy trì tính phi tập trung thông qua việc phân phối cổ phần minh bạch.

3. Xác định những thách thức trong các mô hình hiện có

Đây là một số hạn chế về kiến trúc và kinh tế trong việc ủy quyền Ethereum hiện tại
thực tiễn, xuất hiện trực tiếp từ hiệu suất của các mô hình phái đoàn ngày nay và tác động của chúng đối với
sự phân cấp của mạng lưới và động lực xác thực:

• Tập trung hóa việc ủy quyền : cổ phần được ủy quyền tập trung cao độ vào một số ít cổ phần thanh khoản
  giao thức. Sự tập trung này hạn chế tính đa dạng ở cấp độ giao thức và quyền tự chủ của bộ xác thực và
  tạo ra một cấu trúc độc quyền làm suy yếu mục tiêu phi tập trung của Ethereum.
• Ảnh hưởng hạn chế đối với người ủy quyền : người ủy quyền không có tiếng nói được giao thức công nhận trong trình xác thực
  lựa chọn hoặc quản lý. Biện pháp duy nhất của họ là rút lui và chuyển vốn đi nơi khác, thường là
  gây ra sự chậm trễ và chi phí cơ hội. Nếu không có cơ chế thể hiện sở thích của người xác thực hoặc quan điểm quản trị, người ủy quyền sẽ chỉ có giá trị về mặt kinh tế nhưng lại không có tiếng nói về mặt chính trị. Điều này làm giảm hiệu quả của việc ủy quyền như một cơ chế tăng cường an ninh.
• Tăng sự xáo trộn của trình xác thực : tần suất các mục nhập và thoát của trình xác thực là giả tạo
  bị thổi phồng ngày nay do mô hình ủy quyền thiếu cơ chế phân bổ lại cổ phần một phần. Nếu không có hỗ trợ trong giao thức để ủy quyền lại nhanh hơn, các giao thức đặt cược thanh khoản phải thoát khỏi trình xác thực.
  hoàn toàn và tạo ra các máy chủ mới chỉ để phân bổ lại vốn. Điều này gây ra tình trạng luân chuyển máy xác thực dư thừa, tăng tải cho lớp đồng thuận (hàng đợi kích hoạt, hàng đợi thoát, quét máy xác thực) và làm tăng gánh nặng xác minh chữ ký. Mặc dù việc hợp nhất máy xác thực được giới thiệu bởi EIP-7251 giúp giảm tỷ lệ máy chủ luân chuyển (rundown), nhưng nó không giải quyết hoàn toàn tình trạng máy chủ luân chuyển liên quan đến việc điều chỉnh ủy quyền.
  Các mô hình ủy quyền hiện tại vẫn gây ra hiện tượng churn không cần thiết khi cổ phần thay đổi giữa các trình xác thực. Tính năng hợp nhất cải thiện khả năng mở rộng, nhưng vẫn còn hạn chế đối với các vấn đề churn cụ thể của ủy quyền.
• Thiếu khả năng hiển thị giao thức vào Ủy quyền : Giao thức đồng thuận của Ethereum không theo dõi
  mối quan hệ ủy quyền. Nó không "xem" liệu ETH có được ủy quyền hay không, cho ai hoặc trong bao lâu.
  Nếu không có khả năng hiển thị, giao thức không thể hỗ trợ lựa chọn trình xác thực có nhận thức về ủy quyền hoặc tín hiệu quản trị. Điều này hạn chế khả năng phát triển theo hướng đồng thuận và mô hình trách nhiệm giải trình của trình xác thực nhạy bén hơn.

4. Mô hình ủy quyền cần có những yêu cầu gì?

Phác thảo danh sách (không giới hạn) các yêu cầu và ràng buộc thiết kế cho bất kỳ sự ủy quyền khả thi nào
người mẫu:

Nó nên đạt được điều gì

• Loại bỏ các rủi ro hợp đồng do LST gây ra (tiền gửi, ủy quyền), đồng thời duy trì giao thức
  đảm bảo an ninh.
• Tối ưu hóa giao thức cho các nhà khai thác trong nước. Việc phân quyền sẽ tạo điều kiện cho các đối thủ cạnh tranh mới trong
  thị trường đặt cược, bao gồm cả các nhà điều hành tại nhà , do đó, điều hợp lý là một mô hình ủy quyền khả thi sẽ hỗ trợ sự tham gia của nhóm nhà điều hành xác thực phi tập trung nhất, đa dạng nhất nhưng kém bền vững nhất về mặt tài chính đối với nền kinh tế quy mô, mà không tập trung hóa
• Vai trò và tiếng nói có ý nghĩa trong giao thức dành cho Người ủy quyền (người nắm giữ ETH)
• Hỗ trợ giao thức gốc cho việc giới thiệu tín hiệu quản trị trong tương lai, ví dụ như xếp hạng và lựa chọn trình xác thực
• Cải thiện UX cho cả nhà điều hành xác thực và nhà cung cấp vốn

Chức năng mong đợi:

• Hoạt động ủy quyền liền mạch được khởi tạo từ ví của người nắm giữ ETH

• Phân bổ lại trọng số giao thức nhanh hơn (phân bổ lại nhanh hơn)

• Trách nhiệm giải trình được ghi nhận đối với các hoạt động ủy quyền an toàn và không cần xin phép

  Chức năng tính năng mở rộng cải thiện tỷ lệ giữa độ phức tạp của giao thức được tạo ra và lợi ích của nó, do đó, Delegation sẽ không chỉ là một kênh an toàn để tạo doanh thu từ các hoạt động xác thực mà còn là một cơ chế lựa chọn và là cách để người nắm giữ ETH truyền tín hiệu quản trị đến giao thức.

Hạn chế

Tính năng này nên giới thiệu mức độ phức tạp thấp nhất có thể, đồng thời đạt được mục tiêu mong muốn
chức năng. Theo mọi nghĩa thực tế, Ủy quyền, theo tôi, nên là một tính năng giao thức tùy chọn,
hỗ trợ sự tham gia giao thức gián tiếp.
Về mặt lý tưởng, việc ủy quyền sẽ phù hợp với các nâng cấp trong lộ trình và giảm thiểu một số
sự đánh đổi liên quan đến:

• Triển khai SSF : Giảm bộ xác thực do SSF áp đặt, được thực hiện bằng cách giới hạn bộ xác thực
  thiết lập hoặc bằng cách triển khai Orbit SSF, sẽ ngăn chặn hoặc làm giảm sự tham gia giao thức của các thực thể
  kiểm soát số cổ phần không đủ để vượt qua vòng loại. Khả năng giới thiệu các vai trò giao thức nhẹ
  tách biệt với việc chứng thực , sẽ giảm thiểu sự đánh đổi này. Một mô hình ủy quyền khả thi sẽ là
  tương thích với chuyên môn hóa vai trò xác thực trong tương lai
• Hạn chế đường cong phát hành đồng thời tối ưu hóa cho một số lượng lớn giao thức
  những người tham gia , mặc dù là những người tham gia ít. Trong trường hợp giới hạn đường cong phát hành, giá trị
  đề xuất đặt cược có thể trở nên kém hấp dẫn hơn đối với các nhà điều hành lớn, trong khi nhiều nhà điều hành nhỏ
  Các bên xác thực có thể muốn tham gia. Với đường cong phát hành hiện tại, việc staking ETH là hành vi bình thường, hợp lý của bất kỳ người nắm giữ ETH nào. Với việc giới hạn đường cong cuối cùng, sau một ngưỡng staking nhất định, việc chỉ cần nắm giữ ETH là đủ , để khả thi về mặt kinh tế. Do đó, việc staking, hay ủy quyền staking, có thể sẽ chuyển thành tín hiệu quản trị, với việc người nắm giữ ETH ủy quyền để hỗ trợ khả năng phục hồi và phi tập trung, thay vì chỉ vì lý do hiệu quả vốn. Một mô hình ủy quyền khả thi sẽ cung cấp một đường truyền liền mạch, an toàn cho tín hiệu quản trị được điều chỉnh theo trọng số ủy quyền.

Kỳ vọng tin cậy đối với các nhà điều hành xác thực

Các nút staking thương mại, cung cấp dịch vụ staking cho người nắm giữ ETH, trước hết đã được công nhận là đáng tin cậy , nhờ các ràng buộc pháp lý và thương mại để thực hiện tốt nhiệm vụ Đại lý và duy trì danh tiếng tốt. Sự khác biệt giữa nhà điều hành nội địa và nhà điều hành thương mại thực sự không nằm ở hiệu suất, mà là ở niềm tin . Nhà điều hành nội địa giành được niềm tin cho đại lý của mình thông qua kinh tế học tiền điện tử, hay còn gọi là "có lợi ích trong trò chơi".

Một mô hình ủy quyền khả thi sẽ cung cấp một cách thức liền mạch cho các nhà vận hành xác thực đặt cọc và đủ điều kiện nhận ủy quyền. Và mặc dù "điều gì đó bị đe dọa" rất có thể sẽ vẫn tồn tại trong Ethereum, nhưng trong tương lai, với cơ sở hạ tầng phù hợp, giao thức này có thể chấp nhận các chỉ số tin cậy khác ngoài uy tín, chẳng hạn như sự phù hợp với các giá trị cộng đồng.

5. Đầu hàng mô hình

eODS (Phân tách người ủy quyền điều hành) đề xuất tách vai trò Người xác thực giữa Người điều hành và Người ủy quyền, về mặt chức năng bổ sung tính năng ủy quyền vào lớp đồng thuận của Ethereum.

Diễn viên và mối quan hệ

Phần sau minh họa các vai trò cốt lõi trong mô hình phân quyền này:

Phía EL

• Người nắm giữ ETH là thực thể vật lý cung cấp vốn và sở hữu khóa rút tiền
• Tiền đặt cọc để ủy quyền hợp đồng
• Hợp đồng yêu cầu hoạt động ủy quyền (Biên dịch trước)

Phía CL

• Người ủy quyền như một thực thể giao thức
• Trình xác thực được ủy quyền như một thực thể giao thức, đóng vai trò là trình bao bọc xung quanh thực thể Trình xác thực hiện có và
• Kế toán chuỗi Beacon, một tiện ích kế toán giao thức

Phần trên mô tả một cấu trúc ủy quyền, sẽ không sửa đổi cách trình xác thực thực hiện
nhiệm vụ giao thức.

Mối quan hệ giữa các bên

• Người nắm giữ ETH : thực thể vật lý cung cấp vốn và là người sở hữu thông tin xác thực rút tiền.
• Người nắm giữ ETH gửi tiền vào DEPOSIT_TO_DELEGATE_CONTRACT
• Người ủy quyền , với tư cách là thực thể giao thức được tạo ra hoặc nếu tồn tại, số dư của nó sẽ được nạp thêm
• Người ủy quyền được kiểm soát bởi khóa rút tiền của người nắm giữ ETH
• Sổ đăng ký các trình xác thực được ủy quyền của BeaconState chính thức hóa mối quan hệ giữa
  Người ủy quyền và người xác thực ở cấp độ giao thức. Theo mô hình này, các điều kiện sau PHẢI được đáp ứng để người xác thực bắt đầu nhận ủy quyền:
  • Trình xác thực phải tồn tại trong sổ đăng ký của tiểu bang
  • Thông tin xác thực rút tiền được thiết lập để gộp và người xác thực chọn trở thành Nhà điều hành ,
    tức là tham số validator.is_operator được đặt thành True .
• Khi ủy quyền, người ủy quyền được liên kết rõ ràng với người xác thực được ủy quyền. Người ủy quyền
  sổ đăng ký bên trong mỗi đối tượng trình xác thực được ủy quyền chứa hai danh sách song song: delegated_balances và delegators_quotas
• Kế toán chuỗi Beacon, một tiện ích kế toán được ghi nhận có trách nhiệm lưu giữ
  bảng cân đối kế toán cụ thể theo ủy quyền.

Biểu đồ dòng vốn

DÒNG VỐN 2731×1727 158 KB

Vòng đời ủy quyền

Vòng đời ủy quyền cho mô hình eODS này bao gồm các khả năng ủy quyền cụ thể sau đây
hành động:

Tiền gửi để ủy quyền

 **ETH holder**└── sends ETH from execution address→ **Deposit to Delegate Contract** (ETH is burned)└── Contract emits → deposit to delegate event └── received by → **Consensus Client** via the execution payload└── deposit to delegate request is processed during epoch_transition└── creates new **Delegator** inside the Beacon Statetops-up existing **delegator**s balance with delegated amount└── links → **ETH holder** ⇄ **Delegator** via ETH holder s execution address

Kích hoạt toán tử

 **Validator signs EL tx with withdrawal key**└── calls **Delegation Operations Requests Precompile**└── received by → **Consensus Client** via the execution payload└── activation request is processed during epoch_transition└── changes `validator.is_operator` parameter to `True`└── appends the **Delegated Validator** inside the Beacon state registry└── links → **Delegated Validator** ⇄ **target Validator**

Ủy quyền (cho người xác thực)

 **User (Delegator) signs EL tx from execution address**└── calls **Delegation Operations Requests Precompile**└── received by → **Consensus Client** via the execution payload└── delegation request is processed during epoch_transition└── asserts the delegation amount fits in the activation churn limit└── invokes → **beacon-chain-accounting**└── decreases **Delegator** s non delegated balance ( available balance ) with delegated amount└── increases **Delegated Validator**'s total delegated balance and the delegated balance from that specific Delegator with delegated amount└── recalculates delegators quotas under that specific **Delegated Validator**└── cumulates the **Validator**'s total delegated balance into its effective balance

Hủy ủy quyền (từ trình xác thực)

 **User (Delegator) signs EL tx from execution address**└── calls **Delegation Operations Requests Precompile**└── received by → **Consensus Client** via the execution payload└── undelegation request is processed during epoch_transition└── calculates the undelegation s exit and withdrawability epochs└── appends the undelegation in the undelegation exit queue└── at withdrawal epoch, invokes → **beacon_chain_accounting** to settle undelegation└── decreases **Delegated Validator** s total delegated balance and the delegated balances from that specific Delegator with undelegated amount ( includes validator fee )└── recalculates delegators quotas under that specific **Delegated Validator**└── credits **Delegator**s non delegated balance with the undelegated amount minus validator fee└── credits **Validator**s actual balance with validator fee 

Phân quyền lại (từ trình xác thực nguồn sang trình xác thực đích)

Lưu ý: Một lần tái ủy quyền bao gồm một lần hủy ủy quyền theo sau là một lần ủy quyền.

 **User (Delegator) signs EL tx from execution address**└── calls **Delegation Operations Requests Precompile**└── received by → **Consensus Client** via the execution payload└── redelegation request is processed during epoch_transition└── calculates the redelegation s exit and withdrawability epochs before balance re-allocation to target validator└── the redelegation is appended in the undelegation exit queue└── at withdrawal epoch, appends the redelegation in the delegations activation queue└── delegation request processed during epoch_transition└── asserts the delegation amount fits in the activation churn limit└── invokes → **beacon-chain-accounting**└── increases target validator s total delegated balance and the delegated balance from that specific delegator with delegated amount└── recalculates delegators quotas under that specific **Delegated Validator**└── cumulates the validator s total delegated balance into its effective balance 

Rút khỏi người ủy quyền (đến địa chỉ thực hiện)

 **User (Delegator) signs EL tx from execution address**└── calls **Delegation Operations Requests Precompile**└── received by → **Consensus Client** via the execution payload└── withdraw from delegator request is processed during block processing└── the withdrawal is appended in a withdrawal queue└── the withdrawal from delegator is processed in next block → ETH minting to delegator's address 

Mô hình kế toán nội bộ

Kế toán chuỗi Beacon là một nhóm các phương thức trong đặc tả eODS giúp duy trì việc hạch toán các ủy quyền. Phương thức này được giao thức kích hoạt trong quá trình chuyển đổi trạng thái. Nó vận hành "bảng cân đối kế toán" trong các hoạt động cụ thể của ủy quyền như gửi tiền, rút tiền từ người ủy quyền, chuyển động số dư giữa người ủy quyền và người xác thực được ủy quyền, cũng như áp dụng phần thưởng, hình phạt và khấu trừ.

Kiến trúc này đảm bảo rằng chức năng kế toán chuỗi beacon hoạt động như một tiện ích giao thức —
được lưu giữ ở cấp độ giao thức nhưng tương thích với các nâng cấp trong tương lai, bao gồm vai trò xác thực
sự tách biệt.

Hạn ngạch

Người ủy quyền và hạn ngạch của người vận hành, theo một trình xác thực được ủy quyền nhất định, được duy trì một cách linh hoạt,
với các tính toán về phần thưởng và hình phạt phản ánh tỷ lệ cổ phần giữa những người ủy quyền.
Hạn ngạch được tính toán lại trong DelegatedValidator trên mỗi thay đổi trạng thái liên quan đến ủy quyền, sử dụng
danh sách song song ( delegated_balances , delegators_quotas ).

Cơ chế ủy quyền

Các hoạt động ủy quyền được khởi tạo thông qua các yêu cầu được kích hoạt bởi EL được thực thi trong CL. Điều này
cho phép luồng ủy quyền được quản lý theo giao thức.

Yêu cầu kích hoạt của Lớp thực thi (EL)

Ở cấp độ EL, người dùng tương tác với một hợp đồng yêu cầu hoạt động ủy quyền. Mỗi
hoạt động liên quan đến ủy quyền phát ra một yêu cầu hoạt động được cam kết vào
danh sách execution_requests , trong gói thực thi, được EL xây dựng cho người đề xuất.

Các loại yêu cầu hoạt động ủy quyền được kích hoạt bởi EL được hỗ trợ là:

(*) Giới hạn ở mức 16/khối để giảm thiểu tối đa các khoản rút tiền liên quan đến ủy quyền phát sinh thêm vào khối lượng thực thi. Bằng cách này, chi phí gas cho các hoạt động cấp hệ thống này có thể bằng không.

Các yêu cầu hoạt động này sẽ được xử lý trong quá trình xử lý kỷ nguyên/khối, các yêu cầu không hợp lệ sẽ bị loại bỏ.

Xử lý lớp đồng thuận (CL)

Trên Lớp đồng thuận, các yêu cầu hoạt động ủy quyền được xếp hàng trong quá trình xử lý khối và
được thực hiện tại thời điểm, ngoại trừ việc rút tiền từ số dư của người ủy quyền, được thực hiện trong quá trình xử lý khối. CL phân tích các yêu cầu này và gọi các chương trình con tương ứng trong
beacon-chain-accounting. Đối với mục đích kế toán liên quan đến ủy quyền, logic vòng đời ủy quyền được thực hiện dưới dạng các hoạt động kế toán mô-đun. Mô-đun beacon-chain-accounting không khởi tạo các chuyển đổi trạng thái hoặc quản lý trực tiếp các sổ đăng ký; các chương trình con của nó được gọi bởi beacon chain, nơi điều phối quá trình chuyển đổi trạng thái Beacon.

Mỗi phương pháp sau đây triển khai một giai đoạn duy nhất trong vòng đời ủy quyền:

An toàn có trách nhiệm trong eODS

Giai đoạn chủ quan yếu không bị ảnh hưởng bởi đề xuất này. Phân tích chi tiết về cách thức mô hình này
giữ cho số dư vào và ra khỏi giao thức được tính toán, có thể được tìm thấy tại đây .

Phần thưởng và hình phạt

Phần thưởng và hình phạt được phân bổ theo từng kỷ nguyên, cho tất cả người xác thực được ủy quyền và người ủy quyền của họ, theo tỷ lệ với hạn ngạch tham gia của họ.

Chém

Slashing là một cơ chế bảo mật cốt lõi trong các hệ thống bằng chứng cổ phần, xử phạt hành vi sai trái của trình xác thực
chẳng hạn như sự mơ hồ hoặc thời gian ngừng hoạt động. Nó bảo vệ tính toàn vẹn của sự đồng thuận bằng cách áp đặt các hậu quả kinh tế lên các tác nhân chịu trách nhiệm cho các lỗi nghiêm trọng. Trong Ethereum ngày nay, việc cắt giảm chỉ áp dụng cho các trình xác thực.
Người ủy quyền — thường là người dùng của các nhóm staking — không thể bị cắt giảm ở cấp độ giao thức. Bất kỳ tổn thất nào họ phải chịu đều được điều chỉnh bởi các điều khoản của dịch vụ staking, chứ không phải bởi chính giao thức. Các hệ sinh thái khác như Cosmos, Tezos và Solana triển khai tính năng theo dõi ủy quyền gốc và áp dụng cắt giảm tương ứng cho người ủy quyền.

Chém dưới eODS

Mô hình này đề xuất việc giới thiệu việc cắt giảm cả trình xác thực mơ hồ và trình xác thực cuối cùng của nó
người ủy quyền, tỷ lệ thuận với hạn ngạch tham gia của họ.

So sánh các mô hình cắt

Phương pháp đề xuất để cắt giảm đảm bảo rằng các nhà cung cấp vốn được tiếp xúc trực tiếp với người xác thực
rủi ro, giúp tăng cường sự liên kết nhưng cũng làm tăng mức độ tiếp xúc thụ động của các bên liên quan, với những người ủy quyền được khuyến khích ủy quyền cho các nhà điều hành xác thực phát ra mức độ tín hiệu tin cậy theo yêu cầu của họ.

Giao thức	Mục tiêu chém	Ủy quyền cấp giao thức	Người ủy quyền có thể cắt giảm	Tác động của người ủy quyền
Ethereum (hiện tại)	Chỉ dành cho người xác thực			Chính sách gián tiếp qua nhóm
Ethereum (với mô hình eODS này)	Người xác thực và Người ủy quyền			Cắt giảm tỷ lệ trực tiếp
Vũ trụ	Người xác thực và Người ủy quyền			Cắt giảm tỷ lệ trực tiếp
Tezos	Người xác thực và Người ủy quyền			Chia sẻ mất mát về hành vi sai trái
Solana	Người xác thực và Người ủy quyền			Cổ phần ủy quyền bị cắt giảm trực tiếp

Phân quyền lại ở cấp độ giao thức

Việc chuyển giao lại ở cấp độ giao thức cho phép người ủy quyền chuyển một phần cổ phần được ủy quyền của họ từ một
người xác thực cho người khác mà không thực hiện rút toàn bộ tiền rồi gửi lại. Điều này giải quyết
một trong những hạn chế cốt lõi của việc ủy quyền thông qua các nhóm đặt cược dựa trên hợp đồng thông minh. Nó cũng giúp
giảm thiểu sự xáo trộn của người xác thực, duy trì sự ổn định của mạng và mang lại cho người ủy quyền sự linh hoạt trong việc phản hồi
Hiệu suất của người vận hành hoặc sở thích quản trị. Nhìn từ góc độ tổng thể, một lệnh tái phân quyền bao gồm một lệnh hủy phân quyền, tiếp theo là một lệnh phân quyền.

Phụ lục cung cấp liên kết đến bài viết phân tích sâu về hình thức ủy quyền, hủy ủy quyền và tái ủy quyền từ góc nhìn của nhà phát triển.

6. Câu chuyện người dùng và tích hợp vòng đời

Để hiểu được những tác động thực tế của eODS, chúng tôi định hình chức năng của nó thông qua lăng kính của
Trải nghiệm của người tham gia. Những câu chuyện người dùng sau đây minh họa cách các bên liên quan của Ethereum—người nắm giữ ETH, nhà điều hành xác thực và khách hàng giao thức—tương tác với vòng đời ủy quyền theo mô hình này.
Đây không phải là giao diện người dùng cuối giả định, mà là các câu chuyện dựa trên vai trò được cấu trúc xung quanh
khả năng cung cấp giao thức được đề xuất trong eODS.

Người nắm giữ ETH (Người ủy quyền)

• Với tư cách là người nắm giữ ETH , tôi muốn gửi ETH vào DEPOSIT_TO_DELEGATE_CONTRACT ,
  để tôi trở thành người ủy quyền được giao thức công nhận với execution_address đã đăng ký và
  THĂNG BẰNG.
  → Vòng đời: DEPOSIT_TO_DELEGATE_REQUEST_TYPE → PendingDepositToDelegate , được xử lý tại ranh giới kỷ nguyên thông qua process_pending_deposits_to_delegate`.

• Với tư cách là người ủy quyền , tôi muốn ủy quyền một phần số dư chưa được ủy quyền của mình cho một người xác thực,
  để cổ phần của tôi góp phần vào bảo mật giao thức và có thể tích lũy phần thưởng thông qua nhà điều hành đó.
  → Vòng đời: DELEGATE_REQUEST_TYPE → PendingDelegateRequest , được thêm vào khối, được xử lý trên kỷ nguyên thông qua process_pending_delegations .

• Với tư cách là người ủy quyền , tôi muốn phân bổ lại cổ phần từ người xác thực này sang người xác thực khác mà không cần thoát khỏi
  hệ thống, để tôi có thể phản ứng hiệu quả với hiệu suất của nhà điều hành hoặc xu hướng quản trị.
  → Vòng đời: REDELEGATE_REQUEST_TYPE → PendingRedelegateRequest , được thêm vào khối, kích hoạt đường dẫn chuyển giao lại thông qua DelegationExitQueue .

• Với tư cách là người ủy quyền , tôi muốn hủy ủy quyền từ người xác thực trở lại số dư chưa ủy quyền của mình,
  để tôi vẫn có thể phân bổ lại cổ phần hoặc rút về EL sau này.
  → Vòng đời: UNDELEGATE_REQUEST_TYPE → PendingUndelegateRequest , được thêm vào khối, rút vào kỷ nguyên, với việc rút theo giai đoạn thông qua DelegationExitItem .

• Với tư cách là người ủy quyền , tôi muốn rút ETH từ số dư chưa được ủy quyền của mình trở lại địa chỉ thực hiện để tôi lấy lại toàn bộ tính thanh khoản bên ngoài hệ thống đặt cược.
  → Vòng đời: WITHDRAW_FROM_DELEGATOR_REQUEST_TYPE → PendingWithdrawFromDelegatorRequest , được xử lý trong khối , thông qua get_expected_withdrawals_from_delegators .

• Là người ủy quyền , tôi muốn mối quan hệ ủy quyền của mình có thể được quan sát theo giao thức,
  để chúng có thể đóng vai trò là tín hiệu công khai cho việc sắp xếp trình xác thực và sử dụng quản trị tiềm năng.
  → Vòng đời: Siêu dữ liệu ủy quyền được hiển thị trong các vùng chứa DelegatedValidator , có thể xem được thông qua kiểm tra trạng thái nhưng không được thực thi.

Toán tử xác thực

• Với tư cách là người xác thực , tôi muốn kích hoạt trạng thái nhà điều hành của mình để có thể nhận được cổ phần được ủy quyền và đóng vai trò là người xác thực được ủy quyền.
  → Vòng đời: ACTIVATE_OPERATOR_REQUEST_TYPE → PendingActivateOperator , được xác minh trên khối và được xử lý ngay lập tức thông qua process_pending_activate_operators .

• Với tư cách là người xác thực , tôi muốn nhận cổ phần được ủy quyền từ nhiều người ủy quyền, để tôi có thể khuếch đại trọng số xác thực của mình thông qua danh tiếng, chứ không chỉ riêng vốn.

• Với tư cách là người xác thực , tôi muốn phối hợp thanh khoản sớm với người ủy quyền trong quá trình thoát, để tôi có thể truy cập ETH trước khi hàng đợi rút tiền bị trì hoãn hoàn toàn.
  → Vòng đời: EARLY_LIQUIDITY_REQUEST_TYPE ghép nối nội bộ giao dịch rút tiền do bên ủy quyền khởi tạo với thông tin xác thực của nhà điều hành với giao dịch hoàn trả trong tương lai từ phía bên xác thực.

Chức năng giao thức

• Với tư cách là lớp đồng thuận , tôi muốn nhận các yêu cầu ủy quyền có cấu trúc thông qua
  execution_requests.delegation_operations để tôi có thể diễn giải, xếp hàng và xử lý chúng theo đúng thời điểm được giao thức xác định.
  → Vòng đời: DelegationOperationRequest được gửi trên khối, được phân tích cú pháp bởi
  process_delegation_operation_request , được định tuyến đến bộ đệm thích hợp.

• Là máy trạng thái giao thức , tôi muốn thực thi kỷ luật thời gian đối với các phái đoàn, để
  giới hạn tỷ lệ hủy và xếp hàng được duy trì.
  → Vòng đời: Việc xả bộ đệm ( process_pending_* ) xảy ra tại thời điểm, ngoại trừ
  withdraw_from_delegator sẽ rút tiền ở khối có giới hạn là 16.

• Với tư cách là lớp kế toán , tôi muốn duy trì hạn ngạch ủy quyền một cách năng động,
  để tính toán phần thưởng/hình phạt phản ánh tỷ lệ phần thưởng giữa người ủy quyền và người điều hành.
  → Vòng đời: Hạn ngạch được tính toán lại trong DelegatedValidator trên mỗi thay đổi trạng thái liên quan đến ủy quyền, sử dụng danh sách song song ( delegated_balances , delegators_quotas ).

7. Các bước tiếp theo

Trong bài đăng này, tôi đã đề xuất một tính năng sẽ tách biệt vai trò Người xác thực giữa Người vận hành (
Người đại diện) và Người ủy quyền (Người đứng đầu), đưa ra ý tưởng về việc ủy quyền được ghi nhận
ở cấp độ giao thức. Tôi đã trình bày một mô hình ủy quyền khả thi cho Ethereum, như một thông số kỹ thuật tối thiểu
của eODS, có thể được thử nghiệm và tinh chỉnh trong tương lai gần. Mô hình này cung cấp sự ủy quyền như một
tính năng lựa chọn tham gia, sẽ không sửa đổi nhiệm vụ đồng thuận của người xác thực hoặc thay đổi lựa chọn người xác thực,
Cơ chế ủy quyền đã được trình bày trong các chương trước. Có thể thực hiện thêm các nỗ lực nghiên cứu để phát triển các cơ chế mới dựa trên mô hình tối thiểu, chẳng hạn như tính thanh khoản ban đầu cho người xác thực, hoặc một cách để theo dõi việc ủy quyền và các số liệu liên quan.

Thanh khoản sớm cho người xác thực

Trong điều kiện hạn chế, người xác thực có thể yêu cầu truy cập ngay vào thanh khoản bằng cách rút tiền từ
số dư nhàn rỗi (không được ủy quyền) do người ủy quyền đã đăng ký nắm giữ.

• Người xác thực sẽ khởi tạo một yêu cầu thanh khoản sớm. Những người ủy quyền tham gia đồng ý
  chuyển một phần số dư của họ đến địa chỉ của người xác thực, kèm theo một khoản phí.
• Người ủy quyền thực hiện rút một phần số dư khả dụng của mình, gửi ETH đến
  địa chỉ thực thi của trình xác thực.
• Người xác thực, đến lượt mình, được mong đợi sẽ trả lại cho người ủy quyền thông qua việc rút tiền một phần theo tiêu chuẩn từ
  số dư thực tế của nó, được định tuyến thông qua hàng đợi thoát của trình xác thực.
• Việc hoàn trả không diễn ra ngay lập tức — nó được xử lý thông qua cơ chế rút tiền theo giao thức hiện có -
  duy trì tất cả các hạn chế về lãi suất và cắt giảm các đảm bảo. Số dư thanh khoản ban đầu được tạo ra
  có trách nhiệm an toàn theo quan điểm của giao thức, bằng cách áp đặt một trái phiếu bổ sung có số tiền bằng nhau từ số dư còn lại của người ủy quyền, có thể bị cắt, cho đến khi việc rút tiền của người xác thực đạt đến exit_epoch , ngăn chặn các cuộc tấn công giả mạo người ủy quyền-người xác thực.

Tính năng này có thể cho phép người xác thực truy cập ETH trong các tình huống nhạy cảm về thời gian (ví dụ: muốn thoát hoặc bù đắp các khoản phạt/thanh lý ở lớp ứng dụng) mà không ảnh hưởng đến tính an toàn của sự đồng thuận hoặc yêu cầu thoát ngay lập tức.

Tích hợp quản trị ban đầu

Người ủy quyền sẽ gửi các ưu tiên không ràng buộc của họ cho người xác thực, tương ứng với cổ phần của họ.
Các số liệu này có thể được trình bày cho người ủy quyền thông qua tiện ích mở rộng kế toán chuỗi đèn hiệu, để
Giao thức có thể theo dõi và cộng đồng có thể nghiên cứu theo thời gian, những tín hiệu ưu tiên quản trị có thể quan sát được. Dữ liệu ủy quyền hiển thị trên giao thức có thể đóng vai trò là nền tảng cho trách nhiệm giải trình của bên xác thực linh hoạt hơn trong tương lai. Rút kinh nghiệm từ các chuỗi như Cosmos, nơi thời gian hoạt động và hành vi sai trái của bên xác thực ảnh hưởng trực tiếp đến quyết định ủy quyền, các cơ chế tương tự trong Ethereum có thể khuyến khích bên xác thực duy trì hiệu suất cao và tính minh bạch, phù hợp với các giá trị cộng đồng và do đó giành được sự tin tưởng lớn hơn từ bên ủy quyền. Nếu và khi các chỉ số tin cậy mới được phát triển, việc lựa chọn bên xác thực có thể tính đến điều này, cho phép dòng vốn hợp lý chảy vào các dự án đáng tin cậy và phù hợp.
người vận hành.

PHỤ LỤC

thông số kỹ thuật có chú thích eODS

Có thể đi sâu vào eODS từ góc nhìn của nhà phát triển, cùng với các chú thích thông số kỹ thuật
tìm thấy ở đây .

Thay đổi Lớp thực thi

Trên lớp thực thi, các phần bổ sung là:

• DEPOSIT_TO_DELEGATE_CONTRACT, tương tự như DEPOSIT_CONTRACT hiện tại. Các sự kiện của hợp đồng này sẽ được phân tích cú pháp trong giao thức theo cùng cách mà các sự kiện của DEPOSIT_CONTRACT hiện đang được phân tích cú pháp:
  Ngữ nghĩa dòng chảy ETH

  • Hợp đồng nhận ETH và phát ra sự kiện.
  • Quỹ ETH bị đốt trên EL.
  • CL ghi có Gwei tương đương vào số dư của người ủy quyền

• Hợp đồng yêu cầu hoạt động ủy quyền, một hợp đồng thông minh chuyên dụng lấy cảm hứng từ thiết kế của Hợp đồng yêu cầu rút tiền EIP-7002 sử dụng định dạng EIP-7685 để mã hóa yêu cầu.

Thay đổi lớp đồng thuận

Bạn có thể tìm thấy toàn bộ những thay đổi đồng thuận trong kho lưu trữ GitHub sau đây. Chúng được chia thành:

• Beacon Chain thay đổi.
• Tệp thông số kỹ thuật mới của Beacon Chain Accounting .
• Lựa chọn ngã ba thay đổi.
• Hướng dẫn xác thực trung thực đã thay đổi.