의견: 버전 관리가 없는 EVM

편집자 주: 이 기사의 출처는이더리움 애호가(ID: Ethfans)편집자 주: 이 기사의 출처는

이더리움 애호가(ID: Ethfans)

, 저자: Wei Tang, 번역: A Jian, 승인을 받아 Odaily에서 재인쇄함.

EVM을 재설계하고, 이전 버전과의 호환성을 개선하고, 기능 업그레이드에 보다 친숙하게 만들고, 기존의 역사적 짐을 완전히 무시할 기회가 있다면 어떻게 해야 할까요?

이 기사에서 나는 이 질문을 탐구하고 그로부터 진화한 기술 설명과 디자인 철학을 문서화합니다.

보조 제목

웹은 버전이 없으며 수십 년 동안 존재해 왔습니다. 그래서 여기서는 버전 차이가 없는 EVM을 만들고 싶다고 가정합니다.

또한 이 가상 머신이 이전 버전과의 호환성이 좋은지 확인하려고 합니다(필수 속성임). 즉, 적어도 기존 컨트랙트와 잘 호환될 수 있고(현재 EVM에서는 단일 opcode의 가스 소비 변경만으로도 기존 컨트랙트가 깨질 수 있음) 새로운 기능을 쉽게 추가할 수 있습니다.

보조 제목

유효하지 않은 opcode

• 영구 EVM을 설계하기 위한 가장 간단하고 아마도 가장 중요한 변경 사항은 계약 배포를 위한 확인 프로세스를 추가하는 것입니다. 모든 바이트 시퀀스가 ​​유효한 EVM 코드는 아니며 유효하지 않은 opcode가 체인에 배포되어서는 안 됩니다. 향후 이러한 코드에 다른 기능을 가진 새 opcode가 할당될 수 있기 때문입니다.

• 이 검사의 기술적 세부 사항은 EIP-1712에 처음 문서화되었습니다. 간단히 말해서 계약에 의해 생성된 상태 전환 기능을 실행하기 전에(또는 상태에 계약 코드를 추가하기 전에) 다음 검사가 수행됩니다.

• 코드의 바이트코드 순회

• 코드가 PUSH(n) opcode인 경우 다음 n바이트를 건너뜁니다.

그렇지 않으면 오류가 발생합니다(트랩).

위의 확인은 점프 대상 확인과 다소 유사합니다. 여기서는 예외에 대해 "트랩"을 사용하고 있으며 이에 대해서는 아래에서 자세히 설명합니다.

보조 제목

기능 프로브

• EVM이 버전 차이를 완화하려면 EVM 기반 코드 실행에 기본 환경이 특정 기능을 지원하는지 여부를 조사할 수 있는 기능이 있어야 합니다. EVM이 수행하는 역할을 감안할 때 우리는 이미 정의된 opcode의 기능이 변경되지 않고 유지되고 기능을 추가하기 위해 새로운 opcode가 도입될 수 있기를 항상 희망합니다. 그리고 일부 계약은 특정 기능을 도입하기 전에 배포되었을 수 있습니다. 이러한 계약은 기능이 EVM에서 지원되지 않을 때 실행할 폴백 서브루틴을 예약하고 하드 포크가 활성화되는 즉시 새 기능을 사용하기 시작할 수 있습니다. 기능 조사 구성 요소는 여기에서 사용될 점퍼와 같습니다.

• 이 opcode는 스택 인수를 사용합니다. 매개변수가 0에서 2^8 사이인지 확인하고 그렇지 않은 경우 오류를 포착합니다.

인수(opcode로 해석됨)가 지원되지 않으면 0x0을 스택에 다시 푸시하고 그렇지 않으면 0x1을 푸시합니다.

예외와 함정

EVM 동작 중에는 실행 실패(fail)를 일으킬 수 있는 여러 가지 요인이 있을 수 있다. 가스 고갈로 인해 단일 트랜잭션이 실패할 수 있으며 호출 스택의 각 계층이 개별적으로 실패할 수 있으며 해당 오류는 상위 호출 프레임에서 명시적으로 처리해야 합니다. 이러한 기능은 우리에게 어느 정도의 유연성을 제공하지만 블록체인에서 실행되는 계약에 반드시 좋은 것은 아닙니다. 여기에서 우리는 EVM 자체에서 발생하는 모든 예외가 실패를 대신하여 트랩 동작을 가질 수 있음을 재정의하고자 합니다. 즉, 호출 프레임워크의 모든 실행 중, 가스가 소비되거나 현재 상태 함수가 롤백되고 변경되는 경우에도 트랩이 있을 수 있습니다. 그런 다음 계약은 부모 호출자에게 치명적이지 않은 오류를 전달하려는 경우 반환 값을 사용하도록 권장됩니다.

보조 제목