Bridge Validator

The transactions and information that each each Validator verifies depends on the governance group to which it belongs. They perform verification based on the block data of each chain according to the

Verification Process

Verification of transactions with Vaults

• Verifies that the transaction object data (transaction hash, block number, method, parameter, memo ... ) sent to a Vault matches the data passed to OrbitHub or BridgeContract.

• Data to be verified

  • Block Confirmation. ( ex, ETH & KLAYTN : 24 block confirmation )

  • Verification that relayed data by operator and Deposit event data in transaction are the same.

Verification of transactions with Minters

• Verifies that the transaction object data (transaction hash, block number, method, parameter, memo ...) sent to a Minter matches the data passed to OrbitHub or BridgeContract.

• Data to be verified

  • Block Confirmation. ( ex, ETH & KLAYTN : 24 block confirmation )

  • Verification that relayed data by operator and RequestSwap event data in transaction are the same.

Verification for the execution of transactions to each destination chain is carried out in a transaction consensus process.

• For Tendermint affiliates, consensus is required prior to signing transactions of fee and sequence information. Thus, Validators verify that the actual transaction signature transfer fee is appropriate and sequence can be executed.

Verification Hash

Used to prevent double spending

Swap & RequestSwap Hash

bytes32 hash = sha256(abi.encodePacked(hubContract, fromChain, toChain, fromAddr, toAddr, token, bytes32s, uints));

Used as verification hash to execute Minting or Release.

• address hubContract : Orbit Hub Contract Address

• string fromChain : Chain Symbol requesting bridging.

• string toChain : Chain Symbol to execute bridging.

• bytes fromAddr : Address of the chain requesting bridging.

• bytes toAddr : Address of chain to execute bridging.

• bytes token : Token Information to be executed bridging.

• bytes32[] bytes32s : Bytes32 data array used in the bridging consensus process.

  • index 0 : Governance Identifier.

  • index 1 : Transaction Hash of fromChain.

• uint[] uints : Uint data array used in the bridging consensus process

  • index 0 : Token Amount to be executed bridging.

  • index 1 : Token Decimal to be executed bridging

  • index 2 ( optional ) : Unique Identifier for Requesting Bridging ( ex, depositId in ETH, KLAYTN )

Subscribe Orbitchain

• Validator should subscribe OrbitChain's new block and detect SwapRelay event

event SwapRelay(string fromChain, string toChain, bytes fromAddr, bytes toAddr, bytes token, bytes32[] bytes32s, uint[] uints);

Verification Detail for SmartContract based transaction

• Supported chains : Ethereum, Klaytn, Icon

• Events detail of Vault / Minter contracts

event Deposit(string fromChain, string toChain, address fromAddr, bytes toAddr, address token, uint8 decimal, uint amount, uint depositId, uint block);
event SwapRequest(string fromChain, string toChain, address fromAddr, bytes toAddr, bytes token, address tokenAddress, uint8 decimal, uint amount, uint depositId, uint block);

• Pre-defined in launch-governance settings

  • address hubContract : SwapRelay event must be from hubContract address

  • bytes32 bytes32s[0] : verify Governance Identifier validator's own id.

• Get transaction from Vault / Minter chain using bytes32 bytes32s[1]

• Parse event and compare params with SwapRelay event

  • string fromChain

  • string toChain

  • bytes fromAddr

  • bytes toAddr

  • bytes token

  • uint[] uints[0:2] : Must be equal to amount, decimal and depositId in array order.

• Hash two variables from the beginning of an bytes32[] bytes32s

• Hash three variables from the beginning of an uint[] uints

Verification Detail for Terra transaction

Mint token to other chains

• Sample Transaction. HERE

• Pre-defined in launch-governance settings

  • address hubContract : SwapRelay event must be from hubContract address

  • bytes32 bytes32s[0] : verify Governance Identifier validator's own id.

• Get transaction from Terra node using bytes32 bytes32s[1]

• Verify transaction exist and succeeded

• Filter messages that meet the message type bank/MsgSend and send to vault address

• Verify vault address same with SwapRelay event's bytes fromAddr

• Verify filtered messages's token denom and amount of token same with SwapRelay event

  • bytes token

  • uint uints[0]

• Parse memo in JSON format and compare with SwapRelay event

  • string toChain

  • bytes toAddr

• uint uints[1] value must 6

• Hash two variables from the beginning of an bytes32[] bytes32s

• Hash three variables from the beginning of an uint[] uints

Release token to Terra address

• Typically, verify release of tokens takes place in the minting chain.

• But, don't support COSMWASM yet, additional step needed for build Terra transaction

• Events will be validated

event TransactionSuggested(bytes32 govId, uint suggestIndex);
event TransactionSelected(bytes32 govId, uint selectionIndex);

• Verification transaction suggest

  • Get orbitchain suggestion data object using Governance Identifier, suggestIndex (use pre-defined gov id in launch-governance)

  • Get orbitchain swap data object(include swapDataArray) using Governance Identifier, suggest data's uint uints[0]

  • Verify vault have sufficient funds. have more than swapDataArray's uint uints[0]

  • Verify suggestion's gas properly estimated

  • Verify suggestion's fee properly estimated

  • Verify suggestion's sequence same with vault address's sequence

  • Build hash

bytes32 hash = sha256(abi.encodePacked(address(this), govId, suggestIndex, s.uints, s.signatureHash));