The follow-up efforts are located at %Pipelining - Part 3

Abstract

The pipelining project objectives are two-fold. It first aims at reducing the number of block and operations applications. It also aims at propagating blocks before validating them after performing a validity operation check on the block and its contents. In order to achieve this, the validity check must ensure that the block is correct. Correctness being defined as: the full block application will not fail. Both these goals aim at increasing the TPS and improve scaling globally.

Currently, in Tezos, the validity of an operation is intertwined with its application. We can define the validity of an operation as an operation that can be applied without error. For instance, a valid manager operation requires the operation to be well-signed, the counter to be exact and the balance of the contract to have a sufficient amount to pay the fees.

Outline

This milestone is divided in two parts:

• The first part is expected to be part of the K protocol. This includes:

  • Fixing the semantics for the reveal operation (!5182 (merged)):

    Reveal operations will act as a noop instead of actually revealing a contract when there is a failure (e.g. gas exhaustion, failing in another packed operation, ...). It also includes some refactoring to clarify/optimize the reveal mechanism.

  • Explicitly dissociating "validation" from "application" when validating/applying operations:

    Previously, both mechanisms were intertwined: an operation would run a set of checks before applying these operations. Failing during the checks, aka validation, would make the operation not includable in a block (e.g. bad signature) but failing during application (e.g. gas exhausted or smart-contract failure) wouldn't prevent this operation from being present in a block. The mempool's precheck mechanism already does this in an ad hoc manner. We implement this dissocation by splitting both parts in two separate modules exposing sound and efficient validation to be used by the precheck plugin's mechanism. This also paves the way for the future validation of blocks and new protocol's mempool mode required to implement the full pipelining project.

• The second part, planning for the L protocol will integrate the remaining parts necessary for the pipelining to be shipped:

  • Generalize the validation mechanism for blocks as well

  • Remove the context dependency to the baker and its validation mechanism to speed-up block production

  • Implement a protocol-side mempool based on the operation validation part

  • Adapt the mempool to use this mechanism instead of the ad hoc precheck

Meta-document:

• https://codimd.nomadic-labs.com/iKMynsaGTt6sqxfW54r1SQ

Related:

• https://forum.tezosagora.org/t/baking-without-executing-any-smart-contract/1444

Non-critical issues are referenced in the Pipeling - Backlog dedicated milestone and will be addressed at a later date.