계약 바이트코드란 무엇이며 Solidity 코드에서 어떻게 생성됩니까?

이더리움의 계약 바이트코드 이해

1. 계약 바이트코드는 EVM(Ethereum Virtual Machine)이 직접 실행할 수 있는 16진수 형식으로 작성된 기계 수준 명령 세트입니다. 스마트 계약이 이더리움 블록체인에 배포되면 이 바이트코드가 온체인에 저장되고 트랜잭션 중에 호출됩니다. 바이트코드에는 원래 상위 수준 코드에 정의되었지만 EVM이 이해하는 형식으로 변환된 모든 논리가 포함되어 있습니다.

2. Solidity의 모든 함수, 상태 변수 및 수정자는 바이트코드의 최종 구조에 기여합니다. 여기에는 실행 가능한 논리뿐만 아니라 생성자 인수, 함수 선택기, 내부 메서드 디스패치 메커니즘과 같은 메타데이터도 포함됩니다. EVM은 바이트코드의 opcode를 해석하여 스토리지 쓰기, 산술 계산, 외부 호출과 같은 작업을 수행합니다.

3. 계약 생성을 목표로 하는 트랜잭션이 브로드캐스트되면 배포 프로세스가 시작됩니다. 수신자 주소를 지정하는 대신 '받는 사람' 필드는 비워두고 데이터 필드에는 초기화 바이트코드가 포함됩니다. 일단 채굴되면 EVM은 이 코드를 실행하고 배포된 계약의 영구 논리가 되는 런타임 바이트코드를 생성합니다.

4. Etherscan과 같은 검증 도구를 사용하면 개발자는 배포된 바이트코드를 원래 Solidity 소스와 일치시킬 수 있습니다. 이는 특히 사용자가 내부 작업을 알지 못한 채 계약과 상호 작용하는 분산 금융(DeFi) 프로토콜의 경우 투명성과 신뢰를 보장합니다. 컴파일된 바이트코드를 온체인 버전과 일치시키면 배포 중에 변경된 사항이 없음이 확인됩니다.

Solidity에서 Bytecode로의 컴파일 프로세스

1. 변환은 사람이 읽을 수 있는 .sol 파일을 구문 분석하는 Solidity 컴파일러 solc 로 시작됩니다. 중간 표현을 생성하기 전에 구문을 확인하고 가져오기를 해결하며 유형의 유효성을 검사합니다. 이 단계에서는 일치하지 않는 함수 서명이나 잘못된 가시성 지정자와 같은 오류를 포착합니다.

2. 의미론적 분석 후 컴파일러는 계약을 EVM 호환 어셈블리로 변환합니다. 이 단계에서는 루프 및 조건과 같은 상위 수준 구성을 JUMP, SLOAD 및 MUL과 같은 EVM opcode 시퀀스로 매핑합니다. 각 opcode는 EVM에서 지원하는 특정 하위 수준 작업에 해당합니다.

3. 그런 다음 어셈블리 출력은 16진수 문자열로 표시되는 원시 바이트코드로 변환됩니다. 여기에는 초기화 코드(배포 중에 사용됨)와 런타임 코드(배포 후에도 유지됨)가 모두 포함됩니다. 생성자 로직은 초기화 중에 한 번 실행되며 스토리지 레이아웃에 영향을 주지 않는 한 최종 런타임 바이트코드에서 제외됩니다.

4. 컴파일하는 동안 메타데이터가 바이트코드 끝에 추가되는 경우가 많습니다. 여기에는 컴파일러 버전, 소스 코드 해시, ABI 등의 세부정보가 포함됩니다. 실행되지는 않지만 이 정보는 확인 및 디버깅에 도움이 됩니다. 일부 도구는 온체인 배포와의 정확한 일치를 보장하기 위해 비교하기 전에 이 메타데이터를 제거합니다.

ABI 및 배포 아티팩트의 역할

1. 바이트코드와 함께 Solidity 컴파일러는 계약 기능과 상호 작용하는 방법을 설명하는 ABI(Application Binary Interface)를 생성합니다. ABI는 함수 이름, 매개변수, 반환 유형, 상수인지 지불 가능한지 여부를 지정합니다. 이것이 없으면 외부 애플리케이션은 계약에 대한 호출을 올바르게 인코딩하거나 디코딩할 수 없습니다.

2. Hardhat 또는 Truffle과 같은 개발 프레임워크는 컴파일 및 배포 워크플로를 자동화합니다. 바이트코드와 ABI가 모두 포함된 아티팩트를 저장하므로 다양한 네트워크에서 계약을 더 쉽게 배포하고 테스트할 수 있습니다. 이러한 아티팩트는 외부 논리가 필요한 복잡한 계약에 사용되는 연결 라이브러리도 지원합니다.

3. Solidity의 라이브러리는 별도로 배포되고 컴파일 타임에 연결됩니다. 해당 주소는 컴파일 중에 기본 계약의 바이트 코드에 포함됩니다. 제대로 연결되지 않으면 결과 바이트 코드에 자리 표시자가 포함되어 런타임 오류가 발생할 수 있습니다. 도구는 최종 바이트코드 생성 전에 자동으로 라이브러리를 배포하고 참조를 업데이트하여 이를 처리합니다.

4. 프록시 계약과 같은 업그레이드 가능한 패턴은 바이트코드 구조를 이해하는 데 크게 의존합니다. 프록시는 저장소를 보유하고 주소가 변경될 수 있는 구현 계약에 호출을 위임합니다. 이러한 경우 위임자 호출 전달이 의도한 대로 작동하고 스토리지 슬롯이 충돌하지 않도록 하려면 바이트코드를 분석하는 것이 중요합니다.

계약 바이트코드는 이더리움 네트워크에서 실행하는 데 필수적이며 컴파일 후 배포 가능한 최종 Solidity 코드 형태를 나타냅니다.

자주 묻는 질문

계약의 바이트코드를 보는 데 어떤 도구를 사용할 수 있나요? 여러 도구를 사용하여 바이트코드를 검사할 수 있습니다. Remix IDE는 컴파일된 바이트코드를 직접 표시합니다. 명령줄 solc는 --bin 플래그를 사용하여 바이트코드를 출력합니다. Etherscan과 같은 블록 탐색기는 검증에 성공한 후 '바이트코드' 탭 아래에 검증된 계약 바이트코드를 표시합니다.

두 개의 서로 다른 Solidity 코드가 동일한 바이트코드를 생성할 수 있습니까? 예, 로직과 컴파일러 설정이 동일한 경우 Solidity의 다른 형식 또는 변수 이름 지정으로 인해 동일한 바이트코드가 발생할 수 있습니다. 컴파일러 최적화로 인해 구조적으로 다른 코드가 유사한 opcode 시퀀스로 수렴될 수도 있습니다. 특히 논리가 기능적으로 동일한 경우 더욱 그렇습니다.

바이트코드에 떼 해시가 포함되는 이유는 무엇입니까? Swarm 해시는 역사적으로 소스 코드와 빌드 설정이 포함된 메타데이터 파일의 위치를 ​​가리키도록 바이트코드에 내장되었습니다. 이를 통해 개발 세부 정보를 오프체인에서 검색할 수 있었습니다. 현대 관행에서는 개인 정보 보호를 위해 이를 제거하거나 계약 확인 중에 대체 메타데이터 처리 방법을 사용하는 경우가 많습니다.

배포된 계약이 로컬 바이트코드와 일치하는지 어떻게 확인할 수 있나요? web3.js 또는 ethers.js를 사용하여 로컬 컴파일 출력의 런타임 바이트코드와 블록체인의 런타임 바이트코드를 비교할 수 있습니다. eth_getCode를 통해 온체인 바이트코드를 검색한 다음 정확한 비교를 위해 필요한 경우 메타데이터를 제외하고 로컬로 컴파일된 버전과 일치시킵니다.