AIP #005 - Bridge Operator Standard

Title: Bidirectional Bridge Operator Standard Author(s): Rakesh Gohel Type: ASC (Aion Standards and Conventions) Status: Accepted Creation Date: September 23th, 2018 Contact Information: rakesh@mavennet.com

Summary

A standard to meet the functionality requirements of a bidirectional bridge operator to support a two way flow of tokens or assets.

Value Proposition

To enable the movement of tokens/assets beyond the boundary of a connected blockchain to AION and similarly in the opposite direction. Most of the tokens are tied to the network they have been created in. If a similar token is available on Aion, they can be benefited from the Aion ecosystem. Moreover, there is a value proposition to create a split ICO token to receive the benefits of two different blockchain networks.

Motivation

The primary motivation for the proposol is to enable tokens available on other blockchain networks to be able to participate and receive the benefits of Aion blockchain. The exchange route to move the tokens across the network could be expensive and a lot more complexity involved for the user. The bridge operator helps user to move their tokens to Aion with ease. Secondly the token supply can be split on two different networks to get the best out of two networks.

Non-Goals

The scope of this standard is limited to on-chain functionality for token transfer on two different networks. This standard does not address how cross-chain token movements should be reflected on third party services or tools such as blockchain explorers, wallets or exchanges.

Success Metrics

There are two key indicators of success for this standard: 1) Number of contract deployments with bridge functionality 2) Number of Bridge operator contracts deployed for cross-chain movements

Description

Fungible tokens have proven to be one of the core building blocks of the current decentralized web era. Most of the tokens are tied up in the network they have been issued.

The bridge operator provides a core ability to perform cross chain token transfer across a different blockchain network of which ecosystem allows to reap the benefits not available on source chain. The Aion token standard or ERC-20 controller achieve this function by maintaining security and stable token supply and choosing whom to appoint as bridge operator.

This standard aims to provide a reliable interface that can be implemented by any token issuer if they want to act as bridge operator by themselves or any trusted 3rd party looking to support bridge functionalities.

High-Level Architecture

This diagram provides a high-level overview of the proposed bridge operator contract architecture related to tokens to enable cross-chain movements.

Note: The scope of this AIP is limited to the bridge operator contract highlighted. In the diagram.

bridge-operator

Specification

Definitions

Bridge Operator: An organization(s) / project (s) / account that execute the required functions to enable a cross-chain transaction on behalf of the token holder
Bridge Registry: A smart contract registry that maintains a mapping of bridgeId, Bridge Contracts and networkId
Bridge Contract: A smart contract designed to receive, verify and emit events and signature bundles from/to a specific bridge
Token Issuer: The project / user / account that owns the Token Contract
Token Contract: A smart contract that is deployed using this token standard
Token Holder: An account / user that has ownership over a token balance
Token Sender: An account / user that is sending a token
Token Receiver: An account / user that is receiving a token
source chain: The blockchain network where the cross-chain transaction originates and is emitted from
destination chain: The blockchain network that is the destination for the cross-chain transaction

Methods

Validator Interface

The constant functions detailed below MUST be implemented.

isValidator function

Returns true/false for a validator's address.

returns: boolean.

    function isValidator(address validator) constant returns (bool);

validatorCount function

Returns the number of validators participating in bridge operation.

returns: number.

    function validatorCount() constant returns (uint128);

minimumValidatorApproval function

Get the minimum number of validators required to thaw tokens on destination network.

returns: Minimum validator count.

    function minimumValidatorApproval() constant returns (uint128);

initializeValidatorGroup function

Bridge operator decides the number of independent validators and initializes the bridge.

NOTE: initializeValidatorGroup(address[]) should be accessed when a bridge operator contract does not have any validators assigned, otherwise fails.

parameters
validators: List of addresses of validator accounts.

The following rules MUST be applied regarding the initializeValidatorGroup:

The list of validators values MUST be unique at creation time.
The validators cannot be reinitialized if there exists a validator

    function initializeValidatorGroup(address[] validators) public;

addValidator function

The bridge operator adds additional validator after initializing the bridge.

The following rules MUST be applied regarding the addValidator:

The validator value MUST be unique.
If previously added validator exists revert
If validator is added successfully, emit an event AddedValidator

    function addValidator(address validator) public;

removeValidator function

The bridge operator can remove validator in case of they do not want to participate in process or cannot be trusted further.

The following rules MUST be applied regarding the removeValidator:

The validator value MUST exists.
If validator exists, it is removed
If validator is removed successfully, emit an event RemovedValidator

    function removeValidator(address validator) public;

Solidity Interface

interface ValidatorInterface {
    function initializeValidatorGroup(address[] validators) public;
    function addValidator(address validator) public;
    function removeValidator(address validator) public;
    function isValidator(address validator) constant returns (bool);
    function validatorCount() constant returns (uint128);
    function minimumValidatorApproval() constant returns (uint128);

    event AddedValidator(address validator);
    event RemovedValidator(address validator);
}

Bridge Operator

A bridge operator is an address which is allowed to thaw tokens on destination network when an independent validator confirms that the token holder has frozen her token on the source network.

The following rules apply to any bridge operator:

The token contract configures an address of bride opeartor to provide cross chain token movement.
The token contract disables freeze functionality when bridge operator is not configured.
If a failure happens while processing a bundle, the bridge operator marks the failure for all transfers and they MUST be reverted
The token contract MUST emit a Thaw event with the correct values when a token contract successfully executes thaw [Thaw Event].
The bridge operator contract MUST emit a Distributed event with the correct values when a token contract successfully able to execute thaw [Distributed Event].
The bridge operator contract MUST emit a ProcessedBundle event with the correct values when a bridge operator makes the token contract to thaw for all transfer transactions as defined in the [ProcessedBundle Event].

NOTE: A token contract MAY have multiple operators at the same time.

NOTE: A token contract MAY configure additional operator. A BridgeOperatorSet MUST be emitted each time.

NOTE: A token contract MAY remove an already removed operator. A BridgeOperatorUnset MUST be emitted each time.

processBundle function

Bridge operator verifies that the required minimum validators have confirmed the bundle containing all token transfer transactions. The function iterates over all the signature parameters and decides whether to thaw from the token contact. If the bundle is successfully verified, it emits ProcessedBundle event with its correct parameters. If a bundle has already been previously verified and exist, it emits SuccessfulTransactionHash event with its correct parameter.

NOTE: These events MUST NOT be emitted elsewhere in the process.

parameters
sourceBlockHash: The block hash from the source chain.
recipients : The destination chain account address participating in transfer
amounts : The respective amount to be thawed by bridge operator.
r : The r component of a signature of Secp256k1 or public key of a signature of ED25519.
s : The s component of a signature of Secp256k1 or first 32 bytes of a signature of ED25519.
v : The v component of a signature of Secp256k1 or last 32 bytes of a signature of ED25519.

function processBundle(bytes32 sourceBlockHash,
        bytes32[] sourceTransactionHashes, address[] recipients, bytes32[] amounts,
        bytes32[] r, bytes32[] s, bytes32[] v) public;

setBundle function

Set a destination chain transaction hash in case of bundle is successfully processed. When a bundle is being processed, the solidity function does not have access to the transaction hash, so the relay can set the transaction hash after processing the bundle.

NOTE: The only bridge operator should be able to set the transaction hash.

parameters
bundleHash: The hash of the bundle.
transactonHash : The transaction hash of the processedBundle operation

function setBundle(bytes32 bundleHash, bytes32 transactonHash) public;

getBundle function

Given the hash of a bundle, retrive the transaction hash on destination network.

parameters
bundleHash: The hash of the bundle.

returns: transactionHash if a bundle has already been processed.

Distributed event

Indicate a distribution of amount of tokens to recipient address on destination chain.

parameters
sourceTransactionHash: Address of token recipient on source chain.
recipient: Number of tokens to thaw.
amount: Bridge to used for relaying transaction.

event Distributed(bytes32 sourceTransactionHash, address recipient, uint128 amount);

ProcessedBundle function

This event is emitted at the end of processing the bundle without an error.

NOTE: MUST emit ProcessedBundle event.

NOTE: MUST revert if not enough balance in bridge opeartor account.

parameters
sourceBlockHash: The block hash of the source chain.
bundleHash: The bundle hash of the current transfer.

event ProcessedBundle(bytes32 sourceBlockHash, bytes32 bundleHash);

SuccessfulTransactionHash function

Called by an operator to move tokens to destination chain on behalf of token holder.

NOTE: MUST emit SuccessfulTransactionHash event if the bundle has already been processed.

parameters destinationTransactionHash: The transaction hash on the destination chain thawing token to recipients.

event SuccessfulTransactionHash(bytes32 destinationTransactionHash);

Solidity Interface

interface BridgeOperatorInterface {
    function processBundle(bytes32 sourceBlockHash,
        bytes32[] sourceTransactionHashes, address[] recipients, bytes32[] amounts,
        bytes32[] r, bytes32[] s, bytes32[] v) public;
    function setBundle(bytes32 bundleHash, bytes32 _transactonHash) public;
    function getBundle(bytes32 bundleHash) constant returns (bytes32);

    event Distributed(bytes32 sourceTransactionHash, address recipient, uint128 amount);
    event ProcessedBundle(bytes32 sourceBlockHash, bytes32 bundleHash);
    event SuccessfulTransactionHash(bytes32 aionTransactionHash);
}

Logic

Cross Chain Functionality

To send a cross chain token transfer from the source chain to the destination chain, the sender must freeze the token on source chain and specify the destination chain and destination token receiver address using the freeze or operatorFreeze functions. The Bridge Contract then relays the transaction to the destination chain and thaws the appropriate token amount from destination chain token contract.

To send a cross chain token transfer from a destination chain to source chain, the sender must first freeze their destination tokens by sending them to the token contract and emitting an event which specifies the destination address on the source chain and the Bridge Contract to use. The Bridge Contract then relays the transaction to the source chain and calls the thaw function.

Risks & Assumptions

[ERC20] compatibility notes:
This standard assumes that token contract has cross chain functions available in ATS. In case of existing ERC20 tokens without this functions, a control contract must be created which adds cross chain functions.

Test Cases

N/A

Implementations

Reference Implementation

Dependencies

The implementation of token contract supporting cross chain functionality is mentioned in AIP-04.

Copyright

All AIP’s are public domain. Copyright waiver: https://creativecommons.org/publicdomain/zero/1.0/

aionnetwork / AIP