introduction.tex

\section{Introduction}

This document describes the extensions to the multi-asset formal ledger specification~\cite{shelley_ma_spec} that are
required for the support of phase two scripts, in particular Plutus Core. This underpins future Plutus development: there should be minimal changes to these ledger rules to support future phase-2 languages (eg. upcoming versions of Plutus).
%
The two major extensions that are described here are:

\begin{inparaenum}
\item
the introduction
of \emph{phase-2} scripts, i.e. scripts that are not evaluated internally by the ledger; and
\item
  additions to the Shelley-era UTxO (unspent transaction output) model that are needed to support Plutus
  constructs (the ``extended UTxO'' model).
\end{inparaenum}

This document defines these extensions as changes to the multi-asset structured transition system,
using the same notation and conventions that were used for the multi-asset specification~\cite{shelley_ma_spec}.
As with the multi-asset formal specification, these rules will be implemented in the form of an executable ledger specification that will then be
integrated with the Cardano node.

\subsection{Phase Two Scripts}

The Shelley formal specification introduced the concept of ``multi-signature'' scripts.
\emph{Phase one scripts}, such as these, are captured entirely by the ledger rules.
Execution costs can therefore be easily assessed \emph{before} they are processed by the implementation,
and any fees can be calculated directly within the ledger rule implementation,
based on e.g. the size of the transaction that includes the script.

In contrast, \emph{phase-2} scripts can perform arbitrary
(and, in principle, Turing-complete) computations.
We require transactions that use phase-2 scripts
to have a budget in terms of a number of abstract $\ExUnits$.
This budget gives a quantitative bound on resource usage in terms of a number of specific metrics, including memory usage or abstract execution steps.
The budget is then used as part of the transaction fee calculation.

Every phase-2 scripting language
converts the calculated execution cost into a number of $\ExUnits$ using a cost model,
$\CostMod$, which depends on the language and is provided as a protocol parameter.
This allows execution costs (and so transaction fees) to be varied without requiring a major protocol version change (``hard fork'').
This may be used, for example, if a more efficient interpreter is produced.

The approach we use to bound execution costs to a pre-determined constant is
distinct from the usual ``gas'' model in the following notable ways :

\begin{itemize}
  \item The budget to run a script is expressed in terms of computational resources,
  and included in the transaction data. The \emph{exact} resource budget required can
  be computed before submitting a transaction, since script execution is deterministic.
  See Section \ref{sec:determinism}.
  In the gas model, the budget is expressed indirectly as an upper bound
  on the fee the submitter is willing to pay for execution of the
  contract (eg. their total available funds).

  \item The user specifies the UTxO entries containing funds sufficient to cover a percentage
  (usually $100$ or more) of the total transaction fee.
  These inputs are only collected \emph{in the case of script validation failure},
  and are called \emph{collateral inputs}. In the case of
  script validation success, the fee specified in the fee field of the transaction is collected,
  but the collateral is not.

  This scheme is different from the gas model in that the exact payment collected in
  both the case of script validation success and validation failure is known ahead of time,
  though the collected fees are different in the two cases.
\end{itemize}

Another important point to make about both phase one and two scripts on Cardano is that
running scripts in all languages will be supported indefinitely whenever possible.
Making it impossible to run a script in a particular scripting language
makes UTxO entries locked by that script unspendable.

We use the terms Plutus, $\PlutusVI$, and ``phase two scripting language'' in this specification
somewhat interchangeably. The reason for this is that while we intend for the infrastructure
set up in this document to be somewhat language-agnostic (in particular,
able to support multiple versions of Plutus), it only gives all the details for
the first and (currently only) phase-2 script language, $\PlutusVI$,
the introduction of which represents the
start of the Alonzo era.


\subsection{Extended UTxO}

The specification of the extended UTxO model follows the description that was given in~\cite{chakravarty2020extended}.
All transaction outputs that are locked by phase-2 scripts must include the hash of an additional ``datum''. The actual datum needs to be supplied by the transaction spending that output, and can be used to encode state, for example.
While this datum could instead have been stored directly in the UTxO, our choice of storing it in the transaction body improves space efficiency in the implementation by reducing the UTxO storage requirements. The datum is passed to a script that validates that the output is spent correctly.

All transactions also need to supply a \emph{redeemer} for all items that are validated by a script. This is an additional piece of data that is passed to the script, and that could be considered as a form of user-input to the script. Note that the same script could be used for multiple different purposes in the same transaction, so in general it might be necessary to include more than one redeemer per script.
There will, however, always be at least one redeemer per script.