QtumOfficial ‏ x86 VM을 실제로 사용하기 위해 부단히 노력

다음 형식은 인터페이스 및 스마트 계약 코드에 표시됩니다.

런타임 길이 인코딩 형식

블록 체인에서 x86 용 모든 계약 데이터는 0 인 바이트에 대해 RLE (Runtime Length Encoding) 변형을 사용합니다. 0이 아닌 데이터는 인코딩되지 않습니다. 바이트 스트림에서 0이 발견되면 0 바이트가 이어지는 길이를 나타내는 길이가됩니다. RLE에 대해 길이가 0이면 명시 적으로 금지되며 블록 또는 mempool에 포함될 수없는 유효하지 않은 트랜잭션이 발생합니다

RLE 페이로드에는 24 비트 디코드 크기 필드가 포함 된 32 비트 정수가 접두사로 사용됩니다. 이 크기가 디코드 된 페이로드와 정확히 일치하지 않으면 트랜잭션이 유효하지 않습니다.

32 비트 정수에 남아있는 다른 8 비트는 잠재적으로 다른 압축 포맷을 구현하기위한 버전 번호로 예약됩니다

추가 메모리를 할당하지 않고도 페이로드의 크기를 확인할 수 있습니다.

관련 코드 주석 :

//format: decoded payload length (uint32_t) | payload
//the compression only compresses 0 bytes. 
//when 0x00 is encountered in the bytestream, it is transformed converted to a run-length encoding
//encoding examples:
//0x00 00 00 00 -> 0x00 04
//0x00 -> 0x00 01
//0x00 00 -> 0x00 02
//0x00 (repeated 500 times) -> 0x00 0xFF 0x00 0xF5
//as part of the encoding process, a 32 bit length field is prefixed to the payload

RLE 인코딩은 다른 형식의 맨 위에 사용됩니다.

인코딩 및 디코딩을위한 코드는 x86Lib에 포함되어 있지만 필요한 모든 언어로 구현하는 것이 쉽습니다.

길이 필드는 나중에 제거 될 수 있으므로 이점이 없습니다. 원래의 이론적 근거는 잠재적으로 다중 할당을 필요로하지 않고 일정한 메모리 할당 프로파일을 사용할 수 있도록하는 것이 었습니다. 그러나 디코딩 된 데이터 형식은 현재 Qtum의 백업 데이터베이스에 저장되므로 디코딩을 한 번만 수행하면됩니다.

스마트 계약 바이트 코드 형식

x86 VM은 EVM이 계약을 인코딩하고 저장하는 방식과 다르게 작동합니다. EVM에는 opcode의 플랫 배열이 모두 제공됩니다. 그런 다음 이러한 opcode가 실행되고 opcode 및 데이터의 어떤 부분이 계약상의 바이트 코드로 영구 저장 장치에 실제로 저장되는지 결정합니다.

Qtum의 x86 VM을 사용하면 훨씬 간단하고 일반적으로 추론하기가 더 쉽습니다. 옵션 (예 : 계약 구성 정보 등), 초기화 된 데이터 및 코드에 대해 별도의 섹션이있는 사용자 정의 이진 형식입니다. 전체 바이너리는 영구 저장 장치에 직접 저장됩니다. 이렇게하면 EVM에서 계약서에 계약 저장자가 있어야하는 상황을 방지 할 수 있습니다. 이것은 EVM에서 너무 복잡하지는 않지만 x86 개발에 사용 된 기존 패러다임을 사용하면 극히 드문 일이며 아마도 예상 된 주소 메모리 오류 등을 방지하기 위해 완전히 별도의 두 프로그램을 작성해야 할 필요가있을 것입니다.

ELF 프로그램을이 사용자 지정 바이너리 형식으로 변환하기 위해 x86Lib 테스트 벤치 프로그램에 도구가 제공됩니다. ELF를 직접 사용하지 않는 이유는 대부분의 ELF 프로그램이 매우 간단하게 구문 분석 할지라도 ELF는 상당한 복잡성을 가지고 있기 때문입니다. "ELF"유형 구현에서 이러한 기능을 사용할 수없는 특별한 경우를 작성하는 대신, 매우 간단한 사용자 정의 형식을 사용하고 변환 도구를 제공하는 것이 더 쉽습니다. 이 때문에 평범한 바이너리, PE 및 기타 바이너리 형식 지원을 잠재적으로 제공 할 수도 있습니다.

사용자 지정 형식은 각 섹션의 길이를 나타내는 접두사 맵이있는 플랫 바이트 배열입니다.

//The data field available is only a flat data field, so we need some format for storing
//Code, data, and options.
//Thus, it is prefixed with 4 uint32 integers.
//1st, the size of options, 2nd the size of code, 3rd the size of data
//4th is unused (for now) but is kept for padding and alignment purposes
struct ContractMapInfo {
    //This structure is CONSENSUS-CRITICAL
    //Do not add or remove fields nor reorder them!
    uint32_t optionsSize;
    uint32_t codeSize;
    uint32_t dataSize;
    uint32_t reserved;
} __attribute__((__packed__));

이 맵 후에는 바이트의 단순한 배열 만 남습니다.

흐름:

• LOCATION = 0은 ContractMapInfo 다음의 첫 번째 바이트입니다.
• 옵션 데이터를 LOCATION에서 LOCATION + optionsSize까지의 버퍼에 복사하십시오. optionsSize로 위치를 증가 시키십시오.
• 코드 데이터를 LOCATION에서 LOCATION + codeSize까지의 버퍼에 복사하십시오. codeSize로 LOCATION 증가
• 등등 ...

섹션 설명 :

• 옵션은 현재 사용되지 않으므로 optionsSize는 0이어야합니다. 나중에 종속성 그래프, 신뢰할 수있는 계약 옵션 및 기타 특수 구성 데이터가 포함됩니다. 이 데이터는 계약 코드에 직접 노출되지 않습니다. 단, 옵션에서 특별히 명시하지 않는 한
• 코드는 읽기 전용 실행 코드입니다. 이것은 계약의 메모리 공간에 0x1000으로로드되며 현재 최대 크기는 1Mb입니다. 계약에서이 메모리의 내용을 수정할 수 없습니다. JIT 및 기타 최적화가 더 어려워 질 수 있으므로이 섹션 외부에서 코드를 실행하기위한 요금이 추가 요금이 될 수도 있습니다. 현재이 섹션의 크기는 1Mb이며 codeSize를 초과하는 데이터는 0으로 설정됩니다.
• 데이터는 초기화되고 읽기 - 쓰기 데이터입니다. 이것은 계약의 메모리 공간에 0x100000으로로드되며 1Mb 제한도 있습니다. 일부 문서에서는이 메모리 섹션을 "스크래치 메모리"라고도합니다. 현재이 공간의 크기는 1Mb로 고정되어 있으며 dataSize 이상의 모든 데이터는 0으로 설정됩니다. ELF 파일 (초기화되지 않은 메모리)의 ".BSS"섹션도이 메모리 영역에 저장되지만 연결된 데이터가 없으므로 그걸로 .BSS에 대한 정보를 VM에 제공 할 필요가 없습니다. ELF 파일 변환기는 데이터 크기 + bss 크기가 1Mb를 초과하지 않는지 확인합니다.

스마트 계약 트랜잭션 호출 형식

계약에는 호출 된 계약에 인수를 보내고 호출 된 계약에는 데이터를 반환하는 데 사용할 수있는 호출 스택이 있습니다. 그러나 트랜잭션에서 수많은 데이터 엔티티를 갖는 것은 검증 목적으로 다루는 것이 중요하지 않습니다. 따라서 계약서 호출 용 트랜잭션 형식에는 실제 데이터 필드가 1 개만 있습니다 (현재 EVM과 동일). 그러나 ABI는이 구문 분석을위한 스마트 계약의 책임을 단순화하기 위해 제공됩니다. 형식은 전달하려는 바이트 배열이 하나 인 큰 인수 만 있으면 무시할 수 있습니다.

흐름:

• LOCATION = 0, 데이터의 첫 번째 바이트
• LOCATION에서 32 비트 정수 SIZE를 읽음
• LOCATION이 2 씩 증가합니다 (정수 크기).
• 버퍼는 크기 SIZE로 할당 된 다음 메모리가 LOCATION에서 LOCATION + SIZE로 복사됩니다.
• LOCATION의 크기가 SIZE 씩 증가합니다.
• 데이터가 남아 있지 않을 때까지 반복하십시오.

시스템 호출 인터페이스

Qtum은 Linux 기반 시스템과 매우 유사한 방식으로 syscall을 사용합니다. 스택은 전혀 사용되지 않으며 레지스터 만 사용됩니다. 레지스터보다 많은 인수가 필요한 경우 한 레지스터는 일종의 구조에서 이러한 추가 인수가있는 메모리 영역을 가리켜 야합니다. 인터럽트 번호 0x40은 현재 모든 Qtum 시스템 호출에 사용됩니다.

전화 등록자 :

• EAX - 시스템 호출 번호
• EBX, ECX, EDX, ESI, EDI, EBP - 인수 1-6
• ESP, EFLAGS - 미사용

syscall에서 복귀 할 때 등록 :

• EAX - 반환 값 (0은 일반적으로 길이를 반환하는 연산을 제외한 성공을 의미 함)
• EBX, ECX, EDX, ESI, EBP, ESP, EFLAGS - 수정되지 않음

언어를 사용하여 C ABI에 대한이 인터페이스를 단순화하기 위해 libqtum에 래퍼 함수가 제공됩니다.

.global __qtum_syscall
// long syscall(long number, long p1, long p2, long p3, long p4, long p5, long p6)
__qtum_syscall:
  push %ebp
  mov %esp,%ebp
  push %edi
  push %esi
  push %ebx
  mov 8+0*4(%ebp),%eax
  mov 8+1*4(%ebp),%ebx
  mov 8+2*4(%ebp),%ecx
  mov 8+3*4(%ebp),%edx
  mov 8+4*4(%ebp),%esi
  mov 8+5*4(%ebp),%edi
  mov 8+6*4(%ebp),%ebp
  int $0x40
  pop %ebx
  pop %esi
  pop %edi
  pop %ebp
  ret

libqtum은 각 시스템 콜에 대해 사용하기 쉬운 래퍼 함수를 ​​제공하기 때문에 대부분의 사람들은 syscall을 사용하여 아무 것도 할 필요가 없습니다.