search

entropyxyz / entropy-core

Protocol and cryptography development.
https://docs.entropy.xyz/
GNU Affero General Public License v3.0
11 stars 2 forks source link

Block number used in TDX quote cannot be known when quote is not immediately submitted #1174

Open ameba23 opened 3 days ago

ameba23 commented 3 days ago

Related to https://github.com/entropyxyz/entropy-core/issues/982

https://github.com/entropyxyz/entropy-core/pull/1173 adds a HTTP route which creates a quote and returns it to the caller in the response body. This is intended for use by node operators to retrieve a TDX quote for use in the validate, change_endpoint and change_tss_accounts extrinsics.

The problem is, the current block number is included in the quote input data which is checked when validating the quote.

Since there is a human in the loop (the node operator), we cannot know at the point of creating the quote exactly when it will be submitted for verification.

Possible solutions:

  1. Instead of block number, include some other contextual information such as an enum expressing which of the 3 extrinsics this quote is intended to be used for.
  2. Have a sliding window of allowed block numbers (eg: it must be submitted in the next hour). The tricky part is that the block number is hashed with other data to create the quote input, so when validating a quote, we would have to create and check all possible input hashes for the different allowed block numbers.
  3. Have the TSS server submit the extrinsic itself immediately. This means all other data which should be included in the extrinsic must be given in the HTTP request, and that the extrinsic will be coming from the TSS account, rather than the validator stash account.
  4. Redesign our system so that the quote can be submitted as a separate extrinsic beforehand.
  5. Assume that in production this will be used in an automated script or program where the extrinsic will be immediately submitted on getting the quote. In which case we can close this issue and do nothing.

I would go for either 1 or 5 for now as they are the simplest.

HCastano commented 3 days ago

I'd like to avoid dealing with block numbers here if possible. They introduce an element of uncertainty, especially in testing.

I think (1) is the most reasonable approach. One thing I'd like to ensure though is that there are a limited number of pending quotes issued per validator (and maybe the limit here is just one). We could either enforce this per track (e.g one per enum variant) or just one limit overall.