Discussion topic for EIP-7906:
The point of this EIP is to provide the mechanism for wallets to actually restrict the outcomes of transactions the users are signing. This is just a building block on top of which a truly secure wallet UI can be build.
@alex-forshtat-tbk I love this proposal.
It’s very similar to the concept of Assertions that we have been developing for a while at Phylax as part of a wider protocol. Essentially, taking a more liberal approach of running some user defined solidity after every state transition, which evaluates whether it should be a valid state transition or not.
I have been ideating on a wallet/user-facing integration of the above concept, with wallets being able to offer “pre-defined” assertions for users to enable. One big difference is that we intend to integrate at the network level with enforcement being done by block builders.
Would love to collaborate on this. How are you thinking the support for EIP-7906? A modified full-node that makes the checks at the RPC level?
Hello @odysseas_eth, thank you for your feedback!
Regarding the Solidity defined Assertions, I think this is a great idea which gives a remarkable flexibility in defining the restrictions for a transaction. This is something that, unfortunately, will never be possible with a pre-determined set of restrictions like in EIP-7906.
It is not very clear if this approach of using full-fledged Solidity code for restrictions is practical for the Ethereum mainnet, but it may be worth it to think about having some minimal scripting support for restrictions in EIP-7906.
I have been ideating on a wallet/user-facing integration of the above concept, with wallets being able to offer “pre-defined” assertions for users to enable.
Yes, in general I would hope that it becomes a common practice for smart contract developers and dapps to provide the transactions’ restrictions in the same way they currently provide raw calldata, and for the wallets to have a list of “pre-defined” restrictions for all major known contract types.
For instance, an ERC-20 token transfer will have a very simple “pre-defined” restriction saying “your balance goes down by X, another balance goes up by X, nothing else happens anywhere”, and this restriction is basically “hard-coded” in the wallet’s immutable code.
And for a transaction to a contract that is unknown to the wallet, the dApp would provide a restriction to the wallet saying “writes slots X,Y,Z in contract A and writes any slot in contract B and nothing else happens anywhere”.
There is already a set of RPC APIs around EIP-2930 access lists that could be used to prepare the restrictions.
The wallet will need to present this information to the user in a somewhat human-readable way. And in an “advanced” mode users should be able to get involved and modify the proposed restrictions, for example adding an extra ban on moving some especially valuable asset.
How are you thinking the support for EIP-7906? A modified full-node that makes the checks at the RPC level?
With this being an “EIP”, if this proposal were to be accepted all full nodes in Ethereum would be modified in order to support the restrictions. We may require some modifications to the RPC methods but in general once the transaction is broadcast through the eth_sendRawTransaction RPC method there is no difference with other transactions, and the receipt will just state that the transaction reverted on-chain if the restrictions are violated.
Would love to collaborate on this.
Sure, that would be great! Please feel free to share any feedback on the proposal itself and if there are any additional details about the assertions mechanism you have built, I would be happy to learn more.
Well, following the same philosophy of the EIP, we could send the EVM bytecode as part of the request, communicating that the EVM bytecode must not revert if executed after the transaction is applied to the state.
One thing that I like with the EIP is that because of the restricted nature of what constraints can be expressed, it doesn’t need to handle the complexity of adding a turing-complete user-defined computation at the end of a state transition.
Yes, I have the exact same concept in mind.
To be honest, I don’t see why we should be limited by the EIP process here. This feature we are describing here, either via EIP-7006 restrictions or the more turing-complete script version that I described with Assertions, could be unilaterally implemented as an experimental RPC path. Getting Infura/Metamask on-board for their default RPC endpoints would probably deliver more than 80% of the value. Instead of the transaction reverting on-chain, it would be instead dropped by the RPC node and then communicated to the user/wallet.
Of-course handling that at the RPC level introduces the risk of an attack which would modify the state inside the block in such a way that the transaction would actually violate the predicates when it’s executed inside the block. That would have been missed at the RPC level, since by necessity it can only check the transaction against the latest finalised state of the blockchain and not against the state on top of which the transaction will be executed when it’s added to the new block.
Will circle back with more comments as I reflect on this EIP.
Right, however in order to support all features of restrictions this bytecode will probably need to have a mechanism to access private slots of contracts, so it can’t be achieved with a pure EVM code.
My biggest concern with this approach is establishing a false sense of security, which is the worst possible outcome. It is more or less trivial for an attacker to extract the signed transaction from the user’s communication with Infura/Metamask and broadcast it to a non-compliant RPC endpoint.
However, the users may trust the wallet’s message saying that the transaction does not modify any important storage state and sign the transaction on a very shady front-end dapp.
This is a threat in addition to the one you described where the transaction changes its behaviour once it is included on-chain, which can be achieved in many different ways by an attacker.