La primera decisión de Gavin tras su regreso: Parity ya no solo construirá infraestructura, ¡también desarrollará productos!

Durante los últimos dos años, Polkadot ha enfrentado un dilema fundamental: la tecnología de la cadena es de clase mundial, pero las aplicaciones que realmente funcionan son extremadamente limitadas.

DeFi puede funcionar, pero otros escenarios de Web3 están casi estancados. Los desarrolladores externos no han “construido aplicaciones en Polkadot” como se esperaba, y la expansión del ecosistema ha encontrado un cuello de botella.

Así que cuando Gavin regresó a Parity para liderar la dirección, una cosa se volvió más clara que nunca: si nadie construye aplicaciones Web3, entonces Parity tendrá que hacerlo primero por sí misma.

Esto no es simplemente “hacer algunos demos”. Es un cambio estratégico a nivel fundamental: pasar de “Parity se encarga de la infraestructura y las aplicaciones las hace el ecosistema” a “Parity desarrolla primero prototipos de aplicaciones que realmente puedan reemplazar a Web2, verificando personalmente el valor de la tecnología de Polkadot”.

En esta edición de la larga entrevista de “Space Monkeys”, el vicepresidente de ingeniería, Pierre, explicó por primera vez de manera sistemática:

• Por qué fracasó el modelo de constructores externos 
• Por qué es necesario volver a hacer productos 
• Por qué Polkadot Hub debe ser “primero EVM, luego PVM” 
• Por qué Gavin impulsa “una iteración cada dos semanas” 
• Por qué Polkadot está reconstruyendo toda la pila de aplicaciones de computación, almacenamiento, notificaciones e identidad descentralizadas 

Verás claramente que Parity está construyendo una “capa descentralizada que sustituye AWS + Web2”. Esto determinará si Polkadot puede volver a la vanguardia en la segunda era.

¿Por qué Parity decidió “construir aplicaciones por sí misma”?

Jay: ¡Bienvenidos a la última edición del programa “Space Monkeys”! El invitado de hoy es Pierre Aubert, vicepresidente de ingeniería de Parity. Es un placer tenerlo de vuelta; ha pasado un tiempo desde la última vez que estuvo aquí. En ese entonces, acababa de unirse a Parity. Hoy hablaremos sobre lo que ha aprendido, los cambios que ha observado y la dirección futura. ¡Bienvenido de nuevo, Pierre!

Pierre: Gracias, ¡hola a todos!

Jay: Antes trabajabas en Google, y ya estabas pensando en la forma de los sistemas de red Web3 y en el papel que podrías desempeñar en ellos. Ahora, ¿qué has aprendido?

Pierre: Ahora tengo una comprensión más clara de cómo funciona todo el sistema y algunas buenas ideas sobre lo que podemos hacer. El potencial de este sistema es enorme, hay muchas cosas que se pueden lograr, pero la implementación no es sencilla.

Actualmente, el estado de Web3 es que, aparte de DeFi (finanzas descentralizadas), el progreso en otros campos es bastante lento. Recientemente, Gav regresó a la empresa como líder y decidió que la empresa se enfocara más en la creación de productos, lo cual creo que es la dirección correcta.

Hace dos años, nuestro enfoque era que Parity construyera la infraestructura blockchain y que las aplicaciones fueran desarrolladas por terceros. Pero la realidad demostró que este plan no se desarrolló como esperábamos. Ahora, nuestra estrategia es hacerlo nosotros mismos, primero creando algunos prototipos de aplicaciones pequeñas para demostrar cómo utilizar sistemas descentralizados y probar que esta arquitectura realmente puede producir productos útiles.

Así que el primer paso es construir estas aplicaciones nosotros mismos y usarlas internamente, lo que se conoce como “dogfooding” (prueba interna). Muchas de las aplicaciones iniciales se centrarán en herramientas que usamos a diario, con el objetivo de reemplazarlas con sistemas descentralizados. Cuando estas aplicaciones estén lo suficientemente maduras internamente, se lanzarán a los usuarios. Por ejemplo, en la Web3 Summit, en realidad no usamos nuestra propia tecnología: las entradas se compraron a través de empresas tradicionales de Web2 y el pago fue en euros; el sistema de control de acceso del lugar también era de arquitectura Web2. Este es un escenario en el que podríamos intervenir, usando nuestra propia tecnología para construir un sistema más seguro y abierto.

Jay: Pero estos sistemas ya son muy eficientes y estables. ¿Cuál es el sentido de convertirlos en sistemas Web3?

Pierre: Si crees que los sistemas centralizados satisfacen tus necesidades, no hay problema. Especialmente en escenarios como la venta de entradas. Pero en el caso del control de acceso, las ventajas de la descentralización son evidentes. Por ejemplo, cuando vas a un hotel, te dan una tarjeta para abrir la puerta, pero en realidad, muchas personas en el hotel pueden copiar la tarjeta y dejar que extraños entren. En un sistema Web3, solo tú puedes “acuñar” tu propio certificado de acceso, lo que mejora enormemente la seguridad.

Así que depende del escenario de la aplicación. En algunos casos, es fácil ver por qué la descentralización es mejor. Por ejemplo, no me gustan los servicios web tradicionales: casi cada seis meses, una empresa es hackeada y mis datos se filtran, incluyendo dirección, contraseña, información bancaria, etc. La razón es simple: estos sistemas no son lo suficientemente seguros.

Y quiero que Polkadot logre “seguridad por defecto”: porque los datos me pertenecen a mí. Por ejemplo, cuando compro una entrada, no necesito decirte mi dirección. Solo tengo que proporcionar una prueba de conocimiento cero para demostrar que vivo en algún lugar, pero no sabrás mi dirección exacta. Así, incluso si tu sistema es hackeado, mi información real no se filtrará. No quiero que mis datos personales sean recolectados y filtrados por todas partes. Tal vez sea por razones de seguridad, o simplemente por privacidad. En resumen, incluso en sistemas muy maduros hoy en día, si se pueden descentralizar, serán mejores y más seguros.

¿Cómo mejora Parity la eficiencia laboral?

Jay: En los últimos dos años, han invertido mucho esfuerzo en construir sistemas descentralizados. Desde que asumiste como vicepresidente de ingeniería, ¿en qué aspectos ha mejorado Parity?

Pierre: En realidad, lo que he hecho son cosas bastante básicas de gestión, nada complicado, solo organizar el sistema de gestión. El resultado ha sido muy bueno, la productividad ha mejorado mucho. Son operaciones básicas, como establecer procesos estandarizados. A los ingenieros les gusta un entorno ordenado y con reglas claras. Cuando los procesos y responsabilidades están claros, la equidad surge naturalmente. Por ejemplo, promovemos a quienes realmente lo hacen bien; quien tiene mejor desempeño recibe un salario más alto, y este proceso es confiable y transparente. A los ingenieros les gusta esta equidad: si ganas más que yo, es porque realmente eres mejor. Esta equidad ha sido reconocida por todos, y a mí también me gusta este enfoque; creo que así es como debe funcionar una organización saludable.

Jay: Para otros que lideran equipos, incluso equipos pequeños, ¿tienes algún consejo práctico, por ejemplo, cómo evaluar empleados, decidir promociones o delegar autoridad? ¿En qué cualidades te fijas en el crecimiento de los empleados?

Pierre: Nos enfocamos más en los resultados que en el proceso. Por ejemplo, hay personas que trabajan muy duro y hacen saber a todos lo mucho que se esfuerzan, pero al final no logran resultados. Por otro lado, hay quienes trabajan de manera inteligente, tal vez solo veinte horas a la semana, pero logran resultados y generan impacto real. Eso es lo que más valoramos. En resumen: trabajar de manera inteligente es más importante que trabajar duro.

Jay: ¿Has notado algún rasgo común en los empleados que no logran resultados? Pueden estar ocupados, pero no producen. ¿Qué tienen en común?

Pierre: En la mayoría de los casos, no es un problema personal, sino de gestión. Normalmente es porque no tienen claros sus objetivos laborales, no saben exactamente qué deben hacer. Esta “falta de claridad” hace que el trabajo sea muy difícil. Especialmente en un entorno como Parity, donde todos son bastante capaces; si alguien no logra resultados, suele ser por falta de dirección.

Así que hacer que los objetivos sean claros y específicos es lo más importante. Otro punto clave es que a veces los miembros del equipo no saben a quién acudir cuando tienen un problema. Antes, Parity no lo hacía bien en este aspecto, pero ahora lo hemos mejorado: está claro quién es responsable de cada cosa. Al final, la persona responsable debe poder tomar decisiones: “¿Vamos a la izquierda o a la derecha?” Una vez que esto está claro, el equipo puede avanzar sin problemas.

Jay: Sí, lo entiendo perfectamente. Antes, a menudo había gente que eludía la responsabilidad: “Esta decisión la tiene que tomar otro, tengo que esperar a que decidan para poder seguir”. Así el trabajo se estanca.

Pierre: Exacto, la claridad en la responsabilidad es clave. Y en realidad no es complicado, muchas veces basta con escribirlo y explicarlo claramente. También hay un fenómeno negativo: algunas personas se atribuyen el mérito cuando tienen éxito, pero culpan a otros cuando fallan. Eso no es aceptable. No puedes querer el crédito por el éxito y echar la culpa a otros por el fracaso.

Así que el beneficio de la “claridad” es que la organización funciona de manera más fluida. No cambiará mucho tu trabajo diario, pero a largo plazo, toda la empresa será más eficiente.

Estrategia de Polkadot Hub: primero EVM, luego PVM

Jay: Hablemos del proyecto Polkadot Hub. ¿Consideras que ha sido un éxito o un fracaso?

Pierre: Diría que sí y no. En cuanto a la calidad del producto, es un proyecto exitoso, el resultado final es bueno.

Pero en la forma de trabajar, hay cosas que podemos mejorar. Por ejemplo: al principio del proyecto, decidimos usar la tecnología PVM porque tiene mejor rendimiento. Pero después de un año, descubrimos que la mayoría de los grandes contratos inteligentes de Ethereum no podían ejecutarse en PVM, lo cual nos sorprendió mucho. Esto era algo que deberíamos haber probado antes, pero subestimamos la complejidad del ecosistema EVM. Luego nos dimos cuenta de que teníamos que soportar EVM. Así que tuvimos que “retroportar” el soporte de EVM al sistema, lo que hizo el proyecto más complejo.

Además, subestimamos la complejidad de muchas cosas en el ecosistema Ethereum, como los marcos de pruebas (como Anvil), la asignación de Gas, etc. Así que este proceso nos dejó una lección importante: antes de empezar un proyecto, hay que escribir y pensar bien las cosas. Especialmente en proyectos complejos, no se puede actuar solo por “parece sencillo”.

Ahora, en la industria cripto, mucha gente dice: “¡No importa, solo hazlo!” Cada vez que alguien dice eso, les pido que escriban un documento. Muchas cosas que parecen simples, en la práctica no lo son, y el proyecto termina llevando mucho más tiempo y recursos de lo esperado.

En general, Hub es exitoso en rendimiento y calidad, pero en la práctica de ingeniería aún no hemos alcanzado el estado ideal, el ciclo de desarrollo fue demasiado largo.

Jay: Entiendo. ¿Participaste en la implementación del proyecto Hub? Escuché que han estado tratando de atraer a otros proyectos para que se trasladen allí.

Pierre: No soy el responsable técnico directo, pero seleccioné y formé el equipo adecuado y establecí un estándar de calidad para garantizar la estabilidad del sistema. Por ejemplo, estoy especialmente satisfecho con la migración de activos, que requirió mucho esfuerzo y se hizo de manera muy profesional. Esto demuestra que Parity ahora tiene la capacidad de realizar migraciones a gran escala sin afectar a los usuarios. Esto no es trabajo de “nivel startup”, sino de calidad de gran empresa. Tomó tiempo y recursos, pero demostramos que cuando nos comprometemos, podemos alcanzar un nivel muy alto, lo cual es una señal positiva para el futuro: si podemos mantener este nivel de calidad en proyectos futuros, la tecnología no será un problema.

Jay: El objetivo de este ecosistema es facilitar el despliegue de proyectos que ya conocen EVM o contratos inteligentes Solidity. Entonces, en la etapa inicial, ¿qué proyectos se unirán? ¿Cómo será el proceso de despliegue? ¿Será directamente en EVM o migrarán a PVM?

Pierre: Depende. Para los grandes contratos de Ethereum, en realidad no tienen incentivos para migrar a PVM. Así que primero los dejaremos desplegar en EVM, que es compatible y muy sencillo, solo hay que desplegar.

Jay: ¿Te refieres a esos protocolos DeFi “blue chip”? Básicamente están en todas las cadenas principales.

Pierre: Estos proyectos en realidad no obtendrán muchas ventajas de rendimiento de PVM, ya que su negocio no requiere mucha computación. Sus contratos inteligentes suelen ser: leer el saldo de la cuenta → ejecutar algo de lógica → escribir el resultado. Todo el proceso no requiere mucha computación, el cuello de botella está en la lectura y escritura de datos, y en este caso, el rendimiento de EVM es suficiente. La ventaja de PVM está en manejar tareas de computación intensiva; en el futuro podremos hacer en la cadena cosas que ahora deben hacerse fuera de la cadena. Ahí es donde PVM realmente puede brillar.

Jay: ¿Por ejemplo, qué cosas concretas?

Pierre: Puedes calcular ZK-SNARK en tiempo real en la cadena. De hecho, puedes hacer muchas cosas en PVM que no puedes hacer en EVM. Creo que esto es bueno para el ecosistema cripto: poner más cosas en la cadena puede reducir esas prácticas extrañas fuera de línea y la dependencia de oráculos de terceros.

En general, poner más lógica en la cadena es más beneficioso que perjudicial. Si el mundo cripto aprende de Web2, la gente siempre llenará la CPU; si das más recursos de computación, la gente encontrará la manera de usarlos.

Ahora tenemos el sistema de computación Polkadot, estamos construyendo el sistema de almacenamiento y notificaciones

Jay: Bien. Hablando de la transición a productos, Gavin mencionó en una reunión interna de Parity que su ideal es hacer una iteración de producto cada dos semanas, quiere lanzar muchos productos rápidamente y avanzar poco a poco. ¿Estos productos usarán PVM y Hub? ¿O se desplegarán en otras pilas tecnológicas?

Pierre: Depende del producto, pero la mayoría usará algún tipo de contrato inteligente.

Jay: Ah, bien. Entonces la mayoría de los productos probablemente no usarán primero la solución rollup + parachain, ¿verdad?

Pierre: Depende, es demasiado pronto para decirlo. Por ejemplo, los servicios de almacenamiento o notificaciones probablemente serán parachains independientes, pero para escenarios como control de acceso, los contratos inteligentes ya pueden hacerlo bien.

Jay: ¿Cómo va el proyecto de almacenamiento? Siento que hemos intentado varias soluciones diferentes, pero aún no tenemos una solución unificada.

Pierre: El almacenamiento es una de nuestras tareas más complejas e importantes: construir un sistema de almacenamiento descentralizado que sea útil. Solo definir el estándar de “útil” ya es complicado, así que se necesitan varias iteraciones. Hay un equipo en el ecosistema trabajando en esto, y Moonbeam también está trabajando en ello.

Jay: ¿Te refieres a cosas como DataHaven?

Pierre: Sí, por ejemplo DataHaven, y también Eiger (que está trabajando en algunos primitivos de bajo nivel). Parity internamente también está desarrollando un almacenamiento integrado en la cadena; además hay proyectos como JamDA. Ahora hay muchos equipos impulsando proyectos de almacenamiento descentralizado, cada uno con diferentes características, y probablemente necesitaremos más de una solución: necesitamos almacenamiento descentralizado barato (por ejemplo, para subir fotos, no puede ser caro), y también almacenamiento más “rápido”, que permita lecturas y escrituras frecuentes pero no necesite almacenar grandes cantidades de datos.

Así que probablemente coexistirán varias soluciones de almacenamiento, o será un software configurable en diferentes modos. Ahora la idea es usar JamDA como un almacenamiento temporal/corto plazo: los datos son temporales, por ejemplo, expiran después de 28 días.

(La ortografía de JamDA puede ser incorrecta, se agradecen correcciones)

Jay: ¿A menos que renueves activamente?

Pierre: Sí, se puede renovar. O también podemos construir un sistema descentralizado distribuido a gran escala sobre JamDA, permitiendo elegir el almacenamiento a largo plazo. Por ejemplo, si escribes un artículo académico y quieres que se conserve públicamente a largo plazo, usarías almacenamiento a largo plazo. Así que podría ser un sistema de dos etapas: “temporal + largo plazo”.

Jay: ¿Qué características tiene este sistema que IPFS no puede satisfacer?

Pierre: Por ejemplo, IPFS no garantiza la disponibilidad. Puedes subir un documento, pero no puedes garantizar que siempre estará disponible para su lectura en el futuro.

Jay: ¿Las diferentes soluciones que mencionaste estarán finalmente protegidas por la seguridad de Polkadot? Es decir, ¿funcionarán bajo el modelo de seguridad de Polkadot?

Pierre: Finalmente sí, pero al principio puede que no.

Jay: ¿Qué quieres decir?

Pierre: Por ejemplo, podemos usar primero sistemas existentes como Filecoin, añadiendo una capa encima para ver si satisface nuestras necesidades. Cuando nuestra propia solución esté madura, reemplazaremos gradualmente Filecoin u otras soluciones. Todavía no está completamente definido.

El siguiente paso es desarrollar las funciones integradas en la cadena, luego JamDA, y poco a poco integrar otras soluciones, así que aún llevará tiempo tener una solución estable.

El almacenamiento es diferente de la computación: si la computación falla, puedes volver a ejecutarla, estamos acostumbrados (por ejemplo, si el navegador falla, solo hay que actualizar); pero el almacenamiento es mucho más complejo, por ejemplo, si subes una foto cifrada a la web, esperas poder recuperarla después, no necesariamente de inmediato, pero debe haber una garantía del 100% de que puedes encontrar la copia de seguridad. Así que, en comparación con la computación, las expectativas sobre el almacenamiento son mucho más altas.

Jay: Sí. Estamos cada vez más cerca de construir esa “nube” o “servidor” descentralizado, todos los componentes se están perfeccionando poco a poco.

Pierre: Exacto, paso a paso. Verás que estamos reconstruyendo de forma descentralizada muchos servicios muy comunes en Web2, con diferentes características, pero en esencia son el mismo tipo de sistemas. Ahora tenemos el sistema de computación Polkadot y estamos construyendo el sistema de almacenamiento y notificaciones.

Jay: Mencionaste el “sistema de notificaciones”, ¿a qué te refieres exactamente?

Pierre: Bueno, por ejemplo, tienes una aplicación y cuando alguien te responde, comenta tu documento o interactúa contigo, necesitas recibir una notificación, ¿verdad? Ese es el sistema de notificaciones. Pero el problema es que, en la comunicación por Internet, normalmente ambos estamos detrás de un firewall, lo que significa que no puedo conectarme directamente contigo. La forma habitual es usar un servidor centralizado como intermediario. Este servidor nos “abre la puerta”, establece la conexión y luego podemos comunicarnos punto a punto.

Jay: Como cuando creamos una sala de chat privada.

Pierre: Sí, exacto. Ahora queremos usar una solución descentralizada para reemplazar ese servidor central, logrando la misma capacidad de comunicación. La funcionalidad del sistema es similar, pero será más compleja porque queremos algunas características adicionales, como: no depender de ninguna autoridad centralizada y no generar metadatos rastreables. Por ejemplo, cuando chateas en Signal, otros no saben de qué hablas, pero sí saben “que estoy hablando contigo”. En el sistema que queremos construir, ni siquiera se podrá probar “con quién estoy hablando”.

¡Sigue a PolkaWorld en WeChat! En el próximo artículo compartiremos más de la entrevista con Pierre.