이론과 실제: 이더 롤업에서 검열 저항 트랜잭션은 어떻게 트리거되나요?

저자: NIC Lin, 타이페이 이더리움 밋업 책임자

원제: "롤업의 강제 포함 메커니즘 소개"

어제 수많은 사람들에게 충격을 안겨준 일이 있었습니다: 메타마스크 모회사 컨센시스가 출시한 이더리움의 두 번째 티어인 Linea가 자발적으로 중단된 것입니다. 메타마스크의 모회사 컨센시스가 출시한 이더라인의 두 번째 티어인 리네아가 자발적으로 폐쇄되었으며, 공식적으로는 벨로코어 해킹의 영향을 줄이기 위한 조치였다고 주장했습니다. 이는 해킹 피해를 줄이기 위해 관계 당국이 조율했던 이전의 BNB 체인 셧다운을 연상시킵니다. 이런 일이 발생할 때마다 사람들은 Web3가 주장하는 탈중앙화 가치에 의구심을 품게 됩니다.

물론 위 사건의 핵심적인 원인은 다음과 같은 인프라 자체의 불완전성에 더 큰 원인이 있습니다. 충분히 탈중앙화되지 않음: 체인이 충분히 탈중앙화되어 있다면 멈추지 않아야 합니다. 이더의 레이어 2의 독특한 구조로 인해 레이어 2의 대부분은 중앙화된 시퀀서에 의존하고 있으며, 최근 몇 년 동안 탈중앙화된 시퀀서에 대한 주장이 커지고 있지만, 레이어 2의 존재 목적과 구조를 고려할 때 레이어 2의 시퀀서가 훨씬 더 탈중앙화되지 않을 가능성이 있다고 가정하는 것이 합당합니다. 보다 덜 탈중앙화될 수 있습니다. 만약 이것이 사실이라면 어떻게 해야 할까요?

사실, 레이어 2의 경우 비분산형 시퀀서의 가장 즉각적인 피해는 검열 저항과 활동입니다. 트랜잭션을 처리하는 엔티티(시퀀서)가 극소수인 경우, 시퀀서가 원하면 사용자를 거부할 수 있고 사용자가 이에 대해 할 수 있는 일이 없을 정도로 절대적인 권한을 보유하게 됩니다. 검열에 대한 Layer2의 저항을 어떻게 해결할 것인가는 분명 중요한 주제입니다.

지난 몇 년 동안 주요 이더넷 레이어 2는 검열 방지 문제에 대한 다양한 해결책을 제시해왔는데, 루프링과 디게이트, 스탁엑스의 강제 탈퇴 및 탈출 포드 기능, 아비트럼과 기타 OP 롤업의 강제 포함 기능 등은 특정 조건 하에서 다음과 같은 기능을 제공합니다. 시퀀서가 임의의 사용자의 트랜잭션 요청을 부당하게 거부하는 것을 방지하기 위해 견제와 균형을 만들 수 있습니다.

오늘의 글에서 타이페이 이더네트워크 협회의 NIC 린은 주류 롤업 4곳의 검열 방지 거래 기능을 직접 실험해보고, 워크플로우와 운영 방식 측면에서 강제 포함 메커니즘의 설계를 철저히 분석했으며, 이는 이더네트워크 커뮤니티와 막대한 자산을 보유한 대기업에 유용할 것입니다. 이는 특히 이더리움 커뮤니티와 대규모 자산을 보유한 대규모 투자자에게 유용합니다.

거래 검열 및 강제 포함

거래 검열 저항은 블록체인에 매우 중요하며, 블록체인이 사용자가 시작한 거래를 임의로 검열하고 거부할 수 있다면 이는 웹2.0 서버와 다를 바 없습니다. 이더의 현재 트랜잭션 검열 저항성은 수많은 검증자가 있기 때문에 누군가가 밥의 트랜잭션을 검열하고 블록체인에서 차단하려면 네트워크의 검증자 대부분을 매수하거나, 전체 네트워크에 스팸을 보내 밥보다 높은 수수료를 지불하고 쓰레기 거래를 계속 전송하여 블록의 공간을 차지할 수 있습니다. 어느 쪽이든 비용은 매우 높을 것입니다.

주: 이더리움의 현재 PBS 아키텍처에서는 트랜잭션 검열 비용이 상당히 낮을 것입니다(OFAC와 함께 토네이도 캐시 트랜잭션을 검열하는 블록의 비율을 참조하세요). 현재 검열 저항은 OFAC와 정부 관할권 밖에 있는 독립적인 검증자와 릴레이에 의존하고 있습니다.

그러나 롤업은 어떤가, 보안을 위해 많은 검증자가 필요하지 않으며 롤업이 블록을 생성하는 중앙화된 역할(시퀀서)만 가지고 있어도 L1만큼 안전할 것입니다. <하지만 보안과 검열 저항성은 별개의 문제이며, 롤업이 이더만큼 안전하더라도 중앙화된 시퀀서 하나만 있으면 사용자의 트랜잭션을 검열할 수 있습니다.

세컨서는 사용자의 트랜잭션 처리를 거부할 수 있으며, 그 결과 사용자의 자금이 롤업에서 이탈하지 못하도록 보류

강제 포함 메커니즘

요구 사항 롤업이 많은 수의 탈중앙화 시퀀서를 가지려면 L1의 검열 저항성을 활용하는 것이 좋습니다 :

원래 시퀀서는 트랜잭션 데이터를 L1의 롤업 컨트랙트에 패키징하기 위한 것이므로 사용자가 직접 트랜잭션을 삽입할 수 있는 디자인을 계약에 통합하는 것이 더 좋을 것입니다. 이 메커니즘을 "강제 포함"이라고 합니다. 시퀀서가 L1 수준에서 사용자를 검열할 수 없는 한, 사용자가 L1 수준에서 트랜잭션을 강제 삽입하는 것을 막을 수 없습니다. 이러한 방식으로 롤업은 L1의 검열 저항성을 상속받습니다.

비용이 많이 들지 않는 한 시퀀서는 사용자의 L1 트랜잭션을 검토할 수 없습니다

강제 거래는 어떻게 작동해야 하나요?

강제 포함을 통해 트랜잭션을 롤업 컨트랙트에 직접 기록하도록 허용하면(즉, 즉시 효력이 발생하면) 롤업의 상태가 즉시 변경됩니다. 예를 들어 Bob이 "1,000 DAI를 Carol에게 전송"이라는 트랜잭션을 강제 포함을 통해 삽입하면 롤업의 상태가 즉시 변경됩니다. 예를 들어, 강제 포함 메커니즘을 통해 "1000 다이를 캐롤에게 전송"이라는 트랜잭션을 삽입하는 경우, 트랜잭션이 즉시 적용되면 최신 상태의 밥의 잔액은 1000 다이가 줄어들고 캐롤의 잔액은 1000 다이가 늘어납니다.

강제 포함이 트랜잭션을 롤업 컨트랙트에 직접 기록하여 바로 적용되도록 할 수 있다면, 상태는 다음과 같이 즉시 변경

이 시점에서 시퀀서가 체인 아래로 트랜잭션을 수집하고 다음 트랜잭션 배치를 롤업 컨트랙트로 전송하는 경우, 밥의 강제 포함에 의해 즉시 영향을 받을 수 있습니다. 이는 피해야 할 문제이므로 롤업은 강제 포함 트랜잭션을 즉시 효력을 발생시키지 않고 대신 사용자가 트랜잭션을 L1의 대기 대기열에 삽입하고 "준비" 상태로 진입할 수 있도록 합니다.

시퀀서는 오프체인 트랜잭션을 롤업 컨트랙트에 패키징할 때 트랜잭션 시퀀스에 포함할지 여부를 선택하며, 시퀀서가 "준비" 상태의 트랜잭션을 계속 무시하는 경우, 사용자는 윈도우가 만료된 후 해당 트랜잭션을 강제로 큐에 포함시킬 수 있습니다. 시퀀서가 "준비됨" 상태의 트랜잭션을 계속 무시하는 경우, 윈도우가 종료되면 사용자는 해당 트랜잭션을 롤업 컨트랙트에 강제로 포함시킬 수 있습니다.

서퀀서는 대기 대기열에 있는 트랜잭션을 "드롭"할 시기를 결정할 수 있습니다

서퀀서는 여전히 대기 대기열의 트랜잭션 처리를 거부할 수 있습니다

Sequencer는 여전히 대기 대기열의 트랜잭션을 거부할 수 있습니다

시퀀서가 장시간 거부할 경우, 일정 시간이 지나면 누구나 강제 포함 기능을 통해 트랜잭션을 롤업 컨트랙트로 강제 포함시킬 수 있습니다

다음으로 옵티미즘을 차례로 다뤄보겠습니다, 아비트럼, 스타크넷, zk싱크 순으로 다뤄보겠습니다.

옵티미즘의 강제포섭 메커니즘

먼저, 옵티미즘에 돈을 입금하는 것뿐만 아니라 다음을 포함하는 옵티미즘의 입금 프로세스를 소개합니다. "이 디파짓은 단순히 옵티미즘에 돈을 입금하는 것뿐만 아니라 사용자가 L2에 메시지를 보내고, L2 노드가 새로 입금된 메시지를 받으면 이를 L2 트랜잭션으로 변환하여 실행한 후 메시지에 지정된 수신자에게 전송하는 과정도 포함하고 있습니다.

사용자가 L1 예금에서 L2로 보내는 메시지

L1CrossDomainMessenger 컨트랙트

사용자가 이더 또는 ERC-20 토큰을 옵티미즘에 입금하려는 경우.

사용자가 옵티미즘에 ETH 또는 ERC-20 토큰을 입금하려면 프론트엔드 웹페이지를 통해 L1의 L1StandardBridge 컨트랙트와 상호작용하여 입금할 금액과 해당 자산을 받을 L2 주소를 지정합니다.

그런 다음 L1StandardBridge 컨트랙트는 L1과 L2가 서로 통신하기 위한 구성 요소 역할을 하는 다음 단계의 L1CrossDomainMessenger 컨트랙트로 메시지를 전달하고, L1StandardBridge 컨트랙트는 다시 다음 단계의 L1CrossDomainMessenger 컨트랙트로 메시지를 전달합니다. 그런 다음 L1StandardBridge는 이 공통 통신 구성 요소를 사용하여 L2의 L2StandardBridge와 통신하여 누가 L2에서 토큰을 발행할 수 있는지 또는 누가 L1에서 토큰을 잠금 해제할 수 있는지 결정합니다.

개발자가 L1과 L2 간에 상호 운용하고 상태를 동기화하는 컨트랙트를 개발해야 하는 경우, L1CrossDomainMessenger 컨트랙트 위에 구축할 수 있습니다.

사용자의 메시지는 CrossDomainMessenger 계약을 통해 L1에서 L2로 전달됩니다주: 이 문서의 일부 이미지에서 CrossDomainMessager는 CrossChainMessager로 작성되었습니다

OptimismPortal 컨트랙트

그러면 L1CrossDomainMessenger 컨트랙트는 메시지를 전송합니다. 메시지를 맨 아래 OptimismPortal 컨트랙트로 전송하고, 이 컨트랙트는 "발신자", "수신자", "수신자", "수신자", "수신자", "수신자", "수신자", "수신자", "수신자", "수신자", "수신자", "수신자", "수신자"라는 매개변수와 함께 TransactionDeposited 이벤트를 던지게 됩니다. ", "수신자" 및 관련 실행 매개변수입니다.

그런 다음 L2 Optimism 노드는 OptimismPortal 컨트랙트가 던진 Transaction Deposited 이벤트를 수신하고 이벤트의 파라미터를 L2 트랜잭션으로 변환하여 트랜잭션에 의해 시작됩니다. 이 트랜잭션의 개시자는 Deposited 이벤트 파라미터에 지정된 "발신자"가 되고, 트랜잭션의 수신자는 이벤트 파라미터의 "수신자"가 되며, 다른 트랜잭션 파라미터는 위 이벤트의 파라미터에서 파생됩니다.

L2 노드는 옵티미즘 포털밋의 트랜잭션 입금 이벤트 파라미터를 L2 트랜잭션으로 변환합니다

예를 들어 사용자가 L1StandardBridge 컨트랙트를 통해 입금한 0.01 ETH 트랜잭션을 살펴봅시다. 이 메시지와 이더리움은 옵티미즘 포털 컨트랙트(주소 0xbEb5...06Ed)까지 이동한 후 몇 분 후 L2 트랜잭션으로 변환되었습니다.

메시지 개시자는 L1CrossDomainMessenger 컨트랙트입니다; 수신자는 L2의 L2CrossDomainMessenger 컨트랙트이며, 메시지는 L1StandardBridge가 BoB로부터 0.01 ETH를 입금 받았다는 내용입니다. 그러면 L2StandardBridge에 0.01 ETH를 추가로 전송하는 등의 프로세스가 트리거되고, 이 프로세스는 이를 Bob에게 전달합니다.

이것이 정확히 어떻게 일어나는가

옵티미즘의 롤업 컨트랙트로 트랜잭션을 강제하려면 다음을 수행하고자 하는 것이 좋습니다. "L2의 L2 주소에서 시작되어 실행될" 트랜잭션이 실행될 수 있다면, 귀하는 L2 주소로 OptimismPortal 컨트랙트에 직접 메시지를 제출해야 합니다 (OptimismPortal 컨트랙트는 실제로 L1에 있지만 OP는 L2에 있다는 점에 유의하세요). OP의 주소 형식은 L1 주소 형식과 동일하며, L2 계정과 동일한 주소를 가진 L1 계정으로 위의 컨트랙트를 직접 호출할 수 있습니다).

컨트랙트가 트랜잭션 입금 이벤트를 발생시키면 L2 트랜잭션의 '개시자'는 여러분의 L2 계정이 되며, 트랜잭션 형식은 일반 L2 트랜잭션과 동일합니다.

거래 입금 이벤트에서 변환된 L2 트랜잭션에서 개시자는 Bob 자신이고, 수취자는 유니스왑 계약이며, Bob이 직접 L2 거래를 개시한 것처럼 지정된 양의 ETH가 수반됩니다

만약에 옵티미즘의 강제 포함 함수를 호출하려면 옵티미즘 포털 컨트랙트의 입금 트랜잭션 함수를 직접 호출하여 L2에서 실행하려는 트랜잭션의 매개 변수로 채우는 것이 좋습니다

나는 간단한 강제 포함 실험을 했습니다. 포함 실험을 해봤는데요, "강제 포함"이라는 문자 메시지와 함께 L2에서 제 주소(0xeDc1...6909)로 돈을 자동 이체하는 것이었습니다.

옵티미즘 포털 컨트랙트를 통해 입금 트랜잭션 함수를 실행한 L1 트랜잭션이며, 이것이 던지는 트랜잭션 입금 이벤트에서 발신자와 수신자가 모두 저라는 것을 알 수 있습니다

불투명 데이터 열의 나머지 값은 "입금 트랜잭션 함수 호출에 첨부된 ETH의 양", "얼마나 많은 ETH가 호출에 첨부되었는지", "얼마나 많은 ETH가 ETH", "L2 트랜잭션 개시자가 수신자에게 보내는 이더리움의 양", "L2 트랜잭션 가스 제한", "L2 수신자에게 보내는 데이터". " 등입니다.

위 정보를 해독하면 다음과 같은 결과가 나옵니다.

"입금 트랜잭션을 호출한 사람이 얼마나 많은 이더를 첨부했는지": 0, L1에서 이더를 저장하지 않기 때문입니다. L2에 ETH 입금;

"L2 트랜잭션의 발신자가 수신자에게 보내야 하는 ETH의 양": 5566 (wei)

"L2 트랜잭션의 가스한도. ": 50000

"L2 수신자에게 보낼 데이터": 0x666f72636520696e636c7573696f6e, 즉 단어입니다. 문자열의 16진수 인코딩 "강제 포함"

그런 다음 변환된 L2 트랜잭션이 나타나는 데 오래 걸리지 않았습니다: 제가 직접 돈을 이체한 L2 트랜잭션, 금액은 5566위안이고 데이터는 다음과 같습니다. "강제 포함" 문자열이었습니다. 다이어그램의 두 번째 행에 있는 기타 속성의 TxnType에 시스템 트랜잭션 126이 표시되어 있는데, 이는 이 트랜잭션이 L2에서 내가 시작한 것이 아니라 L1 트랜잭션의 입금 이벤트에서 변환된 것임을 나타냅니다.

변환된 L2 트랜잭션

L2 컨트랙트를 호출하려는 경우 강제 포함을 통해 L2 컨트랙트를 호출하고 다른 데이터를 전송하려면 이전 입금 트랜잭션 함수에 파라미터를 하나씩 입력하기만 하면 되는데, 입금 트랜잭션 함수를 호출하려면 L1 계정과 동일한 L2 주소를 사용해야 한다는 점만 기억하면 됩니다. 가 L2 트랜잭션으로 변환될 때 개시자는 L2 계정이 됩니다.

SequencerWindow

앞서 언급한 Optimism L2 노드는 입금된 트랜잭션 이벤트를 L2 트랜잭션으로 변환하는데, 사실 이 Optimism 노드는 시퀀서를 가리키며, 결국 트랜잭션과 관련이 있습니다. 시퀀싱과 관련되어 있으므로 오직 Sequencer만이 앞서 언급한 이벤트를 언제 L2 트랜잭션으로 변환할지 결정할 수 있습니다.

트랜잭션 디포저드 이벤트를 수신할 때, 시퀀서는 반드시 이벤트를 바로 L2 트랜잭션으로 변환하는 것이 아니라 지연이 있으며, 그 최대값을 시퀀서 윈도우라고 합니다.

현재 Optimism 마스터의 시퀀서 윈도우는 24시간입니다. 현재 시퀀서 윈도우는 24시간으로, 사용자가 돈을 입금하거나 L1에서 트랜잭션을 강제 포함할 때, 해당 트랜잭션이 L2 트랜잭션 내역에 포함되기까지 최악의 경우 24시간이 걸립니다.

Arbitrum의 강제 포함 메커니즘

옵티미즘에서는 L1 입금 작업은 트랜잭션 입금 이벤트를 던지고 나머지는 시퀀서가 작업을 포함할 때까지 기다립니다. 그러나 아비트럼에서는 L1에서 발생하는 작업(돈을 입금하거나 L2로 메시지를 전달하는 등)은 단순히 이벤트를 던지는 것이 아니라 L1의 큐에 저장됩니다. .

시퀀서에게는 위 큐에 있는 트랜잭션들을 L2 트랜잭션 내역에 통합할 수 있는 시간이 주어지고, 그 시간까지 시퀀서가 아무것도 하지 않았다면 누구나 가서 시퀀서를 대신하여 트랜잭션을 처리할 수 있습니다.

Arbitrum은 L1 컨트랙트에서 큐를 유지합니다.

Arbitrum은 L1 컨트랙트에 큐를 유지하며, 시퀀서가 큐에 있는 트랜잭션을 적극적으로 처리하지 않을 경우, 때가 되면 누구나 큐에 있는 트랜잭션을 L2 거래 내역에 포함하도록 강제할 수 있습니다

Arbitrum의 설계는 L1에서 발생하는 입금 등의 작업은 이름 그대로 작업이 지연되는 계약인 지연된 인박스 계약으로 수행되고, 다른 계약은 작업이 지연되는 계약이 되도록 되어 있습니다. 또 다른 컨트랙트는 시퀀서 트랜잭션을 L2에서 L1으로 업로드하는 시퀀서 트랜잭션을 직접 수행하는 곳인 시퀀서 받은 편지함입니다. 시퀀서가 L2 트랜잭션을 업로드할 때마다 지연된 받은 편지함에서 보류 중인 트랜잭션을 가져와 트랜잭션 기록에 기록할 수 있습니다.

서퀀서가 지연된 수신함의 트랜잭션과 함께 새 트랜잭션을 작성복잡한 디자인 및 잘못된 참조

독자가 시퀀서 및 강제 포함에 대한 공식 Arbitrum 챕터를 직접 참조하면, 일반적으로 강제 포함이 어떻게 작동하는지, 그리고 일부 매개변수와 함수 이름이 언급되어 있음을 알 수 있습니다.

사용자는 먼저 DelayedInbox 섹션으로 이동합니다. DelayedInbox 컨트랙트로 이동하여 sendUnsignedTransaction 함수를 호출하고, 시퀀서가 약 24시간 이내에 이를 포함하지 않으면 사용자는 SequencerInbox 함수를 호출할 수 있습니다. 컨트랙트의 forceInclusion 함수를 호출할 수 있습니다. 그런데 아비트럼은 공식 문서에 해당 함수에 대한 링크를 첨부하지 않았기 때문에 컨트랙트 코드에서 해당 함수를 직접 확인해야 합니다.

송신자 서명되지 않은 트랜잭션 함수를 찾으면 논스 값과 가스당 최대 수수료 값을 입력해야 한다는 것을 알 수 있습니다. 어떤 주소에 대해 논스를 입력하고 어떤 네트워크에 대해 최대 가스당 수수료 값을 입력하는 가장 좋은 방법은 무엇인가요? 참고할 만한 문서가 없으며 심지어 Natpsec에서도 찾을 수 없습니다. 그런 다음 Arbitrum 콘트랙트에서 비슷한 모양의 함수를 찾을 수 있습니다:

sendL1FundedUnsignedTransaction, sendUnsignedTransactionToFork, sendContractTransaction, 그리고 이러한 함수의 차이점, 사용 방법, 매개변수 입력 방법을 알려주는 문서가 없으며, 심지어 Natpsec도 없습니다.

모든 함수를 올바르게 사용하는 방법을 알아내기 위해 시행착오를 겪으며 매개변수를 입력하고 트랜잭션을 보내보지만, 모든 함수가 L1 주소에 주소 앨리어싱을 수행하여 최종적으로 L2에서 트랜잭션을 시작할 때 발신자의 주소가 달라지고 L2 주소가 이동하지 않는 것을 발견하게 됩니다.

sendL2Message

그런 다음 우연히 구글 검색을 통해 Arbitrum 자체에 L1에서 L2 트랜잭션을 전송하는 방법(일명 강제 포함)을 보여주는 스크립트가 포함된 튜토리얼 라이브러리가 있다는 사실을 알게 되었습니다. 그리고 위에서 언급한 함수 대신 sendL2Message라는 함수가 나열되어 있고, 가져올 메시지 매개변수는 L2 계정으로 서명된 트랜잭션이라는 것을 알게 되었습니다.

"강제 포함을 통해 L2로 전송"할 메시지가 "서명된 L2 트랜잭션"일 줄 누가 알았겠습니까? 그리고 이 기능을 언제, 어떻게 사용해야 하는지 설명하는 문서나 Natspec도 없습니다.

결론: Arbitrum의 필수 트랜잭션을 수동으로 생성하는 것은 다소 까다롭기 때문에 공식 튜토리얼에서 Arbitrum SDK를 실행하는 것이 좋습니다. Arbitrum은 다른 롤업처럼 명확한 개발자 문서와 코드 노트가 없으며, 많은 함수의 용도와 매개변수에 대한 설명이 없기 때문에 예상보다 비용이 많이 들 수 있습니다. 많은 함수와 매개변수가 설명되어 있지 않아 개발자가 액세스하고 사용하는 데 예상보다 많은 시간이 걸립니다. 또한 Arbitrum 디스코드에서 Arbitrum 담당자에게 질문했지만 만족스러운 답변을 얻지 못했습니다.

디스코드에서 문의한 결과, 다른 함수(심지어 강제 포함 문서에 언급된 sendUnsignedTransaction도)가 무엇을 하는지, 어떻게 작동하는지, 언제 작동하는지에 대한 설명 없이 sendL2Message만 살펴보라는 답변만 들었습니다.

StarkNet의 강제 포함 메커니즘

아쉽게도 StarkNet은 아직 강제 포함 메커니즘을 가지고 있지 않습니다. 공식 포럼에 검열과 강제 포함에 대해 논의하는 글은 두 개뿐입니다.

실패한 트랜잭션을 증명할 수 없음

위와 같은 이유는 StarkNet의 영지식 증명 시스템에는 실패한 트랜잭션을 증명할 방법이 없기 때문에 강제 포함이 허용될 수 없으며, 누군가 악의적으로 (또는 의도하지 않게) 강제 포함하는 경우이기 때문입니다. 트랜잭션이 강제 포함되면 증명자가 실패한 트랜잭션을 증명해야 하는데, 그럴 방법이 없기 때문에 StarkNet은 꼼짝할 수 없게 됩니다.

스타크넷은 v0.15.0에서 실패한 트랜잭션을 증명하는 기능을 도입할 예정이며, 그 이후에는 강제 포함 메커니즘을 추가로 구현할 수 있을 것으로 예상됩니다.

zkSync의 강제 포함 메커니즘

zkSync의 L1-L2 메시징과 강제 포함 메커니즘은 MailBox 컨트랙트의 요청L2트랜잭션 함수를 통해 구현됩니다. 사용자는 L2 주소, 콜데이터, 추가 이더리움 양, L2GasLimit 값 등을 지정하면 요청L2트랜잭션은 이러한 파라미터를 L2 트랜잭션으로 결합한 다음 우선순위 큐(PriorityQueue)에 넣습니다. PriorityQueue), 시퀀서는 L1에 업로드된 트랜잭션에 (commitBatches 함수를 통해) 패키징되며, 어떤 방식으로 우선순위 큐에서 몇 개의 트랜잭션을 꺼내어 L2 트랜잭션 레코드에 함께 포함할지를 나타냅니다.

zkSync는 Arbitrum처럼 단일 트랜잭션을 채우는 것이 아니라, 관련 함수를 호출하기 위해 발신자의 L2 주소(L1 주소와 동일)를 가져와 정보(수신자, 호출 데이터 등)를 채운다는 점에서 강제 포함 형태는 Optimism과 매우 흡사합니다. 서명된 L2 트랜잭션이지만, L1에 큐를 유지하고 시퀀서가 사용자가 제출한 보류 중인 트랜잭션을 큐에서 직접 가져와 트랜잭션 기록에 기록하도록 하는 설계는 Arbitrum과 동일합니다.

zkSync의 공식 브릿지를 통해 이더 입금으로 이동하는 경우. 이 트랜잭션과 같이 공식 zkSync 브리지를 통해 이더를 입금하는 경우, 메일박스 컨트랙트의 requestL2Transaction 함수를 호출하여 이 이더 입금 L2 트랜잭션을 우선순위 대기열에 넣고 NewPriorityRequest 이벤트를 던질 것입니다. 컨트랙트는 L2 트랜잭션 정보를 바이트 문자열로 인코딩하기 때문에 읽기 쉽지 않으므로, 대신 이 L1 트랜잭션의 파라미터를 살펴보면 파라미터의 L2 수신자가 트랜잭션의 개시자이기도 하므로(자신에 대한 입금이기 때문에), 잠시 후 이 L2 트랜잭션을 Sequeuncer가 우선순위 큐에서 꺼내 트랜잭션의 기록에 포함하면 L2에서 자신에 대한 입금으로 변환하고 NewPriorityRequest 이벤트를 던지게 될 것입니다. 자신을 자신에게 이체하는 트랜잭션으로 변환되며, 이체된 금액은 트랜잭션의 발신자가 L1의 이더 입금 트랜잭션에서 가져온 이더의 양입니다.

L1Deposit 트랜잭션, 트랜잭션 발신자와 수신자는 모두 0xeDc1...6909, 금액은 0.03ETH, 호출 데이터는 비어 있습니다

L2에는 0xeDc1의 금액이 있을 것입니다. ...6909개의 자체 전송을 시스템 트랜잭션인 255의 트랜잭션 유형(TxnType)으로 저에게 전송했습니다

그리고 앞서 OP의 강제 트랜잭션 함수 실험에서 했던 것처럼 zkSync의 requestL2Transaction 함수를 직접 호출하여 자체 전송을 보냈습니다: ETH가 없으면 호출 데이터는 "강제 포함" 문자열의 HEX 인코딩을 가져옵니다.

그런 다음 호출 데이터에 "강제 포함" 헥스 문자열을 사용하여 L2에서 자체 전송 트랜잭션으로 변환됩니다: 0x666f72636520696e636c7573696f6e.

시퀀서가 우선순위 큐에서 트랜잭션을 가져와 트랜잭션 기록에 기록하면, L2에서 해당 L2 트랜잭션으로 변환됩니다

요청L2Transaction 함수를 통해 사용자는 L1 주소와 동일한 L1 계정을 사용하여 L2에 정보를 제출할 수 있습니다. L2 수신자, 첨부된 이더리움 수량, 콜 데이터를 지정하고, 다른 데이터로 다른 컨트랙트를 호출하고자 하는 경우 요청L2Transaction 함수에 파라미터를 하나씩 입력하는 방식으로 동일하게 수행됩니다.

강제 포함 함수는 아직 없습니다

L2 트랜잭션이 시퀀서에 포함되기 위한 대기 기간은 L2 트랜잭션이 우선순위 큐에 배치된 후 계산되지만, 현재 zkSync 설계에는 강제 포함 함수가 없습니다. 그러나 현재 zkSync 설계에는 사용자가 강제로 포함시킬 수 있는 강제 포함 기능이 없으므로 반쪽짜리 작업일 뿐입니다. 즉, "포함 대기 시간"이 있긴 하지만 실제로는 "포함 여부는 시퀀서에게 달려 있다"는 것입니다. 시퀀서는 만료 날짜까지 기다리거나 우선순위 큐에 더 이상 트랜잭션을 포함하지 않을 수 있습니다.

향후 zkSync에는 유효 기간이 만료되었지만 아직 시퀀서에 포함되지 않은 트랜잭션을 사용자가 L2 트랜잭션 기록에 강제로 포함시킬 수 있는 기능이 포함되어야 진정한 의미의 강제 포함 메커니즘이 될 것입니다.

요약

L1은 네트워크를 "보안"과 "검열 방지"로 유지하기 위해 많은 수의 검증자에 의존합니다. 롤업은 소수 또는 단일 시퀀서에 의해 작성되기 때문에 검열 저항성이 훨씬 낮습니다.

롤업은 사용자가 시퀀서를 우회하여 트랜잭션을 기록에 기록할 수 있도록 강제 포함 메커니즘이 필요하며, 시퀀서가 트랜잭션을 검토하지 못하게 하고 롤업에서 자금을 사용하거나 인출할 수 없게 합니다.

강제 포함을 사용하면 트랜잭션을 롤업의 기록에 강제로 포함할 수 있습니다. 강제 포함을 사용하면 사용자가 거래를 강제로 기록에 포함할 수 있지만, 거래를 즉시 기록에 삽입할지, 아니면 즉시 효력을 발생시킬지 선택할 수 있도록 설계되었습니다. 트랜잭션이 즉시 적용되도록 허용하면 수집 대기 중인 L2의 모든 트랜잭션이 L1에서 강제로 수집되는 트랜잭션의 영향을 받을 수 있으므로 시퀀서에 부정적인 영향을 미칠 수 있습니다.

따라서 현재 롤업의 강제 포함 메커니즘은 L1에 삽입된 트랜잭션이 먼저 대기 상태로 전환되도록 허용하고, 시퀀서가 반응하여 이러한 대기 트랜잭션을 포함할지 여부를 선택할 수 있는 시간을 제공합니다.

zkSync와 Arbitrum 모두 L1에서 L2 트랜잭션 또는 사용자가 L2로 보낸 메시지를 관리하는 큐를 L1에 유지합니다. arbitrum은 DelayedInbox, zkSync는 PriorityQueue라고 합니다. 는 L2 트랜잭션을 전송하는 방식이 옵티미즘과 유사하며, 둘 다 L2 주소에서 L1으로 메시지를 전송하므로 L2 트랜잭션의 발신자는 L2 트랜잭션으로 변환된 후 해당 L2 주소가 됩니다. Arbitrum은 완전한 L2 트랜잭션을 생성하고 서명한 다음 sendL2Message 함수를 통해 전송하고, 서명을 통해 서명자를 L2 트랜잭션의 발신자로 복원합니다.

StarkNet에는 아직 강제 포함 메커니즘이 없으며, zkSync는 우선순위 큐와 각 큐의 L2 트랜잭션이 포함되는 반쪽짜리 강제 포함을 수행합니다. 우선순위 큐가 있고 각 큐에는 L2 트랜잭션에 대한 만료 날짜가 있지만, 이 만료 날짜는 현재 장식용일 뿐이며 시퀀서는 실제로 우선순위 큐에 L2 트랜잭션을 전혀 포함하지 않도록 선택할 수 있습니다