Enable and improve libraries

[mikhailUshakoff]

Abstract

This document describes the storage and utilization of library functions for use in smart contracts.

Motivation

At present, smart contract developers store all smart contract code in a single account. Consequently, they are compelled to repeatedly upload redundant code to the blockchain. If an error or suboptimal code is found within a function, developers must update all smart contracts using that function.

Specifications

Add the following functionality:

• Each account can add/modify/delete library functions if the corresponding logic is implemented within it.

• Each account pays the storage fee for its own library functions.

• Each account using libraries pays gas fees for loading and executing library functions.

• Libraries stored on the master chain are visible on the master chain and on work chains.

• Libraries stored on a work chain are visible only to that work chain.

Changes at the blockchain state level

• The key of the library is considered to be a hash of the initial code and the account address.

• Limit the number of libraries per account to 250.

• Store libraries for workchains.

Changes at the VM level

• Create instructions for updating library code.

Changes at the account level

No changes required.

Cost of storing the library

No changes required.

Cost of loading and using the library

No changes required.

Library upload process

No changes required.

Library modification process

No changes required.

Library usage process

No changes required.

[vp-mazekine]

I would avoid calling this simply "libraries" as it creates confusion with "library" objects in T-Sol.
Let's call it "shared libraries" instead.

Another question that is not clear is about: "Each account can add/modify/delete library functions if the corresponding logic is implemented within it." Does it mean that only the account that has initially deployed some shared library code can update/modify it? Or any account using such a library?

One more question: shall there be backwards compatibility or versioning of libraries not to ruin contracts that use the specific version?

[rualekseev]

Let's call it "shared libraries" instead.

Yes, good idea.

Does it mean that only the account that has initially deployed some shared library code can update/modify it? Or any account using such a library?

The account who deploy library can modify or delete it. Other account can't.
It's possible if account have code for update\delete libraries. If it doesn't have this code, the library will be immutable

One more question: shall there be backwards compatibility or versioning of libraries not to ruin contracts that use the specific version?

At the protocol level we add the ability to deploy, change, use libraries. We don't check what these libraries do
Developers of libraries and smart contracts must themselves monitor the backward compatibility of library versions.

[cryshado]

Each account can add/modify/delete library functions if the corresponding logic is implemented within it.

• We shouldn't call them library "functions" since it could be any tvm cell, not necessarily containing tvm code

Each account pays the storage fee for its own library functions.

• The libraries are stored in AccountState, this is not a feature, it is the same fact as the account pays storage fees for its own balance

Libraries stored on a work chain are visible only to that work chain.

• How would this be solved in the context of every shard in the workchain could have its own shard state? Wouldn't this lead to some "synchronization" of the basechain?

Limit the number of libraries per account to 250.

• Why 250? That number seems weird. Why not 256, for example?

[mnill]

Libraries stored on a workchain will not work when everscale realise that we need to return hypercube routing back, so only masterchain is an opton in my opinion

[rualekseev]

Libraries stored on a workchain will not work when everscale realise that we need to return hypercube routing back, so only masterchain is an opton in my opinion

Why you think that we need to return hypercube? Hypercube is bad for finality

[mnill]

Libraries stored on a workchain will not work when everscale realise that we need to return hypercube routing back, so only masterchain is an opton in my opinion

Why you think that we need to return hypercube? Hypercube is bad for finality

Okay, hypercube or any other form of data sharding.

Actually, I think even vanilla hypercube is not so bad for finality.

What I understand by hypercube routing is that it's about reducing the load on collators/validators. In the case where we have a large number of shards, for example, 100, a collator in order to create a block based on the last master has to manage to import all the blocks from the workchain. It's quite likely that he won't do this instantly, and will be creating his own blocks based on not the very latest master block but based on latest minus 1/2/3. So, with a very high load, it is likely that several master blocks will still be required for a message to travel from one shard to another.

On the other hand, with hypercube routing, a collator only needs to manage to import the blocks from its neighbors in order to create their own blocks based on the last master. I also think that hypercube won't be that slow with the implementation of fast finality; on the contrary, I believe that without hypercube, fast finality will won't work on very large number of shards

[rualekseev]

• The libraries are stored in AccountState, this is not a feature, it is the same fact as the account pays storage fees for its own balance

Yes, this fact is written here, account pay for the libraries they deployed

• We shouldn't call them library "functions" since it could be any tvm cell, not necessarily containing tvm code

Thx, "functions" word is superfluous here

• How would this be solved in the context of every shard in the workchain could have its own shard state? Wouldn't this lead to some "synchronization" of the basechain?

When collator produce shard block it have link to master block and actual state of worchain for the master block.

• Why 250? That number seems weird. Why not 256, for example?

We had a dispute about limits. In general, it was about limiting it to one library or many per account.
I think we need to change the issue. We need to write that the number of libraries per account is limited.
What actual number of libraries per account would be optimal should be decided by tests