바로 어제 수많은 사람들을 충격에 빠뜨린 일이 일어났습니다. Metamask 모회사인 Consensys가 출시한 이더 의 두 번째 계층인 Linea가 사전에 종료되었습니다. 관계자들은 이번 조치의 목적이 Velocore 해킹 사건의 영향을 줄이는 것이라고 밝혔습니다. 그리고 이는 해커 공격으로 인한 손실을 줄이기 위해 이전에 공식적인 조정 하에 BSC 체인(BNB 체인)이 종료되었음을 사람들에게 상기시키지 않을 수 없습니다. 사람들은 이런 이야기를 할 때마다 Web3가 주장하는 탈중앙화 가치에 대해 의심하게 될 것입니다.
물론, 위에서 언급한 사건의 핵심 이유는 인프라 자체의 불완전성, 즉 탈중앙화 부족에 더 있습니다 . 체인이 충분히 탈중앙화 되어 있다면, 한 순간에 멈춰서는 안 됩니다. 이더 의 두 번째 레이어의 독특한 구조로 인해 대부분의 레이어 2는 중앙 집중식 시퀀서에 의존합니다 . 최근 몇 년간 탈중앙화 순서 에 대한 논의가 점점 더 많아졌지만 두 번째 레이어의 목적과 구조를 고려할 때 가능성은 희박합니다. 레이어 2 순서 그다지 탈중앙화 되지 않을 가능성이 높으며 결국 BSC 체인만큼 탈중앙화 되지 않을 수도 있다고 간주할 수 있습니다. 정말 그렇다면 우리는 어떻게 해야 할까요?
실제로 두 번째 계층의 경우 순서 의 탈중앙화 로 인해 발생하는 가장 직접적인 피해는 검열 저항과 활동에 있습니다. 트랜잭션을 처리하는 엔터티(시퀀서)가 소수인 경우 서비스 제공 여부에 대한 절대적인 권한을 갖습니다. 원하는 경우 거부할 수 있으며 선택의 여지가 없을 수 있습니다. Layer 2의 검열 방지 문제를 어떻게 해결하느냐는 분명히 중요한 주제입니다.
지난 몇 년 동안 주요 이더 두 번째 계층에서는 Loopring 및 Degate, StarkEx의 강제 철수 및 탈출 해치 기능, Arbitrum 및 기타 OP Rollup의 Force Inclusion 기능과 같은 검열 방지 문제에 대한 다양한 솔루션을 제안했으며 이러한 방법은 검사를 생성할 수 있습니다. 이유 없이 사용자의 거래 요청을 거부하는 것을 방지하기 위해 특정 조건에서 시퀀서의 균형을 유지합니다.
오늘 기사에서 타이페이 이더 협회의 NIC Lin은 자신의 계정을 제공하고 4개의 주류 롤업의 검열 방지 트랜잭션 기능을 직접 실험했으며 워크플로 및 운영 방법과 같은 측면에서 Force Inclusion의 메커니즘 설계를 심층적으로 분석했습니다. 이는 이더, 엄청난 양의 자산을 보유하고 있는 커뮤니티와 대규모 투자자에게 특히 참고 가치가 있습니다.
거래 검토 및 강제 포함
블록체인에서는 거래 검열 저항(Censorship Resistance)이 매우 중요합니다. 블록체인이 사용자가 시작한 거래를 임의로 검토하고 거부할 수 있다면 Web2 서버와 다르지 않을 것입니다. 검열에 대한 이더 의 현재 트랜잭션 저항은 많은 수의 유효성 검사기에서 비롯됩니다. 누군가 Bob의 트랜잭션을 검토하고 그의 트랜잭션이 체인에 업로드되는 것을 방지하려면 네트워크의 대부분의 유효성 검사기에 뇌물을 주거나 스팸을 보내야 합니다. 블록 공간을 점유하기 위해 Bob보다 더 높은 처리 비용으로 정크 트랜잭션을 지속적으로 보냅니다. 어느 쪽이든 비용은 매우 높을 것입니다.
참고: 현재 이더리움의 PBS 구조에서는 거래 검토 비용이 많이 절감됩니다 . OFAC와 협력하여 Tornado Cash 거래를 검토하는 블록의 비율을 참고할 수 있습니다. 현재 검열 저항은 OFAC 및 정부 관할권 외부의 독립 검증자 및 중계자에 의존합니다.
하지만 롤업은 어떻습니까? Rollup은 보안을 보장하기 위해 많은 수의 검증자가 필요하지 않습니다. Rollup에는 블록을 생성하는 중앙 집중식 역할(Sequencer)이 하나만 있어도 L1만큼 안전합니다. 그러나 보안과 검열 저항은 서로 다른 것입니다. 롤업이 이더 만큼 안전하더라도 중앙 집중식 시퀀서 하나만 있으면 모든 사용자의 트랜잭션을 검열할 수 있습니다.
Sequencer는 사용자의 거래 처리를 거부하여 사용자의 자금이 보류되고 롤업을 떠날 수 없게 됩니다.
강제 포함 메커니즘
Rollup에 대량 의 탈중앙화 형 시퀀서를 요구하는 것보다 L1의 검열 방지 기능을 직접 활용하는 것이 더 좋습니다.
원래 Sequencer는 트랜잭션 데이터를 패키징하여 L1 Rollup 컨트랙트로 보내는 것입니다. 사용자가 스스로 트랜잭션을 Rollup 컨트랙트에 삽입할 수 있도록 컨트랙트에 설계를 추가하는 것이 더 좋습니다. 이 메커니즘을 "Force Inclusion"이라고 합니다. Sequencer가 L1 수준에서 사용자를 검열할 수 없는 한, 사용자가 L1에 트랜잭션을 강제로 삽입하는 것을 막을 수는 없습니다. 이런 방식으로 Rollup은 L1의 검열 저항성을 상속받을 수 있습니다.
시퀀서는 높은 비용을 지불하지 않고는 사용자의 L1 트랜잭션을 검토할 수 없습니다.
강제 거래는 어떻게 시행되어야 합니까?
Force Inclusion을 통해 트랜잭션을 Rollup 컨트랙트에 직접 기록할 수 있는 경우(즉, 즉시 적용) Rollup 상태가 즉시 변경됩니다. 예를 들어 Bob은 Force Inclusion을 통해 "1000 DAI를 Carol에게 전송"이라는 트랜잭션을 삽입합니다. 메커니즘이 거래가 즉시 적용되면 최신 상태에서 Bob의 잔액 1,000 DAI가 줄어들고 Carol의 잔액은 1,000 DAI가 더 많아집니다.
강제 포함이 롤업 계약에 트랜잭션을 직접 작성하고 즉시 적용되면 상태가 즉시 변경됩니다.
이때 Sequencer가 오프체인 트랜잭션도 수집하고 다음 트랜잭션 일괄 처리를 Rollup 컨트랙트로 보내는 경우 Bob이 강제로 삽입한 트랜잭션의 영향을 받아 즉시 적용될 수 있습니다. 이러한 종류의 문제는 가능한 한 피해야 하므로 Rollup은 일반적으로 Force Inclusion 트랜잭션을 즉시 적용하지 않고 먼저 사용자가 L1의 대기 대기열에 트랜잭션을 삽입하고 "준비 중" 상태로 들어갈 수 있도록 합니다. .
Sequencer가 오프체인 트랜잭션을 패키징하여 롤업 계약으로 보낼 때 앞서 언급한 트랜잭션을 트랜잭션 시퀀스에 삽입할지 여부를 선택합니다. Sequencer가 "준비 중" 상태에서 이러한 트랜잭션을 무시한 경우 창 기간이 끝난 후 사용자는 이러한 거래를 롤업 계약에 삽입할 수 있습니다.
시퀀서는 대기열에서 대기 중인 트랜잭션을 "실수로 수신"할 시기를 결정할 수 있습니다.
Sequencer는 여전히 대기 중인 대기열의 트랜잭션 처리를 거부할 수 있습니다.
Sequencer가 오랫동안 거부하는 경우 일정 시간이 지나면 누구나 Force Inclusion 기능을 통해 트랜잭션을 Rollup 컨트랙트로 강제할 수 있습니다.
다음으로 Optimism, Arbitrum, StarkNet 및 zkSync를 포함하여 잘 알려진 4가지 Rollup의 Force Inclusion 메커니즘 구현을 순서대로 소개하겠습니다.
낙천주의의 강제 포함 메커니즘
먼저 Optimism의 입금 프로세스를 소개하겠습니다. 이 입금은 Optimism에 돈을 입금하는 것뿐만 아니라 "사용자가 L2에 보낸 정보를 L2로 보내는 것"도 포함합니다. 새로 보관된 메시지를 받은 후 L2 노드는 실행을 위해 메시지를 L2 트랜잭션으로 변환하고 지정된 메시지 수신자에게 보냅니다.
L1 Deposit에서 L2 L1CrossDomainMessenger 계약으로의 사용자 메시지
사용자가 ETH 또는 ERC-20 토큰을 Optimism에 입금하려는 경우 프런트 엔드 웹 페이지를 통해 L1의 L1StandardBridge 계약과 상호 작용하여 입금할 금액과 이러한 자산을 받을 L2 주소를 지정합니다.
L1StandardBridge 계약은 메시지를 다음 레벨 L1CrossDomainMessenger 계약으로 전달합니다. 이 계약은 주로 L1과 L2 간의 상호 통신을 위한 구성 요소로 사용됩니다 . L1StandardBridge는 이 일반 통신 구성 요소를 통해 L2StandardBridge와 통신하여 토큰을 민트 할 수 있는 사람을 결정합니다. L2 코인 또는 L1에서 토큰을 잠금 해제할 수 있는 사람.
개발자가 L1과 L2 간의 상태를 전달하고 동기화하는 계약을 개발해야 하는 경우 L1CrossDomainMessenger 계약을 기반으로 구축할 수 있습니다.
사용자의 메시지는 CrossDomainMessenger 계약을 통해 L1에서 L2로 전달됩니다.
참고: 이 기사의 일부 그림에서는 CrossDomainMessager가 CrossChainMessager로 작성되었습니다.
Optimism포털 계약
그런 다음 L1CrossDomainMessenger 계약은 가장 낮은 수준의 OptimismPortal 계약으로 메시지를 보냅니다. 처리 후 OptimismPortal 계약은 TransactionDeposited 라는 이벤트를 발생시킵니다. 매개변수에는 "메시지를 보낸 사람", "메시지를 받은 사람"이 포함됩니다. 및 관련 실행 매개변수.
그런 다음 L2 Optimism 노드는 OptimismPortal 계약에 의해 발생한 Transaction Deposited 이벤트를 수신하고 이벤트의 매개변수를 L2 트랜잭션으로 변환합니다 . 이 트랜잭션의 개시자는 Transaction Deposited 이벤트 매개변수에 지정된 "메시지 발신자"가 됩니다. 트랜잭션 수신자는 이벤트 매개변수에서 "메시지를 받는 사람"이며, 다른 트랜잭션 매개변수도 위 이벤트의 매개변수에서 파생됩니다.
L2 노드는 OptimismPortalemit의 Transaction Deposited 이벤트 매개변수를 L2 트랜잭션으로 변환합니다.
예를 들어, 사용자가 L1StandardBridge 컨트랙트를 통해 0.01ETH를 입금한 후 이 메시지와 ETH가 OptimismPortal 컨트랙트(주소는 0xbEb5...06Ed)까지 전송된 후 L2로 변환되는 트랜잭션입니다. 몇 분 후 거래:
메시지의 개시자는 L1CrossDomainMessenger 계약이고, 수신자는 L2의 L2CrossDomainMessenger 계약입니다. 메시지 내용은 L1StandardBridge가 BoB의 0.01ETH 보증금을 받았다는 것입니다. 그 후, L2StandardBridge에 0.01 ETH를 추가로 발행하는 등 일부 프로세스가 실행되어 Bob에게 전송됩니다.
구체적으로 트리거하는 방법
Optimism의 Rollup 계약에 트랜잭션을 강제 적용하려는 경우 "L2 주소에서 L2에서 시작되고 실행되는 트랜잭션"이 원활하게 실행되도록 하는 효과를 얻으려면 L2 주소를 사용해야 합니다 . OptimismPortal 계약에 직접 메시지를 제출합니다. (OptimismPortal 계약은 실제로 L1에 있지만 OP의 주소 형식은 L1 주소 형식과 동일합니다. OP와 동일한 주소를 가진 L1 계정을 사용하여 위 계약을 직접 호출할 수 있습니다 . L2 계정 ).
컨트랙트에 의해 발생된 Transaction Deposited 이벤트에 의해 변환된 L2 트랜잭션의 "개시자"는 귀하의 L2 계정이 됩니다. 이때 트랜잭션 형식은 일반 L2 트랜잭션과 일치합니다.
Transaction Deposited 이벤트에서 변환된 L2 트랜잭션에서 개시자는 Bob 자신이 되며, 수신자는 Uniswap 계약이 되며 Bob 자신이 L2 트랜잭션을 시작한 것처럼 지정된 ETH가 수반됩니다.
Optimism의 Force Inclusion 기능을 호출하려면 OptimismPortal 컨트랙트의depositTransaction 함수를 직접 호출하고 L2에서 실행하려는 트랜잭션의 매개변수를 입력해야 합니다.
나는 간단한 Force Inclusion 실험을 수행했습니다. 이 트랜잭션은 한 가지를 달성하기를 원했습니다: 내 주소를 사용하여 L2(0xeDc1...6909)에서 자체 전송하고 "force inclusion"이라는 문자 메시지를 첨부했습니다.
OptimismPortal 컨트랙트를 통해 예금트랜잭션 함수를 실행하는 L1 트랜잭션입니다. Transaction Deposited 이벤트에서 from과 to가 모두 본인이라는 것을 알 수 있습니다.
나머지 불투명 데이터 열의 값은 "예금 거래 기능을 호출한 사람과 함께 제공되는 ETH의 양", "L2 거래 개시자가 수신자에게 보내고자 하는 ETH의 양", "L2 거래 GasLimit" 및 " L2 수신기의 데이터" 및 기타 정보.
위의 정보를 디코딩하면 다음을 얻게 됩니다.
"예금 거래를 호출한 사람이 ETH를 얼마만큼 첨부했는지": 0, L1에서 L2로 ETH를 입금하지 않았기 때문입니다.
"L2 거래 개시자가 수신자에게 얼마나 많은 ETH를 보내야 하는가" : 5566 (wei)
"L2 거래에 대한 GasLimit" : 50000
"L2 수신기용 데이터": 0x666f72636520696e636c7573696f6e. 이는 문자열 "force inclusion"의 16진수 인코딩입니다.
얼마 지나지 않아 변환된 L2 트랜잭션이 나타났습니다. 내가 나 자신에게 돈을 이체한 L2 트랜잭션, 금액은 5566 wei, 데이터는 "force inclusion" 문자열이었습니다. 그리고 그림의 마지막 줄에서 두 번째 줄에 있는 기타 속성의 TxnType(트랜잭션 유형)에 시스템 트랜잭션 126(시스템)이 표시되어 있음을 알 수 있습니다. 이는 이 트랜잭션이 L2에서 내가 시작한 것이 아니라 L1 트랜잭션에 의해 입금되었음을 의미합니다. . 이벤트에서 변환되었습니다.
변환된 L2 트랜잭션
L2 계약을 호출하고 Force Inclusion을 통해 다른 데이터를 전송하려면 이전 입금 트랜잭션 기능에 매개변수를 하나씩 입력하면 됩니다. L2 계정과 동일한 L1 주소를 사용하여 호출하면 됩니다. 예금 거래 기능을 통해 예금 이벤트가 L2 거래로 변환될 때 개시자는 L2 계정이 됩니다.
시퀀서 창
앞서 언급한 Optimism L2 노드는 Transaction Deposited 이벤트를 L2 트랜잭션으로 변환합니다. 실제로 이 Optimism 노드는 Sequencer를 참조합니다. 이는 결국 트랜잭션 순서 와 관련되므로 앞서 언급한 이벤트를 언제 변환할지를 Sequencer만이 결정할 수 있습니다 . L2 트랜잭션.
TransactionDeposited 이벤트를 수신할 때 Sequencer는 이벤트를 즉시 L2 트랜잭션으로 변환하지 않습니다. 이 기간의 최대값을 SequencerWindow라고 합니다.
현재 Optimism 메인넷의 Sequencer Window는 24시간입니다. 즉, 사용자가 L1에서 일정 금액을 입금하거나 트랜잭션을 강제 포함하면 최악의 시나리오는 24시간 후에 L2 트랜잭션 내역에 포함된다는 것입니다.
Arbitrum의 강제 포함 메커니즘
Optimism에서 L1의 Deposit 작업은 Transaction Deposited 이벤트를 발생시키고 나머지는 Sequencer가 위 작업을 수집할 때까지 기다리는 것입니다. 그러나 Arbitrum에서는 L1에서 발생하는 작업(돈을 절약하거나 L2에 메시지를 보내는 등) .)은 단순히 이벤트를 발생시키는 것이 아니라 L1에 저장됩니다.
Sequencer에는 위 대기열의 트랜잭션을 L2 트랜잭션 기록에 포함할 수 있는 기간이 제공됩니다. 시간이 다 됐을 때 Sequencer가 아무 작업도 하지 않으면 누구나 Sequencer를 위해 이를 완료할 수 있습니다.
Arbitrum은 L1 계약에서 대기열을 유지 관리합니다. 시퀀서가 대기열의 트랜잭션을 적극적으로 처리하지 않는 경우 시간이 다 되면 누구나 대기열의 트랜잭션을 L2 트랜잭션 기록에 포함하도록 강제할 수 있습니다.
Arbitrum의 설계에서는 L1에서 발생하는 입금과 같은 작업은 이름에서 알 수 있듯이 지연된 받은 편지함 계약을 거쳐야 합니다. 다른 계약은 바로 시퀀서 받은 편지함입니다. Sequencer는 L2 트랜잭션을 L1에 업로드합니다. Sequencer가 L2 트랜잭션을 업로드할 때마다 지연된 받은 편지함에서 일부 보류 중인 트랜잭션을 꺼내 트랜잭션 기록에 기록할 수 있습니다.
Sequencer가 새 트랜잭션을 작성할 때 DelayedInbox에서 트랜잭션을 꺼내 함께 쓸 수 있습니다.
복잡한 디자인과 광범위한 참고 자료
독자가 Sequencer 및 Force Inclusion에 대한 Arbitrum의 공식 장을 직접 참조하면 Force Inclusion이 대략적으로 작동하는 방식과 일부 매개변수 이름 및 함수 이름이 언급되어 있음을 알 수 있습니다.
사용자는 먼저 DelayedInbox 컨트랙트로 이동하여 sendUnsignedTransaction 함수를 호출합니다. Sequencer가 약 24시간 이내에 포함되지 않으면 사용자는 SequencerInbox 컨트랙트의 forceInclusion 함수를 호출할 수 있습니다. 그렇다면 Arbitrum 공식에서는 공식 웹사이트 문서에 해당 기능의 링크를 첨부하지 않았기 때문에 해당 기능은 계약 코드에서만 직접 볼 수 있습니다.
sendUnsignedTransaction 함수를 찾아보면 nonce 값과 maxFeePerGas 값을 직접 채워야 한다는 걸 알게 됩니다. nonce는 어떤 주소인가요? maxFeePerGas는 어느 네트워크에 있나요? 그것을 채우는 가장 좋은 방법은 무엇입니까? 파일 참조가 없으며 Natpsec도 없습니다. 그런 다음 Arbitrum 계약에서 비슷한 모양의 함수를 찾을 수도 있습니다.
SendL1FundedUnsignedTransaction, sendUnsignedTransactionToFork, sendContractTransaction, sendL1FundedContractTransaction, 이러한 함수 간의 차이점, 사용 방법, 매개 변수 입력 방법을 알려주는 문서는 없으며 Natpsec도 없습니다.
올바른 사용법을 찾을 수 있는지 확인하기 위해 시행착오를 거쳐 매개변수를 입력하고 트랜잭션을 보내려고 하지만 이러한 기능이 모두 L1 주소에서 AddressAliasing을 수행한다는 것을 알게 됩니다. , L2에서 최종 오류가 발생합니다. 트랜잭션을 시작할 때 보낸 사람은 단순히 다른 주소이므로 L2 주소는 움직이지 않습니다.
sendL2메시지
나중에 우연히 Google 검색을 클릭하여 Arbitrum에 L1에서 L2 트랜잭션을 보내는 방법(Force Inclusion의 의미)을 보여주는 스크립트가 포함된 Tutorial 라이브러리가 있다는 것을 알게 되었는데, 여기에 나열된 기능은 어떤 기능도 아닙니다. 위에서 언급했지만 sendL2Message 라는 함수와 message 매개변수는 실제로 L2 계정으로 서명된 트랜잭션인가요?
"Force Inclusion을 통해 L2로 전송된 메시지"가 실제로 "서명된 L2 트랜잭션"이라는 것을 누가 알았겠습니까? 그리고 이 기능을 언제 어떻게 사용하는지 설명하는 문서나 Natspec이 없습니다.
결론: Arbitrum 강제 트랜잭션을 수동으로 생성하는 것은 번거로운 일이며 공식 튜토리얼을 따르고 Arbitrum SDK를 실행하는 것이 좋습니다. 다른 롤업과 달리 Arbitrum에는 명확한 개발자 문서와 코드 노트가 있으며 많은 기능의 목적과 매개변수에 대한 설명이 부족하여 개발자가 액세스하고 사용하는 데 예상보다 더 많은 시간을 소비하게 됩니다. 저도 Arbitrum Discord에서 Arbitrum 분들에게 물어봤지만 만족스러운 답변을 얻지 못했습니다.
제가 Discord에서 문의했을 때 상대방은 sendL2Message만 보라고 하더군요. 그들은 다른 기능의 기능(Force Inclusion 문서에 언급된 sendUnsignedTransaction도 포함), 용도, 사용 방법에 대해 설명하고 싶어하지 않았습니다. , 그리고 언제 사용하는지.
StarkNet의 ForceInclusion 메커니즘
불행하게도 StarkNet에는 현재 ForceInclusion 메커니즘이 없습니다. 공식 포럼에는 검열과 ForceInclusion을 논의하는 기사가 두 개뿐입니다.
실패한 거래를 증명할 수 없습니다
위의 이유는 실제로 스타크넷의 영지식증명 시스템이 실패한 거래를 증명할 수 없어 강제 포함을 허용할 수 없기 때문입니다. 왜냐하면 누군가가 악의적으로(또는 의도하지 않게) 증명할 수 없는 실패한 트랜잭션을 강제 포함하면 StarkNet이 직접 중단될 것이기 때문입니다. 트랜잭션이 강제로 포함된 후 증명자는 실패한 트랜잭션을 증명해야 하지만 증명할 방법이 없기 때문입니다.
StarkNet은 버전 v0.15.0에서 실패한 트랜잭션을 증명하는 기능을 도입할 예정이며, 이후 강제 포함 메커니즘을 추가로 구현하는 것이 가능할 것으로 예상됩니다.
zkSync의 ForceInclusion 메커니즘
zkSync의 L1->L2 메시징 및 Force 포함 메커니즘은 MailBox 계약의 requestL2Transaction 함수를 통해 수행됩니다 . 사용자는 L2 주소, 호출 데이터, 추가 ETH 금액, L2GasLimit 값 등을 지정합니다. requestL2Transaction 이러한 매개변수는 L2 트랜잭션으로 결합된 다음 우선순위 대기열(PriorityQueue)에 배치됩니다. 트랜잭션이 패키징되어 L1에 업로드되면(commitBatches 함수를 통해) Sequencer는 우선순위 대기열에서 꺼낼 트랜잭션 수를 나타냅니다. L2 트랜잭션 기록을 함께 포함합니다.
zkSync 실행 중 포함은 형식상 Optimism과 매우 유사합니다. 단일 항목을 채우는 대신 개시자의 L2 주소(L1 주소와 일치)를 사용하여 관련 기능을 호출하고 정보(호출 수신자, 호출 데이터 등)를 채웁니다 . Arbitrum과 유사하지만 설계상 Arbitrum과 동일합니다. 대기열은 L1에 유지되며 Sequencer는 대기열에서 사용자가 직접 제출한 보류 중인 트랜잭션을 꺼내어 트랜잭션 기록에 기록합니다.
이 트랜잭션과 같이 zkSync의 공식 브리지를 통해 Deposit ETH로 이동하면 MailBox 계약의 requestL2Transaction 함수를 호출하여 Deposit ETH의 L2 트랜잭션을 우선 순위 대기열에 넣고 NewPriorityRequest 이벤트를 발생시킵니다 . 계약은 L2 트랜잭션 데이터를 바이트 문자열로 인코딩하기 때문에 읽기가 어렵습니다. 이 L1 트랜잭션의 매개변수를 보면 매개변수에 있는 L2의 수신자가 트랜잭션의 개시자이기도 함을 알 수 있습니다( 자신에게 Deposit되어 있기 때문에), 그래서 잠시 후 Sequencer에 의해 우선순위 큐에서 이 L2 트랜잭션이 꺼내져 트랜잭션 내역에 포함되면 L2에서 자신에게 전송되는 트랜잭션으로 변환되며, 그 금액은 이체는 L1 거래 개시자의 예금입니다. ETH 거래에 포함된 ETH의 양입니다.
L1Deposit 트랜잭션에서 트랜잭션 개시자와 수신자는 모두 0xeDc1...6909이고 금액은 0.03ETH이며 calldata는 비어 있습니다.
0xeDc1...6909의 트랜잭션이 L2에 나타납니다. 트랜잭션 유형(TxnType)은 255이며 이는 시스템 트랜잭션입니다. 그런 다음 이전 OP의 강제 트랜잭션 기능처럼 zkSync의 requestL2Transaction 함수를 직접 호출하고 자체 전송을 보냈습니다. ETH가 없으면 calldata에 "force inclusion" 문자열의 HEX 코드가 포함됩니다. 그런 다음 L2의 마지막 트랜잭션으로 변환됩니다. calldata는 "강제 포함"의 16진수 문자열입니다: 0x666f72636520696e636c7573696f6e.
Sequencer가 PriorityQueue에서 트랜잭션을 가져와 트랜잭션 기록에 기록하면 L2에서 해당 L2 트랜잭션으로 변환됩니다.
requestL2Transaction 기능을 통해 사용자는 동일한 L2 주소를 가진 L1 계정을 사용하여 L2 수신자, 동반 ETH 금액 및 통화 데이터를 지정하여 L1에 정보를 제출할 수 있습니다. 사용자가 다른 데이터로 다른 계약을 호출하려는 경우 requestL2Transaction 함수에 매개변수를 하나씩 입력하면 동일한 작업이 수행됩니다.
사용자가 강제로 포함할 수 있는 기능은 없습니다.
L2 트랜잭션이 우선순위 큐에 배치된 후 L2 트랜잭션이 Sequencer에 포함될 때까지의 대기 시간이 부수적으로 계산되지만, 현재 zkSync 설계에는 사용자가 강제로 적용할 수 있는 Force Inclusion 기능이 없습니다. 단지 절반 세트에 해당합니다 . 즉, "포함 대기 기간"이 있지만 실제로는 여전히 "시퀀서가 수익을 받기를 원하는지 확인"하는 것입니다. 시퀀서는 만료될 때까지 기다렸다가 트랜잭션을 수신하거나 전혀 트랜잭션을 수신할 수 없습니다. 우선순위 큐에 있습니다.
앞으로 zkSync는 소득 유효 기간이 지났지만 Sequencer에 포함되지 않은 경우 사용자가 해당 거래를 L2 거래 내역에 강제로 포함할 수 있도록 관련 기능을 추가해야 합니다. 이는 정말 효과적인 Force Inclusion 메커니즘입니다.
요약
L1은 네트워크의 "보안"과 "검열 저항"을 보장하기 위해 많은 수의 검증기에 의존합니다. Rollup은 소수 또는 단일 시퀀서를 사용하여 트랜잭션을 작성하며 검열 저항은 더욱 약합니다. 따라서 Rollup에는 사용자가 Sequencer를 우회하고 거래 내역에 기록하여 Sequencer의 검토를 피하고 Rollup에서 자금을 사용하거나 인출하는 것을 불가능하게 만드는 Force Inclusion 메커니즘이 필요합니다 .
강제 포함을 사용하면 사용자가 거래를 내역에 강제로 기록할 수 있지만 설계에서는 거래가 즉시 내역에 삽입되고 즉시 적용될 수 있는지 여부를 선택해야 합니다. 트랜잭션이 즉시 적용되도록 허용하면 Sequencer에 부정적인 영향을 미치게 됩니다. L2에서 수신 대기 중인 트랜잭션이 L1에서 강제로 수신한 거래소 에 의해 영향을 받을 수 있기 때문입니다.
따라서 현재 Rollup의 Force Inclusion 메커니즘은 먼저 L1에 삽입된 트랜잭션을 대기 상태로 전환 하고 Sequencer에 반응할 시간을 제공하고 이러한 보류 중인 트랜잭션을 포함할지 여부를 선택합니다.
zkSync와 Arbitrum은 모두 L1에서 큐 대기열을 유지하여 사용자가 L1에서 L2로 보낸 L2 트랜잭션이나 메시지를 관리합니다. Arbitrum은 DelayedInbox라고 하며 zkSync는 PriorityQueue라고 합니다.
그러나 zkSync가 L2 트랜잭션을 보내는 방식은 Optimism과 유사합니다 . 둘 다 L2 주소를 사용하여 L2 트랜잭션으로 변환한 후 L2 주소가 됩니다. L2 트랜잭션을 전송하는 Optimism의 기능은depositTransaction이라고 하며 zkSync는 requestL2Transaction이라고 합니다. Arbitrum은 완전한 L2 트랜잭션을 생성하고 서명한 다음 sendL2Message 기능을 통해 이를 전송합니다. Arbitrum은 L2 트랜잭션의 개시자로 L2의 서명을 통해 서명자를 복원합니다.
StarkNet에는 현재 Force Inclusion 메커니즘이 없습니다. zkSync는 Force Inclusion의 절반 세트와 같습니다 . PriorityQueue가 있고 대기열의 각 L2 트랜잭션에는 포함 유효 기간이 있지만 이 유효 기간은 현재 장식용입니다. 시퀀서는 PriorityQueue에 L2 트랜잭션을 전혀 포함하지 않도록 선택할 수 있습니다.
