Add commit hash to policy #22
Open
Conversation
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
|
This PR is in a bad state because it's trying to build off of this PR in Ruteri's repo: #21 once that merges to flashtestations master this PR will be much cleaner |
Melvillian
force-pushed
the
add-commit-hash-to-policy
branch
from
798b9c7 to
a7e083a
Compare
Melvillian
changed the base branch from
minimal-example-of-working-onchain-verification-on-ethereum-sepolia
to
main
…o a policy Completes UNI-835 We want to add the commit hash to the Policy because Flashtestations needs a way to associate a TEE's workloadId with the source code used to build the TEE image represented by that workloadId. There is no way to do this that does not involve some sort of onchain permissioned action, because to do it without permissioned action would require building TEE images onchain, which is prohibitively expensive. Instead, we settle for a multisig signer that is permissioned to associate workloadIds with commit hashes. The recordLocators part of the metadata makes it easier for verifiers to find the URL from which to fetch the source code. We provide multiple locators so there is higher availability. Offchain verifiers can then use this commit hash to locate the TEE image build source code, build the TEE image, derive the workloadId, and then compare that locally-built workloadId with the workloadId in the policy that is associated with the commit hash. In this way, anyone can reliably prove that a given block is built using source code that orders transactions in a fair and verifiable manner which is the purpose of flashtestations). fix broken tests fixed tests
Melvillian
force-pushed
the
add-commit-hash-to-policy
branch
from
a7e083a to
8d99a49
Compare
Ruteri
approved these changes
Jul 28, 2025
| bytes32 workloadKey = WorkloadId.unwrap(workloadId); | ||
|
|
||
| // Check if workload already exists | ||
| require(bytes(approvedWorkloads[workloadKey].commitHash).length == 0, WorkloadAlreadyInPolicy()); |
There was a problem hiding this comment.
We can consider allowing updates to the commit hash — it's not necessarily wrong. If the commit changes only say the readme or release notes it'd still have the same associated image and workloadId but be more informative. The owner can always remove the old workload and then add a new one.
That being said it's of course more secure to not allow the update — we could in that case have an explicit comment about it.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
We want to add the commit hash to the Policy because Flashtestations
needs a way to associate a TEE's workloadId with the source code used
to build the TEE image represented by that workloadId. There is no way
to do this that does not involve some sort of onchain permissioned action,
because to do it without permissioned action would require building TEE
images onchain, which is prohibitively expensive. Instead, we settle for
a multisig signer that is permissioned to associate workloadIds with commit hashes.
Offchain verifiers can then use this commit hash to locate the TEE image build source code,
build the TEE image, derive the workloadId, and then compare that locally-built
workloadId with the workloadId in the policy that is associated with the commit hash.
In this way, anyone can reliably prove that a given block is built using source code
that orders transactions in a fair and verifiable manner which is the purpose of flashtestations).