범위 - 이더리움을 위한 동기식 구성성 프로토콜

Ellie , Luca , Florian , Ladislaus 님 , 그리고 여러 검토팀의 피드백에 감사드립니다. 피드백이 반드시 추천을 의미하는 것은 아닙니다.

SCOPE는 푸시 기반 동기식 구성성을 위한 최소 프로토콜로, 이더리움 컨트랙트와 롤업이 마치 단일 체인에 있는 것처럼 서로를 호출하고 결과를 즉시 처리할 수 있도록 합니다. 단일 원자 실행 범위 내에서 L1↔L2 및 L2↔L2의 모든 방향을 지원합니다. 최소 개념 증명은 여기에서 확인할 수 있습니다.

동기 부여

이더리움의 롤업 중심 로드맵은 보안을 유지하면서 확장성을 확보할 수 있는 방안을 제시하지만, 단편화라는 대가를 치러야 합니다. 각 롤업은 자체적인 상태, 사용자, 그리고 개발자 생태계를 갖춘 고립된 실행 환경으로 운영됩니다. 이러한 단편화는 이더리움을 처음부터 강력하게 만들었던 핵심 속성인 결합성을 약화시킵니다.

결합성은 스마트 컨트랙트가 레고 블록처럼, 즉 허가 없이, 표현력 있고, 즉각적으로 상호 작용할 수 있도록 합니다. 롤업을 통해 수평적으로 확장함에 따라, 이러한 단편화를 해소하기 위해 노력해야 합니다. 이상적인 것은 동기식 결합성(SC)입니다. 한 체인의 스마트 컨트랙트가 다른 체인의 컨트랙트를 직접 호출하고 결과를 즉시 사용할 수 있으므로, 단일 공유 블록 공간의 개발자 경험을 유지할 수 있습니다.

크로스 체인 인텐트(intent)를 위한 노력이 증가하고 있지만, 이러한 접근 방식은 토큰 전송에만 국한되는 경향이 있습니다. 결합성은 더 광범위한 목표입니다. 즉, 계약이 유동성뿐만 아니라 여러 체인에서 로직을 조정할 수 있도록 합니다. Fabric은 기반 롤업 개발을 주도하는 데 집중해 왔습니다. 롤업 간 동기식 결합성뿐 아니라, 더 중요하게는 이더리움과 롤업 간의 동기식 결합성을 고유하게 구현하기 때문입니다. 이러한 기반을 바탕으로 SCOPE(Synchronous Composability Protocol for Ethereum)는 동기식 결합성의 완전한 비전을 실현하도록 설계된 프레임워크로, 궁극적으로 이더리움의 네트워크 효과를 강화합니다.

배경

동기적 결합성은 한 체인의 계약이 다른 체인의 함수를 호출하고 동일한 실행 컨텍스트(예: 단일 L1 슬롯) 내에서 결과를 즉시 수신하고 처리할 수 있도록 하는 속성입니다. 중요한 것은 크로스 체인 상호작용이 원자적이어야 한다는 것입니다. 즉, 양쪽 모두 성공하거나 둘 다 성공하지 못합니다.

두 가지 주목할 만한 디자인은 원자 동기식 구성 가능성을 보여주었습니다.

• CIRC (Coordinated Inter-Rollup Communication)는 롤업 간의 효율적이고 검증 가능한 메시징을 위한 메일박스 기반 프레임워크를 도입했습니다. CIRC는 풀 기반 설계로, 한 체인의 계약은 다른 체인에서 전송된 메시지를 검사하고 해당 메시지에 따라 실행 조건을 지정할 수 있습니다. 그러나 CIRC는 메시지 실행을 트리거하는 것을 허용하지 않으며, 두 개의 트랜잭션이 필요합니다. 하나는 소스 체인에 메시지를 작성하는 트랜잭션이고, 다른 하나는 목적지 체인에서 해당 메시지를 사용하는 트랜잭션입니다.
• Ultra Transactions는 푸시 기반 모델을 채택하여 모든 크로스 체인 활동을 블롭(blob)과 정산 증명을 포함하는 단일 L1 번들 트랜잭션으로 패키징합니다. XCALLOPTIONS 사전 컴파일이 도입되면 계약은 다른 체인의 계약을 원활하게 호출할 수 있습니다. 모든 L1 계약은 ExtensionOracle 계약과 통합되고 Ultra 트랜잭션의 증명 시스템을 신뢰하는 경우, 더 저렴한 롤업 실행 환경으로 실행을 연기할 수 있습니다.

범위

그것은 무엇입니까?

SCOPE는 이전의 두 가지 접근 방식을 기반으로 동기식, 신뢰 최소화 크로스체인 함수 호출을 위한 범용 프레임워크를 제공합니다.

• CIRC 로부터 사서함 커밋을 사용하여 효율적이고 검증 가능한 메시지 회계를 상속받았습니다.
• Ultra Transactions 는 푸시 기반 실행 모델을 채택하고 계정 추상화 번들러를 활용하여 크로스체인 실행을 단일 원자 범위로 통합합니다.

SCOPE는 다음 두 가지를 모두 제공합니다.

• 롤업이 SC 호출을 지원하기 위해 상속할 수 있는 표준화된 스마트 계약 세트 (예: ScopedCallable ).
• 롤업이 크로스체인 실행, 번들링 및 검증 중에 호환성을 보장하기 위해 구현할 수 있는 파생 친화적 프로토콜 입니다.

엘리5

이더리움을 본토라고 생각하고, 각 롤업을 바로 앞바다에 있는 섬이라고 생각해 보세요. 오늘날 섬들 간의 소통은 마치 병 속에 메시지를 보내는 것과 같습니다. 메시지는 도착하기 전에 몇 분 또는 몇 시간 동안 표류하며, 발신자는 아무런 확인도 받지 못하고, 사용 가능한 답장은 더더욱 받지 못합니다. SCOPE는 모든 섬이 본토에 연결된 것처럼 느껴지게 하여 양방향으로 즉시 완전한 대화가 이루어질 수 있도록 합니다. 말하고, 답을 받고, 즉시 실행할 수 있어, 섬들이 형성되기 전 이더리움이 누렸던 원활한 협력 관계를 복원합니다.

SCOPE는 롤업이 서로 L1 간에 원자적으로 메시지를 전송할 수 있도록 할 뿐만 아니라, 한 체인의 사용자가 다른 체인의 함수를 호출하고 결과를 즉시 수신하여 처리할 수 있도록 합니다. 이를 통해 롤업의 확장성 이점을 유지하면서 단일 체인에서 작업하는 것과 같은 경험을 제공합니다.

어떻게 작동하나요?

SCOPE는 검증 가능한 푸시 기반 크로스체인 거래에 필요한 회계 모델을 공식화합니다. 참여하는 각 체인은 크로스체인 요청 및 응답의 전체 시퀀스를 나타내는 4개의 롤링 해시와 단일 바이트 매핑을 유지합니다.

• requestsOutHash : 이 체인에서 시작된 발신 크로스체인 호출을 기록합니다.
• requestsInHash : 이 체인에서 실행될 수신 크로스체인 호출을 기록합니다.
• responsesOutHash : 이 체인에서 실행된 크로스체인 호출의 나가는 응답을 기록합니다.
• responsesInHash : 이 체인에서 시작된 크로스체인 호출에서 들어오는 응답을 기록합니다.
• responsesIn : 이 체인에서 시작된 크로스체인 호출에서 들어오는 응답을 원시 바이트로 기록합니다.

scopedCallable 인터페이스는 이러한 값이 업데이트되는 방식을 정의합니다.

 interface IScopedCallable {/// @notice Struct describing a cross-chain function call.struct ScopedRequest {address to;uint256 value;uint256 gasLimit;bytes data;}/// @notice Initiates a synchronous cross-chain call./// @dev Emits an event, updates a nonce, and updates the requestsOutHash./// Reads the result from the responsesIn array (pre-filled by the sequencer)./// @param targetChainId The ID of the chain the `ScopedRequest` will execute on./// @param from The address that initiated the cross-chain call on the source chain./// @param request Encoded function call for the destination chain./// @return response The result bytes returned from the responsesIn array.function scopedCall(uint256 targetChainId,address from,ScopedRequest calldata request) external payable returns (bytes memory response);/// @notice Executes a cross-chain call./// @dev Called by the sequencer. Updates requestsInHash, emits an event, and updates responsesOutHash./// @param sourceChainId The ID of the chain the `ScopedRequest` was initiated from./// @param from The sender address on the origin chain./// @param nonce A unique nonce for deduplication./// @param request Encoded call to execute locally.function handleScopedCall(uint256 sourceChainId,address from,uint256 nonce,ScopedRequest calldata request) external;/// @notice Pre-fills the responsesIn array with pre-simulated responses of cross-chain calls./// @dev Each response updates the responsesInHash for the corresponding chain ID./// @dev All arrays must have the same length (ie, chainIds[i] corresponds to reqHashes[i])./// @param chainIds The chain IDs from which the responses originate./// @param reqHashes The hashes of the original cross-chain requests./// @param responses The execution results from the destination chain.function fillResponsesIn(uint256[] calldata chainIds,bytes32[] calldata reqHashes,bytes[] calldata responses) external;/// @notice Returns the current rolling mailbox hashes for a given chain./// @param chainId The remote chain ID whose rolling hashes are tracked./// @return requestsOut Rolling hash of this chain's outbound requests./// @return requestsIn Rolling hash of this chain's inbound requests./// @return responsesOut Rolling hash of this chain's outbound responses./// @return responsesIn Rolling hash of this chain's inbound responses.function getRollingHashes(uint256 chainId)externalviewreturns (bytes32 requestsOut,bytes32 requestsIn,bytes32 responsesOut,bytes32 responsesIn);}

개발자에게 노출되는 핵심 기본 요소는 scopedCall() 함수입니다. 이 함수를 사용하면 한 롤업의 계약이 다른 롤업의 함수를 동기적으로 호출하고 결과를 즉시 사용할 수 있습니다. scopedCall() 이 호출되면 소스 체인의 requestsOutHash 에 고유 요청 식별자를 추가하고 로컬 responsesIn 매핑에서 미리 채워진 응답을 읽습니다. 호출자 관점에서 이 상호작용은 시퀀서가 이미 대상 체인에서 호출을 시뮬레이션하고 responsesIn 미리 채웠기 때문에 동기적으로 보입니다. *scopedCall* 이라는 이름은 전체 크로스 체인 상호작용(요청, 실행, 응답) 이 단일 원자적 실행 범위 내에서 처리되어 체인 간에 로컬 구성이 가능하다는 착시를 제공합니다.

목적지 체인에서 시퀀서는 handleScopedCall() 실행합니다. 이 메서드는 동일한 요청 식별자를 requestsInHash 에 추가하고, ScopedRequest 를 실행한 후 responsesOutHash 에 결과를 업데이트합니다. 이 출력은 다시 전달되어 소스 체인의 responsesIn 에 삽입됩니다.

정산 시점에 브리지는 두 체인 모두 요청과 응답의 올바른 순서를 준수했는지 확인합니다. 구체적으로 다음 사항을 확인합니다.

• 소스 체인의 requestsOutHash 대상 체인의 requestsInHash 와 일치합니다.
• 소스 체인의 responsesInHash 대상 체인의 responsesOutHash 와 일치합니다.

호출이 건너뛰어지거나, 순서가 바뀌거나, 변조되면 이러한 롤링 해시는 일치하지 않고 롤업이 정착되지 않아 원자성이 보장됩니다.

L2↔L2 동기식 구성성

SCOPE는 L2↔L2 상호 작용에서 특히 효과적으로 작동합니다. Rollup A의 계약이 Rollup B의 함수를 호출해야 한다고 가정해 보겠습니다. 공유 시퀀서는 A의 scopedCall() 관찰하고 즉시 B에 일치하는 handleScopedCall() 주입합니다. B에서 대상 함수를 실행하고 response 받은 후, 시퀀서는 A의 fillResponsesIn() 트랜잭션을 미리 채워서 A의 scopedCall() 실제로 실행될 때 로컬 호출과 마찬가지로 response 동기적으로 읽고 처리할 수 있도록 합니다.

H(0) 의 초기 해시에서 시작하여 흐름은 다음을 생성합니다 B.requestsInHash = A.requestsOutHash = H(H(0) || H(ScopedRequest)) 및 A.responsesInHash = B.responsesOutHash = H(H(0) || H(response)) .시퀀서가 요청을 잘못 주입하면 B의 requestsInHash A의 requestsOutHash ( scopedCall() 에서 파생됨)와 일치하지 않습니다.시퀀서가 응답을 잘못 전달하면 A의 responsesInHash B의 responsesOutHash ( handleScopedCall() 에서 파생됨)와 일치하지 않습니다.두 가지 불일치 모두 결제 시 동등성 검사를 중단시키고 EVM 실행을 변조하는 것과 동일하며 표준 상태 전환 증명에서 거부됩니다.

장점

• 병렬 증명: 두 체인 모두 전체 트랜잭션 순서를 가지고 있으므로, 각 롤업은 자체 상태 전이를 병렬로 독립적으로 증명합니다. 유일한 교차 체인 종속성은 결제 시 최종 롤링 해시 동등성 검사입니다.
• 필수 공유 시퀀서 없음: 공유 시퀀서는 지연 시간을 최적화할 수 있지만, SCOPE는 결제 계층을 공유하고 서로의 시퀀싱을 신뢰하는 한 독립적으로 시퀀싱된 롤업과 호환됩니다. 따라서 Optimism Superchain과 같은 생태계와 직접 호환됩니다.
• 실시간 증명 요구 사항 없음: 동기식 L1↔L2와 달리 L2↔L2 호출은 유효성 증명을 동일한 슬롯에서 생성할 필요가 없습니다. 유일한 요구 사항은 참여 롤업이 결국 함께 모여 롤링 해시 동등성을 검증할 수 있다는 것입니다.
• 공유 커밋을 통한 비용 상각: 두 롤업이 공유 L2↔L2 실행에 커밋하면 1) 블롭 공간을 공유하고 2) 단일 유효성 증명을 공유할 수 있습니다. 이를 통해 롤업당 오버헤드가 줄어들고, 더 작은 롤업으로 여러 참여자에게 블롭 및 증명 비용을 상각할 수 있습니다.

L1 ↔ L2 동기식 구성성

L2↔L2 동기 호출은 공유 시퀀싱과 공유 결제를 가정하면 비교적 쉽게 추론할 수 있지만, 여기에 L1을 도입하면 상황이 복잡해집니다. 동기식 L1↔L2 scopedCall() 실행 가능하게 하려면 세 가지 복잡한 과제를 해결해야 합니다. L1 블록 공간 제어, 체인 간 원자성, 그리고 사용자를 대신하여 L1 트랜잭션을 실행할 수 있는 기능입니다.

SCOPE의 중심에는 Ultra Transactions 모델에서 영감을 받은 슈퍼 빌더가 있습니다. 슈퍼 빌더는 전체 크로스 체인 호출(L1 및 L2 구간 모두)을 시뮬레이션하고 모든 것이 하나의 L1 슬롯 내에서 원자적으로 정산되도록 보장합니다. 이를 위해서는 L1 제안자 및 L2 시퀀서와의 긴밀한 협력이 필요하며, 이상적으로는 슈퍼 빌더가 두 가지 역할을 모두 수행하는 것이 좋습니다.

L1 블록 공간 제어: 첫 번째 과제는 L1 제안자만이 블록에 포함될 내용을 결정한다는 것입니다. L2 시퀀서가 L1 상태를 가정하여 scopedCall() 을 시뮬레이션하지만, L1 제안자가 트랜잭션을 삽입하거나 순서를 변경하여 해당 상태를 무효화하는 경우, L2 시뮬레이션은 무효화되고 결제가 실패합니다. 이를 방지하기 위해 슈퍼 빌더는 L2 증명 생성 시점에 L1 내용에 대한 결정권을 가져야 합니다. 이는 슈퍼 빌더가 L1 제안자 이거나 L1 제안자와 시퀀싱을 조정해야 함을 의미합니다.

실시간 정산: 다음으로, 원자성을 위해서는 두 체인이 함께 정산되고 롤링 해시 검사가 실패할 경우 롤백되어야 합니다. 하지만 L1↔L2에서는 롤업 상태만 롤백할 수 있습니다. 원자성을 유지하려면 모든 scopedCall() 활동(L1 함수 호출, 블롭 제출, 증명 검증)을 단일 L1 트랜잭션으로 묶어야 합니다. 롤링 해시 검사가 실패하면 전체 묶음이 원래 상태로 돌아가 L1 및 롤업 상태가 롤백됩니다. 중요한 점은 L2가 L1 상태를 소비 해야 하므로 동일한 L1 슬롯 내에서 시뮬레이션하고 정산해야 하며, 이는 L2↔L2의 경우에는 존재하지 않는 실시간 증명 요구 사항을 야기한다는 것입니다.

위임 실행: 마지막으로, 롤업은 시퀀서가 사용자를 대신하여 트랜잭션을 주입할 수 있도록 하는 경우가 많습니다. 예를 들어 입금 후 ETH를 발행하는 경우가 있습니다. L1은 이러한 위임을 기본적으로 지원하지 않으므로, L2→L1 scopedCall() 지원하기 위해 EIP-7702 위임 실행을 사용합니다. 사용자는 작업을 승인하는 페이로드에 서명하고, 번들러는 해당 페이로드를 L1 트랜잭션으로 래핑합니다.

예

이 예제는 scopedCall() 사용하여 크로스 체인 토큰 스왑을 보여줍니다. L1 컨트랙트는 L2 컨트랙트와 상호 작용하여 스왑을 실행하고 생성된 ERC-20 토큰을 즉시 L1에서 인출합니다. 시퀀서는 fillResponsesIn() 을 통해 스왑 결과를 미리 채워서 롤업 정산 전에 동일한 트랜잭션에서 인출이 이루어질 수 있도록 합니다. 일반적인 머클 증명 기반 인출과 달리, 이 경우의 withdraw() 호출은 비허가형(permissionless)으로 실행될 수 있습니다. 증명이 실패하거나 롤링 해시가 일치하지 않을 경우, 인출을 포함한 전체 번들(bundle)이 원자성 롤백으로 보호되어 자금의 무단 유출을 방지합니다.

시뮬레이션

시뮬레이션 및 시퀀싱 시 슈퍼 빌더는 각 롤업이 크로스체인 호출에 대한 부분 순서를 준수하는지 확인해야 합니다.

• 소스 체인에서 모든 scopedCalls 명확하게 정의된 상대적 순서로 나타나야 합니다.
• 대상 체인에서 모든 해당 handleScopedCalls 일치하는 상대적 순서로 나타나야 합니다.
• 그 외의 모든 것(일반 거래)은 ScopedRequest 페이로드나 계산된 response 롤링 해시를 변경하는 방식으로 변형시키지 않는 한 인터리브될 수 있습니다.

구체적으로:

• scopedCall(req) 시퀀싱한 후 슈퍼 빌더는 req 변경하는 소스 체인 트랜잭션(예: mutate to , value , gasLimit 또는 data 을 포함해서는 안 됩니다.
• handleScopedCall(req) 시뮬레이션하고 response 캡처한 후 슈퍼 빌더는 response 변경할 대상 체인 트랜잭션을 포함해서는 안 됩니다.

시뮬레이션을 위해 슈퍼 빌더는 다음을 수행합니다.

1. 소스 체인의 scopedCall() 가로채다
2. 소스 체인의 requestsOutHash 로컬로 업데이트합니다.
3. handleScopedCall() 대상 체인에 삽입하고 실행합니다.
4. response 소스 체인의 실행으로 다시 전달합니다.

이 과정을 반복하면 슈퍼 빌더는 fillResponsesIn() 호출하는 데 필요한 모든 response 값을 결정합니다.

충수

여기서는 대상이 동기식 L1↔L2 구성성이라고 가정하고 SCOPE를 지원하는 데 필요한 변경 사항을 식별하기 위해 인기 있는 롤업 스택을 분석합니다.

핵심 SCOPE 요구 사항(L1↔L2)

• 공유 시퀀서 : 공통 시퀀서는 참여하는 모든 롤업에서 크로스체인 거래 흐름을 조정해야 합니다.
• L1 클라이언트 수정 : L1→L2 scopedCall() 실행 시보다 시뮬레이션 중에 다른 동작이 필요합니다.
• L2 클라이언트 수정: 핵심 상태 전환 기능을 넘어, 롤업은 모든 크로스체인 요청과 응답에 대해 롤링 해시 동등성을 증명해야 하며, 참여 체인 간의 검증 가능한 일관성을 보장해야 합니다.
• L1 브리지 수정 : 브리지는 결제 중 동등성 검사를 통해 원자성을 강제하기 위해 롤링 해시( requestsInHash , requestsOutHash , responsesInHash , responsesOutHash )를 추적해야 합니다.
• 실시간 증명 : 롤업은 원자적 scopedCall() 실행에 참여하기 위해 동일한 L1 슬롯 내에서 유효성 증명(즉, 이의 제기 불가능한 롤업)을 생성하고 제출해야 합니다.
• L1 제안자 조정 : 시퀀서는 L1 제안자여야 하거나 scopedCall() 의 L1 구간이 시뮬레이션된 대로 정확하게 실행되도록 보장하기 위해 상태 잠금을 얻어야 합니다.
• 반환 값 지원 : 크로스체인 호출을 사전에 시뮬레이션하고 L1 및 L2 모두에서 responsesOutHash , responsesInHash 및 resultsIn 매핑을 추적합니다. 이를 통해 호출하는 컨트랙트가 마치 로컬 호출인 것처럼 반환 값을 동기적으로 사용할 수 있습니다.

사례 연구: Ethrex

Ethrex 스택은 권한이 있는 트랜잭션을 통해 반환 값이 없는 푸시 기반 L1→L2 크로스 체인 호출과 풀 기반 L2→L1 메시지 전달을 지원합니다.

L1→L2 오늘

1. CommonBridge.sendToL2() 를 호출하면 대상 L2 함수 호출을 인코딩하는 임의의 SendValues 페이로드가 전송됩니다. 페이로드의 해시값이 pendingTxHashes 배열에 추가되고 PrivilegedTxSent 이벤트가 발생합니다.

2. 시퀀서는 PrivilegedTxSent 이벤트를 수신하고 PrivilegedL2Transaction 을 L2 메모리 풀에 주입합니다. 이 트랜잭션은 SendValues 에 인코딩된 함수 호출을 실행합니다.

3. 결제 과정에서 증명 시스템은 모든 PrivilegedL2Transactions 수집하고, 롤링 해시를 계산하고, OnChainProposer.verifyBatch() 를 통해 체인상에서 계산된 pendingTxHashes 의 롤링 해시와 일치하는지 확인합니다.

   이 메커니즘은 SCOPE 모델에서 L1 requestsOutHash L2 requestsInHash 와 일치하는지 확인하는 것과 같습니다.

L2→L1 오늘

1. L2ToL1Messenger.sendMessageToL1(bytes32 data) 를 호출하면 L1Message 이벤트가 발생하는데, 여기서 data 전송되는 메시지의 해시입니다.
2. 시퀀서는 이러한 모든 data 값에서 머클 트리를 구성하고 L2 정산 중에 루트를 커밋합니다.
3. 메시지를 완성하기 위해 사용자는 원시 메시지와 Merkle 증명을 제공하여 메시지가 L2에 의해 커밋되었는지 확인할 수 있습니다.

현재 L1 브리지는 토큰 출금만 지원합니다. CommonBridge 계약에서 시작된 범용 L1 함수 호출은 아직 지원되지 않지만, 쉽게 추가할 수 있습니다.

SCOPE 호환성에는 다음이 필요합니다.

• sendToL2() scopedCall() 로 교체하고 responsesOutHash , responsesInHash 및 resultsIn 매핑을 도입하여 호출 계약에서 크로스체인 함수 호출에서 반환 값을 즉시 사용할 수 있도록 합니다.
• L1에서 발생하는 PrivilegedTxSent 이벤트를 기다리는 대신, 시퀀서는 L1 블록 확인 전에 PrivilegedL2Transactions 미리 주입하여 체인 전체에서 동기적 실행을 활성화해야 합니다.
• 풀 기반 L2→L1 메시징을 L2에서 시작되어 L1의 handleScopedCall() scopedCall() ()로 대체합니다. 이를 통해 임의의 L1 계약 호출이 동일한 L1 슬롯 내에서 실행될 수 있습니다.

사례 연구: OP Stack

OP 스택은 반환 값이 없는 양방향 푸시 기반 크로스체인 호출을 지원합니다.

참여 롤업이 결제 계층을 공유하고 서로의 시퀀싱을 상호 신뢰하는 한, 공유 시퀀서나 실시간 증명이 필요 없이 L2↔L2 동기적 구성을 가능하게 하기 위해 SCOPE를 SuperChain에도 적용할 수 있습니다.

L1→L2 오늘

1. L1 CrossDomainMessenger.sendMessage() 호출하면 임의의 불투명 바이트를 대상 L2 계약에 호출 데이터로 전송할 수 있습니다.
2. OptimismPortal.depositTransaction() 은 잠금 상자에 있는 모든 ETH를 에스크로하고 TransactionDeposited 이벤트를 발생시킵니다.
3. 시퀀서는 TransactionDeposited 이벤트를 수신하고 CrossDomainMessenger.relayMessage() 호출하는 L2에 트랜잭션을 주입합니다. 이 트랜잭션은 이전에 전송된 데이터를 사용하여 L2 함수 호출을 실행합니다.

파생 파이프라인은 모든 TransactionDeposited 이벤트가 전달되는 메시지와 일치하는지 확인합니다. 그렇지 않으면 시퀀서가 사기를 저지른 것입니다.

L2→L1 오늘

1. L2 CrossDomainMessenger.sendMessage() 호출하면 임의의 불투명 바이트를 대상 L1 계약에 호출 데이터로 전송할 수 있습니다.
2. L2ToL1MessagePasser.initiateWithdrawal() sentMessages 매핑에 메시지 해시를 기록하고 MessagePassed 이벤트를 내보냅니다.
3. 시퀀서는 sentMessages 매핑 상태를 커밋하는 output_root 포함하는 L2 output 제안합니다.
4. 사용자는 머클 증명과 함께 L1 OptimismPortal.proveWithdrawalTransaction() 호출하여 메시지 포함을 증명합니다.
5. 사기 방지 기간이 지나면 L1 OptimismPortal.finalizeWithdrawalTransaction() 호출하여 L1 함수 호출을 실행합니다.

유효성 증명을 사용하면 이러한 풀 기반 접근 방식을 두 가지 거래로 줄일 수 있습니다. 하나는 L2에서 메시지를 시작하는 거래이고 다른 하나는 L1에서 실행을 증명하고 완료하는 거래입니다.

SCOPE 호환성에는 다음이 필요합니다.

• 단일 L1 슬롯 내에서 롤업을 정착시킬 수 있도록 실시간 증명이 가능한 유효성 증명을 지원합니다.
• op-node [ SequencerConfDepth](https://github.com/ethereum-optimism/optimism/blob/f70219a759e1da31e864c0ccdc2c757689aba3ec/op-node/rollup/driver/config.go#L12) = 0 설정하고 L1에서 TransactionDeposited 이벤트가 발생하기 전에 CrossDomainMessenger.relayMessage() 호출되도록 하여 동기식 L1→L2 scopedCall() 지원합니다.
• 현재의 여러 단계로 구성된 L2→L1 메시지 전달 프로세스를 단일 L2 시작 scopedCall() 로 대체하여 동기식 L2→L1 호출을 활성화합니다.

사례 연구: 타이코

Taiko 스택은 반환 값 없이 양방향, 풀 기반 크로스체인 호출을 지원합니다.

L1→L2

1. Bridge.sendMessage() 를 호출하면 대상 L2 계약에 대한 함수 호출을 인코딩하는 임의의 Message 전송할 수 있습니다. Message 는 해시되어( 신호 생성) L1 SignalService 계약에 저장됩니다.
2. 사용자는 표준 eth_getProof RPC를 사용하여 저장 증명을 생성하여 신호가 L1에 존재한다는 것을 증명합니다.
3. 각 Taiko 블록은 현재 L1 월드 스테이트 루트와 새로운 신호 목록을 주입하는 앵커 트랜잭션 으로 시작합니다. 이후 이러한 신호는 L2 SignalService 계약에 기록됩니다.
4. 사용자는 Message 와 L1 저장소 증명을 사용하여 L2 Bridge.processMessage() 호출함으로써 메시지가 L1에 포함되었음을 증명합니다. 이는 L1 월드 스테이트 루트와 L2 SignalService 계약에 대한 신호를 검증함으로써 수행됩니다.
5. 그런 다음 _invokeMessageCall() 은 대상 L2 계약의 Message 에 인코딩된 함수 호출을 실행합니다.
6. 결제 중에 시스템은 앵커 거래에서 보고된 신호가 L1 SignalService 에 기록된 내용과 일치하는지 확인합니다.

동등한 신호를 확인하는 것은 SCOPE에서 L1 requestsOutHash 와 L2 requestsInHash 비교하는 것과 기능적으로 동일합니다.

L2→L1

1. 사용자는 L2 Bridge.sendMessage() 호출하는데, 이는 L2 SignalService 계약에 메시지 해시( 신호 )를 저장합니다.
2. 롤업이 정착되고 월드 상태가 확정되면 L1 Bridge.processMessage() 원래 Message 와 L2 SignalService 계약에 신호가 존재함을 보여주는 저장 증명과 함께 호출할 수 있습니다.
3. 그런 다음 _invokeMessageCall() 은 L1 계약에 대한 인코딩된 함수 호출을 실행합니다.

SCOPE 호환성에는 다음이 필요합니다.

• 현재의 신호 기반 흐름을 Bridge.sendMessage() scopedCall() 과 동등해지는 푸시 기반 모델로 대체합니다. 시퀀서는 개별 신호를 기록하여 목적지 체인에 전달하는 대신, 전체 Message 직접 전달합니다. 소스 체인은 메시지를 롤링 requestsOutHash 에 추가하고, 목적지 체인은 handleScopedCall() 중에 일치하는 requestsInHash 계산합니다. 이렇게 하면 변조된 Message 롤링 해시 검사에 실패하여 결제를 방해하기 때문에 머클 증명이 필요하지 않습니다.
• Bridge.processMessage() handleScopedCall() 과 동일하며, 즉시 호출되어 Message 실행하고 requestsInHash 와 responsesOutHash 모두 업데이트해야 합니다. 합리적인 제안자는 롤업이 완료되도록 메시지가 올바른 순서로 처리되도록 해야 하므로(즉, requestsInHash 와 requestsOutHash 일치하도록) 이 함수는 권한이 필요 없을 수 있습니다.

사례 연구: Linea

Linea 스택은 Postman 서비스 가 사용되는지 여부에 따라 푸시 또는 풀 기반 전달을 사용하여 반환 값 없이 양방향 크로스체인 호출을 지원합니다.

L1→L2 오늘

1. L1MessageService.sendMessage() 를 호출하면 불투명 바이트(calldata)가 대상 L2 계약으로 전송됩니다. 메시지 해시는 롤링 해시에 통합되고 L1에서 MessageSent 이벤트가 발생합니다.
2. 코디네이터 서비스는 이러한 이벤트를 모니터링하고, 두 L1 에포크 동안 최종성을 기다린 후 L2에서 L2MessageManager.anchorL1L2MessageHashes() 를 호출합니다. 이 함수는 메시지 해시를 L2에 기록하고 RollingHashUpdated 이벤트를 발생시켜 두 체인 모두에서 동일한 롤링 해시를 다시 계산할 수 있도록 합니다.
3. 마지막으로, L2MessageServiceV1.claimMessage() L2 함수 호출을 실행하고, 재전송을 방지하는 플래그를 설정하고, MessageClaimed 내보냅니다. 이는 사용자가 수동으로 호출하거나, 사용자가 L1 요금을 선불한 경우 Postman 서비스 에서 자동으로 호출할 수 있습니다.
4. 결제 시점에 L2에서 생성된 최종 RollingHashUpdated L1의 롤링 해시와 비교되어 체인 전체에서 메시지 일관성이 검증됩니다.

이 메커니즘은 SCOPE 모델에서 L1 requestsOutHash L2 requestsInHash 와 일치하는지 확인하는 것과 같습니다.

L2→L1 오늘

1. L2MessageServiceV1.sendMessage() 호출하면 메시지 해시가 포함된 MessageSent 이벤트가 방출되고 임의의 불투명 바이트가 대상 L1 계약에 대한 호출 데이터로 인코딩됩니다.
2. 결제 과정에서 증명자는 모든 방출된 메시지 해시 값의 머클 트리를 구성하고 머클 루트를 L1에 커밋합니다.
3. 메시지를 완성하기 위해 사용자(또는 Postman 서비스 )는 원시 메시지와 해당 Merkle 증명을 사용하여 L1MessageService.claimMessageWithProof() 호출합니다. 이를 통해 L1 함수 호출이 실행됩니다.

SCOPE 호환성에는 다음이 필요합니다.

• anchorL1L2MessageHashes() 단계를 제거하고 대신 claimMessage() 메서드에서 L2 롤링 해시를 점진적으로 업데이트합니다. 이는 handleScopedCall() 메서드와 동일합니다. 시퀀서는 L1과 L2 간의 롤링 해시 일관성을 보장하기 위해 메시지가 올바른 순서로 요청되도록 해야 합니다.
• claimMessageWithProof() 에서 사용되는 현재 Merkle 증명 검증을 L2에서 시작된 scopedCall() 사용하는 푸시 기반 모델로 대체합니다. handleScopedCall() 이 호출되면 L2는 requestsOutHash 추적하고 L1은 일치하는 requestsInHash 계산합니다.
• LineaRollup.submitBlobs() 와 LineaService.finalizeBlocks() 는 함께 번들링되어 원자적으로 실행되어야 합니다. 이렇게 하면 L2가 실시간으로 처리됩니다.

기반 사전 확인 및 범위

사전 확인은 SCOPE의 엄격한 요건이 아닙니다. 누구나 슈퍼 빌더 역할을 하여 크로스 체인 호출을 포함하는 유효한 번들을 제안하고 사전 설정(preconf)을 제공하지 않는 "완전한 무정부 상태" 기반 롤업을 상상해 볼 수 있습니다. 이 모델은 효과적이지만, 사전 설정은 사용자에게 거래 결과에 대한 확실성을 더 일찍 제공하여 UX를 향상시킬 수 있습니다.

실행 사전 설정은 일반적으로 금본위제로 간주되지만 SCOPE의 작업 순서는 이를 복잡하게 만듭니다.스코프드콜 scopedCall() 의 사후 상태는 responsesIn 매핑을 채워야 하기 때문에 시뮬레이션과 실행에서 다릅니다.효율성을 위해 슈퍼 빌더는 각 scopedCall() 이전이 아닌 모든 시뮬레이션이 실행된 후에 단일 fillResponsesIn() 호출을 삽입할 수 있습니다.이는 롤업 에서 모든 scopedCall() 바로 앞에 fillResponsesIn() 배치하여 해결할 수 있으며, 이는 가스 측면 에서 가능합니다.L1에서 대안은 슈퍼 빌더가 해당 요청 및 응답 데이터와 함께 사전 및 사후 롤링 해시를 사전 확인하는 것입니다.이 접근 방식을 사용하면 사용자는 오류 발생 시 증명하기 쉽고 슈퍼 빌더에서 실행하기 쉬운 방식으로 크로스 체인 요청의 결과를 안정적으로 알 수 있습니다(중간 상태 루트가 필요하지 않기 때문).

CUSTARD 와 같은 이전 연구는 슈퍼 빌더의 슬롯보다 앞서 만들어진 "슈퍼 트랜잭션" 사전 설정의 실행 가능성을 확장하는 방법을 탐구합니다. ScopedRequests CUSTARD에서 설명하는 기법으로 잠글 수 없는 임의의 상태 저장 데이터에 의존하는 경우, 이러한 초기 scopedCall() 실행이 안전한지 확인하기 위해서는 추가 연구가 필요합니다. (예: ScopedRequest scopedCall() 실행 시점에 결정된 pricefeed 데이터를 포함할 수 있으며, 이는 시뮬레이션 및 사전 확인된 슬롯과 다를 가능성이 높습니다.)

SCOPE 대 AggLayer

SCOPE와 AggLayer는 모두 신뢰할 수 없는 크로스체인 메시지 전달을 목표로 하지만, 서로 다른 관점에서 문제에 접근합니다. AggLayer는 자체적인 결제 규칙을 갖춘 완전한 상호운용성 프로토콜인 반면, SCOPE는 이름에 "프로토콜"이라는 단어가 들어가 있음에도 불구하고, 기본적으로 AggLayer, Superchain, Elastic Network와 같은 기존 시스템에 오버레이될 수 있는 회계 프레임워크입니다.

두 시스템 모두 동일한 비관적 증명 철학을 공유합니다. 체인은 자체 상태 전이를 독립적으로 증명하고 암호화 동등성 검사를 통과한 경우에만 결제됩니다. AggLayer에서 이는 "로컬 종료 트리"를 통해 나타나며, 이 트리의 루트는 SCOPE의 requestsOutHash 와 유사한 역할을 합니다. 차이점은 AggLayer 및 유사 프로토콜이 크로스 체인 호출에서 동기식 반환 값을 기본적으로 지원하지 않는다는 것입니다. 메시지는 전송되지만 동일한 실행에서 아무것도 반환되지 않습니다.

SCOPE는 responsesInHash 또는 가상의 "로컬 진입 트리"를 통해 인바운드 응답을 추적하여 이 모델을 확장합니다. 이를 통해 체인은 마치 하나의 통합된 환경에 속한 것처럼 반환 데이터를 동기적으로 사용할 수 있습니다. 그 결과, 단순한 메시지 전달에서 진정한 공유 실행 범위로 전환하는 동시에 결제 시 안전성 보장은 동일하게 유지됩니다.