HASHI-XTF

XTF is a protocol that enables the creation of crypto ETFs. It divides the large ETF asset pool into smaller vaults to facilitate manageable deposits. Once a vault receives all assets across various blockchains, it mints ETF share tokens for that crypto index. The process can be reversed, and users holding sufficient ETF share tokens can exchange them for the underlying assets of a completed vault. A cross-chain protocol communicates deposit activities on sidechains to the mainchain, where ETF tokens are issued, and simultaneously instructs the sidechains to release assets when a vault is burned using ETF share tokens, facilitating the exchange for the underlying assets. The protocol is fully customizable, enabling users to select the optimal trade-off between performance and security. Users can choose which blockchains, oracles, and bridge technologies to use for their crypto ETF, adapting the system to meet their investors' requirements.

In this hackathon, we tested the possibility of having an extra layer of security for cross-chain communication. We implemented a more secure and robust version of the BURN operation utilising HASHI. Users can now adjust security settings to enable multiple bridges to confirm the burn operation from the mainchain across all sidechains. Upon completing the burn on the mainchain, the user receives block information and proof of its "burn" 's inclusion. The user then instructs HASHI reporters to distribute this information (the blockhash for block number) to all sidechains. On the sidechain, HASHI receives all hashes and verifies their consistency. The user then invokes the new burn (safe_burn), providing the block proof of the burn on the mainchain. This validates that the proof's block is the same as agreed by HASHI and further checks the burn was part of the specified block before the assets on sidechains are released.

This process introduces an additional layer of confidence in operations conducted on the main chain. While it can slow communication, setting the right threshold can enhance reliability. With a threshold of n out of m bridges, users only need n operational bridges, making the system more fault-tolerant.

We wanted to run a full end-to-end demo. However, no bridges between Chiado and Sepolia were available, especially since Goerli has been deprecated and Sepolia does not host a HASHI instance.

To address this, we create a script to deploy a custom Hyperlane bridge, including validators and relayers, to link Chiado with Sepolia. The chain details and the security model used are outlined in chains.yaml and ism.yaml (https://github.com/GaetanoMondelli/GNOSIS-XTF/blob/main/bridge/configs/chains.yaml). The script initialise_bridge.sh, handles the installation of necessary dependencies such as Rust, Hyperlane core, and CLI and sets up a minimal bridge architecture with two validators (one for each chain) and a relayer: https://github.com/GaetanoMondelli/GNOSIS-XTF/blob/15f0566040cbb24d2bf33cf3d8b3ccc22d2cb20b/initialise_bridge.sh#L80.

In addition, we deployed all necessary HASHI contracts on both networks using the 00_deploy_etf.ts (https://github.com/GaetanoMondelli/GNOSIS-XTF/blob/main/packages/hardhat/deploy). Because the deployment requires multiple actions on different chains, I have documented the steps and the npm actions that must run in the repo Readme (https://github.com/GaetanoMondelli/GNOSIS-XTF/blob/main/README.md).

Further setups include the deployment script 02_deploy_hashi.ts, which establishes a separate HASHI instance for initial testing and later used for manually dispatching blocks through a custom Hyperlane Reporter https://github.com/GaetanoMondelli/GNOSIS-XTF/blob/58607b53baa3f293888abc28f02c7c5571d4dca0/packages/hardhat/deploy/02_deploy_hashi.ts#L42. Another script, 03_deploy_getProofRPC.ts, retrieves storage proofs from blocks, which is essential for the secureBurn function https://github.com/GaetanoMondelli/GNOSIS-XTF/blob/58607b53baa3f293888abc28f02c7c5571d4dca0/packages/hardhat/deploy/01_test_getProofRPC.ts#L236.

The main contract, ETFIssuingChain, is configured to meet the specific needs of each chain. On the mainchain (Chiado), it tracks deposit states across all chains for the ETF, whereas on sidechains, it only monitors its deposits. Additionally, it informs the mainchain about these deposits and releases assets upon receiving a corresponding message from the mainchain..https://github.com/GaetanoMondelli/GNOSIS-XTF/blob/main/packages/hardhat/contracts/ETFIssuingChain.sol The contract was initially designed exclusively for the mainchain but was later adapted to function across both chains. Communication via the bridge involves the 'handle' function, which transmits messages regarding deposits on sidechains and vault burnings on the mainchain. In this implementation, the trivial burn through a message to the sidechain was disabled (https://github.com/GaetanoMondelli/GNOSIS-XTF/blob/58607b53baa3f293888abc28f02c7c5571d4dca0/packages/hardhat/contracts/ETFIssuingChain.sol#L372). The basic functioning of the ETF can be seen in the test file at https://github.com/GaetanoMondelli/GNOSIS-XTF/blob/main/packages/hardhat/test/ETFIssuingChain.ts.

Initially, the ETF contract was designed to notify reporters automatically in this new implementation. However, this approach would have necessitated storing the block number of each burn to enable subsequent block dispatches, adding a step to the process anyway. In our demo, we simplified the process by having users manually retrieve the block number and invoke the dispatcher themselves. However, to enhance user experience and maintain consistency, we aim to automate these interactions in future iterations. This will make the HASHI implementation more transparent and user-friendly, with plans to integrate these improvements directly into the UI. To ensure smooth operations and practical demonstration of each step in the demo, we utilised Scaffold's debug react view page, enabling direct interaction and seamless verification processes during the demo.

The Proof validation happens in the 'Prover.sol' contract (https://github.com/GaetanoMondelli/GNOSIS-XTF/blob/main/packages/hardhat/contracts/Prover.sol) . The code for proverSlotZero was adapted from the GHO-fragola project (https://github.com/crosschain-alliance/gho-fragola), simplifying the verification process. We removed the nonce check as our operations are idempotent. For the storage proof, instead of calculating a slot from a nested map, we simplified it by having a commitment variable stored in the slot at position 0. 'abi.encodePacked(keccak256(abi.encodePacked(uint256(0))))' https://github.com/GaetanoMondelli/GNOSIS-XTF/blob/58607b53baa3f293888abc28f02c7c5571d4dca0/packages/hardhat/contracts/Prover.sol#L105.

The commitment stores a binary map of all the burned vaults (https://github.com/GaetanoMondelli/GNOSIS-XTF/blob/58607b53baa3f293888abc28f02c7c5571d4dca0/packages/hardhat/contracts/ETFIssuingChain.sol#L154) We understand that this design may incur some race conditions, which require a new iteration to have more complex and secure proofs.