ever-node
ever-node copied to clipboard
everx-labs
Enable and improve libraries
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.
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?
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.
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?
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
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
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
- 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