Delphi

Delphi

This is a joint post from Nomadic Labs, Metastate and Gabriel Alfour.

We’re happy to announce that we have compiled a Tezos protocol proposal we’re dubbing “Delphi”, with hash PsDELPH1Kxsxt8f9eWbxQeRxkjfbxoqM52jvs5Y5fBxWWh4ifpo. Delphi contains a number of small bug fixes, but, more importantly, it makes substantial improvements to the performance of the Michelson interpreter and to the gas model, and thus dramatically improves gas costs. In addition, it reduces storage costs by a factor of 4 to reflect improvements in the underlying storage layer.

Many of you have probably been playing with the Dalphanet test network, which includes support for Sapling, baking accounts, and more. The teams contributing to that code have projected that testing and tuning will be done in several months.

During the online town hall meeting on August 19th, it was asked whether an interim protocol proposal could be made that introduces gas improvements sooner, as this would be of substantial help to people developing smart contracts on Tezos.

The motivation for such an interim proposal is straightforward. The size and complexity of smart contracts is limited by gas constraints, and so people attempting to build contracts with rich functionality have needed improvements to those constraints for some time. Thus, such improvements are crucial to enable novel applications on Tezos that target areas like DeFi (“Decentralized Finance”), collectibles, and gaming. Luckily, in August, we finalized some long-standing work on improving the performance of the Michelson type checker and interpreter, and on refining the cost model, thus mitigating the gas problem.

We carefully considered the idea of an interim proposal, and realized that the suggestion was practical. A small protocol proposal is simpler to create and evaluate than a large one, and there is currently an opportunity to inject an interim protocol proposal focused on improving gas constraints without significantly changing the expected proposal date for the code in Dalphanet. Because it is a very limited set of changes, it was feasible to assemble a proposal in time.

The finished proposal, which we have named “Delphi”, incorporates the subset of changes to the Tezos protocol in Dalphanet that considerably improve performance and relax gas constraints.

Here are some examples of the performance gains you can expect to see in Delphi:

  • A block may now include 3.5 times more simple tz* to tz* ops
  • A block may now include 4 times more FA2 transfers
  • A contract may perform 10 times more internal calls

The precise improvement you can expect will vary significantly depending on the specific case, but importantly, the benefits will be most visible in large and complex contracts involving multiple calls to other contracts and substantial computation.

(A complete list of updates in the proposal will be made available in a separate post.)

As for Sapling, baking accounts, and all the rest: the code for those is feature complete and available for members of the community to play with in the Dalphanet test network. We encourage you to try out Dalphanet; the more testing it gets, the better the final proposal will be.

After the end of the amendment process for Delphi, we intend to introduce a new proposal based on the features currently in Dalphanet that are judged to be ready at that time. If Delphi is adopted, this next proposal (which may have a name starting with the letter “E”) could be injected and enter the Tezos amendment process in early December.

35 Likes

Gabriel, thank you for sharing. Do you have a general timeline in mind for proposal injection? Also is the proposal code public on GitLab?

5 Likes

That’s the right idea!

4 Likes

Amazing! Thank you

5 Likes

You could do 4 amendments every year. Don’t be afraid of voter apathy, this great Community will not leave you alone :+1: :rocket:

7 Likes

All the development was publicly made on GitLab: https://gitlab.com/metastatedev/tezos/-/tree/delphi

The amendment proposal is available as a tarball: https://blog.nomadic-labs.com/files/delphi_007_PsDELPH1.tar

The injection will be made very soon.

12 Likes

If I understand correctly, will this proposal not include many of the updates currently on Dalphanet, and mostly focus on performance improvements, etc. for those changes in the future?

2 Likes

What about storage burn?

2 Likes

Can you guys do an AMA?

3 Likes

storage burn is decreased by a factor of 4 (https://blog.nomadic-labs.com/delphi-changelog.html#lowered-storage-costs)

5 Likes

( meta: this is posted in the Research and Development category but really should be a post in the proposal category, can mods move this? )

3 Likes

Proposal threads are automatically produced by the actual on-chain proposal. Once this is injected we will make a link to the changelog and @galfour’s post above.

4 Likes

That’s actually a valid and good call out :ok_hand:

2 Likes

I like this. :dizzy:

3 Likes

I :heart: Tezos

…that is all

2 Likes

Move to proposals por favor :crazy_face:

1 Like

ah yes that makes sense

1 Like

Will previously burned balances be refunded as per the new storage costs? And the burned tez from new account creation/origination?

1 Like

What’s burned in the past should be gone with finality. Refunding burn costs like that sets a dangerous precedent in my opinion.

1 Like

Well it’s not clear that it was burned at all. The client does say “–burn-cap” but in the internals of the protocol it’s not referred to as a burn but rather as a storage fee, and the amount of storage “purchase” is kept track off. I believe only the account creation cost of .257 is referred to as an actual burn.

I think it would make sense in the future to credit the source account when they end up reducing the storage size of contracts.

For the purpose of answering @first’s question: no, in the Delphi proposal, there is no refund for storage costs that were paid at a higher rate, nor is it credited in the form of a higher waterline.

2 Likes