aesophia_http

An HTTP interface to the Sophia compiler. It handles compiling contracts and generating ACI data for contract. The examples show

HTTP interface uses port 3080, settable with application variable aesophia_http.port.

Interface paths (see the config/swagger.yaml for details):

/aci - generate ACI format for contract in both JSON encoded and textual decoded forms. Tags 'code' and 'options'.

/compile - compile contract and return code in a JSON structure encoded to contract_bytearray.

/decode-call-result - Tags 'source', 'function', 'call-result', 'call-value'.

/decode-call-result/bytecode - Tags 'bytecode', 'function', 'call-result', 'call-value'.

/encode-calldata - Tags 'source', 'function' and 'arguments'.

/decode-calldata/bytecode - Input calldata and contract bytecode, get function name and VM type arguments.

/decode-calldata/source - Input calldata and (possibly partial) conctract source code, get function name and Sophia type arguments.

/validate-byte-code - Check that some bytecode was produced from the given source code.

/fate-assembler - Get the FATE assembler (as a string) from FATE bytecode.

/compiler-version - Extract the compiler version from bytecode.

/version - return the version of the Sophia compiler

/api-version - return the version of the API

/api - return the API in a JSON-term (intended to be consumed by tools)

Usage

We publish a docker image as aeternity/aesophia_http - so if docker is in place all that is needed to have an HTTP server serving the Sophia compiler API is:

Where PORT is the local port where you'd like the API to be served.

Building

The most convenient way to start the an HTTP server serving the Sophia compiler API is using docker. make docker will create a docker image aeternity/aesophia_http:local and it is started by docker run -p <PORT>:3080 aeternity/aesophia_http:local where PORT is the local port where you'd like the API to be served.

Examples

In all the following examples we use the contract SimpleStorage defined as:

Preparation

To make the example calls easier to read we have bound the shell variable $contract to the contract definition:

Generating ACI

To get the ACI of the contract we use the /aci interface:

Returns:

Important: If your contract code contains quotes, you need to escape every quote with a backslash:

This returns a structure with two fields: encoded_aci is a description of the contract containing the types and functions;interface is a definition of the contract suitable to be included in other contracts.

Compiling contract to bytecode

We can now compile the contract and get the bytecode:

Returns:

Validating bytecode

You can check that some particular bytecode, for instance obtained from the chain, was compiled from given source code, using the validate-byte-code endpoint:

Returns:

Validating against source code with a different implementation of id returns:

Getting fate assembler

You can get the FATE assembler code for some particular bytecode:

Returns:

Encoding calldata

To encode the call data necessary to call the function set with the argument 42:

Returns:

Decoding call data

Call data from transactions can be decoded in two ways, either using the contract bytecode (this is a long one) which returns the VM types and values, or the Sophia contract source.

With Contract Bytecode

Example:

Returns:{"arguments":[{"type":"word","value":42}],"function":"set"}

With Sophia Source

And secondly, using the Sophia contract source which returns the Sophia types and values:

Returns:

Decoding return value

You can also decode the return value of a contract call:

Returns:

The contract call result can also be decoded using the bytecode as a starting point:

Returns:

Getting the compiler version used

You can extract the compiler version that was used to compile some particular bytecode:

Returns:

Complete API overview

To get information about the current version of the Sophia compiler, API version and the whole actual API (paste into any swagger file generator):

Note that in a future release the swagger specification will be replaced by an OpenAPI 3.0 specification.

Last updated

Was this helpful?