시작하기 스마트 컨트랙트 노드 운영 dApp 개발자

클레이튼 가상머신 (구 버전 문서)

NOTE: This document contains the KLVM used before the activation of the protocol upgrade. If you want the latest document, please refer to latest document.

Overview

The current version of the Klaytn Virtual Machine (KLVM) is derived from the Ethereum Virtual Machine (EVM). The content of this chapter is based primarily on the Ethereum Yellow Paper. KLVM is continuously being improved by the Klaytn team, thus this document could be updated frequently. Please do not regard this document as the final version of the KLVM specification. As described in the Klaytn position paper, the Klaytn team also plans to adopt other virtual machines or execution environments in order to strengthen the capability and performance of the Klaytn platform. This chapter presents a specification of KLVM and the differences between KLVM and EVM.

KLVM is a virtual state machine that formally specifies Klaytn's execution model. The execution model specifies how the system state is altered given a series of bytecode instructions and a small tuple of environmental data. KLVM is a quasi-Turing-complete machine; the quasi qualification stems from the fact that the computation is intrinsically bounded through a parameter, gas, which limits the total amount of computation performed.

KLVM executes Klaytn virtual machine code (or Klaytn bytecode) which consists of a sequence of KLVM instructions. The KLVM code is the programming language used for accounts on the Klaytn blockchain that contain code. The KLVM code associated with an account is executed every time a message is sent to that account; this code has the ability to read/write from/to storage and send messages.

KLVM 사양

표기 규칙

We use the following notations and conventions in this document.

  • A := B

    • : = A를 <code> B로 정의하는 데 사용됩니다.

  • "스마트 컨트랙트"와 "컨트랙트"라는 용어를 번갈아 사용합니다.

  • We use the terms "opcode" as the "operation code/operation"

기호

The following tables summarize the symbols used in the KLVM specification.

블록체인 관련 기호

기호Description

BC

블록체인

B

Block

B_header

현재 블록의 블록 헤더

상태 관련 기호(State-Related Symbols)

SymbolDescription

S

상태(State)

S_system

시스템 상태

S_machine

머신 상태

P_modify_state

상태 수정 권한

트랜잭션 관련 기호(Transaction-related symbols)

SymbolDescription

T

Transaction

T_code

실행할 머신 코드를 포함하는 바이트 배열(byte array)

T_data

입력 데이터를 포함하는 바이트 배열. 실행 에이전트(execution agent)가 트랜잭션인 경우, 이것은 트랜잭션 데이터가 됩니다.

T_value

Pep 단위로 표기된 값이 실행 과정 중에 계정을 전달됩니다. 만약 실행 에이전트가 트랙잭션이라면 이 값은 트랜잭션 값이 됩니다.

T_depth

현재 메시지 호출 또는 컨트랙트 작성 스택의 깊이 (즉, 현재 호출 또는 실행 횟수)

가스 관련 기호(Gas-Related Symbols)

SymbolDescription

G

가스

G_rem

연산에 사용하기 위한 남은 잔여 가스

G_price

실행 시작한 트랜잭션의 가스 가격

주소 관련 기호(Adress-Related Symbols)

SymbolDescription

A

Address

A_code_owner

실행 코드를 소유한 계정의 주소

A_tx_sender

현재 실행을 시작한 트랜잭션의 발신자 주소

A_code_executor

코드를 실행한 계정의 주소. 실행 에이전트가 트랜잭션이라면, 이는 트랜잭션 발신자(transaction sender) 가 됩니다.

함수

SymbolDescription

F_apply

주어진 상태에 입력된 트랜잭션을 적용하고 결과 상태 및 출력을 반환하는 함수

기본 사항

KLVM is a simple stack-based architecture. The word size of the machine (and thus the size of stack items) is 256-bit. This was chosen to facilitate the Keccak-256 hash scheme and the elliptic-curve computations. The memory model is a simple word-addressed byte array. The stack has a maximum size of 1024. The machine also has an independent storage model; this is similar in concept to the memory but rather than a byte array, it is a word-addressable word array. Unlike memory, which is volatile, storage is nonvolatile and is maintained as part of the system state. All locations in both storage and memory are initially well-defined as zero.

The machine does not follow the standard von Neumann architecture. Rather than storing program code in generally accessible memory or storage, code is stored separately in virtual read-only memory and can be interacted with only through specialized instructions.

The machine can execute exception code for several reasons, including stack underflows and invalid instructions. Similar to an out-of-gas exception, these exceptions do not leave state changes intact. Rather, the virtual machine halts immediately and reports the issue to the execution agent (either the transaction processor or, recursively, the spawning execution environment), which will be addressed separately.

트랜잭션 수수료 개요

Fees (denominated in gas) are charged under three distinct circumstances.

  • The first and most common is the constantGas. It's a fee intrinsic to the computation of the operation.

  • Second, gas may be deducted to form the payment for a subordinate message call or contract creation; this forms part of the payment for CREATE, CALL and CALLCODE.

  • Finally, gas may be charged due to an increase in memory usage.

Over an account's execution, the total fee payable for memory-usage payable is proportional to the smallest multiple of 32 bytes that are required to include all memory indices (whether for read or write) in the range. This fee is paid on a just-in-time basis; consequently, referencing an area of memory at least 32 bytes greater than any previously indexed memory will result in an additional memory usage fee. Due to this fee, it is highly unlikely that addresses will ever exceed the 32-bit bounds. That said, implementations must be able to manage this eventuality.

Storage fees have a slightly nuanced behavior. To incentivize minimization of the use of storage (which corresponds directly to a larger state database on all nodes), the execution fee for an operation that clears an entry from storage is not only waived but also elicits a qualified refund; in fact, this refund is effectively paid in advance because the initial usage of a storage location costs substantially more than normal usage.

비용표

The fee schedule G is a tuple of 37 scalar values corresponding to the relative costs, in gas, of a number of abstract operations that a transaction may incur. Also, there's gas items to calculate the gas of the precompiled contracts called by CALL_* opcodes. For other tables such as intrinsic gas cost or key validation gas cost, please refer to this document

Scalar values representing constantGas of an opcode

Name값Name in codeOpcodes

G_base

2

GasQuickStep

ADDRESS, ORIGIN, CALLER, CALLVALUE, CALLDATASIZE, CODESIZE, GASPRICE, COINBASE, TIMESTAMP, NUMBER, DIFFICULTY, GASLIMIT, RETURNDATASIZE, POP, PC, MSIZE, GAS

G_verylow

3

GasFastestStep

ADD, SUB, LT, GT, SLT, SGT, EQ, ISZERO, AND, OR, XOR, NOT, BYTE, CALLDATALOAD, MLOAD, MSTORE, MSTORE8, PUSH, DUP, SWAP

G_low

5

GasFastStep

MUL, DIV, SDIV, MOD, SMOD, SIGNEXTEND

G_mid

8

GasMidStep

ADDMOD, MULMOD, JUMP

G_high

10

GasSlowStep

JUMPI

G_blockhash

20

GasExtStep

BLOCKHASH

G_balance

400

BalanceGas

BALANCE

G_sload

200

SloadGas

SLOAD

G_jumpdest

1

JumpdestGas

JUMPDEST

G_sha3

30

Sha3Gas

SHA3

G_call

700

CallGas

CALL, CALLCODE, STATICCALL, DELEGATECALL

G_create

32000

CreateGas

CREATE, CREATE2

G_extcodesize

700

ExtcodeSizeGas

EXTCODESIZE

G_extcodehash

400

ExtcodeHashGas

EXTCODEHASH

Scalar values used to calculate the gas based on memory and log usage

NameValueName in CodeDescription

G_memory

3

MemoryGas

Amount of gas paid for every additional word when expanding memory

G_copy

3

CopyGas

Partial payment for COPY operations, multiplied by words copied, rounded up

G_log

375

LogGas

Partial payment for a LOG operation

G_logdata

8

LogDataGas

Amount of gas paid for each byte in a LOG operation's data

G_logtopic

375

LogTopicGas

Amount of gas paid for each topic of a LOG operation

Scalar values used to calculate the gas of the particular opcode

NameValueName in CodeDescription

G_sset

20000

SstoreSetGas

Amount of gas paid when the storage value when set storage

G_sreset

5000

SstoreResetGas, SstoreClearGas

Amount of gas paid when the storage value remains unchanged at zero or is set to zero

R_sclear

15000

SstoreRefundGas

Refund Gas given (added to the refund counter) when the storage value is set to zero from nonzero

G_exp

10

ExpGas

Partial payment

G_expbyte

50

ExpByte

Partial payment when multiplied by ceil(log_256(exponent))

G_selfdestruct

5000

SelfdestructGas

Amount of gas paid for a SELFDESTRUCT operation

R_selfdestruct

24000

SelfdestructRefundGas

Refund Gas given (added to the refund counter) for self-destructing an account

G_callvalue

9000

CallValueTransferGas

Amount of gas paid for a nonzero value transfer

G_callstipend

2300

CallStipend

Free gas given at beginning of call for a nonzero value transfer

G_newaccount

25000

CallNewAccountGas

Amount of gas paid when creating an account. It is also be defined as CreateBySelfdestructGas with SELFDESTRUCT operation.

G_codedeposit

200

CreateDataGas

Amount of gas paid per byte for a creating a contract that succeeds in placing code into state

G_sha3word

6

Sha3WordGas

Amount of gas paid for each word (rounded up) for an SHA3 input data

Items to calculate the precompiled contracts gas

Precompiled contracts are special kind of contracts which usually perform complex cryptographic computations and are initiated by other contracts.

For example, gas cost can be calculated simply like below, but some gas cost calculation functions are very complex. So I would not explain the exact gas cost calculation function here.

# ecrecover, sha256hash, ripemd160hash, dataCopy
Gas = XXXBaseGas + (number of words * XXXPerWordGas)

# validateSender
Gas = number of signatures * ValidateSenderGas
AddressPrecompiled contractsItemValue

0x01

ecrecover

EcrecoverGas

3000

0x02

sha256hash

Sha256BaseGas, Sha256PerWordGas

60, 12

0x03

ripemd160hash

Ripemd160BaseGas, Ripemd160PerWordGas

600, 120

0x04

dataCopy

IdentityBaseGas, IdentityPerWordGas

15, 3

0x05

bigModExp

ModExpQuadCoeffDiv

20

0x06

bn256Add

Bn256AddGas

150

0x07

bn256ScalarMul

Bn256ScalarMulGas

6000

0x08

bn256Pairing

Bn256PairingBaseGas, Bn256PairingPerPointGas

45000, 34000

0x09

vmLog

VMLogBaseGas, VMLogPerByteGas

100, 20

0x10

feePayer

FeePayerGas

300

0x11

validateSender

ValidateSenderGas

5000

Gas calculation during contract execution

The gas cost of one transaction is calculated through the methods described below. First, gas is added according to the transaction type and input. Then, if the contract is executed, opcodes are executed one by one until the execution ends or STOP operation appears. In the process, the cost is charged according to the constantGas defined for each opcode and the additionally defined gas calculation method.

Below is a brief explanation of the gas calculation logic during contract execution using the fee schedule variables defined above. As it assumes a general situation, unusual situations such as revert appears is not considered.

  • add constantGas defined in each opcode to gas

    • e.g. if an opcode is MUL, add G_low to gas

    • e.g. if an opcode is CREATE2, add G_create to gas

  • add the gas which is calculated through additionally defined gas calculation method

    • For LOG'N', where N is [0,1,2,3,4], add G_log + memoryGasCost * g_logdata + N x G_logtopic to gas

    • For EXP, add G_exp + byteSize(stack.back(1)) x G_expbyte to gas

    • For CALLDATACOPY or CODECOPY or RETURNDATACOPY, add wordSize(stack.back(2)) x G_copy to gas

    • For EXTCODECOPY, add wordSize(stack.back(3)) x G_copy to gas

    • For SHA3, add G_sha3 + wordSize(stack.back(1)) x G_sha3word to gas

    • For RETURN, REVERT, MLoad, MStore8, MStore, add memoryGasCost to gas

    • For CREATE, add memoryGasCost + size(contract.code) x G_codedeposit

    • For CREATE2, add memoryGasCost + size(data) x G_sha3word + size(contract.code) x G_codedeposit to gas

    • For SSTORE,

      • From a zero-value address to a non-zero value (NEW VALUE), add G_sset to gas

      • From a non-zero value address to a zero-value address (DELETE), add G_sreset to gas and add R_sclear to refund

      • From a non-zero to a non-zero (CHANGE), add G_sreset to gas

    • For CALL, CALLCODE, DELEGATECALL, STATICCALL,

      • if it is CALL and CALLCODE and if it transfers value, add G_callvalue to gas

      • if it is CALL and if it transfers value and if it is a new account, add G_newaccount to gas

      • if the callee contract is precompiled contracts, calculate precompiled contract gas cost and add it to gas

      • add memoryGasCost + availableGas - availableGas/64, where availableGas = contract.Gas - gas to gas

    • For SELFDESTRUCT,

      • if it transfers value and if is a new account, add G_newaccount to gas

      • if the contract has not suicided yet, add R_selfdestruct to refund

실행 환경

실행 환경은 시스템 상태 S_system, 연산을 위해 남은 가스 G_rem, 실행 에이전트가 제공하는 정보 I으로 이루어져 있습니다. I는 다음과 같이 정의된 튜플입니다.

I := (B_header, T_code, T_depth, T_value, T_data, A_tx_sender, A_code_executor, A_code_owner, G_price, P_modify_state)

실행 모델은 F_apply 함수를 정의하는데, 이로 결과로 나온 상태 S_system', 잔류 가스 G_rem ' , 발생한 하위 상태 A 및 결과적인 출력 O_result 를 계산할 수 있습니다. 현재는 다음과 같이 정의합니다.

(S_system', G_rem', A, O_result) = F_apply(S_system, G_rem, I)

여기서 우리는 발생된 하위 상태인 A는 suicides 집합인 Set_suicide, 로그 시리즈 L, 접근한 계정의 집합 Set_touched_accounts , 그리고 환불 G_refund의 튜플로 정의된다는 것을 기억해야 합니다.

A := (Set_suicide, L, Set_touched_accounts, G_refund)

실행 개요

대부분의 실제 구현에서 F_apply는 전체 시스템 상태 S_system과 머신 상태 S_machine 쌍의 반복적인 진행으로 모델링됩니다. 형태적으로, 우리는 상태 머신에서 하나의 사이클의 결과값을 정의하는 이터레이터 함수 O와 현재 상태가 예외적으로 중단된 머신 상태인지 확인하는 함수 Z, 그리고 현재 상태가 정상적으로 중단된 머신 상태일 경우에만 명령어의 출력 데이터를 지정하는 H를 사용하는 함수 X를 이용하여 재귀적으로 정의합니다.

빈 시퀀스 ()는 빈 Set을 가리키는 Set_empty와는 다릅니다. 이는 H의 결과를 해석할 때 중요한데, 실행을 계속해도 된다면 결과가 Set_empty이고 실행이 중지되어야 한다면 결과가 (아마도 비어 있을)시퀀스이기 때문입니다.

F_apply(S_machine, G_rem, I, T) := (S_system', S_machine,g', A, o)

  • (S_system', S_machine,g', A, ..., o) := X((S_system, S_machine, A^0, I))

  • S_machine,g := G_rem

  • S_machine,pc := 0

  • S_machine,memory := (0, 0, ...)

  • S_machine,i := 0

  • S_machine,stack := ()

  • S_machine,o := ()

  • X((S_system, S_machine, A, I)) :=

    • (Set_empty, S_machine, A^0, I, Set_empty) if Z(S_system, S_machine, I)

    • (Set_empty, S_machine', A^0, I, o) if w = REVERT

    • O(S_system, S_machine, A, I) · o if o != Set_empty

    • X(O(S_system, S_machine, A, I)) otherwise

where

  • o := H(S_machine, I)

  • (a, b, c, d) · e := (a, b, c, d, e)

  • S_machine' := S_machine except

    S_machine,g' := S_machine,g - C(S_system, S_machine, I)

    • 이는 F_apply를 계산할 때

      남은 가스 S_machine,g'를

      결과로 남은 머신 상태 S_machine'에서 차감한다는 의미입니다.

따라서 Z가 true 즉 현재 상태에 예외가 발생했으며 머신이 반드시 중지되어야 하고 따라서 모든 상태 변화는 무시되는 상황이 될 때까지, 또는 H가 (Set_empty가 아닌) 시퀀스가 될 때 즉 머신이 통제 가능한 중지 상황에 이를 때까지 X는 재귀적으로(보통 실제 구현은 단순한 반복 루프 사용) 반복해서 정의됩니다.

머신 상태

머신 상태 S_machine는 튜플 (g, pc, memory, i, stack)로 정의됩니다. 이는 사용 가능한 가스량, 프로그램 카운터 pc (64-bit unsigned integer), 메모리 컨텐츠(memory contents,), 현재 메모리에 있는 단어 수(position 0부터 계속 카운팅), 스택 컨텐츠(stack contents)를 의미합니다. 메모리 컨텐츠 S_machine,memory는 사이즈가 2^256이며 0으로 이루어진 series입니다.

For ease of reading, the instruction mnemonics written in small-caps (e.g., ADD) should be interpreted as their numeric equivalents; the full table of instructions and their specifics is given in the Instruction Set section.

Z, H와 O를 정의하기 위해, w를 실행할 현재 연산으로 정의합니다.

  • w := T_code[S_machine,pc] if S_machine,pc < len(T_code)

  • w :=STOP otherwise

명령어 세트(Instruction Set)

참고: 이 장은 나중에 업데이트 될 예정입니다.

KLVM과 EVM의 차이점

앞에서 언급했듯이 현재 KLVM은 EVM을 기반으로합니다. 따라서 현재 사양은 EVM의 사양과 매우 유사합니다. KLVM과 EVM의 몇 가지 차이점은 다음과 같습니다.

  • KLVM은 peb, ston 또는 KLAY와 같은 Klaytn의 가스 단위(unit)를 사용합니다.

  • KLVM은 사용자로부터 가스 가격을 입력 받지 않습니다. 대신, 플랫폼이 정의한 값을 가스 가격으로 사용합니다.

Klaytn팀은 KLVM과 EVM간의 호환성을 유지하려고 노력하지만 Klaytn이 점차 구현되고 발전함에 따라 KLVM 사양이 업데이트되며, EVM과 비교하여 더 많은 차이가 생겨날 수 있습니다.

참고: 이 장은 나중에 업데이트 될 예정입니다.

PreviousKlaytn 가상머신Next스토리지

Last updated