Vitalik Buterin propone una solución de escalado de resumen cruzado

El cofundador de Ethereum, Vitalik Buterin, ha presentado una propuesta para vincular las diferentes soluciones de escalado de la segunda capa para que puedan 'hablar' entre sí para mantener la sinergia y la componibilidad defi.

Ahora existen numerosos protocolos de segunda capa. , Siendo Optimistic el último en lanzarse pronto.

A pesar de sus muchas diferencias, todos son básicamente una red basada en contratos inteligentes a la que ingresas depositando en el contrato inteligente, con ese contrato inteligente y luego manteniendo la cuenta de los cambios de propiedad de transacciones dentro de él sin comunicarse con la red ethereum más amplia a menos que haya un acuerdo o transacción en la cadena.

El problema es que a menos que todos estén usando la misma segunda capa de contrato inteligente, algo como Synthetix no puede 'hablar' con Uniswap y así Las estrategias Y no pueden funcionar a menos que todo se haga en cadena.

Aún así, cualquier escala es mejor que ninguna. Por lo tanto, la mayoría de las dapps principales están lanzando algún contrato inteligente de segunda capa 'aislado' que debería aumentar la capacidad y básicamente condensando el mantenimiento de cuentas en cadena a través de hashes de los movimientos en el contrato.

Ahora parece que estamos en la etapa dónde podemos ir más allá, con Buterin proponiendo una forma sencilla de conectar estas redes de contratos "aisladas". Él dice:

“Supongamos que hay un intermediario de intercambio, Iván (en una implementación real habría muchos intermediarios para elegir). Ivan tiene una cuenta IVAN_A en el rollup A (que controla por completo). Iván también tiene algunos fondos depositados en un contrato inteligente IVAN_B en el resumen B…

Alice envía una transacción a IVAN_A con N monedas y un memo ALICE_B
Iván envía una transacción enviando monedas TRADE_VALUE * (1 – tarifa) a través de IVAN_B a ALICE_B. ”

No sabemos quién es este tipo Ivan o por qué alguien le daría dinero, pero la sugerencia básica es que tenemos una especie de capa de conexión que mantiene los depósitos en todos estos contratos aislados y luego envía un +1 en el resumen A con la capa de conexión obteniendo un -1 en el resumen B.

Entonces, eventualmente, esta capa de conexión tendrá que hacer arreglos dentro de sí misma porque su cuenta podría agotarse en un contrato.

Esto es una especie de cómo se mueve Fiat actualmente. Si toma un depósito de Barclays y se lo da a Citi, es posible que los números en la pantalla se hayan movido instantáneamente, pero la liquidación real ocurre una vez al día cuando Barclays envía "dinero real", es decir, fondos guardados en la Fed o en cualquier banco central. de su cuenta de la Fed de Barclays a la cuenta de la Fed de Citi.

Como es obvio que podría haber alguien más que fue de Citi a Barclays, solo liquida la diferencia, con esta capa de conexión, por lo tanto, quizás mejor denominada reservuar.

El único El problema es, en teoría, ¿por qué el reservuar debería pedir menos de un centavo por debajo de la tarifa principal en cadena?

La respuesta a eso puede ser porque no hay una razón por la que no pueda haber mil de estas cosas sin en de todos modos afecta la interoperabilidad o la sinergia porque todos hacen la misma función de mover sus fondos de un rollo a otro sin ir en cadena al utilizar estas reservas 'comunes'.

Esa competencia, por lo tanto, debería reducir las tarifas al costo más un poco de relaciones públicas de él, y presumiblemente debería impulsar más innovación y mejora, sobre todo a través de la especialización de nivel casi láser, ya que a escala definitivamente necesitaría algunos desarrolladores de la reserva que se centren únicamente en la forma más fluida y mejor de mover fondos de diferentes acumulaciones sin tocar la cadena de bloques por transacción.

Si va a haber diferentes, entonces habrá diferentes experimentaciones, y presumiblemente la más interesante sería sobre quién es este tipo Ivan, ¿por qué alguien debería confiarle su dinero? ?

No deberían, por lo que probablemente tendríamos un token, una participación y un DAO, con ese token probablemente enviado desde el aire a los proveedores de liquidez para la reserva y a los usuarios, después de que los desarrolladores obtuvieran fondos de VC para codificar todo esto y lanzarlo, y con suerte todo a tiempo antes de que la SEC diga algo sobre los lanzamientos aéreos, ya que entonces podríamos terminar sin saber que el nombre del desarrollador es Ivan, y mucho menos por qué deberíamos confiar en el código fuente abierto.

pag Probablemente sean tres de estos, uno con el 70% de participación de mercado debido a los efectos de la red, y actuarán como guardianes de las nuevas segundas capas mientras deciden con quién llevar las cuentas, 'ellos' aquí, con suerte, serán cualquiera que quiera tener el token .

En diez años, la gente puede quejarse de este guardián que puede resultar como Twitter, pero como siempre tienes la opción en cadena, no pueden hacer demasiado.

En la implementación, esperarías todo de esto para estar en el backend, al menos eventualmente. Las aplicaciones pueden incluso tener alguna reserva predeterminada que usan, por lo que no te molestan en absoluto, y las mejores te dan la opción de elegir entre opciones avanzadas.

La única dificultad entonces sería codificar esto de una manera confiable , comenzando quizás con dos resúmenes, y luego mostrando el prototipo donde Alice B le dice a Ivan que envíe algo de eth a Alice A y todos los espectadores pueden estar seguros de que esto no es exactamente Iván el Terrible.

Conceptualmente, sin embargo, todo tiene sentido y dado que ethereum es Turing completo, presumiblemente aquí no necesitaríamos torres de vigilancia y probablemente no habría problemas de liquidez debido a los incentivos simbólicos.