Future Proposals and lowering the barrier for evaluation

At Taquito, we want to work with new protocol features early on in the Tezos Protocol Lifecycle (TPL).

Early access gives tooling developers the opportunity to:

  • Evaluate and learn new features early on, enabling tooling devs to be partners in delivering new protocol features to the ecosystem.
  • Provide early feedback to protocol development teams.
  • Help catch regressions early in the development cycle.
  • Run our integration-test suite against new protocols to catch regressions or understand breaking changes
  • Where possible, provide Taquito feature releases that support new features, allowing others to build on new protocol primitives early on.

The over-arching goal is to reduce the time-to-value for new protocol updates.

How do we get there? Maybe Sandboxes.

Features / Requirements

Here I layout a wishlist of features

Protocol preview sandboxes should

Start from a genesis block with some well-known accounts.

Sandboxes should exercise migrations

Sandboxes start out running the incumbent mainnet protocol or the next protocol in advanced stages of the governance cycle. Let’s assume edonet is the incumbent protocol.

The protocol should transition from edonet to the new protocol at a predefined level using the user-activated-upgrade or “UAU” feature.

Why?

  • Making sandboxes activate protocols gives visibility to the migration process, which adds testers and demystifies the process.
  • Users of the sandbox can originate contracts and send operations before the protocol transition and make assertions after the transition. - – This allows us to build surety around what happens during transition/migration time.
  • Allows tooling developers to understand and test the proper handling of protocol transitions in their libraries and applications.

Protocol names/hashes and chainids should be discoverable from the container

In our integration tests and packages, we have constants for protocol names. To add new protocols to our builds and tests, we can use configuration files or code-gen to add support for protocols on the fly, allowing for integration tests to run.

Nightly Sandboxes

On the presumption that features end up merged to a single next protocol git branch, producing nightly sandboxes from this branch will allow downstream teams to run automated tests.

Feature-Branch Sandboxes

As Tezos evolves, new features can take far longer than a single adoption cycle. Sapling features have been around for some time, but the barrier for downstream teams to spin up and evaluate such features is presently high.

By encouraging protocol teams to produce sandbox builds, downstream teams can assist with early feedback. Further to this, we gain the opportunity to create demo applications for new features that cross-cut the entire stack, from protocols up to dApps, Wallets and backend systems.

Summary

By lowering the barrier to entry for working with new protocol features, protocol developers will benefit from early feedback and more fruitful collaboration with their users.

Tooling developers will have the opportunity to support new protocol features early.

Application developers, too, will have the opportunity to build the next big thing.

The ecosystem gets a shorter value chain, and we all have a better opportunity to communicate the value and possibilities of new protocol features. It’s a team effort.

How will this happen?

We need Protocol teams to start producing these sandboxes (or another approach that meets the need).

16 Likes