Alors que la plupart des L2 sont encore en train de se mesurer en TPS (transactions par seconde), @Hemi Hemi sort du circuit : le véritable cœur des L2 n'est pas le "rapide", mais l'"ordre" - comprendre quelles choses nécessitent une réponse en temps réel, lesquelles doivent avancer lentement et avec rigueur, et lesquelles doivent être traçables. Sa solution est très claire : utiliser une sécurité à double source (Ethereum + Bitcoin) comme base, en divisant les étapes d'exécution de manière modulaire, séparant complètement l'expérience du "rapide" de la sécurité du "lent", et aboutissant finalement à un L2 pratique "orienté vers le grand public et également vers les développeurs".
Une, logique centrale : d'abord distinguer le "rapide" du "lent", puis trouver le bon "niveau de transition"
La façon dont Hemi classe le « rapide » et le « lent » colle parfaitement aux scénarios de besoins réels :
- **Ce qui doit aller vite** : se concentrer sur la fluidité « pour les utilisateurs et les développeurs » — connexion utilisateur, attribution de droits, paiement des factures ; rapprochement des commerçants, itération du code pour les développeurs. Même en réseau faible et en période de pointe, il faut que ce soit « sans friction » : pas de blocage ni d’anxiété liée à l’attente ;
- **Ce qui doit être lent** : se concentrer sur la « sécurité du système et son finalité » — arbitrage en cas de litige, engagements d’actifs clés (par exemple, le volume total des actifs sur tout le réseau), mises à jour des paramètres du système, comptes rendus après incidents. Il faut que ce soit « lent, mais structuré » : chaque étape laisse une trace, est vérifiable, et jamais on ne sacrifie la sécurité au nom de la vitesse.
II. Architecture de base : double sécurité en guise de secours, adaptation flexible et modulaire
Pour réaliser « rapide/lent avec ordre », Hemi ne reconstruit pas la couche de base ; il intègre plutôt les avantages de réseaux matures et découpe les fonctions clés en « modules remplaçables » :
- **Double sécurité : chacun fait son rôle**
- S’appuyer sur** Ethereum** et son écosystème : compatibilité parfaite avec EVM. Les développeurs peuvent utiliser Solidity, Hardhat, etc., des outils familiers, pour démarrer facilement et réutiliser directement l’écosystème de smart contracts d’Ethereum, sans construire à partir de zéro ;
- Sécurité grâce à** Bitcoin** : considérer Bitcoin comme « ancre de valeur + socle anti-attaque ». Les données clés (par exemple, les soldes d’actifs de la passerelle, les instantanés du système) sont ancrées régulièrement à Bitcoin ; pour attaquer, un acteur malveillant doit traverser un réseau hétérogène, ce qui augmente considérablement le coût de la malveillance.
- **Découpage modulaire : flexible, sans vous contraindre**
Il faut découper « exécution, disponibilité des données (DA), tri, messages interdomaines, preuve, gouvernance » en modules indépendants : par exemple, la DA peut passer entre Ethereum et d’autres réseaux DA majeurs ; le tri peut évoluer d’un « seul opérateur » vers un « tri partagé » et un « tri équitable ». Toute mise à niveau d’un module commence par une « exécution en fantôme », puis une validation en déploiement progressif (gray-scale). Si les indicateurs ne sont pas atteints, le système effectue automatiquement un retour arrière, afin d’éviter qu’un problème dans un module ne fasse s’effondrer tout le réseau.
III. Modules clés : mettre dans le détail « une expérience rapide » et « une sécurité lente »
### 1. Domaine d’exécution : rendre le développement et l’usage « légers »
Hemi s’aligne sur l’écosystème d’outils EVM grand public : les développeurs n’ont pas besoin d’apprendre de nouvelles compétences. Parallèlement, il optimise le mode « calcul hors chaîne + preuve on-chain » : le local ne conserve que les changements simples d’état ; les calculs complexes sont confiés à l’environnement hors chaîne ou à de la puissance de calcul externalisée ; une fois le calcul terminé, on renvoie la preuve une seule fois pour le règlement en chaîne.
Il y a deux avantages à cela : d’une part, on peut choisir la latence (économie/stabilité/rapide) ; en cas de congestion, il devient clair « combien payer en plus pour accélérer, et combien attendre au maximum ». D’autre part, les coûts sont transparents (les frais de preuve et les gains par lots peuvent être consultés sur le panneau). L’équipe choisit, comme en souscrivant un service cloud, les standards de service « IA / jeux / DeFi » (SLO) selon les besoins.
### 2. Pont interdomaines : pas de fonctions complexes, seulement la protection de la ligne de sécurité
Le franchissement de domaine est une « zone à haut risque » de niveau 2. Hemi simplifie l’« interaction interdomaines » en « preuve plutôt que message » : le domaine source effectue l’opération, génère un engagement d’état et une preuve ; le domaine cible n’a qu’à vérifier la preuve, puis peut exécuter directement la comptabilisation.
La passerelle ne touche pas à des activités commerciales complexes : elle ne gère que trois choses — contrôle des quotas, temps de refroidissement, ordre de mise en file d’attente ; elle est également liée à quatre indicateurs : quota de la passerelle, écart de stocks, latence de compensation, priorité de règlement. En cas d’anomalie, le système passe automatiquement en « ralentissement → traitement par petits lots → retour arrière (rollback) », en priorité pour laisser passer les transactions critiques (par exemple, retraits des utilisateurs) afin d’éviter que la passerelle « fasse exploser » le système.
### 3. Expérience et gestion des risques : laisser les soucis au système, laisser la fluidité aux utilisateurs
- **Côté expérience : même en dégradation, c’est avec des bénéfices**
En cas de réseau faible et d’horaires de pointe, l’interaction se comprime en « unité minimale vérifiable », permettant « utiliser d’abord, régler ensuite » (par exemple, recevoir d’abord des droits, puis finaliser l’enregistrement ultérieurement). Après la mise en chaîne par lots, les résultats se synchronisent automatiquement vers le portefeuille et l’application. Si le délai dépasse le seuil, le système compense automatiquement, ajuste temporairement les limites de quotas et publie un compte rendu récapitulatif dans les 72 heures, afin que les utilisateurs aient un droit à l’information.
- **Côté gestion des risques : règles entièrement transparentes**
Les règles de contrôle de fréquence, les restrictions géographiques / d’âge, l’empreinte de l’appareil, etc., sont toutes publiées sur le panneau. Les règles déclenchées ne font que « réduire les droits (baisser la priorité), introduire un délai aléatoire, et augmenter le taux de frais » ; en cas de faux positifs, il existe un chemin de recours pour rétablir la situation. Les indicateurs comme le taux d’erreur (kill rate), le taux d’autorisation (pass rate), etc., sont publiés en temps réel, en finissant avec le « réglage au feeling ».
IV. Mécanismes de gouvernance : remplacer « le pouvoir de parole » par « la preuve »
La gouvernance de Hemi ne repose pas sur des « jeux de votes », mais sur « la parole des données » :
- Lors de l’ajustement des paramètres clés (par exemple, limites de transfert, ratio de partage des profits), il faut impérativement lier « fenêtre de validation + retour automatique » : régler les paramètres, c’est comme faire une expérience ; si les indicateurs ne sont pas atteints, on revient à l’état d’origine ;
- Mises à niveau des algorithmes de tri, ajustements des règles de gestion des risques, etc. : opérations de bout en bout entièrement publiques, consultables par tous ;
- Incitations orientées vers « la valeur à long terme » : les équipes fournissant des modules de base comme DA, tri, etc., peuvent continuer à en tirer des bénéfices parce que ces modules sont réutilisés fréquemment ; les jeux de spéculation à court terme ou sans valeur réelle ne reçoivent pas d’incitations du trésor.
Au fond, Hemi ne veut pas être « le L2 le plus rapide », mais « le L2 le plus soucieux de l’ordre » : permettre aux développeurs de déployer des applications sans effort, aux gens d’utiliser le service comme une application ordinaire, et à la sécurité d’être renforcée en s’appuyant sur Ethereum et Bitcoin. L’augmentation de capacité n’est pas « empiler des chiffres de TPS », mais décomposer au bon niveau « l’expérience rapide » et « la sécurité lente », c’est la clé pour que le L2 puisse atteindre le grand public.
*Avertissement* : cet article partage uniquement des tendances de marché et des analyses de projet ; il ne constitue pas un conseil en investissement. Les investissements comportent des risques ; soyez prudent avant d’entrer sur le marché.