fix(tee_verifier): correctly initialize storage for re-execution

[haraldh]

What ❔

With this commit, the TEE verifier uses WitnessStorageState of VMRunWitnessInputData to initialize the storage. This requires waiting for the BasicWitnessInputProducer to complete and therefore the TEE verifier input producer can be removed. The input for the TEE verifier is now collected in the proof_data_handler, which enables to remove the whole job queue for the TEE verifier input producer.

Why ❔

Previously the storage for VM re-execution was initialized just from WitnessInputMerklePaths. This although misses the storage values for slots, which are only read/written to by rolled back transactions. This led to failed verification of blocks, which would normally pass.

Checklist

• PR title corresponds to the body of PR (we generate changelog entries from PRs).
• Tests for the changes have been added / updated.
• Documentation comments have been added / updated.
• Code has been formatted via zk_supervisor fmt and zk_supervisor lint.

[EmilLuta]

I've left my concerns on the current implementation. If there's a doc for me to understand what's going on, that'd be great, could provide better input. Otherwise, maybe writing it down (maybe as part of PR?) would help moving this forward.

[pbeza]

We should probably remove this function altogether:

zksync-era/core/lib/dal/src/tee_proof_generation_dal.rs

Lines 199 to 229 in 3a97168

	pub async fn insert_tee_proof_generation_job(
	&mut self,
	batch_number: L1BatchNumber,
	tee_type: TeeType,
	) -> DalResult<()> {
	let batch_number = i64::from(batch_number.0);
	let query = sqlx::query!(
	r#"
	INSERT INTO
	tee_proof_generation_details (
	l1_batch_number, tee_type, status, created_at, updated_at
	)
	VALUES
	($1, $2, $3, NOW(), NOW())
	ON CONFLICT (l1_batch_number, tee_type) DO NOTHING
	"#,
	batch_number,
	tee_type.to_string(),
	TeeProofGenerationJobStatus::Unpicked.to_string(),
	);
	let instrumentation = Instrumented::new("insert_tee_proof_generation_job")
	.with_arg("l1_batch_number", &batch_number)
	.with_arg("tee_type", &tee_type);
	instrumentation
	.clone()
	.with(query)
	.execute(self.storage)
	.await?;
	Ok(())
	}

You are now inserting new entries in the lock_batch_for_proving function instead:

zksync-era/core/lib/dal/src/tee_proof_generation_dal.rs

Lines 78 to 104 in 3a97168

	INSERT INTO
	tee_proof_generation_details (
	l1_batch_number, tee_type, status, created_at, updated_at, prover_taken_at
	)
	SELECT
	l1_batch_number,
	$1,
	$2,
	NOW(),
	NOW(),
	NOW()
	FROM
	upsert
	ON CONFLICT (l1_batch_number, tee_type) DO
	UPDATE
	SET
	status = $2,
	updated_at = NOW(),
	prover_taken_at = NOW()
	RETURNING
	l1_batch_number
	"#,
	tee_type.to_string(),
	TeeProofGenerationJobStatus::PickedByProver.to_string(),
	TeeProofGenerationJobStatus::Unpicked.to_string(),
	processing_timeout,
	min_batch_number

Update

You may consider merging my PR (#3037) that is addressing the above mentioned issue.

[EmilLuta]

Rubber stamping, as long as @slowli's comments have been addressed, good with me.

[pbeza]

I think core/lib/dal/doc/TeeProofGenerationDal.md got outdated.