이더리움 가상 머신(EVM)이란 무엇입니까? 왜 중요한가요?

EVM의 핵심 아키텍처

1. EVM은 이더리움 네트워크의 모든 전체 노드에 걸쳐 복제되는 분산형 결정론적 실행 환경으로 작동합니다.

2. 각 스택 항목이 정확히 32바이트를 차지하고 최대 깊이가 1024개 항목으로 제한되는 스택 기반 계산 모델을 구현합니다.

3. 일시적인 계산을 위한 휘발성 메모리, 계약 계정당 영구 저장소, 입력 매개변수에 대한 불변의 호출 데이터라는 세 가지 고유한 메모리 계층이 존재합니다.

4. EVM에서 실행되는 모든 명령은 미리 결정된 양의 가스를 소비하여 엄격한 리소스 책임을 적용하고 무한 루프 또는 DoS 공격을 방지합니다.

5. 프로그램 카운터는 컴파일된 바이트코드 내에서 바이트 수준 실행 위치를 추적하여 JUMP 및 JUMPI opcode를 통한 정밀한 점프 제어 및 조건부 분기를 가능하게 합니다.

EVM 내부의 실행 워크플로

1. Solidity 소스 코드는 1바이트 opcode 시퀀스를 포함하는 EVM 호환 바이트코드로 컴파일됩니다.

2. 트랜잭션 제출 시 EVM은 계정 잔액 및 저장 가치를 포함하여 현재 세계 상태와 함께 계약 바이트코드를 로드합니다.

3. 각 opcode는 산술 연산, 메모리 쓰기 또는 저장소 읽기와 같은 특정 상태 전환을 트리거하며 부작용은 성공적인 완료 시에만 기록됩니다.

4. 실행 중에 가스 소진이 발생하면 트랜잭션 시작 이후의 모든 상태 변경이 원자적으로 되돌려져 블록체인 일관성이 유지됩니다.

5. 함수 호출의 반환 데이터는 메모리에 인코딩되어 최종 상태 커밋 전에 출력 버퍼에 복사됩니다.

보안 및 격리 속성

1. EVM은 엄격한 샌드박싱을 시행합니다. 즉, 파일 시스템 액세스가 없고 네트워크 I/O가 없으며 호스트 운영 체제 리소스와 직접적인 상호 작용이 없습니다.

2. 계약 코드는 명시적인 인터페이스 호출 및 적절한 액세스 제어 논리 없이 다른 계약의 저장소를 직접 조작할 수 없습니다.

3. 위임 호출을 포함한 모든 외부 호출에는 가스 제한 및 되돌리기 전파 규칙이 적용되어 재귀 호출 깊이와 계약 간 영향이 제한됩니다.

4. 메모리 할당은 선형적이고 제한적입니다. 범위를 벗어난 읽기는 0을 반환하는 반면, 할당된 공간을 초과하는 쓰기는 가스 집약적인 확장을 트리거합니다.

5. 되돌리기 의미론은 부분적인 실패로 인해 전체 성공이든 전체 롤백이든 일관되지 않은 중간 상태가 남지 않도록 보장합니다.

Opcode 분류 및 기능

1. PUSH1, POP, DUP1 및 SWAP1과 같은 스택 조작 opcode는 평가 중 피연산자 위치 지정 및 복제를 제어합니다.

2. ADD, MUL, AND, XOR을 포함한 산술 및 비트 명령어는 256비트 단어에서 하위 수준 계산을 수행합니다.

3. 스토리지 작업 SLOAD 및 SSTORE는 각 계약 주소에 연결된 영구 키-값 저장소와 상호 작용합니다.

4. CALLER, ORIGIN, BLOCKHASH 및 TIMESTAMP와 같은 환경 opcode는 실행 중인 계약에 상황별 블록체인 메타데이터를 노출합니다.

5. JUMPDEST, JUMP, JUMPI와 같은 제어 흐름 기본 요소는 런타임 조건에 따라 구조화된 프로그램 흐름과 동적 디스패치를 ​​가능하게 합니다.

가스 회계 및 경제 집행

1. 가스 비용 일정은 opcode별로 정의되고 진화하는 하드웨어 효율성과 공격 표면 분석을 반영하기 위해 Ethereum 개선 제안을 통해 업데이트됩니다.

2. 거래 개시자는 가스 한도와 가스 가격을 모두 지정하여 최대 계산 예산과 블록 포함 우선 순위를 결정해야 합니다.

3. 실행 후 사용되지 않은 가스는 발신자에게 환불되어 효율적인 코딩 관행과 정확한 가스 추정을 장려합니다.

4. 0이 아닌 값을 덮어쓸 때 SSTORE와 같은 특정 작업은 스팸을 방지하고 사려 깊은 상태 설계를 장려하기 위해 비대칭 비용을 수반합니다.

5. 자체 파괴 기능은 부분 가스 환불을 통한 계약 종료 메커니즘을 제공하여 장기 저장 용량 증가를 줄입니다.

자주 묻는 질문

Q: EVM 바이트코드를 읽기 가능한 Solidity 소스로 리버스 엔지니어링할 수 있습니까? 손실이 있는 컴파일, 최적화 변환, 배포된 바이트코드에 기호 테이블이나 주석이 없기 때문에 원래의 상위 수준 논리를 복구하는 것은 일반적으로 불가능합니다.

Q: EVM이 레지스터 기반 대신 스택 기반 아키텍처를 사용하는 이유는 무엇입니까? 스택 기반 설계는 명령어 인코딩을 단순화하고, opcode 크기 오버헤드를 줄이며, 레지스터 할당 전략 없이도 이기종 하드웨어에서 결정론적 실행을 가능하게 합니다.

Q: 두 계약이 동일한 스토리지 슬롯에 동시에 쓰기를 시도하면 어떻게 됩니까? 저장소 슬롯의 범위는 계약 주소별로 지정됩니다. 함수 호출 및 합의된 인터페이스를 통해 명시적으로 중재되지 않는 한 계약 간에 공유된 변경 가능 상태는 존재하지 않습니다.

Q: EVM은 정수 오버플로 또는 언더플로를 어떻게 처리합니까? 이스탄불 업그레이드 이전에는 산술 연산이 자동으로 래핑되었습니다. 업그레이드 후 내장된 오버플로 검사를 통해 잘못된 산술 결과를 즉시 되돌릴 수 있습니다.