롤업 간의 신뢰 없는 상호 운용성: 개요, 구축 및 과제

저자: Marshall Vyletel Jr. 출처: 1kx 번역: Good Oba, Golden Finance

소개

Ether의 롤업 건수가 폭발적으로 증가했습니다. align: left;">Ether의 롤업 수가 폭발적으로 증가했습니다. L2Beat에 따르면, 이 글을 쓰는 시점에 91개의 L2 및 L3 롤업이 시작되었으며 82개가 더 진행 중입니다. 그 결과 이동성, 사용자 경험, 개발자 도구 측면에서 많은 파편화도 존재합니다. 현재의 상호운용성 솔루션은 타사 브리지, 외부 패키지 자산, 인텐트 프레임워크의 조합에 의존하고 있으며 각각 고유한 문제가 있기 때문에 개선해야 할 점이 많습니다.

1. 유동성 브리지는 종종 가장 큰 암호화폐 해킹(예: 3억 2,100만 달러 규모의 웜홀 브리지 해킹)의 표적이 됩니다

2. 외부 패키지 자산은 인기가 없으며, 데이터에 따르면 사람들은 가능한 한 원래의 형태로 자산을 보유하는 것을 선호합니다(예: L2Beat에 따르면 표준 브릿지 자산의 가치는 220억달러인 반면 외부 패키지 자산은 30억달러에 불과합니다)

3. 인텐트 프레임워크는 무시할 수 없는 수준의 신뢰를 요구하는 제3자에 의존하며, 크로스 롤업 활동을 촉진하기 위해 추가 수수료를 부과합니다(예: Degen 체인 사용자는 규제되지 않은 공식 브리징으로 인해 토큰의 80% 이상을 잃었습니다). 중앙화된 의도적 프레임워크는 또한 경쟁이 낮아져 최적의 가격 및 성능에 미치지 못할 수 있습니다

이 백서에서는 탈중앙화된 롤업 생태계 간의 상호운용성 솔루션을 6가지 수준으로 정의하고 논의함으로써 신뢰 없는 상호운용성에 대한 전망을 조사합니다.

소스 롤업에서 L1으로의 비동기 인출과 타겟 롤업으로의 수동 브리징이라는 기본 시나리오부터 시작하여 단일 트랜잭션에서 교차 롤업 구성이 가능한 가상의 아키텍처로 마무리합니다. 각 수준의 상호운용성이 사용자 경험, 개발자 경험, MEV 잠재력, 롤업 자체(특히 인프라 변경과 관련된)에 어떤 영향을 미치는지 살펴보겠습니다.

이 백서는 이더넷과 그 L2에 초점을 맞추고 있으며 신뢰 없는 상호운용성에만 초점을 맞추고 있습니다. 여기서 '신뢰 없는 상호운용성'이란 대부분의 롤업에 이미 필요한 인프라를 넘어서는 전송을 촉진하기 위해 제3자가 필요하지 않은 프로토콜 내 채널을 의미합니다.

준비

정의

기본적으로 신뢰 없는 상호운용성을 위해서는 상호운용을 원하는 두 프로토콜이 사용할 수 있어야 하는 여러 공유 리소스가 필요합니다. 상호 운용을 원하는 두 프로토콜은 이러한 리소스에 액세스할 수 있어야 합니다. 이더리움 L1의 경우, 모든 스마트 콘트랙트는 이더리움의 전체 상태를 공유하는 동일한 환경에 존재하므로 항상 가장 높은 수준의 상호운용성을 갖습니다. 그러나 L2는 별도의 브리징 컨트랙트를 통해 결제 레이어만 공유하므로 상호운용성이 상당히 제한적입니다.

신뢰 없는 상호운용성의 사다리를 오를 수 있는 핵심 공유 인프라 구성 요소는 공유 시퀀서, 슈퍼 빌더, 공유 정산입니다. 이러한 공유 계층이 제공하는 보증과 새로운 기능은 서로 연관되어 있지만 본질적으로 직교합니다.

1. 공유 시퀀서/슈퍼빌더: 속도와 사용자 경험이 크게 개선되었습니다.

2. 공유 결제: 외부 패키징 및 프로토콜 내 메시징 없이 에셋을 교환할 수 있습니다.

먼저, 소개에서 언급한 6단계의 신뢰 없는 상호운용성을 정의하겠습니다.

1. L1 비동기:
   →집계 정산된 L1을 통한 상호운용성을 위한 수동 자산 전송.

2. 원자적 포함:
   →롤업 번들의 모든 트랜잭션이 해당 번들에 포함된 각 롤업의 다음 블록에 포함되도록 보장하거나 아무것도 포함되지 않도록 보장합니다.

3. 공유 결제:
   → 여러 롤업이 동일한 브리징 컨트랙트를 통해 L1에 연결됩니다.

4. 아토믹 실행:
   → 교차 롤업의 모든 트랜잭션을 보장합니다. 롤업 번들의 모든 트랜잭션은 번들에 포함된 각 롤업의 다음 블록에 포함되고 성공적으로 실행되며, 그렇지 않으면 트랜잭션이 실행되지 않습니다. 실행 성공은 각 트랜잭션이 롤백 없이 실행되고 번들 내 각 롤업의 업데이트된 상태에 반영됨을 의미합니다.

5. 블록 수준 구성 가능성:
   → 롤업 번들에서 다음 블록은 종속 트랜잭션을 포함할 수 있도록 보장됩니다(롤업 B의 tx B는 롤업 A의 tx A 결과에 따라 달라짐)

6. 트랜잭션 수준 구성 가능성:
   → 스마트 컨트랙트 수준의 상호운용성은 여러 롤업 간에 동시에(번들 해제) 상태 변화를 일으키기 위해 단 하나의 트랜잭션만 필요합니다. 어떤 롤업에서든 프로토콜을 사용하는 것은 논리적으로 하나의 체인에서 서로 다른 스마트 콘트랙트를 사용하는 것과 동일합니다. 중요한 점은 호출 이전에 변경된 모든 상태는 반환 시 복원할 수 있다는 것입니다.

각 레벨에 대한 이해를 돕기 위해 각 레벨의 기능과 사용자, 개발자, 애그리게이터, MEV 검색자에게 미치는 영향을 보여주는 주요 사용 사례는 다음과 같습니다.

예시:

1. 동일한 토큰 전송
   → 본인에게 보내기: 두 롤업 거래소 간 두 롤업 간 이더에서 이더로 또는 ERC-20에서 ERC-20으로

2. 토큰 구매
   → 교차 롤업 제한 주문: 롤업 A의 이더/ERC-20을 사용하여 롤업 B에서 서로 다른 ERC-20으로 구매하고 (선택적으로) 롤업 A로 다시 전송

의미:

집합된 생태계의 주요 주주들에게 미치는 영향에 대해 자세히 알아보기 위해 다음 질문에도 답할 것입니다. 시사점.

1. 사용자 경험
   이러한 수준의 상호운용성을 구현하면 사용자 경험은 어떻게 달라질까요?

2. 개발자 경험
   이러한 수준의 상호운용성을 지원하면 개발자 경험은 어떻게 달라지나요?

3. MEV 잠재력
   이러한 수준의 상호운용성을 달성하면 새로운 MEV 기회가 생길 가능성이 있나요?

4. 롤업의 영향
   이를 실현하기 위해 롤업이 새로운 인프라에 참여해야 하며, 롤업의 요금 구조에는 어떤 변화가 있으며, 롤업이 해당 인프라에 참여함으로써 얻을 수 있는 잠재적 혜택은 무엇인가요?

개략적인 개요

신뢰 없는 상호운용성을 향한 6단계

1. L1 비동기

필요한 인프라:

적용 불가

정의상 이는 현재 기본값인 신뢰할 수 없는 인터롭 모드를 의미합니다. 모든 롤업은 L1의 결제 계층으로 구축되어 해당 L1에 대한 브리지 계약을 통해서만 액세스할 수 있고 네트워크를 보호하기 위해 주기적으로 상태 업데이트를 게시하기 때문에 이러한 방식으로 정의됩니다.

이 경우, 신뢰가 필요하지 않은 크로스 롤업 활동을 수행하는 유일한 표준 방법은 표준 브리지를 통해 소스 롤업에서 자산을 추출하고 L1에서 사용할 수 있게 되면 대상 롤업에 수동으로 입금하는 것입니다.

낙관적 롤업의 경우, 오류 수정 기간을 고려하여 인출 지연 시간은 약 7일입니다. ZK 롤업의 경우 출금 지연은 덜 확실하지만 15분에서 최대 하루까지 걸릴 수 있으며, 이는 ZkSync의 경우입니다.

또한 스마트 컨트랙트를 사용하는 P2P 아토믹 교환이 가능하지만, 이는 소규모 사용 사례이며 효과적으로 확장되지 않습니다.

현재 존재하는 타사 솔루션에 주목할 필요가 있습니다.

1. 모빌리티 브릿지

< li>

인텐트 프레이밍

두 예시 모두 타사 솔루션의 도움이 필요합니다.

자신에게 보내기:

1. 규범 사례:
   → 롤업 A에서 자산 추출
   → 롤업 B에 수동으로 입금

2. 제3자:
   → 유동성 브리지/솔버 네트워크

롤업 제한 주문 스패닝

class=" list-paddingleft-2">

1. 설명:
   → 롤업 A에서 자산 추출
   → 롤업 B에 수동 입금
   → 지정가 주문 실행
   → 반송하려면 대상 ERC-20이 외부에 있어야 합니다. 패키징

2. 제3자
   → 교차 집계 지정가 주문을 위한 새로운 솔루션 공간
   → 이를 용이하게 하는 사용 의도에 대한 개방형 설계가 있음

기본값이므로 UX, DevEx, MEV 및 집계 변경에 대해 논의할 필요가 없습니다.

2. 원자 포함

필수 인프라

공유 시리얼라이저 *

원자적 포함은 교차 요약 번들이 다음 블록에 포함되도록 보장할 뿐입니다.

이를 위해서는 공유 시퀀서가 필요하지만, 이론적으로는 주어진 두 롤업의 시퀀서가 처리량을 최대로 처리하지 못하는 경우(각 롤업에 두 개의 개별 트랜잭션을 제출하면 됩니다) 수동으로 달성할 수 있습니다. 이것이 바로 필수 인프라에 별표를 추가한 이유입니다.

그러나 공유 시퀀서가 연결된 각 롤업의 전체 노드를 실행한다고 가정하는 것은 아니므로 트랜잭션 세트의 성공적인 실행을 보장할 수는 없습니다. 이 경우 공유 시퀀서는 트랜잭션이 올바르게 포맷되어 다음 블록에 포함된다는 것만 보장할 수 있으며, 반드시 성공적으로 실행되는 것은 보장하지 않습니다.

실행을 보장할 수 없기 때문에 트랜잭션 중 하나가 취소될 위험을 감수하지 않고는 프로그래밍적으로 의미 있는 방식으로 원자 봉쇄를 활용하는 것이 불가능합니다. 따라서 본질적으로 L1 비동기 상호운용성과 똑같은 상황에 처하게 됩니다.

원자 포함 보장만으로 간단한 교차 요약 교환을 시작하는 것을 고려해 보세요:

1. 크로스 롤업 교환 번들
   → Tx 1: 소스 롤업에서 토큰 잠금/파기
   → Tx 2: 대상 롤업에서 사용자 주소로 토큰 발행

아토믹 포함 보장은 두 트랜잭션이 실제로 각 집합의 다음 블록에 포함된다는 것을 보장할 수 있지만, 두 트랜잭션이 실제로 각 집합의 다음 블록에 포함될 수 있습니다. 하지만 첫 번째 트랜잭션은 롤백되고 두 번째 트랜잭션은 롤백되지 않으면 사용자는 소스 체인에서 자금을 잠그거나 소각하지 않고도 타겟 체인에 자금을 잘못 할당하게 되며 이중 지불 문제가 발생합니다.

유동성 브리지, 인텐트 프레임워크, xERC-20 거래소 등 모든 상호운용성 솔루션은 이러한 위험에 취약하며 이를 완화하기는 어렵습니다. 이러한 위험 때문에 현재 솔루션은 시작 트랜잭션이 성공적으로 실행되고 소스 체인의 블록에 포함되어야만 리피터가 발신 메시지를 전달하고 대상 체인에서 두 번째 트랜잭션을 실행하는 데 사용할 수 있습니다.

중요 참고: 원자 포함은 상호운용성 잠재력에 큰 영향을 미치지 않습니다

3. 공유 결제

필수입니다. 인프라:

집계 계층 증명 // 공유 브리지 계약

이제부터 상황이 더 흥미로워지기 시작합니다. 공유 브리지 컨트랙트 덕분에 L1에서 롤업 생태계에 예치된 모든 모빌리티는 연결된 모든 롤업 간에 자유롭게 이동할 수 있습니다. 이전에는 규제된 채널을 통하거나 외부에서 자산을 패키징하거나 타사 솔루션을 사용하지 않고는 롤업 간에 교환할 수 없었습니다.

왜 쉐어드 브리지 계약인가요? 공유 브리지 컨트랙트를 통해 신뢰가 필요 없는 방식으로 롤업 간에 자산을 전송할 수 있는 이유를 이해하려면 먼저 롤업 A에 이더리움이 있고, 이를 소멸시킨 다음 레이어1에서 공유 브리지 컨트랙트를 만들 필요 없이 롤업 B에 기본적으로 캐스팅할 수 있다면 어떤 일이 발생할지 생각해 보시기 바랍니다.

각 롤업이 메인 네트워크의 브리지 컨트랙트와 동기화되지 않았음을 알 수 있습니다. 롤업 B에는 여전히 50개의 이더가 브리지 컨트랙트에 있으므로 사용자는 다음과 같이 할 수 없습니다. 이더 중 1개를 L1로 인출할 수 없습니다.

이 문제를 해결하기 위해 저희는 네트워크의 다른 곳에서 네이티브 버전을 상징하는 외부 랩핑 버전의 토큰을 통합적으로 발행하는 외부 자산 랩핑 프로토콜을 구축했습니다.

공유 결제 레이어를 사용하면 상황이 달라집니다. 연결된 각 롤업의 모든 유동성이 동일한 브릿지 콘트랙트에 고정되므로 브릿지 콘트랙트의 총 가치가 일정하게 유지되고 항상 인출이 가능하기 때문에 롤업 간에 자유롭게 이동할 수 있습니다.

사용자가 어디서든 출금할 수 있도록 유동성의 위치를 파악하려면 L1 컨트랙트 수준에서 업데이트가 필요하지만, 모든 연결에 걸친 집계가 공유 컨트랙트에 읽기/쓰기가 가능하므로 이는 간단합니다.

공유 결제 레이어를 사용하면 간단한 본인 송금 시나리오의 경우 다음과 같은 프로세스가 나타날 수 있습니다.

본인에게 보내기:

1. 사용자가 초기 트랜잭션 생성:
   →Tx 1: 롤업 A에서 이더가 추출되고(롤업 B에 캐스팅됨)
   →거래가 일괄 처리되어 L1 컨트랙트에 제출됨
   →모든 공유 결제 롤업을 그룹화하는 트랜잭션 루트에 집계됨

2. 롤업 B가 이 트랜잭션 루트로 가져오기

3. 사용자가 초기 거래를 생성함:

4. 사용자가 초기 거래를 생성함:
   

5. 릴레이는 트랜잭션을 Mint에 제출하고 머클 증명을 롤업 B에 제출합니다

6. 롤업 B는 머클 증명과 트랜잭션을 사용합니다. 루트가 트랜잭션의 파기를 확인

7. 사용자가 롤업 B에서 이더를 채굴

8. 롤업 B가 L1에 증명 제출

공유 브리지 컨트랙트는 연결된 모든 어그리게이션 간의 프로토콜 내 메시징 계층으로 생각할 수 있습니다. 따라서 이론적으로 이 프로세스는 거의 모든 임의의 메시징 표준으로 확장할 수 있습니다.

이렇게 하면 컴포저빌리티에 가까워지지만, L1의 상태 변경을 반영한 후에만 메시지의 집계 및 전달 증명이 필요하기 때문에 지연 시간이 더 길어집니다(L1 비동기식보다는 훨씬 짧지만). 또한 복잡한 교차 롤업 활동(예: 롤업 A의 자산에서 시작하는 롤업 B의 DEX를 사용한 교차 롤업 지정가 주문)은 여전히 사용자가 직접 대상 롤업의 자산을 전송하고 수동으로 교환해야 하므로 번거로운 프로세스입니다. 이 경우 원자 교차 롤업 번들을 생성할 수 없습니다.

공유 결제의 또 다른 중요한 장점은 여러 환경에서 주문을 체결하는 유동성 공급자나 체결자의 마찰이 적다는 것입니다. 연결된 모든 롤업의 유동성이 동일한 브리지 계약에 반영되므로, 교차 롤업 유동성을 관리하기 위해 전체 인출 기간을 기다릴 필요가 없습니다.

이해관계자에게 미치는 영향:

1. 사용자:
   이제 네이티브 형태로 자산을 전송할 수 있습니다. L1 드로다운 기간이 필요하지 않습니다

2. 개발자:
   변경은 토큰 발행자로 제한되며, 이제 프로토콜 내 메시지를 사용하여 연결된 모든 롤업에서 네이티브 버전의 ERC-20을 발행할 수 있습니다

3. MEV 검색자:
   롤업당 여러 블록에서 발생하므로 새로운 MEV 잠재력은 없습니다

4. 롤업:
   롤업은 반드시 롤업에서 공유 브리지 컨트랙트를 사용하고 교차 롤업 메시지를 처리하기 위해 사전 컴파일을 추가할 수 있습니다

중요: 공유 정산은 외부에서 패키지화되지 않은 자산 전송과 공유 브리지 컨트랙트와 증명 집계 레이어의 모든 집계에서 임의의 메시징을 허용하지만 여전히 무시할 수 없는 지연 시간이 존재합니다( L1 비동기보다는 훨씬 짧지만)과 교차 집계 원자 번들을 생성할 수 없다는 단점이 있습니다.

4. 원자 실행

필요 인프라:

공유 소터 // 슈퍼 빌더

공유 소터 // 슈퍼 빌더

원자 실행을 사용하면 볼륨 간 번들의 성공적인 실행을 보장할 수 있지만, 곧 살펴보겠지만 종속성 트랜잭션이 없는 볼륨 간 번들의 사용 사례 수는 처음 예상보다 적습니다.

종속 트랜잭션 세트의 단일 트랜잭션이 취소되면 다른 모든 트랜잭션도 무효가 되며, 교차 롤업 소멸 및 토큰 발행의 경우처럼 취소해야 합니다. 대상 롤업에서 토큰을 발행하는 것은 소스 롤업에서 토큰이 소멸되었는지 또는 잠겼는지에 따라 달라지므로 소멸과 발행 트랜잭션의 집합을 종속 트랜잭션의 집합이라고 할 수 있습니다.

대상 트랜잭션을 생성할 수 있는 중개자(예: 슈퍼 빌더)가 없으면 이 번들을 생성할 수 없습니다.

사용자 이외의 당사자의 개입 없이 크로스 롤업 거래소 번들을 생성하기 위해 충족해야 하는 조건을 고려하세요. 소스 롤업의 자산을 잠그거나 소각하고 대상 롤업의 자산을 발행하려면 번들을 만들어야 하지만 다음과 같은 문제가 발생했습니다.

1. 소스 롤업의 컨트랙트는 다음과 같은 경우에만 사용할 수 있습니다. 원본 소스 자산을 잠그거나 삭제할 때만 메시지를 보낼 수 있으며, 대상 롤업에서 트랜잭션을 호출하고 생성할 수 없습니다.
   → 이것이 바로 메시징 프로토콜과 릴레이 네트워크가 존재하는 이유입니다.
   → 메시지는 대상에 대한 호출을 구성하는 데 사용할 수 있지만 실제로 트랜잭션 자체를 생성할 수는 없습니다.

2. 발행을 위해 타겟 롤업에 두 번째 트랜잭션 생성:
   → 사용자는 롤업의 토큰에 대한 발행 권한이 없으므로 이 tx를 직접 만들 수 없음 B
   → (즉,) 타겟 체인은 토큰이 소스 체인에서 소각/잠금되었음을 증명해야 하지만 이 증명은 초기 트랜잭션이 실행될 때까지 불가능하며, 이는 원자성에 대한 우리의 요구 사항을 위반할 수 있습니다. → 이론적으로 발행 권한으로 두 번째 트랜잭션을 생성할 수 있는 다른 당사자는 소스 체인에 "번" 또는 잠금을 먼저 생성하지 않고도 언제든지 대상 체인에 "민트" 트랜잭션을 생성할 수 있으며 이는 큰 허점입니다.

우리는 교차 총합 번들의 실행을 보장할 수 있지만, 가치 있는 자산을 이동하기 위해 애초에 이를 구축하는 방법에 어려움이 있다는 것을 알 수 있습니다.

그러나 크로스 롤업 번들에 의존하지 않는 아토믹 실행 사용 사례도 여전히 존재합니다. 그 중 하나가 크로스 롤업 차익거래입니다.



이 거래들 사이에 엄격한 의존성이 없으므로 누구나 이 원자 패키지를 생성하여 원자 실행을 보장할 수 있는 공유 시리얼라이저에 제출할 수 있습니다.

그러나 애초에 아토믹 실행을 보장받으려면 롤업이 연결된 모든 롤업의 전체 노드를 실행할 공유 시퀀서와 슈퍼 빌더를 선택해야 하므로 모든 공유 시퀀싱 솔루션처럼 아토믹 실행에서 블록 수준 구성 가능성까지의 단계는 매우 작습니다. 필요한 유일한 변경 사항은 블록 빌더 또는 기타 제3자가 사용자를 대신해 트랜잭션을 생성하여 종속적인 크로스 롤업 번들을 완료할 수 있어야 한다는 것입니다.

더 이상의 컴포저빌리티를 활성화하지 않고 아토믹 실행만 허용하는 인프라가 구축될 가능성은 낮습니다. 인프라에 이미 원자 실행 기능이 있다는 점을 감안할 때, 완전한 블록 수준의 컴포저빌리티를 달성하는 데 따른 상대적 이점이 이를 달성하는 데 따른 어려움보다 훨씬 더 큽니다.

이해관계자에 미치는 영향:

1. 사용자:
   서드파티가 인텐트와 같은 솔루션을 제공할 수는 있지만, 아마도 변화가 없을 것입니다. Intent와 같은 솔루션을 제공할 수 있지만, 구현 방법이 명확하지 않음

2. 개발자:
   변화는 없을 것임

3. MEV 검색자:
   크로스 롤업 차익거래는 아토믹 실행을 고려할 때 더 안전합니다

4. 롤업:
   롤업은 공유 시퀀서/슈퍼빌더를 사용하여 상호 운용을 원하는 각 롤업의 트랜잭션이 포함된 블록을 제출하도록 선택해야 하며, 이는 롤업의 롤업의 수익 구조를 변경할 수 있습니다. 어떻게 변경될지는 불분명합니다. -
   시장을 분류하면 기존 빌더가 ToB 공간을 구매할 수 있게 되어 롤업의 수익이 증가할 수 있습니다

중요 참고: 크로스 롤업 번들은 아토믹 실행을 보장하지만, 번들의 일부를 생성하는 슈퍼 빌더가 없다면, 이러한 번들을 어떻게 구축할지 이러한 번들이 어떻게 빌드될지 불분명하므로 원자 실행 자체는 상호 운용성에 영향을 미치지 않을 것입니다. 기본적으로 공유 시리얼라이저/슈퍼빌더는 블록 수준의 컴포저빌리티를 구축해야 합니다.

5. 블록 수준 컴포저빌리티

필요 인프라:

공유 시퀀서 // 슈퍼빌더 // 증명 어그리게이션 레이어* // 공유 브리지 컨트랙트*

(* = 선택 사항)

공유 시퀀서 및 공유 결제 레이어에 대한 대부분의 논의에서 이러한 수준의 상호운용성을 설명하는 데 일반적으로 사용되는 용어는 다음과 같습니다. "동기식 컴포저빌리티"입니다.

이 용어를 좀 더 명확하게 설명하기 위해 약간 수정했습니다. 이 용어를 "블록 수준 구성 가능성"으로 업데이트하면 다음 블록에 포함되고 성공적으로 실행될 두 롤업 간의 교차 롤업 트랜잭션 패키지를 결합할 수 있다는 뜻입니다. 동기식 구성 가능성은 다음 섹션에서 살펴볼 트랜잭션 수준 구성 가능성과 혼동될 수 있습니다. 중요한 점은 종속 트랜잭션 패키지의 실행자이자 생성자가 될 수 있는 중간 당사자(공유 주문 인프라)가 필요하다는 것입니다.

이 수준에서는 단순히 다른 롤업의 디앱에 참여하기 위해 자신을 보내는 것이 아니라 롤업 간의 진정한 구성 가능성을 보기 시작합니다.

거래를 생성할 수 있는 공유 시퀀서를 추가함으로써 이제 개발자가 프로그래밍 방식으로 활용할 수 있는 교차 집계 패키지를 만들 수 있습니다.

다음 두 가지 시나리오를 고려할 수 있습니다.

1. 블록 수준 컴포저빌리티

2. 블록 수준 컴포저빌리티 + 공유 정산 레이어

두 경우 모두 더 복잡한 활동을 위해 교차 집계 번들을 만들 수 있지만 두 번째 경우 공유 정산을 사용하면 예를 들어 네이티브 에셋을 사용하면 교차 집계 DEX 캠페인에 더 나은 가격 영향을 미칠 수 있습니다.

블록 수준의 구성성을 통해 아토믹 실행의 장점과 트랜잭션 종속 번들을 생성할 수 있는 추가 기능을 모두 갖추게 됩니다. 두 가지 예시를 살펴보겠습니다.

xERC-20을 통해 동일한 토큰 전송하기(공유 결제 없음):

1. 사용자 소유 ERC-. 20

2. 사용자가 dapp을 통해 tx를 생성합니다:
   → xERC-20 패키지 버전을 받기 위해 xERC-20 락박스에 ERC-20을 저장합니다
   → xERC-20을 파괴합니다
   → 공유 정렬 인프라에 크로스 롤업 전송이 이루어졌음을 나타내는 메시지를 보냅니다. 교환을 용이하게 하기 위해 관련 데이터와 함께 크로스 롤업 전송을 시작

3. 슈퍼빌더가 트랜잭션을 픽업하여 크로스 롤업 번들 생성
   → Tx 1: 위에서 설명한 대로 트랜잭션 패키징 및 파기
   → Tx 2 : 롤업 B에 xERC-20 캐스팅

4. 슈퍼빌더가 이 크로스 롤업을 공유 시퀀서에 제출
   → 슈퍼빌더는 연결된 두 롤업의 전체 노드를 실행 중이므로 트랜잭션을 시뮬레이션하여 번들이 완료되었는지 확인합니다. 번들이 성공적으로 실행되는지 확인하기 위해 트랜잭션을 시뮬레이션합니다. 트랜잭션 중 하나라도 롤백되면 전체 번들이 롤백됩니다.

5. 공유 시퀀서는 두 트랜잭션이 포함된 블록을 DA 레이어와 상태 변경을 수행한 노드에 제출합니다

6. 롤업 B에서 xERC-20 캐스팅을 수행합니다. 사용자에게

공유 결제 레이어를 사용하면 교환을 위해 먼저 ERC-20을 xERC-20으로 패키징할 필요가 없으므로 프로세스가 더욱 간소화됩니다.

이제 롤업 A의 초기 (다른) ERC-20으로 롤업 B에서 ERC-20을 구매하고 결과물인 ERC-20을 롤업 A로 다시 보내는 교차 롤업 지정가 주문을 살펴봅시다. 공유 정산 레이어가 있다고 가정하지는 않지만, 공유 정산 레이어의 경우에도 유사한 프로세스가 존재합니다. 유일한 차이점은 자산의 추가적인 외부 래핑이 필요하지 않다는 점입니다.

이 경우 필요한 트랜잭션은 다음과 같습니다:

1. A의 ERC-20 패키징 및 파기

2. B에 xERC-20 발행

3. B의 초기 xERC-20을 대상 ERC-20으로 교환

< li>

B의 대상 ERC-20을 패키징하고 파기

4. A의 xERC-20을 채굴

가능한 작업 흐름은 다음과 같습니다:





흐름:

1. 사용자가 첫 번째 거래를 시작합니다:
   →xERC-20을 패킹 및 소멸하고 거래소의 매개 변수(대상 체인, DEX 주소, 교환할 ERC-20, 지정가 주문의 가격, 반송 여부의 부울 값)를 지정하는 메시지를 전송합니다. )

2. 슈퍼빌더가 트랜잭션을 확인하고 번들을 생성합니다:
   → Tx 1: 사용자가 위 트랜잭션 생성
   → Tx 2: 목적지에서 xERC-20 캐스팅(슈퍼빌더는 캐스팅 권한이 있어야 함)
   → Tx 3: 위 교환을 사용하여 xERC-20을 소멸(슈퍼빌더는 캐스팅 권한이 있어야 함)

   → Tx 4: 제한 주문이 완전히 이행되었다고 가정하여 B에서 ERC-20을 패킹 및 파괴하고 소스 체인에 캐스팅하라는 메시지 전송
   → Tx 5: 소스 체인에 거래소 출력에서 대상 xERC-20의 캐스팅

< p style="text-align: left;">슈퍼빌더는 블록을 생성하고 트랜잭션을 시퀀싱하기 때문에 각 트랜잭션을 시뮬레이션하고 어떤 트랜잭션이 취소될 때 번들을 생략할 수 있습니다. 예를 들어 사용자가 지정가 주문을 완전히 이행할 수 없는 것으로 확인되면 블록이 실행되기 전에 번들이 생략됩니다.

공유 청산 계층이 있는 공유 주문 인프라가 없는 상황에서 외부 랩드 버전의 이더리움 및 xERC-20을 사용하면 랩드 자산의 유동성 풀이 얇아져 DEX의 시장 상황이 악화될 수 있습니다. 이 경우 사용자는 더 낮은 한도를 사용해야 하고 슬리피지 허용치가 높아지며 최적의 가격보다 낮은 가격을 받을 수 있습니다. USDC가 관여할 때는 예외가 있습니다. 공유 정산이 없는 공유 시퀀서는 롤업 전반에서 USDC 계약에 대한 독점 권한을 얻기 위해 Circle과 협력하여 롤업 전반에서 네이티브 USDC 전송 및 교환을 촉진할 수 있습니다.

공유 청산 레이어를 사용하면 이러한 외부 래퍼가 필요하지 않으며 네이티브 자산 스왑을 위한 더 깊은 유동성 풀로 인해 더 나은 가격을 제공할 수 있지만, 프로세스는 본질적으로 동일합니다.

시퀀서를 낙관적으로 신뢰

롤업은 효과적인 크로스 롤업 번들을 생성하기 위해 공유 시퀀서/슈퍼 빌더를 낙관적으로 신뢰해야 합니다. 이는 주로 이 크로스 롤업 번들에는 블록이 각 롤업의 체인에 추가되고 L1의 결제 레이어에 집계될 때까지 개별 롤업에서 검증할 수 없는 종속 트랜잭션이 포함되어 있기 때문입니다. 예를 들어 소스에서 대상으로 이더를 처음 소멸하고 캐스팅하는 것을 들 수 있습니다. 소스 체인에서 이더를 물리적으로 소멸한 다음 목적지 체인에서 주조하는 것이 중요하며, 그렇지 않으면 이중 지불이 발생할 수 있습니다.

그러나 블록에서 이 완전한 번들을 실행하려면 트랜잭션이 블록 이전의 유효하지 않은 상태를 나타내더라도(예: 사용자가 블록 이전에 이더를 보유하고 있지 않더라도 거래소의 목적지 체인에 이더가 있는 경우) 모든 트랜잭션이 해당 블록에 존재해야 합니다. 따라서 시퀀서가 실제로 교차 집계 번들에 유효한 종속성을 포함한다는 확신이 있어야 합니다. 각 트랜잭션의 유효성을 입증하기 위해 나중에 증빙을 제출할 수 있습니다.

그러나 랩드 자산을 사용하는 경우 L1에 저장된 기본 유동성에 영향을 미치지 않으므로 이는 덜 중요하지만, 악의적인 시퀀서나 코드 오류의 위험을 상쇄할 수 있는 폴백 메커니즘이 있어야 트랜잭션 번들이 복원된 종속 거래로 실행될 수 있습니다.

이해관계자에 미치는 영향:

1. 사용자
   사용자 경험에 대규모 업그레이드가 이루어져 다음을 수행할 수 있게 되었습니다. 단일 블록에서 교차 집계 지정가 주문

2. 개발자
   는 교차 롤업 활동을 인지해야 하며 사용자 지정 사전 컴파일을 활용하고 싶을 수 있습니다. 개발자는 트랜잭션뿐만 아니라 번들의 관점에서 생각해야 하지만, 슈퍼 빌더와 사용자 정의 롤업 인프라는 대부분의 개발자에게 복잡성을 제거할 수 있습니다.

3. MEV 검색자
   MEV 검색자는 교차 집계 번들에서 L1 전략을 사용할 수 있는 기회는 기본적으로 동일하지만, PBS(제안자-빌더 분리)가 어떻게 구현되는지에 따라 달라집니다.
   → 교차 집계 번들은 본질적으로 개별 거래로 취급되므로 가격이 허용 가능한 슬리피지 이상으로 밀리지 않는 한(그러면 전체 번들이 회복되고 MEV 시도가 실패하기 때문에) 거래를 선점하거나 고정하여 MEV를 찾을 수 있습니다

4. 롤업
   은 공유 시퀀싱 인프라(슈퍼빌더 포함)에 옵트인해야 하며, 공유 정산 레이어의 경우 공유 시퀀서에서 이더 소멸/캐스팅에 대한 액세스가 허용되어야 합니다.
   → 블록 공간을 빌더에게 판매하여 MEV를 내재화할 수 있음

6. 거래 수준 구성성

필요한 인프라:

VM 레벨 변경 // 공유 결제 // 슈퍼빌더

거래 수준 구성 가능성은 EVM 체인에서 스마트 콘트랙트가 공유하는 동일한 수준의 기능을 의미합니다. 이 경우 단일 트랜잭션이 여러 롤업의 상태를 동시에 업데이트할 수 있으며, 호출이 실패할 경우 호출 이전의 모든 상태 변경을 되돌릴 수 있습니다. 사실상 블록 수준 컴포저블 환경의 원자 트랜잭션 패키지는 단일 교차 롤업 및 교차 VM 트랜잭션으로 완료될 수 있습니다. 이를 위해서는 공유 결제 레이어와 슈퍼 빌더 외에도 연결된 모든 롤업에 대한 VM 수준의 변경이 필요합니다.

여기에서는 한 가지 가능한 메커니즘을 높은 수준에서 설명합니다. (저희가 아는 한, 이 구조는 Espresso 팀에서 만든 것입니다). 먼저, 사용자는 트랜잭션에 의해 상태가 변경된 모든 롤업 또는 모든 관련 롤업에 블록을 빌드할 수 있는 슈퍼빌더에 크로스 롤업 트랜잭션을 제출합니다. 슈퍼 빌더는 트랜잭션을 시뮬레이션하고 각 관련 롤업에 대해 하나씩 입력-출력 쌍의 목록을 형성하며, 이 목록은 트랜잭션에서 필요하고 예상되는 크로스 롤업 메시지를 지정합니다. (슈퍼 빌더는 일정 기간 동안 모든 관련 롤업에 대한 보안 주문 권한이 있는 경우에만 이 작업을 수행할 수 있습니다.) 그런 다음 슈퍼 빌더는 각 롤업 트랜잭션에 대해 예상되는 입출력 쌍 목록과 함께 시뮬레이션된 블록을 각 롤업 제안자에게 보냅니다. 롤업이 실행되는 동안 각 롤업은 인터롤업 트랜잭션 목록의 입력이 정확하다고 가정하고 자체 상태 전환 함수를 정상적으로 실행합니다. 정산 중에는 공유 정산 계층의 증명 집계 단계에서 입력 목록과 출력 목록을 교차 비교하고 안전성을 증명할 수 있습니다. 특히, 크로스 롤업 트랜잭션의 예상 입력 중 하나가 다른 롤업에서 지정한 출력과 일치하지 않으면 정산 프로세스는 전체 크로스 롤업 트랜잭션을 거부합니다.

플래시 렌딩 외에 트랜잭션 수준의 구성성을 통해 잠금 해제할 수 있는 새로운 기능은 제한적이지만, 개발자의 크로스 롤업 앱 제작 경험은 크게 개선될 수 있습니다. 크로스 롤업 번들에 대해 고민할 필요 없이 모든 연결 체인과 상호작용하는 디앱을 만들 수 있게 되면 멀티 롤업 환경에서 훨씬 더 쉽게 혁신할 수 있게 될 것입니다. 또한 새로운 사용 사례와 행동 방식이 등장할 가능성이 높습니다.

트랜잭션 수준 컴포저빌리티와 관련하여 아직 해결되지 않은 설계 문제가 많이 있습니다. 첫째, 개발자가 롤업 콜에서 스마트 컨트랙트에 참여하거나 탈퇴하는 방법을 신중하게 고려해야 합니다. 임의의 구성 가능성을 제한 없이 허용하는 것은 단일 롤업으로 돌아가는 것을 의미하며, 개발자가 계약의 특정 진입점을 솔리디티 수정자를 통해 호출 가능한 크로스 롤업으로 표시하는 등 계약에서 크로스 롤업 구성 가능성이 필요한 위치를 명시적으로 표시하도록 하는 것이 해답이라고 생각합니다(예: "composable").

이해관계자에 미치는 영향

1. 사용자:
   블록 수준 구성 가능성과 동일하며, 블록 수준 구성 가능성과도 동일합니다. 플래시 대출과 같은 다른 고급 기능과 함께 블록 레벨 구성 가능성과 동일함
   → UX는 단일 체인을 사용하는 옵트인 디앱과 거의 동일

2. 개발자: 디앱 개발자는 로컬에서 컨트랙트 교차 집계를 호출하고 해당 호출의 출력을 사용할 수 있기 때문입니다. (예: 단일 집계 호출), 개발자 환경이 크게 개선됨 → 슈퍼빌더/시퀀서 인프라는 여전히 교차 집계 호출의 영향을 받는 집계 블록에 트랜잭션을 배치해야 하지만 블록 수준의 구성성을 위해 동일한 번들을 구축할 필요는 없음 → 슈퍼빌더/시퀀서 인프라는 여전히 트랜잭션을 배치해야 하지만 블록 수준의 구성성을 위해 동일한 번들을 구축할 필요는 없습니다.

3. MEV 검색자:
   크로스 롤업 번들은 이제 본질적으로 체인에서 단일 트랜잭션과 동등하므로 MEV 잠재력이 높습니다

4. 롤업:
   공유 시퀀서 및 공유 결제 레이어의 선택뿐만 아니라 VM 수준의 변경이 필요함
   →증명을 통해 상태를 검증하기 전에 다른 롤업의 입력 및 출력을 신뢰해야 하며, 이는 추가적인 신뢰 가정을 포함하지만 컷백 메커니즘은 신뢰 부담을 완화할 수 있음

요약 및 생태계 다이어그램

여기에 정의된 각 상호운용성 수준에 대한 기술적 세부 사항을 이해한 후 요약하면 다음과 같습니다.

1. 공유 정산은 외부 랩핑 자산 없이 교차 롤업 교환을 허용하고 연결된 모든 롤업 간에 프로토콜 내 메시징 경로를 생성합니다

2. 공유 정렬/  슈퍼빌더는 크로스 롤업 번들에 대한 다음 블록 실행 보장을 허용

3. 블록 수준의 구성성을 통해 복잡하고 빠르며 상호 의존적인 크로스 롤업 번들을 생성하여 스마트 컨트랙트에 가까운 스마트 컨트랙트 수준의 구성성을 구현할 수 있습니다. 스마트 컨트랙트에서 스마트 컨트랙트 수준으로 구성 가능한 에코시스템.
   → 이러한 크로스 롤업 번들은 공유 결제를 추가하여 외부에서 패키지화된 자산을 사용하지 않고도 만들 수 있습니다

4. 거래 수준의 구성이 가능하며, 새로 오픈한 사용 사례는 보다 정교한 사용자들을 대상으로 하지만 크로스 어그리게이션 개발 경험을 획기적으로 확장할 수 있는 잠재력을 지니고 있습니다.

현재 이러한 기본적으로 상호 운용 가능한 생태계를 구축하는 것을 목표로 하는 여러 프로젝트가 등장하고 있습니다. 다음은 이 분야에 대한 개괄적인 개요입니다.

생태계 지도

<그림>



결론

이 백서에 설명된 프레임워크의 기술적 세부 사항에 대해 아직 미해결된 질문이 많이 남아 있습니다. 예를 들어, 블록 수준의 구성 가능한 에코시스템에서 교차 집계 지정가 주문을 위한 번들을 구축하려면 시장가 주문의 부분 체결 및 슬리피지 허용 오차를 처리하기 위해 보다 세부적인 설계가 필요할 수 있습니다. 주문이 완전히 체결되지 않았지만 설계 공간이 열려 있는 경우 교차 지정가 주문 번들을 복원하는 잠재적 솔루션을 여기에서 제공합니다.

또한, 이는 오늘날 애플리케이션 체인 공간에서 증가하는 아이디어 공유와 관련이 있다는 점에 주목할 필요가 있습니다. 애플리케이션 체인은 특정 관련 프로토콜을 단일 L2로 분리하기 위해 일반적이거나 라이선스가 부여된 롱테일 L2입니다. 블록 수준의 구성 가능성에 도달함에 따라, 연결된 모든 네트워크 간에 네이티브 구성 가능성을 갖는 애플리케이션 체인 환경도 상당한 주목을 받기 시작할 것으로 보입니다.

현재 이러한 애플리케이션 체인에 이동성을 도입하는 것은 여전히 어렵지만, 대규모 체인이 상호 운용 가능한 환경의 진입점으로 연결되면 공유 인프라를 중심으로 벽으로 둘러싸인 정원 생태계를 보게 될 가능성이 높습니다.

또 다른 중요한 미해결 과제는 슈퍼빌더 주변의 설계 공간을 어떻게 해결할 것인가입니다. 이 분야의 개발은 아직 초기 단계에 있으며, 가장 효율적인 방식으로 교차 집합 패키지를 만들 수 있는 복합 건축업자 네트워크를 만드는 방법은 아직 명확하지 않습니다. 이러한 교차 집계 패키지를 블록에 포함시키는 가장 좋은 방법과 집계 수익에 미치는 영향은 아직 미지수이며, 많은 팀에서 다양한 전략을 모색하고 있습니다.

미래에는 프로토콜 내 브리징 솔루션과 프로토콜 외 브리징 솔루션이 함께 작동하여 모두에게 더 나은 상호 운용 가능한 프로세스를 제공할 수 있을 것입니다. 이 백서에 정의된 진행 상황은 최종 사용자를 위해 롤업 전반에서 보다 원활한 상호운용성을 제공하는 데 주력하는 개발자와 빌더를 위한 가이드 역할을 할 수 있을 것으로 믿습니다.