This post introduced LabNet, an experimental test network aimed at Tezos hackers. The goal of LabNet is to be built openly in interaction with the community, and with a focus on experimentation and features with immediate utility.
As mentioned in the previous post, when introducing a feature, we want to integrate it with the entire pipeline, which includes among other things the protocol, smart-contract languages, development libraries, wallets, etc. As such, it will be the chance to experiment with full-stack coordination, even sometimes yielding real prototypes and demos.
This post is meant as a starting point, as a way to open the discussion about which features we should work on and prioritize. We’ll show some features that we have in mind, with basic explanations.
Smart Contracts Features
Views have been explained in this post. We will iterate over the prototype and integrate them. We’re also open to discussing and/or implementing alternative designs as well.
Events are a feature in Ethereum where a smart-contract can leave a trace of information that can be used by wallets and libraries outside the blockchain. Events are a common request from new Tezos developers and can make application development significantly easier. The goal of Events is to know about things that have happened in a given smart-contract without having to monitor all of its operations and their execution stacks.
Hot and Cold Storage
Right now, Tezos makes the assumptions that all contracts are stored on disk. Preliminary benchmarks show that most of the time of a transaction is spent loading the code and storage of the smart-contract.
While it is possible to use caching strategies to optimize this, it is a bad idea to base the gas-cost model on those caching strategies. Indeed, caching strategies optimize for the average case, however, gas pricing has to be estimated on the basis of the worst case (as there is always someone who could try to stall the blockchains by sending operations hitting the worst case).
Given this, a solution would be to have a designated amount of space dedicated to contracts stored in RAM. The size of that space will depend on a trade-off between decentralization and speed. Contracts would be able to purchase a right to be in that space, and contracts there would be much faster and their gas cost (as a consequence) much cheaper.
This is also an opportunity to experiment with space renting models.
The same way optimizations were added in Babylon for combinations of
DUP , we need optimizations for combinations of
CDR . This is the low hanging fruit.
More complex optimizations would involve
JUMBLE in general (a dreamed instruction that can reshuffle the Michelson stack).
For prototyping both OVM and zkRollup, we’ll initially be adding the KECCAK-256 hash function and arithmetic and pairing operations for Barreto-Naehrig elliptic curves. As applications develop, and for research purposes, this may be extended to include additional hash functions (e.g. KECCAK-512, Pedersen, MiMChash, Poseidon, etc.) and curves (e.g. BLS, MNT, Cocks-Pinch, or even user-defined curves).
Many of these are unlikely to be good fits for upgrades of the Tezos mainnet, yet could serve to make LabNet a site of original research.
Although Tezos is self-amending, writing protocol upgrades remains a difficult task that requires interacting with diverse parts of a large and complex code base. Through documenting our work in adding features to LabNet, we hope to illuminate this process and provide a stepping stone for developers outside of current Tezos core dev teams to contribute to the protocol.
We plan on sourcing ideas for new features from members of the Tezos community (smart contract developers, tooling developers, baking infrastructure providers, etc.) as well as members of other blockchain communities who may find the speed at which we can iterate appealing.
We are currently making a grant to TF for a team of 3/4 developers to work on these things and more. Until then, developers from other team are working on this in their free time.