This is indeed a possible variation on the OTX design, but it certainly comes with its own implications:
- What shall really be the smallest granularity supported here? CellInput has OutPoint and since fields, while OutPoint might make sense to be the smallest entity, since could be further divided into pieces? Do we want to support the case that only epoch-based since value is used? Or does OTX needs to be expressive to explain the fact that any value that is later than 500,000 block can be used? In addition, it is not enough to simply split a script into
code_hash
,hash_type
, andargs
. Do we need to consider the scenario where anyhash_type
later thandata1
? Or does it make sense for an OTX to only cover the first 20 bytes ofargs
? Or[4..8)
inargs
? And let’s go still one step further: does it make sense for an OTX to only define the lock script for a particular input cell? There is a pretty deep rabbit hole waiting for us. - Another problem here, is that the security assumption might also change if an OTX only defines certain part of a cell. Assuming an OTX only guards the type script & cell data, what if the OTX agent assembles the OTX using an always-success lock, or a lock that cannot be unlocked? What if someone tries to steal the CKBytes for an OTX that does not lock the capacity part?
Of course we could add all kinds of validation rules, supporting finer granularity, but that would pretty much lead us back to previously tried paths:
- Exploring the CKB OTX Paradigm: Accomplishments and Insights from Building a Transaction Streaming Prototype
- RFC: Composable Open Transaction Lock Script
One big rationale behind the OTX Cobuild protocol, is that we want to use a complete cell as the smallest entity in OTX apps. Yes I’m fully aware of the implications, and the fact that this might not be as flexible as previous designs, but it will be easier to reason about OTX apps now. Given a full cell, you will know exactly what an OTX want to achieve, the ambiguity will be reduced to a minimum state, one does not need to think about the complications when OTX guards only part of a cell.
I do agree that in later designs, we might end up adding support to finer-grained guards like discussed here. But personally I am not sure if we want to be as expressive as we can in the first version of OTX design. I do feel safer when we are only dealing with complete cells at the moment, at least till we know more about the implications of OTXs in a real-world setting.