Le réseau Ika, soutenu stratégiquement par la fondation Sui, a récemment dévoilé sa position technique et sa direction de développement. En tant qu'infrastructure innovante basée sur la technologie de calcul sécurisée multiparty (MPC), la caractéristique la plus marquante de ce réseau est sa vitesse de réponse en sous-seconde, ce qui est une première parmi les solutions MPC similaires. L'adéquation technique entre lka et la blockchain Sui est particulièrement remarquable, les deux étant hautement compatibles en termes de traitement parallèle, d'architecture décentralisée et d'autres concepts de conception sous-jacents. À l'avenir, Ika sera directement intégré dans l'écosystème de développement Sui, fournissant un module de sécurité inter-chaînes plug-and-play pour les contrats intelligents Sui Move.
D'un point de vue fonctionnel, Ika est en train de construire une nouvelle couche de validation sécurisée : elle sert à la fois de protocole de signature dédié à l'écosystème Sui et propose des solutions inter-chaînes standardisées pour l'ensemble de l'industrie. Sa conception en couches prend en compte la flexibilité du protocole et la facilité de développement, et il y a une certaine probabilité qu'elle devienne un cas pratique important pour l'application à grande échelle de la technologie MPC dans des scénarios multi-chaînes.
1.1 Analyse des technologies clés
La mise en œuvre technique du réseau IKA s’articule autour de signatures distribuées haute performance, et son innovation réside dans l’utilisation du protocole de signature de seuil 2PC-MPC avec l’exécution parallèle de Sui et le consensus DAG pour obtenir de véritables capacités de signature en moins d’une seconde et une participation décentralisée des nœuds à grande échelle. Grâce au protocole 2PC-MPC, aux signatures distribuées parallèles et à une intégration étroite avec la structure de consensus Sui, Ika souhaite créer un réseau multi-signatures qui répond aux besoins de performances ultra-élevées et de sécurité stricte. Sa principale innovation réside dans l’introduction de la communication de diffusion et du traitement parallèle dans le protocole de signature de seuil, et voici une ventilation des fonctions de base.
Protocole de signature 2PC-MPC : Ika adopte un schéma MPC à deux parties amélioré (2PC-MPC), qui décompose essentiellement l'opération de signature de la clé privée de l'utilisateur en un processus impliquant deux rôles : "l'utilisateur" et "le réseau Ika". Le processus complexe qui nécessitait auparavant une communication pair à pair entre les nœuds (similaire à chaque personne dans un groupe de discussion qui envoie des messages privés à tous) est transformé en mode de diffusion (similaire à une annonce de groupe), ce qui maintient également le coût de communication et de calcul au niveau constant pour l'utilisateur, indépendant de l'échelle du réseau, permettant ainsi à la latence de la signature de rester au niveau subsecond.
Traitement parallèle, décomposer les tâches pour travailler simultanément : Ika utilise le calcul parallèle pour décomposer une opération de signature unique en plusieurs sous-tâches concurrentes exécutées simultanément entre les nœuds, dans le but d'accélérer considérablement la vitesse. Cela intègre le modèle de parallélisme objet de Sui, permettant au réseau de ne pas avoir à atteindre un consensus d'ordre global pour chaque transaction, traitant ainsi de nombreuses transactions simultanément, augmentant le débit et réduisant la latence. Le consensus Mysticeti de Sui élimine le délai de validation des blocs grâce à une structure DAG, permettant une soumission instantanée des blocs, permettant ainsi à Ika d'obtenir une confirmation finale en moins d'une seconde sur Sui.
Réseau de nœuds à grande échelle : alors que les solutions MPC traditionnelles ne prennent généralement en charge que 4 à 8 nœuds, IKA peut s’adapter à des milliers de nœuds pour participer à la signature. Chaque nœud ne contient qu’une partie du fragment de clé, et même si certains nœuds sont compromis, la clé privée ne peut pas être récupérée individuellement. La distribution des nœuds est au cœur du modèle Zero Trust d’IKA, car des signatures valides ne peuvent être générées que lorsque les utilisateurs et les nœuds du réseau travaillent ensemble, et aucune partie ne peut opérer ou falsifier des signatures indépendamment.
Contrôle inter-chaînes et abstraction de la chaîne : En tant que réseau de signature modulaire, Ika permet aux contrats intelligents d’autres chaînes de contrôler directement les comptes (appelés dWallets) dans le réseau Ika. Plus précisément, pour que le contrat intelligent d’une chaîne (par exemple, Sui) puisse gérer des comptes de signature multipartites sur Ika, il doit vérifier l’état de la chaîne dans le réseau Ika. Pour ce faire, IKA déploie les preuves d’état de la chaîne dans son propre réseau. À l’heure actuelle, la preuve d’état Sui a été mise en œuvre en premier, de sorte que les contrats sur Sui peuvent intégrer dWallet en tant que bloc de construction dans la logique commerciale, et compléter la signature et l’exploitation d’autres actifs de la chaîne via le réseau IKA.
1.2 Ika peut-il activer de manière inverse l'écosystème Sui ?
Source de l'image : Ika
Après son lancement, Ika pourrait étendre les capacités de la blockchain Sui et apporter un certain soutien à l'infrastructure de l'écosystème Sui. Le jeton natif de Sui, SUI, et le jeton d'Ika, $IKA, seront utilisés conjointement. $IKA sera utilisé pour payer les frais de service de signature du réseau Ika, tout en servant également d'actif de mise pour les nœuds.
L'impact le plus significatif d'Ika sur l'écosystème Sui est d'apporter la capacité d'interopérabilité entre chaînes, son réseau MPC supporte l'accès aux actifs des chaînes comme Bitcoin, Ethereum, etc., avec une latence relativement faible et une sécurité élevée sur le réseau Sui, permettant ainsi des opérations DeFi inter-chaînes telles que le mining de liquidités et les prêts, ce qui contribue à renforcer la compétitivité de Sui dans ce domaine. En raison de sa rapidité de confirmation et de sa forte évolutivité, Ika a déjà été intégré par plusieurs projets Sui, ce qui a également, dans une certaine mesure, favorisé le développement de l'écosystème.
En matière de sécurité des actifs, Ika propose un mécanisme de garde décentralisé. Les utilisateurs et les institutions peuvent gérer leurs actifs sur la chaîne grâce à son système de signatures multiples, offrant ainsi plus de flexibilité et de sécurité par rapport aux solutions de garde centralisées traditionnelles. Même les demandes de transaction initiées hors chaîne peuvent être exécutées en toute sécurité sur Sui.
Ika a également conçu une couche d'abstraction de chaîne, permettant aux contrats intelligents sur Sui d'opérer directement sur des comptes et des actifs d'autres chaînes, sans passer par des processus de pontage ou d'emballage d'actifs compliqués, ce qui simplifie tout le processus d'interaction inter-chaînes. L'intégration du Bitcoin natif permet également au BTC de participer directement aux opérations DeFi et de garde sur Sui.
Sur le dernier point, je pense également qu'Ika offre un mécanisme de validation multi-facettes pour les applications d'automatisation AI, capable d'éviter les opérations d'actifs non autorisées, augmentant ainsi la sécurité et la crédibilité lors de l'exécution des transactions par l'IA, tout en fournissant une possibilité pour l'expansion future de l'écosystème Sui dans le domaine de l'IA.
1.3 lka défis auxquels nous faisons face
Bien qu'Ika soit étroitement lié à Sui, pour devenir un "standard universel" d'interopérabilité multi-chaînes, il faut voir si d'autres blockchains et projets sont prêts à l'adopter. Il existe déjà de nombreuses solutions de cross-chain sur le marché, comme Axelar et LayerZero, qui sont largement utilisées dans différents scénarios. Pour se démarquer, Ika doit trouver un meilleur équilibre entre "décentralisation" et "performance", afin d'attirer davantage de développeurs et inciter plus d'actifs à migrer.
Parler de MPC suscite néanmoins de nombreuses controverses, la question courante étant que les droits de signature sont difficiles à révoquer. Tout comme avec les portefeuilles MPC traditionnels, une fois que la clé privée a été fragmentée et distribuée, même si elle est re-fragmentée, la personne qui a obtenu l'ancien fragment pourrait théoriquement toujours restaurer la clé privée d'origine. Bien que le schéma 2PC-MPC améliore la sécurité grâce à la participation continue des utilisateurs, je pense qu'il n'existe pas encore de mécanisme de solution particulièrement complet sur la question de "comment changer de nœud de manière sécurisée et efficace", ce qui pourrait représenter un point de risque potentiel.
IKA lui-même dépend également de la stabilité du réseau Sui et de ses propres conditions de réseau. Si Sui fait une mise à niveau majeure à l’avenir, comme la mise à jour du consensus Mysticeti vers MVs 2, Ika devra également s’adapter. Mysticeti, un consensus basé sur le DAG, prend en charge une concurrence élevée et des frais peu élevés, mais comme il n’a pas de structure de chaîne principale, il peut rendre le chemin du réseau plus complexe et l’ordre des transactions plus difficile. Couplé au fait qu’il s’agit d’une comptabilité asynchrone, bien qu’elle soit efficace, elle apporte également de nouveaux problèmes d’ordre et de sécurité consensuels. De plus, le modèle DAG est très dépendant des utilisateurs actifs, et si l’utilisation du réseau n’est pas élevée, il est sujet à des retards de confirmation des transactions et à une dégradation de la sécurité.
II. Comparaison des projets basés sur FHE, TEE, ZKP ou MPC
2.1 FHE
Zama & Concrete : En plus du compilateur à usage général basé sur MLIR, Concrete adopte la stratégie de « bootstrap hiérarchique », qui divise les grands circuits en plusieurs petits circuits et les crypte séparément, puis assemble dynamiquement les résultats, ce qui réduit considérablement le délai d’un seul bootstrapping. Il prend également en charge l’encodage hybride : l’encodage CRT pour les opérations d’entiers sensibles au retard et l’encodage au niveau du bit pour les opérations booléennes qui nécessitent un haut degré de parallélisme, d’équilibrage des performances et du parallélisme. De plus, Concrete fournit un mécanisme d'« emballage de clés », qui peut réutiliser plusieurs opérations isomorphes après une importation de clé, réduisant ainsi les frais de communication.
Fhenix : Basé sur TFHE, Fhenix a effectué plusieurs optimisations personnalisées pour le jeu d’instructions Ethereum EVM. Il remplace les registres en texte brut par des « registres virtuels de texte chiffré » qui insèrent automatiquement un micro-bootstrap avant et après l’exécution d’instructions arithmétiques pour récupérer le budget de bruit. Dans le même temps, Fhenix a conçu un module de pontage d’oracle hors chaîne pour effectuer des vérifications de preuve avant d’interagir avec l’état du texte chiffré sur la chaîne avec des données en clair hors chaîne, réduisant ainsi le coût de la vérification sur la chaîne. Par rapport à Zama, Fhenix se concentre davantage sur la compatibilité EVM et l’accès transparent aux contrats on-chain
2.2 TEE
Réseau Oasis : en s’appuyant sur Intel SGX, Oasis introduit le concept de « racine de confiance » qui utilise le service de devis SGX pour vérifier la fiabilité du matériel au niveau de la couche inférieure, et un micronoyau léger au niveau de la couche intermédiaire qui isole les instructions suspectes et réduit la surface d’attaque du connecteur de segment SGX. L’interface de ParaTime utilise la sérialisation binaire Cap’n Proto pour assurer une communication efficace à travers ParaTime. Dans le même temps, Oasis a développé le module « Sustainability Log », qui écrit les modifications d’état critiques dans un journal de confiance pour prévenir les attaques de retour en arrière.
2.3 ZKP
Aztec : En plus de la compilation Noir, Aztec intègre la technologie de "récursion incrémentale" dans la génération de preuves, en regroupant récursivement plusieurs preuves de transaction selon une séquence temporelle, puis en générant une petite taille SNARK. Le générateur de preuves est écrit en Rust et utilise un algorithme de recherche en profondeur parallélisé, permettant une accélération linéaire sur des CPU multi-cœurs. De plus, pour réduire l'attente des utilisateurs, Aztec propose un "mode nœud léger", où les nœuds n'ont besoin de télécharger et de vérifier zkStream plutôt que la preuve complète, optimisant ainsi encore plus la bande passante.
2.4 MPC
Partisia Blockchain : Son implémentation MPC est basée sur l’extension du protocole SPDZ, en ajoutant un « module de prétraitement » pour pré-générer des triples Beaver hors chaîne afin d’accélérer les opérations de phase en ligne. Les nœuds de chaque partition interagissent via la communication gRPC et les canaux chiffrés TLS 1.3 pour garantir la sécurité de la transmission des données. Le mécanisme de partitionnement parallèle de Partisia prend également en charge l’équilibrage de charge dynamique, qui ajuste la taille de la partition en temps réel en fonction de la charge du nœud.
Trois, Calcul de la vie privée FHE, TEE, ZKP et MPC
Source de l'image : @tpcventures
3.1 Aperçu des différentes solutions de calcul de la confidentialité
Le calcul de la confidentialité est actuellement un sujet brûlant dans le domaine de la blockchain et de la sécurité des données, les principales technologies comprennent le chiffrement homomorphe complet (FHE), l'environnement d'exécution de confiance (TEE) et le calcul sécurisé multipartite (MPC).
Chiffrement entièrement homomorphe (FHE) : Un schéma de cryptage qui permet le calcul arbitraire de données cryptées sans décryptage, et réalise le cryptage complet de l’entrée, du processus de calcul et de la sortie. Il est sûr sur la base de problèmes mathématiques complexes (tels que les problèmes de treillis) et possède des capacités de calcul théoriquement complètes, mais la surcharge de calcul est extrêmement élevée. Ces dernières années, l’industrie et le monde universitaire ont amélioré leurs performances grâce à des algorithmes optimisés, des bibliothèques dédiées (par exemple, TFHE-rs de Zama, Concrete) et l’accélération matérielle (Intel HEXL, FPGA/ASIC), mais il s’agit toujours d’une technologie à rupture lente et rapide.
Environnement d'exécution de confiance (TEE) : Module matériel de confiance fourni par le processeur (comme Intel SGX, AMD SEV, ARM TrustZone) capable d'exécuter du code dans une zone de mémoire sécurisée isolée, empêchant les logiciels et systèmes d'exploitation externes d'accéder aux données et à l'état d'exécution. Le TEE repose sur une racine de confiance matérielle, avec des performances proches du calcul natif et généralement peu de surcoûts. Le TEE peut offrir une exécution confidentielle aux applications, mais sa sécurité dépend de la mise en œuvre matérielle et du firmware fourni par le fabricant, présentant des risques potentiels de portes dérobées et de canaux auxiliaires.
Multi-Party Secure Computation (MPC) : à l’aide d’un protocole de cryptographie, plusieurs parties peuvent calculer conjointement la sortie d’une fonction sans révéler leurs propres entrées privées. MPC ne dispose pas d’un point de confiance unique, mais l’informatique nécessite une interaction multipartite, une surcharge de communication et les performances sont limitées par la latence du réseau et la bande passante. Par rapport à FHE, MPC est beaucoup moins coûteux en termes de calcul, mais sa mise en œuvre est plus complexe et nécessite un protocole et une architecture minutieux.
Zero-knowledge proofs (ZKP) : Techniques de cryptographie qui permettent aux vérificateurs de vérifier qu’une déclaration est vraie sans révéler d’informations supplémentaires. Un prouveur peut prouver à un vérificateur qu’il dispose d’une information secrète, telle qu’un mot de passe, mais il n’est pas obligé d’exposer directement cette information. Les implémentations typiques incluent les zk-SNARK basés sur des courbes elliptiques et les zk-STAR basés sur le hachage.
Quels sont les scénarios d'adaptation pour FHE, TEE, ZKP et MPC ?
Source de l'image : biblicalscienceinstitute
Les différentes technologies informatiques de préservation de la vie privée ont leur propre importance, et la clé réside dans les exigences du scénario. Prenons l’exemple des signatures inter-chaînes, qui nécessitent une collaboration multipartite et évitent l’exposition d’une clé privée en un seul point, auquel cas MPC est plus pratique. À l’instar de la signature de seuil, plusieurs nœuds enregistrent chacun une partie du fragment de clé et le signent ensemble, de sorte que personne ne puisse contrôler la clé privée seul. Il existe des solutions plus avancées, telles que le réseau Ika, qui traite les utilisateurs comme un nœud système comme l’autre, et utilise 2PC-MPC pour signer en parallèle, qui peut traiter des milliers de signatures à la fois, et peut être mis à l’échelle horizontalement, plus il y a de nœuds, plus c’est rapide. Cependant, TEE peut également effectuer des signatures inter-chaînes et peut exécuter une logique de signature via des puces SGX, ce qui est rapide et facile à déployer, mais le problème est qu’une fois que le matériel est violé, la clé privée est également divulguée et la confiance est entièrement épinglée sur la puce et le fabricant. FHE est faible dans ce domaine, car le calcul de signature n’appartient pas au mode « addition et multiplication » pour lequel il est bon, bien qu’il puisse être fait théoriquement, mais la surcharge est trop importante, et fondamentalement personne ne le fait dans un système réel.
Dans les scénarios DeFi, tels que les portefeuilles multisig, l’assurance coffre-fort et la conservation institutionnelle, le multisig lui-même est sécurisé, mais le problème réside dans la façon de sauvegarder la clé privée et de partager le risque. MPC est maintenant un moyen plus courant, comme Fireblocks et d’autres fournisseurs de services, la signature est divisée en plusieurs parties, différents nœuds participent à la signature et tout nœud est piraté sans problème. La conception d’Ika est également très intéressante, utilisant un modèle bipartite pour obtenir la « non-collusion » des clés privées, réduisant ainsi la possibilité d’un MPC traditionnel « tout le monde est d’accord pour faire le mal ensemble ». TEE dispose également d’applications à cet égard, telles que des portefeuilles matériels ou des services de portefeuille cloud, qui utilisent un environnement d’exécution approuvé pour assurer l’isolation des signatures, mais il ne peut toujours pas éviter le problème de confiance matérielle. FHE n’a pas beaucoup de rôle direct au niveau de la conservation à l’heure actuelle, mais plutôt pour protéger les détails de la transaction et la logique du contrat, par exemple, si vous effectuez une transaction privée, les autres ne peuvent pas voir le montant et l’adresse, mais cela n’a rien à voir avec le séquestre de clé privée. Par conséquent, dans ce scénario, MPC se concentre davantage sur la confiance décentralisée, TEE met l’accent sur les performances et FHE est principalement utilisé pour une logique de confidentialité de haut niveau.
En ce qui concerne l’IA et la confidentialité des données, la situation sera différente, et les avantages de FHE sont évidents ici. Il peut garder les données chiffrées du début à la fin, par exemple, si vous lancez des données médicales sur la chaîne pour l’inférence de l’IA, FHE peut faire en sorte que le modèle complète le jugement sans voir le texte en clair, puis produire les résultats afin que personne ne puisse voir les données dans l’ensemble du processus. Cette capacité de « calcul chiffré » est idéale pour gérer des données sensibles, en particulier lors de la collaboration entre chaînes ou institutions. Par exemple, Mind Network envisage de permettre aux nœuds PoS d’effectuer la vérification du vote sans se connaître via FHE, ce qui empêcherait les nœuds de copier les réponses et garantirait la confidentialité de l’ensemble du processus. MPC peut également être utilisé pour l’apprentissage fédéré, par exemple lorsque différentes institutions coopèrent pour entraîner des modèles, chacune contenant des données locales sans partage et n’échangeant que des résultats intermédiaires. Cependant, une fois qu’il y aura plus de participants à cette méthode, le coût et la synchronisation de la communication deviendront un problème, et la plupart des projets sont encore expérimentaux. Bien que TEE puisse exécuter directement des modèles dans un environnement protégé, et que certaines plateformes d’apprentissage fédérées l’utilisent pour l’agrégation de modèles, il présente également des limites évidentes, telles que des limitations de mémoire et des attaques par canal auxiliaire. Par conséquent, dans les scénarios liés à l’IA, la capacité de « chiffrement complet » de FHE est la plus importante, et MPC et TEE peuvent être utilisés comme outils auxiliaires, mais des solutions spécifiques sont toujours nécessaires.
Performance et latence : FHE (Zama/Fhenix) a une latence élevée en raison de Bootstrapping fréquent, mais peut offrir la meilleure protection des données en état chiffré ; TEE (Oasis) a la latence la plus basse, proche de l'exécution normale, mais nécessite une confiance matérielle ; ZKP (Aztec) a une latence contrôlable lors de la preuve en lot, la latence des transactions individuelles se situant entre les deux ; MPC (Partisia) a une latence moyenne-basse, affectée principalement par la communication réseau.
Hypothèse de confiance : FHE et ZKP reposent tous deux sur des problèmes mathématiques, sans avoir besoin de faire confiance à un tiers ; TEE dépend du matériel et des fabricants, avec un risque de vulnérabilités dans le firmware ; MPC repose sur un modèle semi-honnête ou au maximum t anomalies, sensible au nombre de participants et aux hypothèses de comportement.
Scalabilité : ZKP Rollup (Aztec) et le partitionnement MPC (Partisia) prennent en charge nativement l'évolutivité horizontale ; l'évolutivité FHE et TEE doit tenir compte des ressources de calcul et de l'offre de nœuds matériels.
Difficulté d'intégration : Le projet TEE a le seuil d'entrée le plus bas et nécessite le moins de modifications du modèle de programmation ; ZKP et FHE nécessitent des circuits dédiés et des processus de compilation ; MPC nécessite une intégration de pile de protocoles et une communication inter-nœuds.
Quatrième, le point de vue général du marché : « FHE est supérieur à TEE, ZKP ou MPC » ?
Il semble que, que ce soit FHE, TEE, ZKP ou MPC, les quatre présentent un problème d'impossible triangle dans la résolution de cas d'utilisation pratiques : "performance, coût, sécurité". Bien que FHE soit attractif en matière de protection de la vie privée théorique, il n'est pas supérieur à TEE, MPC ou ZKP dans tous les aspects. Le coût de la faible performance rend FHE difficile à promouvoir, sa vitesse de calcul étant bien inférieure à celle des autres solutions. Dans les applications sensibles à la réactivité et au coût, TEE, MPC ou ZKP sont souvent plus viables.
La confiance et les cas d'utilisation diffèrent également : TEE et MPC offrent chacun des modèles de confiance et une commodité de déploiement différents, tandis que ZKP se concentre sur la vérification de l'exactitude. Comme le soulignent les opinions du secteur, différents outils de confidentialité ont chacun des avantages et des limites, il n'existe pas de solution optimale "taille unique". Par exemple, pour la vérification des calculs complexes hors chaîne, ZKP peut résoudre efficacement ; pour les calculs nécessitant que plusieurs parties partagent des états privés, MPC est plus direct ; TEE offre un support mature sur les plateformes mobiles et dans le cloud ; tandis que FHE est adapté au traitement de données extrêmement sensibles, mais nécessite encore une accélération matérielle pour fonctionner.
FHE n’est pas une solution unique, et le choix de la technologie devrait dépendre du compromis entre les besoins de l’application et les performances, et peut-être que l’avenir de l’informatique de confidentialité est souvent le résultat de la complémentarité et de l’intégration de plusieurs technologies, plutôt que d’une seule solution. Par exemple, IKA est conçu en mettant l’accent sur le partage de clés et la coordination des signatures (l’utilisateur conserve toujours une copie de la clé privée), et sa valeur principale est de permettre un contrôle décentralisé des actifs sans avoir besoin de conservation. En revanche, ZKP excelle dans la génération de preuves mathématiques pour la vérification en chaîne de l’état ou des résultats de calcul. Les deux ne sont pas simplement des substituts ou des concurrents, mais plutôt des technologies complémentaires : ZKP peut être utilisé pour vérifier l’exactitude des interactions inter-chaînes, réduisant ainsi dans une certaine mesure le besoin de confiance dans la partie qui fait le pont, tandis que le réseau MPC d’Ika fournit la base sous-jacente pour le « contrôle des actifs » qui peut être combiné avec ZKP pour construire des systèmes plus complexes. De plus, Nillion a commencé à intégrer plusieurs technologies de confidentialité pour améliorer les capacités globales, et son architecture informatique aveugle a intégré de manière transparente MPC, FHE, TEE et ZKP pour équilibrer la sécurité, le coût et les performances. Par conséquent, à l’avenir, l’écosystème informatique respectueux de la vie privée aura tendance à utiliser la combinaison la plus appropriée de composants techniques pour construire des solutions modulaires.
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Regardez la lutte technologique entre FHE, TEE, ZKP et MPC à travers le réseau MPC sous seconde lancé par Sui.
Auteur original : YBB Capital Researcher Ac-Core
I. Vue d'ensemble et positionnement du réseau Ika
Source de l'image : Ika
Le réseau Ika, soutenu stratégiquement par la fondation Sui, a récemment dévoilé sa position technique et sa direction de développement. En tant qu'infrastructure innovante basée sur la technologie de calcul sécurisée multiparty (MPC), la caractéristique la plus marquante de ce réseau est sa vitesse de réponse en sous-seconde, ce qui est une première parmi les solutions MPC similaires. L'adéquation technique entre lka et la blockchain Sui est particulièrement remarquable, les deux étant hautement compatibles en termes de traitement parallèle, d'architecture décentralisée et d'autres concepts de conception sous-jacents. À l'avenir, Ika sera directement intégré dans l'écosystème de développement Sui, fournissant un module de sécurité inter-chaînes plug-and-play pour les contrats intelligents Sui Move.
D'un point de vue fonctionnel, Ika est en train de construire une nouvelle couche de validation sécurisée : elle sert à la fois de protocole de signature dédié à l'écosystème Sui et propose des solutions inter-chaînes standardisées pour l'ensemble de l'industrie. Sa conception en couches prend en compte la flexibilité du protocole et la facilité de développement, et il y a une certaine probabilité qu'elle devienne un cas pratique important pour l'application à grande échelle de la technologie MPC dans des scénarios multi-chaînes.
1.1 Analyse des technologies clés
La mise en œuvre technique du réseau IKA s’articule autour de signatures distribuées haute performance, et son innovation réside dans l’utilisation du protocole de signature de seuil 2PC-MPC avec l’exécution parallèle de Sui et le consensus DAG pour obtenir de véritables capacités de signature en moins d’une seconde et une participation décentralisée des nœuds à grande échelle. Grâce au protocole 2PC-MPC, aux signatures distribuées parallèles et à une intégration étroite avec la structure de consensus Sui, Ika souhaite créer un réseau multi-signatures qui répond aux besoins de performances ultra-élevées et de sécurité stricte. Sa principale innovation réside dans l’introduction de la communication de diffusion et du traitement parallèle dans le protocole de signature de seuil, et voici une ventilation des fonctions de base.
Protocole de signature 2PC-MPC : Ika adopte un schéma MPC à deux parties amélioré (2PC-MPC), qui décompose essentiellement l'opération de signature de la clé privée de l'utilisateur en un processus impliquant deux rôles : "l'utilisateur" et "le réseau Ika". Le processus complexe qui nécessitait auparavant une communication pair à pair entre les nœuds (similaire à chaque personne dans un groupe de discussion qui envoie des messages privés à tous) est transformé en mode de diffusion (similaire à une annonce de groupe), ce qui maintient également le coût de communication et de calcul au niveau constant pour l'utilisateur, indépendant de l'échelle du réseau, permettant ainsi à la latence de la signature de rester au niveau subsecond.
Traitement parallèle, décomposer les tâches pour travailler simultanément : Ika utilise le calcul parallèle pour décomposer une opération de signature unique en plusieurs sous-tâches concurrentes exécutées simultanément entre les nœuds, dans le but d'accélérer considérablement la vitesse. Cela intègre le modèle de parallélisme objet de Sui, permettant au réseau de ne pas avoir à atteindre un consensus d'ordre global pour chaque transaction, traitant ainsi de nombreuses transactions simultanément, augmentant le débit et réduisant la latence. Le consensus Mysticeti de Sui élimine le délai de validation des blocs grâce à une structure DAG, permettant une soumission instantanée des blocs, permettant ainsi à Ika d'obtenir une confirmation finale en moins d'une seconde sur Sui.
Réseau de nœuds à grande échelle : alors que les solutions MPC traditionnelles ne prennent généralement en charge que 4 à 8 nœuds, IKA peut s’adapter à des milliers de nœuds pour participer à la signature. Chaque nœud ne contient qu’une partie du fragment de clé, et même si certains nœuds sont compromis, la clé privée ne peut pas être récupérée individuellement. La distribution des nœuds est au cœur du modèle Zero Trust d’IKA, car des signatures valides ne peuvent être générées que lorsque les utilisateurs et les nœuds du réseau travaillent ensemble, et aucune partie ne peut opérer ou falsifier des signatures indépendamment.
Contrôle inter-chaînes et abstraction de la chaîne : En tant que réseau de signature modulaire, Ika permet aux contrats intelligents d’autres chaînes de contrôler directement les comptes (appelés dWallets) dans le réseau Ika. Plus précisément, pour que le contrat intelligent d’une chaîne (par exemple, Sui) puisse gérer des comptes de signature multipartites sur Ika, il doit vérifier l’état de la chaîne dans le réseau Ika. Pour ce faire, IKA déploie les preuves d’état de la chaîne dans son propre réseau. À l’heure actuelle, la preuve d’état Sui a été mise en œuvre en premier, de sorte que les contrats sur Sui peuvent intégrer dWallet en tant que bloc de construction dans la logique commerciale, et compléter la signature et l’exploitation d’autres actifs de la chaîne via le réseau IKA.
1.2 Ika peut-il activer de manière inverse l'écosystème Sui ?
Source de l'image : Ika
Après son lancement, Ika pourrait étendre les capacités de la blockchain Sui et apporter un certain soutien à l'infrastructure de l'écosystème Sui. Le jeton natif de Sui, SUI, et le jeton d'Ika, $IKA, seront utilisés conjointement. $IKA sera utilisé pour payer les frais de service de signature du réseau Ika, tout en servant également d'actif de mise pour les nœuds.
L'impact le plus significatif d'Ika sur l'écosystème Sui est d'apporter la capacité d'interopérabilité entre chaînes, son réseau MPC supporte l'accès aux actifs des chaînes comme Bitcoin, Ethereum, etc., avec une latence relativement faible et une sécurité élevée sur le réseau Sui, permettant ainsi des opérations DeFi inter-chaînes telles que le mining de liquidités et les prêts, ce qui contribue à renforcer la compétitivité de Sui dans ce domaine. En raison de sa rapidité de confirmation et de sa forte évolutivité, Ika a déjà été intégré par plusieurs projets Sui, ce qui a également, dans une certaine mesure, favorisé le développement de l'écosystème.
En matière de sécurité des actifs, Ika propose un mécanisme de garde décentralisé. Les utilisateurs et les institutions peuvent gérer leurs actifs sur la chaîne grâce à son système de signatures multiples, offrant ainsi plus de flexibilité et de sécurité par rapport aux solutions de garde centralisées traditionnelles. Même les demandes de transaction initiées hors chaîne peuvent être exécutées en toute sécurité sur Sui.
Ika a également conçu une couche d'abstraction de chaîne, permettant aux contrats intelligents sur Sui d'opérer directement sur des comptes et des actifs d'autres chaînes, sans passer par des processus de pontage ou d'emballage d'actifs compliqués, ce qui simplifie tout le processus d'interaction inter-chaînes. L'intégration du Bitcoin natif permet également au BTC de participer directement aux opérations DeFi et de garde sur Sui.
Sur le dernier point, je pense également qu'Ika offre un mécanisme de validation multi-facettes pour les applications d'automatisation AI, capable d'éviter les opérations d'actifs non autorisées, augmentant ainsi la sécurité et la crédibilité lors de l'exécution des transactions par l'IA, tout en fournissant une possibilité pour l'expansion future de l'écosystème Sui dans le domaine de l'IA.
1.3 lka défis auxquels nous faisons face
Bien qu'Ika soit étroitement lié à Sui, pour devenir un "standard universel" d'interopérabilité multi-chaînes, il faut voir si d'autres blockchains et projets sont prêts à l'adopter. Il existe déjà de nombreuses solutions de cross-chain sur le marché, comme Axelar et LayerZero, qui sont largement utilisées dans différents scénarios. Pour se démarquer, Ika doit trouver un meilleur équilibre entre "décentralisation" et "performance", afin d'attirer davantage de développeurs et inciter plus d'actifs à migrer.
Parler de MPC suscite néanmoins de nombreuses controverses, la question courante étant que les droits de signature sont difficiles à révoquer. Tout comme avec les portefeuilles MPC traditionnels, une fois que la clé privée a été fragmentée et distribuée, même si elle est re-fragmentée, la personne qui a obtenu l'ancien fragment pourrait théoriquement toujours restaurer la clé privée d'origine. Bien que le schéma 2PC-MPC améliore la sécurité grâce à la participation continue des utilisateurs, je pense qu'il n'existe pas encore de mécanisme de solution particulièrement complet sur la question de "comment changer de nœud de manière sécurisée et efficace", ce qui pourrait représenter un point de risque potentiel.
IKA lui-même dépend également de la stabilité du réseau Sui et de ses propres conditions de réseau. Si Sui fait une mise à niveau majeure à l’avenir, comme la mise à jour du consensus Mysticeti vers MVs 2, Ika devra également s’adapter. Mysticeti, un consensus basé sur le DAG, prend en charge une concurrence élevée et des frais peu élevés, mais comme il n’a pas de structure de chaîne principale, il peut rendre le chemin du réseau plus complexe et l’ordre des transactions plus difficile. Couplé au fait qu’il s’agit d’une comptabilité asynchrone, bien qu’elle soit efficace, elle apporte également de nouveaux problèmes d’ordre et de sécurité consensuels. De plus, le modèle DAG est très dépendant des utilisateurs actifs, et si l’utilisation du réseau n’est pas élevée, il est sujet à des retards de confirmation des transactions et à une dégradation de la sécurité.
II. Comparaison des projets basés sur FHE, TEE, ZKP ou MPC
2.1 FHE
Zama & Concrete : En plus du compilateur à usage général basé sur MLIR, Concrete adopte la stratégie de « bootstrap hiérarchique », qui divise les grands circuits en plusieurs petits circuits et les crypte séparément, puis assemble dynamiquement les résultats, ce qui réduit considérablement le délai d’un seul bootstrapping. Il prend également en charge l’encodage hybride : l’encodage CRT pour les opérations d’entiers sensibles au retard et l’encodage au niveau du bit pour les opérations booléennes qui nécessitent un haut degré de parallélisme, d’équilibrage des performances et du parallélisme. De plus, Concrete fournit un mécanisme d'« emballage de clés », qui peut réutiliser plusieurs opérations isomorphes après une importation de clé, réduisant ainsi les frais de communication.
Fhenix : Basé sur TFHE, Fhenix a effectué plusieurs optimisations personnalisées pour le jeu d’instructions Ethereum EVM. Il remplace les registres en texte brut par des « registres virtuels de texte chiffré » qui insèrent automatiquement un micro-bootstrap avant et après l’exécution d’instructions arithmétiques pour récupérer le budget de bruit. Dans le même temps, Fhenix a conçu un module de pontage d’oracle hors chaîne pour effectuer des vérifications de preuve avant d’interagir avec l’état du texte chiffré sur la chaîne avec des données en clair hors chaîne, réduisant ainsi le coût de la vérification sur la chaîne. Par rapport à Zama, Fhenix se concentre davantage sur la compatibilité EVM et l’accès transparent aux contrats on-chain
2.2 TEE
Réseau Oasis : en s’appuyant sur Intel SGX, Oasis introduit le concept de « racine de confiance » qui utilise le service de devis SGX pour vérifier la fiabilité du matériel au niveau de la couche inférieure, et un micronoyau léger au niveau de la couche intermédiaire qui isole les instructions suspectes et réduit la surface d’attaque du connecteur de segment SGX. L’interface de ParaTime utilise la sérialisation binaire Cap’n Proto pour assurer une communication efficace à travers ParaTime. Dans le même temps, Oasis a développé le module « Sustainability Log », qui écrit les modifications d’état critiques dans un journal de confiance pour prévenir les attaques de retour en arrière.
2.3 ZKP
Aztec : En plus de la compilation Noir, Aztec intègre la technologie de "récursion incrémentale" dans la génération de preuves, en regroupant récursivement plusieurs preuves de transaction selon une séquence temporelle, puis en générant une petite taille SNARK. Le générateur de preuves est écrit en Rust et utilise un algorithme de recherche en profondeur parallélisé, permettant une accélération linéaire sur des CPU multi-cœurs. De plus, pour réduire l'attente des utilisateurs, Aztec propose un "mode nœud léger", où les nœuds n'ont besoin de télécharger et de vérifier zkStream plutôt que la preuve complète, optimisant ainsi encore plus la bande passante.
2.4 MPC
Partisia Blockchain : Son implémentation MPC est basée sur l’extension du protocole SPDZ, en ajoutant un « module de prétraitement » pour pré-générer des triples Beaver hors chaîne afin d’accélérer les opérations de phase en ligne. Les nœuds de chaque partition interagissent via la communication gRPC et les canaux chiffrés TLS 1.3 pour garantir la sécurité de la transmission des données. Le mécanisme de partitionnement parallèle de Partisia prend également en charge l’équilibrage de charge dynamique, qui ajuste la taille de la partition en temps réel en fonction de la charge du nœud.
Trois, Calcul de la vie privée FHE, TEE, ZKP et MPC
Source de l'image : @tpcventures
3.1 Aperçu des différentes solutions de calcul de la confidentialité
Le calcul de la confidentialité est actuellement un sujet brûlant dans le domaine de la blockchain et de la sécurité des données, les principales technologies comprennent le chiffrement homomorphe complet (FHE), l'environnement d'exécution de confiance (TEE) et le calcul sécurisé multipartite (MPC).
Quels sont les scénarios d'adaptation pour FHE, TEE, ZKP et MPC ?
Les différentes technologies informatiques de préservation de la vie privée ont leur propre importance, et la clé réside dans les exigences du scénario. Prenons l’exemple des signatures inter-chaînes, qui nécessitent une collaboration multipartite et évitent l’exposition d’une clé privée en un seul point, auquel cas MPC est plus pratique. À l’instar de la signature de seuil, plusieurs nœuds enregistrent chacun une partie du fragment de clé et le signent ensemble, de sorte que personne ne puisse contrôler la clé privée seul. Il existe des solutions plus avancées, telles que le réseau Ika, qui traite les utilisateurs comme un nœud système comme l’autre, et utilise 2PC-MPC pour signer en parallèle, qui peut traiter des milliers de signatures à la fois, et peut être mis à l’échelle horizontalement, plus il y a de nœuds, plus c’est rapide. Cependant, TEE peut également effectuer des signatures inter-chaînes et peut exécuter une logique de signature via des puces SGX, ce qui est rapide et facile à déployer, mais le problème est qu’une fois que le matériel est violé, la clé privée est également divulguée et la confiance est entièrement épinglée sur la puce et le fabricant. FHE est faible dans ce domaine, car le calcul de signature n’appartient pas au mode « addition et multiplication » pour lequel il est bon, bien qu’il puisse être fait théoriquement, mais la surcharge est trop importante, et fondamentalement personne ne le fait dans un système réel.
Dans les scénarios DeFi, tels que les portefeuilles multisig, l’assurance coffre-fort et la conservation institutionnelle, le multisig lui-même est sécurisé, mais le problème réside dans la façon de sauvegarder la clé privée et de partager le risque. MPC est maintenant un moyen plus courant, comme Fireblocks et d’autres fournisseurs de services, la signature est divisée en plusieurs parties, différents nœuds participent à la signature et tout nœud est piraté sans problème. La conception d’Ika est également très intéressante, utilisant un modèle bipartite pour obtenir la « non-collusion » des clés privées, réduisant ainsi la possibilité d’un MPC traditionnel « tout le monde est d’accord pour faire le mal ensemble ». TEE dispose également d’applications à cet égard, telles que des portefeuilles matériels ou des services de portefeuille cloud, qui utilisent un environnement d’exécution approuvé pour assurer l’isolation des signatures, mais il ne peut toujours pas éviter le problème de confiance matérielle. FHE n’a pas beaucoup de rôle direct au niveau de la conservation à l’heure actuelle, mais plutôt pour protéger les détails de la transaction et la logique du contrat, par exemple, si vous effectuez une transaction privée, les autres ne peuvent pas voir le montant et l’adresse, mais cela n’a rien à voir avec le séquestre de clé privée. Par conséquent, dans ce scénario, MPC se concentre davantage sur la confiance décentralisée, TEE met l’accent sur les performances et FHE est principalement utilisé pour une logique de confidentialité de haut niveau.
En ce qui concerne l’IA et la confidentialité des données, la situation sera différente, et les avantages de FHE sont évidents ici. Il peut garder les données chiffrées du début à la fin, par exemple, si vous lancez des données médicales sur la chaîne pour l’inférence de l’IA, FHE peut faire en sorte que le modèle complète le jugement sans voir le texte en clair, puis produire les résultats afin que personne ne puisse voir les données dans l’ensemble du processus. Cette capacité de « calcul chiffré » est idéale pour gérer des données sensibles, en particulier lors de la collaboration entre chaînes ou institutions. Par exemple, Mind Network envisage de permettre aux nœuds PoS d’effectuer la vérification du vote sans se connaître via FHE, ce qui empêcherait les nœuds de copier les réponses et garantirait la confidentialité de l’ensemble du processus. MPC peut également être utilisé pour l’apprentissage fédéré, par exemple lorsque différentes institutions coopèrent pour entraîner des modèles, chacune contenant des données locales sans partage et n’échangeant que des résultats intermédiaires. Cependant, une fois qu’il y aura plus de participants à cette méthode, le coût et la synchronisation de la communication deviendront un problème, et la plupart des projets sont encore expérimentaux. Bien que TEE puisse exécuter directement des modèles dans un environnement protégé, et que certaines plateformes d’apprentissage fédérées l’utilisent pour l’agrégation de modèles, il présente également des limites évidentes, telles que des limitations de mémoire et des attaques par canal auxiliaire. Par conséquent, dans les scénarios liés à l’IA, la capacité de « chiffrement complet » de FHE est la plus importante, et MPC et TEE peuvent être utilisés comme outils auxiliaires, mais des solutions spécifiques sont toujours nécessaires.
3.3 Différences entre les différentes options
! Regard sur le jeu technique entre FHE, TEE, ZKP et MPC à partir du réseau MPC lka lancé par Sui
Performance et latence : FHE (Zama/Fhenix) a une latence élevée en raison de Bootstrapping fréquent, mais peut offrir la meilleure protection des données en état chiffré ; TEE (Oasis) a la latence la plus basse, proche de l'exécution normale, mais nécessite une confiance matérielle ; ZKP (Aztec) a une latence contrôlable lors de la preuve en lot, la latence des transactions individuelles se situant entre les deux ; MPC (Partisia) a une latence moyenne-basse, affectée principalement par la communication réseau.
Hypothèse de confiance : FHE et ZKP reposent tous deux sur des problèmes mathématiques, sans avoir besoin de faire confiance à un tiers ; TEE dépend du matériel et des fabricants, avec un risque de vulnérabilités dans le firmware ; MPC repose sur un modèle semi-honnête ou au maximum t anomalies, sensible au nombre de participants et aux hypothèses de comportement.
Scalabilité : ZKP Rollup (Aztec) et le partitionnement MPC (Partisia) prennent en charge nativement l'évolutivité horizontale ; l'évolutivité FHE et TEE doit tenir compte des ressources de calcul et de l'offre de nœuds matériels.
Difficulté d'intégration : Le projet TEE a le seuil d'entrée le plus bas et nécessite le moins de modifications du modèle de programmation ; ZKP et FHE nécessitent des circuits dédiés et des processus de compilation ; MPC nécessite une intégration de pile de protocoles et une communication inter-nœuds.
Quatrième, le point de vue général du marché : « FHE est supérieur à TEE, ZKP ou MPC » ?
Il semble que, que ce soit FHE, TEE, ZKP ou MPC, les quatre présentent un problème d'impossible triangle dans la résolution de cas d'utilisation pratiques : "performance, coût, sécurité". Bien que FHE soit attractif en matière de protection de la vie privée théorique, il n'est pas supérieur à TEE, MPC ou ZKP dans tous les aspects. Le coût de la faible performance rend FHE difficile à promouvoir, sa vitesse de calcul étant bien inférieure à celle des autres solutions. Dans les applications sensibles à la réactivité et au coût, TEE, MPC ou ZKP sont souvent plus viables.
La confiance et les cas d'utilisation diffèrent également : TEE et MPC offrent chacun des modèles de confiance et une commodité de déploiement différents, tandis que ZKP se concentre sur la vérification de l'exactitude. Comme le soulignent les opinions du secteur, différents outils de confidentialité ont chacun des avantages et des limites, il n'existe pas de solution optimale "taille unique". Par exemple, pour la vérification des calculs complexes hors chaîne, ZKP peut résoudre efficacement ; pour les calculs nécessitant que plusieurs parties partagent des états privés, MPC est plus direct ; TEE offre un support mature sur les plateformes mobiles et dans le cloud ; tandis que FHE est adapté au traitement de données extrêmement sensibles, mais nécessite encore une accélération matérielle pour fonctionner.
FHE n’est pas une solution unique, et le choix de la technologie devrait dépendre du compromis entre les besoins de l’application et les performances, et peut-être que l’avenir de l’informatique de confidentialité est souvent le résultat de la complémentarité et de l’intégration de plusieurs technologies, plutôt que d’une seule solution. Par exemple, IKA est conçu en mettant l’accent sur le partage de clés et la coordination des signatures (l’utilisateur conserve toujours une copie de la clé privée), et sa valeur principale est de permettre un contrôle décentralisé des actifs sans avoir besoin de conservation. En revanche, ZKP excelle dans la génération de preuves mathématiques pour la vérification en chaîne de l’état ou des résultats de calcul. Les deux ne sont pas simplement des substituts ou des concurrents, mais plutôt des technologies complémentaires : ZKP peut être utilisé pour vérifier l’exactitude des interactions inter-chaînes, réduisant ainsi dans une certaine mesure le besoin de confiance dans la partie qui fait le pont, tandis que le réseau MPC d’Ika fournit la base sous-jacente pour le « contrôle des actifs » qui peut être combiné avec ZKP pour construire des systèmes plus complexes. De plus, Nillion a commencé à intégrer plusieurs technologies de confidentialité pour améliorer les capacités globales, et son architecture informatique aveugle a intégré de manière transparente MPC, FHE, TEE et ZKP pour équilibrer la sécurité, le coût et les performances. Par conséquent, à l’avenir, l’écosystème informatique respectueux de la vie privée aura tendance à utiliser la combinaison la plus appropriée de composants techniques pour construire des solutions modulaires.
Contenu de référence :
( 1)
( 2)
( 3) caff.com/zh/archives/29752? ref= 416
( 4)