Skyhook
SkyhookStart here

Introduction

Skyhook is a protocol that lets a smart contract on Ethereum, or on any other Turing-complete blockchain such as Solana, act on a payment made in shielded Zcash. The contract does not trust a custodian, a bridge operator, or a validator committee to report the payment. Instead, it rebuilds the Zcash transaction identifier from the parts it needs to check and confirms that a block containing that transaction was mined and is final. The note being spent and the address that signs for it stay private throughout. Until Milestone 3, the recipient’s address, its public key, is visible on Ethereum; no viewing key is involved at any point, and an address cannot decrypt any transaction (why that matters).

Skyhook and the Skyhook Bridge

Two names appear throughout this site, and they mean different things. Skyhook is the mechanism, together with its implementation: the way a contract on another chain recognizes that a specific shielded Zcash payment was made and is final, without trusting anyone to report it. The Skyhook Bridge is one application of that mechanism: a protocol for trustless swaps between shielded ZEC and assets on other chains, with its own escrow contracts, pricing, liquidity and programmable payouts. The bridge is the application this grant completes, but it is not the only thing Skyhook can do.

Because Skyhook only proves that a shielded payment of a given value reached a given address, any contract can build on it. Beyond swaps, it makes possible smart-contract actions triggered by a shielded payment, such as minting a token or an NFT; contracts that accept ZEC to an address of their own, including wrapped tokens whose deposits need no one’s approval; and further extensions that use the same check in other ways. The simplest of these, Pay-to-Smart-Contract, already works: any contract can accept shielded ZEC to an address of its own and act on the amount paid, reusing an existing deployment’s finality.

Skyhook is being developed by Strahn Cryptography, and a beta of the Skyhook Bridge that swaps Sepolia ETH for testnet ZEC (TAZ) has been operated publicly by members of the Zcash community forum.

Background

Skyhook completes an idea almost as old as Zcash. In January 2017, Zcash’s founder Zooko Wilcox-O’Hearn proposed cross-chain atomic transactions, or XCAT, between Zcash, Bitcoin and Ethereum, as part of an effort called Project Alchemy.1 Later that year Zcash engineers demonstrated XCAT swaps between ZEC and bitcoin using hash time-locked contracts, but only between transparent addresses: a time-locked contract needs a script on both chains, and shielded Zcash transactions have none.2

Project Alchemy’s other half was a Zcash light client on Ethereum, in the style of BTC Relay, with Zcash’s Equihash proof-of-work verified in Solidity.3 Checking Equihash means computing hundreds of BLAKE2b hashes, far too expensive on the EVM at the time, so the effort proposed a precompiled BLAKE2b compression function for Ethereum. It became EIP-152 and went live in Ethereum’s Istanbul upgrade in 2019.4 Skyhook’s Equihash verifier calls that precompile for every hash it computes, 513 times for each block it checks.

The last piece came with ZIP 244, by Kris Nuttycombe, Daira-Emma Hopwood and Jack Grigg, activated in NU5 in 2022, which made a transaction’s identifier a tree of BLAKE2b hashes.5 A tree can be checked from a few revealed values and the hashes of everything else, and that is how a Skyhook contract confirms a shielded payment without learning who sent it. Three decisions made years apart, Zcash’s use of BLAKE2b (which Zooko co-designed), the BLAKE2b precompile on Ethereum, and tree-structured transaction identifiers, are what make it possible to finish what Project Alchemy started, and to do it for shielded payments rather than transparent ones.

Why “Skyhook”

The name comes from a proposed way of reaching orbit without a full rocket. A skyhook is a long tether rotating in orbit: once per rotation its tip dips low, catches whatever craft is waiting at the pickup point, and swings it up to orbit. A craft that misses the tip waits for the next pass.

Skyhook’s rollups work the same way. Transactions wait with their payment made; the next rollup sweeps past and finalizes every one that is ready, lifting it from Zcash into a contract on another chain. A transaction that just misses a rollup can wait for the next, or launch itself with one-shot finality.

A swap, step by step

The simplest application, and the one the Skyhook Bridge implements, is a swap between two people. Alice holds ETH and wants shielded ZEC; Bob, a liquidity provider, holds shielded ZEC and wants ETH.

  1. Alice locks her ETH in a Skyhook Bridge contract on Ethereum. The lock states what the contract expects in return: an amount of ZEC, paid to Alice’s shielded address.
  2. Bob sends Alice that ZEC in an ordinary shielded Zcash transaction.
  3. Bob gives the contract the values he used to build that transaction that the contract needs to check, such as the amount, Alice’s public key and diversifier, and the nullifier. The rest of the transaction reaches the contract only as opaque hashes.
  4. The contract hashes these values together. If they combine to the transaction identifier of a transaction that Zcash miners included in a block, and that block is final, the contract releases Alice’s ETH to Bob.

The contract can rely on this because of how Zcash computes transaction identifiers. Since ZIP 244, a transaction identifier is the root of a tree of hashes. Changing any value in the transaction changes the root, so a transaction that differs from the one Bob actually sent, in amount, recipient or anything else, has a different identifier, and no block will ever contain it. Values the contract does not need to inspect can stay folded into their branch hashes, which is what keeps the sender private.5 How It Works explains this with a worked example.

Finality

Knowing that a transaction is in some block is not enough. Bob could try to mine a private block containing a transaction that the real Zcash network never accepted, or the block holding his payment could be replaced during a chain reorganization. Skyhook therefore requires proof that the block belongs to the main Zcash chain and is buried deeply enough to be final. Skyhook provides this proof through rollups: bundles of Zcash blocks that anyone can build, which include the blocks following the payment’s block and FlyClient samples of the history behind it. FlyClient is a super-light-client protocol by Bünz, Kiayias and Leonardos whose commitments Zcash already includes in its block headers.6 Transactions waiting for finality join a rollup and share its cost, and a swap can also finalize its own rollup in one transaction. No stakers, committees or votes are involved. See Chain Finality.

Organization of this site

The design is documented in six sections:

  • Chain Finality covers how the contract decides that a Zcash block is final, and how it verifies Equihash proof-of-work on the EVM.
  • The Contracts describes the Ethereum contracts: the life of a swap, the two ways counterparties agree on a price, and lock-scripts.
  • The Zcash Side covers notes, the Ironwood transaction format, and the software that builds and scans transactions.
  • ESMASTe describes the virtual machine that executes lock-scripts on Ethereum.
  • Roadmap sets out the six funded milestones, what each has already built, and how reviewers accept them.
  • Ideas collects unfunded future directions.

The Glossary defines the terms used throughout, and References lists the specifications and papers the design relies on. The official grant application is reproduced unchanged.

See also

References

  1. Zooko Wilcox-O’Hearn, “Cross-Chain Atomic Transactions / Project Alchemy / Stellar”, Zcash Community Forum, January 2017. ↩

  2. “Zcash continues work on atomic trades between ZEC and bitcoin”, CryptoNinjas, September 2017, reporting the XCAT demonstration by Ariel Gabizon and Jay Graber and its support for transparent addresses only. ↩

  3. Project Alchemy, ConsenSys: a BTC Relay–inspired Zcash light client for the EVM, with BLAKE2b and Equihash in Solidity. ↩

  4. EIP-152: a precompile for the BLAKE2 compression function F, motivated by verifying Zcash’s Equihash on Ethereum. ↩

  5. ZIP 244: Transaction identifiers as digest trees. ↩ ↩2

  6. Bünz, Kiayias and Leonardos, FlyClient: Super-Light Clients for Cryptocurrencies, IEEE S&P 2020; history commitments specified in ZIP 221. ↩