Revision a86a09b014e025f9631163688bc0591a63399c46 authored by Sylvain Ribstein on 07 September 2022, 07:07:44 UTC, committed by Marge Bot on 12 September 2022, 08:36:23 UTC
In order to replace Sc_rollup_PVM_sem.input by input in the signature of
function in `alpha_context.mli` I had to reorganized the order of
the module.

Now the `Message` and the type `input` are defined before `Inbox` and
the function `produce_proof` and `verify_proof` can use the correct type

I renamed `Message` to `Inbox_message` to not confuse it with `Outbox.Message`
1 parent 9159b8d
Raw File
CHANGES.rst
Development Changelog
'''''''''''''''''''''

**NB:** The changelog for releases can be found at: https://tezos.gitlab.io/CHANGES.html


This file lists the changes added to each version of tezos-node,
tezos-client, and the other Octez executables. The changes to the economic
protocol are documented in the ``docs/protocols/`` directory; in
particular in ``docs/protocols/alpha.rst``.

When you make a commit on master, you can add an item in one of the
following subsections (node, client, …) to document your commit or the
set of related commits. This will ensure that this change is not
forgotten in the final changelog, which can be found in ``docs/CHANGES.rst``.
By having your commits update this file you also make it easy to find the
commits which are related to your changes using ``git log -p -- CHANGES.rst``.
Relevant items are moved to ``docs/CHANGES.rst`` after each release.

Only describe changes which affect users (bug fixes and new features),
or which will affect users in the future (deprecated features),
not refactorings or tests. Changes to the documentation do not need to
be documented here either.

Node
----

- Add a field ``dal`` in the node's configuration file. This field is
  for a feature which is being developed and should not be
  modified. It should be used only for testing.

- Fixed a bug in the p2p layer that prevented a fast regulation of the
  number of connections (when having too few or too many connections)

- Improved the octez store merging mechanism performed on each new
  cycle. The node's memory consumption should not differ from a normal
  usage where, in the past, it could take up to several gigabytes of
  memory to perform a store merge. It also takes less time to perform
  a merge and shouldn't impact normal node operations as much as it
  previously did; especially on light architectures.

- Added support for ``level..level`` range parameters in the replay command.

- Breaking change: Node events using a legacy logging system and are migrated to
  the actual one. Impacted events are in the following sections:
  ``validator.chain``, ``validator.peer``, ``prevalidator`` and
  ``validator.block``. Section ``node.chain_validator`` is merged into
  ``validator.chain`` for consistency reasons. Those events see their JSON
  reprensentation shorter, with no duplicated information. e.g.
  ``validator.peer`` events were named ``validator.peer.v0`` at top-level and
  had an ``event`` field with a ``name`` field containing the actual event name,
  for example ``validating_new_branch``. Now, the event is called
  ``validating_new_branch.v0`` at top-level and contains a ``section`` field
  with ``validator`` and ``peer``.


*  Added support for ``--strict`` mode in the replay command: it causes the
   command to be less permissive.

Client
------

- Simulation returns correct errors on batches of operations where some are
  backtracked, failed and/or skipped.

- External operations pool specified by the ``--operations-pool`` option are
  guaranteed to be included in the order they are received from the operations
  source.

- Added commands to get the used and paid storage spaces of contracts:
  ``tezos-client get used storage space for <contract>`` and
  ``tezos-client get paid storage space for <contract>``.

- Added RPCs to get the used and paid storage spaces of contracts:
  ``GET /chains/<chain_id>/blocks/<block_id>/context/contracts/<contract_id>/storage/used_space``
  and ``GET /chains/<chain_id>/blocks/<block_id>/context/contracts/<contract_id>/storage/paid_space``.

- Added commands related to the "consensus key" feature:

	Update the consensus key of a baker:

```shell
tezos-client set consensus key for <mgr> to <key>
```

  It is also possible to register as a delegate and immediately set the consensus key:

```shell
tezos-client register key <mgr> as delegate with consensus key <key>
```

  (The current registration command still works.)


  Drain a baker's account:

```shell
tezos-client drain delegate <mgr> to <key>
```

  or, if the destination account is different from the consensus key

```shell
tezos-client drain delegate <mgr> to <dest_key> with <consensus_key>
```
	
Baker
-----

- External operations pool specified by the ``--operations-pool`` option are
  guaranteed to be included in the order they are received from the operations
  source.

- The logs now display both the delegate and its consensus key.

Accuser
-------

Signer
------

Proxy Server
------------

Protocol Compiler And Environment
---------------------------------

Codec
-----

Docker Images
-------------

Rollups
-------

Miscellaneous
-------------
back to top