# EIP-7702 — La Fin de la Distinction EOA vs Compte Contrat
L'EIP-7702, prévu pour la fork Prague (Q4 2024), révolutionne l'expérience utilisateur sur Ethereum.
Le Problème Actuel
Aujourd'hui, il existe deux types de comptes :
EOA (Externally Owned Account) :
- Contrôlé par une clé privée
- Peut initier des transactions
- ❌ Pas de logique custom
- ❌ Pas de social recovery
- ❌ Pas de batch transactions
- ❌ Pas de sponsoring de gas
Smart Contract Account :
- Code arbitraire
- ✅ Logique custom
- ❌ Ne peut pas initier de transactions seul
- ❌ Nécessite un déploiement coûteux
La Solution : EIP-7702
Permet à un EOA d'emprunter temporairement le code d'un contrat pendant une transaction.
Syntaxe
// Nouveau type de transaction
type: 0x04,
authorizationList: [
{
chainId: 1,
address: 0x..., // Adresse du contrat à "emprunter"
nonce: 0,
v, r, s // Signature de l'EOA
}
]
Exemple Concret
Avant (EOA classique) :
// Alice veut approver un token ET swap en une transaction
// ❌ Impossible : nécessite 2 transactions séparées
// Tx 1
token.approve(dex, 1000);
// Tx 2 (doit attendre que Tx 1 soit minée)
dex.swap(token, 1000);
Après (EIP-7702) :
// Alice signe une authorization pour utiliser le code de BatchExecutor
contract BatchExecutor {
function execute(Call[] calldata calls) external {
for (uint256 i = 0; i < calls.length; i++) {
(bool success,) = calls[i].target.call(calls[i].data);
require(success);
}
}
}
// Transaction unique :
authorizationList: [{ address: BATCH_EXECUTOR }]
calls: [
{ target: TOKEN, data: approve(DEX, 1000) },
{ target: DEX, data: swap(TOKEN, 1000) }
]
// ✅ Atomique, 1 seule transaction
Cas d'Usage Révolutionnaires
1. Social Recovery
contract SocialRecovery {
mapping(address => Guardian[]) public guardians;
function recover(address newOwner) external {
require(hasGuardianApproval(msg.sender, newOwner));
// Change la clé de contrôle de l'EOA
}
}
// Si vous perdez votre clé privée :
// Vos guardians (3 amis) signent une transaction
// Votre EOA exécute le code de SocialRecovery
// → Votre compte est récupéré vers une nouvelle clé
2. Sponsoring de Gas
contract GasSponsorship {
function executeWithSponsor() external {
// Le sponsor paie le gas
// L'utilisateur signe juste l'intention
require(sponsor.hasBalance(msg.sender));
// Execute l'action de l'utilisateur
}
}
// Onboarding sans friction :
// Nouveaux utilisateurs n'ont pas besoin d'ETH pour le gas
3. Session Keys
contract SessionKey {
mapping(address => Session) public sessions;
struct Session {
uint256 expires;
uint256 spendLimit;
address[] allowedTargets;
}
function execute(address target, bytes calldata data) external {
Session memory s = sessions[msg.sender];
require(block.timestamp < s.expires);
require(isAllowed(target, s.allowedTargets));
// Execute
}
}
// Pour une dApp de gaming :
// Créez une session key valable 24h avec 0.1 ETH max
// Jouez sans signer chaque action
Différence avec EIP-4337 (Account Abstraction)
| Feature | EIP-7702 | EIP-4337 |
|---------|----------|----------|
| Nécessite un nouveau contrat | ❌ Non | ✅ Oui |
| Compatible EOA existants | ✅ Oui | ❌ Non |
| Nécessite infrastructure off-chain | ❌ Non | ✅ Oui (bundlers) |
| Changement de protocole | ✅ Oui (hard fork) | ❌ Non |
| Activation | Temporaire (par tx) | Permanente |
EIP-7702 = Account Abstraction "à la demande"
Implémentation
// Avec ethers.js v7+
const tx = await wallet.sendTransaction({
type: 4,
to: TARGET_CONTRACT,
data: calldata,
authorizationList: [
{
chainId: 1,
address: DELEGATED_CODE_ADDRESS,
nonce: 0,
signature: await wallet.signAuthorization(...)
}
]
})
Sécurité
⚠️ Risques :
Protections :
// Wallet UI doit afficher clairement :
// "Vous autorisez votre compte à exécuter le code de : 0x123..."
// "Ce code peut : [liste des permissions]"
Timeline
- ✅ Q1 2024 : EIP finalisé
- 🚧 Q4 2024 : Fork Prague (prévu)
- 📅 2025 : Adoption massive des wallets
Ressources
EIP-7702 est le chaînon manquant pour rendre Ethereum aussi simple qu'une app Web2.