Transmisión semanal en vivo, 2 de septiembre de 2022 - Seguridad

Invitado:Esta semana, tenemos un invitado muy especial: Robert. Estamos muy contentos de trabajar con Robert y estamos muy emocionados de tenerlo aquí, ya que es uno de los principales auditores de Move y experto en seguridad a nivel mundial. Ha auditado muchos proyectos y protocolos básicos. Sobre Roberto, sabemos que hace monólogos en su tiempo libre, así que tal vez podamos ver ese lado de él también. Mejor hagamos que Robert se presente y nos cuente un poco de su trayectoria.

Roberto:¡Gracias por recibirnos! No tengo ningún chiste preparado en este momento, pero tal vez pensaré en algunos a medida que avanzamos. Ayudo a administrar OtterSec, una firma de auditoría de contratos inteligentes. Nos fijamos mucho en las partes internas de Move y tratamos de tener una comprensión profunda tanto de la capa de VM como de la capa SDK específica de Aptos. Con eso, tratamos de poder garantizar ciertos aspectos de seguridad. En el pasado, hemos trabajado en estrecha colaboración con grandes instituciones como Alameda Research, Jump Crypto, y también tenemos acuerdos con Pontem Foundation para auditar su código central. Estoy emocionado de estar en este espacio para hablar más sobre lo que hace que Move sea un lenguaje tan emocionante y también cómo estamos trabajando con Pontem para proteger sus aplicaciones porque tiene un buen enfoque en la seguridad.      

Invitado Excelente. Cuéntame, ¿qué te emociona de Move? ¿En qué se diferencia y en qué se parece? ¿Cuáles son algunos cambios de paradigma que ve, especialmente en el área de seguridad?

Roberto: Vamos a publicar una publicación de blog sobre este mismo tema probablemente en unos días. Move como lenguaje es muy emocionante, y es una de las principales ventas para mudarse a Aptos. Yo llamaría Move a Rust para blockchain; es más específico del dominio, lo que significa que puede evitar muchos de los problemas generales que tiene Rust. Por ejemplo, no necesita serializar o deserializar manualmente los datos cuando usa Move. Es un lenguaje de nivel mucho más alto que brinda a los desarrolladores más herramientas para poder escribir programas más seguros.  

¿Qui puedo ser técnico? Creo que un aspecto específico genial de Move es que la máquina virtual es extremadamente [versátil]. Un ejemplo de esto es que las referencias están disponibles de forma nativa, como si fueran un valor de primera clase en Move VM. Entonces en realidad podría en el bi-código, empujar la referencia en la pila y también puede eliminar la referencia de una referencia directamente. Una implicación de esto es que cuando desea llamar a una función, pasa directamente una referencia. En general, Move es un lenguaje de alto nivel mucho más específico de dominio, específico de blockchain, que creo que resuelve muchos problemas de seguridad que vemos en la programación normal.

‍Invitado: Desarrollemos un poco más, ¿qué significa ser un valor de primera clase? ¿Cuál es la analogía?

Roberto:Buena pregunta. Entonces, primera clase solo significa que es compatible de forma nativa con la máquina virtual. Por el contrario, al deserializar datos con Rust, por ejemplo, debe poder tener algún tipo de representación intermedia para ese valor, o algún tipo de representación para convertir los bytes subyacentes en lo que usa su programa. Debe tener este paso intermedio en el que convierte el binario sin procesar en un valor de Rust utilizable. Por otro lado, Move simplemente ignora el paso por completo si puede usar el valor directamente.

Invitado: ¿ETH es nativo? ¿El token Compound o UNI es un valor de primera clase? ¿Cómo se compara eso con Ethereum?

Roberto:Para ETH, tendría un contrato, y luego necesitaría tener un back-end para cargar los valores, por lo que en realidad no tiene acceso de primera clase a la estructura de nivel superior en sí. Realmente no puede pasar una referencia a un token. Tendrías que llamar al contrato para recibir el valor. Todavía queda ese paso intermedio, pero es un poco diferente porque todos los estados de los contratos se almacenan dentro de los propios contratos.  

Invitado:Entonces, ¿tengo que llamar a un contrato como un contrato ERC-20?

Roberto:Sí.

Invitado:¿Es más eficiente también? Además de la seguridad, ¿ahorro en gas?

Roberto:Bueno, supongo que esa parte está algo separada de los ahorros de gas. Creo que Move, como lenguaje, está diseñado para ser muy rápido. Es escalable, por lo que el costo para los usuarios también debería ser menor. Aunque el gas es como un concepto nativo de VM, el gas Move se expresa en unidades completamente diferentes a las del gas ETH o Solana.

Invitado:Hagamos esta comparación un poco más teorico. ¿Qué pasaría si los pusiéramos uno al lado del otro en algo como Cosmos o Polkadot, cuál funcionaría mejor? ¿El Move o el EVM? ¿Qué aspectos deberíamos estar explorando?

Roberto:En teoría, podría escribir estos contratos en cualquier idioma. Creo que el punto principal para mí es que Move es más seguro por defecto. Le permite escribir contratos más seguros sin esforzarse tanto o sin prestar tanta atención.

Invitado:Entonces, ¿lo que estás diciendo es que es mucho más difícil pegarme un tiro en el pie, esencialmente?

Roberto: Idealmente, sí. Sé que a Pontem le importa mucho la seguridad, pero para ser honesto, creo que hay muchos desarrolladores de contratos inteligentes a los que no les importa mucho la seguridad o que no entienden todas las implicaciones. Simplemente escriben código que implementan en la red principal lo más rápido posible, y eso a menudo termina disparándose en el pie.

Invitado:Entonces, ¿cómo pueden las personas, especialmente los usuarios finales, realmente asegurarse de que no se vean afectados por los equipos y desarrolladores que hacen cosas como esa? ¿Cuáles son las mejores prácticas que existen para los proyectos? ¿Qué deben tener en cuenta nuestros usuarios para asegurarse de que estén seguros en el metaverso?

Roberto:El usuarios debe mantenerse alerta con los diferentes proyectos, pero es importante asegurarse de que aquellos con los que interactúa sean realmente confiables y seguros y hayan pasado por el proceso de trabajar con una firma de auditoría profesional y hacer que se audite su contrato. Creo que esa es probablemente la mejor manera de mitigar el riesgo de vulnerabilidades de seguridad. Por supuesto, las auditorías no son perfectas, por lo que siempre existe la posibilidad de que se les escape algo, pero la posición general o la postura del equipo con respecto a la seguridad es realmente importante. Tener un equipo que se preocupa por la seguridad me da mucha más confianza en su protocolo que un equipo que realmente quiere que lleves tus cosas a producción.

Supongo que una cosa que debe tener en cuenta es la confirmación en el repositorio de Github frente a la confirmación en el informe de auditoría. Si es diferente, tal vez debería hacer algunas preguntas más sobre si hay un compromiso continuo con el equipo, o si sabe que el protocolo solo está enviando cosas a producción o a Github sin consultar realmente sobre esos cambios adicionales.

Invitado:¿Hay alguna manera de que nosotros, como protocolo, podamos hacer eso sin confianza? ¿Hay alguna certificación que pueda hacer como auditor para decir que la versión que está activa ahora mismo en Github es la que auditó? ¿Podría estar potencialmente en una billetera o en algún lugar donde podamos ver certificaciones o señales?

Roberto:En todos los informes de auditoría, y pronto produciremos algunos para Pontem, pero en todos nuestros informes de auditoría tenemos el hash de confirmación, que usted sabe que sellamos nosotros, que revisamos. Pero la integración de la cartera es una buena idea, y estamos hablando de un par de carteras. Sería genial si de forma nativa en la aplicación de billetera, hubiera una manera para que los usuarios vieran que este código en la cadena es en realidad el mismo que fue aprobado por un auditor. Y eso podría hacerse, por ejemplo, simplemente comparando el hash del código en la cadena.

Entonces, idealmente, podría tener algún tipo de opción incluso, donde si los usuarios quieren pasar al modo de confianza total, solo interactúan con contratos que han sido completamente verificados. De esta manera, también sabrá si el contrato ha cambiado debajo de usted.

Invitado:Esa es una muy buena idea. Definitivamente vamos a descubrir cómo convertir eso en una función y agregarla a la hoja de ruta. Este también es un buen giro hacia la seguridad de la billetera. Dado que la billetera es la interfaz en el metaverso, cuénteme más: ¿qué debemos tener en cuenta con la seguridad de la billetera? Recientemente ha habido hacks. Nos ocuparemos de lo que pasó con Solana. ¿Quizás podría darnos algunas de sus opiniones allí y cómo los usuarios y los proyectos pueden protegerse a sí mismos, así como a los usuarios? ¿Qué opinas sobre la billetera como interfaz o deshacerse del navegador como intermediario?

Roberto:Hay muchas preguntas para desarrollar aquí. El primero es la seguridad. Personalmente, creo que la seguridad de la billetera ha pasado desapercibida durante mucho tiempo. La gente se preocupa mucho. Ven mucho que estas dApps se han visto comprometidas potencialmente, pero antes de este evento de Solana, a nadie realmente le importaba si las billeteras habían sido auditadas. Lo cual, si lo piensas bien, no tiene mucho sentido, porque las billeteras son esencialmente tu puente hacia todo este mundo de las criptomonedas. Si ese puente centralizado se ve comprometido, entonces todo con lo que interactúa también podría verse comprometido. Es como un único punto de falla para todo con lo que interactúas.

Sobre Solana, en realidad estamos trabajando con los equipos involucrados. Hemos contratado a la Fundación Solana, por lo que estamos trabajando con ellos tratando de averiguar qué sucedió realmente. Publicamos un informe sobre nuestros hallazgos que puede encontrar en nuestra cuenta de Twitter. Creo que el resumen fue que hubo mnemónicos o claves secretas que se registraron accidentalmente. Sospechamos que eso podría haber llevado al compromiso de las claves de usuario. Creo que la conclusión de esos eventos específicamente es que debe tener mucho cuidado al manejar datos confidenciales de los usuarios. Debe asegurarse de que esos datos no terminen en algún lugar accidentalmente.

En realidad fue un accidente, no estaban tratando intencionalmente de hacerlo. Simplemente se almacenó accidentalmente en un objeto que terminó siendo enviado al servidor. Había varias capas de abstracción que realmente no se tomaron el tiempo de descifrar o no notaron hasta que fue demasiado tarde.    

Invitado:¿Es algo que podría haber quedado atrapado en un informe de auditoría?

Roberto:Sí, pero creo que tendrías que estar buscándolo específicamente. Creo que los desarrolladores deben tener mucho cuidado cuando hacen este tipo de cosas. O necesita tener una empresa externa que se centre específicamente en lo que debe buscar, o debe pasar mucho tiempo buscando este tipo de casos extremos en los que los datos confidenciales de los usuarios pueden transmitirse de maneras que no es su intención.
Hay muchas billeteras que no les importa mucho la seguridad. De hecho, hemos encontrado e informado problemas a varias billeteras fuera de Phantom. Si bien es un poco preocupante, también hemos visto que algunas de las billeteras con las que trabajamos en el pasado han mejorado su postura.

Invitado:Este punto central de falla es bastante aterrador. Piense la cantidad de personas que usan Metamask sobre otras billeteras en Ethereum. ¿Cómo resolvemos este problema? ¿Existe tal cosa como una billetera descentralizada?

Roberto:Creo que la solución sería, como usuarios, impulsar un mayor enfoque en la seguridad. Solo trabaje con billeteras que tengan un socio de seguridad fuerte. Haga preguntas sobre lo que ha hecho la billetera para garantizar su seguridad. Potencialmente, podría tener una billetera descentralizada, pero no estoy muy seguro de cómo funcionaría. Una consideración es que el código de la billetera debe estar algo centralizado. No estoy muy seguro de que realmente pueda tener una base de código de billetera descentralizada. Quiero decir, tal vez podría tener múltiples interfaces o algo así, pero siempre habrá un punto único o puntos únicos de falla para el usuario.

Invitado:Entonces, ¿cree que las billeteras deberían ser auditadas y tan públicas con sus informes como las dApps de contratos inteligentes?

Roberto:Creo que las billeteras son tan importantes, si no más, que las dApps en términos de seguridad. Los usuarios deben estar seguros de que la billetera que están usando no firmará accidentalmente una transacción que no quieren firmar y muestra correctamente todas las transacciones. Hubo una investigación interesante que alguien más hizo sobre si podías averiguar, como un contrato, que estabas en una simulación, como una llamada de simulación de RPC, y cambias tu comportamiento en base a eso. En realidad no deberías estar interactuando con contratos en los que no confías, pero también es una pregunta interesante: ¿realmente puede confiar en lo que sucede en el nivel de simulación? Aunque no sé si eso es una vulnerabilidad de billetera, per se. Yo diría que es más una preocupación de diseño de VM. Creo que las billeteras definitivamente deben preocuparse mucho por la seguridad y los usuarios deben presionar por la seguridad de las billeteras que usan. Al final del día, la necesidad de seguridad tiene que venir de los usuarios. Si a los usuarios no les importa la seguridad, a las billeteras tampoco les va a importar. Pero si los usuarios exigen seguridad, entonces las billeteras tendrán el incentivo de auditar su código.

Invitado: Tengo una idea ¿Qué pasa si las personas simplemente descargan y ejecutan la billetera ellos mismos? No está enviando ninguna información a ninguna parte. ¿Podría eso potencialmente funcionar? ¿O tal vez no necesitar confiar en ningún tercero para enviarle cosas? Esto es parte de la ética de Web2 frente a Web3, ¿verdad? Al igual que Web2, desea realizar un seguimiento de todo. Desea ver dónde hace clic el usuario. Todos estos registros pueden ser útiles para mejorar el producto, pero también es un arma de doble filo, ¿no?

Roberto:Sí, creo que incluso en Web2 hay una gran preocupación por la carga de datos confidenciales. Aunque el problema en Web2 es que no es una pérdida directa. Incluso si roba un montón de nombres de usuario y contraseñas, no tiene acceso directo al dinero en comparación con Web3. Si tiene la clave privada de la billetera de alguien, puede agotar sus fondos de inmediato. Por eso creo que Web3 da mucho más miedo.

Invitado:Sí, eso tiene sentido. Esta es una muy buena retroalimentación. Honestamente, con todos los sitios web, probablemente no deberíamos registrar nada, correos electrónicos o conocer direcciones IP ni nada. No deberíamos enviarlos a ningún servidor de AWS aunque sé que es útil. Podemos hablar de eso: ¿cómo haces lo más simple que recopila la menor cantidad de información posible para que ni siquiera haya una fuga porque no estás recopilando nada?

Roberto:Creo que también es una buena idea para los usuarios. Idealmente para los usuarios, no desea que ningún proveedor externo rastree sus datos. Por lo tanto, minimizar eso también ha tenido el efecto secundario positivo no deseado de minimizar este problema más amplio del seguimiento corporativo de los usuarios.

Invitado:Incluso hay preocupaciones aquí más allá de la filtración de su información personal. También existe potencialmente MEV, valor extraíble máximo. Esta centralización, o punto central de falla, significa que estas billeteras tienen mucha información que podría ser muy valiosa para los comerciantes que podrían estar tratando de ganar algo de dinero en función de las transacciones que está realizando. La gente probablemente esté familiarizada con el comercio de alta frecuencia, es Web2, es finanzas tradicionales, el mismo problema de lo que la gente llama "ejecución frontal", o "ejecución trasera", o "ataques sándwich", o cualquiera de las otras formas de MEV. Quería escuchar sus pensamientos sobre esto también.

Roberto:Sí, definitivamente creo que si tienes alguna información, potencialmente eso podría

permitir que alguien explote eso. Aunque, al menos desde mi experiencia, parece que la mayoría de las ganancias están mirando el mempool o observan lo que ha estado sucediendo en la cadena e intentan usar eso para obtener ganancias.

Invitado:¿Las billeteras no actúan como un transmisor de esta información? Quiero escuchar sus pensamientos porque parece que no son un guardián per se, pero las transacciones pasan por ellos y pueden elegir qué validadores las recogen.

Roberto:Sí, creo que el flujo de órdenes de pago para billeteras es definitivamente bastante interesante. No sé si alguna billetera puede hacer eso en este momento, pero no lo he investigado demasiado, por lo que es posible. Mis pensamientos iniciales son que siento que los validadores probablemente no serían los que hacen MEV. Probablemente serían búsquedas externas. Entonces, si la billetera hiciera eso, se conectaría a algún mercado o algo donde podría transmitir las transacciones como flashspots. Tampoco creo que las billeteras deberían estar haciendo esto para ser honesto. Viola la confianza entre ellos y los usuarios.

Invitado:Creo que el argumento es que alguien lo va a hacer porque sabe que está fluyendo por ahí. ¿Por qué no hacer que sea transparente? Supongo que ese es el argumento a favor de los flashpots. Esto está sucediendo, así que pongámoslo en cadena y permitamos que un mercado eficiente evolucione a su alrededor. Así que tal vez permitamos este tipo de MEV y no este tipo de MEV. Es el Salvaje Oeste ahí fuera. ¿Cómo creamos un salón seguro en el que, si te van a ganar, al menos te paguen por ello? Debido a que alguien lo va a hacer, ¿por qué no dejar que los vaqueros que tienen en mente tus mejores intereses te dejen hacerlo?

Roberto:Eso es justo. Supongo que tampoco estoy seguro de qué es más importante, el flujo de pedidos o el pedido en el bloque. Creo que ambos son importantes, pero creo que la mayoría de las recompensas terminarían yendo a los mismos validadores porque controlan el flujo de pedidos, porque reciben todas las transacciones, pero también los pedidos. Controlan qué bloque se produce realmente. Creo que los validadores querrían que no jugaran con eso.  

Invitado:El problema es que si todo el mundo usa Metamask y Metamask, de forma predeterminada, lo envía todo a los mismos validadores, eso parece un conflicto de intereses. Tal vez haya una manera de reconocer a quién envía las transacciones, pero eso también podría hacer que su transacción transcurra mucho más lentamente.

Roberto:Solo creo que la óptica del flujo de órdenes de pago, hay un gran lío en Reddit por eso. Simplemente creo que no es una gran cosa para hacer. Creo que es un poco arriesgado en términos de cómo los usuarios lo perciben.

Invitado:Veo dos opciones: cobra algún tipo de tarifa para que las personas paguen por adelantado los servidores de AWS. O la gente no ve la tarifa, pero está pagando un diferencial, llamémoslo. De cualquier manera, solo necesita ser transparente sobre cuáles son los costos y luego dejar que los usuarios decidan.

Roberto:Creo que mientras los usuarios entiendan y conozcan los aspectos de lo que realmente está sucediendo, entonces creo que está totalmente bien. Solo necesita ser comunicado adecuadamente a los usuarios.

Invitado:Enfriar. Cambiemos de marcha aquí. Tenemos muchas preguntas que nos han llegado. No sé si vamos a tener tiempo para todas ellas. Dejemos que alguien se levante para hablar.

Jeff - Ponente:Me encanta este tema sobre la seguridad, especialmente para una nueva plataforma porque mi experiencia es en educación, que luego cambié al espacio Web3. Dirijo cohortes y capacito a desarrolladores y una de las cosas de las que hablamos desde el primer día es cada forma diferente en que puede crear contratos e infraestructura seguros. La mejor respuesta a esta pregunta es, por supuesto, desea esas auditorías y verificaciones, pero debe enseñar a los desarrolladores desde el primer día una forma bastante estandarizada de probar todo en el camino. Por mucho que queramos tener ese momento importante de envío, debe encontrar ese buen equilibrio de envío rápido pero también asegurarse de que está enviando un buen código que sea seguro para los usuarios. Porque un paso en falso o como decías hace unos minutos, sabes que alguien accidentalmente hace algo en el código y es No te pillo, estás hablando de miles de millones de dólares. Así que creo que comienza desde el principio con la forma en que entrenas a las personas para que tengan una mentalidad de seguridad, tanto como una mentalidad de barco.

Invitado:Ese es un muy buen punto en el que pienso todos los días, porque viniendo de un fondo tecnológico tradicional, el espíritu es moverse rápido y romper cosas y luego aprender de esos errores y mejorar el proceso. Pero aquí si rompes cosas, no es bueno. Entonces, he tenido que lidiar mucho con esto y me encantaría escuchar tus pensamientos, Robert, y también los tuyos, Jeff.

Jeff - Ponente:Estoy con Web3 Builders Alliance y actualmente estamos en Cosmos. Estamos llegando a las redes Move y al lenguaje de contratación inteligente basado en Rust. Ofrecemos una cohorte de nivel de maestría, no para principiantes, para personas que quieren ser desarrolladores senior.

Invitado:De hecho, probaremos Move VM en Cosmos en el futuro. Bifurcamos la VM de Libra, la hicimos compatible con Wassum y jugamos con el SDK de Cosmos. También tenemos un Parachain Polkadot. Obviamente, estamos felices de tenerlo aquí en Aptos, pero también estaremos llegando a Cosmos pronto. Pero sobre este tema de moverse rápido y romper cosas rápidamente, en realidad del ecosistema Kusama/Polkadot, aprendí que en realidad puedes probar, siempre y cuando les digas a todos que todo el mundo va a ser caótico. Me gusta esta idea de tener quizás dos versiones de aplicaciones. Una versión es inmutable, inalterable, confía en que nadie tiene ningún tipo de acceso multifirma a ella. Nadie puede cambiarlo. Puede haber cosas mal con él, con suerte no porque haya pasado por auditorías, y esa es su versión lista para producción. Pero, ¿qué pasa con una bifurcación de eso que se puede actualizar donde puede enviar cosas rápido? Puede decirles a todos: "Oye, es posible que esto no esté completamente auditado, lo estamos probando". Nos permitiría movernos rápidamente, probar cosas, experimentar, romper cosas, romper no solo el código, sino incluso la teoría del juego detrás de algunas de las suposiciones que tenemos. Tan un poco curioso de escuchar sus pensamientos sobre eso.

Roberto:Ese es un diseño interesante. Mi principal preocupación sería, ¿cómo saben los usuarios cuál usar? Creo que el problema es que los usuarios realmente no saben cómo evaluar estos riesgos. Incluso con contratos inteligentes, es muy difícil saber cuál es la probabilidad de ser pirateado. Ni siquiera lo sabemos realmente. Creo que, en este caso, si tiene dos versiones de la misma aplicación, y una es más segura y la otra no es tan segura, supongo que los usuarios que estén dispuestos a asumir más riesgos podrían usar la que se envía constantemente. Pero creo que, de manera realista, si alguno de ellos fuera pirateado, aún sería una especie de crisis de relaciones públicas con la que lidiar.

Invitado:En ese sentido, es más un posicionamiento, ya sabes, "esta-cosa-será-hackeada.com" frente a "esta-cosa-no-va-a-ser-hackeada-(con suerte).com". Simplemente coloque descargos de responsabilidad rojos gigantes en todas partes que digan que use bajo su propio riesgo, no ponga más dinero del que está dispuesto a perder, etc.  

‍Jeff:La red de prueba incentivada también es un buen modelo. Si incentiva a las personas a participar en su testnet y a dar su opinión, y las recompensa con tokens útiles, está alimentando la base de usuarios. Todavía beneficia a los proyectos porque incluso si quieren gamificar usando la red de prueba para obtener más tokens, al menos la están usando y todos están ganando. Estás recibiendo comentarios y ellos están usando la red de prueba. Su objetivo es romper cosas. Ganan más tokens en la red de prueba incentivada al intentar romper tus cosas. Alimentas las necesidades emocionales de los usuarios. Mire, cuanto más rojo ponga en una pantalla que diga "No use esto", más degens totales entrarán y lo usarán. Es mejor simplemente decir "Ven y úsalo y rómpelo y te daremos algunas fichas".

Invitado:E incluso puedes poner recompensas en el otro, como, Oye, si lo rompes, está esta apuesta, ¿verdad?

Jeff:Totalmente. Lo que pasa con la palabra "recompensas", aunque, quiero decir, psicológicamente, ya sabes, digo la palabra "recompensa". Me pregunto cuántas personas en esta llamada piensan, bueno, tienes que ser un desarrollador para hacer eso. No necesariamente desea que solo los desarrolladores entren e intenten romper sus cosas, sino que también quiere que los usuarios regulares usen sus cosas al azar y traten de romperlas desde el punto de vista del usuario, no desde un punto de vista técnico.

Invitado:De la forma en que pienso sobre la arquitectura de esta red de prueba incentivada, hay dos formas de crear una red separada. Podrías hacer girar tus propios nodos. Creo que el problema es que si no hay valor fluyendo a través de él, no hay protección contra correo no deseado. Es por eso que me gusta la idea de simplemente enviarlo a algún lugar donde haya un valor real, como la idea de Kusama. Tengo curiosidad por escuchar sobre esa red de prueba incentivada, pero tal vez en producción o en vivo.

Jeff:Hay un par de versiones diferentes de cómo se ve esto. Y mira, no hay valor real porque son tokens de testnet. La forma en que crea valor es si hay una entrada de alguien que envía comentarios o "Rompí sus cosas", la salida es:

Invitado:La diferencia es que si lo lancé en la red principal de Aptos, digamos, en lugar de en una red de desarrollo, entonces las personas en la red de desarrollo de Aptos no pueden enviar spam porque necesitan tokens de Aptos para enviar transacciones. Entonces, digamos que un ataque DDoS en su red de desarrollo es algo inevitable. La gente simplemente solicita tokens del faucet o necesita hacer KYC/AML, o algo así, que es muy oneroso y podría tener implicaciones de privacidad. Entonces, ¿cómo lanzamos esto en un entorno real donde existe la protección contra correo no deseado? Potencialmente, aquí es donde creo que necesitas algún tipo de valor del mundo real, para que estas cosas cobren vida por sí mismas. Creo que necesita ser en vivo, en la naturaleza. No puede guardarlo en el laboratorio, de lo contrario, no está realmente probando todas las cosas que podrían romperse y usted ' no se está beneficiando de la protección contra spam de estar en vivo. Lo siento, interrumpí.

Jeff:¡No, estás totalmente bien! Para mí, una gran pregunta conduce a la innovación. No he pensado en lo que voy a decir, pero quiero decir, quizás juegues con algún tipo de ficha inventada. Sé que es una blasfemia total, pero con solo usarlo, estás ganando puntos que luego pueden canjearse por valor real. Entonces, por ejemplo, lanzó esto en la red principal y puede obtener fondos de grifo, pero es limitado, no puede obtener mil millones de ellos. Entras y juegas, y ganas puntos por jugar y una vez que alcanzas un cierto umbral, obtienes un premio que puedes canjear por valor real en algún momento. Ahora bien, esto no atraerá a sus degens DeFi, porque no quieren jugar, pero atraerá a suficientes personas que sí quieren jugar para obtener algunos comentarios que de otro modo no tendrían. Es un problema que podría funcionar.

Roberto:Creo que la preocupación podría existir si eso fuera viable. Si tiene un token que tiene valor en el mundo real con solo usarlo, es posible falsificar ese uso de alguna manera.

Invitado:Creo que solo quieres evitar que los bots envíen spam a cualquier mecanismo que tengas. La protección contra spam es el valor del mundo real. Te cuesta dinero. Así que creo que esta idea de que las fichas tienen valor en el mundo real es obviamente más filosófica. Digamos que formamos un clon de bitcoin y lo acabamos de lanzar al mundo. ¿Cuál es el valor del mundo real allí? Si alguien puede atacarlo con spam, entonces probablemente no tenga valor en el mundo real. Pero si alguien necesita tokens de Aptos para atacarlo con spam, entonces sabe que al menos está comenzando a vincularlo con algún valor del mundo real. Digamos que soy un bot, gasté $ 1,000 en gasolina para obtener estas monedas, y ahora esto vale $ 1,000. Nuevamente, lanzas esto al mundo y ves qué sucede, pruébalo. Creo que necesitas conectarlo a recompensas por errores y vulnerabilidades.

Roberto:Creo que otra preocupación central es que muchos errores son casos extremos, por lo que es muy difícil encontrarlos a menos que estés leyendo el código intencionalmente. A veces, es posible que ni siquiera sea posible encontrarlos a través de la interfaz de usuario. A veces, puede ser que la interfaz de usuario sea segura de usar, pero si modifica un poco la interfaz de usuario o realiza sus propias llamadas de contrato personalizadas, puede explotar.

Invitado:Supongo que un caso de uso en el que estoy pensando es este: digamos que Aave está trabajando en una v7 y están pensando en una innovación completamente nueva que nadie ha hecho nunca en el mundo. Pueden obtener 10 millones de auditorías, pero lo necesitan en el mundo para que alguien descubra qué sucedería si hago este préstamo con este token y luego lo traigo desde este otro puente. Tal vez ocurra alguna extraña teoría de juegos o un ataque económico que ni siquiera está en el código. ¿Cómo prueban eso sin que sea en vivo en un entorno real? Solo estoy pensando, si van a publicar una versión y tratar de empujarla a la gente, tal vez haya una manera de permitir que la gente la pruebe en vivo, en producción, sin que sea realmente la versión de producción. ¿Hay alguna manera de hacer esto de manera segura?

Roberto:Sí, tal vez para el diseño económico o los modelos de incentivos tendría más sentido.

Invitado:O incluso los expertos, ¿verdad? Te invitaría a ti, Robert, y a todos los demás que creen que pueden piratearlo porque, al final del día, si lo haces, debería haber una recompensa o una recompensa de hacker de sombrero blanco. Y ese puede ser el valor tangible del mundo real que se le atribuye. Es como, OK, si lo rompes, está este precio. Creo que Jeff estaba diciendo eso. Pienso que es una buena idea.

Roberto:Sí, creo que eso también podría funcionar. Hay una variedad de formas diferentes de incentivar a las comunidades a mirar contratos o diseños.

Invitado:Bueno, llegamos a la hora, así que si necesitas irte Robert, siéntete libre. Me quedo un poco más y tú también eres bienvenido. Jeff, eres bienvenido a quedarte también. Mencionemos a otro invitado, Rashid.

Sus preguntas fueron un poco difíciles de escuchar, pero creo que tal vez la primera fue: ¿hay alguna vulnerabilidad del mundo real que haya sido detectada y luego cómo es este proceso?

Todo eso aparecerá en los informes, y si hay problemas trabajaremos en estrecha colaboración con Robert para solucionarlos en tiempo real. Si hay vulnerabilidades, esta es exactamente la razón por la que trabajamos con alguien como Robert para que nos ayude a encontrarlas y solucionarlas. Publicamos un informe público que cualquiera puede salir y leer, para que se sienta seguro al usar los productos. Es parte del proceso de lanzamiento de estas cosas, especialmente en un ecosistema completamente nuevo. Tienes que ser muy cuidadoso. También estamos siendo redundantes con los auditores, por lo que estamos teniendo múltiples auditorías. Lo siento Robert, espero que no sea una trampa. Pero probablemente estaría de acuerdo en que es bueno que tengamos redundancia.

Cuando lancemos, estaremos listos desde el primer día gracias a que Robert nos ayudó a realizar estas auditorías. También haremos muchas pruebas de penetración en la billetera, como comentamos, eso será muy importante. Muy pronto podrá usar estos productos en la red principal cuando Aptos esté disponible. Todo está en vivo en el devnet en este momento. Visite liquidswap.com y pruébelo.

Tengo un poco de curiosidad por escuchar tus pensamientos, Robert, sobre cómo la comunidad puede vincularse con la seguridad.

Roberto:Creo que la retención de usuarios es una de las cosas más complicadas. Pienso mucho en las dApps, pero especialmente en las billeteras, básicamente monetizas las páginas de destino de los usuarios. Es por eso que Metamask puede cobrar tarifas relativamente altas y ganar mucho dinero de esa manera. Creo que por seguridad, no trabajamos directamente con la comunidad, pero creo que trabajamos con protocolos que se preocupan mucho por su comunidad y tratamos de ser lo más activos posible en la comunidad, por eso estamos en esto. Espacio de Twitter, por ejemplo. Es bueno escuchar los comentarios de los protocolos, pero también de los usuarios y tratar de entender cómo nosotros, como firma de auditoría, podemos responder mejor a los usuarios. Porque al final, todos servimos a los usuarios y estamos tratando de hacer todo lo posible para que este lugar sea mejor para todos.

Invitado:Sí. Y si nos sentimos seguros, creo que la gente querrá quedarse. Esa es probablemente la prioridad número uno, ¿verdad? Solo para que la gente se sienta segura.

Roberto:Exactamente, creo que últimamente ha habido mucha atención negativa en cripto con todos los problemas de seguridad. Pero sí, una cosa que nos importa es asegurarnos de que, con suerte, los protocolos con los que trabajamos nunca tengan que lidiar con ellos. Ese es el objetivo.

He terminado, ha sido todo muy divertido, esto es todo por mi parte. Es genial charlar sobre seguridad con todo el mundo. Gracias por invitarme

Invitado:Gracias por venir y te esperamos de nuevo pronto. También traeremos más invitados, y muchas gracias a todos por hacer preguntas. Nos vemos la próxima semana.