Legal Oracle

mechanism compliance

정책 엔진을 직접 수정하지 않고도 PCL의 규칙을 최신 규제에 맞게 유지하는 파라미터 공급원입니다.

규제는 변합니다. Travel Rule 임계 금액이 바뀌고, 제재 리스트가 갱신되고, 관할권 규칙이 진화합니다. 마루는 정책 엔진 (PCL — 안정적, 거의 변하지 않음)과 파라미터 공급 (Legal Oracle — 법·정책 변화에 따라 갱신)을 분리합니다. 새로운 규제 요구는 파라미터 추가로 — 길어야 새 PolicyTemplate 등록으로 — 흡수되며, 체인 코어 코드는 건드리지 않습니다. 마루 테스트넷에서는 이 파라미터, 즉 전역 정책 설정을 PCL 정책 관리자라는 단일 계정이 설정하며, 어떤 계정이 정책 관리자인지를 포함한 모듈 파라미터는 거버넌스가 관리합니다. 모든 변경은 온체인 트랜잭션이므로 공개되고 감사할 수 있습니다.

Legal Oracle를 통과하는 것

Legal Oracle 입력은 파라미터이지 코드가 아닙니다. 구체적으로 다음을 공급합니다.

  • DENYLIST_POLICY의 갱신된 denylist를 공급합니다 (제재 리스트 추가·제거).
  • VOLUME_POLICY의 새 maxLimit / minLimit 값을 공급합니다.
  • PERIODIC_VOLUME_POLICY의 새 기간 정의와 한도를 공급합니다.
  • EAS_POLICY의 새 schema UID를 공급합니다 (예: 새 KYC 계층이 출시되는 경우).
  • 새로 등록된 정책 템플릿의 새 파라미터를 공급합니다.


공급하지 않는 것: 새 정책 로직(네트워크 업그레이드가 필요한 영역), 사용자 개인 데이터, 표준 PCL 평가 파이프라인을 우회하는 모든 것은 Legal Oracle 범위 밖입니다.

권한과 키 관리

마루 테스트넷에서 PCL이 강제하는 체인 전역 파라미터, 즉 전역 정책 설정과 등록된 템플릿은 PCL 정책 관리자(IPcl.policyAdmin())라는 단일 계정이 PCL 프리컴파일을 통해 설정합니다. 컨트랙트별 정책은 각 컨트랙트의 컨트랙트 정책 admin이 설정하며, 이 계정은 자신이 그 admin인 경우에만 바꿀 수 있습니다. 마루 테스트넷에서는 Privacy 프리컴파일의 컨트랙트 정책 admin이 이 계정입니다. 거버넌스는 어떤 계정이 정책 관리자인지를 포함한 x/pcl 모듈 파라미터를 관리하므로 그 키를 교체할 수 있습니다. dApp 빌더 입장에서 중요한 점은 모든 변경이 타임스탬프와 함께 기록되는 온체인 트랜잭션이어서 빌더가 이를 모니터링할 수 있다는 것입니다. 키 관리 흐름의 세부 사항은 dApp 표면 영역 밖에 있습니다.

이 분리가 개발자에게 중요한 이유

마루 위에서 빌드한다면 Legal Oracle은 대체로 보이지 않습니다. 트랜잭션은 현재 활성 파라미터를 사용해 PCL이 평가합니다. 중요한 이유는 다음과 같습니다.

1. 정책은 정적이지 않습니다. dapp이 의존하는 VOLUME_POLICY의 maxLimit은 PCL 정책 관리자가 새 전역 정책 설정을 게시하면(setGlobalPolicies) 바뀔 수 있습니다. UI에 파라미터 값을 하드코딩하지 말고 체인에서 쿼리합니다(또는 구체 금액은 eth_estimateGas로 트랜잭션을 시뮬레이션해 테스트합니다. 정책이 거절하면 PCL ReasonCode로 revert됩니다. m-aws policy.preflight는 PCL 정책을 평가하지 않으며, 에이전트 자체의 지출 한도와 허용 대상을 오프체인에서 확인합니다).
2. 컴플라이언스 요구사항은 계속 바뀝니다. 오늘 적용되지 않는 규정이 내일 적용될 수 있습니다. PCL 위에서 개발하면 체인의 컴플라이언스 상태가 변화할 때마다 자동으로 반영되며, 모든 규제 변화를 직접 추적할 필요가 없습니다.
3. 감사와 예측 가능성이 보장됩니다. 파라미터 변경은 온체인 트랜잭션이므로 공개되고 날짜가 기록됩니다. 다른 온체인 상태와 같은 수준으로 감사 가능하기 때문에, "블록 N 시점에 효력 있던 규칙"을 추론할 수 있습니다.
ESC
검색어를 입력하세요