ERC7638 - 크로스체인 전송 규격

1. 프로토콜에 대해여

EIP 문서 : https://eips.ethereum.org/EIPS/eip-7683

ERC-7683: Cross Chain Intents

유니스왑과 Across 가 만든 Defi의 크로스 체인 전송 프로토콜.

체인이 매우 많아지고 각 체인간 전송 프로토콜 규격이 다르기 때문에 실패확률이나 UX가 현저히 높아지는 것이 현실. 이에 대한 대안으로 공통 규격을 제안한 것.

결국 영향력 있는 회사들이 만든 프로토콜이며 ERC로도 돌라와서 통합 규격이 될 경우 크로스체인 관련 브릿지/메세지 프로토콜을 만들 때 해당 규격을 적용해야 할 필요성이 존재한다.

https://x.com/AcrossProtocol/status/1778434193288249636 
EIP 7638 - Forum

X의 Across님(@AcrossProtocol)

https://ethereum-magicians.org/t/erc-7683-cross-chain-intents-standard/19619

ERC-7683: Cross Chain Intents Standard

2. 프로토콜 분석

1. 규격 조건

먼저 크로스체인 메세징을 할때 CrossChainOrder를 ABI로 지원할 수 있는 형태로 남겨야 한다.

/// @title CrossChainOrder type
/// @notice Standard order struct to be signed by swappers, disseminated to fillers, and submitted to settlement contracts
struct CrossChainOrder {
	/// @dev The contract address that the order is meant to be settled by.
	/// Fillers send this order to this contract address on the origin chain
	address settlementContract;
	/// @dev The address of the user who is initiating the swap,
	/// whose input tokens will be taken and escrowed
	address swapper;
	/// @dev Nonce to be used as replay protection for the order
	uint256 nonce;
	/// @dev The chainId of the origin chain
	uint32 originChainId;
	/// @dev The timestamp by which the order must be initiated
	uint32 initiateDeadline;
	/// @dev The timestamp by which the order must be filled on the destination chain
	uint32 fillDeadline;
	/// @dev Arbitrary implementation-specific data
	/// Can be used to define tokens, amounts, destination chains, fees, settlement parameters,
	/// or any other order-type specific information
	bytes orderData;
}

크로스체인 메세징을 할 때 주문이 ResolvedCrossChainOrder 구조체로 컨버트 가능하게 만들어야 한다.

/// @title ResolvedCrossChainOrder type
/// @notice An implementation-generic representation of an order
/// @dev Defines all requirements for filling an order by unbundling the implementation-specific orderData.
/// @dev Intended to improve integration generalization by allowing fillers to compute the exact input and output information of any order
struct ResolvedCrossChainOrder {
	/// @dev The contract address that the order is meant to be settled by.
	address settlementContract;
	/// @dev The address of the user who is initiating the swap
	address swapper;
	/// @dev Nonce to be used as replay protection for the order
	uint256 nonce;
	/// @dev The chainId of the origin chain
	uint32 originChainId;
	/// @dev The timestamp by which the order must be initiated
	uint32 initiateDeadline;
	/// @dev The timestamp by which the order must be filled on the destination chain(s)
	uint32 fillDeadline;

	/// @dev The inputs to be taken from the swapper as part of order initiation
	Input[] swapperInputs;
	/// @dev The outputs to be given to the swapper as part of order fulfillment
	Output[] swapperOutputs;
	/// @dev The outputs to be given to the filler as part of order settlement
	Output[] fillerOutputs;
}

/// @notice Tokens sent by the swapper as inputs to the order
struct Input {
	/// @dev The address of the ERC20 token on the origin chain
	address token;
	/// @dev The amount of the token to be sent
	uint256 amount;
}

/// @notice Tokens that must be receive for a valid order fulfillment
struct Output {
	/// @dev The address of the ERC20 token on the destination chain
	/// @dev address(0) used as a sentinel for the native token
	address token;
	/// @dev The amount of the token to be sent
	uint256 amount;
	/// @dev The address to receive the output tokens
	address recipient;
	/// @dev The destination chain for this output
	uint32 chainId;
}

settlement 컨트렉트 주소에 해당하는 컨트렉트의 경우 다음 인터페이스를 상속해야 한다.

/// @title ISettlementContract
/// @notice Standard interface for settlement contracts
interface ISettlementContract {
	/// @notice Initiates the settlement of a cross-chain order
	/// @dev To be called by the filler
	/// @param order The CrossChainOrder definition
	/// @param signature The swapper's signature over the order
	/// @param fillerData Any filler-defined data required by the settler
	function initiate(CrossChainOrder order, bytes signature, bytes fillerData) external;

	/// @notice Resolves a specific CrossChainOrder into a generic ResolvedCrossChainOrder
	/// @dev Intended to improve standardized integration of various order types and settlement contracts
	/// @param order The CrossChainOrder definition
	/// @param fillerData Any filler-defined data required by the settler
	/// @returns ResolvedCrossChainOrder hydrated order data including the inputs and outputs of the order
	function resolve(CrossChainOrder order, bytes fillerData) external view returns (ResolvedCrossChainOrder);
}

실제로 크로스체인 메세지의 세부 내용을 수행하는 SettlementContract가 initiate라는 함수를 통해서 CrossChainOrder라는 구조체와 구조체를 서명한 값인 signature, 메세지의 세부 데이터인 fillerData 이렇게 3가지를 넣고 함수를 실행하면 이벤트를 남기면서 반대쪽 체인에 기록을 넘기게 되고 여기에 대해서 누구나 디코딩이 가능하도록 resolve라는 view 함수를 만들어서 CrossChainOrder라는 구조체와 bytes로 fillerData를 넣어주면 해당 데이터로부터 ReslovedCrossChainData 구조체를 뽑아내는 식으로 구현해 주면된다.

2. 규격 조건 설명

일반 주문 데이터
핵심적인 고려 사항은 광범위한 크로스체인 인텐트 설계가 동일한 표준 내에서 작동할 수 있도록 하는 것입니다. 이를 위해 사양은 표준 크로스 체인 인텐트 흐름을 중심으로 설계되었으며, 해당 흐름 내에서 다양한 구현 세부 사항을 허용합니다.

표준 크로스체인 인텐트 흐름:

스와퍼가 주문의 매개변수를 정의하는 오프체인 메시지에 서명합니다.
주문이 필러에게 전달됩니다.
필러가 오리진 체인에서 거래를 개시합니다.
필러가 목적지 체인에서 주문을 체결합니다.
주문을 정산하기 위해 크로스 체인 정산 프로세스가 진행됩니다.

이 흐름 내에서 표준 구현자는 다음과 같은 동작을 사용자 지정할 수 있는 설계 유연성을 갖습니다:

가격 해결(예: 더치 경매 또는 오라클 기반 가격 책정)
주문 처리 제약 조건
정산 절차.

 

주문데이터 필드를 사용하면 통합자가 주문의 기본 필드를 구문 분석할 수 있는 동시에 구현에서 이러한 동작에 대한 임의의 사양을 사용할 수 있습니다.

이 기능은 또한 해결 보기 함수와 ResolvedCrossChainOrder 유형의 동기를 부여했습니다. 해석을 통해 통합 필러는 주문 데이터 필드에 대한 구체적인 지식 없이도 주문을 검증하고 평가할 수 있습니다.

 

주문데이터 필드를 사용하면 통합자가 주문의 기본 필드를 구문 분석할 수 있는 동시에 구현에서 이러한 동작에 대한 임의의 사양을 사용할 수 있습니다.

 

=> ResolvedCrossChainOrder : 원래 크로스체인 데이터 가 bytes로 저장되면 분석하기 어렵기 때문에 (백엔드 등에서 따로 다시 원본으로 바꾸어 주어야한다.) 이를 다시 원래대로 해석하기 위해 주문 데이터 필드를 분석할 수 있도록 만든 구조체이다.

Permit2 사용 (옵션):

Permit2는 이 표준에서 특별히 요구하지는 않지만, 표준을 준수하는 프로토콜을 구축하기 위한 효율적이고 간단한 접근 방식을 제공합니다. 특히 Permit2의 감시 기능을 통해 스와퍼는 단일 서명으로 토큰 전송과 주문 자체를 모두 승인할 수 있습니다. 이는 또한 토큰 전송과 주문의 성공적인 시작을 훌륭하게 결합합니다.

반면 표준 승인 모델에서는 토큰 승인(ERC-2612 또는 온체인)과 스왑 조건을 승인하는 서명, 두 가지 서명이 별도로 필요합니다. 또한 토큰 승인과 스왑을 분리하므로 버그가 있거나 신뢰할 수 없는 결제자 계약으로 인해 승인된 토큰이 언제든 탈취될 수 있습니다.

Permit2를 중심으로 표준을 준수하는 정산자 시스템을 구축할 때는 다음과 같은 사항을 고려해야 합니다.

주문 구조의 논스는 Permit2 논스여야 합니다.
주문 구조의 개시 마감일은 허가Permit2 마감일이어야 합니다.
파싱된 orderData를 포함한 전체 주문 구조가 permit2 호출 중에 감시 유형으로 사용되어야 합니다. 이렇게 하면 스와퍼가 주문 허가에 서명할 때 투명성을 최대한 보장할 수 있습니다.

3. 활용

아직까지 해당 표준에 대한 구현체는 찾을 수 없어서 직접 구현을 해보았다.

기존 브릿지 구조에서 메세지 규격 정도만 맞춰주는 정도이지만 문제는 구조체 형태를 이벤트로 남기게 되면 용량에 제한이 있고, 그렇다고 매핑으로 데이터를 넣어두면 가스비가 너무 많이 발생하는 문제가 있었다.

따라서 아래 예제를 참고하여 encode, decode를 통해서 구조체 자체의 요소들을 bytes로 남기고 이를 이벤트로 남기는 식으로 기존 이벤트 emit 브릿지 형태에서 적용가능하게 설계하였으며 Settlement에서는 리턴 함수를 통하여서 해당 bytes에 대한 resolve를 구현하는식으로 설계하였다.

https://solidity-by-example.org/abi-decode/

Solidity by Example