MRC-13

## 초록

이 MRC는 Monad 스테이킹 프리컴파일(`0x0000000000000000000000000000000000001000`)을 보완하는 온체인 레지스트리 계약을 지정하며, 인간이 읽을 수 있는 검증자 메타데이터: 이름, 웹사이트, 설명, 로고 URL, JSON `socials` 필드, 그리고 향후 호환 가능한 확장을 위한 JSON `additionalInfo` 필드를 포함합니다. 최소한, 검증자의 권한 주소 — 스테이킹 프리컴파일에 의해 보고된 — 는 해당 검증자에 대한 메타데이터를 작성할 수 있어야 하며; 구현은 자체 권한 모델에 따라 추가 호출자에게 쓰기 권한을 부여할 수 있습니다. 레지스트리는 전체 기록 쓰기와 필드별 업데이트를 모두 노출하며, 저장된 기록에 대한 읽기 메서드를 제공합니다.

## 동기

Monad 스테이킹 프리컴파일은 합의 계층에서 검증자 신원의 진실의 원천이지만, 의도적으로 합의 및 보상 회계를 위해 필요한 데이터(권한 주소, 플래그, 스테이크, 수수료, 공개 키 등)만 노출합니다. 검증자에 대한 인간이 읽을 수 있는 신원은 제공하지 않습니다.

지갑, 블록 탐색기, 스테이킹 대시보드, 거버넌스 UI, 그리고 위임 도구는 모두 숫자 `validatorId` 대신 인식 가능한 이름과 로고로 검증자를 렌더링할 필요가 있습니다. 현재 각 통합자는 이를 독립적으로 해결하고 있으며 — 일반적으로 오프체인 `metadata.json` 파일이나 중앙에서 관리되는 목록을 유지함으로써 — 이는 생태계 전반에 걸쳐 일관되지 않은 명명, 깨지거나 오래된 링크, 그리고 검증자가 사용자에게 어떻게 라벨링되는지를 통제하는 중앙 집중화 위험을 초래합니다.

허가 없는 검증자 제어 온체인 레지스트리는 큐레이션 병목 현상을 제거합니다: 이미 스테이킹 매개변수를 제어하는 동일한 권한 키가 검증자의 메타데이터를 게시할 수 있도록 허용되며, 모든 통합자는 이 표준에 부합하는 레지스트리 계약에서 직접 읽을 수 있습니다.

## 사양

이 문서에서 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"이라는 주요 용어는 [RFC 2119](https://www.ietf.org/rfc/rfc2119.html) 및 [RFC 8174](https://www.ietf.org/rfc/rfc8174.html)에서 설명된 대로 해석되어야 합니다.

### 개요

준수하는 구현은 아래 정의된 `IValidatorMetadata` 인터페이스에 부합하는 단일 계약을 배포해야 합니다. 계약은 주어진 `validatorId`의 현재 권한 주소를 결정하기 위해 `0x0000000000000000000000000000000000001000`에서 Monad 스테이킹 프리컴파일을 쿼리해야 하며, 호출 시 해당 권한 주소로부터의 쓰기 호출을 수락해야 합니다. 구현은 추가적으로 자체 권한 규칙에 따라 다른 호출자로부터의 쓰기를 수락할 수 있습니다; [Authorization](#authorization)을 참조하십시오.

### 인터페이스

```solidity
interface IValidatorMetadata {
    /// 유효성 검사자의 메타데이터에 대한 모든 성공적인 쓰기 시 발생합니다.
    event MetadataUpdated(uint64 indexed validatorId, address indexed authority, Metadata metadata);

    /// 유효성 검사자 메타데이터 레코드. 쓰기 규칙 및 `socials`와 `additionalInfo` 필드에 대한 JSON
    /// 규칙을 보십시오.
    struct Metadata {
        string name;
        string website;
        string description;
        string logo;
        string socials;
        string additionalInfo;
    }

    /// `updateMetadataField`에 대한 필드 선택기.
    enum Field {
        NAME,
        WEBSITE,
        DESCRIPTION,
        LOGO,
        SOCIALS,
        ADDITIONAL_INFO
    }

    /// 권한 해석에 사용되는 Monad 스테이킹 프리컴파일의 주소.
    /// 구현은 `0x0000000000000000000000000000000000001000`을 반환해야 합니다.
    function STAKING_PRECOMPILE() external view returns (address);

    /// 유효성 검사자에 대한 전체 메타데이터 레코드를 설정하거나 교체합니다. 권한이 있는 호출자
    /// 및 되돌리기 조건은 Authorization 및 Field Semantics에 정의되어 있습니다.
    function setMetadata(uint64 validatorId, Metadata calldata metadata) external;

    /// 단일 필드를 업데이트하고 다른 필드는 그대로 둡니다. `validatorId`에 대한 레코드가 아직 존재하지 않으면
    /// 되돌립니다 — `setMetadata`는 레코드를 생성할 수 있는 유일한 진입점입니다. `field == SOCIALS` 또는
    /// `ADDITIONAL_INFO`의 경우, 호출자는 UTF-8 JSON 객체를 전달해야 합니다; 레지스트리는 `value`를
    /// 있는 그대로 저장합니다.
    function updateMetadataField(uint64 validatorId, Field field, string calldata value) external;

    /// `validatorId`에 대한 전체 저장된 메타데이터 레코드를 읽거나, 레코드가 존재하지 않으면 모든 기본값
    /// `Metadata` 구조체를 반환합니다. `hasMetadata`를 사용하여 구분하십시오.
    function getMetadata(uint64 validatorId) external view returns (Metadata memory metadata);

    /// `validatorId`에 대한 메타데이터 레코드가 작성되었는지 여부. `name`이 비어 있지 않은 것과
    /// 동등합니다. `name`은 모든 쓰기에서 필수입니다.
    function hasMetadata(uint64 validatorId) external view returns (bool);

    /// 유효성 검사자의 저장된 이름만 읽거나, 메타데이터가 설정되지 않은 경우 빈 문자열을 반환합니다.
    function getValidatorName(uint64 validatorId) external view returns (string memory);
}
```

### 권한 부여

모든 쓰기 진입점(`setMetadata`, `updateMetadataField`)에 대해, 구현은 호출 시 `STAKING_PRECOMPILE()`에서 스테이킹 프리컴파일의 `getValidator(validatorId).authority`를 호출하여 유효성 검사자의 권한을 해결해야 하며, `msg.sender`가 해당 주소와 같을 때 호출을 수락해야 합니다. 구현은 권한 주소를 캐시하거나 그림자 처리해서는 안 됩니다: 스테이킹 프리컴파일에서 권한 변경은 즉시 적용되어야 합니다.

MRC-13: 검증자 메타데이터 레지스트리

Beyond this baseline, implementations are free to define their own authorization model and MAY accept writes from additional callers — for example, a delegated operator key, a multisig wrapper, a governance contract, or a designated metadata manager — provided that any caller not granted access under the chosen scheme is rejected. The revert reason for unauthorized callers is implementation-defined but SHOULD be a custom error (e.g. `Unauthorized()`) rather than a string.

### 필드 의미

- `name`은 필수이며 모든 메타데이터가 있는 검증자에 대해 비어 있지 않아야 합니다. `setMetadata`는 비어 있는 `name`이 주어지면 revert해야 합니다. `updateMetadataField`는 `Field.NAME`과 비어 있는 값으로 호출되면 revert해야 합니다. 위와 마찬가지로, revert 이유는 구현에 따라 정의되지만 사용자 정의 오류(예: `ValidatorNameEmpty()`)여야 합니다.
- `website`, `description`, `logo`, `socials`, 및 `additionalInfo`는 선택적 문자열입니다. 레지스트리는 그 내용을 검증해서는 안 되며, 통합자는 이를 신뢰할 수 없는 입력으로 간주하고 렌더링 전에 정리해야 합니다.
- `socials`는 비어 있지 않을 경우, 키가 소문자 플랫폼 식별자인 UTF-8 JSON 객체여야 하며, 값은 해당 프로필 URL 또는 핸들이어야 합니다. 예를 들어:

  ```json
  {
    "x": "https://x.com/monad_xyz",
    "telegram": "https://t.me/monad",
    "discord": "https://discord.gg/monad",
    "github": "https://github.com/monad-developers"
  }
  ```

  플랫폼 키의 집합은 이 MRC에서 열거되지 않습니다. 통합자는 알려지지 않은 키를 불투명한 것으로 간주하고 그대로 전달해야 합니다. `socials`를 JSON 객체로 인코딩하는 것은 생태계의 소셜 미디어 환경이 시간이 지남에 따라 변화함에 따라 레지스트리를 사용 가능하게 유지합니다.
- `additionalInfo`는 비어 있지 않을 경우 UTF-8 JSON 객체여야 합니다. 이는 호환 가능한 메타데이터 확장을 위해 예약되어 있으며(예: 위임 정책, 서명된 증명, 콘텐츠 해시, 향후 MRC 페이로드) 이 MRC에 의해 정의된 최상위 스키마는 없습니다. 하위 MRC는 그 안에 예약된 키 네임스페이스를 정의할 수 있습니다.
- `socials`와 `additionalInfo`는 원시 문자열로 저장됩니다. 레지스트리는 이를 파싱하려고 시도해서는 안 되며, 구문적으로 유효하지 않은 JSON을 거부해서는 안 되며, 읽기 시 바이트 단위로 반환해야 합니다. 따라서 JSON 준수는 레지스트리에 의해가 아니라 작성자와 소비자에 의해 시행되는 관습입니다.

### 쓰기 전제 조건

`setMetadata`는 새 레코드를 생성할 수 있는 유일한 진입점입니다. `updateMetadataField`는 기존 레코드가 없는 `validatorId`에 대해 호출되면 revert해야 합니다(즉, `hasMetadata(validatorId)`가 `false`인 경우). 이 불변성은 "`name`은 필수" 규칙을 시행 가능하게 만듭니다: 비어 있는 `name`으로 레코드가 존재할 수 없으며, 레코드를 생성하는 유일한 방법인 `setMetadata`가 비어 있는 이름을 거부하고, 필드 업데이트는 레코드가 존재하기 전에 실행될 수 없습니다.

### 이벤트

성공적인 쓰기마다 정확히 하나의 `MetadataUpdated` 이벤트가 발생해야 합니다. `metadata` 필드는 쓰기 직후 관찰 가능한 전체 레코드를 반영해야 하며 — `updateMetadataField`의 경우, 이는 이전에 저장된 필드와 새로 업데이트된 필드를 포함합니다.

### 읽기 의미

- `getMetadata`, `getValidatorName`, 및 `hasMetadata`는 스테이킹 프리컴파일을 호출해서는 안 됩니다.
- `STAKING_PRECOMPILE()`는 `0x0000000000000000000000000000000000001000`을 반환해야 합니다.
- `hasMetadata`는 저장된 `name`이 비어 있지 않을 경우에만 `true`를 반환해야 합니다. `name`은 모든 기본값이 초기화되지 않은 슬롯의 일부로 비어 있는 문자열로 설정될 수 없기 때문에, 이는 "이 검증자에 대해 메타데이터가 한 번이라도 작성되었고 이후에 null로 설정되지 않았다"는 것과 동등합니다.
- 구현은 이 인터페이스 외부에 추가 뷰 함수를 노출할 수 있지만(예: 결합된 "스테이킹 정보 + 메타데이터" 리더), 여기 정의된 함수의 의미를 변경해서는 안 됩니다.

### 체인 세부사항

이 MRC에 따라 준수하는 레지스트리 계약은 배포 시 선택된 일반 계약 주소에 배포됩니다 — 프리컴파일 주소가 아니라 — 그리고 두 주소는 권한 해결을 위해 `0x0000000000000000000000000000000000001000`에서 프리컴파일을 호출한다는 점 외에는 관련이 없습니다.

이 MRC는 특정 바이트코드나 주소가 아닌 인터페이스와 행동 사양을 정의합니다. 독립적으로 배포된 준수 구현체는 Monad-EVM 네트워크에서 공존할 수 있으며; 이 MRC는 그 중 어떤 것도 정본으로 지정하지 않으며 주소를 기록하지 않습니다. 통합자와 검증자는 자신의 신뢰 및 운영 선호에 따라 어떤 준수 배포에 쓰고 읽을지를 선택합니다.

어떤 배포도 `0x0000000000000000000000000000000000001000`에서 스테이킹 프리컴파일을 노출하는 네트워크에서만 유효합니다; 프리컴파일이 없는 네트워크에서는 쓰기 메서드가 되돌려지고 프리컴파일을 통해 프록시하는 읽기 메서드는 제로 레코드를 반환하므로, 준수 레지스트리는 이러한 네트워크에서 기능할 수 없습니다.

## 근거

**스테이킹 프리컴파일에 권한 부여를 왜 고정해야 합니까?** 프리컴파일은 이미 `validatorId`에서 권한 주소로의 표준 매핑을 보유하고 있으며, 권한 회전이 합의에 의해 인식되는 유일한 메커니즘입니다. 다른 출처(예: 이름에 대한 ECDSA 서명)에서 신원을 다시 유도하는 것은 두 번째, 분기된 신원 시스템을 도입하게 됩니다.

**`setMetadata`와 `updateMetadataField`를 왜 분리해야 합니까?** 로고 URL과 같은 것을 변경하고자 하는 검증자는 전체 레코드(잠재적으로 긴 `description` 및 `additionalInfo` 필드를 포함하여)를 다시 제출해야만 짧은 문자열 하나를 변경할 수 있습니다. 필드별 업데이트는 가스 및 calldata 비용을 줄이고, 권한이 다른 필드를 실수로 덮어쓰는 가능성을 줄입니다.

**왜 `name`이 유일한 필수 필드입니까?** 이름이 없는 검증자는 설정되지 않은 레코드와 구별할 수 없습니다(참조: `hasMetadata`). 다른 모든 필드는 방어 가능한 빈 기본값을 가지고 있습니다 — 검증자는 합법적으로 웹사이트, 로고 또는 소셜 존재가 없을 수 있습니다.

**왜 JSON `additionalInfo` 필드가 필요합니까?** 구조체를 확장하는 것은 ABI를 깨는 변경입니다. 자유 형식의 텍스트 필드는 향후 MRC가 구조화된 확장(위임 정책, 서명된 증명, IPFS CID 등)을 새로운 레지스트리 배포나 저장소 마이그레이션 없이 계층화할 수 있게 합니다. JSON은 나머지 레코드가 이미 사람이 읽을 수 있는 텍스트이기 때문에 선택되었으며, 이 공간의 모든 오프체인 소비자는 이미 JSON을 사용하고, 이진 페이로드는 필요할 때 JSON 값 내에서 헥스 인코딩될 수 있습니다.

**왜 `socials`에 JSON을 사용합니까(플랫폼당 하나의 열 대신)?** 구조체에서 특정 플랫폼을 명시하면 레지스트리가 오늘날의 소셜 미디어 환경에 고정됩니다. 플랫폼 식별자로 키가 지정된 JSON 객체는 도구가 알려진 키(`"x"`, `"telegram"`, …)를 선택할 수 있을 만큼 구조화되어 있으며, 세트를 규정하지 않습니다; 새로운 플랫폼은 검증자가 레지스트리에 변경 없이 추가할 수 있고, 플랫폼은 죽은 구조체 필드를 남기지 않고 제거할 수 있습니다. 레지스트리는 의도적으로 JSON을 파싱하지 않습니다 — 이는 온체인에서 비용이 많이 들고 사양이 특정 JSON 방언에 고정되도록 강요할 것입니다 — 따라서 일관성은 작성자와 독자 간의 사회적 규범에 의해 강제됩니다.

**왜 권한 주소가 단지 기준일 뿐, 유일한 작성자가 아닙니까?** 권한 주소는 오늘날 모든 검증자가 명백히 제어하는 유일한 신원이므로, 이를 고정하는 것은 일관되고 합의에 맞는 기본값을 제공합니다. 그러나 검증자는 메타데이터 관리를 위임할 실제 이유가 있습니다 — 핫키/콜드키 분리, 스테이킹 키를 건드리지 않고 브랜드를 회전하는 팀 운영자, 보안에 민감한 운영자를 위한 멀티시그 게이트 변경 — 그리고 이러한 흐름이 권한 키를 공유하도록 강제하면 폭발 반경이 확장되거나 검증자가 다시 오프체인 큐레이션으로 밀려날 수 있습니다. 구현이 권한 기준 위에 작성자 집합을 확장할 수 있도록 하면 기본 경로의 감사 가능성을 유지하면서(누구나 권한이 최소한 허용되었음을 검증할 수 있음) 운영적으로 현실적인 정책을 위한 여지를 남깁니다.

**왜 데이터를 온체인에 저장하고 단순히 콘텐츠 해시를 사용하지 않습니까?** 이름을 온체인에 저장하는 것은 검증자의 가스 예산에 비해 저렴하며, 이름 및 웹사이트와 같은 1급 필드에 대한 외부 콘텐츠 주소 지정 저장소의 가용성에 대한 의존성을 제거하고, 라이트 통합자가 IPFS 또는 HTTP 가져오기 없이 메타데이터를 읽을 수 있게 합니다. 더 무거운 확장 페이로드는 `additionalInfo`를 사용하여 콘텐츠 해시를 보유할 수 있습니다.

## 하위 호환성

이 MRC는 순수하게 추가적입니다: 새로운 애플리케이션 레이어 계약을 지정하며, 스테이킹 프리컴파일, EVM 또는 기존의 합의 또는 네트워킹 동작을 변경하지 않습니다. 하위 호환되지 않는 변경 사항을 도입하지 않습니다.

현재 오프체인 `metadata.json` 파일을 사용하는 생태계 도구는 계속 사용할 수 있습니다. 도구는 사용 가능한 경우 레지스트리에서 읽도록 마이그레이션해야 하며, 메타데이터를 아직 등록하지 않은 검증자를 위한 백업으로 오프체인 파일을 취급해야 합니다.

## 테스트 케이스

준수하는 구현은 다음과 같은 동작을 보여야 합니다:

1. 검증자의 권한으로부터 `setMetadata` 호출이 성공하고, 전체 레코드가 지속되며, 저장된 레코드와 함께 `MetadataUpdated`가 발생합니다.
2. 검증자의 현재 권한도 아니고 구현의 자체 스킴에 따라 권한이 부여되지 않은 주소로부터 `setMetadata` 호출이 되면 되돌려집니다.
3. `metadata.name == ""`인 상태로 `setMetadata`를 호출하면, 다른 모든 필드가 비어 있지 않고 호출자가 권한이 있어도 되돌려집니다.
4. `hasMetadata`가 `false`인 `validatorId`에 대해 `updateMetadataField`를 호출하면, 호출 주소와 관계없이 되돌려집니다.
5. 각 `Field` 변형에 대해 `updateMetadataField`를 호출하면 해당 필드만 업데이트되고, 다른 모든 필드는 변경되지 않으며, 전체 업데이트 후 레코드를 포함한 `MetadataUpdated`가 발생합니다.
6. `updateMetadataField(_, NAME, "")` 호출은 되돌려집니다. 다른 어떤 `field`와 빈 `value`로 호출하면 성공하고 해당 필드를 지웁니다.
7. `updateMetadataField(_, ADDITIONAL_INFO, value)` 호출은 `additionalInfo`에 `value`를 그대로 저장하며, 레지스트리에 의해 JSON 검증이 수행되지 않습니다.
8. 검증자를 위한 스테이킹 프리컴파일의 권한이 `A`에서 `B`로 회전한 후, `B`의 쓰기가 레지스트리에 대한 어떤 조치도 요구하지 않고 성공하여 권한이 실시간으로 해결됨을 보여줍니다.
9. `hasMetadata(id)`는 한 번도 기록되지 않은 어떤 `id`에 대해서는 `false`를 반환하고, 성공적인 `setMetadata` 후에는 `true`를 반환합니다.
10. `STAKING_PRECOMPILE()`는 `0x0000000000000000000000000000000000001000`을 반환합니다.

## 참조 구현

규범적 아티팩트