> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/ko/core-concepts/constraints.md). # 제약 사항 Rome EVM에서 빌드할 때의 제한 — Solana 트랜잭션 크기, 약 140만 CU 예산, 계정 상한, 저장소 레이아웃, 그리고 Rome이 각 제한을 우회하는 방법. Rome EVM에서 구축할 때의 중요한 한계와 경계입니다. 이러한 제약을 이해하면 안정적으로 작동하는 계약을 설계하는 데 도움이 됩니다. ## Solana 트랜잭션 한도 | 제약 | 값 | 영향 | | ------------ | ------------------ | ------------------------------------------------------------------- | | 트랜잭션 크기 | 4 KB (4,096 bytes) | Rome은 Solana v1 트랜잭션을 전송합니다. 더 큰 EVM 트랜잭션은 보관 계정에 단계적으로 적재됩니다(투명하게) | | 트랜잭션당 컴퓨트 유닛 | 약 140만 CU | 이를 초과하는 작업은 반복 모드를 사용하며, 이 모드에는 별도 한도(아래)가 있습니다 | | 트랜잭션당 계정 수 | 64개 주소 | v1 트랜잭션 한도입니다. EVM 트랜잭션과 그 CPIs가 접촉하는 모든 것, Rome 자체 계정도 포함하여 계산됩니다 | | 최대 보관 크기 | 80 KB | 단일 EVM 트랜잭션의 최대 RLP 크기 | ## EVM 실행 한도 | 제약 | 값 | 참고 | | --------------------- | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | 계약 저장 슬롯 | 저장 계정당 256개 | 계약당 여러 저장 계정을 생성할 수 있습니다 | | 반복당 오퍼코드 수 | 적응형 | 각 Solana 트랜잭션의 CU 예산에 맞춰 패킹됨 (VmIt) | | 계정 잠금 TTL | 3초(세션이 28개 이상의 계정을 건드리면 4초) | 반복 실행 동안; 각 단계마다 갱신됨 | | 반복 세션 길이 | 160단계 | 한도를 넘으면 다음 단계에서 세션의 잠금을 해제하고 아무것도 커밋하지 않은 채 종료합니다 | | Rust Rome SDK가 계획한 레그 | 128 | 반복 컴포저의 상한입니다. 실제 호출은 훨씬 적은 횟수로 완료됩니다 | | 지갑 서명 계획당 트랜잭션 수 | 64 | 최대 `rome_submitSignedV1Plan` 한 번의 호출에서 허용합니다. 참조: [릴레이된 호출 및 장시간 호출](/ko/developer-guides/call-evm-from-solana.md#relayed-calls-and-long-calls) | | 재무 지갑 | 64 | 수수료 풀 지갑 | | 계약 크기 한도 | 24 KB | Ethereum과 동일(EIP-170, 24,576바이트) | ## CPI 제약 | 제약 | 값 | 참고 | | -------------- | ---------------------------------------------------------------- | --------------------------------------------------------------------------------- | | CPI 깊이 | 최대 4단계 | Solana의 CPI 깊이 한도 | | CPI 호출당 계정 수 | 64개 주소 트랜잭션 한도 내 | 트랜잭션이 접촉하는 다른 모든 계정과 공유됩니다 | | CPI + 전송 후크 깊이 | CPI 단계 사용 | CPI 내부의 전송 후크는 깊이를 초과할 수 있습니다 | | 계약당 하나의 트랙 | 레거시 (`0xff…07/08/09`, `0x42…16`) **또는** 캐시됨 (`0xff…04/05/06/0b`) | 둘의 변경 호출을 하나의 트랜잭션에 섞는 것은 거부됩니다 | | 반복 모드의 레거시 CPI | 허용되지 않음 | 반복 트랜잭션에서 레거시 트랙 CPI는 다음 오류로 실패합니다 `CpiProhibitedInIterativeTx`; 캐시 트랙의 효과는 허용됩니다 | **CPI 깊이는 가장 중요한 제약입니다.** Solana가 Rome 프로그램을 호출할 때 Rome EVM은 CPI 한 단계를 사용합니다. 그런 다음 Solidity 계약이 CPI를 통해 또 다른 Solana 프로그램을 호출하면 그것이 2단계입니다. 그 프로그램이 또 다른 프로그램을 호출하면 3단계입니다. 총 최대 4단계입니다. ``` 0단계: Solana 런타임 → Rome EVM 프로그램 1단계: Rome EVM 프로그램 → 귀하의 CPI 대상(예: Jupiter) 2단계: Jupiter → 다른 프로그램(예: Raydium) 3단계: Raydium → SPL Token(최대 깊이) ``` ## Token-2022 전송 후크 제약 | 제약 | 영향 | | -------------------- | --------------------------------------------------------- | | 민트당 후크 하나 | Token-2022 민트에는 단일 전송 후크 슬롯이 있습니다 | | `transfer_checked` 만 | 일반 `전송에서는 후크가 작동하지 않습니다`. Rome 브리지 작업은 `transfer_checked` | | 민트/소각에는 후크가 적용되지 않음 | 후크가 아니라 민트 권한으로 제어됩니다 | ## 가스 및 가격 제약 | 제약 | 참고 | | -------- | ----------------------------------- | | 가스 가격 소스 | Meteora DAMM 풀, v1 또는 v2(SPL 가스 토큰) | | 가스 가격 배수 | 프록시별로 구성 가능(`gas_price_mul`) | | 최소 가스 가격 | 프록시 설정에 의해 설정됨 | | 가스 추정 | 제출 전에 Mollusk 에뮬레이터를 통해 오프체인에서 수행됨 | ## 네트워크별 제약 | 환경 | 체인 ID | rome-evm 프로그램 ID | | ------------- | ------ | --------------------------------------------- | | Hadrian(테스트넷) | 200010 | `RPTWwELXAY4KC9ZPHhaxp7Sq1hHtU3HNEgLbSegCcWf` | | Rubicon(메인넷) | 7531 | `RomePq9X3iAoTr813HR7uRarafFDUJty6GdiEceYpzX` | ## 프리컴파일 제약 | 프리컴파일 | 제약 | | ---------------------- | --------------------------------------------------------------------------------------------------- | | Modexp (0x05) | **비활성화됨** — 호출은 다음으로 되돌아갑니다 `big_mod_exp 호출이 비활성화되어 있습니다` Solana가 다음을 활성화할 때까지 `big_mod_exp` 시스템 호출 | | BN254 ecPairing (0x08) | 프로그램 가격 책정 기준으로 약 2.2만 CU에 쌍당 1.28만 CU가 추가됩니다. 4쌍 검사는 하나의 원자적 트랜잭션에 들어갑니다 | | CPI 프리컴파일 (0xFF...08) | 계정은 Solana 트랜잭션에서 미리 선언되어야 합니다 | ## 트랜잭션 검증 | 규칙 | 효과 | | ----------------- | --------------------------------------------------------------------------------------------------------------------- | | 서명 변형 가능성 (EIP-2) | 서명된 트랜잭션의 `s` s 값이 곡선 차수의 절반을 초과하면 거부됩니다 | | RLP 형식 | RLP 목록이 마지막 항목 뒤에 후행 바이트를 포함하는 트랜잭션은 거부됩니다 | | 구현되지 않은 오퍼코드 | 전체 트랜잭션을 중단합니다(`IncompatibleVersionEVM(opcode)`); 아무것도 커밋되지 않으며 호출한 계약이 이를 삼킬 수 없습니다 | | 가스 계측 | Rome에는 오퍼코드별 가스 스케줄이 없습니다. 다음에 전달된 가스는 `CALL`/`CREATE` 는 강제되지 않으며, 2300가스 스티იპენდ도 없습니다 — 스티იპेंड 기반 재진입 방어에 의존하지 마세요 | ## 오라클 제약 | 제약 | 값 | | --------------- | -------------------------------------------------- | | 기본 최대 최신성 경과 시간 | 60초 | | 과거 라운드 데이터 | 지원되지 않음 — `getRoundData(roundId)` 되돌아갑니다 | | Switchboard EMA | 지원되지 않음 — `latestEMAData()` SwitchboardV3에서 되돌아갑니다 | | 파서 오프셋 | 경험적으로 검증됨 — 재배포 전에 다시 검증해야 합니다 | ## 설계 권장사항 1. **CPI 깊이를 얕게 유지하세요.** 중첩을 최소화하도록 계약을 설계하세요. Jupiter가 Raydium을 호출하고 Raydium이 SPL Token을 호출한다면 3단계에 해당하며, 한도에 위험할 정도로 가깝습니다. 2. **원자적 모드를 선호하세요.** 작업이 약 140만 CU 내에 들어오도록 설계하세요. 반복 모드는 지연(3\~4초 잠금), 세션당 160회 반복 한도, 그리고 지갑이 레그를 직접 서명할 때 Solana 레인에서 레그마다 지갑 프롬프트를 추가합니다. 레거시 트랙 CPI를 수행하는 호출은 반복적으로 실행될 수 없습니다. 3. **계정을 미리 선언하세요.** CPI가 건드리는 모든 Solana 계정은 트랜잭션 생성 시점에 알려져 있어야 합니다(프록시의 에뮬레이션이 이를 발견합니다). CPI 호출 중 동적 계정 발견은 불가능하며, 전체 수는 64개 주소 한도 내여야 합니다. 4. **계약당 프리컴파일 트랙 하나를 선택하세요.** 커스텀 Solana 프로그램을 호출하는 것(`invoke_signed`)은 레거시 트랙이며 원자적 모드만 가능합니다. 참조: [Solana 프로그램 통합](/ko/developer-guides/integrate-solana-program.md). 5. **사용하세요 `transfer_checked`.** Token-2022 토큰을 다루는 어떤 것을 구축하든 항상 사용하여 `transfer_checked` 후크가 작동하도록 하세요. 6. **CU 소모를 테스트하세요.** 트랜잭션 영수증에서 실제 Solana 컴퓨트 유닛을 측정하세요(`computeUnitsConsumed`) — EVM `gasUsed` 는 Solana CU를 충실하게 대변하지 않습니다. 자주 실행되는 경로는 Yul로 최적화하세요. ## 다음 단계 * [컴퓨트 예산](/ko/core-concepts/compute-budget.md) — 작업별 세부 CU 비용 * [토큰 상호운용성](/ko/core-concepts/token-interop.md) — ERC-20 ↔ SPL 브리징 모델 * [프리컴파일 참조](/ko/reference/precompiles.md) — 모든 셀렉터와 해당 디스패치 클래스 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.rome.builders/ko/core-concepts/constraints.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.