MIJI DApp Server Docs

V4 - 메타 트랜잭션(가스 대납) 지원 계획

본 문서는 Phase 4 이후 진행 예정인 메타 트랜잭션 기반 transfer/mint 대납 기능의 개발 범위를 정의합니다. 목표는 “사용자가 지갑(예: MetaMask)에서 서명만 하고, DApp 서버가 가스를 대납해 민팅/전송을 수행”하는 흐름을 구현하는 것입니다.

1. 컨트랙트 변경 사항

  1. Trusted Forwarder 활성화
    • POST /contracts/deploy 요청에 trustedForwarder 필드를 추가하거나, .env (TRUSTED_FORWARDER_ADDRESS)를 통해 기본 Forwarder 주소를 주입.
    • 템플릿 컨트랙트(MijiERC721, MijiERC1155) 배포 시 해당 주소를 constructor에 전달해 EIP-2771 context를 실제로 사용하도록 함.
  2. (선택) 전용 메타Tx 함수
    • 필요 시 gift(address from, address to, uint256 tokenId, bytes signature) 같은 wrapper 함수를 추가해 이벤트/검증을 단순화.

2. 인프라/컨트랙트 배포

  1. Trusted Forwarder 컨트랙트 배포
    • 예: OpenZeppelin MinimalForwarder.
    • 체인별로 하나씩 배포 후 주소를 .env에 등록.
  2. 키 관리
    • DApp 서버가 대납에 사용할 Relayer 키를 Secrets Manager에 저장하고, BlockchainService를 통해 signer를 가져오도록 구성.

3. 서버/API 변경

  1. 신규 API (예시)
    • POST /transfers/relay 
      {
  "chainId": "43113",
  "contractAddress": "0x...",
  "from": "0x선물자",
  "to": "0x수신자",
  "tokenId": "1",
  "signature": "<EIP-712>",
  "deadline": 1234567890
}
    • 서버는 서명을 검증한 뒤 Bull 큐(transfer-queue)에 작업을 적재.
  2. 큐/Processor
    • TransferProcessor가 blockchainService.getSigner()로 Relayer signer를 받아 Forwarder 컨트랙트를 호출.
    • 성공 시 TransferOrder 문서를 업데이트하고 Webhook/로그 발송.
  3. 기존 API 영향
    • 민팅 API는 그대로 유지하되, 메타Tx민팅이 필요하다면 별도 endpoint(POST /minting/relay)를 도입.

4. 데이터 스키마

  1. TransferOrder (신규)
    • chainId, contractAddress, from, to, tokenId, signature, status, txHash, errorMessage, createdAt, updatedAt.
  2. Metadata/Minting 도메인 영향
    • 메타Tx 민팅을 도입할 경우 MintingOrder에도 signature, relayedBy 등의 필드가 추가될 수 있음.

5. 클라이언트 연동

  1. EIP-712 서명 스펙 정의
    • 도메인: name, version, chainId, verifyingContract.
    • 타입: ForwardRequest 또는 커스텀 구조.
  2. UX 흐름
    • 사용자가 “선물/transfer” 버튼 클릭 → 프론트엔드가 서명 팝업을 띄워 서명 값 획득 → 서버로 전송 → 대납 처리.

6. 보안/검증 포인트

  1. 서명 만료(deadline) 및 nonce 관리로 재사용 공격 차단.
  2. 서버가 서명 내용을 재검증하여 조작 방지.
  3. Forwarder 호출 시 가스 상한/비용 모니터링.

위 항목들은 메타 트랜잭션 기능 구현 시 필수적으로 고려해야 할 범위를 정리한 것입니다. 실제 개발 착수 시 컨트랙트/백엔드/프론트엔드가 병행해 수정되어야 합니다.