Tard dans la nuit, après avoir passé en revue le livre blanc technique et le code source principal sur GitHub, j’ai enfin compris la complexité de la scalabilité hors chaîne (Off-chain Scaling). Par rapport au bruit du marché, la logique d’interaction sous-jacente est la clé.
J’avais tendance à comparer les différentes solutions Layer 2, mais lors de cette rétrospective, j’ai réalisé que ma compréhension de la "sécurité héritée" était encore insuffisante. Beaucoup considèrent Plasma comme une logique de side-chain simple, alors que le cœur réside dans la façon d’utiliser des contrats intelligents sur la chaîne principale pour faire respecter la validité des transitions d’état. C’est une différence fondamentale.
Le problème le plus épineux reste celui de la "disponibilité des données". Contrairement aux Rollups qui compressent et uploadent le calldata sur L1, Plasma choisit de laisser les données de transaction hors chaîne, ne soumettant que le Merkle Root du bloc à la chaîne principale. Cela permet effectivement de réduire considérablement le coût en Gas, mais introduit aussi une complexité dans la stratégie de jeu. Si un validateurs fait du mal en retenant les données, comment l’utilisateur peut-il prouver en toute sécurité, via Merkle, qu’il peut retirer ses fonds du sous-chaîne ?
Cela soulève la conception du mécanisme de "sortie". Les preuves de fraude interactives traditionnelles ont un problème de délai de contestation trop long, ce qui impacte la liquidité des fonds. La nouvelle architecture envisage d’introduire des preuves à connaissance zéro pour optimiser — en remplaçant une partie de la logique de preuve de fraude par une preuve d’efficacité — permettant, sans faire confiance à quiconque, d’améliorer significativement la performance finale de la confirmation d’état.
L’adaptation entre le modèle UTXO et le modèle basé sur les comptes est également très intéressante. En haute concurrence, il faut à la fois prévenir la double dépense et maintenir une structure d’état allégée. En regardant la logique de pruning de l’arbre d’état dans le code, on ne peut qu’admirer la finesse de cette architecture.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
14 J'aime
Récompense
14
7
Reposter
Partager
Commentaire
0/400
TokenomicsDetective
· 01-21 21:50
Travailler tard dans la nuit sur du code peut vraiment aider à ouvrir l'esprit, mais je reste un peu sceptique concernant la disponibilité des données de Plasma, j'ai l'impression que le risque est sous-estimé.
Voir l'originalRépondre0
CryptoNomics
· 01-21 21:49
Honnêtement, si vous effectuez une matrice de corrélation de base sur les contraintes de disponibilité des données de plasma vs la surcharge de calldata des rollups, les preuves empiriques indiquent un compromis de conception fondamental que la plupart des traders particuliers manquent complètement. Les chiffres ne mentent pas—mais les gens oui, sûrement.
Voir l'originalRépondre0
unrekt.eth
· 01-21 21:46
Travailler tard dans la nuit pour coder permet enfin de comprendre ce qu'est une véritable scalabilité, ce n'est pas en criant des slogans qu'on y parvient.
Ce mec a vraiment une conception géniale du mécanisme Plasma, je n'avais pas compris la partie sur la sortie du jeu auparavant, mais maintenant, avec l'optimisation zk, tout devient logique.
La disponibilité des données reste un point de douleur éternel...
Voir l'originalRépondre0
AirdropHunterZhang
· 01-21 21:44
Travailler tard dans la nuit sur du code, à quoi ça sert ? Ce qui compte, c'est de rentabiliser, c'est la règle d'or.
Voir l'originalRépondre0
ProofOfNothing
· 01-21 21:34
Je n'ai pas dormi encore tard dans la nuit en codant, c'est alors que j'ai compris à quel point Plasma et Rollups diffèrent... Regarder uniquement le livre blanc ne suffit vraiment pas
---
La disponibilité des données est vraiment compliquée, si le validateurs fait vraiment une erreur, comment on peut s'en sortir...
---
Donc, la logique de base est vraiment essentielle, ne croyez pas ceux qui se vantent dans la crypto
---
La preuve à divulgation zéro pour remplacer la preuve de fraude ? Ça a l'air bien, mais j'ai peur que ce soit encore une autre illusion...
---
Le pruning de l'arbre d'état est vraiment bien codé, il peut prévenir la double dépense en haute concurrence tout en restant léger
---
Pourquoi faut-il rendre tout si compliqué ? Ne peut-on pas faire plus simple...
---
Haha, les réflexions nocturnes sont toujours les plus sincères, demain matin, ce sera probablement une autre histoire
---
La compréhension de la sécurité héritée est vraiment difficile pour la plupart, moi y compris, au début j'étais perdu
---
La conception du mécanisme de sortie du jeu est cruciale, elle influence directement si tu peux partir à temps
---
On a l'impression que cette technologie Plasma marche sur une corde raide entre le coût du Gas et la complexité de la confiance
Voir l'originalRépondre0
SchrodingerAirdrop
· 01-21 21:27
Je comprends le sentiment de coder tard dans la nuit, mais pour être honnête, l'ensemble Plasma est effectivement facile à faire monter en flèche de manière exagérée.
Je voulais plutôt demander... la disponibilité des données a-t-elle vraiment été résolue ? J'ai l'impression que c'est toujours un piège.
Le code est ingénieux, mais le principal, c'est que quelqu'un ose le faire fonctionner sur le réseau principal.
Voir l'originalRépondre0
gas_fee_therapist
· 01-21 21:26
Fêter tard dans la nuit devant le code, c'est ça le vrai bonheur
Tard dans la nuit, après avoir passé en revue le livre blanc technique et le code source principal sur GitHub, j’ai enfin compris la complexité de la scalabilité hors chaîne (Off-chain Scaling). Par rapport au bruit du marché, la logique d’interaction sous-jacente est la clé.
J’avais tendance à comparer les différentes solutions Layer 2, mais lors de cette rétrospective, j’ai réalisé que ma compréhension de la "sécurité héritée" était encore insuffisante. Beaucoup considèrent Plasma comme une logique de side-chain simple, alors que le cœur réside dans la façon d’utiliser des contrats intelligents sur la chaîne principale pour faire respecter la validité des transitions d’état. C’est une différence fondamentale.
Le problème le plus épineux reste celui de la "disponibilité des données". Contrairement aux Rollups qui compressent et uploadent le calldata sur L1, Plasma choisit de laisser les données de transaction hors chaîne, ne soumettant que le Merkle Root du bloc à la chaîne principale. Cela permet effectivement de réduire considérablement le coût en Gas, mais introduit aussi une complexité dans la stratégie de jeu. Si un validateurs fait du mal en retenant les données, comment l’utilisateur peut-il prouver en toute sécurité, via Merkle, qu’il peut retirer ses fonds du sous-chaîne ?
Cela soulève la conception du mécanisme de "sortie". Les preuves de fraude interactives traditionnelles ont un problème de délai de contestation trop long, ce qui impacte la liquidité des fonds. La nouvelle architecture envisage d’introduire des preuves à connaissance zéro pour optimiser — en remplaçant une partie de la logique de preuve de fraude par une preuve d’efficacité — permettant, sans faire confiance à quiconque, d’améliorer significativement la performance finale de la confirmation d’état.
L’adaptation entre le modèle UTXO et le modèle basé sur les comptes est également très intéressante. En haute concurrence, il faut à la fois prévenir la double dépense et maintenir une structure d’état allégée. En regardant la logique de pruning de l’arbre d’état dans le code, on ne peut qu’admirer la finesse de cette architecture.