지난 1년 동안 바나베 모노, 블라딘, 미하일 칼리닌, 알렉스 스토크스, 포투즈와의 생산적인 토론에 깊이 감사드립니다(이는 보증을 의미하지 않습니다). 다음 작업에서 제시된 의견과 견해는 지난 18개월간의 프로토콜 로드맵 및 R&D 담론에 기반하고 있지만, 이 프로젝트에 입력을 제공한 검토자 및 프로토콜 관계자의 견해를 반드시 대변하지는 않습니다. 앞으로 저는 레인보우 스테이킹과 같은 더 넓은 스테이킹 프레임워크를 위한 위임 모델을 제안하며, 그 논리, 구조, 구현 경로를 설명하겠습니다. 이 게시물은 해당 기능의 Pyspec이 첨부되어 있으며, 향후 Pytest 및 POC를 통해 모델의 성숙도를 높일 것입니다.
0. 개요
위임 - 제3자에게 스테이킹 권한 또는 거버넌스 권한을 할당하는 과정 - 은 많은 블록체인 생태계에서 근본적입니다. 그러나 이더리움은 프로토콜 수준에서 네이티브 위임을 지원하지 않으며, 대신 계약 기반 스테이킹 서비스에 의존하고 있습니다. 이러한 서비스는 자본 유치에 효과적이었지만, 중앙화 위험과 거버넌스 과제를 야기하여 프로토콜의 신뢰할 수 있는 중립성을 크게 약화시킵니다.
[이하 생략]당사자 간 관계
- 이더리움(ETH) 홀더: 자본을 제공하고 인출 자격 증명을 소유한 물리적 개체.
- 이더리움(ETH) 홀더가
DEPOSIT_TO_DELEGATE_CONTRACT에 예치 - 프로토콜 개체로서 위임자가 생성되거나, 기존의 경우 잔액이 보충됨
- 위임자는 이더리움(ETH) 홀더의 인출 키에 의해 제어됨
- 비콘 상태의 위임된 검증인 레지스트리는 프로토콜 수준에서 위임자와 검증인 간의 관계를 공식화합니다. 이 모델에서 검증인이 위임을 받기 시작하려면 다음 조건을 반드시 충족해야 합니다:
- 검증인이 상태 레지스트리에 존재해야 함
- 인출 자격 증명이 복리로 설정되고 검증인이 운영자가 되는 것을 선택해야 함, 즉
validator.is_operator매개변수가True로 설정됨.
- 위임 시, 위임자는 명시적으로 위임된 검증인과 연결됩니다. 각 위임된 검증인 객체 내의 위임자 레지스트리에는 두 개의 병렬 목록이 포함됩니다:
delegated_balances와delegators_quotas - 비콘 체인 회계는 위임 특정 대차대조표를 유지하는 책임이 있는 고유의 회계 장치입니다.
자본 흐름 다이어그램
(이하 생략, 전체 번역을 원하시면 추가로 요청해주세요)
합의 계층(CL) 처리
합의 계층에서 위임 작업 요청은 블록 처리 중에 대기열에 추가되고 출금을 제외하고 에포크에서 실행됩니다. 이때 위임자 잔액의 출금은 블록 처리 중에 실행됩니다. CL은 이러한 요청을 구문 분석하고 비콘 체인 회계에서 해당 서브루틴을 호출합니다. 위임 관련 회계 목적으로 위임 수명 주기 로직은 모듈식 회계 작업으로 수행됩니다. 비콘 체인 회계 모듈은 상태 전환을 시작하거나 레지스트리를 직접 관리하지 않으며, 해당 서브루틴은 비콘 체인에 의해 호출되어 비콘 상태 전환을 조정합니다.
[이하 생략하고 동일한 방식으로 번역]위임자로서, 내 위임 관계가 프로토콜에 의해 관찰 가능하기를 원합니다.
검증자 정렬 및 잠재적 거버넌스 사용을 위한 공개 신호로 사용될 수 있도록 합니다.
→ 라이프사이클: 위임 메타데이터는 DelegatedValidator 컨테이너에 노출되며, 상태 검사를 통해 볼 수 있지만 강제되지는 않습니다.
검증자 운영자
검증자로서, 내 운영자 상태를 활성화하고 싶습니다. 위임된 지분을 받고 위임된 검증자로 서비스를 제공할 수 있도록 합니다.
→ 라이프사이클:ACTIVATE_OPERATOR_REQUEST_TYPE→PendingActivateOperator, 블록에서 검증되고process_pending_activate_operators를 통해 즉시 처리됩니다.검증자로서, 여러 위임자로부터 위임된 지분을 받고 싶습니다. 자본만이 아니라 평판을 통해 검증자 가중치를 증폭시킬 수 있도록 합니다.
검증자로서, 탈출 시 위임자와 초기 유동성을 조정하고 싶습니다. 전체 인출 대기열 지연 전에 이더리움에 접근할 수 있도록 합니다.
→ 라이프사이클:EARLY_LIQUIDITY_REQUEST_TYPE은 내부적으로 운영자 자격증명에 대한 위임자 주도 인출을 향후 검증자 측 상환과 연결합니다.
프로토콜 기능
합의 계층으로서,
execution_requests.delegation_operations를 통해 구조화된 위임 요청을 받고 싶습니다. 프로토콜에서 정의한 적절한 시점에 이를 해석, 대기열에 추가 및 처리할 수 있도록 합니다.
→ 라이프사이클:DelegationOperationRequest가 블록에서 디스패치되고,process_delegation_operation_request에 의해 구문 분석되어 적절한 버퍼로 라우팅됩니다.프로토콜 상태 머신으로서, 위임에 대한 타이밍 규율을 강제하고 싶습니다. 변동 및 대기열 속도 제한이 유지되도록 합니다.
→ 라이프사이클: 버퍼 배출(process_pending_*)은 에포크에서 발생하며,withdraw_from_delegator는 16개의 상한선으로 블록에서 배출됩니다.회계 계층으로서, 위임자 할당량을 동적으로 유지하고 싶습니다.
위임자와 운영자 간 비례 지분을 반영하여 보상/페널티 계산이 이루어지도록 합니다.
→ 라이프사이클: 할당량은 각 위임 관련 상태 변경 시DelegatedValidator에서 재계산되며, 병렬 목록(delegated_balances,delegators_quotas)을 사용합니다.
7. 다음 단계
이 게시물에서 저는 검증자 역할을 운영자(에이전트)와 위임자(주체) 사이에 분리하는 기능을 제안했으며, 프로토콜 수준에서 위임을 고정하는 아이디어를 제시했습니다. 이더리움을 위한 가능한 위임 모델을 최소한의 eODS 사양으로 제시했으며, 이는 즉시 테스트되고 개선될 수 있습니다. 이 모델은 선택적 기능으로서의 위임을 제공하며, 검증자 합의 임무를 수정하거나 검증자 선택을 변경하지 않습니다. 추가 연구 노력을 통해 최소 모델 위에 검증자를 위한 초기 유동성이나 위임 및 관련 지표를 추적하는 새로운 메커니즘을 개발할 수 있습니다.
