EOSIO-lock, a free open source service provides temporary immutability to eos smart contracts

bloxchanger
5 min readAug 18, 2019

EOSIO-lock.net

Introduction

One of the features of the blockchains based on the EOSIO framework is that the smart contract’s code can be easily updated and modified by the account owner. This possibility differentiates EOS based systems from others, like the Ethereum platform, where code is immutable once deployed on the blockchain.

While this feature is extremely useful from a developer’s perspective, as it allows programmers to fix bugs and update the code with new versions, it may result less convenient from the perspective of the smart contract’s users. In fact, the program owner could decide at any time to change the code and divert the users’ resources to his advantage.

Consider, for instance, the case of a distributed application (dapp) that during his normal operations needs to collect token deposits from its users. This would be the case, for example, for many gambling, financial or even internet-of-things related blockchain applications. Now, if the contract is not immutable, a significant amount of trust would be required from the users’ side in order to make a deposit on the dapp’s account where the developer can decide to change the code in any way that allows him to steal all the deposited funds.

The EOSIO framework already provides a solution to these issues. In particular, the account permission system allows to replace the account keys with an “eosio.null” permission which makes the account, and the corresponding smart contract, immutable. In this case, the code will never again become amendable and the account creator will never get back in control of the account and code. This solution will, in fact, reproduce the way smart contracts work in other platforms as for example the Ethereum blockchain.

However, for many applications, turning into a completely immutable and non recoverable account might be an unnecessary and too extreme solution. In particular, there are many cases which might require only temporary immutability and might still benefit from the possibility to update the code from time to time.

The EOSIO-lock service proposes a solution that exploits the possibilities offered by the extremely flexible Eos permission system together with the programming features of the platform in order to provide temporary immutability for eos accounts.

Temporary immutability might be very useful for all the cases where the users would make a deposit on a given smart contract’s account and then use or withdraw the deposited funds in a relatively short time. Think for instance to a gambling dapp. The developer might turn the account to temporary-immutable for consecutive periods of, say, one month. During each one-month period the users can play on the dapp being reassured that the developer cannot change the code to his advantage and no trust would be required on this side. At the same time, the developer would have the possibility to regain control of his account at the end of each one-month period in order to fix and update the code.

The first prototype developed by the EOSIO-lock service was deployed on the accountlock1 address on the Eos mainnet. The service was also deployed on the accountlock1 address of the Telos mainnet. It is a completely secure dapp that can lock a target account for a pre-defined time and ensures that no-one has control of that account while locked.

How it works

First of all, the original accountlock1 keys were removed and the permissions were set to “eosio.null” in order to turn the account into an immutable account. Therefore, the utility is deployed on an immutable account.

The smart contract deployed on the account has two main actions:

  • lock(target_contract, lock_time, public_key_string)

This function can be used to lock a given target account/contract. The parameters to be provided include the name of the account that we want to lock, the lockup time (in seconds) and the public key (string) that should be assigned to the contract once it gets unlocked.

The action requires an authority from the target account ensuring that only the possessor/s of the account can activate the lockup procedure. In order to be able to correctly run the lockup process, the owner/s of the account must add the accountlock1@eosio.code authority to the owner permission before calling the lock action.

Once the lock action is called, it will replace the keys assigned to the owner and active permissions with the accountlock1@eosio.code authority. In addition, it will add a record on a multi-index table stored on the accountlock1 address which will include the name of the locked account, the date and time after which it can be unlocked and the public key which will be assigned after the contract is unlocked.

At this point and until the expiry date of the lockup period, no-one will be able to operate the account except the accountlock1 contract’s code. Since the account-lock contract was turned into an immutable contract, the code cannot be changed and the only action that can be called for this contract would be the unlock action.

  • unlock(target_contract)

The unlock action has only one parameter which specifies the name of the account to be unlocked. It will run successfully only once that the defined deadline has expired.

This action does not require any authorization and can be run by any account (please note that, of course, it cannot be called using the locked account itself as no-one has control of the required keys and authority while locked).

Once called, the action will restore the public key defined during the lockup as the owner and active permission key. At this point the account will thus be unlocked and the owner of the public key gets back in control of the account and contract’s code.

In addition, the unlock action removes the previously saved record on the account-lock data table. Please note that while an account is locked, the data table stored on the accountlock1 contract provides at the same time a certification of the lockup and information of the unlock time/date. Any dapp user can easily access these details using an eos blockchain explorer.

Possible future improvements and additional features

The accountlock1 contract is a first application that conditions the lock/unlock feature to an elapsing period of time. More advanced versions of the application may condition the lockup to different constraints and more articulated parameters. The utility may be implemented in such a way that a contract gets unlocked only when a given condition is met. For instance, it could be unlocked only when a given percentage of users express their vote in favor to a hypothetical unlock proposal. Otherwise, it could be structured in such a way that it gives control back to the owner/developer only when the deposits from the dapp users are all withdrawn or reduced to zero.

Other potential improvements involve the user interface of the application. Currently, the accountlock1 contract does not have a web interface and must be activated from the cleos command line or through one of the eos toolkits available on the web. Future improvements may involve the development of an online user interface that allows developers and users to directly activate the smart contract’s actions and easily setup the required parameters.

--

--