State of the Languages

Project Updates
,
7

Thank you for following the latest in Tezos smart contract language development. We have fresh updates on all your favorite languages, including first-quadrimester updates on Albert and Michelson!

Let us know if you have:

  • feedback or suggestions
  • a language you would like to add

Recent development

Albert

January - May 2020

Basile Pesin wrote the first prototype for the Albert compiler in summer 2019 during his internship at Nomadic Labs. Since the beginning of 2020 the focus of Albert developers is to turn this prototype into a Minimal Viable Product for a first release of the Albert compiler.

This includes

  • adding many tests
  • measuring their coverage
  • improving error reporting
  • improving documentation
  • certifying in Coq parts of the compiler pipeline

Most notably they have proved type and semantics preservation for the Albert backend optimizer that operates at the Michelson level.

For more information about the Albert language, see the Albert website. Albert development happens on its public Gitlab repository.

Archetype

The Archetype team is finalizing the 1.0 version of Archetype transcoder. It will provide full support for LIGO and Whyml generation.

Following feedback from early adopters, Archetype syntax has been enhanced:

  • The get method is removed from the asset collection API; retrieving an asset is now done straightforwardly from its key with map-like bracket syntax; for example, the syntax to access field f of asset with key k from the
    my_asset collection is now:

    my_asset[k].f

    As a consequence, it is no longer possible to create a local asset variable, which could make believe you were dealing with an object physically detached from the storage, when the reality is that that field’s updates were automatically synchronized with the storage.

    The double update syntax is sill valid though: for example, in order to update integer field f to 1 the following two expressions are possible:

    my_asset.update(k, { f = 1 });

    my_asset[k].f := 1;

  • It is now possible to update asset collection fields straightforwardly in the update syntax. For example, consider the following assets declaration:

    asset simple_asset {
  str : string;
}

asset my_asset {
  id : string;
  assets : simple_asset collection
}

    The following instruction adds 2 simple assets to the assets fields of asset with key "k":

    my_asset.update("k", { assets += [{"str1"},{"str2"}] });

The LIGO generated code has been improved and optimized to reduce its size, including:

  • use of native LIGO syntax to access maps
  • transcription of an asset collection to a map or a set, based on its structure and usage

At last, on the verification side, the Whyml Archetype theory is being verified. This is the library the whyml-transcoded contract relies on.

LIGO

The LIGO team finished an in-house OCaml generator that can be used to derive

  • comparators
  • printers and exporters
  • other repetitive functions on AST nodes

This will make it possible remove some boilerplate (comparators are extremely fragile to maintain: it’s very easy to add a case to the AST, and update the so that it produces incorrect results 1% of the time), and make it easier to write more intermediate ASTs. It should be possible to use that generator to automatically derive transformations from one AST to the other, only requiring specification of how to handle the parts that actually change.

Added new features:

  • Michelson_pair type: This allows users to define a data structure as they would in Michelson, including ‘%’ annotation.
  • Verbatim string: delimited with {| ... |} instead of " ... " verbatim string are not escaped.
  • Code insertion: a new expression has been added to allow the user to write Michelson code inside LIGO. This code will be present in the produced contract. This feature targets the advance Michelson user who wants specific code to be run instead of LIGO generated code

Error messages, Michelson coverage and bug fixes:

  • Began to refactor error reporting mechanisms to enhance user experience
  • Continued work on error messages, fixing bugs, and support on all Michelson features

Michelson

January - May 2020

The Michelson interpreter is implemented inside the Tezos protocol that is subject to the on-chain governance process. Since the successful activation of the Carthage proposal in March 2020, Nomadic Labs, Cryptium Labs and Marigold work on a new protocol amendment proposal that can be followed on Cryptium Labs’ Gitlab repository.

Michelson updates activated in proto-006 Carthage

Carthage is a housekeeping release, so no deep changes to Michelson were made; primarily small bugfixes. The most noticeable one is that comb pairs can now be used as set elements and to index maps and big maps.

For a detailed description of the Michelson changes in Carthage, see the Carthage protocol documentation.

Reviewed Michelson updates for proto-007

Nomadic Labs, Cryptium Labs, and Marigold plan to soon inject protocol amendment proposals whose main new features are Sapling and Baking accounts. These proposals will also contain changes to Michelson. The most important ones:

  • Refactoring
    • MR 53 Gas accounting is now better separated from the rest of the interpreter.
    • MR 65 Checking for equality of types in the type-checker has been simplified.
    • MR 157 The performance of the interpreter has been improved by identifying some bottlenecks; this will allow for a reduction of gas costs (to be computed).
  • Gas
    • MR 58 Gas units have been rescaled by a factor of 1000 so that the cost of very cheap instructions such as stack manipulations can be observed on execution traces.
  • Type system
    • MR 52 An empty type called never has been added
    • MRs 64, 72, and 135 The following types are now comparable: pair, or, option, unit. chain_id, mutez, key, key_hash, and signature
  • New instructions
    • MR 71 the LEVEL instruction has been added, it gives access to the level of the current block
    • MR 75 The SELF_ADDRESS instruction has been added, it is equivalent to SELF; ADDRESS but it is also allowed in lambdas
    • MR 54 The very common UNPAIR macro has been promoted as an instruction.
  • Legacy
    • MR 125 The three legacy instructions that are obsolete since the activation of the Babylon protocol (STEPS_TO_QUOTA, CREATE_ACCOUNT and the legacy version of CREATE_CONTRACT) have been removed.

Other Michelson updates planned for protocol 007 proposals

The following changes are planed for the proto 007 proposals and are currently under review:

  • Sapling

    • In order to support smart contracts managing shielded tokens, types for Sapling states and transactions have been added together with instructions to initialize a sapling state and to verify and apply a transaction on a state.

  • Baking accounts

    • The new stateful baking accounts will be associated with a new kind of key hash, called baking_key_hash and exposed as a new Michelson type.
    • An abstract type of PVSS keys pvss_key is also added
    • Baking accounts run a fixed Michelson script performing multisignature authentication. In order to interact with the chain in meaningful ways, new instructions are added to change the keys, to participate in votes, and to deactivate or reactivate delegation. These operations are of a new baking_operation type that can only be emitted by a baking account.

  • Combs

    • In Babylon, several n-ary instructions (DIG, DUG, DIP, and DROP) were added to provide cheap access to stack elements located deep in the stack. For protocol 007, a similar mechanism is planned for comb pairs and comb ors.

  • Tickets

  • Voting power

    • A VOTING_POWER instruction is added returning the number of rolls held by a baker according to the last voting snapshot.

Michelson updates discussed for future amendments

The following features were discussed and could be proposed in a future protocol amendment proposal:

SCaml

Language

SCaml now supports multi-compilation units. This is not an entirely separate compilation, but now users can write library modules to share codes between smart contracts. For this change, [@entry] attribute is now mandatory for the entrypoint definitions.

SCaml.Contract.contract' is added to access a contract entrypoint with the given name.

SCaml supports exception raising by raise. Users now can define custom exceptions and throw them. The exception values are encoded to Michelson values and used for FAILWITH opcode for later investigation. Since Michelson exceptions are always fatal, there is no way to catch these exceptions in SCaml.

Test environment

The SCaml team is working on 2 testing frameworks:

  • Sandboxing/testnet
    This is to test SCaml contracts by actually running in Tezos. The execution results are decompiled back to SCaml values so that the correctness can be checked in OCaml. They are now playing with Flextesa to launch sandbox nodes and run contracts.

  • Simulation in OCaml
    Given emulation semantics of SCaml primitives in OCaml, they can simulate the execution of SCaml contracts in OCaml. This is more ambitious than the former and has to assume the correctness of the compiler, but if it works they can run tests very efficiently in native code.

Social

SCaml did their first SCaml hands-on remotely, using Zoom, as an experiment for a larger event in the near future. It was fun and went smoothly; very good to obtain some experience in remote hands-on. They hope to soon publish the material, which will be available in Japanese.

SmartPy

The SmartPy team is working on the following:

  • building, together with Cryptonomic, a bridge for Chainlink oracles in Tezos
  • working on their next open source release that will contain everything from SmartPy.io/dev + a few specific enhancements in the SmartPy CLI including out-of-the-box sandbox integration
  • added the recent FA2 SmartPy template in SmartPy.io/dev
  • still working on their decompiler (now expected first release in June)
  • continuing the work started with the Faucet Importer and the Ledger Hardware Wallet integration in SmartPy.io

Thank you for reading, and check back soon for our next update!

Eowyn on behalf of the LIGOlang team

5 Likes