IntegrityProof

## Goals - prove that bundle has not been tempered with - enable trustless slot selection --- ## Requirements - A challenger should be able to prove the block builder has tempered with the bundle - Bundle sender should not be able to game the system - Block builder should not be able to game the system - A bundle sender should be able to express slot preference to a block builder --- ## Description - There will be only one contract, call it `proofOfIntegrity.sol` - When new bundle is submitted, a sender should include a tx calling the `stamp()` function of the `proofOfIntegrity.sol` contract - `stamp(Txs tx, uint blockNumber, uint bundleIndex)` - take in all of the transactions in a bundle. `Txs` is an array that takes in a contract defined `Transaction` type i.e. `struct Transaction` - the function calculate the hash using `keccak256` , count the tx number in the bundle, and use `blockNumber` and `msg.sender` to update to mappings - `mapping(address => (mapping(uint = > uint))) public bundleSizeMap` - this is a mapping `senderAddress` ⇒ `blockNumber` ⇒ `bundleSize` - `mapping(address => (mapping(uint => bytes))) public bundleHash` - this is a mapping `senderAddress` ⇒ `blockNumber` ⇒ `bundleHash` - Additionally, function will update another mapping - `mapping(address => (mapping uint => uint)) bundleIndexMap` - this is a mapping `senderAddress` ⇒ `blockNumber` ⇒ `bundleIndex` - Note: `bundleIndex` is to express the slot number a bundle wants to be placed in the block. The top slot a bundle can express is 2, since the slot 1 will always be taken by the `verifyBundle()` function invoked by the block builder(more on this later) - Then, the function will check the value in the `mapping(address => (mapping uint => bool)) bundleVerificationMap` . If the ending `bool` is the default value `0`, then the function reverts with log `bundleVerificationMap not updated` - Note: the reason why it needs to revert is because it forces the block builder to insert a `verifyBundle()` transaction call on the top of the bundle. This will also let the block builder know that the sender has requested that he/she wants the bundle to be later subject to proof-of-integrity - this is a mapping `senderAddress` ⇒ `blockNumber` ⇒ `verified` - this mapping can only be updated by the `verifyBundle()` function(more on this in the following section) - when the bundle is submitted, the block builder needs to call the `verifyBundle()` function, and this function can only be called by a whitelisted block builders in a `whitelist` mapping - `verifyBundle(Txs txs, address sender, uint blockNumber) onlyBlockBuilder returns(bundleIndex)` - Note:`onlyBlockBuilder` is a modifier checking whether the caller is in the `whitelist` - the purpose of this function is to make sure that the value in the `bundleSize` , `bundleHash`, inputted by the bundle sender is correct because bundle sender could game the system by randomly putting the arbitrary `bundleSize` and `bundleHash` - The block builder will need to supply the three arguments `txs`, `sender`, `blockNumber`. All three of these values can be found the in the bundle submitted by the bundle sender - in the function, it’ll do the following: - get the length of `txs`, and use `sender` and `blockNumber` to query the `bundleSizeMap` . If match, continue; otherwise revert - calculate the `bundleHash` from the `txs`, and use `sender` and `blockNumber` to query the `bundleHashMap`. if match, continue; otherwise revert - Update the `bundleVerificationMap` to true by providing the `sender` and `blockNumber` - returns the `bundleIndexMap` to get the index a bundle sender wants - If the bundle index is accepted by the block builder, the block builder will add the bundle, with the tx calling `verifyBundle()` on the top of the bundle, to the block. Otherwise, the block builder discard the bundle. - Note: `verifyBundle()` can be called in a simulation to get the `bundleIndexMap` 💡 Technically, a block builder can still temper the bundle after this step. A malicious block builder could call the `verifyBundle()` function first, then to change the ordering, or insert its own transaction in the middle of the bundle, and include the tempered bundle into the block. All of the previous steps are for a block builder to verify the arguments supplied by the bundle sender in `stamp()`function is correct. This is why we need the following steps - After the block has been built and mined on-chain. A third party could challenge by submitting a proof of integrity using Axiom V2 - In a challenge, a user could use a front-end application to query two values leveraging Axiom V2 - bundle hash: - The front end app would require a user to provide two values: `senderAddress` and `blockNumber` - the address is the bundle sender’s address, and `blockNumber` is the block when bundle was submitted - the front-end app will call the Axiom V2 API to query the block info. In the payload, the front-end app would find the bundle submitted by the `sender` by indexing the `senderAddress`. - Then, the front-end app would query the `bundleSizeMap` and `bundleHashMap` to get the `bundleSize` and `bundleHash`, given the `senderAddress` and `blockNumber` - By using the index number on a block, plus the bundle size, the front-end app could generate a `bundleHash` value in the browser. If it matches the `bundleHash` result from the Axiom V2 API, then it mean bundle was not tempered with; otherwise, it means the bundle has been tempered - submit the proof to a staking contract where block builder’s stake will be slashed - Bundle index: - using similar method, the front-end app could get the `bundleIndex` to see if the block builder actually put the bundle at the slot number a bundle sender requested in the `stamp()` function

IntegrityProof

About

How it's made