StandardBridge,
CrossDomainMessenger 쌍, OptimismPortal 컨트랙트가 관련됩니다.
이 가이드가 적합한 대상
다음과 같은 경우 이 가이드를 사용하십시오.- L1에서 L2 작업을 시작하는 컨트랙트나 백엔드 인프라를 구축하는 경우. 예를 들어 사용자 지정 토큰 bridge, L1에서 제어하는 L2 컨트랙트, 또는 L2에 트랜잭션을 강제로 포함시킬 수 있어야 하는 프로토콜이 있습니다.
- 하나의 경로를 그대로 따르는 것이 아니라 어떤 컨트랙트 인터페이스를 기반으로 구축할지 선택해야 하는 경우.
시작하기 전에
다음이 준비되어 있어야 합니다.- Solidity 개발 환경과 Sepolia 및 OP Sepolia(또는 다른 OP Stack testnet)에서 자금이 있는 계정.
- 단일 체인에서 컨트랙트가 서로를 호출하는 방식에 대한 기본적인 이해. bridging 기초 가이드에서 기본 용어를 설명합니다.
1단계: 입금 경로 파악
어떤 인터페이스를 사용하든 모든 L1에서 L2로의 쓰기 작업은 결국OptimismPortal 컨트랙트의 depositTransaction 함수 호출로 끝납니다. 이 함수는
TransactionDeposited 이벤트를 발생시키고, rollup node는 이를 L2 트랜잭션으로
파생합니다. 입금 흐름 설명을 읽고 다음을
파악하십시오.
- 캡슐화 체인: 여러분의 컨트랙트가 messenger를 호출하고, messenger가 portal을
호출하며, portal이 이벤트를 발생시키고,
op-node가 이벤트를 L2 트랜잭션으로 변환합니다. 사용하는 각 레이어는 그 아래 레이어 위에 편의성과 안전성을 더합니다. - 입금은 sequencer의 재량이 아니라 파생(derivation)에 의해 포함됩니다. L1 트랜잭션이 확인되면 L2 트랜잭션은 반드시 실행됩니다.
sendMessage(target, message, minGasLimit) 인터페이스 형태, L1에서
L2로의 전달 시간이 1~3분이라는 점, 그리고 portal이 L1 gas를 소각하여 L2 실행
비용을 부과하는 방식을 파악하십시오.
2단계: 진입 레이어 선택
이것이 이후의 모든 것을 결정하는 선택입니다. 표를 위에서부터 차례로 살펴보고 처음으로 맞는 행에서 멈추십시오.
현재 컨트랙트 인터페이스는
contracts-bedrock 레퍼런스
또는
develop의 소스를 사용하십시오:
StandardBridge.sol,
CrossDomainMessenger.sol,
OptimismPortal2.sol.
OP Mainnet과 OP Sepolia의 배포 주소는
컨트랙트 주소 페이지에 있습니다.
사용자 지정 bridge가 필요하다고 판단했다면
사용자 지정 bridge 가이드를 읽고,
처음부터 새로 만들기보다 StandardBridge를 확장하라는 권장 사항과 bridged 토큰을
Superchain Token List에 등록해야 한다는 요구 사항을 파악하십시오.
3단계: 안전 관련 세부 사항 올바르게 처리
입금 경로의 세 가지 특성은 사용자 지정 통합에서 예상치 못한 문제를 일으킵니다. 코드를 작성하기 전에 설계를 각 항목과 대조해 확인하십시오.- 주소 aliasing. EOA가 아닌 컨트랙트가 입금을 시작하면, L2에서의
from주소는 L1 컨트랙트 주소에 일정한 오프셋을 더한 값이 됩니다. L2 컨트랙트가msg.sender를 L1 컨트랙트 주소와 비교한다면 aliasing된 형태로 비교해야 합니다. 입금 명세의 주소 aliasing을 읽고 오프셋 상수와 그것이 존재하는 이유를 파악하십시오. messenger는 이를 추상화하지만, portal을 직접 사용하는 통합은 이를 직접 처리해야 합니다. - gas 한도는 실질적인 하한이 있는 최솟값입니다.
sendMessage에 전달하는minGasLimit는 L2 실행을 위한 최솟값이며, portal은 모든 입금에 대해 데이터 크기에 비례하는 자체 최솟값을 적용합니다(OptimismPortal2.sol의minimumGasLimit참조). 또한 입금 calldata 크기에는 엄격한 상한이 있습니다. L2 gas 비용을 지불하기 위해 소각되는 L1 gas는 동적으로 변하므로, messaging 가이드의 수수료 안내를 따르고 gas 한도에 최소 20%의 여유를 두라는 권장 사항을 파악하십시오. - 발신자 인증. 수신 측에서
msg.sender는 여러분의 L1 컨트랙트가 아니라 L2 messenger입니다. msg.sender 접근을 읽고xDomainMessageSender확인 패턴을 파악하십시오. portal 직접 입금에는 이 기능이 없으며, L2 대상은 (aliasing된)from만 볼 수 있습니다.
4단계: 패턴에 따라 구축
각 진입 레이어에는 실제로 실행 가능한 예제 경로가 있습니다. 2단계의 결정에 맞는 경로를 따르십시오. 각각은 튜토리얼이므로 이 가이드에서 생략한 환경 설정도 포함되어 있습니다.- 사용자 지정 토큰을 사용하는 Standard Bridge:
Standard Bridge용 L2 토큰 생성의
사용자 지정 토큰 경로를 따라 사용자 지정 로직이 포함된
OptimismMintableERC20변형을 배포합니다. - messenger 기반 컨트랙트 호출: L1과 L2의 컨트랙트 간 통신을 따라 Solidity에서 전송, 릴레이, 인증의 전체 과정을 구현합니다.
- portal 직접 입금: 전용 튜토리얼은 없습니다.
OptimismPortal2.sol의depositTransaction인터페이스와 입금 명세를 바탕으로 작업하고, 3단계의 aliasing 및 gas 규칙을 항상 염두에 두십시오.
5단계: 로컬에서 흐름 테스트
입금은 두 체인에 걸쳐 이루어지므로, testnet에 앞서 로컬 멀티체인 환경에서 테스트하십시오. supersim 입금 트랜잭션 튜토리얼을 따르고, supersim이 각 로컬 체인의OptimismPortal,
L1CrossDomainMessenger, L1StandardBridge 주소를 제공하는 방식과 전체
derivation pipeline을 실행하지 않고도 입금이 L2에 도달하는 것을 확인하는 방법을
파악하십시오.
6단계: 실패한 입금에 대비
L2 실행은 실패할 수 있으며(주로 out-of-gas), 설계 단계에서 누가 이를 감지하고 누가 재시도 비용을 지불할지 미리 결정해야 합니다.
messenger 경로의 경우
실패한 입금 재실행 튜토리얼을
따르고, 실패한 메시지를 감지하는 방법과 더 많은 gas로 이를 재시도하는 재실행
호출을 파악하십시오.
7단계: 결과 검증
testnet에서 흐름을 처음부터 끝까지 실행하고 체인의 각 연결 고리를 확인하십시오.- L1 측: 트랜잭션이
OptimismPortal에서 (직접 또는 messenger를 통해)TransactionDeposited이벤트를 발생시킵니다. 이 이벤트는 입금이 시스템에 들어갔다는 정식 증거입니다. - L2 측: 해당 L2 트랜잭션이 몇 분 내에 나타나고, 대상 컨트랙트가 예상한
발신자를 확인합니다(messenger 흐름의 경우
xDomainMessageSender, portal 직접 흐름의 경우 aliasing된 주소). - 실패 훈련(messenger 흐름):
minGasLimit를 작게 설정하여 하나의 입금을 강제로 실패시키고, 실패한 메시지로 기록되는지 확인한 다음, 6단계에 따라 성공적으로 재실행합니다. - 토큰 회계(bridge 흐름): L1에서 잠긴 금액이 L2에서 발행된 금액과 일치하고, 다시 돌아오는 왕복 과정에서 소각과 해제가 올바르게 이루어집니다.
다음 단계
- 프로토콜 명세의 입금: 입금 트랜잭션, 입금 컨트랙트, 주소 aliasing에 대한 규범적 정의입니다.
- contracts-bedrock 레퍼런스: 현재 컨트랙트에 대해 생성된 인터페이스 문서로, 정확한 함수 및 이벤트 시그니처가 필요할 때 참조합니다.
- develop 브랜치의
OptimismPortal2.sol:minimumGasLimit와 calldata 상한을 포함한 입금 진입점의 소스입니다.develop브랜치를 추적하므로, 여러분의 체인이 실제로 실행하는 릴리스와 함께 읽으십시오. - Superchain Token List: 사용자가 찾을 수 있도록 사용자 지정 bridge 토큰을 등록해야 하는 곳입니다.