[dlc-dev] Support for non-corresponding multi-oracle DLCs
LE GUILLY THIBAUT
thibaut at cryptogarage.co.jp
Mon Feb 22 00:54:54 CET 2021
Hi Nadav,
Regarding Numeric Oracle, I think option 2 is the best, but I must say that
I don't really understand what option 1 is, in particular the second point.
Do you have an example to clarify this? And for option 2, it's not really
clear to me that there is a loss in security, in which sense do you mean
that?
For enumerated outcomes it's much less clear to me that this would be a
desired feature and I don't really have an opinion on which one is best.
Regards,
Thibaut
On Sat, Feb 20, 2021 at 6:22 AM Nadav Kohen via dlc-dev <
dlc-dev at mailmanlists.org> wrote:
> Hi all,
>
> One of the outstanding items that needs to be resolved as part of the v0
> milestone is support for multi-oracle DLCs where not all oracles involved
> have exactly corresponding outcome sets [1]. Let us consider Numeric
> outcome and Enumerated outcome oracles separately.
>
> *Numeric Oracle Options*:
> Differences can occur between numeric oracle outcome sets when oracles
> have non-equal num_digits and/or non-equal bases.
>
> 1. Use the smallest supported outcome set (intersection of all
> oracles' outcome sets).
> - Build CETs as usual but with extra prefixes where needed (such as
> leading zeros in the case that an oracle's num_digits is greater than the
> smallest num_digits).
> - Then separately build a set of CETs to cover all outcomes where
> the non-minimal oracles have more extreme outcomes than the minimal oracles.
> 2. DLC participants specify contract bounds and accept a weakened
> security model in edge cases.
> - Build CETs as usual but using max/min value for oracles if we
> require something from them that is out-of-bounds.
> - Client software should clearly communicate what the loss in
> security is to the client when bounds exceed some of the oracle's support
> (noting that you are still better than the situation where you just ignore
> minimal oracles altogether because you validate that they are signing
> max/min value).
> - A benefit of this scheme is it still allows users to choose
> options 1 or 3 if they prefer.
> 3. Use the largest possible supported outcome set (union of all
> oracles' outcome sets).
> - Constructed in the same way as option 2 if the largest possible
> bounds are chosen.
>
> I think Option 2 is superior to Option 3 as they both require the same
> amount of code to implement, but an argument could be made that Option 1 is
> a little simpler to implement than Option 2 while Option 2 is strictly more
> expressive than Option 1.
>
> *Enumerated Oracle Options*:
> Differences can occur between enum oracle outcome sets when oracles have
> non-equal enumerations.
>
> 1. Construct a meta-enumeration
> - Map each element of the meta-enumeration to all corresponding
> oracle-enum outcomes and then build a DLC around the meta-enumeration.
> 2. Directly construct a list of all allowed/agreeing outcomes
> corresponding to the future set of CETs
>
> I can't really think of many pros/cons/differences between these two
> approaches other than that the former seems to be more portable than the
> second.
>
> I'd be really interested in what people think will be the best approach
> for both of these cases before I start adding handling for these cases to
> the specification and the code!
>
> [1]
> https://github.com/discreetlogcontracts/dlcspecs/blob/master/v0Milestone.md#multi-oracle-support-for-non-corresponding-outcome-sets
>
> Best,
> Nadav
>
> dlc-dev mailing list
> dlc-dev at mailmanlists.org
> https://mailmanlists.org/mailman/listinfo/dlc-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/mailman/private/dlc-dev/attachments/20210222/0981ebd4/attachment.htm>
More information about the dlc-dev
mailing list