Initialement publié en anglais par StarkWare le 21 décembre, 2021

La route des layers

1. Les preuves récursives ouvrent des options de conception surprenantes et originales

2. Présentation de L3, la couche spécifique à l’application, construite récursivement sur L2

3. L3 répond aux besoins sur mesure des applications, comme l’hyper-scalabilité, un meilleur contrôle de la pile technologique, et la confidentialité

4. StarkEx, actuellement au service des clients en tant que solution L2, sera porté vers L3.

5. Des instances autonomes de StarkNet seront également disponibles en L3

Le coût prohibitif des transactions sur Ethereum le conduit à devenir un layer de règlement pour L2. Nous pensons (et d’autres) que, dans un avenir proche, les utilisateurs finaux effectueront la majeure partie de leurs activités sur L2 en raison de la réduction significative des coûts de transaction, de l’utilisation croissante des outils DeFi et de la liquidité accrue fournie par L2.

Les L2 augmentent la scalabilité en réduisant le coût du gas par transaction et en améliorant les taux de transaction. En même temps, les L2 conservent les avantages de la décentralisation, de la logique polyvalente et de la composabilité. Cependant, certaines applications nécessitent une adaptation spécifique qui peut être mieux servie par de nouveau Layer séparée : Découvrez L3!

L3 se rapporte à L2 tout comme L2 se rapporte à L1. L3 peut être réalisé en utilisant des preuves de validité tant que le L2 est capable de supporter un smart contract du verifieur. Lorsque le L2 utilise également des preuves de validité soumises sur L1, comme le fait StarkNet, cela devient une structure récursive extrêmement élégante où l’avantage de compression des preuves L2 est multiplié par l’avantage de compression des preuves L3. En d’autres termes, si chaque couche atteint, par exemple, 1000X de réduction des coûts, L3 peut atteindre 1.000.000X de réduction par rapport à L1 – tout en conservant la sécurité de L1.

Imaginez, des transactions pour une fraction de gas !

Les principaux avantages de L3 sont :

1. Hyper-scalable : tirer parti de l’effet multiplicatif de l’étalonnage récursif.

2. Meilleur contrôle par le concepteur d’applications de la stack technologique :

a. Une performance et un coût plus déterministe,

b. Modèles personnalisés data availability (disponibilité des données) (p.ex, compression de données on-chain basée sur Validium ou spécifique à une application),

c. Fonction et vitesse technologiques plus rapides (p.ex, introduction de nouvelles fonctionnalités qui ne sont pas encore prêtes à être mises à la disposition du public).

1. Confidentialité : par exemple, les Zero Knowledge Proofs appliquées aux transactions préservant la confidentialité sur une L2 publique.

2. Une interopérabilité L2-L3 plus économique/simple : Les flux d'activation et de désactivation actuellement utilisés entre L1 et L2 sont notoirement coûteux. En revanche, en raison de la rentabilité de L2, ces flux, lorsqu'ils sont appliqués à L3, deviennent non seulement extrêmement intéressants, mais aussi simples à mettre en œuvre. Si la latence du déplacement des actifs entre L2 et L3 peut être plus longue qu'entre les applications déployées sur le même L2, le coût et le débit sont comparables.

3. Interopérabilité L3-L3 plus économique/simple : Les L3 indépendants interopéreront via L2, et non L1. L2 est évidemment censé être moins cher que son L1. En l'absence de L3, les L3 fonctionneraient tous comme des L2 et, en tant que tels, devraient interopérer via L1, considérablement plus chère.

4. L3 comme réseau "Canary" pour L2 : Les nouvelles innovations peuvent être testées sur L3 avant d'être mises à la disposition du grand public sur L2 ou L3 (un peu comme le rôle joué par Kusama pour Polkadot).

Plusieurs L3 seront montés au-dessus d’un L2. De plus, des Layers supplémentaires (L4, etc.) peuvent être construites sur L3 pour les solutions de Layer fractales.

Le diagramme 1 illustre un tel écosystème. Ces L3 comprennent :

1. Avec StarkNet la data availability Validium, p.ex, pour une utilisation générale par des applications très sensibles à la tarification.

2. Systèmes StarkNet spécifiques à l’application personnalisés pour améliorer les performances de l’application, par exemple en utilisant des structures de stockage désignées ou la compression de data availability.

3. Le système StarkEx (tels que ce qui dessert dYdX, Sorare, Immutable et DeversiFi) avec une disponibilité de données Validium ou Rollup, apporte immédiatement à Starknet des avantages de scalabilité prouvés au combat.

4. Confidentialité des instances StarkNet (dans cet exemple aussi comme un L4) permettent des transactions de protection de la vie privée sans les inclure dans StarkNets publics.

Le diagramme 2 illustre l’architecture classique de L2 qui comprend les éléments suivants :

1. Un smart contract traçant une state root L2 sur L1 (p.ex, le smart contract StarkNet sur Ethereum).

2. Pour des preuves de validité basées sur L2, un smart contract Verifieur pour vérifier la validité des preuves de transition d’état.

3. Contrats-relais sur L1 pour la gestion des dépôts et des retraits de jetons vers/depuis L2.

4. Contrats jetons sur L2 agissant en tant que contreparties des contrats jetons de L1 (par exemple, ERC20, ERC721).

Le diagramme 3 illustre la relation entre L3 et ses sous-jacents L2 et L1. En mettant en œuvre le suivi de l’état et le verifieur des smart contracts sur L2, L3 peut voyager en toute sécurité sur L2.

L3 promet une hyper-scalabilité, un meilleur contrôle de la stack technologique pour différents besoins et la confidentialité, tout en maintenant les garanties de sécurité fournies par Ethereum (L1). Le concept récursif qu’il utilise peut être étendu à des layers supplémentaires pour les solutions de layer fractales.

StarkEx, actuellement exploité en tant que L2, sera porté en L3. De plus, les instances de StarkNet seront disponibles en L3.

Merci à Polynya et Alex Connolly (Immutable) pour leurs commentaires et leurs avis sur ce post. Nous remercions tout particulièrement Pierre Duperrin (Sorare) pour ses précieuses idées.

Gidi Kaempfer, directeur de l’ingénierie de base, StarkWare

Traduction faite par @cleminso

Initialement publié en anglais par StarkWare le 21 décembre, 2021

La route des layers

1. Les preuves récursives ouvrent des options de conception surprenantes et originales

2. Présentation de L3, la couche spécifique à l’application, construite récursivement sur L2

3. L3 répond aux besoins sur mesure des applications, comme l’hyper-scalabilité, un meilleur contrôle de la pile technologique, et la confidentialité

4. StarkEx, actuellement au service des clients en tant que solution L2, sera porté vers L3.

5. Des instances autonomes de StarkNet seront également disponibles en L3

Le coût prohibitif des transactions sur Ethereum le conduit à devenir un layer de règlement pour L2. Nous pensons (et d’autres) que, dans un avenir proche, les utilisateurs finaux effectueront la majeure partie de leurs activités sur L2 en raison de la réduction significative des coûts de transaction, de l’utilisation croissante des outils DeFi et de la liquidité accrue fournie par L2.

Les L2 augmentent la scalabilité en réduisant le coût du gas par transaction et en améliorant les taux de transaction. En même temps, les L2 conservent les avantages de la décentralisation, de la logique polyvalente et de la composabilité. Cependant, certaines applications nécessitent une adaptation spécifique qui peut être mieux servie par de nouveau Layer séparée : Découvrez L3!

L3 se rapporte à L2 tout comme L2 se rapporte à L1. L3 peut être réalisé en utilisant des preuves de validité tant que le L2 est capable de supporter un smart contract du verifieur. Lorsque le L2 utilise également des preuves de validité soumises sur L1, comme le fait StarkNet, cela devient une structure récursive extrêmement élégante où l’avantage de compression des preuves L2 est multiplié par l’avantage de compression des preuves L3. En d’autres termes, si chaque couche atteint, par exemple, 1000X de réduction des coûts, L3 peut atteindre 1.000.000X de réduction par rapport à L1 – tout en conservant la sécurité de L1.

Imaginez, des transactions pour une fraction de gas !

Les principaux avantages de L3 sont :

1. Hyper-scalable : tirer parti de l’effet multiplicatif de l’étalonnage récursif.

2. Meilleur contrôle par le concepteur d’applications de la stack technologique :

a. Une performance et un coût plus déterministe,

b. Modèles personnalisés data availability (disponibilité des données) (p.ex, compression de données on-chain basée sur Validium ou spécifique à une application),

c. Fonction et vitesse technologiques plus rapides (p.ex, introduction de nouvelles fonctionnalités qui ne sont pas encore prêtes à être mises à la disposition du public).

1. Confidentialité : par exemple, les Zero Knowledge Proofs appliquées aux transactions préservant la confidentialité sur une L2 publique.

2. Une interopérabilité L2-L3 plus économique/simple : Les flux d'activation et de désactivation actuellement utilisés entre L1 et L2 sont notoirement coûteux. En revanche, en raison de la rentabilité de L2, ces flux, lorsqu'ils sont appliqués à L3, deviennent non seulement extrêmement intéressants, mais aussi simples à mettre en œuvre. Si la latence du déplacement des actifs entre L2 et L3 peut être plus longue qu'entre les applications déployées sur le même L2, le coût et le débit sont comparables.

3. Interopérabilité L3-L3 plus économique/simple : Les L3 indépendants interopéreront via L2, et non L1. L2 est évidemment censé être moins cher que son L1. En l'absence de L3, les L3 fonctionneraient tous comme des L2 et, en tant que tels, devraient interopérer via L1, considérablement plus chère.

4. L3 comme réseau "Canary" pour L2 : Les nouvelles innovations peuvent être testées sur L3 avant d'être mises à la disposition du grand public sur L2 ou L3 (un peu comme le rôle joué par Kusama pour Polkadot).

Plusieurs L3 seront montés au-dessus d’un L2. De plus, des Layers supplémentaires (L4, etc.) peuvent être construites sur L3 pour les solutions de Layer fractales.

Le diagramme 1 illustre un tel écosystème. Ces L3 comprennent :

1. Avec StarkNet la data availability Validium, p.ex, pour une utilisation générale par des applications très sensibles à la tarification.

2. Systèmes StarkNet spécifiques à l’application personnalisés pour améliorer les performances de l’application, par exemple en utilisant des structures de stockage désignées ou la compression de data availability.

3. Le système StarkEx (tels que ce qui dessert dYdX, Sorare, Immutable et DeversiFi) avec une disponibilité de données Validium ou Rollup, apporte immédiatement à Starknet des avantages de scalabilité prouvés au combat.

4. Confidentialité des instances StarkNet (dans cet exemple aussi comme un L4) permettent des transactions de protection de la vie privée sans les inclure dans StarkNets publics.

Le diagramme 2 illustre l’architecture classique de L2 qui comprend les éléments suivants :

1. Un smart contract traçant une state root L2 sur L1 (p.ex, le smart contract StarkNet sur Ethereum).

2. Pour des preuves de validité basées sur L2, un smart contract Verifieur pour vérifier la validité des preuves de transition d’état.

3. Contrats-relais sur L1 pour la gestion des dépôts et des retraits de jetons vers/depuis L2.

4. Contrats jetons sur L2 agissant en tant que contreparties des contrats jetons de L1 (par exemple, ERC20, ERC721).

Le diagramme 3 illustre la relation entre L3 et ses sous-jacents L2 et L1. En mettant en œuvre le suivi de l’état et le verifieur des smart contracts sur L2, L3 peut voyager en toute sécurité sur L2.

L3 promet une hyper-scalabilité, un meilleur contrôle de la stack technologique pour différents besoins et la confidentialité, tout en maintenant les garanties de sécurité fournies par Ethereum (L1). Le concept récursif qu’il utilise peut être étendu à des layers supplémentaires pour les solutions de layer fractales.

StarkEx, actuellement exploité en tant que L2, sera porté en L3. De plus, les instances de StarkNet seront disponibles en L3.

Merci à Polynya et Alex Connolly (Immutable) pour leurs commentaires et leurs avis sur ce post. Nous remercions tout particulièrement Pierre Duperrin (Sorare) pour ses précieuses idées.

Gidi Kaempfer, directeur de l’ingénierie de base, StarkWare

Traduction faite par @cleminso