You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
description: Introducción a los canales de estado y a los canales de pago como solución de escalado actualmente utilizada por la comunidad de Ethereum.
4
+
lang: es
5
+
sidebarDepth: 3
6
+
---
7
+
8
+
Los "canales de estado" permiten a los participantes hacer transacciones seguras fuera de la cadena mientras siguen manteniendo interacción con la Red principal de Ethereum a un nivel mínimo. Los pares de un canal puede realizar un número arbitrario de transacciones fuera de la cadena solamente enviando dos transacciones en cadena, una para abrir y otra para cerrar el canal. Esto permite una alta velocidad en el número de transacciones y conlleva un menor costo para los usuarios.
9
+
10
+
## {#how-do-sidechains-work}
11
+
12
+
Las cadenas de bloques públicas, como Ethereum, enfrentan desafíos de escalabilidad debido a su arquitectura distrubuida: todas las transacciones hechas dentro de la cadena deben ser ejecutadas por todos los nodos. Los nodos deben ser capaces de manejar el volumen de transacciones en un solo bloque usando equipos de cómputo modestos, lo cual limita el volumen de transacciones para mantener la red descentralizada.
13
+
14
+
### {#consensus-algorithms}
15
+
16
+
Los canales son simples protocolos entre pares que permiten a dos entidades hacer cuantas transacciones requieran entre ellos y, al finalizar, solamente publicar el resultado final en la cadena de bloques. El canal usa criptografía para demostrar que los datos de resumen que generan son el verdadero resultado de un conjunto válido de transacciones intermedias. Un contrato inteligente ["multifirma"](/developers/docs/smart-contracts/#multisig) asegura que las transacciones sean firmadas por las entidades correctas.
17
+
18
+
-[]()
19
+
-[]()
20
+
-
21
+
22
+
Con los canales, los cambios de estado son ejecutados y validados por las partes interesadas, minimizando el nivel de cómputo requerido en la capa de ejecución de Ethereum. Esto disminuye la congestión en Ethereum a la vez que incrementa la velocidad de procesamiento de transacciones para los usuarios.
23
+
24
+
#### {#block-parameters}
25
+
26
+
Cada canal es administrado por un [contrato inteligente multifirma](/developers/docs/smart-contracts/#multisig) que corre en Ethereum. Para abrir un canal, los participantes implementan el contrato del canal en la cadena y depositan fondos en él.
27
+
28
+
Para cerrar un canal, los participantes deben enviar el estado final acordado del canal en la cadena. Después el contrato inteligente distribuye los fondos bloqueados de acuerdo al saldo de cada uno de los participantes indicado en el estado final del canal.
29
+
30
+
Los canales entre pares son particularmente útiles en situaciones donde un definido número de participantes deseen hacer transacciones con alta frecuencia sin incurrir grandes gastos. Los canales de la cadena de bloques se dividen en dos categorías: **canales de pago** y **canales de estado**.
31
+
32
+
### {#evm-compatibility}
33
+
34
+
Un canal de pago podría describirse mejor como un "libro mayor de dos vías" mantenido de manera colectiva por dos usuarios. El saldo inicial del libro mayor es la suma de los depósitos enviados al contrato en cadena durante la fase de apertura del canal.
35
+
36
+
Las actualizaciones del saldo del libro mayor (es decir, el estado del canal de pago) requieren la aprobación de todas las partes del canal. Una actualización del canal, firmada por todos los participantes del canal, se considera finalizada, al igual que una transacción en Ethereum.
37
+
38
+
Los canales de pago fueron algunas de las primeras soluciones de escalado diseñadas para minimizar la costosa actividad en cadena de las interacciones simples de los usuarios (por ejemplo, transferencias de ETH, intercambios o swaps atómicos o micropagos). Los participantes del canal pueden realizar una cantidad ilimitada de transacciones instantáneas entre sí, siempre y cuando la suma neta de sus transferencias no exceda los tokens depositados.
39
+
40
+
Aparte de permitir los pagos fuera de la cadena, los canales de pago no han demostrado ser útiles para manejar lógica general de transición de estados. Los canales de estado se crearon para resolver este problema y hacer que los canales fueran útiles para escalar los cálculos de uso general.
41
+
42
+
### {#asset-movement}
43
+
44
+
Los canales de estado todavía tienen mucho en común con los canales de pago. Por ejemplo, los usuarios interactúan intercambiando mensajes firmados criptográficamente (transacciones), que los otros participantes del canal también deben firmar. Si una actualización de estado propuesta no está firmada por todos los participantes, se considera no válida.
Copy file name to clipboardExpand all lines: public/content/translations/es/developers/docs/smart-contracts/composability/index.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -57,7 +57,7 @@ Si crea un dapp que requiere que las transacciones se paguen en ETH, puede permi
57
57
58
58
### Gobernanza {#governance}
59
59
60
-
Crear sistemas de gobernanza a medida para una [DAO](/dao/) puede ser costoso y consumir mucho tiempo. En su lugar, se podría utilizar un kit de herramientas de gobernanza de código abierto, como [Aragon Client](https://client.aragon.org/), para arrancar la DAO y poder crear rápidamente un marco de gobernanza.
60
+
Crear sistemas de gobernanza a medida para una [DAO](/dao/) puede ser costoso y consumir mucho tiempo. En su lugar, se podría utilizar un kit de herramientas de gobernanza de código abierto, como <0">Aragon Client</a>, para arrancar la DAO y poder crear rápidamente un marco de gobernanza.
Copy file name to clipboardExpand all lines: public/content/translations/es/roadmap/future-proofing/index.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,7 +15,7 @@ Parte de la [criptografía](/glossary/#cryptography) que protege Ethereum en la
15
15
16
16
El desafío al que se enfrentan los desarrolladores de Ethereum es que el actual protocolo de [prueba de participación](/glossary/#pos) se base en un esquema de firmas muy eficiente conocido como BLS para agregar votos en [bloques](/glossary/#block) válidos. Las computadoras cuánticas son capaces de descodificar esta estrategia de firmas, no obstante, las alternativas cuántico-resistentes no son tan eficientes.
17
17
18
-
Las [estrategias comprometidas «KZG»](/roadmap/danksharding/#what-is-kzg) que Ethereum utiliza en múltiples ocasiones para generar secretos criptográficos tienen vulnerabilidad cuántica. Actualmente, esto se evita usando «configuraciones seguras» en las que muchos usuarios generan una aleatoriedad a la que las computadoras cuánticas no pueden aplicar ingeniería inversa. De cualquier forma, la solución idónea sería incorporar simplemente criptografía cuántica segura. Hay dos enfoques principales que podrían convertirse en sustituciones eficientes de las estrategias BLS: [el basado en STARK](https://hackmd.io/@vbuterin/stark_aggregation) y [el basado en redes](https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175) de firmas. **Se los sigue investigando y se siguen elaborando prototipos**.
18
+
Las [estrategias comprometidas «KZG»](/roadmap/danksharding/#what-is-kzg) que Ethereum utiliza en múltiples ocasiones para generar secretos criptográficos tienen vulnerabilidad cuántica. Actualmente, esto se evita usando «configuraciones seguras» en las que muchos usuarios generan una aleatoriedad a la que las computadoras cuánticas no pueden aplicar ingeniería inversa. De cualquier forma, la solución idónea sería incorporar simplemente criptografía cuántica segura. Hay dos enfoques principales que podrían convertirse en sustituciones eficientes de las estrategias BLS: [el basado en STARK](https://hackmd.io/@vbuterin/stark_aggregation) y [el basado en redes](https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175) de firmas. **Se los sigue investigando y se siguen elaborando prototipos**.
19
19
20
20
<ButtonLinkvariant="outline-color"href="/roadmap/danksharding#what-is-kzg"> Lea acerca de KZG y las configuraciones seguras</ButtonLink>
Copy file name to clipboardExpand all lines: public/content/translations/es/roadmap/scaling/index.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,7 +7,7 @@ alt: "Hoja de ruta de Ethereum"
7
7
template: roadmap
8
8
---
9
9
10
-
Ethereum escala utilizando las [capas 2](/layer-2/#rollups)(también conocidas como acumulaciones o «rollups»), que agrupan transacciones y envían el resultado a Ethereum. Aunque las acumulaciones son hasta ocho veces más baratas que la red principal de Ethereum, es posible optimizarlas aún más para reducir costes para los usuarios finales. Las acumulaciones dependen de algunos componentes centralizados que los desarrolladores podrán eliminar en la medida en que dichas acumulaciones maduren.
10
+
Ethereum escala utilizando las [capas 2](/layer-2/#rollups)(también conocidas como acumulaciones o «rollups»), que agrupan transacciones y envían el resultado a Ethereum. Aunque las acumulaciones son hasta ocho veces más baratas que la red principal de Ethereum, es posible optimizarlas aún más para reducir costes para los usuarios finales. Las acumulaciones dependen de algunos componentes centralizados que los desarrolladores podrán eliminar en la medida en que dichas acumulaciones maduren.
"nav-roadmap-user-experience": "Mejor experiencia de usuario",
311
310
"nav-roadmap-ux-description": "El uso de Ethereum debe simplificarse",
@@ -336,7 +335,7 @@
336
335
"nav-whitepaper-description": "El informe técnico original de Ethereum escrito por Vitalik Buterin en 2014",
337
336
"nav-zkp-description": "Una forma de demostrar la validez de una declaración sin tener que revelarla",
338
337
"nft-page": "NFT: tókenes no fungibles",
339
-
"nfts": "NFT",
338
+
"nfts": "NTF",
340
339
"no": "No",
341
340
"on-this-page": "En esta página",
342
341
"open": "Abierto",
@@ -362,7 +361,7 @@
362
361
"privacy-policy": "Política de privacidad",
363
362
"private-ethereum": "Red privada de Ethereum",
364
363
"product-disclaimer": "Los productos y servicios se indican para comodidad de la comunidad Ethereum. La inclusión de un producto o servicio<strong>no implica su recomendación</strong>por parte del equipo del sitio web ethereum.org ni de Ethereum Foundation.",
0 commit comments