Replies: 5 comments
-
|
An example would help me in understanding this. Would this be a script checking the fanout transaction? Would this script also be used on the L2 to ensure it will be a valid fanout transaction? |
Beta Was this translation helpful? Give feedback.
-
|
@ch1bo yes and yes. The point is to add extra L1 validations, that are also enforced on L2. From a ledger perspective, you can really imagine an extra step composed with |
Beta Was this translation helpful? Give feedback.
-
|
Would this be done similarly to #370 and the validator would run on a hypothetical fanout of the resulting |
Beta Was this translation helpful? Give feedback.
-
|
That's how I imagine it so far indeed. |
Beta Was this translation helpful? Give feedback.
-
|
I still don't understand what the purpose of such a script would be and how exactly it would be applied. |
Beta Was this translation helpful? Give feedback.
-
Why
As for any protocol, Hydra comes with both limitations and guarantees. Those guarantees are good enough for a certain number of use-cases. Yet, the current setup lack of flexibility in the sense that users can't really adapt or enhance the protocol to fit a use-case which is almost addressed by the basic version of the protocol.
Being able to provide this flexibility without compromising on the security would open up new interesting use-cases for Hydra heads.
What
What if participants of the head were able to inject some extra validation logic to the head, such that it is also enforced on the layer 1, during de-commits / fanout.
Since heads provide isomorphic channels, it is possible to define a (Plutus) script to capture a set of extra verification to be applied on top of the already existing validations. A reference to this script can be recorded in the on-chain head state during the head initialization, and executed / spent during the fanout transaction. The piece of logic inside the script would be completely opaque to the head contract itself, and completely user-defined. This could allow for instance to enforce that a certain committed UTxO can only be spent in the L2 given some pre-defined conditions.
In such a scenario, participants are all aware of the extra validations (which they confirm implicitly by committing, unless they do no recognize the reference script mentioned in the init transaction). Off-chain, the same script can be executed after each transaction validation to ensure that accepting a transaction would still yield to a valid transition on the L1.
We'd call such script a Plugin as it provides a non-intrusive and flexible way to enrich a head with extra validation logic, and thus, from a client perspective, extra guarantees to reason about. The validation of the script is almost completely off-loaded to the L1. The head on-chain validations (OCV) must only ensure that, when applicable, the input referenced during initialization must also be spent during the fanout transition.
Beta Was this translation helpful? Give feedback.
All reactions