diff --git a/.gitignore b/.gitignore
index 192a3d4fd..dba739fbf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -25,6 +25,7 @@ cache/
config/geth/data/
backup
docker/volumes
+**/tmp
#hardhat coverage
coverage
diff --git a/doc/deprecated/api.md b/doc/deprecated/api.md
deleted file mode 100644
index 4159ad284..000000000
--- a/doc/deprecated/api.md
+++ /dev/null
@@ -1,186 +0,0 @@
-# nightfall-client
-
-## GET /healthcheck
-
-Used to test if the server is up.
-
-### Parameters:
-
-None
-
-### Response
-
-status code 200.
-
-## POST /incoming-viewing-key
-
-subscribe to block proposed event with the provided incoming viewing key for optimist2 such that
-this key will be used to decrypt secrets send to the blockchain as part of a transfer transaction
-
-### Parameters
-
-```js
-{
- zkpPrivateKeys: // the array of private keys which will be used to decrypt messages
- nullifierKeys: // the array of secrets required to create nullifier for a commitment being spent. Required to store nullifier for a commitment being created in DB
-}
-```
-
-### Response
-
-`status:` to show if the subscription with the key is a `success`
-
-## GET /contract-address/{contractName}
-
-Used to get the address of a particular blockchain contract. This is mostly for testing use.
-
-### Parameters
-
-`contractName:` The name of the solidity contract (case sensitive) without the `.sol` extension,
-e.g. `Shield`.
-
-### Response
-
-`address:` The requested contract address, as a hex string
-
-## POST /deposit
-
-Creates a transaction to make Layer 2 token from a Layer 1 ERC20, ERC721 or ERC1155 token.
-
-### Parameters
-
-```js
-{
- ercAddress: // the address of the Layer 1 ERCx token contract
- tokenType: // type of token - ERC20/ERC721/ERC1155
- tokenId: // the ID of the token ('0x00' for ERC20 tokens)
- value: // the value of the token ('0x00' for ERC721 tokens)
- fee: // the amount that the transactor will pay to a proposer to incorporate the transaction in a Layer 2 block.
-}
-```
-
-### Response
-
-`txDataToSign:` abi-encoded transaction data. This should be signed and sent to the blockchain by
-the calling application, along with the fee for the Proposer (as `msg.value`). Note that the
-Shield.sol contract will attempt to take the value being transacted into escrow (whether an
-ERC20/1155 value or an ERC721 non fungible token). Thus, before the deposit endpoint is called, the
-Shield contract must be approved by the user to make the withdrawal (using the relevant ERCx
-`approve` function).
-
-## POST /transfer
-
-Creates a transaction to transfer ownership of a ZKP-shielded asset between two owners (identified
-by their zkp public key).
-
-### Parameters
-
-```js
-{
- offchain: // sends the transfer transaction directly to a proposer instead of the smart contract if set to true
- ercAddress: // the address of the ERCx contract holding the equivalent Layer 1 tokens
- tokenType: // type of token - ERC20/ERC721/ERC1155
- value: // value of token to be sent
- tokenID: // the identity of the token to be transferred (`0x00 for an ERC20`)
- compressedZkpPublicKey: // recipients' respective compressed zkp public key
- fee: // amount to pay proposer
-}
-```
-
-### Response
-
-`txDataToSign:` abi-encoded transaction data. This should be signed and sent to the blockchain by
-the calling application, along with the fee for the Proposer (as `msg.value`).
-
-## POST /withdraw
-
-Creates a transaction to convert a ZKP-shielded token back to a conventional Layer 1 token. A
-current limitation is that a ZKP commitment of the exact value must exist. You may need to make a
-transfer to yourself of the exact value you wish to withdraw, if there isn't already a commitment of
-the correct value.
-
-### Parameters
-
-```js
-{
- offchain: // sends the transfer transaction directly to a proposer instead of the smart contract if set to true
- ercAddress: // the address of the ERCx contract holding the equivalent Layer 1 tokens
- tokenType: // type of token - ERC20/ERC721/ERC1155
- tokenID: // the identity of the token to be transferred (`0x00 for an ERC20`)
- value: // value of token to be withdrawn
- recipientAddress: // Ethereum address of the Layer 1 token recipient
- fee: // amount to pay proposer
-}
-```
-
-### Response
-
-`txDataToSign:` abi-encoded transaction data. This should be signed and sent to the blockchain by
-the calling application, along with the fee for the Proposer (as `msg.value`).
-
-# nightfall-optimist
-
-## POST /proposer/register
-
-Creates a transaction to register a Proposer, so that they can start producing blocks.
-
-## Parameters
-
-```js
-{
- address: // the address of the proposer to register, as a hex string
-}
-```
-
-## Response
-
-`txDataToSign:` abi-encoded transaction data. This should be signed and sent to the blockchain by
-the calling application (along with the proposer bond value).
-
-## POST /challenger/add
-
-Adds the address of a challenger that this `nightfall-optimist` instance should create challenges
-for. This information is needed so that `nightfall-optimist` can check that a challenge commit has
-been posted to the blockchain successfully, and therefore it can send the reveal. Multiple
-challenger addresses can be added.
-
-## Parameters
-
-```js
-{
- challenger: // the address of the challenger
-}
-```
-
-## Response
-
-`txDataToSign:` abi-encoded transaction data. This should be signed and sent to the blockchain by
-the calling application.
-
-# Notes
-
-- Unless otherwise stated, all values should be formatted as 32 byte hex strings, padding with
- leading zeros as needed and preceeded by `0x`. The `general-number` package provides a convenient
- method for converting various types to 32 byte strings.
-- Unsigned challenge transactions and Layer 2 block creation transactions are emitted by a websocket
- from `nightfall-optimist` back to the Challenger/Proposer. These must be signed and sent to the
- blockchain to either raise a challenger or to create a new block. This cannot be done by
- `nightfall-optimist` because it does not have access to Ethereum private keys. See the test suite
- `adversary.test.mjs` for an example of this working. The basic code is:
-
-```js
-connection = new WebSocket(optimistWsUrl);
-connection.onopen = () => {
- connection.send('challenge');
- connection.send('blocks');
-};
-connection.onmessage = async message => {
- // let txReceipt;
- txQueue.push(async () => {
- const msg = JSON.parse(message.data);
- const { type, txDataToSign } = msg;
- if (type === 'block') {
- //sign a block transaction and send to blockchain
- else if type === 'challenge'
- //sign a challenge transaction and send to blockchain
-```
diff --git a/doc/deprecated/architecture.md b/doc/deprecated/architecture.md
deleted file mode 100644
index 59240b955..000000000
--- a/doc/deprecated/architecture.md
+++ /dev/null
@@ -1,78 +0,0 @@
-# Nightfall_3
-
-Nightfall_3 makes the [nightfall](https://github.com/EYBlockchain/nightfall) solution more developer
-friendly and much more Gas efficient. A developer can use Nightfall_3 to make ZKP transactions
-without ever having to worry about the underlying cryptography: no hashes to generate, no
-commitments to manage, no salts... As far as possible it's just like transferring a conventional
-ERCx token.
-
-The use of an optimistic rollup reduces the Gas use by a factor of approximately 80. This has become
-increasingly necessary in the current climate of high ETH values and high Gas costs.
-
-You may be wondering what happened to Nightfall_2. Nightfall_2 has no rollup capability and so we
-decided to move directly to Nightfall_3.
-
-To achieve that we've made a number of changes.
-
-- The `nightlite` library has been withdrawn. It had two main drawbacks: a developer using the
- library still had to do a _large_ amount of work to generate ZKP transactions and these required
- considerable knowledge of how ZKPs work; and the advent of the `Timber` Merkle tree manager
- required the library to access a `Timber` microservice before it could be used. This created a
- really odd dependency for the library.
-- The GUI has been removed. It's pointless except as a technology demonstrator but requires
- significant code maintenance.
-- The Circom components have been factored out to a separate microservice that pulls
- proof-generation work from a queue. The proof generation is the main rate limiting step (by far).
- This architecture enables easy autoscaling of Circom workers.
-- A `nightfall-client` microservice has been created when enables ZKP transactions to be enacted
- with simple API calls. This is the endpoint for creating transactions with Nightfall ZKPs.
-
-The container infrastructure is summarised in this image. Volume mounts are shown too:
-
-
-## Infrastructure
-
-Nightfall_3 comprises five containerised microservices. These are stored in a monorepo for
-convenience and can be brought up using a docker-compose yaml file for development purposes.
-
-## The Nightfall_3 Microservices
-
-The set of services that together form Nighfall_2 are as follows:
-
-- _`nightfall-client`_: The endpoint for making ZKP transactions. Calls to this API allow Deposit
- (to Layer 2), Transfer (within Layer 2) and Withdraw (removal back to Layer 1). No computation of
- crypto primitives, tracking of commitments or other ZKP weirdness is required to use the service.
- Commitment data is optionally stored in a volume mounted to the `nightfall-client` so the caller
- does not need to manage this data unless they really want to. In a multi-user situation, each
- organisation/unit would deploy their own nightfall-client.
-- _`circom-microservice`_: Encapsulates the Circom binary and allows interaction through simple API
- calls (`/generate-zkp-keys`, `/generate-proof`, `/verify`). The user never needs to interact
- directly with this container though. It interfaces via AMQP and operates as a worker for
- `nightfall-client`'s work queue, sharing state between all instances of the microservice. In a
- multi-user situation, each organisation/unit would deploy multiple `circom-microservices` attached
- to a `nightfall-client` and would autoscale their number. It also exposes an http interface.
-- _`timber`_: The Timber microservice is similar to the existing
- [microservice](https://github.com/EYBlockchain/timber) but has additional functionality to enable
- rollback of the commitment database in the case of a successful challenge and compatibility with a
- Layer 2 Block . Timber manages an off-chain commitment Merkle tree. This approach is _much_
- cheaper than holding all of the tree on-chain. Again, the user never interacts directly with this
- container. There would be one of these for each organisation in a multiuser situation, unless more
- were required for resilience.
-- _`nightfall-deployer`_: A container that initialises the Nightfall solution and then exits. It
- compiles and deploys the Solidity contracts to the blockchain, and compiles the ZKP dsls and
- performs a trusted setup. There would only ever be one ephemeral instance of `nightfall-deployer`
- for each main net deployment.
-- _`nightfall-optimist`_: Is the main endpoint for Proposers and Challengers. It listens to
- blockchain events to determine when transactions have been posted (or sent directly) and
- automatically assembles them into Layer 2 Blocks when one of the Proposer addresses it is managing
- is the active Proposer. It also listens to Block proposal events and check each Layer 2 Block that
- is posted to the blockchain. If any are flawed, it automatically launches a challenge. It is
- possible to disable either of the Proposer or Challenger functionalities if required to suit
- individual implementations (for example one may wish to be a Challenger but not a Proposer or to
- use a separate pod for issuing Challenges).
-
-Note that `nightfall_3` does not hold any Ethereum private keys, for security reasons. Therefore,
-calls to its endpoints return an unsigned Ethereum Layer 1 transaction when it needs to change the
-blockchain state. It expects these to be signed by the calling application and submitted to the
-blockchain on its behalf. `nightfall-optimist`, `nightfall-client` and `timber` only listen to the
-blockchain; they never directly change its state.
diff --git a/doc/deprecated/chain-reorgs.md b/doc/deprecated/chain-reorgs.md
deleted file mode 100644
index da5ecf6a5..000000000
--- a/doc/deprecated/chain-reorgs.md
+++ /dev/null
@@ -1,188 +0,0 @@
-# How Nightfall_3 Copes with Chain Reorganisations
-
-A chain reorganisation happens when the local node realises that it is not in consensus with the canonical chain
-and it abandons the chain branch it was operating on for the heavier canonical chain.
-
-When this happens, there are a number of Layer 1 changes. Nightfall_3 must update its Layer 2 record so that it
-is consistent with the new layer two state.
-
-For clarity we will call the branch that is to be abandoned in favour of the new consensus the `uncle` branch
-and the new, heavier branch which is part of the canonical chain, the `canonical` branch.
-
-## The effect of a reorg on Layer 1
-
-The transactions in the uncle branch are returned to the mempool and, from the point of view of the local node
-are replaced by those in the canonical branch. Eventually they will be re-mined and this may not be in the
-same order that they were originally created (although nonces are respected). Thus dependencies between
-the transactions may cause some to revert even though they worked on the uncle branch.
-
-## The effect of a reorg on Layer 2
-
-The L2 state is held both in Optimist and Timber (soon these will be combined). The state is updated in response
-to L1 emitting blockchain events, which the L2 code listens for, for example a BlockProposed event. These are
-all defined in Structures.sol.
-
-When a L1 chain reorg happens, the following will be seen by the listeners:
-
-1) The events in the uncle branch will be replayed except that they will trigger a 'changed' rather than a 'data'
-event type, and the event object will have a `.removed` property, which is set to `true` (NF_3 uses the property
-value rather than the event type).
-
-2) The events in the canonical branch will be played to them in the order they appear on the canonical branch.
-
-3) The L1 transactions that were in the uncle branch will re-play as they are re-mined from the Mempool. Most
-of these transactions will emit L2 events which will not necessarily be in the original order, although nonce
-order for each `fromAddress` will be respected.
-
-## Handling a chain reorg (no rollback)
-
-When there is a reorg which does not revert a L2 rollback, the situation is simplified. We will treat this case
-first.
-
-### Layer 1 (smart contract state)
-
-From the point of view of the local node, we see L2 Block hashes sequentially added to the blockchain record.
-Suppose that the local node has the following L2 blockHash record:
-```
-H_0, H_1 ... H_r, H_s ... H_n
-```
-Let's further suppose there is a heavier chain segment out there with alternative facts:
-```
-H_0, H_1 ... H_r, H'_s ... H'_m
-```
-Note that the chains differ (fork) just after H_r. After that point, they no longer agree on the blockchain record.
-
-Eventually, there will be a chain reorg and the heavier branch will become the canonical chain. At that point, the
-local node will agree that the correct chain is:
-```
-H_0, H_1 ... H_r, H'_s ... H'_m
-```
-and there will be a set of L1 transactions in the Mempool, corresponding to those on the now defunct uncle branch:
-```
-H_s ... H_n
-```
-The next thing that will happen is that the miners will pick up the transactions in the mempool; we say that they
-will be 're-mined'. Note however that each Block struct (see Structures.sol) contains the hash of the previous block
-and the ordinal number of the block. The `proposeBlock` function checks these for correctness before adding a block hash
-to the `blockHashes` array. In this case, certainly the previous block hash check and probably the block number hash
-will fail and the transaction will revert. Effectively, these uncle transactions will be cleared from the Mempool
-and no state changes will result. This is exactly what we want to achieve.
-
-Any L2 transactions that were submitted to the uncle chain will also be re-mined. Their L1 transactions will all
-succeed and they will be re-notarised to the blockchain. They may or may not be valid depending on whether they
-have dependencies on earlier transactions that no longer exist, or now occur later because they were re-mined out
-of order.
-
-### Layer 2 (Optimist)
-
-Firstly, Optimist sees the event removals. When it receives a BlockProposed event removal, it finds the block in its
-database and sets the block's L1 block number to null. This indicates to NF_3 that the Block hash has been removed from the L1 chain.
-You might imagine we could just delete these blocks, but we can't. We'll explain why in a bit.
-
-Next, Optimist sees the new events (if any) come in from the canonical chain. It will check these and they should pass its
-checks because they will fit on the existing blocks at the L2 blockNumber they have.
-
-Finally, BlockProposed events will come from the re-mining of the transactions that were on the uncle branch. There
-will only be these if there were no BlockProposed events on the canonical branch - otherwise the transactions
-will revert at layer 1 (see previous section) and never emit an event.
-
-If such events do exist (and this is quite likely if there aren't many NF_3 transactions on the chain), then they will
-pass the NF_3 checks and the L2 blocks will be added to the database. However, their L2 transactions will also be re-mined.
-These are potentially still perfectly valid and will pass NF_3's checks. This is, however, a problem. Being valid, these L2
-transactions will trigger the block assembler. This creates another block containing the same transactions (one block coming
-from the re-mine, one from the block assembler). That will be seen as a L2 transaction replay attack by Optimist. To prevent
-that we:
-1) trap incoming transactions (function `checkAlreadyInBlock` has this job)
-2) see if they already exist in a block. If yes, check that the blocks L1 block number is null, otherwise throw a duplicate
-transaction challenge. This check is why we cannot delete the removed block (above) and instead set its L1 blocknumber to null.
-If we did delete the block, and these transactions were re-mined before the block containing them was re-mined, we'd think
-they were new transactions.
-3) If they are already in a block and we've determined they aren't really duplicates, then we set their mempool
-property to `false`. That will prevent the block assembler from picking them up and creating yet another block with them in.
-Eventually their original block will be re-mined, if it hasn't been already. The timelines will be restored and
-all will be well once more.
-
-### Layer 2 (Timber)
-
-Like Optimist, Timber firstly sees the event removals. Remember that Timber does not really understand the concept of L2 blocks
-and transactions. Therefore it simply filters L2 BlockProposed event calldata to extract commitment data, on which it operates.
-When Timber receives a removal for a `BlockProposed` event, it computes the `leafCount` (number of leaves in the Merkle Tree)
-which existed before the commitments in the removed block were added. It then calls its `rollback` function to reset the
-Merkle tree back to the point just before the removed L2 block's commitments were added. This is slightly inefficient in
-that it may call rollback more times than absolutely necessary. For now though, it has the benefit of simplicity.
-
-The next thing that happens is that events from the new canonical branch are emitted. Timber will add any commitments
-associated with the `BlockProposed` events into its tree.
-
-Finally, any re-mined `BlockProposed` events will be added. These will only appear if they pass the L1 checks and are
-compatible with the new blocks added by the canonical chain.
-
-### Layer 2 (Client)
-
-Client tracks the commitments owned by its user(s). It will record whether a commitment is spent or not. Specifically,
-it remembers:
-
-1) If a Deposit transaction has been successfully computed (`.isDeposited`)
-2) If the transaction has made it on chain as part of a Block (`.isOnChain`)
-3) If it has been nullified locally (`.isNullified`)
-4) If the nullification has made it on chain as part of a Block (`.isNullifiedOnChain`)
-5) If the commitment has been selected for spending but not yet nullified (`isPendingNullification`)
-
-If a chain reorganisation happens then it may well change the status of some of these transactions. Changes to
-the L2 Block record are relevant, this being the only event that Client subscribes to (other than the rollback which
-we will consider later) Here is specifically how Client responds:
-
-First, the event removals are created. If a `BlockProposed` event is removed, then we need to mark the transactions
-that were in that block (assuming they are 'our' transactions and therefore in the Client database) accordingly.
-
-Removal of a block means that commitments and nullifiers which were on-chain (in the sense of being in a proposed block)
-no longer are. Thus we update `.isOnChain` and `.isNullifiedOnChain` to `-1` (these properties hold a blockNumber
-when set, so they're no simply boolean).
-
-This is the simplest approach that we can take, but it's not the full story because the locally determine state
-(`.isNullified`, `isPendingNullification`) is not reset. That means that these commitments will not be reused
-by Client in new transactions. That's ok because eventually the transactions will be picked up again by a
-Proposer and placed in a new block. If we were to clear their internal state then they may be re-spent before
-this happens. That would create an invalid transaction.
-
-A potential complication arises if dependent L2 transactions are taken off-chain. This is because a Proposer
-may attempt to re-incorporate them into a block in the wrong order (e.g. incorporating a transfer before the
-deposit which enabled it). If that happens, the dependent transaction will fail the Proposer's check and will
-be dropped. That's ok though because this mimics the behaviour that an L1 dependent transaction would experience in a
-chain-reorganisation.
-
-### Effect of Rollback events
-
-Thus far, we have only considered the issue of `blockProposed` events being removed an replayed. However, we should also consider the
-removal of a `rollback` event.
-
-When a `rollback` happens, as the result of an existing challenge, all the L2 block hashes within the scope of a rollback will be removed from
-the blockchain record. Thus we might have the following:
-```
-H_0, H_1 ... H_p, H_q ... H_r ... H_n before rollback
-
-H_0, H_1 ... H_p after rollback
-```
-So the rollback removes all hashes later than `H_p` We then add new block hashes as the chain progresses:
-```
-chain 1: H_0, H_1 ... H_p, H'_q ... H'_r ... H'_t
-```
-Where the new block hashes are completely different from the old, removed ones, and the chain will generally be of a different length.
-Now imagine a chain fork where the rollback never happened. The chain looks like this:
-```
-chain 2: H_0, H_1 ... H_p, H_q ... H_r ... H_m
-```
-Suppose this is the heavier chain. Thus, this will become the canonical chain when the reorganisation happens. What happens to the
-Layer 2 state in Optimist?
-
-let's consider the actual transactions:
-```
-chain 1: propose(H_p), ...propose(H_r), ...propose(H_n), challenge(H_q), propose(H'_q), ...propose(H'_r), ...propose(H'_t)
-chain 2: propose(H_p), ...propose(H_r), ...propose(H_n), ...propose(H_m)
-```
-
-First of all, removal events will be received. This will remove the respective `proposeBlock` calls (`H'_q...H'_t`) from the L2 database (or,
-more accurately it will set their L1 block number to null). Then the new 'chain 2' events will be played. These will be the ones after `propose(H_n)`.
-Then, the events that were removed will be re-mined. The re-mined `proposeBlocks` will revert because none of them can be attached after H_m. However, the `challenge(H_q)` will succeed and will force a rollback to H_p.
-That is correct behaviour because all of the blocks after H_p on chain 2 are in fact invalid (because H_q is invalid).
-
diff --git a/doc/deprecated/diagrams/Deposit.png b/doc/deprecated/diagrams/Deposit.png
deleted file mode 100644
index 11e553cc7..000000000
Binary files a/doc/deprecated/diagrams/Deposit.png and /dev/null differ
diff --git a/doc/deprecated/diagrams/README.md b/doc/deprecated/diagrams/README.md
deleted file mode 100644
index 0658575e4..000000000
--- a/doc/deprecated/diagrams/README.md
+++ /dev/null
@@ -1,6 +0,0 @@
-# Diagrams
-The diagrams contained in this folder are generated using the Websequencediagrams [website](https://www.websequencediagrams.com/). Each diagram has a file `.webseqdiagram` containing the source-code of the diagram, as well an image generated from the source-code. For changing the diagram, one should go to the Websequencediagram website, paste the source-code on the left panel and change it accordingly. After changing, please, remember of save the source-code into the respective diagram file and push the updates.
-
-## The Deposit diagram
-
-
diff --git a/doc/deprecated/diagrams/deposit.webseqdiagram b/doc/deprecated/diagrams/deposit.webseqdiagram
deleted file mode 100644
index f362a5740..000000000
--- a/doc/deprecated/diagrams/deposit.webseqdiagram
+++ /dev/null
@@ -1,14 +0,0 @@
-title Deposit
-
-Transactor->Client: transactionData = deposit(args)
-Client->Client: prepareCommitment()
-note right of Client: Generates a random number for creating the commitment. It returns when the Commitment hash is greather than BN128_GROUP_ORDER
-Client->CircomWorker: proof = generateProof(args)
-Client->Client: shieldContractInstance = getContractInstance(SHIELD_CONTRACT_NAME)
-Client->Client: optimisticDepositTransaction = newTransaction(args)
-Client->Transaction: transformedTransaction = buildSolidityStruct(optimisticDepositTransaction)
-Client->ShieldContract: rawTransaction = submitTransaction(transformedTransaction)
-Client->Client: storeCommitment(commitment, nullifierKey)
-note right of Client: This operation saves the commitment to the DB into the COMMITMENTS collection
-Transactor->Web3: signedTransaction = signTransaction(transactionData, privateKey)
-Transactor->Web3: transactionReceived = sendSignedTransaction(signedTransaction)
diff --git a/doc/deprecated/how_it_works.md b/doc/deprecated/how_it_works.md
deleted file mode 100644
index c54905e90..000000000
--- a/doc/deprecated/how_it_works.md
+++ /dev/null
@@ -1,171 +0,0 @@
-# How Nightfall zk optimistic rollup works
-
-## Actors
-
-There are three actors involved in the process:
-
-- Transactors
-- Proposers
-- Challengers
-
-A `Transactor` is a normal customer of the service. They wish to make `Transactions` i.e. Deposit,
-Transfer, Withdraw. Anyone can be a Transactor. They pay a fee for the service.
-
-A `Proposer` proposes new updates to the state of the Shield contract. By _state_, we mean
-specifically the storage variables that are associated with a zkp transaction: nullifiers, and
-commitment roots. Update proposals contain many `Transactions`, rolled up into a layer 2 `Block` and
-only a hash of the final state, that would exist after all the Transactions in the Block were
-processed, is stored. The system could be configured with a maximum number of proposers. Anyone can
-become a Proposer if this maximum number is not reached but they must post a minimum stake that is
-also configured in the system. All these parameters could be updated according to a multisig
-administrator contract. The stake is intended to incentivise good behaviour and also is the base to
-calculate the proposer set for the selection of next proposer. Using a similar approach to Polygon
-proposer selection protocol, with proposer set based on staking, and Tendermint’s proposer selection
-based in a weighted round robin algorithm, Nightfall will select next proposer. Every time the
-current proposer propose a block part of this stake is blocked, which is paid to a successful
-challenger. Proposers make money by providing correct blocks and collecting fees from transactors.
-They are somewhat analogous to Miners in a conventional blockchain although the way they operate is
-completely different.
-
-A `Challenger` challenges the correctness of a proposed block. Anyone can be a Challenger. They make
-money from correct challenges.
-
-## Contracts
-
-The following contracts are relevant (others play no specific role in the optimistic rollup process
-and have the same functionality as conventional nightfall).
-
-- `Shield.sol` - this enables a user to submit a transaction for processing by a Proposer. If it's a
- deposit Transaction, it will take payment. It also allows anyone to request that the state of the
- Shield contract (commitment root and nullifier lists) is updated. When the state is updated, any
- withdrawals in the update will be processed (we don't yet allow immediate withdrawal; one needs to
- wait until a block is finalised). Note that there is no fundamental need to post a transfer or
- withdraw transaction to the blockchain: it's simply acting as a message board for proposers to
- pick up the transaction and incorporate it into a layer 2 Block. These days, that's a lot of Gas
- for a bit of convenience. Therefore this functionality can be disabled and transfer transactions
- sent directly to a proposer endpoint (see below).
-- `Proposers.sol` - functionality for registering, deregistering, paying and changing the current
- proposer and, most importantly, proposing a new Layer 2 Block to the blockchain.
-- `Challenges.sol` - functionality to enable a Block to be challenged as incorrect in some way.
-- `MerkleTree_Computations.sol` - A stateless (pure function) version of the original
- `MerkleTree.sol`, used by `Challenges.sol` to help compute challenged blocks on-chain.
-- `Utils.sol` - collects together functionality which is either used in multiple contracts or which,
- if left inline, would affect readability of code.
-- `Config.sol` - holds constants rather like a Nodejs config file. Also has some parameters that
- could be configure with a multisig administrator contract.
-- `Structures.sol` - defines global structs, enums, events, mappings and state variables. It makes
- these easier to find.
-
-## Operation
-
-We assume that several Proposers have registered with the system, posting a bond (I set this at 10
-ETH) to do so.
-
-### Transaction posting
-
-#### **On-chain**
-
-The process starts with a Transactor creating a transaction by calling `submitTransaction` on
-`Shield.sol`. The Transactor pays a fee to the Shield contract for the Transaction, which can be
-anything the Transactor decides. Ultimately this will be paid to the Proposer that incorporates the
-Transaction in a Block. The higher the fee, the more likely a Proposer is to pick up the
-Transaction.
-
-The Transaction call causes a Transaction event to be posted, containing the details of the
-Transaction. If the Transaction is a Deposit, the Shield contract takes payment of the layer 1 ERC
-token in question.
-
-#### **Off-chain**
-
-Transfer and Withdraw transactions have the option of being submitted directly to listening
-proposers rather than being submitted on-chain via the above process. These off-chain transactions
-will save transactors the on-chain submission cost (~45k gas), but requires a greater degree of
-trust from transactors with the proposers they choose to connect to. It is easier for bad acting
-proposers to censor transactions received off-chain than those received on-chain.
-
-### Transaction receival
-
-When proposers receive any transactions, they perform a range of checks to validate that the
-transaction is well-formed and that the proof verifies against the public inputs hash.
-
-If this is true in both cases, the transaction is added to proposer's mempool to be considered in a
-`Block`.
-
-### Block assembly and submission
-
-Proposers wait until the Shield contract assigns them as the current proposer (presently this is
-done by simple rotation, we feel this should be random but we can't actually see a problem with
-rotation).
-
-The current proposer looks at the available Transactions and chooses one. Normally this would be the
-one with the highest fee. They compute the new commitment Merkle-tree that _would_ come into being
-_were_ this transaction to be added to the Shield contract next.
-
-The current Proposer repeats this process n times, until they have assembled a Block, which contains
-the hashes of the Transactions included in the Block and the commitment Merkle-tree root as it would
-exist after processing all the transaction in the block (Commitment Root).
-
-They then call `Proposers.proposeBlock(...)` and pass in the Block struct that they have just
-assembled. The hash of this Block is then stored in a queue consisting of a linked-list of Block
-hashes. They have to stake a `BLOCK_STAKE` to do this, which is additional to their bond.
-
-The submission triggers emission of NewLeaf/NewLeaves events for a Timber listener. The Timber
-listener must realise that these new leaves may be removed after a successful challenge and thus
-must incorporate logic to wait for finalisation.
-
-### Challenges
-
-The blocks will be challengeable in the queue for a week, during which time their correctness may be
-challenged by calling one of the challenging functions in `Challenges.sol`. The challenger will need
-to pass in Block struct and the Transaction structs that are contained in the block, because the
-blockchain does not retain these. `Challenges.sol` will confirm this data against its stored Block
-hashes and then do an on-chain computation to determine the correctness of the challenge (the
-details of the computation being dependent on the type of challenge). The challenges that can be
-made are:
-
-- INVALID_PROOF - the proof given in a transaction does not verify as true;
-- INVALID_PUBLIC_INPUT_HASH - the public input hash of a transaction is not the correct hash of the
- public inputs;
-- HISTORIC_ROOT_EXISTS - the root of the commitment Merkle Tree used to create the transaction proof
- has never existed;
-- DUPLICATE_NULLIFIER - A nullifier, given as part of a Transaction is present in the list of spent
- nullifiers;
-- HISTORIC_ROOT_INVALID - the updated commitment root that results from processing the transactions
- in the Block is not correct.
-- DUPLICATE_TRANSACTION - An identical transaction included in this block has already been included
- in a prior block.
-- TRANSACTION_TYPE_INVALID - The transaction is not well-formed based on the transaction type (e.g.
- DEPOSIT, TRANSFER, WITHDRAWAL).
-
-Should the challenge succeed, i.e. the on-chain computation shows it to be a valid challenge, then
-the following actions are taken by `Challenges.sol`:
-
-- The hash of the Block in question and all subsequent Blocks are removed from the queue;
-- The Block stake, submitted by the Proposer, is paid to the Challenger;
-- The Transactors with a Transaction in the Block are reimbursed the fee that they would have paid
- to the Proposer and any escrowed funds held by the Shield contract in the case of a Deposit
- transaction.
-- The Proposer is delisted.
-
-### State incorporation
-
-We don't explicitly incorporate new state. Any block that is more than a week old is assumed final.
-`Shield.withdraw` can be called to withdraw funds from a finalised block. For this reason, Blocks
-that are final cannot be challenged.
-
-## Avoiding front-running attacks
-
-Challengers submit valid challenges using a 'commit-reveal' scheme to mitigate the risk that their
-challenge can be front-run. The Challenger does not challenge immediately but provides a salted hash
-of the Challenge information. This hash is saved against the sender's address.
-
-Once that transaction has gone through, the Challenger sends the complete Challenge information
-along with the salt. The contract then checks:
-
-- the data sent is the pre-image of the hash, once the salt is added.
-- the originating address is the same for both transactions
-
-A front-runner would be alerted that a challenge has been made but would have to find the flawed
-Block themselves and front-run before the challenge hash is written to the blockchain. This is not
-completely impossible but they have very little time to find the flawed Block and so are unlikely to
-succeed, or rather they have no more chance of succeeding than anyone else, which is fair game.
diff --git a/doc/deprecated/lib/fonts/OpenSans-Bold-webfont.eot b/doc/deprecated/lib/fonts/OpenSans-Bold-webfont.eot
deleted file mode 100644
index 5d20d9163..000000000
Binary files a/doc/deprecated/lib/fonts/OpenSans-Bold-webfont.eot and /dev/null differ
diff --git a/doc/deprecated/lib/fonts/OpenSans-Bold-webfont.svg b/doc/deprecated/lib/fonts/OpenSans-Bold-webfont.svg
deleted file mode 100644
index 3ed7be4bc..000000000
--- a/doc/deprecated/lib/fonts/OpenSans-Bold-webfont.svg
+++ /dev/null
@@ -1,1830 +0,0 @@
-
-
-
\ No newline at end of file
diff --git a/doc/deprecated/lib/fonts/OpenSans-Bold-webfont.woff b/doc/deprecated/lib/fonts/OpenSans-Bold-webfont.woff
deleted file mode 100644
index 1205787b0..000000000
Binary files a/doc/deprecated/lib/fonts/OpenSans-Bold-webfont.woff and /dev/null differ
diff --git a/doc/deprecated/lib/fonts/OpenSans-BoldItalic-webfont.eot b/doc/deprecated/lib/fonts/OpenSans-BoldItalic-webfont.eot
deleted file mode 100644
index 1f639a15f..000000000
Binary files a/doc/deprecated/lib/fonts/OpenSans-BoldItalic-webfont.eot and /dev/null differ
diff --git a/doc/deprecated/lib/fonts/OpenSans-BoldItalic-webfont.svg b/doc/deprecated/lib/fonts/OpenSans-BoldItalic-webfont.svg
deleted file mode 100644
index 6a2607b9d..000000000
--- a/doc/deprecated/lib/fonts/OpenSans-BoldItalic-webfont.svg
+++ /dev/null
@@ -1,1830 +0,0 @@
-
-
-
\ No newline at end of file
diff --git a/doc/deprecated/lib/fonts/OpenSans-BoldItalic-webfont.woff b/doc/deprecated/lib/fonts/OpenSans-BoldItalic-webfont.woff
deleted file mode 100644
index ed760c062..000000000
Binary files a/doc/deprecated/lib/fonts/OpenSans-BoldItalic-webfont.woff and /dev/null differ
diff --git a/doc/deprecated/lib/fonts/OpenSans-Italic-webfont.eot b/doc/deprecated/lib/fonts/OpenSans-Italic-webfont.eot
deleted file mode 100644
index 0c8a0ae06..000000000
Binary files a/doc/deprecated/lib/fonts/OpenSans-Italic-webfont.eot and /dev/null differ
diff --git a/doc/deprecated/lib/fonts/OpenSans-Italic-webfont.svg b/doc/deprecated/lib/fonts/OpenSans-Italic-webfont.svg
deleted file mode 100644
index e1075dcc2..000000000
--- a/doc/deprecated/lib/fonts/OpenSans-Italic-webfont.svg
+++ /dev/null
@@ -1,1830 +0,0 @@
-
-
-
\ No newline at end of file
diff --git a/doc/deprecated/lib/fonts/OpenSans-Italic-webfont.woff b/doc/deprecated/lib/fonts/OpenSans-Italic-webfont.woff
deleted file mode 100644
index ff652e643..000000000
Binary files a/doc/deprecated/lib/fonts/OpenSans-Italic-webfont.woff and /dev/null differ
diff --git a/doc/deprecated/lib/fonts/OpenSans-Light-webfont.eot b/doc/deprecated/lib/fonts/OpenSans-Light-webfont.eot
deleted file mode 100644
index 14868406a..000000000
Binary files a/doc/deprecated/lib/fonts/OpenSans-Light-webfont.eot and /dev/null differ
diff --git a/doc/deprecated/lib/fonts/OpenSans-Light-webfont.svg b/doc/deprecated/lib/fonts/OpenSans-Light-webfont.svg
deleted file mode 100644
index 11a472ca8..000000000
--- a/doc/deprecated/lib/fonts/OpenSans-Light-webfont.svg
+++ /dev/null
@@ -1,1831 +0,0 @@
-
-
-
\ No newline at end of file
diff --git a/doc/deprecated/lib/fonts/OpenSans-Light-webfont.woff b/doc/deprecated/lib/fonts/OpenSans-Light-webfont.woff
deleted file mode 100644
index e78607481..000000000
Binary files a/doc/deprecated/lib/fonts/OpenSans-Light-webfont.woff and /dev/null differ
diff --git a/doc/deprecated/lib/fonts/OpenSans-LightItalic-webfont.eot b/doc/deprecated/lib/fonts/OpenSans-LightItalic-webfont.eot
deleted file mode 100644
index 8f445929f..000000000
Binary files a/doc/deprecated/lib/fonts/OpenSans-LightItalic-webfont.eot and /dev/null differ
diff --git a/doc/deprecated/lib/fonts/OpenSans-LightItalic-webfont.svg b/doc/deprecated/lib/fonts/OpenSans-LightItalic-webfont.svg
deleted file mode 100644
index 431d7e354..000000000
--- a/doc/deprecated/lib/fonts/OpenSans-LightItalic-webfont.svg
+++ /dev/null
@@ -1,1835 +0,0 @@
-
-
-
\ No newline at end of file
diff --git a/doc/deprecated/lib/fonts/OpenSans-LightItalic-webfont.woff b/doc/deprecated/lib/fonts/OpenSans-LightItalic-webfont.woff
deleted file mode 100644
index 43e8b9e6c..000000000
Binary files a/doc/deprecated/lib/fonts/OpenSans-LightItalic-webfont.woff and /dev/null differ
diff --git a/doc/deprecated/lib/fonts/OpenSans-Regular-webfont.eot b/doc/deprecated/lib/fonts/OpenSans-Regular-webfont.eot
deleted file mode 100644
index 6bbc3cf58..000000000
Binary files a/doc/deprecated/lib/fonts/OpenSans-Regular-webfont.eot and /dev/null differ
diff --git a/doc/deprecated/lib/fonts/OpenSans-Regular-webfont.svg b/doc/deprecated/lib/fonts/OpenSans-Regular-webfont.svg
deleted file mode 100644
index 25a395234..000000000
--- a/doc/deprecated/lib/fonts/OpenSans-Regular-webfont.svg
+++ /dev/null
@@ -1,1831 +0,0 @@
-
-
-
\ No newline at end of file
diff --git a/doc/deprecated/lib/fonts/OpenSans-Regular-webfont.woff b/doc/deprecated/lib/fonts/OpenSans-Regular-webfont.woff
deleted file mode 100644
index e231183dc..000000000
Binary files a/doc/deprecated/lib/fonts/OpenSans-Regular-webfont.woff and /dev/null differ
diff --git a/doc/deprecated/lib/scripts/linenumber.js b/doc/deprecated/lib/scripts/linenumber.js
deleted file mode 100644
index 4354785ce..000000000
--- a/doc/deprecated/lib/scripts/linenumber.js
+++ /dev/null
@@ -1,25 +0,0 @@
-/*global document */
-(() => {
- const source = document.getElementsByClassName('prettyprint source linenums');
- let i = 0;
- let lineNumber = 0;
- let lineId;
- let lines;
- let totalLines;
- let anchorHash;
-
- if (source && source[0]) {
- anchorHash = document.location.hash.substring(1);
- lines = source[0].getElementsByTagName('li');
- totalLines = lines.length;
-
- for (; i < totalLines; i++) {
- lineNumber++;
- lineId = `line${lineNumber}`;
- lines[i].id = lineId;
- if (lineId === anchorHash) {
- lines[i].className += ' selected';
- }
- }
- }
-})();
diff --git a/doc/deprecated/lib/scripts/prettify/Apache-License-2.0.txt b/doc/deprecated/lib/scripts/prettify/Apache-License-2.0.txt
deleted file mode 100644
index d64569567..000000000
--- a/doc/deprecated/lib/scripts/prettify/Apache-License-2.0.txt
+++ /dev/null
@@ -1,202 +0,0 @@
-
- Apache License
- Version 2.0, January 2004
- http://www.apache.org/licenses/
-
- TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
- 1. Definitions.
-
- "License" shall mean the terms and conditions for use, reproduction,
- and distribution as defined by Sections 1 through 9 of this document.
-
- "Licensor" shall mean the copyright owner or entity authorized by
- the copyright owner that is granting the License.
-
- "Legal Entity" shall mean the union of the acting entity and all
- other entities that control, are controlled by, or are under common
- control with that entity. For the purposes of this definition,
- "control" means (i) the power, direct or indirect, to cause the
- direction or management of such entity, whether by contract or
- otherwise, or (ii) ownership of fifty percent (50%) or more of the
- outstanding shares, or (iii) beneficial ownership of such entity.
-
- "You" (or "Your") shall mean an individual or Legal Entity
- exercising permissions granted by this License.
-
- "Source" form shall mean the preferred form for making modifications,
- including but not limited to software source code, documentation
- source, and configuration files.
-
- "Object" form shall mean any form resulting from mechanical
- transformation or translation of a Source form, including but
- not limited to compiled object code, generated documentation,
- and conversions to other media types.
-
- "Work" shall mean the work of authorship, whether in Source or
- Object form, made available under the License, as indicated by a
- copyright notice that is included in or attached to the work
- (an example is provided in the Appendix below).
-
- "Derivative Works" shall mean any work, whether in Source or Object
- form, that is based on (or derived from) the Work and for which the
- editorial revisions, annotations, elaborations, or other modifications
- represent, as a whole, an original work of authorship. For the purposes
- of this License, Derivative Works shall not include works that remain
- separable from, or merely link (or bind by name) to the interfaces of,
- the Work and Derivative Works thereof.
-
- "Contribution" shall mean any work of authorship, including
- the original version of the Work and any modifications or additions
- to that Work or Derivative Works thereof, that is intentionally
- submitted to Licensor for inclusion in the Work by the copyright owner
- or by an individual or Legal Entity authorized to submit on behalf of
- the copyright owner. For the purposes of this definition, "submitted"
- means any form of electronic, verbal, or written communication sent
- to the Licensor or its representatives, including but not limited to
- communication on electronic mailing lists, source code control systems,
- and issue tracking systems that are managed by, or on behalf of, the
- Licensor for the purpose of discussing and improving the Work, but
- excluding communication that is conspicuously marked or otherwise
- designated in writing by the copyright owner as "Not a Contribution."
-
- "Contributor" shall mean Licensor and any individual or Legal Entity
- on behalf of whom a Contribution has been received by Licensor and
- subsequently incorporated within the Work.
-
- 2. Grant of Copyright License. Subject to the terms and conditions of
- this License, each Contributor hereby grants to You a perpetual,
- worldwide, non-exclusive, no-charge, royalty-free, irrevocable
- copyright license to reproduce, prepare Derivative Works of,
- publicly display, publicly perform, sublicense, and distribute the
- Work and such Derivative Works in Source or Object form.
-
- 3. Grant of Patent License. Subject to the terms and conditions of
- this License, each Contributor hereby grants to You a perpetual,
- worldwide, non-exclusive, no-charge, royalty-free, irrevocable
- (except as stated in this section) patent license to make, have made,
- use, offer to sell, sell, import, and otherwise transfer the Work,
- where such license applies only to those patent claims licensable
- by such Contributor that are necessarily infringed by their
- Contribution(s) alone or by combination of their Contribution(s)
- with the Work to which such Contribution(s) was submitted. If You
- institute patent litigation against any entity (including a
- cross-claim or counterclaim in a lawsuit) alleging that the Work
- or a Contribution incorporated within the Work constitutes direct
- or contributory patent infringement, then any patent licenses
- granted to You under this License for that Work shall terminate
- as of the date such litigation is filed.
-
- 4. Redistribution. You may reproduce and distribute copies of the
- Work or Derivative Works thereof in any medium, with or without
- modifications, and in Source or Object form, provided that You
- meet the following conditions:
-
- (a) You must give any other recipients of the Work or
- Derivative Works a copy of this License; and
-
- (b) You must cause any modified files to carry prominent notices
- stating that You changed the files; and
-
- (c) You must retain, in the Source form of any Derivative Works
- that You distribute, all copyright, patent, trademark, and
- attribution notices from the Source form of the Work,
- excluding those notices that do not pertain to any part of
- the Derivative Works; and
-
- (d) If the Work includes a "NOTICE" text file as part of its
- distribution, then any Derivative Works that You distribute must
- include a readable copy of the attribution notices contained
- within such NOTICE file, excluding those notices that do not
- pertain to any part of the Derivative Works, in at least one
- of the following places: within a NOTICE text file distributed
- as part of the Derivative Works; within the Source form or
- documentation, if provided along with the Derivative Works; or,
- within a display generated by the Derivative Works, if and
- wherever such third-party notices normally appear. The contents
- of the NOTICE file are for informational purposes only and
- do not modify the License. You may add Your own attribution
- notices within Derivative Works that You distribute, alongside
- or as an addendum to the NOTICE text from the Work, provided
- that such additional attribution notices cannot be construed
- as modifying the License.
-
- You may add Your own copyright statement to Your modifications and
- may provide additional or different license terms and conditions
- for use, reproduction, or distribution of Your modifications, or
- for any such Derivative Works as a whole, provided Your use,
- reproduction, and distribution of the Work otherwise complies with
- the conditions stated in this License.
-
- 5. Submission of Contributions. Unless You explicitly state otherwise,
- any Contribution intentionally submitted for inclusion in the Work
- by You to the Licensor shall be under the terms and conditions of
- this License, without any additional terms or conditions.
- Notwithstanding the above, nothing herein shall supersede or modify
- the terms of any separate license agreement you may have executed
- with Licensor regarding such Contributions.
-
- 6. Trademarks. This License does not grant permission to use the trade
- names, trademarks, service marks, or product names of the Licensor,
- except as required for reasonable and customary use in describing the
- origin of the Work and reproducing the content of the NOTICE file.
-
- 7. Disclaimer of Warranty. Unless required by applicable law or
- agreed to in writing, Licensor provides the Work (and each
- Contributor provides its Contributions) on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
- implied, including, without limitation, any warranties or conditions
- of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
- PARTICULAR PURPOSE. You are solely responsible for determining the
- appropriateness of using or redistributing the Work and assume any
- risks associated with Your exercise of permissions under this License.
-
- 8. Limitation of Liability. In no event and under no legal theory,
- whether in tort (including negligence), contract, or otherwise,
- unless required by applicable law (such as deliberate and grossly
- negligent acts) or agreed to in writing, shall any Contributor be
- liable to You for damages, including any direct, indirect, special,
- incidental, or consequential damages of any character arising as a
- result of this License or out of the use or inability to use the
- Work (including but not limited to damages for loss of goodwill,
- work stoppage, computer failure or malfunction, or any and all
- other commercial damages or losses), even if such Contributor
- has been advised of the possibility of such damages.
-
- 9. Accepting Warranty or Additional Liability. While redistributing
- the Work or Derivative Works thereof, You may choose to offer,
- and charge a fee for, acceptance of support, warranty, indemnity,
- or other liability obligations and/or rights consistent with this
- License. However, in accepting such obligations, You may act only
- on Your own behalf and on Your sole responsibility, not on behalf
- of any other Contributor, and only if You agree to indemnify,
- defend, and hold each Contributor harmless for any liability
- incurred by, or claims asserted against, such Contributor by reason
- of your accepting any such warranty or additional liability.
-
- END OF TERMS AND CONDITIONS
-
- APPENDIX: How to apply the Apache License to your work.
-
- To apply the Apache License to your work, attach the following
- boilerplate notice, with the fields enclosed by brackets "[]"
- replaced with your own identifying information. (Don't include
- the brackets!) The text should be enclosed in the appropriate
- comment syntax for the file format. We also recommend that a
- file or class name and description of purpose be included on the
- same "printed page" as the copyright notice for easier
- identification within third-party archives.
-
- Copyright [yyyy] [name of copyright owner]
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
diff --git a/doc/deprecated/lib/scripts/prettify/lang-css.js b/doc/deprecated/lib/scripts/prettify/lang-css.js
deleted file mode 100644
index 041e1f590..000000000
--- a/doc/deprecated/lib/scripts/prettify/lang-css.js
+++ /dev/null
@@ -1,2 +0,0 @@
-PR.registerLangHandler(PR.createSimpleLexer([["pln",/^[\t\n\f\r ]+/,null," \t\r\n"]],[["str",/^"(?:[^\n\f\r"\\]|\\(?:\r\n?|\n|\f)|\\[\S\s])*"/,null],["str",/^'(?:[^\n\f\r'\\]|\\(?:\r\n?|\n|\f)|\\[\S\s])*'/,null],["lang-css-str",/^url\(([^"')]*)\)/i],["kwd",/^(?:url|rgb|!important|@import|@page|@media|@charset|inherit)(?=[^\w-]|$)/i,null],["lang-css-kw",/^(-?(?:[_a-z]|\\[\da-f]+ ?)(?:[\w-]|\\\\[\da-f]+ ?)*)\s*:/i],["com",/^\/\*[^*]*\*+(?:[^*/][^*]*\*+)*\//],["com",
-/^(?:<\!--|--\>)/],["lit",/^(?:\d+|\d*\.\d+)(?:%|[a-z]+)?/i],["lit",/^#[\da-f]{3,6}/i],["pln",/^-?(?:[_a-z]|\\[\da-f]+ ?)(?:[\w-]|\\\\[\da-f]+ ?)*/i],["pun",/^[^\s\w"']+/]]),["css"]);PR.registerLangHandler(PR.createSimpleLexer([],[["kwd",/^-?(?:[_a-z]|\\[\da-f]+ ?)(?:[\w-]|\\\\[\da-f]+ ?)*/i]]),["css-kw"]);PR.registerLangHandler(PR.createSimpleLexer([],[["str",/^[^"')]+/]]),["css-str"]);
diff --git a/doc/deprecated/lib/scripts/prettify/prettify.js b/doc/deprecated/lib/scripts/prettify/prettify.js
deleted file mode 100644
index eef5ad7e6..000000000
--- a/doc/deprecated/lib/scripts/prettify/prettify.js
+++ /dev/null
@@ -1,28 +0,0 @@
-var q=null;window.PR_SHOULD_USE_CONTINUATION=!0;
-(function(){function L(a){function m(a){var f=a.charCodeAt(0);if(f!==92)return f;var b=a.charAt(1);return(f=r[b])?f:"0"<=b&&b<="7"?parseInt(a.substring(1),8):b==="u"||b==="x"?parseInt(a.substring(2),16):a.charCodeAt(1)}function e(a){if(a<32)return(a<16?"\\x0":"\\x")+a.toString(16);a=String.fromCharCode(a);if(a==="\\"||a==="-"||a==="["||a==="]")a="\\"+a;return a}function h(a){for(var f=a.substring(1,a.length-1).match(/\\u[\dA-Fa-f]{4}|\\x[\dA-Fa-f]{2}|\\[0-3][0-7]{0,2}|\\[0-7]{1,2}|\\[\S\s]|[^\\]/g),a=
-[],b=[],o=f[0]==="^",c=o?1:0,i=f.length;c122||(d<65||j>90||b.push([Math.max(65,j)|32,Math.min(d,90)|32]),d<97||j>122||b.push([Math.max(97,j)&-33,Math.min(d,122)&-33]))}}b.sort(function(a,f){return a[0]-f[0]||f[1]-a[1]});f=[];j=[NaN,NaN];for(c=0;ci[0]&&(i[1]+1>i[0]&&b.push("-"),b.push(e(i[1])));b.push("]");return b.join("")}function y(a){for(var f=a.source.match(/\[(?:[^\\\]]|\\[\S\s])*]|\\u[\dA-Fa-f]{4}|\\x[\dA-Fa-f]{2}|\\\d+|\\[^\dux]|\(\?[!:=]|[()^]|[^()[\\^]+/g),b=f.length,d=[],c=0,i=0;c=2&&a==="["?f[c]=h(j):a!=="\\"&&(f[c]=j.replace(/[A-Za-z]/g,function(a){a=a.charCodeAt(0);return"["+String.fromCharCode(a&-33,a|32)+"]"}));return f.join("")}for(var t=0,s=!1,l=!1,p=0,d=a.length;p=5&&"lang-"===b.substring(0,5))&&!(o&&typeof o[1]==="string"))c=!1,b="src";c||(r[f]=b)}i=d;d+=f.length;if(c){c=o[1];var j=f.indexOf(c),k=j+c.length;o[2]&&(k=f.length-o[2].length,j=k-c.length);b=b.substring(5);B(l+i,f.substring(0,j),e,p);B(l+i+j,c,C(b,c),p);B(l+i+k,f.substring(k),e,p)}else p.push(l+i,b)}a.e=p}var h={},y;(function(){for(var e=a.concat(m),
-l=[],p={},d=0,g=e.length;d=0;)h[n.charAt(k)]=r;r=r[1];n=""+r;p.hasOwnProperty(n)||(l.push(r),p[n]=q)}l.push(/[\S\s]/);y=L(l)})();var t=m.length;return e}function u(a){var m=[],e=[];a.tripleQuotedStrings?m.push(["str",/^(?:'''(?:[^'\\]|\\[\S\s]|''?(?=[^']))*(?:'''|$)|"""(?:[^"\\]|\\[\S\s]|""?(?=[^"]))*(?:"""|$)|'(?:[^'\\]|\\[\S\s])*(?:'|$)|"(?:[^"\\]|\\[\S\s])*(?:"|$))/,q,"'\""]):a.multiLineStrings?m.push(["str",/^(?:'(?:[^'\\]|\\[\S\s])*(?:'|$)|"(?:[^"\\]|\\[\S\s])*(?:"|$)|`(?:[^\\`]|\\[\S\s])*(?:`|$))/,
-q,"'\"`"]):m.push(["str",/^(?:'(?:[^\n\r'\\]|\\.)*(?:'|$)|"(?:[^\n\r"\\]|\\.)*(?:"|$))/,q,"\"'"]);a.verbatimStrings&&e.push(["str",/^@"(?:[^"]|"")*(?:"|$)/,q]);var h=a.hashComments;h&&(a.cStyleComments?(h>1?m.push(["com",/^#(?:##(?:[^#]|#(?!##))*(?:###|$)|.*)/,q,"#"]):m.push(["com",/^#(?:(?:define|elif|else|endif|error|ifdef|include|ifndef|line|pragma|undef|warning)\b|[^\n\r]*)/,q,"#"]),e.push(["str",/^<(?:(?:(?:\.\.\/)*|\/?)(?:[\w-]+(?:\/[\w-]+)+)?[\w-]+\.h|[a-z]\w*)>/,q])):m.push(["com",/^#[^\n\r]*/,
-q,"#"]));a.cStyleComments&&(e.push(["com",/^\/\/[^\n\r]*/,q]),e.push(["com",/^\/\*[\S\s]*?(?:\*\/|$)/,q]));a.regexLiterals&&e.push(["lang-regex",/^(?:^^\.?|[!+-]|!=|!==|#|%|%=|&|&&|&&=|&=|\(|\*|\*=|\+=|,|-=|->|\/|\/=|:|::|;|<|<<|<<=|<=|=|==|===|>|>=|>>|>>=|>>>|>>>=|[?@[^]|\^=|\^\^|\^\^=|{|\||\|=|\|\||\|\|=|~|break|case|continue|delete|do|else|finally|instanceof|return|throw|try|typeof)\s*(\/(?=[^*/])(?:[^/[\\]|\\[\S\s]|\[(?:[^\\\]]|\\[\S\s])*(?:]|$))+\/)/]);(h=a.types)&&e.push(["typ",h]);a=(""+a.keywords).replace(/^ | $/g,
-"");a.length&&e.push(["kwd",RegExp("^(?:"+a.replace(/[\s,]+/g,"|")+")\\b"),q]);m.push(["pln",/^\s+/,q," \r\n\t\xa0"]);e.push(["lit",/^@[$_a-z][\w$@]*/i,q],["typ",/^(?:[@_]?[A-Z]+[a-z][\w$@]*|\w+_t\b)/,q],["pln",/^[$_a-z][\w$@]*/i,q],["lit",/^(?:0x[\da-f]+|(?:\d(?:_\d+)*\d*(?:\.\d*)?|\.\d\+)(?:e[+-]?\d+)?)[a-z]*/i,q,"0123456789"],["pln",/^\\[\S\s]?/,q],["pun",/^.[^\s\w"-$'./@\\`]*/,q]);return x(m,e)}function D(a,m){function e(a){switch(a.nodeType){case 1:if(k.test(a.className))break;if("BR"===a.nodeName)h(a),
-a.parentNode&&a.parentNode.removeChild(a);else for(a=a.firstChild;a;a=a.nextSibling)e(a);break;case 3:case 4:if(p){var b=a.nodeValue,d=b.match(t);if(d){var c=b.substring(0,d.index);a.nodeValue=c;(b=b.substring(d.index+d[0].length))&&a.parentNode.insertBefore(s.createTextNode(b),a.nextSibling);h(a);c||a.parentNode.removeChild(a)}}}}function h(a){function b(a,d){var e=d?a.cloneNode(!1):a,f=a.parentNode;if(f){var f=b(f,1),g=a.nextSibling;f.appendChild(e);for(var h=g;h;h=g)g=h.nextSibling,f.appendChild(h)}return e}
-for(;!a.nextSibling;)if(a=a.parentNode,!a)return;for(var a=b(a.nextSibling,0),e;(e=a.parentNode)&&e.nodeType===1;)a=e;d.push(a)}var k=/(?:^|\s)nocode(?:\s|$)/,t=/\r\n?|\n/,s=a.ownerDocument,l;a.currentStyle?l=a.currentStyle.whiteSpace:window.getComputedStyle&&(l=s.defaultView.getComputedStyle(a,q).getPropertyValue("white-space"));var p=l&&"pre"===l.substring(0,3);for(l=s.createElement("LI");a.firstChild;)l.appendChild(a.firstChild);for(var d=[l],g=0;g=0;){var h=m[e];A.hasOwnProperty(h)?window.console&&console.warn("cannot override language handler %s",h):A[h]=a}}function C(a,m){if(!a||!A.hasOwnProperty(a))a=/^\s*=o&&(h+=2);e>=c&&(a+=2)}}catch(w){"console"in window&&console.log(w&&w.stack?w.stack:w)}}var v=["break,continue,do,else,for,if,return,while"],w=[[v,"auto,case,char,const,default,double,enum,extern,float,goto,int,long,register,short,signed,sizeof,static,struct,switch,typedef,union,unsigned,void,volatile"],
-"catch,class,delete,false,import,new,operator,private,protected,public,this,throw,true,try,typeof"],F=[w,"alignof,align_union,asm,axiom,bool,concept,concept_map,const_cast,constexpr,decltype,dynamic_cast,explicit,export,friend,inline,late_check,mutable,namespace,nullptr,reinterpret_cast,static_assert,static_cast,template,typeid,typename,using,virtual,where"],G=[w,"abstract,boolean,byte,extends,final,finally,implements,import,instanceof,null,native,package,strictfp,super,synchronized,throws,transient"],
-H=[G,"as,base,by,checked,decimal,delegate,descending,dynamic,event,fixed,foreach,from,group,implicit,in,interface,internal,into,is,lock,object,out,override,orderby,params,partial,readonly,ref,sbyte,sealed,stackalloc,string,select,uint,ulong,unchecked,unsafe,ushort,var"],w=[w,"debugger,eval,export,function,get,null,set,undefined,var,with,Infinity,NaN"],I=[v,"and,as,assert,class,def,del,elif,except,exec,finally,from,global,import,in,is,lambda,nonlocal,not,or,pass,print,raise,try,with,yield,False,True,None"],
-J=[v,"alias,and,begin,case,class,def,defined,elsif,end,ensure,false,in,module,next,nil,not,or,redo,rescue,retry,self,super,then,true,undef,unless,until,when,yield,BEGIN,END"],v=[v,"case,done,elif,esac,eval,fi,function,in,local,set,then,until"],K=/^(DIR|FILE|vector|(de|priority_)?queue|list|stack|(const_)?iterator|(multi)?(set|map)|bitset|u?(int|float)\d*)/,N=/\S/,O=u({keywords:[F,H,w,"caller,delete,die,do,dump,elsif,eval,exit,foreach,for,goto,if,import,last,local,my,next,no,our,print,package,redo,require,sub,undef,unless,until,use,wantarray,while,BEGIN,END"+
-I,J,v],hashComments:!0,cStyleComments:!0,multiLineStrings:!0,regexLiterals:!0}),A={};k(O,["default-code"]);k(x([],[["pln",/^[^]+/],["dec",/^]*(?:>|$)/],["com",/^<\!--[\S\s]*?(?:--\>|$)/],["lang-",/^<\?([\S\s]+?)(?:\?>|$)/],["lang-",/^<%([\S\s]+?)(?:%>|$)/],["pun",/^(?:<[%?]|[%?]>)/],["lang-",/^]*>([\S\s]+?)<\/xmp\b[^>]*>/i],["lang-js",/^