LabNet: Toward a Roadmap

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

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

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.

Michelson

CADADAR optimizations

The same way optimizations were added in Babylon for combinations of DIP / DUP , we need optimizations for combinations of CAR / CDR . This is the low hanging fruit.

More complex optimizations would involve MAP_CAR and JUMBLE in general (a dreamed instruction that can reshuffle the Michelson stack).

Cryptographic Primitives

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.

Open Development

Technical Process

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.

Administrative Situation

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.

9 Likes

Towards the end of 2017, wrapped ether (WETH) gained traction in the Ethereum community as an ERC-20 compliant ether token. The motivation for this is that ether does not conform to the ERC-20 standard.

WETH is used in different applications and financial primitives, notably DeFi ones (e.g. 0x and MakerDAO). At the time, there were discussions in the Ethereum community to natively expose ETH to an ERC-20 interface. I’m not sure where this stands today.

It seems like this could be valuable to implement on Tezos with the token standards currently in development (once ready). Perhaps this should be added to the LabNet roadmap?

This response is simply meant to start a discussion about this. Look forward to hearing from others!

Making a dummy “wrapped tez” contract at the protocol level which actually operates on tez, without having to wrap them, is not a bad idea, but it might need to be restricted to implicit accounts, and require smart contracts to explicitely opt in.

1 Like

Thank you for your participation :slight_smile:
Indeed, when we define a standard with events and views, WXTZ looks like a good candidate.

I am not sure I understand the implications of having this contract at the protocol level, as opposed to having a regular smart-contract. Is the idea that this way, an implicit account does not have to commit its fund to a centralized smart-contract / originate a new smart-contract?

Yes that’s the idea. Everyone who owns tez in an implicit account owns these “wrapped tez” this way, no need to convert first.

1 Like