Congrats to @SamWilsn on a great presentation of EIP-3074 today on the All-Core Devs call. I think you provided the correct answer to most challenges that were presented, and I hope you’re not discouraged by the sentiment to take more time to prove its safety. (1/x thread)
This call made me think of a theme that has become tragically common in my mind in the last few years, as Chip Morningstar says, “You can’t tell people anything” (we might need to demonstrate the value to get the actual buy-in)
http://habitatchronicles.com/2004/04/you-cant-tell-people-anything/
In violation of that advice, I’m now going to take a shot at explaining the safety again, in response to a repeated misunderstanding on the call.
I was pretty disappointed to see multiple smart people, (and every objector!) comparing this proposal to SUDO. It’s a catchy objection, but I think it’s pretty easy to demonstrate why that equivalence is dramatically off, and I think drilling into exactly why it’s different might help others build an intuition for how this EIP works.
This is Alice. She has lots of different valuable things in her account.
In actuality, her account is just a metaphor for control, and each of these assets is defined by a different smart contract that obeys her account to control her assets. These arrows represent a flow of control from their fundamental source of truth to an intended recipient.
Today, when interacting with a smart contract like an exchange that needs one of Alice’s coins, she has to first ask that contract for permission, and then inform the other contract (like BobDEX), she first needs to tell the token’s contract to grant an allowance to this new contract, and if this is granted to a malicious contract, guess what happens? (Follow the arrow!)
As we can see from this new “allowance” arrow, Alice used the allowance function to symbolically delegate control of one of her tokens to this new dex. If Bob is evil, he can now steal all of her BlueCoin. People sometimes grant their whole token balance to an untrustworthy contract, and that’s a form of phishing that is real and people do it.
There are different approaches to solving that problem, and they are rooted in multiple problems that are at play:
- The user got phished into wanting to use an exchange that was malicious.
- For convenience the user delegated their whole token balance, when “just enough” would be safer.
Fundamentally, if a user wants to engage with a smart contract, they need to deposit assets into its trust. Even platforms that are prioritizing “offer safety” like Agoric’s Zoe (we guarantee you will receive at least X in exchange for Y) requires that you trust the offer-safety contract itself. Without that initial risk, there is no contract to be had.
This is the tension of a smart contracting platform: Squeezed between letting the user do whatever they want, and keeping them safe. It is natural to want to avoid introducing new insecurity, even at the benefit of new features, and so we should strive to prove that a new mechanism introduces no new insecurity to the platform, and I think this can be proven.
Coming back to EIP-3074. An invoker contract allows for a user to delegate FULL CONTROL OF THEIR ACCOUNT. The most concerned people say this sounds like SUDO, and probably imagine it looks like this to interact with an application:
But actually, this new proposal never suggests delegating messages to new applications. It’s not a tool for that at all, and its “invokers” are better understood as part of the wallet’s own code.
While the addition of an invoker is sensitive, and should be treated as carefully as an infinite allowance permission, this risk is not for regular interactions with new applications, and most wallets probably won’t even allow users to perform this delegation (and at least should never without extreme caution).
Once a wallet trusts an Invoker, it is able to perform batching operations with the user’s keys, or whatever other features the invokers offer and the wallets feel is worth the risk of adding. Exactly like the risks that wallet developers already take every day when evaluating and adding new features.
One of the reasons of infinite allowances today is that gas is expensive, and a user might want to avoid an increased-approval transaction later by approving a higher allowance now. If we had support for batching, wallets would actually have tools to facilitate fewer, cheaper user approvals that allow them to delegate LESS authority to outside parties.
When invoking SUDO, a UNIX user grants the highest authority of the entire system to an application they are invoking. Heck, in UNIX, every invocation grants your full user account authority to any program you run.
In UNIX, every time you run a program you’re basically handing it your private key, and no one is more concerned about those kinds of unintentional delegation risks than wallet developers, and that’s why at MetaMask we’re building tools to allow running scripts with reduced system access:
Unlike the unix permissions model, A 3074 invoker adds a system for wallets to add new trusted modules that can allow for new ways of key-managed accounts to delegate authority.
Once delegated, the most those invokers can do is send messages from the user’s account, meaning if a contract is secure against current user behavior today, it should continue to be secure regardless of any delegation actions the user performs outside of that contract’s system. If another account’s behavior can put a contract you care about at risk, then that contract is not secure.