# Enveloping Arbiter Especification

The Enveloping Arbiter is an off-chain component of the Enveloping solution. It is in charge of ensuring quality of service for the Enveloping clients and is part of the Relay Server.

- Keeps track of network activity analyzing its behavior to estimate and predict fees.
- Provides tiers of service, each one associated with a charge based on predicted fees and a relay time.
- Provides the above information to the Relay Clients so they can decide on the usage of the service and which tier is best suited for their purposes.
- Provides assurance of fulfillment of the relay service in the form of a verificable signed Commitment Receipt.
- Maintains multiple nonce queues (distinct accounts) so transactions pending to be relayed can be organized by deadline, allowing to expand it later to include other rules.

#### Components:

- **Fee Estimator** - estimates the current fees for different tolerated delays.
- **Nonce Queue Selector** - for each transaction that is submitted, chooses which nonce queue will be used, based on existing rules.
- **Commitment Validator** - component for verifying the signature of a Commitment Receipt

#### Structures:
- **Commitment** - represents the terms that the Relay Server agrees in order to relay the request, so it can be disputed in case it doesn't comply

#### Modifications:
- **Relay Server** - now it handles multiple workers. By default it will use 4, each one relaying with different delays, based on using different gas prices, being Tier 1 the lowest speed (< 30min), Tier 2 the standard (and default) speed (< 5min), Tier 3 the fast speed (< 2min) and Tier 4 the instant speed (next block). It now provides a worker signed Commitment Receipt to the client, that signature can be verified also on a smart contract using ecrecover.
- **Relay Client** - now it has a chance of specifying a maxTime field when relaying, a timestamp representing the intended expiration time for the transaction to be relayed and included in the blockchain.
- **Relay Provider** - added support for receiving the maxTime parameter from the user and sending it to the Relay Client.
- **Key Manager** - added a new method signMessage that uses the private key and ethers module to sign a message, used by the Enveloping Arbiter to sign Commitments

### Dependencies Changes

Upgrade of `ethers` from `5.0.19` to `5.0.23`. Here is the repo https://github.com/ethers-io/ethers.js and the changelog for `5.0.23`:

    5.0.20

    Fix browser ws alias for WebSockets. (02546b9)
    Fixing React Native tests. (f10977a, fff72ef)
    Refactoring dist build process. (4809325, 22bd0c7, 8933467)

    5.0.21

    Force address to use bignumber package with base36 private functions. (#1163; c9e5480)
    Remove stray console.log in hardware wallets. (#1136; cc63e61)
    Added some funding links for the sponsor button. (2816850)
    Remove invalid pkg.module reference. (#1133; cddc258)

    5.0.22

    Added directory to repo field for each package. (799896a)
    Add ABI coder function to compute default values. (#1101; a8e3380)
    Fix for new versions of Geth which return formatted data on revert rather than standard data. (#949; 4a8d579)
    Addd missing sideEffects flag to some packages. (20defec)
    Allow base-10 to be passed into BigNumbner.toString and improve errors for other radices. (#1164; c8bb77d, #1164; fbbe4ad)
    Allow private keys to Wallet to omit the 0x prefix. (#1166; 29f6c34)

    5.0.23

    Fix BigNumber when passed something with a length property. (#1172; 45a2902)

Extracted from here https://github.com/ethers-io/ethers.js/releases?after=v5.0.28

### Short Explanation

This solution wants to generate a way to have multiple workers for different scenarios and let the client choose which one is better to execute the transaction in that time due to gas costs.

### Status

Basically we have a PR https://github.com/rsksmart/enveloping/pull/75 that has changes for the relay server and client where logic is added to manage the way the worker is chosen and executes the transactions. Merging this into master throws conflicts that can't be automatically solved by git. This PR also includes tests for all the new features.

### Next Steps

1. Merge into master and resolve conflicts.
2. Test the result code to verify if the server and client are working properly. Also run the defined tests to see if all works properly.
3. Check the qubistry requirements for the arbiter in order to determine if the code is doing what it should be.
4. Work on missing parts of the requirements (if has any)
5. Test everything after finish the development.