Versions are not used for anything and the comment is outdated.

This is much more realistic, as allowing contracts to efficiently access
transaction histories for all addresses is extremely expensive. To do
this, we
* Add an account_balance operation in Chain instead
* Change incoming_txs and outgoing_txs to compute transactions from
  traces
* Require implementations to give a proof-relevant trace, and rework
  proofs to use these, as necessary

This holds for reachable states without this, as proven in
undeployed_contract_no_in_txs.

We don't need these for our current embedding. We may need them later
for inter-contract communication.

A state being reachable means there is an execution starting from the
empty state, that ends up in the state.

- Remove 'prove' tactic
- Remove some duplicated tactics and make some proofs more efficient

Match on smaller expressions, making everything much faster. Also
optimize solve_single.

This proves a concrete property about any Congress contract deployed to
a blockchain. More specifically, we show that the count of transactions
sent out by any Congress contract will always be less than or equal to
the total number of actions it has receive in "create proposal"
messages.
Thus, this property is stated only over the transactions going in and
out to the Congress contract.
To prove this, we reason over incoming and outgoing transactions, the
internal state of the congress and also the actions in the blockchain
queue.

This split between cases only makes things harder.

These abstract the list structure of the trace away from the events, so
that a trace is now a CursorList of ChainEvent values. The ChainState is
a new type for the environment and queue.

This moves ChainStep and ChainTrace to type. The reason being that our
proofs will depend on prefixes of traces and it will be very useful (if
not required) to be able to match on the trace and the steps.
ChainBuilderType is changed appropriately: now, an implementation just
needs to prove that ChainTrace empty_env [] cur_env [] is inhabited.
Thus, ChainTrace can basically be seen as one particular way to order
the execution so that we reach a state. When it is inhabited, it thus
means that there exists a proper way to order actions so that we reach
the state we are in.

Since we will need to reason over specific inhabitants of traces, this
is required to prove many interesting properties by induction, as
explained to me by Danil Annenkov.

Get rid of the proofs showing that ChainStep and ChainTrace respect
EnvironmentEquiv. ChainTrace no longer respects this in the base case
(this was necessary to define trace_app).

Instead of traces always starting from the empty environment and an
empty queue, they can now start from any environment and queue. This
should hopefully make it simpler for us to define what it means to be a
prefix of a trace.