Isomorph
- date: 2023-02-24
- last updated: 2023-02-24
Overview
Isomorph is a Zero Knowledge trustless multichain bridge.
Approach
Sample Process Flow
At a high level when an event happens on chain 1 we want to trigger a corresponding action on chain 2.
For a simple bridging of funds this looks as follows
- Alice deposits 100 TokenX into TokenLocker on Chain 1 (which are locked) **a1
- A transaction t1 is triggered in Block b1 and an event e1 is sent
- The relayer listens to event e1 and relays the transaction receipt information to Chain 2.
- Verifier verifies that t1 is in block b1
- Verifier verifies that block b1 is a valid block
- Verifier verifies that b1 is in Chain1 canoninical chain
- Executor1 triggers a minting of corresponding 100 TokenX∆ on TokenLocker∆ on Chain 2
- A transaction t2 is triggered in Block b2 and an event e2 is sent
- The relayer listens to event e2 and relays the transaction receipt information to Chain 1.
- Verifier verifies that t2 is in block b2
- Verifier verifies that block b2 is a valid block
- Verifier verifies that b2 is in Chain2 canoninical chain
- Executor2 marks the bridge transaction as complete
Proof Components
- Valid Signers : Who are eligible to sign
- Valid Signature:
- Valid Block : (Epoch)
Technology
- TokenLocker: horizon txProof.js npm EthProof
- TransactionVerify: Proves a Merkle Patricia Trie using merkle Proof which verifies the Transaction.Hash against Header.txHash. Here is an example from horizon using horizon txProof.js which calls npm EthProof.
- BlockSignatureVerification
- On Chain Verification : example is Near Rainbow Bridge Fraud Proof
- Optimistic
- Secure Enclave
- Zero Knowledge
- Prover
- Verification
- BlockCanonicalVerification
- Wait Number of Blocks
- Optimistic
- Light Client (Finality Gadgets)
- Finalized Epoch
- EventLister
- Executor
Proving Mechanisms
Avalanche
Binance
Cosmos
Ethereum
NEAR
The leading NEAR Ethereum Bridge today Near Rainbow Bridge uses an optimistic approach. Following is an excerpt from NearOnEthClient 1.
we adopt the optimistic 2 approach where NearOnEthClient verifies everything in the NEAR header except the signatures. Then anyone can challenge a signature in a submitted header within a 4-hour challenge window. The challenge requires verification of a single Ed25519 signature which would cost about 500k Ethereum gas (expensive, but possible).
Harmony
Polygon
Polkadot
Previous proving mechanisms for Polkadot leverage BEEFY (Bridge Effiency Enabling Finality Yielder) 3 an example is Snowbridge 4 which developed their own Interactive Update Protocol 5.
Verification Mechanism
Relayer Mechanisms
Token Lockers
References
Appendices
Appendix F: Data Structures
- Block Structure from go-ethereum
// SealHash returns the hash of a block prior to it being sealed.
func (ethash *Ethash) SealHash(header *types.Header) (hash common.Hash) {
hasher := sha3.NewLegacyKeccak256()
rlp.Encode(hasher, []interface{}{
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,
})
hasher.Sum(hash[:0])
return hash
}
- Transaction structure from go-ethereum
type Transaction struct {
data txdata // Consensus contents of a transaction
time time.Time // Time first seen locally (spam avoidance)
// caches
hash atomic.Value
size atomic.Value
from atomic.Value
}
type txdata struct {
AccountNonce uint64 `json:"nonce" gencodec:"required"`
Price *big.Int `json:"gasPrice" gencodec:"required"`
GasLimit uint64 `json:"gas" gencodec:"required"`
Recipient *common.Address `json:"to" rlp:"nil"` // nil means contract creation
Amount *big.Int `json:"value" gencodec:"required"`
Payload []byte `json:"input" gencodec:"required"`
// Signature values
V *big.Int `json:"v" gencodec:"required"`
R *big.Int `json:"r" gencodec:"required"`
S *big.Int `json:"s" gencodec:"required"`
// This is only used when marshaling to JSON.
Hash *common.Hash `json:"hash" rlp:"-"`
}
FootNotes
NEAR
Polkadot
Footnotes
-
NEAR: ETH-NEAR Rainbow Bridge: a bridge, called Rainbow Bridge, to connect the Ethereum and NEAR blockchains. ↩
-
Optimistic Contracts: contracts that accept all information as fact until proven to be non-factual. This allows for a reduction in the cost of verifying data, as on-chain verification would only be necessary when one is sure that the data is false. ↩
-
Polkadot: BEEFY: The BEEFY (Bridge Effiency Enabling Finality Yielder) is a secondary protocol to GRANDPA to support efficient bridging between the Polkadot network (relay chain) and remote, segregated blockchains, such as Ethereum, which were not built with the Polkadot interchain operability in mind. ↩
-
SnowBridge: Polkadot Verification: use Polkadot’s BEEFY gadget to implement an efficient light client that only needs to verify a very small subset of relay chain validator signatures. ↩
-
Snowbridge: Interactive Update Protocol: A prover wants to convince a light client that at least
of validators signed a statement, which they claim that a specific set of at least of validators do. ↩