본문으로 건너뛰기

EOA Paymaster

개요​

EOA 기반 Paymaster​

이 문서는 EIP-4337에 정의된 Paymaster와는 달리 외부 소유 계정(EOA) 지갑을 위해 특별히 설계된 Paymaster 솔루션을 소개합니다. 최소한의 수정만으로 지갑은 이 솔루션을 통합하여 가스비 후원을 지원하고 사용자 경험을 크게 향상시킬 수 있습니다.

EOA 기반 Paymaster란?​

EIP-4337(진입점 계약 사양을 통한 계정 추상화)의 Paymaster는 Ethereum 거래의 유연성과 사용자 경험을 향상시키기 위해 설계된 중요한 구성 요소입니다. 이를 통해 제3자가 사용자의 거래 수수료를 지불할 수 있으므로 사용자가 가스 비용을 지불하기 위해 ETH를 보유할 필요가 없습니다.

EIP-4337은 스마트 계약 지갑을 위한 혁신적인 Paymaster 개념을 도입했지만 Ethereum 생태계의 상당 부분은 여전히 ​​EOAs에 의존하고 있습니다. 이를 인식하여 EOA 지갑을 위해 특별히 설계된 획기적인 Paymaster 솔루션을 제시합니다. 이 혁신은 스마트 계약 지갑으로 전환하지 않고도 거래 후원 및 향상된 사용자 경험의 이점을 더 넓은 BOT Chain 사용자 기반에 제공합니다. EOA Paymaster 솔루션은 후원 거래에 대한 액세스를 민주화하여 수백만 명의 기존 EOA 지갑 사용자에게 블록체인 상호 작용을 보다 사용자 친화적이고 비용 효율적으로 만드는 것을 목표로 합니다.

작동 원리​

트랜잭션 처리에 상당한 변화가 발생합니다.

  1. 검증인 역할: 검증인은 더 이상 블록 내의 개별 거래 가스 가격을 확인하지 않습니다.

  2. 트랜잭션 번들링: 개인 트랜잭션은 번들로 그룹화되어 빌더에 제출됩니다.

  3. 우선순위: 빌더는 각 번들의 총 가스 가격을 기준으로 우선순위를 지정합니다.

  4. 번들 내 유연성: 단일 번들 내에서 가스 가격은 다양할 수 있으므로 수수료가 없는 거래와 수수료가 높은 거래가 공존할 수 있습니다.

이러한 유연성은 후원 ​​가스 요금 및 가스 없는 거래와 같은 혁신적인 기능을 가능하게 합니다.

정의​

번들: 원자적으로 실행되는 정렬된 트랜잭션 배열로, 번들의 모든 트랜잭션이 함께 처리되거나 전혀 처리되지 않도록 합니다.

빌더(Builder): 블록 구축을 담당하는 MEV 공급망의 새로운 이해관계자입니다. 빌더는 트랜잭션 번들, 퍼블릭 txpool의 개별 트랜잭션, 프라이빗 트랜잭션 순서를 제안된 블록으로 패키지화합니다.

제안자: 여러 빌더의 블록체인 포함 제안 중에서 가장 수익성이 높은 블록을 선택하는 검증인입니다.

Paymaster: 거래 후원을 가능하게 하는 인프라 구성 요소로, 자체 또는 제3자가 가스 요금을 부담할 수 있습니다.

후원자 정책: 후원 자격을 갖춘 거래를 결정하기 위해 가스 후원자가 정의한 일련의 규칙입니다. 여기에는 허용된 거래 발신자 또는 특정 거래 유형과 같은 기준이 포함될 수 있습니다.

전반적인 작업 흐름​

가스 후원 프로세스에는 몇 가지 주요 구성 요소와 단계가 포함됩니다.

  1. 사용자 시작:

    • 사용자는 호환 가능한 지갑을 사용하여 거래를 준비합니다.

    • 지갑은 잠재적으로 후원받는 거래에 대해 가스 가격을 0으로 설정합니다.

  2. Paymaster 제출:

    • 지갑은 가스 가격이 없는 거래를 Paymaster에게 제출합니다.

  3. 스폰서 정책 확인:

    • Paymaster는 기존 스폰서 정책과 비교하여 거래를 확인합니다.

    • 정책에는 보낸 사람/받는 사람 주소, 토큰 유형 또는 거래 한도와 같은 기준이 포함될 수 있습니다.

  4. 후원 처리:

    • 거래가 후원 대상인 경우: a. Paymaster는 더 높은 가스 가격으로 스폰서 거래를 생성합니다. 비. 원래 사용자 거래와 스폰서 거래가 하나의 번들로 결합됩니다.

    • 자격이 없는 경우 거래가 거부되거나 정상적인 처리를 위해 사용자에게 반환됩니다.

  5. 번들 생성 및 제출:

    • 이 번들은 여러 MEV 빌더에 제출되었습니다.

  6. 빌더 선택 및 블록 제안:

    • MEV 빌더는 번들을 블록 제안에 통합합니다.

  7. 블록체인 포함:

    • 제안자(검증자)는 빌더의 제안 중에서 가장 수익성이 높은 블록을 선택합니다.

    • 사용자의 원래 거래와 후원자의 거래가 모두 포함된 선택된 블록이 블록체인에 추가됩니다.

    • 이는 두 트랜잭션의 원자성 실행을 보장합니다.

  8. 거래 후 처리:

    • Paymaster Manager는 스폰서 가스에 대한 적절한 금액을 공제하여 스폰서 계정을 업데이트합니다.

이 솔루션은 기존 지갑 인프라를 크게 변경하지 않고도 원활한 가스 후원을 가능하게 합니다. 블록체인 네트워크의 보안과 무결성을 유지하면서 다양한 후원 모델을 수용할 수 있는 유연한 시스템을 제공합니다.

Paymaster 인프라​

앱이나 지갑에서 가스 없는 환경을 구현할 준비가 되셨나요? 다음은 BOT Chain에서 사용할 수 있는 Paymaster 인프라에 대한 유용한 정보입니다.

  • Nodereal. Nodereal에 의해 구동되는 MegaFuel는 EOA 지갑에 대한 BOT Chain Paymaster를 기반으로 한 Paymaster 구현입니다. 최소한의 수정만으로 지갑은 MegaFuel를 통합하여 가스비 후원을 지원하여 사용자 경험을 크게 향상시킬 수 있습니다. 동시에 스폰서는 MegaFuel에서 스폰서십을 맞춤화하여 스폰서 사용자가 가스 없이 거래를 보낼 수 있도록 할 수 있습니다.

Paymaster API 사양​

광범위한 채택을 촉진하고 다양한 지갑 구현 전반에 걸쳐 상호 운용성을 보장하려면 Paymaster를 위한 표준화된 인터페이스 사양 세트를 설정하는 것이 중요합니다. 이 표준화를 통해 지갑 개발자는 사용하기로 선택한 특정 Paymaster 서비스에 관계없이 가스 후원 기능을 효율적이고 일관되게 통합할 수 있습니다.

API 사양​

Paymaster는 스폰서 및 정책 정보를 지갑에 반환할 수 있도록 pm_isSponsorable라는 JSON-RPC API를 구현해야 합니다. Paymaster는 또한 eth_sendRawTransaction JSON-RPC API를 구현해야 합니다. API 세부 스펙은 아래와 같이 정의됩니다.

pm_isSponsorable​

요청 매개변수

  • jsonrpc: JSON-RPC 프로토콜 버전("2.0").

  • id: 요청의 고유 식별자입니다(이 예에서는 1).

  • method: 호출할 메소드 이름("pm_isSponsorable").

  • params: 다음 필드가 포함된 단일 객체를 포함하는 배열입니다.

    • to: 거래의 수신자 주소입니다.

    • from: 거래의 보낸 사람 주소입니다.

    • value: 거래 금액(16진수)입니다.

    • data: 거래에 대한 추가 데이터(16진수)입니다.

    • gas: 트랜잭션의 가스 한도(16진수)입니다.

예:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "pm_isSponsorable",
  "params": [
    {
      "to": "0x...", // an address
      "from": "0x...", // an address"value": "0xa1",
      "data": "0x",
      "value": "0x1b4",
      "gas" : "0x101b4"
    }
  ]
}

응답 필드

  • jsonrpc: JSON-RPC 프로토콜 버전("2.0").

  • id: 요청의 고유 식별자(이 예에서는 1)입니다.

  • result: 후원 정책 세부정보가 포함된 개체:

    • (필수) Sponsorable: 거래가 후원되는지 여부(참 또는 거짓)를 나타내는 부울입니다.

    • (필수) SponsorPolicy:. 스폰서 정책의 이름입니다.

예:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "Sponsorable": true,
    "SponsorPolicy": "a sample policy name"
  }
}
eth_sendrawtransaction​

Paymaster가 구현한 eth_sendrawtransaction API는 이 Ethereum API 사양을 따라야 합니다. 클라이언트는 eth_sendrawtransaction API를 통해 새로운 메시지 호출 트랜잭션을 생성하거나 서명된 트랜잭션에 대한 계약 생성을 생성할 수 있습니다.

요청 매개변수

params에는 서명된 거래 데이터가 포함되어야 합니다.

예:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_sendRawTransaction",
  "params": [
    "0x02f86a6102850df8475800850df84758000a94cd9c02358c223a3e788c0b9d94b98d434c7aa0f18080c080a0bcb0e8ffa344e4b855c6e13ee9e4e5d22cff6ad8bd1145a93b93c5d332100c2ca03765236eba5fbb357e35014fd19ba4b3c6b87f3793bd14dddf7913fc8dcc88bf"
  ]
}

응답 필드

DATA, 32바이트 - 트랜잭션 해시입니다.

예:

{
  "id": 1,
  "jsonrpc": "2.0",
  "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331"
}

지갑 통합​

이 가이드는 지갑 개발자가 Paymaster 서비스를 통합하여 사용자를 위한 가스 수수료 후원을 활성화하는 단계를 간략하게 설명합니다. 이러한 표준을 따르면 지갑은 여러 Paymaster 제공업체에 걸쳐 원활하고 가스 없는 거래를 제공할 수 있습니다.

상호작용 워크플로​

지갑, Paymaster, 블록체인 간 EOA Paymaster 상호작용 워크플로

통합에는 Paymaster 서비스와 상호 작용하기 위해 거래 생성 및 전송 프로세스를 수정하는 작업이 포함됩니다.

주요 단계는 다음과 같습니다.

  1. 거래 준비:

    • 사용자가 거래를 시작하면 먼저 gm_sponsorable에 전화하여 후원 자격이 있는지 확인하세요.

    • 후원이 가능한 경우 거래 가스 가격을 0으로 설정하세요.

  2. 사용자 알림:

    • 거래는 가스가 없으며 API에서 반환된 "정책 이름"으로 후원된다는 점을 사용자에게 알립니다.

  3. 거래 서명:

    • 사용자가 가스 가격이 없는 거래에 서명하도록 합니다.

  4. Paymaster에 제출:

    • eth_sendRawTransaction을 사용하여 서명된 거래를 Paymaster에게 보냅니다.

  5. 응답 처리:

    • Paymaster의 응답을 처리합니다.

      • 성공하면 사용자에게 거래가 제출되었음을 알립니다.

      • 실패할 경우 일반 트랜잭션 처리로 돌아가거나 사용자에게 실패를 알리는 것을 고려하세요.

  6. 거래 모니터링:

    • 평소대로 거래 상태를 모니터링하세요.

모범 사례​

  1. 가스 가격을 수정하기 전에 항상 후원 여부를 확인하세요.

  2. 후원 상태에 대한 명확한 사용자 피드백을 제공합니다.

  3. 후원이 실패하는 경우 적절한 오류 처리를 구현합니다.

  4. 비후원 거래에 대한 대체 메커니즘을 고려하십시오.

가스리스 거래를 시도해보세요​

주류 지갑에서 Paymaster를 경험해 보세요​

여러 주류 암호화폐 지갑이 이미 Paymaster 통합을 구현했습니다. 이 튜토리얼은 가스 없는 거래를 Paymaster 통합 지갑으로 보내는 경험을 안내합니다.

Paymaster 통합 지갑​

Paymaster 기능이 통합된 지갑은 사용자에게 원활한 경험을 제공합니다. 이 지갑은 거래가 후원 대상인지 여부를 자동으로 감지합니다. 거래가 자격을 갖추면 지갑은 사용자 개입 없이 가스 가격을 0으로 설정합니다.

이를 설명하기 위해 BOT Chain에서 스테이블 코인을 전송하는 과정을 살펴보겠습니다.