En tant que représentant de la voie d'expansion Rollup en L2, après le largage d'Arbitrum, l'ère zkSync sera lancée. Derrière les innombrables nouveaux designs et feuilles de route, quelle est la ligne principale de Rollup et quelle est la pensée évolutive ? Jetons un coup d'œil aujourd'hui.
Points principaux de cet article :
L'idée d'extension de la L1 rédigée pour la classe de troisième
Concevoir une solution Rollup à partir de zéro
Comment utiliser la preuve de connaissance zéro pour faire évoluer Rollup à nouveau
Commencer par une analogie
Pour Bitcoin et Ethereum, depuis leur naissance, il y a deux plus grandes critiques de la part des utilisateurs ordinaires :
Lent : La voie est étroite à l'origine, et s'il y a trop de voitures, elle sera bloquée.
Cher : les péages sur les pics plats ne sont pas bon marché. Si vous voulez passer rapidement pendant la période de pointe, vous devez utiliser la "capacité d'argent" pour ajouter de l'argent et laisser les mineurs piloter des hélicoptères pour vous attraper.
Ces deux critiques découlent de deux facteurs dans la conception de la blockchain :
Capacité de bloc : analogue à une voie, plus la capacité de bloc est grande, plus elle peut accueillir de voitures et moins elle est susceptible d'être bloquée.
Mécanisme d'incitation : quelle que soit la taille de l'allée, il y a une possibilité d'être bloqué. Dans ce cas, qui est autorisé à passer en premier ? Cela dépend de qui est pressé, mais vous ne pouvez pas simplement écouter les mots des gens , cela dépend de la volonté de payer, comme appeler une ambulance, ce sera plusieurs centaines.
Si la blockchain peut vraiment être comme une allée, alors la solution fondamentale est naturellement d'élargir l'allée, et en même temps de coopérer avec des moyens de prix pour guider le temps de sortir, et ne sortez pas si vous n'êtes pas dans un hâte.
Cependant, bien que l'élargissement des voies et l'augmentation de la capacité des blocs soient une solution attrayante pour l'efficacité du trafic, c'est un dernier recours dans la conception de la blockchain. Parce que plus la taille de bloc est grande, plus les exigences matérielles pour les mineurs sont élevées et moins il y a de mineurs qui peuvent répondre aux exigences ; selon cette idée, si vous voulez traiter des milliers de transactions par seconde comme Visa, vous finirez seulement par faire un autre Visa centralisé va à l'encontre de l'objectif principal de l'absence de confiance dans la blockchain.
N 'y a-t-il pas une autre solution? Oui, en plus des conseils de temps, nous pouvons également optimiser l'espace, y compris, mais sans s'y limiter :
Ouvrez différentes voies, une pour les gros camions, une pour les voitures et une pour les bus, sans interférer les unes avec les autres - Sur la base de cette idée, nous pouvons arriver à certaines chaînes principales, chaînes latérales ou Plasma avec leurs propres forces.
Optimisez la conception de l'itinéraire, détournez le trafic de manière appropriée, n'allez pas en ville pour faire quoi que ce soit, vous devez emprunter cette route principale, vous devez passer par le point de contrôle ici —— Sur la base de cette idée, nous pouvons partager.
Pourquoi devez-vous sortir ? Il n'est pas trop tard pour avoir une réunion à distance et parvenir à un accord, et il n'est pas trop tard pour signer un accord hors ligne —— Sur la base de cette idée, nous pouvons avoir une chaîne d'État (State Channel).
Vous n'êtes pas obligé de conduire seul lorsque vous sortez, vous pouvez également faire du covoiturage ou prendre les transports en commun —— Sur la base de cette idée, nous avons le protagoniste de cet article, Rollup.
En tant que bus sur la blockchain, la clé de Rollup est d'économiser de l'espace et de l'essence (gaz, jeu de mots):
Économisez de l'espace, il n'est donc pas facile de rester coincé et le péage partagé par chaque personne est bien inférieur à celui de conduire seul;
L'essence est économisée, donc le prix du billet est proche des gens et tout le monde peut se le permettre.
De cette manière, les deux créneaux de "lent" et "coûteux" sont résolus par Rollup.
Revenons à la blockchain et voyons le plan spécifique de Rollup.
Concevez un Rollup à partir de zéro ;
Au lieu de jeter un coup d'œil à la réponse standard (sans oublier qu'il n'y en a pas), il est préférable d'avoir un peu de suspense et d'imaginer ce que vous ferez lorsque vous serez chargé de concevoir Rollup pour Ethereum.
Autant partir des deux perspectives de réduction des coûts de calcul (économie d'essence) et de réduction des coûts de stockage (économie d'espace), et d'abord proposer une solution plus radicale appelée Rollup 1.0 ;.
Cumul 1.0 ;
Rollup 1.0 se compose de 3 points principaux :
Il existe un prestataire (Opérateur) qui collecte les transactions de "covoiturage" de chacun (Transaction), et "envoie les commandes" lorsque le covoiturage est complet ou non mais que l'heure convenue est écoulée, en tenant compte du prix et du délai ;
Tous les calculs impliqués dans les transactions soumises par tout le monde sont effectués hors chaîne par ce fournisseur de services, car les calculs hors chaîne sont plus rapides que ceux en chaîne, et les calculs représentent souvent l'essentiel des coûts en chaîne, ce qui peut économiser beaucoup de temps. argent;
Après le calcul, obtenez le statut mis à jour (comme le dernier solde de votre compte) et stockez-le sur la chaîne, de sorte que le coût de stockage soit bien inférieur.
Pour faire simple, il s'agit de collecter régulièrement et quantitativement les demandes de transaction de chacun, et après calculs off-chain, seuls les résultats des calculs sont figés sur la chaîne.
Cette solution résout parfaitement les deux principaux points douloureux du « lent » et du « coûteux », mais elle semble générer de nouveaux problèmes :
Incentive : Qui fournira le service de « covoiturage » et quels en sont les avantages.
Problème de révision (Censure) : Le fournisseur de services ne traite pas délibérément ma commande (ou raccroche ou quitte), que dois-je faire ;
Problème de fraude (Fraude): Que dois-je faire si le fournisseur de services triche et falsifie les résultats du calcul, me faisant transférer de l'argent à d'autres, et que l'argent est détourné par lui.
Pour ces trois nouveaux problèmes, nous pouvons itérer une version du plan.
Rollup 2.0 ;
Le problème de la motivation est mieux résolu, et les problèmes qui peuvent être résolus avec de l'argent ne sont pas des problèmes. Le fournisseur de services peut partager le coût du "covoiturage" à parts égales et facturer un petit "pourboire" supplémentaire. Même ainsi, il s'agit toujours d'une situation gagnant-gagnant avec la personne "covoiturage".
Le problème de révision est un peu plus gênant, mais la solution est très courante dans le domaine de la blockchain, et c'est la décentralisation. Un groupe de personnes est un fournisseur de services, ce qui est mieux qu'un seul fournisseur de services ; n'importe qui peut être un fournisseur de services, ce qui est mieux qu'un groupe fixe de personnes. Dans cette dernière façon de jouer, si tous les fournisseurs de services ne sont pas bons, vous pouvez également être vous-même fournisseur de services, ou passer directement en L1 pour initier l'arbitrage.
La fraude est un peu plus difficile. Il peut être décomposé en deux questions : l'une est de savoir comment identifier la fraude et l'autre comment la prévenir.
Tout d'abord, pour identifier la fraude, il faut connaître les données de transaction (Transaction) de chacun, l'état avant la transaction (State), afin de calculer le nouvel état (State') après la transaction, et le comparer avec le nouvel état stocké sur la chaîne du fournisseur de services. Si c'est le même, cela signifie que le fournisseur de services est honnête, sinon cela signifie qu'il a menti. Cependant, nous ne connaissons pas les données de transaction car elles ne sont pas en chaîne. Par conséquent, nous ne pouvons qu'être sceptiques et incapables de juger si le prestataire est honnête ou non.
Ensuite, le meilleur moyen de prévenir la fraude est de rendre impossible la fraude. C'est relativement difficile, à moins que le calcul du prestataire ne soit vérifié à chaque fois sur la chaîne, mais de cette façon, il n'y aura aucun avantage à " faire du covoiturage". On ne peut donc que prendre du recul et rendre le coût de la fraude très élevé, pour que les prestataires de services aient la peau dans le jeu, comme par exemple verser un acompte (Stake), qui sera confisqué si une fraude est constatée. (Cette méthode est appelée consensus social, qui appartient à la sécurité basée sur le jeu, et est également mentionnée dans "Weekly #3;".)
Rollup 3.0 ;
Rollup 2.0 n'est pas mauvais, mais le problème de l'identification de la fraude n'est pas résolu.
Selon l'inférence précédente, pour identifier la fraude, nous devons connaître les données de transaction, donc cette partie des données doit être sur la même chaîne que les données d'état.
Qui va découvrir qu'ils sont frauduleux ? Évidemment, il est peu probable qu'il s'agisse d'un utilisateur ordinaire, car il est impossible pour tout le monde de surveiller chaque mouvement du fournisseur de services 7 x 24 heures, il ne peut donc s'agir que d'un "chasseur de primes" professionnel (Validator). Si un "chasseur de primes" signale une fraude dans les 7 jours suivant l'"envoi de la commande" par le prestataire de services et vérifie qu'elle est vraie, la transaction sera annulée et le prestataire de services sera sanctionné. Bien sûr, de la même manière, les "chasseurs de primes" ont aussi besoin d'incitations. Par exemple, après la découverte d'une fraude, une partie de la caution du prestataire sera reversée au "chasseur de primes" (une partie seulement, pour éviter la collusion entre les fournisseur de services et le chasseur de primes).
Rollup 4.0 ;
À l'étape Rollup 3.0, l'ensemble de la solution a pu fonctionner correctement, mais de nouveaux coûts ont été introduits. Les coûts comprennent jusqu'à présent :
Frais aux fournisseurs de services (y compris les coûts et les "pourboires");
Coût de stockage en chaîne des données de transaction et d'état ;
Lorsque le "Bounty Hunter" estime que le fournisseur de services est frauduleux, le coût de calcul de la vérification de ce qu'il a dit est vrai sur la chaîne.
Voyons quels coûts peuvent être optimisés.
données de transaction
D'une manière spécifique, plusieurs transactions sont agrégées ensemble, et l'espace occupé peut être inférieur à la somme de l'espace occupé par chaque transaction.
En prenant comme exemple la transaction de transfert ETH la plus simple, nous démontons la composition du contenu de chaque transaction, et nous pouvons voir que l'espace de signature représente la plus grande proportion. Nous pouvons combiner les signatures de toutes les transactions en une seule (Key Aggregation), ce qui permet d'économiser beaucoup de frais de stockage (similaire à Schnorr dans Bitcoin). De plus, nous pouvons également optimiser d'autres parties, comme se débarrasser de Nonce, et choisir "gros et mince" autant que possible lors du "covoiturage", et un "covoiturage personne" qui s'adapte parfaitement pour maximiser l'utilisation de la "voiture " espace.
source:
Trois ou deux fois seulement, la taille de chaque transaction de transfert ETH a été réduite de 112 octets à 12 octets, soit près d'un dixième de la précédente ; bien sûr, il existe d'autres moyens de compresser davantage les données de transaction.
En fonctionnement réel, on peut installer une telle méthode dans le contrat déployé sur la chaîne :
function storeTxData(bytes calldata data) external {;// ne rien faire}
Ensuite, chaque fois que le "covoiturage" réussit, les données de transaction fusionnées et compressées sont transmises à cette méthode en tant que données d'appel. Les données d'appel n'ont pas besoin d'être stockées de manière permanente, et après la période de défi publicitaire du consensus social (période de défi), peu importe si elles sont élaguées (Prune); le prix lui-même est très bas, et il sera moins cher avec la mise en œuvre de Pour les EIP tels que Danksharding et Data Blob , cette forme d'application de L1 à la distribution de stockage de données (Data Availability) sera également plus formelle.
données d'état
Maintenant que les données de transaction ont été téléchargées sur la chaîne, n'importe qui peut calculer l'état mis à jour via les données de transaction, et les données d'état ne sont plus si nécessaires. Nous ne pouvons conserver que la racine Merkel des données d'état, qui est utilisée pour permettre aux utilisateurs ordinaires ("covoitureurs") de demander des retraits directement à L1 lorsque le fournisseur de services ne coopère pas, et de s'appuyer sur Merkel Proof pour prouver qu'ils ont de l'argent dans leurs comptes.
Frais d'arbitrage de fraude
Lorsque le « chasseur de primes » signale une fraude au fournisseur de services, le calcul du contrat en chaîne (Replay) est effectué une seule fois et les résultats de statut sont comparés, ce qui est théoriquement faisable. Cependant, le coût de le faire n'est pas faible (bien qu'il soit déjà bon), et le second est que la somme du gaz des transactions incluses dans la "liste de covoiturage" Rollup peut dépasser la limite de gaz d'Ethereum, ce qui rend impossible vérifier.
Par conséquent, l'arbitrage doit réduire la charge, et le moyen de réduire la charge est naturellement de mettre les opérations de calcul inutiles hors chaîne. L'une des solutions s'appelle Interactive Proving. Le processus général est le suivant :
"Bounty Hunter" verse un acompte, puis signale et divise l'ensemble du processus de calcul en n segments dans l'ordre, soulignant que le fournisseur de services a fraudé dans le segment k (1 ;≤k≤n) ;
Le fournisseur de services a creusé et désassemblé le segment k en segment k, et a souligné quel segment du "chasseur de primes" était incorrect ;
Donc aller-retour, sachant que l'opération de calcul ne peut plus être forée ou démontée, par exemple, quand le "chasseur de primes" pense 1+;1;=;2;, le prestataire pense 1+;1;= ;3;;
A ce moment, le contrat sur la chaîne intervient, calcule 1+;1;, et obtient 2;, déterminant ainsi que le prestataire est frauduleux, confisquant son acompte, et en récompensant une partie au "chasseur de primes".
(Pendant tout le processus, si une partie ne répond pas dans un délai imparti, la partie échoue.)
De cette façon, le coût de l'arbitrage sur toute la chaîne est très, très faible.
Cela dit, nous avons complètement construit une solution Rollup. Parce que ce schéma suppose que le fournisseur de services est honnête par défaut, à moins qu'il n'y ait un rapport de "chasseur de primes", cette faction s'appelle le rollup de l'optimiste, le soi-disant Optimistic Rollup.
Alors, notre Rollup 4.0 est-il la meilleure solution ?
Réévolution du rollup
Après nos multiples itérations, Rollup 4.0 présente encore quelques imperfections :
La fraude doit être découverte par les "chasseurs de primes", mais s'il n'y a pas de fraude pendant une longue période, les "chasseurs de primes" peuvent fermer leurs portes parce qu'ils ne sont pas rentables, il y aura donc un écart (bien que peu probable, en raison de la Les parties prenantes de la chaîne de regroupement telles que les fournisseurs d'applications agiront très probablement en tant que "chasseurs de primes" );
Pour être sûr qu'il n'y a pas de fraude, basée sur le consensus social, vous devez attendre plusieurs jours, ce qui affectera les opérations telles que les retraits ;
Il y a beaucoup de données sur la chaîne, et le coût est toujours là ;
S'appuyant actuellement sur une couche d'extension Rollup, le débit peut être multiplié par 10. Est-il possible d'être plus élevé ?
Existe-t-il une solution qui puisse rendre la fraude impossible du tout, rendre la finalité (Finality) plus rapide, faire en sorte que moins de données soient téléchargées sur la chaîne et rendre l'expansion d'un ordre de grandeur supplémentaire ? Je ne veux pas trop, mais il existe une sorte de solution qui peut satisfaire presque toutes les imaginations - Zero Knowledge Rollup (ZK-Rollup en abrégé).
ZK-Rollup est une idée de Rollup utilisant la preuve de connaissance zéro (ZKP). Le soi-disant ZKP fait référence à la technologie qui convainc l'autre partie que vous connaissez cette information sans révéler aucune information sensible. Pour expliquer ZKP, il y a deux de mes exemples préférés :
Imaginez dans une ville européenne médiévale et j'ai une carte au trésor avec un trésor marqué dessus. Afin de vous prouver que j'ai une carte au trésor, mais sans vous faire connaître l'emplacement exact du trésor, je vous mets un bandeau sur les yeux, je vous traîne dans une voiture et je vous fais faire le tour de la ville pendant une demi-heure pour m'assurer vous perdez votre sens de l'orientation, Arrivez enfin à destination, sortez de la voiture et montrez-vous le trésor, puis vous ramènerez. C'est une forme naïve de ZKP.
Une autre analogie est plus courante. Supposons qu'il y ait un puzzle Sudoku, je connais la réponse mais pas vous, mais vous ne croyez pas que je sais ; je veux vous prouver que je sais, mais je ne veux pas que vous connaissiez la réponse. ce qu'il faut faire? Je peux mettre Sudoku sur la table avec des cartes, puis mettre les nombres ouverts vers le haut et les nombres qui doivent être remplis vers le bas, et vous laisser choisir de vérifier ma réponse par ligne ou par colonne. Si c'est par rangée, je regrouperai les nombres de chaque rangée, je les décomposerai et je vous montrerai que chaque rangée va de 1 à 9 ;. Vous pouvez le répéter plusieurs fois, vous pouvez donc croire que je connais vraiment la réponse avec une forte probabilité. C'est l'une des méthodes de preuve interactives de ZKP (car il est difficile d'obtenir une interaction en temps réel sur la chaîne dans la blockchain, une preuve non interactive est généralement utilisée et des défis aléatoires sont générés par la fonction Hash).
En termes moins rigoureux, l'idée centrale de ZKP est que le prouveur (Prover) cache d'abord la connaissance secrète, "commit" (Commit), puis le vérificateur (Verifier) lance un défi aléatoire (Challenge). s'il peut réussir le défi, alors il y a une forte probabilité qu'il ait la connaissance secrète correspondante.
ZKP doit répondre à 3 exigences :
Si le prouveur ment, il y a une forte probabilité d'échouer au défi (Soundness);
Si le prouveur a des connaissances, il pourra réussir le défi (Complétude) ;
Lors de l'interaction entre les deux parties, le prouveur ne divulguera aucune information utile (Zero-knowledgeness).
Afin de répondre à ces trois exigences, ZKP utilise une variété de problèmes NP, y compris la décomposition de nombres premiers la plus simple, et des logarithmes discrets (tels que Schnorr) et ainsi de suite.
ZKP n'est pas une technologie née pour la blockchain, mais elle peut être utilisée pour l'expansion L2, principalement parce qu'un bon ZKP a les caractéristiques utiles suivantes :
Le prouveur (prestataire de services) peut rapidement donner une preuve, afin de s'assurer que l'efficacité du calcul sous la chaîne est très élevée et ne deviendra pas un goulot d'étranglement ;
La taille de la preuve est petite, ou du moins proportionnelle à la quantité de calcul à prouver, et l'impact de la quantité de données est le plus faible possible, de sorte que le coût de stockage sur la chaîne est faible ;
Le vérificateur (contrat L1) peut vérifier rapidement si la preuve est valide, donc le coût de calcul sur la chaîne est faible.
Grâce à ces fonctionnalités, notre solution Rollup peut :
Il n'y a pas besoin de "bounty hunter", le contrat L1 peut détecter par lui-même la fraude sur place ;
Tant que la vérification ZKP est valide, les retraits peuvent être effectués immédiatement et la finalité est réduite de quelques jours à quelques minutes ;
Seul le diff entre les états est requis sur la chaîne, l'espace est très petit et le coût de stockage est très faible (un bonus supplémentaire - la confidentialité est également améliorée) ;
Grâce à l'optimisation logicielle et matérielle personnalisée du processus de preuve et de vérification, la capacité d'extension peut être augmentée d'un autre ordre de grandeur.
Bien sûr, tout mécanisme de sécurité aura des prérequis potentiels, et ZKP n'est pas une panacée pour la blockchain. ZKP a encore de nombreuses limitations à l'heure actuelle, qui doivent être surmontées étape par étape, telles que :
Prenons l'exemple du zk-SNARK le plus couramment utilisé sur la blockchain. De nombreux schémas doivent introduire autant de personnes ou d'entreprises de bonne réputation que possible au début, et effectuer une configuration de confiance pour générer un véritable nombre aléatoire et garantir que le processus de génération est vérifiable mais pas entièrement public (comme dans la cérémonie du Pouvoir du Tau, tant qu'une partie peut faire confiance, mais cela compte toujours comme un défaut). Bien sûr, certains nouveaux schémas zk-SNARK et des zk-STARK améliorés plus tard peuvent résoudre ce problème, mais parfois de nouveaux problèmes sont introduits.
De nombreux problèmes sont difficiles à résumer en problèmes ZKP, ce qui a conduit au fait que la programmabilité n'a pas été bien résolue depuis longtemps. Il est difficile de réaliser ZKP qui soit entièrement compatible avec EVM sur Ethereum, ou même s'il peut être atteint, mais d'autres aspects (tels que l'efficacité de la vérification) seront affectés.
source:
C'est pourquoi, dans ZK-Rollup, un domaine d'expansion tourné vers l'avenir, chaque progrès est louable et gratifiant.
source:
écrire à la fin
En ce qui concerne l'avenir de l'extension de capacité, l'auteur estime que par rapport à l'extension de capacité native de L1, la conception en couches incluant Rollup est une idée plus fiable. La modularisation, chaque couche résout les soucis de chaque couche, ce qui est moins risqué que l'empilement continu sur la L1 déjà "monolithique" ; de plus, la décentralisation de la L1 sous-jacente en raison de l'expansion de la capacité est théoriquement peu probable. La couche supérieure la trouve et fait ça monte. De plus, cette idée de conception en couches a des applications apparemment réussies dans des domaines autres que la blockchain. Le point de vue n'est pas nécessairement correct, mais c'est la connaissance actuelle de l'auteur.
Cet article tente de trier les raisons de réflexion et de conception de la solution d'extension Rollup sur un ton indépendant du projet. En raison du niveau limité, certains endroits sont encore un peu émoussés, ce qui peut non seulement ne pas l'expliquer en place, mais aussi augmenter la difficulté de compréhension ; en tant que champ vertical qui change chaque jour qui passe, l'auteur peut ne pas être conscient de et prendre en compte de nombreux nouveaux développements dans le temps. Sincèrement accueillir les amis pour corriger et communiquer.
Voir l'original
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.
Cet article traite des idées d'évolution et des raisons de conception de la solution d'extension Rollup
Auteur original : ORFEO
Source originale : Le SeeDAO
Le projet L2 est à nouveau à l'honneur.
En tant que représentant de la voie d'expansion Rollup en L2, après le largage d'Arbitrum, l'ère zkSync sera lancée. Derrière les innombrables nouveaux designs et feuilles de route, quelle est la ligne principale de Rollup et quelle est la pensée évolutive ? Jetons un coup d'œil aujourd'hui.
Points principaux de cet article :
Commencer par une analogie
Pour Bitcoin et Ethereum, depuis leur naissance, il y a deux plus grandes critiques de la part des utilisateurs ordinaires :
Ces deux critiques découlent de deux facteurs dans la conception de la blockchain :
Si la blockchain peut vraiment être comme une allée, alors la solution fondamentale est naturellement d'élargir l'allée, et en même temps de coopérer avec des moyens de prix pour guider le temps de sortir, et ne sortez pas si vous n'êtes pas dans un hâte.
Cependant, bien que l'élargissement des voies et l'augmentation de la capacité des blocs soient une solution attrayante pour l'efficacité du trafic, c'est un dernier recours dans la conception de la blockchain. Parce que plus la taille de bloc est grande, plus les exigences matérielles pour les mineurs sont élevées et moins il y a de mineurs qui peuvent répondre aux exigences ; selon cette idée, si vous voulez traiter des milliers de transactions par seconde comme Visa, vous finirez seulement par faire un autre Visa centralisé va à l'encontre de l'objectif principal de l'absence de confiance dans la blockchain.
N 'y a-t-il pas une autre solution? Oui, en plus des conseils de temps, nous pouvons également optimiser l'espace, y compris, mais sans s'y limiter :
En tant que bus sur la blockchain, la clé de Rollup est d'économiser de l'espace et de l'essence (gaz, jeu de mots):
De cette manière, les deux créneaux de "lent" et "coûteux" sont résolus par Rollup.
Revenons à la blockchain et voyons le plan spécifique de Rollup.
Concevez un Rollup à partir de zéro ;
Au lieu de jeter un coup d'œil à la réponse standard (sans oublier qu'il n'y en a pas), il est préférable d'avoir un peu de suspense et d'imaginer ce que vous ferez lorsque vous serez chargé de concevoir Rollup pour Ethereum.
Autant partir des deux perspectives de réduction des coûts de calcul (économie d'essence) et de réduction des coûts de stockage (économie d'espace), et d'abord proposer une solution plus radicale appelée Rollup 1.0 ;.
Cumul 1.0 ;
Rollup 1.0 se compose de 3 points principaux :
Pour faire simple, il s'agit de collecter régulièrement et quantitativement les demandes de transaction de chacun, et après calculs off-chain, seuls les résultats des calculs sont figés sur la chaîne.
Cette solution résout parfaitement les deux principaux points douloureux du « lent » et du « coûteux », mais elle semble générer de nouveaux problèmes :
Pour ces trois nouveaux problèmes, nous pouvons itérer une version du plan.
Rollup 2.0 ;
Le problème de la motivation est mieux résolu, et les problèmes qui peuvent être résolus avec de l'argent ne sont pas des problèmes. Le fournisseur de services peut partager le coût du "covoiturage" à parts égales et facturer un petit "pourboire" supplémentaire. Même ainsi, il s'agit toujours d'une situation gagnant-gagnant avec la personne "covoiturage".
Le problème de révision est un peu plus gênant, mais la solution est très courante dans le domaine de la blockchain, et c'est la décentralisation. Un groupe de personnes est un fournisseur de services, ce qui est mieux qu'un seul fournisseur de services ; n'importe qui peut être un fournisseur de services, ce qui est mieux qu'un groupe fixe de personnes. Dans cette dernière façon de jouer, si tous les fournisseurs de services ne sont pas bons, vous pouvez également être vous-même fournisseur de services, ou passer directement en L1 pour initier l'arbitrage.
La fraude est un peu plus difficile. Il peut être décomposé en deux questions : l'une est de savoir comment identifier la fraude et l'autre comment la prévenir.
Tout d'abord, pour identifier la fraude, il faut connaître les données de transaction (Transaction) de chacun, l'état avant la transaction (State), afin de calculer le nouvel état (State') après la transaction, et le comparer avec le nouvel état stocké sur la chaîne du fournisseur de services. Si c'est le même, cela signifie que le fournisseur de services est honnête, sinon cela signifie qu'il a menti. Cependant, nous ne connaissons pas les données de transaction car elles ne sont pas en chaîne. Par conséquent, nous ne pouvons qu'être sceptiques et incapables de juger si le prestataire est honnête ou non.
Ensuite, le meilleur moyen de prévenir la fraude est de rendre impossible la fraude. C'est relativement difficile, à moins que le calcul du prestataire ne soit vérifié à chaque fois sur la chaîne, mais de cette façon, il n'y aura aucun avantage à " faire du covoiturage". On ne peut donc que prendre du recul et rendre le coût de la fraude très élevé, pour que les prestataires de services aient la peau dans le jeu, comme par exemple verser un acompte (Stake), qui sera confisqué si une fraude est constatée. (Cette méthode est appelée consensus social, qui appartient à la sécurité basée sur le jeu, et est également mentionnée dans "Weekly #3;".)
Rollup 3.0 ;
Rollup 2.0 n'est pas mauvais, mais le problème de l'identification de la fraude n'est pas résolu.
Selon l'inférence précédente, pour identifier la fraude, nous devons connaître les données de transaction, donc cette partie des données doit être sur la même chaîne que les données d'état.
Qui va découvrir qu'ils sont frauduleux ? Évidemment, il est peu probable qu'il s'agisse d'un utilisateur ordinaire, car il est impossible pour tout le monde de surveiller chaque mouvement du fournisseur de services 7 x 24 heures, il ne peut donc s'agir que d'un "chasseur de primes" professionnel (Validator). Si un "chasseur de primes" signale une fraude dans les 7 jours suivant l'"envoi de la commande" par le prestataire de services et vérifie qu'elle est vraie, la transaction sera annulée et le prestataire de services sera sanctionné. Bien sûr, de la même manière, les "chasseurs de primes" ont aussi besoin d'incitations. Par exemple, après la découverte d'une fraude, une partie de la caution du prestataire sera reversée au "chasseur de primes" (une partie seulement, pour éviter la collusion entre les fournisseur de services et le chasseur de primes).
Rollup 4.0 ;
À l'étape Rollup 3.0, l'ensemble de la solution a pu fonctionner correctement, mais de nouveaux coûts ont été introduits. Les coûts comprennent jusqu'à présent :
Voyons quels coûts peuvent être optimisés.
données de transaction
D'une manière spécifique, plusieurs transactions sont agrégées ensemble, et l'espace occupé peut être inférieur à la somme de l'espace occupé par chaque transaction.
En prenant comme exemple la transaction de transfert ETH la plus simple, nous démontons la composition du contenu de chaque transaction, et nous pouvons voir que l'espace de signature représente la plus grande proportion. Nous pouvons combiner les signatures de toutes les transactions en une seule (Key Aggregation), ce qui permet d'économiser beaucoup de frais de stockage (similaire à Schnorr dans Bitcoin). De plus, nous pouvons également optimiser d'autres parties, comme se débarrasser de Nonce, et choisir "gros et mince" autant que possible lors du "covoiturage", et un "covoiturage personne" qui s'adapte parfaitement pour maximiser l'utilisation de la "voiture " espace.
source:
Trois ou deux fois seulement, la taille de chaque transaction de transfert ETH a été réduite de 112 octets à 12 octets, soit près d'un dixième de la précédente ; bien sûr, il existe d'autres moyens de compresser davantage les données de transaction.
En fonctionnement réel, on peut installer une telle méthode dans le contrat déployé sur la chaîne :
function storeTxData(bytes calldata data) external {;// ne rien faire}
Ensuite, chaque fois que le "covoiturage" réussit, les données de transaction fusionnées et compressées sont transmises à cette méthode en tant que données d'appel. Les données d'appel n'ont pas besoin d'être stockées de manière permanente, et après la période de défi publicitaire du consensus social (période de défi), peu importe si elles sont élaguées (Prune); le prix lui-même est très bas, et il sera moins cher avec la mise en œuvre de Pour les EIP tels que Danksharding et Data Blob , cette forme d'application de L1 à la distribution de stockage de données (Data Availability) sera également plus formelle.
données d'état
Maintenant que les données de transaction ont été téléchargées sur la chaîne, n'importe qui peut calculer l'état mis à jour via les données de transaction, et les données d'état ne sont plus si nécessaires. Nous ne pouvons conserver que la racine Merkel des données d'état, qui est utilisée pour permettre aux utilisateurs ordinaires ("covoitureurs") de demander des retraits directement à L1 lorsque le fournisseur de services ne coopère pas, et de s'appuyer sur Merkel Proof pour prouver qu'ils ont de l'argent dans leurs comptes.
Frais d'arbitrage de fraude
Lorsque le « chasseur de primes » signale une fraude au fournisseur de services, le calcul du contrat en chaîne (Replay) est effectué une seule fois et les résultats de statut sont comparés, ce qui est théoriquement faisable. Cependant, le coût de le faire n'est pas faible (bien qu'il soit déjà bon), et le second est que la somme du gaz des transactions incluses dans la "liste de covoiturage" Rollup peut dépasser la limite de gaz d'Ethereum, ce qui rend impossible vérifier.
Par conséquent, l'arbitrage doit réduire la charge, et le moyen de réduire la charge est naturellement de mettre les opérations de calcul inutiles hors chaîne. L'une des solutions s'appelle Interactive Proving. Le processus général est le suivant :
(Pendant tout le processus, si une partie ne répond pas dans un délai imparti, la partie échoue.)
De cette façon, le coût de l'arbitrage sur toute la chaîne est très, très faible.
Cela dit, nous avons complètement construit une solution Rollup. Parce que ce schéma suppose que le fournisseur de services est honnête par défaut, à moins qu'il n'y ait un rapport de "chasseur de primes", cette faction s'appelle le rollup de l'optimiste, le soi-disant Optimistic Rollup.
Alors, notre Rollup 4.0 est-il la meilleure solution ?
Réévolution du rollup
Après nos multiples itérations, Rollup 4.0 présente encore quelques imperfections :
Existe-t-il une solution qui puisse rendre la fraude impossible du tout, rendre la finalité (Finality) plus rapide, faire en sorte que moins de données soient téléchargées sur la chaîne et rendre l'expansion d'un ordre de grandeur supplémentaire ? Je ne veux pas trop, mais il existe une sorte de solution qui peut satisfaire presque toutes les imaginations - Zero Knowledge Rollup (ZK-Rollup en abrégé).
ZK-Rollup est une idée de Rollup utilisant la preuve de connaissance zéro (ZKP). Le soi-disant ZKP fait référence à la technologie qui convainc l'autre partie que vous connaissez cette information sans révéler aucune information sensible. Pour expliquer ZKP, il y a deux de mes exemples préférés :
En termes moins rigoureux, l'idée centrale de ZKP est que le prouveur (Prover) cache d'abord la connaissance secrète, "commit" (Commit), puis le vérificateur (Verifier) lance un défi aléatoire (Challenge). s'il peut réussir le défi, alors il y a une forte probabilité qu'il ait la connaissance secrète correspondante.
ZKP doit répondre à 3 exigences :
Afin de répondre à ces trois exigences, ZKP utilise une variété de problèmes NP, y compris la décomposition de nombres premiers la plus simple, et des logarithmes discrets (tels que Schnorr) et ainsi de suite.
ZKP n'est pas une technologie née pour la blockchain, mais elle peut être utilisée pour l'expansion L2, principalement parce qu'un bon ZKP a les caractéristiques utiles suivantes :
Grâce à ces fonctionnalités, notre solution Rollup peut :
Bien sûr, tout mécanisme de sécurité aura des prérequis potentiels, et ZKP n'est pas une panacée pour la blockchain. ZKP a encore de nombreuses limitations à l'heure actuelle, qui doivent être surmontées étape par étape, telles que :
source:
C'est pourquoi, dans ZK-Rollup, un domaine d'expansion tourné vers l'avenir, chaque progrès est louable et gratifiant.
source:
écrire à la fin
En ce qui concerne l'avenir de l'extension de capacité, l'auteur estime que par rapport à l'extension de capacité native de L1, la conception en couches incluant Rollup est une idée plus fiable. La modularisation, chaque couche résout les soucis de chaque couche, ce qui est moins risqué que l'empilement continu sur la L1 déjà "monolithique" ; de plus, la décentralisation de la L1 sous-jacente en raison de l'expansion de la capacité est théoriquement peu probable. La couche supérieure la trouve et fait ça monte. De plus, cette idée de conception en couches a des applications apparemment réussies dans des domaines autres que la blockchain. Le point de vue n'est pas nécessairement correct, mais c'est la connaissance actuelle de l'auteur.
Cet article tente de trier les raisons de réflexion et de conception de la solution d'extension Rollup sur un ton indépendant du projet. En raison du niveau limité, certains endroits sont encore un peu émoussés, ce qui peut non seulement ne pas l'expliquer en place, mais aussi augmenter la difficulté de compréhension ; en tant que champ vertical qui change chaque jour qui passe, l'auteur peut ne pas être conscient de et prendre en compte de nombreux nouveaux développements dans le temps. Sincèrement accueillir les amis pour corriger et communiquer.