Trust Base Validation
Last updated
Last updated
A fundamental role of USL is to validate incoming claims. These claims are transactions that include the input and output states and the transaction’s .
Specifically, USL verifies whether executing a transaction on the input state while satisfying its given trust specifications yields the claimed output state. The transaction is only settled if validation is successful.
This validation process must be reproducible and independently verifiable. In an environment where these trust assumptions are met, anyone should be able to reproduce the same validation result by re-executing the transaction.
In its simplest form, the Trust Base of a transaction is a of trust assumptions or dependencies that must be satisfied for the transaction’s claim to hold. These trust assumptions might specify:
Version Constraint: A constraint on the version of a software component used in a transaction’s execution step. This could be expressed using a well-known dependency specification notation like poetry’s.
Here are some examples: uniswap_v3_app, ~geth_v1.13, ^solc_v0.8.2
Transaction Generation Constraints: A constraint on the version of a software component involved only in the transaction generation process but not in its execution. This could refer to a web3 application, frontend, or a browser wallet extension.
Here are some examples: aave_frontend_1.1, ^meta_mask_v11.6
Vetting Transaction Parameters: A non-executable trust assumption that specifies an entity attesting to one or more transaction parameters. For example, a trust assumption might assert that the Ethereum Foundation has vetted the transaction’s prestate or that Runtime Verification has audited a version of a smart contract used by the transaction.
Ideally, a Trust Base specification should be thorough and reproducible. This means any USL validating node can establish a full execution environment according to the Trust Base specification, reproduce the claimed transaction, and check for consistency. In that way, a Trust Base specification functions as a configuration file or a Docker image but on a smaller scale.
Here is an example to further explain that. A Uniswap token swap transaction might specify <uniswap_v3_app && geth_v1.13> as its Trust Base. USL validates the transaction by creating an execution environment that uses geth v1.13 and uniswap_v3_app smart contracts to execute the transactions and confirm that the transfer function results in the claimed output. The entities uniswap_v3_app and geth_v1.13 specified in the Trust Base are pointers (addresses) to specific publicly available components.
Furthermore, a transaction’s Trust Base may specify a more complex combination of constraints. For instance, a Uniswap token swap transaction might specify a less restrictive (and therefore superior) Trust Base, such as <uniswap_v3_app && (geth_v1.13 || kevm_v2)>. Here, the transaction does not need to trust geth_v1.13 as validation can be performed using K’s executable specification of EVM, kevm_v2. Generally, a Trust Base specification can be a Disjunctive Normal Form (DNF) formula, where each is a conjunction of atomic trust base specifications.
It is important to note that verifying broader trust dependency specifications, such as those using wild cards like solc_v0.8.* or logical disjunctions like the one above, can be more demanding to validate. A transaction with such specifications must be validated against all execution environments satisfying the constraints given by the specifications.
Ideally, we should formally define the trust specification language, including its syntax and semantics. This would prevent any confusion or ambiguity in interpreting trust constraints among validators. Executable formal specifications of trust assumptions could also provide the following services to components external to USL:
Automatic configuration of environments on demand, for example, for external validators wishing to independently verify state changes in USL.
Automated verification of trust specifications for correctness, such as for apps generating transactions with trust specifications.
The trust specification language can be stored and versioned on-chain for full accessibility and transparency.
From the three trust assumption types above, assumptions of Transaction Generation Constraints and Vetting Transaction Parameters are not components that can be validated through transaction re-execution. However, they can be validated using digital signatures. For example, specifying an address of a front-end component, such as MetaMask, as a trust assumption does not directly contribute to transaction validation.
Similarly, specifying that individuals or organizations, such as the Ethereum Foundation, have vetted certain dependencies does not directly impact the validation process. Despite these trust assumptions not being validated by re-executing the transaction, they are important informational components.
More specifically, the Trust Base specifications of the three types above collectively serve the following three primary goals:
They ensure the reproducibility of validation and independent verifiability of the validation results by specifying all the necessary requirements on the transaction’s execution environment.
They define the trust assumptions and make them explicit, thus raising awareness of trusted components and enabling visualization of the entire transaction’s Trust Base, including potential trust scores and trust base updates.
They enable post-mortem analysis and blame assignment. For example, if an entity vets a language semantics and it is later revealed to have a logic inconsistency that an attacker exploits, the providers of proof generators or verification tools are absolved of fault. Similarly, if an application's front end is exploited, for example, through phishing, resulting in a malicious transaction being generated and signed by its owner, then the entity that developed the smart contract is not at fault.