# Trust-minimized consensus layer access Today there is no trust-minimized way to access the consensus layer from the execution layer (inside the EVM). ## Beacon accumulator with EIP-4788 To partially address this, we have [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788) which adds an opcode to the EVM that provides oracle access to an accumulator (e.g. beacon block root or beacon state root) from the beacon chain at some block height. Access to this accumulator means we can *prove* values from the consensus layer at the execution layer at various points in time using [SSZ merkle proofs](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md). This capability has many use cases that improve the trust model for existing staking pool implementations and expand the possibility set for new staking pool designs. Access to the validator set also unlocks various use cases around restaking that improves the security model there as well. This sounds great, but there is one additional catch: the SSZ proving scheme has a concept of [generalized index](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#generalized-merkle-tree-index) to map between specific data in any given SSZ structure and the backing Merkle tree used to derive the root accumulator. It is possible in general for this generalized index to change and so we would also like for a trust-minimized way to access the generalized indices. (otherwise the aforementioned use cases need some kind of governance to provide the right mapping at each fork) ## Options for generalized index (GI) 1. A new precompile for GI access Add another precompile that takes a description of the consensus object (from the full set of supported objects) and a "path" descriptor pointing to some data in this object (there is [a path description language given here](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#ssz-object-to-index)) Return the GI for this data, along with defining some error criteria 2. Make a SSZ proof verification precompile that combines EIP-4788 and also the logic of (1) Instead of shipping EIP-4788, we could make one precompile routine that does the aggregate task of SSZ proof verification * Input: block number, identifier for consensus object, path to data, serialized data, proof for the data * Output: boolean data to indicate success/failure of proof verification 3. Leave to the application layer Do nothing; applications can find a way to manage governance and/or a common body can provide the GI mapping for each fork as a public good that any application can use on-chain