Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: remove TEE from tree #2627

Closed
wants to merge 4 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 54 additions & 0 deletions core/lib/dal/src/tee_verifier_input_producer_dal.rs
Original file line number Diff line number Diff line change
Expand Up @@ -72,9 +72,63 @@ impl TeeVerifierInputProducerDal<'_, '_> {
Ok(())
}

pub async fn get_new_l1_batch(&mut self) -> DalResult<Option<L1BatchNumber>> {
// Since we depend on Merkle paths, we use the proof_generation_details table to inform us of newly available to-be-proven batches.
let row = sqlx::query!(
r#"
SELECT
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't this mean you could miss some entries (you query once, MAX = 10, you query second time, now there have been 5 batches incoming, MAX = 15, you'd be missing batches 11, 12, 13 and 14, no?).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That should not happen. You only return max(l1_batch_number) from the proof_generation_details table if the TEE jobs table is empty (which just handles the special case when the thing comes up for the first time, L114). Normal case is to return max(l1_batch_number)+1 from the TEE jobs table.

MAX(l1_batch_number) AS "number"
FROM
proof_generation_details
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like that TEE is tied to proof_generation_details. If this table happens to become too hot (for instance, a bug in TEE), proof generation (and our SLAs + customer experience) will degrade. I don't have a better solution than code duplication, which I dislike even more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What code do you intend to duplicate as a potential solution? I'm open to suggestions in terms of an alternate "signal" to monitor for new batches.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that the right way would be to move save_merkle_paths_artifacts_metadata from proof_generation_dal to the blocks_dal (e.g. existence of the metainformation is the property of the block, regardless of the consumer).

This way we (later, not now!) will be able to get rid of insert_proof_generation_details in the updater.rs as well -- so that the tree is not aware of any verification logic (as it should be).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say it's unclear who would create the tables afterwards. But I don't oppose the suggestion.

WHERE
proof_gen_data_blob_url IS NOT NULL
"#
)
.instrument("get_sealed_l1_batch_number")
.report_latency()
.fetch_one(self.storage)
.await?
.number;

let max_sealed = match row {
Some(number) => number,
None => return Ok(None),
};

let row = sqlx::query!(
r#"
SELECT
MAX(l1_batch_number) AS "number"
FROM
tee_verifier_input_producer_jobs
"#
)
.instrument("get_latest_tee_verifier_input_producer_jobs")
.report_latency()
.fetch_one(self.storage)
.await?
.number;

match row {
// If no batches have been processed by TEE so far, i.e., table is empty, we start with the most recent L1 batch.
None => Ok(Some(L1BatchNumber(max_sealed as u32))),
Some(max_tee_batch_number) => {
if max_sealed > max_tee_batch_number {
Ok(Some(L1BatchNumber(max_tee_batch_number as u32 + 1)))
} else {
Ok(None)
}
}
}
}

pub async fn get_next_tee_verifier_input_producer_job(
&mut self,
) -> DalResult<Option<L1BatchNumber>> {
if let Some(n) = self.get_new_l1_batch().await? {
self.create_tee_verifier_input_producer_job(n).await?;
}
thomasknauth marked this conversation as resolved.
Show resolved Hide resolved

let l1_batch_number = sqlx::query!(
r#"
UPDATE tee_verifier_input_producer_jobs
Expand Down
4 changes: 0 additions & 4 deletions core/node/metadata_calculator/src/updater.rs
Original file line number Diff line number Diff line change
Expand Up @@ -152,10 +152,6 @@ impl TreeUpdater {
// right away without having to implement dedicated code.

if let Some(object_key) = &object_key {
storage
.tee_verifier_input_producer_dal()
.create_tee_verifier_input_producer_job(l1_batch_number)
.await?;
// Save the proof generation details to Postgres
storage
thomasknauth marked this conversation as resolved.
Show resolved Hide resolved
.proof_generation_dal()
Expand Down
Loading