Add support for passing data from Bitcoin as inscriptions

[fadeev]

Is your feature request related to a problem? Please describe.

Currently, ZetaChain supports passing data using the op_return opcode, which has an 80-byte limit. This limitation restricts the amount of data that can be included in cross-chain transactions, posing challenges for applications that require more data, such as omnichain NFTs and complex smart contract interactions.

Describe the solution you'd like

To address this limitation, we propose adding support for passing data as inscriptions. Inscriptions allow for longer messages by utilizing the witness portion of a Bitcoin transaction, enabling applications to include more comprehensive data.

Inscriptions involve wrapping data into a Taproot script and injecting it into the witness portion of a Bitcoin transaction. This process allows for data pushes up to 520 bytes, and larger data files can be managed through multiple data pushes. Creating an inscription requires a commit transaction (hash reference) and a reveal transaction (revealing the entire script).

We propose maintaining support for both op_return and inscriptions. The advantage of op_return is that it allows for a single transaction, making it simpler and potentially less costly for users. On the other hand, inscriptions support longer messages, providing more flexibility for applications that need to pass larger amounts of data. A user-facing app could potentially choose which method to use depending on the length of the data being passed.

### Tasks
- [ ] https://github.com/zeta-chain/node/issues/2728
- [ ] https://github.com/zeta-chain/node/issues/2759
- [ ] https://github.com/zeta-chain/node/pull/2524
- [ ] https://github.com/zeta-chain/node/pull/2533
- [ ] https://github.com/zeta-chain/node/pull/2727
- [ ] https://github.com/zeta-chain/node/issues/2534

[bitSmiley]

Zetachain Extending EVM Calldata Size From Bitcoin

Introduction

Currently btc to zeta ominchain call cannot contain arbitrary long evm contract call data length. The current limit is 80 bytes and this is probably too much of a restriction.

From a technical point of view, this comes from BTC "OP_RETURN" opcode that allows only 80 bytes.

This document proposals a possible solution to extend to a larger calldata size by utilizing tapscript based solution, very much like inscription.

Tapscript

Similar to inscriptions used, this approach makes use of the tapscript in bitcoin. Unlike inscription, the current protocol does not have as many attributes, with just the raw hex bytes. To be more specific, the script looks as follows:

OP_FALSE
OP_IF
  OP_PUSH 0x...
  OP_PUSH 0x...
OP_ENDIF

The caller will first makes a "commit" script that hashes the tapscript, then makes a "reveal" script that reveals the tapscript. The protocol does not import on the number of inputs of the reveal transaction, but the number of outputs should just be 1 and targeted to the specific recipient address with value more than the minimal fee. It is possible to have multiple outputs, but keep things simple for now.

The indexer will have to listen to transactions with output targeting TSS address. Once a tapscript is detected, it will concat the bytes in OP_PUSH into one large bytes array and this is the arbitrary call data.

So with the above change, a new method is proposed GetBtcEventWithTapscript:

func GetBtcEventWithTapscript(
	rpcClient interfaces.BTCRPCClient,
	tx btcjson.TxRawResult,
	tssAddress string,
	blockNumber uint64,
	logger zerolog.Logger,
	netParams *chaincfg.Params,
	depositorFee float64,
) (*BTCInboundEvent, error) {
  // a call to existing method first
  event, err := GetBtcEvent(...);

  if event != nil {
    return event, nil;
  }

  if len(tx.Vout) > 0 {
    return tryParseTapscript(...);
  }

  return err("ignore charity txn")
}

There should be no other changes to existing code.

Deliverables and Timeline

There are two major deliverables:

• A typescript/nodejs library/example for creating the commit and reveal txns based on bitcoin-js library (1 week).
• Addition of GetBtcEventWithTapscript method:
  • 2 weeks for development + unit testing
  • 1 week for integration testing + additional documentation

[lumtis]

@bitSmiley thank you for sharing this solution

Just a note on the testing side, our general process for new feature and for validation is to introduce a E2E test. You can see more info on this in this doc: https://github.com/zeta-chain/node/blob/develop/docs/development/LOCAL_TESTING.md

For example, a test_bitcoin_deposit_with_tapscript.go can be introduced for the E2E test.

[bitSmiley]

@lumtis Thx for the tip, I will check them out first. Will take some time to try it.

[bitSmiley]

With the above two PRs merged, the next step is really carrying out integration testing in btc networks:

• [ ] BTC regtest
• [ ] BTC mainnet: actually the inscription transactions were created, just the listener not tested