12 Matching Annotations
  1. Jun 2019
  2. May 2019
    1. Proof Structure

      How do we actually verify the given transaction?

    2. The resulting update MUST have a block number equal to element.block.

      Rephrase into client MUST check, throw error.

    3. After executing the transactions against all updates, the client MUST verify that the resulting state updates are all equivalent.

      Maybe worth explaining why this is necessary.

    4. Next, the client MUST find all previously verified state updates that intersect with the range on the transations and where update.verifiedBlockNumber is equal to element.block - 1.

      Maybe tie this back into non-inclusion proof elements.

    5. The provided transactions are used to compute the newer state update

      Explain client computes.. etc

    6. This process effectively finds any state updates covered by the implicit range and “bumps up” the block to which they’re considered valid

      Expand on this

    7. This process will leave the client with a set of state updates that are entirely covered by the implicit range and ones that no longer intersect.

      Fix grammar

    8. We’re only interested in these state updates because the implicit proof only applies to the element.block but not any previous blocks.

      Explain this better

    9. The client SHOULD check their local database for the deposit before querying Ethereum.

      Expand on this.

    10. Otherwise, a client may not have the necessary information to verify a specific state transition.

      Expand on this, give an example.