Limits, gas and data

Running anyone's code on a shared ledger is risky. A program could loop forever, or try to touch things it should not. The Smart Escrow draft answers with tight limits.

Think of the program as a referee in a glass booth.

• It can look. It may read facts from the ledger: who sent the finish request, what an oracle says, if an account holds a credential.
• It has one notepad. It can write to a single small data field on its own escrow. Nothing else.
• It cannot act. It cannot send transactions or change any other record.
• It is on a timer. Each step the program takes uses up gas. When the gas runs out, the program stops and the answer is no.

The person finishing the escrow pays for the gas. Under the draft, unused gas is not refunded.

The size of the timer, the largest allowed program and the price of gas would not be fixed forever. Validators could tune them with the same voting they already use for fees and reserves. They could even set the limit to zero. That would switch all such code off if a serious bug appeared.

Every server would run the code with the same engine, set up the same way. That matters, because all servers must reach the same answer.

Every number here comes from the drafts and may change before any release.

What the code may do, from XLS-100:

• Read ledger objects.
• Write only the Data field of its own Escrow, with the set_data host function. The draft's guideline is one 4 KB Data field per escrow.
• No write access to other ledger objects.
• No transaction emission or creation.

Limits in FeeSettings. The draft adds three fields, changed through the SetFee pseudo-transaction by fee voting:

If GasLimit or BytecodeSizeLimit is voted to 0, EscrowCreate with Bytecode fails with temTEMP_DISABLED.

Costs in the draft.

• EscrowCreate with Bytecode: 100 drops, plus 5 drops per byte of code.
• Reserve: the first 500 bytes are covered by the escrow's one owner reserve. Each further 500 bytes adds another.
• EscrowFinish: a higher fee tied to gas. The exact amount is not yet in the specification.

The engine, from XLS-102, also a Draft:

• The runtime is Wasmi, at a fixed version, in interpreted mode. Runtimes meter gas differently, so one fixed choice keeps every server's result identical.
• WASM code reaches the ledger only through host functions. Examples: ldgr_index, amendment_enabled, nft_issuer, check_sig, sha512_half. Each has a set gas cost.
• Native floating point, time, randomness and system I/O are not available to the code.
• A new VM instance is created for each run, so no state leaks between runs.
• Code cannot iterate over global ledger state. It reads entries by ID.
• Gas adds up from WASM instructions, memory growth and host function calls.

XLS-102 notes that its host functions are heavily inspired by the Hooks host functions on Xahau. The designs still differ: Smart Escrow code is attached to one escrow and cannot emit transactions.

Related: Hooks and Xahau, Where it stands.