Our Focus

The EEA Interoperability Testing Working Group's goal is to maintain short-term testnets (generally Enterprise Ethereum Permissioned Blockchains) and relevant associated tooling for the purposes of testing conformance and allowing EEA members to experiment.

Resources

The EEA testnet is available to EEA Members.

The testnet is composed of GoQuorum and Hyperledger Besu nodes operating with a QBFT consensus.

Head on to the Github repository to learn how to join and participate in the network.

To see how the QBFT testnet is set up, feel free to take a look at the Github repository that defines its behavior.

Exodus

Exodus is a proposal of the working group representing how to encode the state of a blockchain, specifically its genesis state and initial block, so it can be used in testing.

During testing of distributed systems, we need to load blockchain data and perform some operations.
There is currently no standard in place to codify how to ingest blockchain data. The current solutions involve directly ingesting RLP-encoded data, and that is effectively impossible to read directly which makes it hard to reason about tests.
We aim to facilitate testing and formulation of tests through an explicit format developers can use to represent contracts and transactions in detail, as well as the expected outcomes.

EEA members can access the latest draft on the Github repository.

Current draft


# Exodus format
## Describing blockchain testing data

## Editor:
Antoine Toulme, The Machine Consultancy LLC

## Contributors:
Chaals Nevile (EEA)

# Problem
During testing of distributed systems, we need to load blockchain data and perform some operations.

There is currently no standard in place to codify how to ingest blockchain data. The current solutions involve directly ingesting RLP-encoded data,
and that is effectively impossible to read directly which makes it hard to reason about tests.

We aim to facilitate testing and formulation of tests through an explicit format developers can use to represent contracts and transactions in detail,
as well as the expected outcomes.

# Solution
This document specifies the environment and conditions in which our chain can operate and testing can take place.

The environment is created based on a chain configuration, that can include initial balances, and transactions to be processed.

**Note** This solution can be applied to other use cases. It is helpful if our solution also enables creating sidechains with specific characteristics on demand.

# Proposal

## Requirements

The format MUST be human-readable.

The format MUST allow diffing between versions of a test.

The format MUST allow a "complex" description (including text and links) of what is being tested.

The format MUST allow comments.

The format MUST be verifiable by a program that tests the validity of the content.

The format MUST be lintable by a program performing style checks on the content.

The format MUST be transformable into a genesis block containing all transactions in order.

## Data model

This section defines the data model of the blockchain data interchange format. The current proposal is to use a YAML-based format allowing key-value pairs.

### Data representation

#### Numbers

Numbers can be represented either as natural numbers, or hexadecimal-encoded strings, starting with the `0x` prefix.

As an example, "0x42" can also be represented as 66. 1337 can be represented as "0x539".

### Chain configuration

#### Chain ID

The configuration must contain the chain identifier. The identifier can be represented either:
- as an integer in decimal form
- 32-bytes, left-padded hexadecimal encoded string starting with the prefix 0x.
- See the [crosschain identifier specification](https://entethalliance.github.io/crosschain-interoperability/crosschainid.html#sec-crosschain-identifier)

Examples:
```yaml
configuration:
  chainId: 23
```

```yaml
configuration:
  chainId: "0x68656c6c6f776f726c64"
```

The chainId configuration key is REQUIRED.

#### Consensus mechanism

The following consensus mechanisms are supported:
* pow
* clique
* ibft
* ibft2
* qbft
* raft

The consensus mechanism lives under the key 'consensus'.

Example:
```yaml
configuration:
  consensus:
    pow:
      mining: "keccak"
```

The consensus key is REQUIRED.


#### Mining algorithm

The following mining algorithm can be specified:
- ethash
- keccak

Example:
```yaml
configuration:
  consensus:
    pow:
      mining: "ethash"
      fixeddifficulty: 10000
```

The mining algorithm is REQUIRED if the consensus is set to `pow`.

Additionally, as shown in the example above, a fixed difficulty MAY be specified as an integer value using the key `difficulty`.

#### Gas cost

The configuration MAY specify to deactivate gas costs.

Example:
```yaml
configuration:
  disableGasCost: true
```

#### Fork blocks

The configuration MUST specify fork blocks mapping to known Ethereum forks.

Example:
```yaml
configuration:
  frontier: 0
  ...
  constantinople: 1000
```

### Chain data

#### Account data

Account data consists of an address, account balance, nonce, storage contents and code.

```yaml
address: "0xcccccccccccccccccccccccccccccccccccccccc"
balance: "0x186a0"
code: "0x60806004600037602060806080600060006001610bb8f1600055608051600155"
nonce: "0x01"
```

Storage contents are encoded as an array of key/value pairs.
```yaml
storage:
  - key: "0x0000000000000000000000000000000000000000000000000000000000000001"
    value: "0x0000000000000000000000000000000000000000000000000000000000000000"
  - key: "0x0000000000000000000000000000000000000000000000000000000000000000"
    value: "0x0000000000000000000000000000000000000000000000000000000000000001"
```

#### Transaction data

A transaction is represented with the following fields:
* nonce: the nonce of the transaction as a 32 bytes hex-encoded value, left padded with zeros.
* gasPrice: the price of the transaction in Wei.
* gasLimit: the gas limit of the transaction.
* to: the recipient of the transaction as a hex-encoded 20 bytes value
* contractCreation: true if this transaction is a contract creation, false if it is a message.
* value: the value of the transaction in Wei.
* payload: the payload of the transaction as hex-encoded byte data
* chainId: the chain ID associated with the transaction as an integer
* sender: the sender of the transaction as a hex-encoded 20 bytes value

```yaml
nonce: "0x1"
gasPrice: "0x42"
gasLimit: "0x300000"
to: "0xcccccccccccccccccccccccccccccccccccccccc"
contractCreation: false
value: "0x"
payload: "0xdeadbeef"
chainId: "0x1337"
sender: "0xe5619b92236e18865b493dcddb9188f77febf766"
```

#### Blocks

Blocks consist of header data:
* The timestamp of the block, as a UNIX timestamp in seconds.
* Up to 32 bytes of data to be used freely as vanity data
* The difficulty of the block, as a hex-encoded 256 bits value

Blocks contain a list of transactions as well.

```yaml
timestamp: 1656055865
extraData: "0xdeadbeef"
difficulty: "0xd1ff1c0147"
transactions:
  - ...
```

#### Account allocations

Account initial allocations are defined as a map of account addresses mapping to account content.

```yaml
accounts:
  - address: "0xcccccccccccccccccccccccccccccccccccccccc"
    balance: "0x186a0"
    code: "0x60806004600037602060806080600060006001610bb8f1600055608051600155"
    nonce: "0x01"
    storage:
      - key: "0x0000000000000000000000000000000000000000000000000000000000000001"
        value: "0x0000000000000000000000000000000000000000000000000000000000000000"
      - key: "0x0000000000000000000000000000000000000000000000000000000000000000"
        value: "0x0000000000000000000000000000000000000000000000000000000000000001"
```

### Blocks

Blocks are listed under the `blocks` key.

Example:
```yaml
blocks:
  - timestamp: 1656055865
    extraData: "0xdeadbeef"
    difficulty: "0xd1ff1c0147"
    transactions:
      - nonce: "0x1"
        gasPrice: "0x42"
        gasLimit: "0x300000"
        to: "0xcccccccccccccccccccccccccccccccccccccccc"
        contractCreation: false
        value: "0x"
        payload: "0xdeadbeef"
        chainId: "0x1337"
        sender: "0xe5619b92236e18865b493dcddb9188f77febf766"
```

# Examples

## Simple Ethash network with a few allocated accounts

```yaml
configuration:
  chainId: 56678
  consensus:
    pow:
       mining: "ethash"
accounts:
  - address: "0xe5619b92236e18865b493dcddb9188f77febf766"
    balance: 100
  - address: "0xacad4071740155f8b6335ad7491981863436c394"
    balance: 100
  - address: "0x608ef13c9ee253e540ffeb86010072871911c79d"
    balance: 100
  - address: "0x8674fce75c8fa7917a5dfe3855724796a47d2561" # Private key: 0xf1d9d40a4e74a4941f47a88f5d0c3972f07f7deba5639eb886eef39a404a46bf
    balance: 100
```

# How to propose changes

Proposing changes is only available to members of the Enterprise Ethereum Alliance.

To propose changes to this document, please open an issue against the [Testing Working Group](https://github.com/EntEthAlliance/testing-wg) repository.

We can discuss the change and turn your issue into a pull request.

                                

How to Contribute

For information on how to join the group, see contact below:

Participation

The Working Group welcomes contributions to its documentation, contracts and other code for deployment, or members who would like to operate their own nodes on the testnets.

Chair

Contact Us

Non-EEA Members:

If you are interested in the work of the EEA Interoperability Testing WG and would like to contribute, please contact james.harsh@entethalliance.org.

EEA Members:

Please contact the EEA Secretariat or your EEA Member Council representative.