이더리움 메타 트랜잭션에 대한 공통 표준 탐색

편집자 주: 이 기사의 출처:이더리움 애호가(ID: ethfans)편집자 주: 이 기사의 출처:

이더리움 애호가(ID: ethfans)

이 기사는 Gitcoin에서 메타 트랜잭션을 일반화하려는 Metamask의 경쟁에 대한 Bloxis의 답변입니다. 이 기능을 곧 출시될 제품에 통합할 계획이므로 이 분야에 많은 시간과 노력을 투자했으며 따라서 이 분야에 대한 논의에 꼭 참여할 수 있기를 바랍니다. 내 견해에 이의가 있는 경우 지적해 주시면 기꺼이 논의하겠습니다.

소개

- 출처 : 깃코인 -

소개

기꺼이 돈을 쓸 의향이 있는 한 거의 완벽하게 분산된 보더리스 블록체인 네트워크에서 이더리움 트랜잭션의 모든 작업(가스 한도를 초과하지 않음)을 수행할 수 있습니다. 아주 멋지지 않나요? 그게 진실이야. 하지만! 문제는 트랜잭션을 실행하는 데 Gas가 필요하고 Gas는 이더리움으로 지불되지만 누가 새로운 사용자를 위해 이더리움을 가지고 있습니까? (뭐? 사이버펑크, 코인 사재기 파티, MLM 조직이 있다고 했지? 자, 보통 사람들이 아니야)

이미지 설명

- 이미지 출처: 이 이모티콘 패키지는 저만의 P: ) -

DeFi, 블록체인 게임 및 dApp 생태계의 미래는 시장에 진입하는 플레이어의 규모에 달려 있습니다. 이는 신규 플레이어의 온보딩 문제를 해결하고 안전한 운영을 위해 지식 임계값을 낮춰야 함을 의미합니다. 현재 두 가지 주요 문제는 플레이어가 시작하려면 디지털 지갑과 약간의 에테르가 필요하다는 것입니다. 이는 업계의 많은 사람들이 극복하기 위해 열심히 노력하고 있는 것입니다.

메타트랜잭션이 등장하기 전에는 위의 서비스를 완료하기 위해 자금을 미리 예치해야 했습니다. Uport의 Lambda Sensui는 이와 관련하여 일반적인 애플리케이션입니다.

성취하다

메타 트랜잭션에 대해 자세히 알아보려면 다음 기사를 읽을 수 있습니다. 저자는 커뮤니티의 벤치마크인 Austin Griffith입니다.

이더리움 메타 트랜잭션: 이더리움 대중화의 장벽 낮추기(편집자 주: 중국어 번역은 기사 끝 부분 참조)

성취하다

온체인에서 메타 트랜잭션을 구현하려면 원래 보낸 사람이 보낸 트랜잭션 데이터를 인코딩하는 인코딩 표준이 필요합니다. 그래야 대상 계약이 msg.sender(즉, 중계자)의 영향을 받지 않고 서명과 데이터를 복구할 수 있습니다. 그러나 오프체인 최종 사용자는 API 또는 통신 프로토콜을 통해 릴레이어와 연결되어야 합니다. 그리고 중계자 자체에는 메타 트랜잭션을 가져오고 전달하기 위한 약간의 에테르와 인프라가 있어야 합니다.

Dai의 ERC-20 토큰 계약에 사용된 permit() 메서드와 같이 체인의 문제를 우아하게 해결하는 특정 시나리오에 매우 적합한 솔루션 - 이는 직접 제출해야 하는 일종의 문제입니다. 최종 사용자 승인 방법. 또한 이 접근 방식은 온체인 사용을 위한 메시지 데이터를 표현하고 서명하기 위한 표준인 EIP-712를 구현합니다. 다이는 이 솔루션을 사용하여 다른 모든 사용 사례(Dai 전송 및 DeFi 운영 조정 등)를 구현할 수 있기 때문에 이 메타 트랜잭션 하나만 지원하면 됩니다.

계약 지갑

Dapper Labs, Gnosis 및 Argent와 같은 여러 조직에서 사용자 경험과 보안의 균형을 맞추는 것을 목표로 하는 계약 지갑을 출시하고 있습니다. 컨트랙트 지갑은 스마트 컨트랙트에서 사용자의 자금을 호스팅하며 컨트랙트에서 거래를 전송하고 계정 보안을 보호하는 기능은 이더리움 프로토콜 자체의 수준을 훨씬 능가할 수 있습니다.

이미지 설명

- 출처 : Dapper Labs -

이 접근 방식을 사용하면 계정에 Ether가 없어도 트랜잭션을 보낼 수 있으며 업계에서 동일한 표준을 수락할 필요가 없습니다. 계약 지갑은 외부 소유자 계정(즉, 표준 키로 제어되는 일반 사용자 주소)과 같을 수 있습니다. 쌍, EOA) 다른 계약을 호출합니다. 또한 Authereum의 트랜잭션 방화벽과 같은 일련의 보안 기능도 제공합니다.

이미지 설명

- 출처: 오더리움 -

계약 지갑이 가져온 문제

Ethereum Naming Service (ENS)와 같은 계약 지갑 및 혁신에 대해 Ethereum 커뮤니티 내에서 많은 소문이 있습니다. 그러나 많은 사용자가 모든 온체인 활동에 대한 ID로 ENS 도메인을 사용하고(및 도메인의 읽을 수 있는 부분에 실제 이름을 사용) 엄청난 개인 정보 보호 및 보안 문제가 발생했습니다.

이더리움 지갑 주소 자체는 "의사 익명"(따라서 다소 비공개)이지만 많은 지갑 소프트웨어 제공업체는 이제 사용자에게 결과를 알리지 않고 ENS 주소를 얻도록 권장하고 있습니다. 즉, 이더리움 계정의 거래 기록(투자 포트폴리오 및 dApp과의 상호 작용 기록 포함)은 체인에 공개되며 주소가 ENS 도메인 이름을 등록한 후 이러한 거래 활동은 이 ENS 도메인 이름과 연결됩니다. 사용자가 등록한 ENS 이름은 사용자가 다른 서비스나 실생활에서 이미 사용하고 있는 이름일 가능성이 높습니다. 이것이 제가 ENS를 계약 지갑 주소(개인용)에 바인딩하는 것에 대해 회의적인 주된 이유입니다.

그러나 나는 사기를 방지하기 위해 스마트 계약을 식별하고 투명한 운영의 혜택을 받을 수 있는 조직을 위해 ENS를 사용하는 계약 지갑/멀티시그 지갑을 지지합니다 🙌

Hierarchical Deterministic Wallet(줄여서 HD 지갑)을 통해 사용자는 단일 개인 키를 사용하여 여러 EOA 주소를 생성하여 다양한 자산을 저장할 수 있습니다. 다수의 거래를 처리하며 여전히 어느 정도의 익명성을 유지합니다. 이 규칙 집합을 사용하여 사용자는 개인 키를 하나만 보유하고 상호 작용에 사용할 각 dApp 및 토큰에 대한 EOA 주소를 생성할 수도 있습니다. 컨트랙트 월렛으로도 가능하지만 가스 수수료가 존재하기 때문에 사용자가 사용하는 각 dApp/토큰에 대한 컨트랙트 월렛을 생성하는 것은 비용이 많이 들고 비실용적입니다. 가스 요금을 고려하지 않더라도 네트워크 정체가 발생합니다.

이미지 설명

- 계층적 결정론적 지갑은 그 자체로 프라이버시 솔루션이며 이더리움 지갑에도 적용됩니다. 출처: 카사-

이더리움 생태계의 모든 사용자가 그들과 상호 작용하는 각 dApp에 해당하는 계약 지갑을 가지고 있다고 가정하면 메타 트랜잭션 기능을 사용하고 개인 정보를 보호할 수 있습니다. 그러면 스마트 계약이 공통 표준을 채택하는 것이 더 합리적일 것입니다. .

보편적인 표준을 향하여

계약 기반 및 계약 지갑 기반 솔루션에 대한 귀하의 입장이 무엇이든 현재로서는 명확한 표준이 없습니다. 메서드 호출은 계약마다 다르고 트랜잭션을 전달하는 시스템도 다릅니다. 주유소 네트워크는 기본 작업을 많이 수행했지만 여전히 유연성이 충분하지 않습니다. 수취인 계약은 가스 요금을 지불하지 않을 수 있습니다. 그렇다면 사용자는 자신의 자산을 사용하여 릴레이어에게 어떻게 지불할까요? 상대방이 이 거래에 대한 가스비를 지불하게 하려면 어떻게 해야 합니까? 이러한 질문은 메타 트랜잭션을 일반화하려는 경쟁에서 해결하고자 하는 질문입니다. 정말 가치 있는 제안은 이러한 질문에 직면합니다.

• 우리가 제안한 아이디어를 바탕으로 법률 고문 Vincent는 dApp 개발자가 사용자가 가스 요금을 지불할 자금을 미리 예치하고 사용자가 법정 통화로 교환할 수 있도록 하는 아이디어를 제안했습니다. 에테르는 dApp 내부에서만 사용할 수 있습니다. 이것이 우리가 미래의 일반화된 메타트랜잭션 표준에서 지원하고자 하는 메커니즘입니다. Gas Station Network는 acceptRelayedCall() 메서드의 사용자 정의 구현으로 이 아이디어를 지원합니다.

• 또한 Relayer가 트랜잭션을 일괄 처리하도록 허용하면 가스 요금도 절감됩니까?

• 대체 중계자 상환/지불 방법을 지원하기 위한 메커니즘 마련

자산 dApp 및 DeFi에 대한 스마트 계약에서 실행하기에 적합한 방법(계약 지갑 표준이 아님)

대상 계약 또는 트랜잭션 릴레이에 사용되는 계약 내에서 트랜잭션 일괄 처리를 지원하는 메커니즘

ethereum/EIP-1613：Gas Station Network

ethereum/EIP-712

제안 개요

보시다시피 주유소네트워크가 제안하는 아이디어를 적극 지지합니다. RelayRecipient에서 제공하는 getSender() 및 getMessageData() 메서드는 통합 인터페이스를 구현하여 모든 계약의 메타 트랜잭션이 서로 호환되도록 합니다. 그러나 현재 형태의 이러한 접근 방식에는 피싱 및 재생 공격으로부터 보호할 수 없다는 두 가지 단점이 있습니다. 세부:

피싱을 방지하기 위해 EIP-712는 독창적인 솔루션인 도메인 이름 구분자를 제안합니다. 이 개체에는 계약의 세부 정보(사용자가 전달할 트랜잭션에 서명), 즉 주소, dApp의 이름 및 버전이 포함됩니다. 이 데이터는 서명에 포함되며 다른 모든 트랜잭션 데이터와 함께 매우 친숙한 방식으로 최종 사용자에게 제공됩니다. 이는 사용자가 트랜잭션에 서명할 수 있는 방식을 제한하여 예기치 않은 유형의 트랜잭션(예: 의도적으로 잘못된 계약으로 트랜잭션 전송)을 시작하는 것을 방지합니다.

Makerdao/dss：https://github.com/makerdao/

이미지 설명

- signTypedData_v4 메서드를 사용하여 데이터 서명을 위한 메타마스크 인터페이스. 출처: 메타마스크 -

EIP-712를 지원하는 계약은 도메인 이름 구분 기호가 계약 자체와 일치하는지 확인하고 일치하지 않으면 거래를 거부해야 합니다. 아래 나열된 Dai 계약 코드에서 이를 확인할 수 있습니다. EIP-712를 getSender() 및 getMessageData()에 통합하여 모든 메서드 호출에서 이 검사를 수행할 수 있도록 하고 싶습니다. 서명이 일치하지 않으면 트랜잭션을 거부합니다. 아래 링크를 클릭하면 이 기능에 대한 코드를 볼 수 있습니다. (죄송합니다. 기사의 임베디드 코드 형식이 제대로 표시되지 않습니다.)

또한 위의 코드에서 MakerDAO가 nonce 속성을 사용하여 재생 보호 자체를 구현하는 것을 볼 수 있습니다. 이 속성이 없으면 승인된 당사자가 트랜잭션을 재생하여 사용자의 자금을 고갈시킬 수 있습니다.

메타트랜잭션은 종종 이전 트랜잭션에 의존할 수 있는 일련의 작업의 일부입니다. 예를 들어, 우리가 구축한 개념 증명 사례에서 사용자는 xDai를 Compound 프로토콜에 입금할 수 있습니다. 메인넷에서 이것은 우리가 cDai 계약에 사용자 자금에 대한 액세스 권한을 부여한 다음 mint() 메서드를 호출하여 해당 자금을 대출 프로토콜에 예치한다는 것을 의미합니다.

사용자의 계정이 계약 지갑이 아닌 경우 이 프로세스를 완료하기 위해 일련의 작업이 필요합니다. 먼저 트랜잭션을 통해 승인()/permit() 메서드를 호출한 다음 mint() 메서드를 호출해야 합니다. 트랜잭션이 패키지됩니다. 계약 지갑을 사용하면 특수 계약 메서드를 호출하여 이러한 트랜잭션을 일괄 처리할 수 있습니다.

모든 사람이 사용할 수 있는 일반화된 메타 트랜잭션 일괄 처리 방법이 있다면 확실히 큰 혁신이 될 것입니다. 이렇게 하면 위에서 언급한 다양한 예와 마찬가지로 체인의 활동이 크게 단순화됩니다. 또한 이 방법을 사용하면 사용자가 동시에 여러 관련 없는 트랜잭션에 서명하고 전달할 수 있습니다.

그러나 경우에 따라 사용자는 단일 계약에 여러 메타 트랜잭션을 보내고자 할 수 있습니다. 예를 들어 하나의 자산만 보유하고 있는 EOA가 급여를 일괄 지급하고자 하는 경우입니다. 메타 트랜잭션을 일괄 처리하는 시스템은 이를 염두에 두고 설계해야 하며 트랜잭션이 전송되는 순서가 유지되도록 해야 합니다.

또한 일괄 처리를 통해 중계자는 사용자 서명 트랜잭션을 통해 중앙에서 수수료를 징수할 수 있습니다. 이는 ERC-20 토큰을 중계자에게 전송하거나 사용자의 대상 계약에서 수수료를 지불하도록 하는 것일 수 있습니다.

릴레이 애그리게이터는 트랜잭션 일괄 처리를 지원하고 동일한 사용자가 여러 트랜잭션을 전송하기 위해 sendRawTransactionSet() 메서드로 sendRawTransaction()을 보완해야 합니다. sendRawTransactionSetPlural() 메서드는 가스 비용을 최소화하기 위해 여러 사용자의 릴레이 일괄 처리 트랜잭션을 용이하게 하는 데에도 활용되어야 합니다.

- 출처 : 타비 -

요약하다

트랜잭션 집합의 트랜잭션으로 자금을 조달할 수 있는 경우 릴레이 애그리게이터의 현재 워크플로우를 약간만 변경하면 달성할 수 있습니다. 릴레이어는 gasPrice를 전달할 수 있으며 수수료 매개변수 acceptRelayCall()은 0으로 설정됩니다. 중계자는 트랜잭션 집합에서 트랜잭션을 지속적으로 추출하고 완료될 때까지 표준에 따라 처리할 수 있습니다.

우리가 직면한 진짜 문제는 트랜잭션을 트랜잭션 세트로 패키징하고 트랜잭션을 풀고 실행하기 위한 표준을 만드는 방법입니다(트랜잭션 원자성을 보장하면서). 트랜잭션 원자성을 보장할 수 없는 경우 릴레이어는 세트의 다른 트랜잭션을 무시하고 유료 트랜잭션만 전달하여 문제를 해결할 수 있습니다. 그게 진짜 일이야! 나는 현재 이 작업을 수행하는 방법에 대해 단서가 없지만 다음 게시물을 계속 지켜봐 주시기 바랍니다! 이것을 경쟁을 위한 실행 가능한 솔루션으로 바꿀 수 있기를 바랍니다.

요약하다