> ## Documentation Index
> Fetch the complete documentation index at: https://docs.optimism.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 사용자 지정 입금 흐름 구현

> 올바른 컨트랙트 진입점을 선택하고 gas, aliasing, 실패한 메시지를 처리하여 애플리케이션을 위한 L1에서 L2로의 입금(디파짓) 경로를 구축합니다.

이 가이드는 Ethereum에서 OP Stack 체인에 영향을 주어야 하는 컨트랙트를 만드는
앱 개발자를 대상으로, 입금(디파짓) 경로 전체를 한 번에 안내합니다. 입금이 L1에서
L2로 전달되는 방식, 세 가지 컨트랙트 진입점 중 여러분의 사용 사례에 맞는 것,
그리고 사용자 지정 통합에서 흔히 잘못 처리하는 안전 관련 세부 사항(gas 한도,
주소 aliasing, 실패한 메시지)을 다룹니다. 여기에는 `StandardBridge`,
`CrossDomainMessenger` 쌍, `OptimismPortal` 컨트랙트가 관련됩니다.

## 이 가이드가 적합한 대상

다음과 같은 경우 이 가이드를 사용하십시오.

* L1에서 L2 작업을 시작하는 컨트랙트나 백엔드 인프라를 구축하는 경우.
  예를 들어 사용자 지정 토큰 bridge, L1에서 제어하는 L2 컨트랙트, 또는 L2에
  트랜잭션을 강제로 포함시킬 수 있어야 하는 프로토콜이 있습니다.
* 하나의 경로를 그대로 따르는 것이 아니라 *어떤* 컨트랙트 인터페이스를
  기반으로 구축할지 선택해야 하는 경우.

레이어 간에 ETH나 표준 ERC-20만 이동하면 되는 경우에는
[Standard Bridge](https://docs.optimism.io/ko/app-developers/guides/bridging/standard-bridge.md)를 그대로
사용하십시오. 목표가 L2에서 L1로의 이동(출금)이라면 대신
[출금 흐름 설명](https://docs.optimism.io/ko/op-stack/bridging/withdrawal-flow.md)을 읽으십시오. 7일간의
이의 제기 기간(challenge period) 때문에 이는 다른 문제가 됩니다. L1과 L2가 아니라
두 OP Stack 체인 간의 메시징에 대해서는
[interop 설명](https://docs.optimism.io/ko/op-stack/interop/explainer.md)을 참조하십시오. 이 가이드는 L1에서
L2 방향만 다룹니다.

## 시작하기 전에

다음이 준비되어 있어야 합니다.

* Solidity 개발 환경과 Sepolia 및 OP Sepolia(또는 다른 OP Stack testnet)에서
  자금이 있는 계정.
* 단일 체인에서 컨트랙트가 서로를 호출하는 방식에 대한 기본적인 이해.
  [bridging 기초 가이드](https://docs.optimism.io/ko/app-developers/guides/bridging/basics.md)에서 기본
  용어를 설명합니다.

## 1단계: 입금 경로 파악

어떤 인터페이스를 사용하든 모든 L1에서 L2로의 쓰기 작업은 결국
`OptimismPortal` 컨트랙트의 `depositTransaction` 함수 호출로 끝납니다. 이 함수는
`TransactionDeposited` 이벤트를 발생시키고, rollup node는 이를 L2 트랜잭션으로
파생합니다. [입금 흐름 설명](https://docs.optimism.io/ko/op-stack/bridging/deposit-flow.md)을 읽고 다음을
파악하십시오.

* 캡슐화 체인: 여러분의 컨트랙트가 messenger를 호출하고, messenger가 portal을
  호출하며, portal이 이벤트를 발생시키고, `op-node`가 이벤트를 L2 트랜잭션으로
  변환합니다. 사용하는 각 레이어는 그 아래 레이어 위에 편의성과 안전성을
  더합니다.
* 입금은 sequencer의 재량이 아니라 파생(derivation)에 의해 포함됩니다. L1
  트랜잭션이 확인되면 L2 트랜잭션은 반드시 실행됩니다.

그런 다음 [L1과 L2 간 데이터 전송](https://docs.optimism.io/ko/app-developers/guides/bridging/messaging.md)을
훑어보고 `sendMessage(target, message, minGasLimit)` 인터페이스 형태, L1에서
L2로의 전달 시간이 1\~3분이라는 점, 그리고 portal이 L1 gas를 소각하여 L2 실행
비용을 부과하는 방식을 파악하십시오.

## 2단계: 진입 레이어 선택

이것이 이후의 모든 것을 결정하는 선택입니다. 표를 위에서부터 차례로 살펴보고
처음으로 맞는 행에서 멈추십시오.

| 조건 | 선택 | 이유 |
| - | - | - |
| ETH 또는 ERC-20 토큰을 이동하며 표준 lock-and-mint 회계 방식이 맞는 경우 | `StandardBridge`, 필요한 경우 확장 | 감사를 거친 경로이며, Superchain Bridges UI 및 토큰 목록과 호환됩니다. 또한 [사용자 지정 bridged 토큰 구축](https://docs.optimism.io/ko/app-developers/tutorials/bridging/standard-bridge-standard-token.md)에서 새 bridge 없이 "표준 토큰이 맞지 않는" 대부분의 경우를 다룹니다. |
| L2 컨트랙트를 호출하며 전달 보장을 원하는 경우 | `L1CrossDomainMessenger.sendMessage` | messenger는 L2에서 실패한 메시지를 기록하고 누구나 더 많은 gas로 재실행할 수 있게 하며, 대상 컨트랙트는 `xDomainMessageSender`를 통해 L1 발신자를 인증할 수 있습니다. |
| 원시 입금 트랜잭션이 필요한 경우: sequencer가 검열할 때의 강제 포함(forced inclusion) 또는 L2 호출에 대한 완전한 제어 | `OptimismPortal.depositTransaction` 직접 호출 | 여러분과 파생 사이에 아무것도 없습니다. 하지만 messenger의 재실행 안전망과 발신자 인증을 포기해야 하며, 여러분의 컨트랙트에 주소 aliasing이 적용됩니다(3단계). |

현재 컨트랙트 인터페이스는
[contracts-bedrock 레퍼런스](https://devdocs.optimism.io/contracts-bedrock)
또는 `develop`의 소스를 사용하십시오:
[`StandardBridge.sol`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/universal/StandardBridge.sol),
[`CrossDomainMessenger.sol`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/universal/CrossDomainMessenger.sol),
[`OptimismPortal2.sol`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L1/OptimismPortal2.sol).
OP Mainnet과 OP Sepolia의 배포 주소는
[컨트랙트 주소 페이지](https://docs.optimism.io/ko/op-mainnet/network-information/op-addresses.md)에 있습니다.

사용자 지정 bridge가 필요하다고 판단했다면
[사용자 지정 bridge 가이드](https://docs.optimism.io/ko/app-developers/guides/bridging/custom-bridge.md)를 읽고,
처음부터 새로 만들기보다 `StandardBridge`를 확장하라는 권장 사항과 bridged 토큰을
Superchain Token List에 등록해야 한다는 요구 사항을 파악하십시오.

## 3단계: 안전 관련 세부 사항 올바르게 처리

입금 경로의 세 가지 특성은 사용자 지정 통합에서 예상치 못한 문제를 일으킵니다.
코드를 작성하기 전에 설계를 각 항목과 대조해 확인하십시오.

* **주소 aliasing.** EOA가 아닌 *컨트랙트*가 입금을 시작하면, L2에서의
  `from` 주소는 L1 컨트랙트 주소에 일정한 오프셋을 더한 값이 됩니다. L2
  컨트랙트가 `msg.sender`를 L1 컨트랙트 주소와 비교한다면 aliasing된 형태로
  비교해야 합니다.
  [입금 명세의 주소 aliasing](https://specs.optimism.io/protocol/deposits.html?utm_source=op-docs\&utm_medium=docs#address-aliasing)을
  읽고 오프셋 상수와 그것이 존재하는 이유를 파악하십시오. messenger는 이를
  추상화하지만, portal을 직접 사용하는 통합은 이를 직접 처리해야 합니다.
* **gas 한도는 실질적인 하한이 있는 최솟값입니다.** `sendMessage`에 전달하는
  `minGasLimit`는 L2 실행을 위한 최솟값이며, portal은 모든 입금에 대해 데이터
  크기에 비례하는 자체 최솟값을 적용합니다(
  [`OptimismPortal2.sol`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L1/OptimismPortal2.sol)의
  `minimumGasLimit` 참조). 또한 입금 calldata 크기에는 엄격한 상한이 있습니다.
  L2 gas 비용을 지불하기 위해 소각되는 L1 gas는 동적으로 변하므로,
  [messaging 가이드의 수수료 안내](https://docs.optimism.io/ko/app-developers/guides/bridging/messaging.md#fees-for-sending-data-between-l1-and-l2)를
  따르고 gas 한도에 최소 20%의 여유를 두라는 권장 사항을 파악하십시오.
* **발신자 인증.** 수신 측에서 `msg.sender`는 여러분의 L1 컨트랙트가 아니라 L2
  messenger입니다.
  [msg.sender 접근](https://docs.optimism.io/ko/app-developers/guides/bridging/messaging.md#accessing-msgsender)을
  읽고 `xDomainMessageSender` 확인 패턴을 파악하십시오. portal 직접 입금에는
  이 기능이 없으며, L2 대상은 (aliasing된) `from`만 볼 수 있습니다.

## 4단계: 패턴에 따라 구축

각 진입 레이어에는 실제로 실행 가능한 예제 경로가 있습니다. 2단계의 결정에 맞는
경로를 따르십시오. 각각은 튜토리얼이므로 이 가이드에서 생략한 환경 설정도
포함되어 있습니다.

* **사용자 지정 토큰을 사용하는 Standard Bridge**:
  [Standard Bridge용 L2 토큰 생성](https://docs.optimism.io/ko/app-developers/tutorials/bridging/standard-bridge-standard-token.md)의
  사용자 지정 토큰 경로를 따라 사용자 지정 로직이 포함된 `OptimismMintableERC20`
  변형을 배포합니다.
* **messenger 기반 컨트랙트 호출**:
  [L1과 L2의 컨트랙트 간 통신](https://docs.optimism.io/ko/app-developers/tutorials/bridging/cross-dom-solidity.md)을
  따라 Solidity에서 전송, 릴레이, 인증의 전체 과정을 구현합니다.
* **portal 직접 입금**: 전용 튜토리얼은 없습니다.
  [`OptimismPortal2.sol`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L1/OptimismPortal2.sol)의
  `depositTransaction` 인터페이스와
  [입금 명세](https://specs.optimism.io/protocol/deposits.html?utm_source=op-docs\&utm_medium=docs#user-deposited-transactions)를
  바탕으로 작업하고, 3단계의 aliasing 및 gas 규칙을 항상 염두에 두십시오.

## 5단계: 로컬에서 흐름 테스트

입금은 두 체인에 걸쳐 이루어지므로, testnet에 앞서 로컬 멀티체인 환경에서
테스트하십시오.
[supersim 입금 트랜잭션 튜토리얼](https://docs.optimism.io/ko/app-developers/tutorials/bridging/deposit-transactions.md)을
따르고, supersim이 각 로컬 체인의 `OptimismPortal`,
`L1CrossDomainMessenger`, `L1StandardBridge` 주소를 제공하는 방식과 전체
derivation pipeline을 실행하지 않고도 입금이 L2에 도달하는 것을 확인하는 방법을
파악하십시오.

## 6단계: 실패한 입금에 대비

L2 실행은 실패할 수 있으며(주로 out-of-gas), 설계 단계에서 누가 이를 감지하고
누가 재시도 비용을 지불할지 미리 결정해야 합니다.

| 조건 | 선택 | 이유 |
| - | - | - |
| messenger(또는 Standard Bridge)를 사용한 경우 | 모니터링 및 재실행 런북 | 실패한 메시지는 L2에 기록되며, 누구나 나중에 더 높은 gas 한도로 재실행할 수 있습니다. |
| portal을 직접 사용한 경우 | 보수적인 gas 한도와 멱등성 있는 L2 핸들러 | 기록된 메시지라는 안전망이 없습니다. 실패한 입금 트랜잭션은 최종적입니다. |

messenger 경로의 경우
[실패한 입금 재실행 튜토리얼](https://docs.optimism.io/ko/app-developers/tutorials/bridging/replay-failed-deposit.md)을
따르고, 실패한 메시지를 감지하는 방법과 더 많은 gas로 이를 재시도하는 재실행
호출을 파악하십시오.

## 7단계: 결과 검증

testnet에서 흐름을 처음부터 끝까지 실행하고 체인의 각 연결 고리를 확인하십시오.

* **L1 측**: 트랜잭션이 `OptimismPortal`에서 (직접 또는 messenger를 통해)
  `TransactionDeposited` 이벤트를 발생시킵니다. 이 이벤트는 입금이 시스템에
  들어갔다는 정식 증거입니다.
* **L2 측**: 해당 L2 트랜잭션이 몇 분 내에 나타나고, 대상 컨트랙트가 예상한
  발신자를 확인합니다(messenger 흐름의 경우 `xDomainMessageSender`, portal 직접
  흐름의 경우 aliasing된 주소).
* **실패 훈련**(messenger 흐름): `minGasLimit`를 작게 설정하여 하나의 입금을
  강제로 실패시키고, 실패한 메시지로 기록되는지 확인한 다음, 6단계에 따라
  성공적으로 재실행합니다.
* **토큰 회계**(bridge 흐름): L1에서 잠긴 금액이 L2에서 발행된 금액과 일치하고,
  다시 돌아오는 왕복 과정에서 소각과 해제가 올바르게 이루어집니다.

## 다음 단계

* [프로토콜 명세의 입금](https://specs.optimism.io/protocol/deposits.html?utm_source=op-docs\&utm_medium=docs):
  입금 트랜잭션, 입금 컨트랙트, 주소 aliasing에 대한 규범적 정의입니다.
* [contracts-bedrock 레퍼런스](https://devdocs.optimism.io/contracts-bedrock):
  현재 컨트랙트에 대해 생성된 인터페이스 문서로, 정확한 함수 및 이벤트
  시그니처가 필요할 때 참조합니다.
* [develop 브랜치의 `OptimismPortal2.sol`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L1/OptimismPortal2.sol):
  `minimumGasLimit`와 calldata 상한을 포함한 입금 진입점의 소스입니다.
  `develop` 브랜치를 추적하므로, 여러분의 체인이 실제로 실행하는 릴리스와 함께
  읽으십시오.
* [Superchain Token List](https://docs.optimism.io/ko/app-developers/reference/tokens/tokenlist.md):
  사용자가 찾을 수 있도록 사용자 지정 bridge 토큰을 등록해야 하는 곳입니다.