The Risks of EIP-3074’s Fork: How Ethereum Smart Contract Accounts Expose Risks for Users

EIP-3074 passed the Ethereum core dev vote to be included in the next Ethereum upgrade (expected to be updated to Solidity in early 2025), but at what cost to potential security concerns? It begs the question: how much access should 3rd parties have? Meanwhile, Kadena’s Pact permits single-time actions, a more granular approach to permission settings for smart contracts.

What is EIP-3074?

EIP-3074 is an overhaul to how accounts work on Ethereum — EIP-3074 allows smart contracts to control funds from an externally-owned account (EOA). It allows you to delegate your funds to be controlled by the contract. EIP-3074 allows users to have more flexibility over account functionality. The most significant feature of the upgrade is Smart Contract Accounts (SCAs), which will allow users to hold and control funds and automate decisions on other contract calls according to programming logic (Bankless).

Customization and UX/UI Upgrades with Increased Risk

While EIP-3074 is highly customizable, it will give attackers a new window of opportunity. The upgrade, according to Bankless, allows wallet users to authorize smart contracts to perform actions on their behalf within a single transaction.

Through EIP-3074, a transaction can continue to happen unless a replay protection is specifically set, which is not intuitive. Additionally, EIP-3074 can allow a contract invoker to transfer tokens as you permit. However, there can essentially be a side agreement that permits an allowance for another withdrawal in the future (Fellowship of Ethereum Magicians).

An Analogy

Think of Ethereum as giving an autonomous robot the key to your house and letting it do tasks at any time. However, it can also do tasks you haven’t specified or don't want it to do.

Kadena, however, is like using a remote-controlled robot, only letting the robot work when you press a button, making it safer and more controlled.

Transaction Malleability Risks

Pact, Kadena’s smart contract language, was intentionally designed so that signatures and the corresponding keys must be contained in the hash. This is crucial for security as it prevents transaction malleability, which is a type of attack that occurs when a Bitcoin transaction’s ID is altered. The risk here is that the attacker can make it look like a transaction did not occur (Coindesk).

Leveraging Pact and the Chainweb API ensures that all commands contain a signed hash for the transaction. This protects against impersonation and keeps a 1:1 relationship between code execution and the signer.

Furthermore, capabilities on Pact permit single-time actions.

Capabilities

Additionally, Pact has a feature called capabilities, which offers a more robust balance of security and customization. Capabilities allow you to scope the exact events that a user can sign for. Pact can store signatures, allowing one-time secondary actions using quicksign and continuation.

Capabilities grant permissions or abilities to smart contracts without incorporating cryptographic elements into the smart contract code. Furthermore, capabilities support single-access smart contracts instead of adding to the multiple-entry smart contract permissions included on other blockchains (e.g., SCAs in EIP-3074).

Using capabilities and specially crafted on-chain accounts, we can perform actions within the smart contract if the user or contract can meet the capability's scope.

In Conclusion

While EIP-3074 will upgrade Ethereum’s UI/UX and customize smart contracts, it comes with several major risks that the average user will not be ready for. Special permissions must be encoded into a smart contract to protect user funds from being siphoned from invokers.

With Pact, capabilities support one-time actions —events can be scoped exactly as you expect with quicksign and continuation, eliminating the risk caused by multiple-entry smart contracts that will be rampant after the EIP-3074 hard fork.