bitSmiley
commented
1 month ago 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_ENDIFThe 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-jslibrary (1 week). - Addition of
GetBtcEventWithTapscriptmethod:- 2 weeks for development + unit testing
- 1 week for integration testing + additional documentation
lumtis
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.