명세
읽기 편의를 위한 AI 번역이며 부정확하거나 오래되었을 수 있습니다. 거버넌스·투표·분쟁 시에는 영어 원문만이 유일한 정식 본문입니다. 정확한 표현은 GitHub 원본을 참고하세요.
GitHub 영어 원문 ↗## 초록 메모리 확장 비용을 선형으로 재정의하고 트랜잭션당 명시적인 최대 메모리 사용량을 강제합니다. ## 동기 현재 EVM 메모리 사용량은 이차 확장 비용과 63/64 규칙에 의해 제한됩니다. 트랜잭션의 이론적인 메모리 한계는 최소 26 MB입니다. 역사적인 트랜잭션 분석에 따르면 평균 메모리 사용량은 약 2 KB이며 최대 관찰된 메모리 사용량은 약 2 MB입니다. 벤치마크 또한 현재의 메모리 확장 공식이 실제 자원 사용량에 대해 과도하게 청구하고 있음을 나타냅니다. 이 업데이트는 비용을 실제 자원 소비와 일치시킵니다. 이는 특히 대규모 메모리 할당에 의존하는 계약에 대해 메모리 사용량을 보다 예측 가능하게 만듭니다. ## 사양 메모리 확장 비용은 다음과 같이 재정의됩니다: ```python memory_size_words = (memory_byte_size + 31) // 32 memory_cost = memory_size_words // 2 ``` 최대 메모리 사용량은 8 MB로 제한됩니다. 메모리 할당은 다음 규칙에 따라 호출 컨텍스트 전반에 걸쳐 제한됩니다: 1. 현재 호출에 의해 사용된 메모리를 `k`라고 하고, 부모 호출에 의해 사용된 메모리를 `j`라고 합니다. 2. 자식 호출에 사용 가능한 남은 메모리는 다음과 같습니다: ```python remaining_memory = 8 * 1024 * 1024 - j - k ``` 3. 호출이 반환되면 메모리는 풀로 반환됩니다. 4. 호출이 남은 메모리 한도를 초과하면 예외적으로 중단되며, 해당 호출 프레임에서 남은 모든 가스를 소모합니다. ## 이전 호환성 이 제안은 기존 계약과 매우 호환됩니다. 거의 모든 표준 EVM 작업은 유효하며 ERC-4337 계약은 자식 호출 메모리가 완료 시 해제되므로 계속해서 올바르게 작동합니다. 역사적인 이더리움 트랜잭션의 재생 테스트를 통해 호환성을 정량화할 것입니다. 그러나 이제 8 MB 이상의 메모리를 할당하는 계약은 예외적으로 중단됩니다. ## 보안 고려사항 8MB 한도로 메모리를 확장하는 비용은 131,072 가스입니다. 결과적으로 현재 비용보다 메모리를 확장하는 것이 더 저렴합니다. OOM 문제를 방지하기 위해 RPC 노드의 동시성 한계를 조정해야 할 수 있습니다. ## 감사의 말 이 MIP의 제안은 두 개의 이전 EIP 문서를 기반으로 합니다. 또한 Charles Cooper와의 대화는 Monad 메모리 모델 개발에 유익했습니다: - [EIP-7686](https://eips.ethereum.org/EIPS/eip-7686) (@vbuterin) - [EIP-7923](https://eips.ethereum.org/EIPS/eip-7923) (@charles-cooper, @qizhou) MIP-3는 EIP-7686과 달리 EIP-7686이 메모리 한도와 가스 한도 간의 직접적인 관계를 정의하고, EIP-7923과 달리 MIP-3는 페이지 기반의 스래싱 비용 모델을 채택하지 않습니다. ## 저작권 저작권 및 관련 권리는 [CC0](../LICENSE.md)를 통해 포기되었습니다.
포럼 토론
-
MIP3 - Linear EVM memory cost This proposal reprices EVM memory expansion from a quadratic cost model to a linear one. To bound total memory usage within a block, each transaction is explicitly limited by its peak memory usage. The motivation is to better align EVM gas costs with real resource usage and to introduce an explicit invariant on total memory usage at the block level. Any feedback or discussion is appreciated on: - the proposed linear memory cost model - the explicit per-transaction memory limit - potential DoS concerns - developer ergonomics and usage concerns
-
Hello, I have questions to the design and spec: 1. How does the call which exceeds memory exit? revert or exceptionally halt? If revert, does the gas to extend memory get charged before reverting? and other instruction gas charges (esp. *CALL )? exceptionally halt is more consistent with current OOM behavior (out-of-gas), but revert is more friendly. The spec says “revert” but I want to confirm that’s what was meant and spec out the fine details. 2. For all calculation related to memory limit, the memory size isn’t rounded up to the nearest word, i.e. if caller frame allocates `limit - 1byte` memory, callee frame can still allocate `1byte` of memory? This is in the spec, but want to confirm.
-
- Can we expand discussion with EIP-7686 and EIP-7923 in the Rationale section, i.e. why is MIP-3 chosen over them? (my understanding is that EIP-7686 would combine unfavorably with Monad’s “charge-gas-limit” rule, what about the paging from EIP-7923?) - Similar to EIP-7923, behavior of MSIZE after the activation should be confirmed (esp. given the lack of rounding to word in memory limit calculation.) In other words - would MSIZE return limit or limit - 1byte in the case mentioned in (2.)?
-
Some Responses: - Exceeding the memory limit causes the current call frame to revert rather than halt. One rationale for this decision is compatibility with ERC-4337 bundlers for the following reason: if exceeding the memory limit resulted in an exceptional halt a transaction could DOS erc4337 bundlers by using the memory limit. If compatibility with erc4337 is not necessary then this can be changed to halt.
-
- Expansion cost remains in terms of 32 byte word expansion. This will be defined more explicitly in the MIP. - EIP-7686 and EIP-7923 are designed for ethereum execution specifically. For example in EIP-7686, it defines a strict bound on memory expansion via gas. This defines the amount of expandable memory to be linearly dependent on the amount of gas forwarded in the call. This is not compatible to the constraints of Monad execution. As it would cause a higher memory footprint per transaction. - MSIZE semantics are unchanged. It returns the size of active memory in bytes. So the case where caller frame allocates limit - 1byte memory is rounded up to the limit memory. The child call would not have any remaining memory to allocate.