|
| 1 | +# EVM Authorization Contract |
| 2 | + |
| 3 | +If a general message passing protocol like Hyperlane wants to be avoided to not require the deployment of additional infrastructure, we also provide a Solidity version of the Authorization contract with similar functionality than the CosmWasm version. |
| 4 | + |
| 5 | +These are the steps to set up our EVM program using the EVM Authorization contract instead of Hyperlane: |
| 6 | + |
| 7 | +1) Deploy `Authorization.sol` providing the program owner, the lite processor address (previously deployed) and a flag specifying if we want to store the callbacks in the contract state or just emit them as events (less gas consumption): |
| 8 | + |
| 9 | +```solidity |
| 10 | +constructor(address _owner, address _processor, bool _storeCallbacks) Ownable(_owner) |
| 11 | +``` |
| 12 | + |
| 13 | +2) Once it's deployed, we need to set the authorization contract as an authorized address on the processor. |
| 14 | + |
| 15 | +```solidity |
| 16 | +function addAuthorizedAddress(address _address) |
| 17 | +``` |
| 18 | + |
| 19 | +This will allow processing the messages that the newly deployed authorization contract will forward to the processor. |
| 20 | + |
| 21 | +3) Now we can start adding our authorizations: |
| 22 | + |
| 23 | +```solidity |
| 24 | + /** |
| 25 | + * @notice Adds standard authorizations for a specific label |
| 26 | + * @dev Can only be called by the owner |
| 27 | + * @param _labels Array of labels for the authorizations |
| 28 | + * @param _users Array of arrays of user addresses associated with each label |
| 29 | + * @param _authorizationData Array of arrays of authorization data associated with each label |
| 30 | + */ |
| 31 | + function addStandardAuthorizations( |
| 32 | + string[] memory _labels, |
| 33 | + address[][] memory _users, |
| 34 | + AuthorizationData[][] memory _authorizationData |
| 35 | + ) |
| 36 | +``` |
| 37 | + |
| 38 | +This method allows adding multiple authorizations at the same time using arrays, to optimize the gas consumption. The most important part here is the `AuthorizationData`, which is defined as follows: |
| 39 | + |
| 40 | +```solidity |
| 41 | + /** |
| 42 | + * @notice Structure representing the data for the authorization label |
| 43 | + * @dev This structure contains the contract address and the function signature hash |
| 44 | + * @param contractAddress The address of the contract that is authorized to be called |
| 45 | + * @param useFunctionSelector Boolean indicating if the function selector should be used instead of callHash |
| 46 | + * @param functionSelector The function selector of the function that is authorized to be called |
| 47 | + * @param callHash The function signature hash of the function that is authorized to be called |
| 48 | + */ |
| 49 | + struct AuthorizationData { |
| 50 | + address contractAddress; |
| 51 | + bool useFunctionSelector; |
| 52 | + bytes4 functionSelector; |
| 53 | + bytes32 callHash; |
| 54 | + } |
| 55 | +``` |
| 56 | + |
| 57 | +As explained above, we have two ways of defining our authorization: using the function selector or a callHash. If we use a function selector, the authorized address is allowed to execute that specific function with **ANY** arguments. For example, if the function is `transfer(uint256 amount)` the address can specify any amount value when calling the authorization. On the other hand, if we want to restrict the call to a specific value, we provide the call hash so that only those specific call bytes can be executed. For example, we compute the `keccak256` hash of the encoded call data (e.g., `abi.encodeWithSignature("transfer(uint256)", 1000)`) and provide that as the `callHash`. Then the authorized address can **ONLY** call this authorization with that specific value. |
| 58 | + |
| 59 | +As we can see this is less flexible than the CosmWasm version due to the nature of the Solidity language vs Rust but tends to be enough for most of the programs. If more flexibility is required, the option of using a message passing protocol with our encoding/decoding mechanisms or using the ZK Coprocessor is also available. |
| 60 | + |
| 61 | +4) Now that everything is set up, we can execute our authorization like this: |
| 62 | + |
| 63 | +```solidity |
| 64 | +function sendProcessorMessage(string calldata label, bytes calldata _message) |
| 65 | +``` |
| 66 | + |
| 67 | +We simply need to specify what label we want to execute and the encoded `ProcessorMessage` that will be forwarded to the Processor. This performs all the checks against our AuthorizationData, and if they all pass, the message will be forwarded to the processor, executed, and a callback will be received on the Authorization contract. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?v=4&size=40){kind=avatar}
0 commit comments