Ethereum Validation IBFT Soma

IBFT Soma

The Ion interoperability framework uses modular validation to allow interoperability with blockchains of any consensus protocol. This document describes the design of the validation contract for the IBFT-Soma mechanism.

A sequence diagram for the IBFT-Soma validation module is given below:

IBFT-Soma Validation Contract

The latest contract can be found here.

IBFT-Soma Specific Properties

The core functions and other properties are identical to those found in the generic validation module specifications - see here. However, to support the functionality of the IBFT-Soma block validation a number of changes are made to the implementation of the validation module, that are specific to IBFT-Soma consensus.

Properties

m_blockhashes

Mapping of block hashes to boolean, allowing simple identification of previously submitted and persisted blocks.

m_headers

Mapping of block hashes to a struct containing fields storing required data for performing state transition verification for an Ethereum chain.

m_blockmetadata

Mapping of block hashes to a struct containing fields storing metadata associated with a given block, used for validation of subsequent blocks validity.

Header

Struct containing relevant fields for persistance of Ethereum state transistions in a given block:

• block number
• block hash
• parent block hash
• transaction state root hash
• transaction receipt state root hash

Metadata

Struct containing relevant fields for verification of block validity:

• Validators of next block
• Mapping of validators to boolean
• Commit seal threshold, (2/3) * N + 1, where N is the number of validators

Functions

RegisterChain

Function: RegisterChain
Purpose: Registers a new chain to the Ion contract, creating a specific connection between the validation contract and Ion hub contract.
Arguments:
    * id (bytes32: Unique id of another chain to interoperate with )
    * validators (address[]: Array containing the validators at the genesis block )
    * genesisHash (bytes32: Hash of the genesis block for the chain being registered with Ion )
  * storageAddr (bytes32: the address of the storage contract for Ethereum network)

SubmitBlock

Function: SubmitBlock
Purpose: Validates a submitted block, needs to recreate the signed hash using the submitted block then perform a verification of the signature used.
Arguments:
  * id (bytes32: the identification hash of the chain being interoperated with )
  * rlpUnsignedHeader (bytes: rlp encoded header without validator signatures )
  * rlpSignerHeader (bytes: rlp encoded signed block as defined by IBFT-Soma, including the validator signature )
  * commitSeals (bytes: rlp encoded signed block as defined by IBFT-Soma, including the validator signature )
  * storageAddr (bytes32: the address of the storage contract for Ethereum network)

Blocks should be submitted RLP encoded in the following ordering:

{  
    header.ParentHash,
    header.UncleHash,
    header.Coinbase,
    header.Root,
    header.TxHash,
    header.ReceiptHash,
    header.Bloom,
    header.Difficulty,
    header.Number,
    header.GasLimit,
    header.GasUsed,
    header.Time,
    header.Extra,
    header.MixDigest,
    header.Nonce
}

However the rlpUnsignedHeader and rlpSignedHeader should contain different data in the extra data field, specific to IBFT-Soma. As documented in the original Istanbul specification the extra data field in IBFT is modified, as follows:

type ExtraData struct {
    Vanity [32]bytes,               // Standard extra data
    Istanbul IstanbulExtra          // Istanbul specific
}

type IstanbulExtra struct {
 	Validators    []common.Address 	// Validator addresses
 	Seal          []byte			// Proposer seal 65 bytes
 	CommittedSeal [][]byte			// Committed seal, 65 * len(Validators) bytes
}

Given a block requested from an IBFT-Soma network a number of modifications must be made to a block in order to perform validation. The contract requires the rlpUnsignedHeader and rlpSignedHeader in order to verify the proposal and committment seals.

Proposal Seal Validation

In order to verify the proposal seal of the block creator the hash of the unsigned must be used as a preimage to perform the recovery of the signed public address. Thus the rlpUnsignedHeader contains the extra data field with Seal and CommittedSeal empty in the IstanbulExtra section of the field.

Note: the IstanbulExtra is simply be RLP encoded and appended to the 32 vanity bytes.

Commit Seals Validation

Similarly, to verify each commit seal the signed header must be passed. This is similar to the above other than the Seal is added to the IstanbulExtra. Howeverthe CommittedSeal field remains empty.

To finalise a submitted block the commitSeals must be passed to the contract. This should be the RLP encoded bytes of the CommittedSeal field in the IstanbulExtra struct.

Note: the IstanbulExtra is simply be RLP encoded and appended to the 32 vanity bytes.

Block Acceptance

Submitted blocks should be rejected if:

• The proposal does not belong to a validator in the whitelist
• The commit seals do not belong to a validator in the whitelist
• ParentHash is not found in the Header mappings

If a block is successfully validated two things should happen:

• Block is appended to the state history of the foreign chain

Finality

IBFT-Soma has deterministic finality, as blocks are rejected unless they contain sufficient commit seals.

Validator Set Update

IBFT-Soma allows additional validators to be added or removed through the Soma smart contract. The Validators field of a submitted block will contain the whitelist of validators of the following block.