¿Por qué otorgamos acceso a nuestros fondos en lugar de simplemente enviarlos al contrato inteligente?

En DeFi, he visto que se solicita a los usuarios que den acceso a sus fondos. ¿Por qué no simplemente enviar esos fondos al contrato inteligente?

¿Cuál es la ventaja de este diseño?

Creo que es por razones de seguridad. stackoverflow.com/questions/67384106/…

Respuestas (2)

No hay "ventaja". La razón por la que la mayoría de las aplicaciones DeFi piden a los usuarios que "permitan" la transferencia de sus fondos es que esos fondos se representan como tokens ERC-20 . La comunidad de Ethereum se enfrenta a una instancia del clásico problema de dependencia de ruta .

Aquí hay una guía que profundiza en las asignaciones ERC-20. Y aquí hay algunas soluciones prácticas:

  • Permiso ERC-20 : agrega una función de "permiso" al estándar ERC-20.
  • ERC-777 : un nuevo estándar de token por completo. Esto no tiene mucha tracción hasta donde yo sé.
En la guía que ha publicado en su respuesta dice: ¿ "Because the Ethereum blockchain allows transactions with smart contracts and those smart contracts can be facilitated by 3rd parties – like a DEX or Protocol Relayer – permissions have to be granted to the 3rd party by token owners before those smart contracts can execute."Cómo es un dex un tercero si el contrato inteligente es el dex?
Es posible que una aplicación frontend de DeFi integre un protocolo que no construyeron ellos mismos. Por ejemplo, 1inch.io , que es un agregador de DEXes. Pero sí, cuando el creador de la interfaz DeFI es el mismo que el creador de DEX, no hay un tercero.
Si mi respuesta lo ayudó, ¿podría presionar el botón de voto positivo o potencialmente marcar la respuesta como aceptada?
Ahora veo cómo entran en juego los terceros. Gracias. Entonces, si no hay un tercero, ¿necesita el 'método de asignación'? Además, en su respuesta, ha dicho ¿ The reason most DeFi apps ask users to "allow" the transfer of their funds is that those funds are represented as ERC-20 tokens.Qué quiere decir con esto? Si no fueran tokens ERC 20, ¿no habría necesidad de la funcionalidad 'permitir'? También ha hablado sobre la dependencia de la ruta. ¿Significa esto que el método allow actualmente no es necesario?
Si no hay un tercero pero los tokens son ERC-20, aún necesita asignaciones. Los contratos inteligentes simbólicos serían los mismos.
Si no fueran tokens ERC-20, entonces sí, potencialmente no habría necesidad de que los usuarios aprobaran los tokens antes de transferirlos. Lea acerca de ERC20Permity ERC-777.
Con respecto a la dependencia de la ruta: lo que quise decir es que ERC-20 es un estándar antiguo. Se remonta a 2016. Mientras tanto, muchas cosas mejoraron en Ethereum. Si tuviéramos que diseñar un token estándar desde cero, hoy lo haríamos bastante diferente.

En general, hay dos formas de transferir tokens (ERC20):

  1. Transferencia directa con transfer. Puede llamar a esta función para transferir sus tokens directamente a otra dirección.

  2. Transferencia indirecta con approvey transferFrom. De esta manera, realiza dos transacciones diferentes: primero, da su aprobación para que el receptor retire sus tokens. Luego llama a alguna funcionalidad en el receptor, y eso se ejecuta transferFromy toma sus tokens.

Creo que hay dos ventajas de usar el método indirecto:

  1. Funcionalidad. Si usa una transferencia directa, el receptor no tiene idea de que ha recibido tokens. De todos modos, necesitaría una segunda transacción para decirle al receptor que "hey, le envié tokens, ahora haga su parte del trato", y también sufriría en seguridad. Además, con las aprobaciones, si confía en el receptor, puede simplemente aprobar todos sus tokens y realizar múltiples transacciones con la misma aprobación, por lo que solo una aprobación y varias "segunda" transacción.

  2. Seguridad. Es más difícil engañar a los usuarios para que envíen tokens al lugar equivocado si se requieren dos transacciones separadas. Además, de esta manera puede leer de antemano el código de contrato del receptor y ver qué sucede cuando realiza la segunda transacción. Con la transferencia directa, simplemente tendría que esperar que el receptor haga lo que prometió hacer.

Primero: ¿Por qué no simplemente tener una función que se paga a la que los usuarios llaman y ejecuta el código necesario? Segundo: ¿Mi primer punto no significaría que aún puede, por adelantado, leer el código de contrato del destinatario y ver qué sucede cuando realiza la segunda transacción?
La función de pago no tiene nada que ver con la transferencia de tokens; solo se usa para transferencias de Ether. Los tokens siempre se transfieren llamando a la funcionalidad del contrato de token.
Ahora entiendo. Para blockchain, todo lo que está haciendo es llamar a la función de otro contrato inteligente.
¿Por qué otorgamos acceso a nuestros fondos en lugar de simplemente enviarlos al contrato inteligente?
RespuestasAquíPolítica de privacidad1y, 0v