Suscríbete a RCast en iTunes | Google Play | Grapadora
Greg Meredith discute el estado de con Isaac DeFrain y Christian Williams.
Greg: Hoy, quería hablar un poco sobre algunas de las otras cadenas de bloques. No me interesa criticar otras cadenas de bloques u ofertas. Alguien de nuestra comunidad me preguntó si haría un análisis competitivo. He dicho lo mismo una y otra vez desde que entré en el espacio de : realmente no creo que sea sobre competencia. Muchas personas, especialmente Vitalik y Vlad y otros, me dan la sensación de que se trata principalmente de proporcionar una infraestructura alternativa. Todos estamos trabajando juntos para proporcionar esa infraestructura alternativa. Es por eso que hubo tanta colaboración entre Ethereum y RChain. Estábamos interesados en encontrar un algoritmo de consenso que funcionara.
No se trata de competencia. Sé que es muy difícil para las personas en el espacio financiero no tener una mentalidad de escasez en lugar de tener una mentalidad de abundancia. Lo único que puedo decirle es que tenemos un suministro abundante de trabajo. Hay un sinfín de trabajos que tenemos que hacer si realmente queremos tomarnos en serio las consecuencias de cómo está cambiando el clima. Más allá de eso, hay todo tipo de trabajo. Uno de mis dichos favoritos es "El arte es largo, la vida es corta". Hay una cantidad infinita de trabajo realmente divertido relacionado con las matemáticas y los aspectos técnicos, y mucho menos algunos de los aspectos económicos.
Hay muchos proyectos por ahí centrados en la interoperabilidad entre redes. Un buen ejemplo es Polkadot. Su reclamo a la fama es la interoperabilidad. Desde el principio, RChain se ha ocupado de la interoperabilidad. Parte de la razón por la que enfatizo la composición y la composicionalidad como características no es solo porque esa es la única forma de escalar y así es como escala la naturaleza. Si observa sistemas de ingeniería a gran escala, debe construirlos a partir de componentes que componen en soluciones. Intentos humanos de escalar la escala de la naturaleza; se trata de composición.
Si observa detenidamente nuestro modelo de composición, también proporciona un modelo de interoperabilidad. Quiero hablar un poco sobre eso desde la perspectiva de dos tipos de problemas que enfrenta con respecto a la confianza, y luego pasar de allí a otros tipos de garantías de seguridad.
Comencemos por fragmentar una sola cadena. Lo que estamos sugiriendo es que hay una colección de – los llamaré validadores. No estoy tratando de ser demasiado específico de Casper, aunque esa es la terminología que usamos con Casper. Hay algunos validadores, algunos elementos computacionales que proporcionan el mecanismo de consenso. Entonces podemos imaginar otro grupo de validadores que también están proporcionando un mecanismo de consenso. Queremos poder componerlos. Ese tipo de composición es solo interoperabilidad, pero con algunas suposiciones adicionales sobre la homogeneidad potencialmente del algoritmo de consenso. En otras palabras, el algoritmo de consenso que se usa en el Fragmento A es el mismo que el algoritmo de consenso que se usa en el Fragmento B.
Isaac: Cuando estás hablando de los validadores de cualquiera de estos dos conjuntos que componen, ¿qué están componiendo exactamente allí? ¿Es el algoritmo de consenso lo que están usando?
Greg: En última instancia, la composición debe ser capaz de proporcionar un mecanismo mediante el cual pueda tener un cálculo que implique acciones en ambas cadenas. Por ejemplo, una transacción que involucra recursos en ambas cadenas. Será un consenso sobre los recursos en A y un consenso sobre los recursos en B, y luego un consenso de nivel superior que rige tanto A como B.
cristiano: ¿Esto está al otro lado del fragmento?
Greg: Sí exactamente. ¿Tiene sentido?
Isaac: Sí, definitivamente.
Greg: Una de las cosas buenas de la forma en que RChain hace las cosas es que simplemente podemos suponer que tenemos un espacio de nombres bifurcado. El fragmento A está operando un espacio de nombres A, el fragmento B está operando un espacio de nombres B. Cuando queremos combinarlos, de lo que estamos hablando como un espacio de nombres compuesto. Eso sería suficiente para una amplia gama de problemas. Sin embargo, hay algunos problemas de confianza adicionales que deben desarrollarse.
Si solo lo miramos desde un punto de vista puramente teórico, solo poder bifurcar el espacio de nombres y luego recomponer el espacio de nombres es una gran solución. Por cierto, eso también funciona para la interoperabilidad. Si decimos que las direcciones de Ethereum constituyen un espacio de nombres o las direcciones de bitcoin constituyen un espacio de nombres, si tiene una solución que le permite tener algoritmos de consenso heterogéneos, entonces el enfoque del espacio de nombres resuelve una gran parte del problema de interoperabilidad.
Lo sabemos desde hace mucho tiempo. Los URI y las URL representan un enfoque basado en el espacio de nombres para acceder a los recursos en Internet. Mucho de lo que sucede en es que olvidamos todas las lecciones que hemos aprendido en Internet.
Una lección que hemos aprendido es que tener acceso composable basado en nombres a los recursos es una pieza importante del rompecabezas. En las últimas dos décadas, desde una perspectiva económica, Internet se ha centrado en el crecimiento de los mercados de activos digitales. Ya sea que esté hablando de Github o Spotify o Facebook o Instagram o incluso finanzas digitales, todo se trata de activos digitales. Ahí es donde está todo el crecimiento.
Es realmente sencillo. Los datos son el rey en la historia. Si no puede manejar grandes cantidades de activos digitales, no competirá. De alguna manera, los mercados de olvidan todas estas lecciones básicas que hemos aprendido de Internet.
De vuelta al fragmentación. Una de las cosas que es realmente clave en ese enfoque es que nuestro enfoque de fragmentación es un enfoque de interoperabilidad bajo el supuesto de que puede manejar un consenso heterogéneo.
Isaac: La forma en que dice que la interoperabilidad podría funcionar utilizando este fragmento de espacio de nombres es básicamente tratar todas las direcciones de bitcoin como ciertos nombres en un espacio de nombres específico y todas las direcciones de Ethereum como nombres en un espacio de nombres diferente. ¿Es eso lo que estás diciendo?
Greg: Eso es exactamente lo que estoy diciendo. La siguiente pieza del rompecabezas que debe tener: incluso en el contexto de consenso homogéneo, hay otra cosa que debe tener en cuenta. Se podría imaginar que un fragmento, todos se confabulan para atacar a otros fragmentos. Todos dicen que estas son las transacciones y los recursos que hemos validado hasta ahora. Lo están haciendo para ocultar una doble inversión y así aprovechar los otros fragmentos de la red.
Solo tienen que hacer esto por un período de tiempo muy corto. No tiene que ser un ataque de largo alcance en ese caso. Ahí es donde las cosas se ponen realmente interesantes porque no puedes asumir, incluso en el caso homogéneo, el mismo tipo de modelo de confianza si solo estás adoptando el enfoque de espacio de nombres o cualquier otro enfoque. Tienes que tener algo de mitigación de ese riesgo.
El problema es: ¿cómo mitigar ese riesgo? La solución que propone RChain, gran parte de esto surgió de las conversaciones que tuvimos con Nash, Mike y Vlad, me gusta mucho la metáfora del sistema de archivos UNIX de Nash.
cristiano: Cada fragmento es, en cierto sentido, su propia cadena.
Greg: Eso es correcto.
cristiano: ¿Poner una estructura en el conjunto de fragmentos es de alguna manera también poner la estructura en la jerarquía de cadenas de la que estás hablando?
Greg: Eso es exactamente correcto. En la relación entre padre e hijo, ha establecido un contrato de doble cara, que efectivamente dice que los tokens del padre están respaldando los tokens del niño. Efectivamente le da intercambio entre los recursos en el padre y el hijo. Eso mejora el riesgo porque ese contrato, y uniendo todos esos contratos en este árbol, el padre está cuidando a todos los niños. El padre es efectivamente responsable de cualquier falla de los niños y así sucesivamente. Las personas interesadas en la seguridad de la red se incentivan a subir más alto en el árbol para obtener más seguridad. Se les incentiva a moverse más abajo en el árbol para ganar velocidad.
cristiano: Eso tiene sentido.
Greg: Estamos hablando de un nivel bastante alto porque es muy difícil comparar cosas en un nivel bajo, pero si comienzas a un nivel bajo, ahí es donde las cosas realmente marcan la diferencia. Creo que Gavin es un ingeniero increíble. Me impresionó mucho la red de chismes de Whisper y otros trabajos que Gavin ha realizado. De ninguna manera estoy tratando de escupir Polkadot o cualquier otro proyecto. Ese no es mi objetivo. Como ingeniero, estoy tratando de comparar cosas y lo que sabemos con las matemáticas.
Pero si vas al sitio web de Polkadot y su literatura, hablan de una agregación de máquinas de estado. Toda la razón, la razón de ser, para la invención de CCS y el cálculo Pi y toda esa área de trabajo, es porque las máquinas de estado no componen. En particular, no componen a lo largo de las líneas de máquina y entorno. Incluso las máquinas Mealy y Moore no componen de esa manera. Eso fue esencialmente por qué Milner inventó CCS.
Como aprendí de la manera difícil, cuando intentas componer máquinas de estado de la forma en que componen, entonces obtienes una explosión exponencial. Es muy, muy, muy rápido y muy malo. Lo que tiene que hacer es modelar las restricciones en el espacio del producto de los estados. La complejidad de eso pasa por el techo.
Una de las cosas que me metió en el cálculo Pi y el cálculo del proceso, en general, fue trabajar en el procesamiento de transacciones relajadas. A finales de los años ochenta / principios de los noventa, estaba trabajando con un equipo en el área del llamado procesamiento de transacciones relajadas. Esto es más sofisticado que las transacciones anidadas de estilo Elliot Moss.
Hubo muchas propuestas diferentes para este tipo de modelos de transacción relajada, el tipo de casos estándar cuando vas de viaje y necesitas reservar tu hotel, tu vuelo y tu transporte. Está bien si el transporte no pasa, pero no está bien si el vuelo o el hotel no pasan, o alguna combinación de ambos. No es como una transacción anidada donde es todo o nada.
Estábamos viendo máquinas de estado compuestas como una forma de abordar esto. Fue por razones similares. Estas son redes autónomas. La red del hotel es autónoma de la red de vuelos, que es autónoma de la red de transporte. Debe tener un compromiso en todas estas redes para tener un viaje exitoso.
Cuando modelamos las máquinas de estado compuestas, realmente las modelamos; realmente los hicimos hacer el espacio del producto, un enfoque de tipo espacio-estatal, que simplemente pondrá de rodillas a una computadora. Incluso con la potencia de cálculo de hoy, pondrá de rodillas a una computadora en muy poco tiempo. En otras palabras, no es escalable.
Una vez que comience a componer máquinas de estados para que un entorno también sea una máquina de estados, debe lidiar con la polaridad: qué es entrada y qué salida. Tan pronto como tenga esta polaridad, cuál es la entrada y la salida entre las dos máquinas diferentes, así es como surge el cálculo de Pi: bajo el supuesto de que la topología de su red es dinámica. Obtiene un CCS de paso de valor si la topología de su red permanece constante. Si puede, como puede hacerlo hoy en Internet, enviar una nueva URL a otro agente, entonces ya está en territorio de cálculo Pi.
cristiano: Es por eso que siempre me ha sorprendido que el cálculo de Pi no se haya apoderado del mundo porque no es solo el lenguaje de las computadoras. Es el lenguaje de internet.
Greg: Eso es precisamente eso. La otra parte es que, como hemos explorado en los últimos podcasts, podemos razonar sobre estas cosas de manera equitativa. Revisé el libro blanco de Polkadot y no vi ningún razonamiento equitativo. Tiene páginas y páginas largas y no hay una sola línea de razonamiento equitativo. El cálculo Rho, que corrige los problemas de espacio de nombres en el cálculo Pi, se puede escribir en una sola página.
Ya sea que estemos hablando de la semántica de Rholang 1.1, donde propuse estas características del lenguaje, propongo su semántica, y luego muestro equitativamente exactamente lo que hacen y por qué ese comportamiento es el comportamiento deseado para la función. Tenemos una especificación está en la web. Podrías leerlo. Cualquiera que sea desarrollador o ingeniero puede pasar por esas ecuaciones como si fuera un código. Eso está en el lado de la contratación inteligente.
Por el lado del consenso, la cuestión de la raíz cuadrada era completamente equitativa. Derivamos equitativamente una noción de tolerancia a fallas y un algoritmo de consenso distribuido sin líder. O los códigos de corrección de errores, que de nuevo se hace a través del razonamiento equitativo. Es algo que podemos verificar en pocas líneas. Es solo entonces que tenemos una gran posibilidad de poder aplicar la verificación formal al protocolo central o, lo que es más importante, y aquí es donde el caucho realmente cumple con el camino, contratos inteligentes definidos por el usuario.
Al final del día, la mayor población de código vendrá de contratos inteligentes definidos por el usuario. Eso dominará como sus fuentes de error. Podrías hacer que los ángeles del cielo escriban tu protocolo central y no importa. Todas sus exposiciones de seguridad están con esos pésimos humanos.
cristiano: ¿Qué pasa si solo le pides a todos que verifiquen primero su código?
Greg: El código DAO fue auditado y no detectaron los errores. Lo mismo va a ser cierto una y otra vez. Puedes tener desarrolladores realmente crackers y auditores realmente crackers y simplemente vas a perder cosas. Es la naturaleza de los sistemas de este nivel de complejidad. Debe tener soporte para detectar estos errores. Cuanto más aumenta la complejidad, a medida que comienza a agregar algoritmos de consenso heterogéneos, entonces debe tener medios equitativos de razonamiento sobre cómo se componen los diferentes algoritmos de consenso para obtener nociones de consenso de extremo a extremo, y debe tener tipos de comportamiento que le permiten ver al menos con cierta aproximación el comportamiento de los diversos contratos que se ejecutan dentro de estos entornos heterogéneos.
Lo bueno es que un tipo de comportamiento puede abstraer el comportamiento de un contrato que se ejecuta en una cadena remota. Una de las cosas que he propuesto desde hace mucho tiempo, desde 1996; no antes de eso, 1993 – cuando estaba haciendo un período de investigación en British Telecoms, propuse usar los tipos de comportamiento como mecanismo de descubrimiento. Un servicio puede decir: "Necesito un servicio que cumpla con el siguiente tipo". Utilizando una forma de residencia, que puede considerarse como una especie de operador de división en lógica, puede buscar cosas que cumplan con una especificación a un delta, y luego ve y encuentra cosas que llenen el delta, y puedes hacerlo recursivamente. Usando tipos de comportamiento, puede superponer un sistema heterogéneo de redes, un mecanismo de descubrimiento para unir contratos que proporcionarán un servicio. Esto es lo que me gustaría que AI hiciera por mí. Me gustaría que AI escribiera código ensamblando código de los fragmentos de código que están ahí fuera.
Isaac: Solo para aclarar, está diciendo que tiene algún tipo de especificación para un servicio en mente, y luego puede buscar contratos existentes que pueda reunir en un acuerdo particular para cumplir con esta especificación.
Greg: Eso es exactamente correcto. Ya he hablado sobre esto antes, pero vale la pena repetirlo. Si piensa en un verificador de modelos o un verificador de tipos y lo pone de lado, se convierte en un motor de consulta, en el siguiente sentido. Tengo todos estos programas en alguna fuente de datos, como en Github, por ejemplo. Están en un idioma que sé cómo modelar verificación o escribir verificación. Entonces envío una especificación, que es una propiedad particular o un tipo particular. Luego voy y la fuerza bruta verifica cada programa en el repositorio contra esta propiedad. Los que satisfacen la propiedad, esos son los que devuelvo como respuesta a la consulta.
Isaac: Simplemente filtra la base de datos por esta propiedad particular …
Greg: Eso es exactamente correcto. El primer refinamiento de esta idea es reconocer que los sistemas de tipos no nos dan muchas búsquedas útiles. Mike Stay tiene un muy buen ejemplo de esto. Si observa los tipos funcionales comunes, como el tipo que puede encontrar en Haskell o Scala, la ordenación y la combinación aleatoria tienen el mismo tipo, pero hacen lo contrario entre sí. La búsqueda basada en tipos funcionales no nos llevará muy lejos. Pero buscar sobre la base de los tipos de comportamiento, ya sea que estemos viendo los tipos de estilo Caires o los tipos de sesión, que son ligeramente más débiles que los tipos de estilo Caires, nos dará mucha más información. En particular, los tipos de estilo Caires nos darán información sobre la estructura de los programas.
Si observa la forma en que LADL, por ejemplo, genera una lógica de monoides, podemos detectar cosas que son primas o no compuestas utilizando ese estilo de tipo. Esa noción de primalidad corresponde al enhebrado único en el cálculo Pi o el cálculo Rho. En realidad, puede buscar, puede decir, "encuéntreme todos los programas que tienen un solo subproceso".
Al revés, lo más probable es que sepa que tiene un error de concurrencia en alguna parte. "Búscame todos los programas en mi repositorio actual que sean multiproceso y que tengan alguna otra propiedad". Eso te dará algunos culpables candidatos para investigar.
Isaac: Puedes probar las condiciones de carrera.
Greg: Ese es un muy buen ejemplo. Esto le brinda un mecanismo de descubrimiento bastante decente. Ahora, la pieza del rompecabezas de la que no hemos hablado en esto es: puedes imaginar que puedes satisfacer un tipo hasta un delta. Esto satisface la mayoría de tu tipo. Hay una noción de residencia que está en juego donde usted dice que satisface un tipo de implicación que involucra a su tipo. Ahora necesita encontrar algo que descargue la hipótesis de la implicación. Esa es la dependencia que necesitas para hacer eso. Eso le da la base para un mecanismo de descubrimiento en el que se reúne a través de esta red heterogénea de cadenas de contratación inteligentes, contratos sobre la marcha, que es donde creo que finalmente necesitamos llegar.
Retrocediendo de esa idea, puede imaginar que algún contrato quiere depender de otro contrato que se ejecuta en una cadena remota. Esos contratos están escritos en idiomas heterogéneos. Pero eso está bien porque a nivel de tipo, en particular, tipos de estilo de comportamiento, no te importa en qué idioma está escrito. Todo lo que te importa es que satisfaga ciertas propiedades con respecto a la secuencia de IO.
cristiano: ¿Tienes que compilar en Rholang primero para determinar el tipo?
Greg: Lo bueno es que dejas que la semántica de la cadena remota proporcione eso. Al final del día, confías en su algoritmo de consenso; confías en un montón de cosas. Debe confiar en la certificación de cambio de que ese contrato inteligente satisface un tipo particular. Luego vas y te aseguras de que la forma en que llega a esa certificación es un cálculo que respetas. ¿Tiene sentido?
cristiano: Está realizando consultas en otras cadenas que utilizan otros idiomas y devolvieron las que han determinado que encajan …
Greg: … esa especificación. Eso es exactamente correcto.
cristiano: Si aún no les proporciona su sistema, ¿cómo lo determinan?
Greg: Todo lo que tienen que hacer es tener el mecanismo de verificación de tipo entre un tipo de lenguaje de propiedad acordado y los idiomas que expresan sus términos. Eso se puede hacer mediante una compilación de un sublenguaje común o se puede hacer de varias otras maneras.
Su propuesta es una implementación particular y estoy tratando de ser más abstracto. Estoy tratando de decir: "si lo implementaron en Rust, no nos importa siempre que tengan una verificación de tipo" o "lo implementaron en Go, no nos importa mientras tengan un tipo verifique ”. Entonces depende de la comunidad decir si se respeta o no ese algoritmo de verificación de tipo en particular. Esa parte ha sido examinada.
Isaac: Casi parece un poco implícito porque está utilizando los datos de esta cadena. Tienes que confiar en todos los aspectos que intervienen en él.
Greg: Cuando habla de interoperabilidad de cadenas, especialmente si habla de interoperabilidad de cadenas de contratos inteligentes, ya está allí.
Felicitaciones a Polkadot por reconocer que los datos son el rey. Si observa su literatura, una de las cosas que realmente se destaca es cuánto de su análisis de mercado coincide con nuestro análisis de mercado. Los datos son el rey y esto importará enormemente si queremos tener la adopción de la cadena de bloques.
Todos los principales jugadores están esperando ver una aplicación que no sea el intercambio de tokens en la parte superior de la cadena de bloques. Si la cadena de bloques continúa optimizándose solo para mover el token, se está configurando para un ciclo de retroalimentación que será muy difícil de escapar. Cuanto más se optimice para eso, más difícil será ser una red de transferencia de datos. Incluso si tiene el mayor protocolo de interoperabilidad del mundo, si las únicas cosas que están interoperando son las que han sido optimizadas para mover tokens, no hay datos en esa red.
Debe sembrar tal cosa con una solución de datos que sea lo suficientemente escalable y rápida. Ahí es donde aterrizó RChain. Debe tener al menos una cadena que maneje los datos, y también maneje los fragmentos, y luego extienda la solución de fragmentos a una solución de interoperabilidad. Se siente de una manera más natural porque entonces está garantizado que al menos una de esas cosas es proporcionar una ruta de escape del token a los datos.
Eso es principalmente lo que quería decir. Hay otras cadenas de las que podríamos hablar. Podemos hablar de Algorand, podemos hablar de Holochain, pero se aplican muchas críticas. Es el mismo tipo de críticas. Lo que realmente exigimos (y creo que todos tienen que exigir) es que tengamos un nivel de verificabilidad con respecto al funcionamiento de la cadena. Ese es solo el nuevo estándar. No sé cómo decirlo de otra manera.
Podemos pensar en las últimas dos décadas de Internet como una exploración de todas aquellas aplicaciones en las que si fallaras, estaría bien. Si Google Maps no le sirve el mapa correcto la primera vez, está bien. Si Facebook no empuja a los memes del gato, eso está bien. Si Spotify no entrega la canción correcta la primera vez, está bien. Nadie va a morir
Estamos llegando al final de esos mercados en cierto sentido. Principalmente porque nos estamos quedando sin tiempo con respecto a cómo abordar el cambio climático, pero ese es un tema aparte. Ahora estamos en un punto en el que debemos considerar las aplicaciones de misión crítica y debemos considerar las aplicaciones de estilo de Internet como aplicaciones de misión crítica. La sociedad no está retrocediendo a un momento en que no tiene internet, o al menos no quiere.
Tenemos que pensar en esta próxima ola de aplicaciones a la luz de las cosas al estilo Six Sigma. ¿Su software es tan bueno que si fuera un sistema de control de tráfico aéreo, pondría a su hija en ese avión? Si esa es su medida, si esa es su barra, entonces debe tener un nivel de verificación formal.
Lo primero es que debe poder abordar las pruebas. Es por eso que realmente busco razonamiento equitativo. Tan pronto como las pruebas se vuelven complicadas con una gran cantidad de inglés, es un estilo matemático más antiguo. El estilo moderno de las matemáticas está mucho más orientado de una manera que podemos automatizarlo con probadores de teoremas y verificadores de modelos.
Para eso es lo que está manejando y debería comenzar a ver. Eso es lo que he estado tratando de argumentar en muchas de estas conversaciones: mira la especificación de Rholang. Podría ir a codificar esto y en nuestro probador de teoremas favorito, pero solo quiero que veas el razonamiento equitativo. Míralo. Es entendible por la gente común. Esa debería ser la primera señal. Comienzas a tener estas especificaciones encantadoras que son limpias y hermosas. Inmediatamente después, tenemos demostradores de teoremas que verifican nuestro trabajo. En ese punto, podemos comenzar a hablar sobre aplicaciones de misión crítica.
Isaac: Ese siempre ha sido el sorteo del proyecto RChain. Ustedes están hablando de razonamiento equitativo y de corrección por construcción y composicionalidad. Eso es lo que siento que todos estos proyectos necesitan.
Greg: Estoy absolutamente de acuerdo. Es algo gracioso porque es un punto ciego. Ayer estuve hablando con alguien, señalando que las personas no deberían sentirse mal o avergonzadas o incluso que es extraño que no tengamos mucho razonamiento compositivo en muchas fórmulas destacadas. Ha sido un punto ciego en la cognición humana. Pensar de esa manera requiere un giro particular de la mente.
He hecho este punto una y otra vez, pero creo que vale la pena repetirlo. La mecánica cuántica, al menos como se formuló inicialmente, no era compositiva. Relatividad general: no compositiva. Eso tiene consecuencias realmente grandes para esas teorías. La razón por la que uso esos ejemplos es que son el pináculo del logro científico en términos de precisión y poder predictivo.
En muchos sentidos, son nuestro estándar de oro y les falta esta característica. Si piensa en ellos como bases de código, les falta esta característica. Es una nueva forma de pensar para pensar compositivamente, pero es la única forma de llegar a escala.
cristiano: Con algunas de las grandes cadenas, cada uno de estos sistemas tendrá su propia cadena. Va a ser menos común que hagan todo lo posible para formar algún tipo de subcadena en otro sistema. Cuando hablas de dentro de RChain tener estos fragmentos de Ethereum y otros lugares, ¿hay alguna manera de que …
Greg: Creo que entiendo tu pregunta. Hay ciertas cosas sobre las que necesitamos tener claridad. Número uno, puede hacer que RChain monte Ethereum, por lo que un fragmento RChain trata a Ethereum como un niño. No necesitas Ethereum para hacer nada especial. Tienes un contrato de Ethereum en un lado que está respaldado por un fragmento RChain en el otro. Hay algunos recursos de Ethereum respaldados por algunos recursos de RChain. Todos los dApps de Ethereum que usan ese recurso en particular, pueden hacer un tipo particular de intercambio y viceversa. Eso supone que los recursos son efectivamente tokens ERC-20. Si quieres hacer RChain y Ether, hay un poco más de trabajo, pero eso también se puede hacer en este estilo sin muchas invasiones.
Si quieres que Ethereum monte RChain, eso es mucho más trabajo. Desde mi punto de vista, eso es genial, porque básicamente pone a RChain en el asiento de interoperabilidad de pegamento, que en última instancia es donde quieres estar. Ese tipo de paisaje está inclinado de tal manera que todo el valor sale de Ethereum y pasa a RChain.
No hay ninguna razón por la que no pueda tener múltiples redes Ethereum. Simplemente inicias una colección de nodos Ethereum y se hablan entre ellos. Ya tenemos eso. Tienes Ethereum Mainnet y tienes varias Ethereum Testnets. Es solo que las personas reconocen una de esas redes como el único Ether verdadero. Pero, de hecho, podría tener el éter rojo y el éter azul y el éter verde, y todos podrían montarse uno con respecto al otro de tal manera que el éter rojo respalde al éter azul, por ejemplo.
cristiano: ¿Una razón por la que una persona de Ethereum vendría a RChain sería que RChain comienza a desarrollar aplicaciones más serias primero?
Greg: Hay dos razones principales. Una es que comienzan a ver un rendimiento mucho mayor en RChain. El segundo es porque hay un mayor rendimiento, las personas están comenzando a crear aplicaciones allí. CryptoKitties no pone a RChain de rodillas.
Otro ejemplo es que hemos medido lo que se necesita para crear aplicaciones que se toman en serio los datos. El backend RCat para RSong y otras cosas permite que las aplicaciones que requieren muchos datos lleguen a un MVP en aproximadamente seis u ocho semanas con dos ingenieros. Se trata del tipo de gasto de recursos que la mayoría de los proyectos gastan en escribir su documento técnico. Pero en lugar de escribir un documento técnico, en realidad podrían producir código en ejecución, lo que demuestra el punto de vista. Creemos que solo podría ser una de las cosas que revitaliza el espacio RChain.
Muchos desarrolladores han dejado el espacio en general porque el dinero se ha agotado. Ya no es una mentalidad de fiebre del oro. Es un enfoque diferente, un tipo diferente de espacio ahora. Si desea involucrar más dApps, debe mostrarles que hay oportunidades para que puedan escribir aplicaciones que satisfagan los mercados que demandan cosas.
