Scalable smart contracts on Tezos

Jérémy Martin
December 6, 2023
Blockchain

Innovation and adaptability are cornerstones of the blockchain ecosystem. At the heart of this evolution are smart contracts, autonomous programs that execute pre-implemented logic, including value transfer capabilities. The power of this architecture lies in its inalienability, which generates trust. Paradoxically, the ability to upgrade smart contract logic can help adhere to changing regulations, fix security flaws, or integrate functional improvements. This modularity is particularly valuable for establishing quick and efficient update mechanisms.

1. The Utility of Scalable Smart Contracts

Scalable smart contracts, also known as amendable, versionable, or upgradable, are defined as smart contracts whose execution logic can be dynamically modified. This goes beyond typical modifications applied to a smart contract, such as updating variables or data structures. For example, in the financial sector, tokens can be updated to incorporate more recent compliance mechanisms. In decentralized applications, functionalities can be enhanced or adapted based on user feedback or market developments.

A. A Fixed Identifier

A key strength is that versionable contracts allow for a fixed address on the blockchain, even considering logical updates. A fixed address is a sort of Holy Grail, as with real addresses or Twitter IDs, enabling a bijective addressing system, where each character string corresponds to a unique endpoint. This strong correspondence has very interesting properties that can be exploited.

B. Achieving a Quality User Experience

This scalability also ensures a better user experience, as services can be improved without major interruptions. In the context of decentralized governance, it allows for active community participation in the evolution of protocols, for example, by implementing voting systems or others. Another essential aspect is compatibility with existing ecosystems and ease of transition to other standard systems. Scalable smart contracts have mechanisms for seamless, disruption-free migration, allowing users and existing smart contracts to easily adapt to new versions.

C. Finely Resolving the Antinomy of the Right to Modify

It's important to note that the scalability of a smart contract raises the fundamental question: "who has the right to propose or apply updates to the smart contract, and by what consensus mechanism?" While not directly addressing this aspect, any governance mechanism can be attached to this type of technical architecture. For example, a DAO (Decentralized Autonomous Organization) could be considered. Decentralization is a fundamental principle and must be well-calibrated. Any upgradable smart contract system must respect this aspect, avoiding excessive centralization of power or control in the hands of a few. Scalable smart contracts must develop governance mechanisms for updating smart contracts, allowing fair community participation.

2. Amendable Contracts on Tezos

In the case of the Tezos blockchain, discussed here, the scalability of smart contracts is also called the 18th Tezos Improvement Proposal (TZIP-18). With its self-amending governance model, this architecture is particularly relevant, as the Tezos blockchain itself is self-amendable.

A. Technical Specifics of Tezos

Tezos stands out for its innovative governance and consensus mechanisms. However, these unique features pose challenges for integrating upgradable smart contracts. Tezos uses a specific smart contract language, LIGOLang, which requires a deep understanding for developing upgradable solutions. Therefore, the proposal for scalable smart contracts must be designed considering these technical peculiarities, ensuring total compatibility with the Tezos ecosystem.

B. Balancing Security and Flexibility

A major challenge is balancing security and flexibility. Upgradable smart contracts, by their very nature, introduce additional risk vectors, especially regarding fund security and smart contract integrity. Thus, the amendable smart contract proposal must incorporate robust mechanisms to prevent any abuse or vulnerability, while retaining the necessary flexibility for updates. For end-users, upgradable smart contracts mean greater trust in the durability and responsiveness of the applications they use. They benefit from constant improvements and assurance that the applications will remain compatible with emerging standards and market expectations.

C. Performance and Optimization

Upgradable smart contracts can affect blockchain performance due to their increased complexity and the additional calls needed to manage scalability logic. The use of scalable smart contracts is optimized to minimize the impact on transaction speed, network load, and execution costs in terms of gas and data stored on the blockchain.

3. Overview of the Implementation Architecture

The proposal for amendable smart contracts introduces a completely innovative architecture and implementation method. This section details the key components of this architecture. The goal is to evolve an arbitrary smart contract from version 1 to version 2 containing new functionalities.

Our scalable smart contract system is based on a modular architecture, consisting of a smart contract called the proxy that transfers the processing request to the correct functional version of the contract. In computing, proxy means “intermediary”. It indeed plays an intermediary role between the calling user and the contracts containing the actual processing logic. It can also be seen as a routing module between different versions containing updates.

The proxy acts as a single entry point for user interactions, while auxiliary smart contracts contain the specific logic for functionalities and can be updated or replaced independently. The proxy delegates calls to the appropriate smart contracts and ensures that interactions remain smooth and secure, even after an upgrade.

Upgrade Mechanism

The system allows for deploying new smart contracts and updating references in the proxy. This approach ensures that improvements can be made without interrupting the smart contract's operation. Thus, there is no possibility of service disruption.

The following parts are very technical, and some ideas have been simplified for a global overview of the system.

1. The Constraint of Transformation Functions

When moving from version 1 to version 2, there is also a transition from state 1 to state 2. Therefore, a transformation function must be defined. For example, if a variable goes from a range of 1 to 10 to a range of 1 to 100, a transformation rule must be determined, and there are infinitely many possible rules. In our case, we could copy the initial value, add 90 to it, or multiply the initial value by 10, and these choices are valid as they transition from a range of 1 to 10 to a range of 1 to 100. It's now a business sense question about what this value represents.

A transformation function must be implemented for each data of each contract version. These functions must be implemented in the higher version smart contract (e.g., in smart contract version 3 for transforming version 2 into version 3).

B. The Constraint of Lazy Mappings

Some classes of data structures are handled lazily, meaning it’s not possible to know their value simply, and in particular, they cannot be copied or sent to other functions or messages. This is due to the underlying implicit constraints of blockchain architecture.

To solve this problem, we don't simply transport data from one version to the next: the successor version takes complete control of the lower version and uses it as a phantom database. The old zombie version can no longer receive calls or use its logic, but the higher transformation function can retrieve the data from its lazy mappings, qualify and transform them, and then bring them into the contract of the next version.

C. The Constraint of Having a Strict Machine

The state assembly machine used for the Tezos engine is based on OCaml and can only process smart contracts compiled in Michelson. This language is strictly typed by construction in the computer science sense, meaning all data are strongly typed.

In particular, all function calls must be typed, and since the entry points of the proxy contract are functions, we must know in advance all the data types. However, this is problematic in our case because we don’t know in advance the data we will use in future versions!

The solution we propose is to pack all data into a generic byte format and unpack the data at each call, then match the unpacked data with what the function expects. If the data match what is expected, we can continue processing normally.

In conclusion, this article presents the notion of scalable smart contracts and some of their constraints, focusing particularly on the Tezos blockchain. It highlights the importance of adaptability in the blockchain ecosystem, emphasizing the crucial role of reasonable architecture in the evolution of technology.

Written by
Jérémy Martin
Research Director