The price list

Every compute (C) charge has a fixed price, set from measurements and frozen with the rest of the protocol. One C is about the time a processor core takes for one integer addition that has to wait for the one before it, about one clock cycle. Every other price says how many of those additions an operation was priced to cover, so a division costs 33 and a load from a large memory costs hundreds. Because the prices are fixed numbers, every node charges the same amounts however fast it really runs. This page lists the prices a program author needs to estimate a program's compute. The exact rules are in section 15 of the protocol rules, and when each price is debited is in section 21.

Instructions#

An instruction's price is debited immediately before it executes.

Entering a defined function also pays for its reservation: one C per parameter, declared local and slot of its maximum operand height, plus any stack it adds; the exact debit is in function entry. A conditional branch costs 18, far more than an addition, because it is priced as the branch the processor never predicts.

Memory prices#

A load waits for memory, and how long depends on how much memory the program has. A small memory stays in the processor's caches. Past the processor's own cache, 2 MiB on the slowest machine the prices are set for, an access can be a trip to RAM, and a very large memory also misses the processor's address-translation caches. Loads, stores, the bytes a program moves and the spans it moves them in are therefore priced by the executing instance's current memory size, in 64 KiB pages.

Each memory size has four prices. The load and store prices are the whole price of those instructions. Moving bytes costs the word price for every started 32 bytes, and the span price for every span that holds at least one byte:

words(n)    = ceil(n / 32)
bytes(n, s) = word × words(n) + span × s      n bytes in s spans that hold a byte

A span is a stretch of memory an operation reads or writes in one piece. A memory.copy has two, its source and its destination, and a memory.fill has one. The host has one for each argument it reads and one for an output it writes. Each span can be a trip to RAM on its own, however few bytes it holds, which is why above 2 MiB the span price is that of a store. bytes(n, s) is the price of a memory.copy or memory.fill, of every copy between a program and the host in either direction, of the bytes a program returns, reverts with or emits, and of copying the data segments into a fresh instance.

Up to 2 MiB the prices step with the caches:

Above 2 MiB they follow a curve over the size. L is the memory size on a logarithmic scale, in whole sixteenths of a doubling: 80 at 32 pages, and 16 more for every doubling, up to 256 at 4 GiB.

load  = 770 + (L − 80)² / 48, rounded up
store = 16 + (L − 80)² / 72, rounded up
word  = 12
span  = store

How L is computed between doublings, in integers only, is in memory prices. A successful memory.grow moves the prices for the instructions after it, so a program that keeps its memory at or under 64 KiB gets the cheapest loads and free spans.

Memory#

Each 64 KiB page costs 40,000 C: every page of an instance's initial memory, at preparation, and every page memory.grow adds. The price covers zeroing the page and the operating system's first touch of it. It also bounds memory: one C buys at most about 1.6 bytes of it, so a node knows from the compute capacity alone how much memory a block can need.

Stack#

An invocation's stack holds, for every function active in it, the slots of its reservation, 8 bytes each, and a record of 3 slots. The first 64 KiB, 8,192 slots, of every invocation's stack are part of its start price. Beyond them, the stack is priced like memory: 40,000 C for every 64 KiB that its highest point so far, its mark, passes.

stack pages of a height h = ⌈h / 8,192⌉ − 1, and 0 for h ≤ 8,192

A call that takes the stack above the mark pays for the pages it adds, and the mark moves up. Returning lowers the stack but never the mark, so a stack paid for once is used again for free. A program whose calls stay within the first 64 KiB of stack pays nothing for it; deep recursion pays as memory does, and memory and stack together hold at most about 1.6 bytes per C of the budget.

Hashing#

Every SHA-256 the runtime computes on a program's behalf is priced by the length m of its input: the whole domain-separated message, 7 bytes plus the tag plus the hashed bytes.

sha(m) = 100 + 900 × ceil((m + 9) / 64)

The hashes a node computes along a record's path through the state tree are part of the record's state access, S, not of C.

Invocations#

Every run of a program, a top-level call, a nested call or a deployment's initializer, starts a fresh instance. Its preparation is one debit:

preparation = 40,000
            + 40,000 × pages of initial memory
            + 40 × globals
            + 4 × table entries
            + 12 × active data segments
            + bytes(data bytes, data spans)

The data bytes are the total length of the active data segments, and the data spans are the number of those segments that hold at least one byte, priced at the initial memory's size.

The 40,000 is the start price: setting up and tearing down an instance, whatever the program. The rest pays for the instance's memory, its globals and table, and copying its data.

Code#

Preparing code to run means decoding and validating it, the same work whether a deployment installs it or a call finds it not yet prepared. Its code price is read from the module's section framing alone, so it is known before validation and invalid code pays it too:

code price = 14,400
           + the module's bytes, each at its rate below
           + 1,215 × functions each function section declares
           + 446 × segments each data section declares

A 20 KiB module with no data, global or element section costs 14,400 + 20,480 × 60 = 1,243,200 C, plus 1,215 C for each function it declares. How the framing is scanned, including for malformed modules, is in code and the code-price scan.

A deployment pays the code price for validation every time, and records it in the contract's manifest. A call pays it when its transaction has not yet prepared that CodeHash; further invocations of the same code in the same transaction pay none. Every transaction starts with nothing prepared, so a node's compiled-code cache never makes a transaction cheaper.

Fixed charges#

Where the numbers come from#

The prices were measured on the three kinds of core of one laptop processor, a performance core, an efficiency core and a low-power core with no third-level cache, against a compiling WebAssembly engine with metering. On each core, each operation was timed in the worst form a program can give it, such as a chain of loads that each wait for the previous one or branches with random outcomes, and expressed in that core's own dependent additions. The price is the highest of the three, rounded up. Hashing is priced at the speed of software SHA-256 on the low-power core, as on a processor without SHA instructions, and code at the speed of the reference decoder.

Real programs run well inside their prices: compiled, the reference signature checks and hashes take 6 to 19 percent of the time their C allows. Only a program built to be slow reaches its price, and none exceeds it. Why prices are measured rather than uniform is on prices, not caps.