docs(anoncomms): Dispute mechanism spec for Logos Oracle Zone - #390
Open
seugu wants to merge 2 commits into
Open
docs(anoncomms): Dispute mechanism spec for Logos Oracle Zone#390seugu wants to merge 2 commits into
seugu wants to merge 2 commits into
Conversation
seugu
changed the title
seugu
marked this pull request as draft
August 3, 2026 06:35
sydhds
reviewed
Aug 21, 2026
| Membership of the active oracle set determines which `oracle id`s submit observations that indexers will accept. | ||
| Membership is also the basis of incentivization. | ||
| To join, an `oracle node` MUST bond stake in a LEZ contract and register its `oracle id` in the membership tree held in LEZ.Registration is a LEZ-only operation and does not require a cross-zone write into the Oracle Zone. | ||
| To join, an `oracle node` MUST bond stake in a LEZ contract and register |
There was a problem hiding this comment.
A bit out of context, but at some point, we might need to define what an oracle node need to stake
| | Heartbeat / round cadence | `R_round` | 1 block (`~30 s`) | Defined in block-height terms; must be `>= T_block`. | | ||
| | Dispute window | `W_dispute` | 3 Bedrock blocks (`~90 s`) | Time a proposed price waits for a dispute before it finalizes. | | ||
| | Heartbeat / round cadence | `R_round` | 1 Bedrock block (`~30 s`) | Defined in block-height terms; must be `>= T_block`. | | ||
| | Dispute window | `W_dispute` | 90 LEZ blocks (`~90 s`) | Time a proposed price waits for a dispute before it finalizes. | |
There was a problem hiding this comment.
90 LEZ blocks == 90s? What's the diff between Bedrock blocks and LEZ blocks?
| Each `PriceObservation` carries the same `signature` and `membership_proof` it had on Bedrock. | ||
| LEZ verifies these against the `root_cycle` frozen for the disputed round's cycle, not against the current live root. | ||
|
|
||
| Since one transaction may not hold the full set at once, |
There was a problem hiding this comment.
The DisputeSubmission proto should have new fields like:
- total numbers of observations
- offset
- obervations length
So first DisputeSubmission would advetize:
- total numbers of observations = 256
- offset: 0
- length: 140
Second one:
- total numbers of observations = 256
- offset: 116
- length: 116
This would allow the lez contracts to enforce and know that a submission is splitted. Wdyt?
| Otherwise LEZ computes the median over the valid set with the same rules as [Aggregation](#aggregation) | ||
| and compares it to the written value. | ||
| If they match, the dispute fails and the written value stands. | ||
| If they differ, the dispute succeeds, the written `AttestedPrice` is replaced with the recomputed one, |
There was a problem hiding this comment.
Should we have a field indicating the AttestedPrice has been replaced by the dispute mechanism here?
|
|
||
| How the dispute set is stored and deduplicated, | ||
| and whether resolution runs in one transaction or several, are left to implementation, | ||
| since both depend on the LEZ storage model and cycle budget. |
There was a problem hiding this comment.
Will need some benchmark and tests so we can validate it is feasible :)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The prev version of RFC has no proposer dispute solving mech so in this PR we present the dispute detection mech.
Assumptions: the disputy is pretty expensive in terms of time and gas but also so rare.
It requires at least
Nmany attestation (requiresNTXs ), LEZ contract deduplicates them all and discard minorities.Then compute median and compare.