Add EIP: Deactivate/Reactivate a Delegated EOA's Key

[colinlyguo]

Introduce a new precompiled contract to enable Externally Owned Accounts (EOAs) to deactivate and reactivate their private keys.

[eth-bot]

✅ All reviewers have approved.

[abcoathup]

Suggested change

	---
	---
	eip: 7851

Assigning next sequential EIP/ERC/RIP number.
Numbers are assigned by editors & associates.

Please also update the filename.

[colinlyguo]

got it. updated in commit 314ed2b.

[abcoathup]

Please create a discussions topic in Eth Magicians using the template: https://ethereum-magicians.org/c/eips/5

[colinlyguo]

thanks. updated in 314ed2b.

[jochem-brouwer]

I don't see how this works with 7702 though. If I have the private key of account A, then if I "deactivate" sending txs from A then I can still auth-sign from address B to A, thus removing the "deactivation" from A?

Should this add an extra check to 7702 when checking the auth-tuples? If the authority has the 00 deactivation byte then skip this authority?

[jochem-brouwer]

"Terminate" here means just "stop" the call to this precompile without making any state changes? (One could also "revert", thus the item put on stack when using the CALL* opcodes to this precompile would put 0 on stack if these conditions are not met (so no state changes are done?))

[colinlyguo]

Thanks for the clarification, the error case of precompile is updated as: "Returns a precompile contract error and consumes all provided gas" (refer to 0f2aaba).

The handling logic is consistent with other precompiles mentioned in https://www.evm.codes/precompiled. Also, consuming all gas for invalid calls (reducing DoS attack vectors) looks reasonable.

For the error return, I searched client implementation in geth and found it handled outside by CALL, STATICCALL, CALLCODE, DELEGATECALL. When precompiles return an error, it will be returned to CALL, and CALL will set return value as 0. But formal documents would help clarify this for sure.

[jochem-brouwer]

I think a rule should be added here. In case that we are updating the delegated code, but we are running in "static" mode (so a call chain after using STATICCALL) this should abort (revert, no state-changes).

[colinlyguo]

yes. you're right! I added the STATICCALL error case in this commit: 0f2aaba

[colinlyguo]

I don't see how this works with 7702 though. If I have the private key of account A, then if I "deactivate" sending txs from A then I can still auth-sign from address B to A, thus removing the "deactivation" from A?

Should this add an extra check to 7702 when checking the auth-tuples? If the authority has the 00 deactivation byte then skip this authority?

nice catch. added the extra check you mentioned in the draft. pls refer to this commit: 0f2aaba

[github-actions]

The commit e8778dc (as a parent of 0008744) contains errors.
Please inspect the Run Summary for details.

[jochem-brouwer]

The check if the current account is deactivated actually is more expensive than a base transaction due to the nature of the state trie. To read an account from the trie, one gets these items:

• Nonce
• Balance
• codeHash
• storageHash

In order to read the actual code (to figure out if the account is delegated and thus to also perform the private key deactivation check) we have to actual read from the database again (to find what code codeHash points to). Since this is a disk read this is expensive and since this is now necessary for all transactions this might be a reason to increase the base transaction cost.

[colinlyguo]

it makes sense. I missed this (code read cost).

In the first draft before opening this pr, the proposal plans to add a new bool (1 byte) field in the account state, so that it can be read together with nonce, balance, codeHash, and storageHash.

this may add some complexities in backward compatibility discussions while keeping the basic cost of transactions cheaper. do you think it makes sense to change the implementation of the draft to this method? so that the basic transaction cost can be kept unchanged.

[rezaeghbal01]

21000**
**

[jochem-brouwer]

@colinlyguo This extra field in state will make this rather complex, because you are adding an extra field to the account state. This also means there will be logic introduced when enabling this EIP: each time if an account is hit, there will be logic to see if this account is "upgraded" to have this boolean in state. If this is not the case, then it could either add this flag to the state, or it could also do it only when necessary (so, if a transaction is sent, there will first be a check if the private key is deactivated. To check, first see if there is a boolean field at all: if this is not the case, then we can know for sure that this is an "old" account state and the private key is thus active. We can then add this field to the state. But this mechanism of checking and adding these fields will make the test vectors for this very big and it will also add a lot of somewhat boilerplate "upgrade" code to ensure the old accounts will update to the new ones (with this private key enabled flag). I would not recommend it.

I do recall in the past there have been discussions of using the nonce field. One could, for instance, use the highest bit of the nonce for this flag. One could use this flag to see if the accounts private key is disabled. What is handy here is that the nonce data is already in the account, so no extra disk lookups are necessary (when compared to putting it in the code).

However some nonce-limiting EIPs are around: https://eips.ethereum.org/EIPS/eip-3338, https://eips.ethereum.org/EIPS/eip-4803, putting a flag in nonce would likely throw away the benefits/rationales of these EIPs (4803 ensures that it can be decoded as int).

[colinlyguo]

agree. introduced a new field in the account state will add a lot of unnecessary "upgrade" code, which should be avoided.

adding a flag in nonce looks like a good idea.

for EIP-3338 which limits the nonce <= 2^52, using the highest bit of 2^52 seems not to make a large difference:

• the number is still large, 2^51 ~= 2.25 * 10^15.
• compared with 2^64-1, it's also quite small (same as 2^52).

For forward compatibility, can move the "deactivated bit" based on the nonce length after an upgrade. i.e. modifying the transaction verification rules.

an alternative to avoid encoding in the highest bit would be to encode the "deactivated bit" in the lowest bit of nonce, the actual nonce = nonce / 2.

[ADNANALISALHADABY]

Ok

[ADNANALISALHADABY]

EIPS/eip-xxxx.md

[Thegaram]

I see no better alternative, but this definitely sounds risky. Once a privkey has been deactivated most users would not take care to keep it secure. If it's leaked an attacker could use it after reactivation.

A powerful solution would be to enable delegation through a precompile. Then the account code could implement the required checks before "upgrading" its own code.

[Thegaram]

This check introduces an additional storage read

Since we read the account anyway for the nonce, I don't think this requires an additional read, so there's no additional workload for the txpool.

[jochem-brouwer]

There is an extra storage read, because the code itself is not directly stored in the account: only the code hash is stored in the account. So an extra storage read is necessary to get the actual code of the account (and not the hash). See also this comment

[Thegaram]

EOAs can reactivate their private keys

The code cannot know if its privkey is currently deactivated or not, right? (Since extcodehash only returns the delegation prefix.) Would this be an issue?

[colinlyguo]

I think it's OK not to know the specific status, each time the contract invokes the precompile, it just toggles the status, i.e. from deactivated to activated, or from activated to deactivated.

[g11tech]

Suggested change

	title: EOA private key deactivation/reactivation
	title: Delegated EOA's private key deactivation/reactivation

may be doesn't fit the title length constraint...

[colinlyguo]

yes. While the added delegated seems necessary, what about Deactivate/Reactivate a Delegated EOA's Key?

[g11tech]

yes sounds good

[ADNANALISALHADABY]

EIPS/eip-7851.md

[g11tech]

lgtm for draft

[eth-bot]

All Reviewers Have Approved; Performing Automatic Merge...

[eth-bot]

All Reviewers Have Approved; Performing Automatic Merge...