¿En qué se diferencia la excepción de ether de un contrato inteligente a la de una dirección normal?

Estamos implementando un pago de ethereum para nuestros clientes y necesitamos decidir entre depósitos a un contrato inteligente o direcciones de clientes individuales. ¿Cuáles son los pros y los contras? ¿Es posible ocultar el saldo de nuestro contrato inteligente si lo usamos para todos los pagos? ¿Por qué algunos intercambios no aceptan pagos de contratos inteligentes? ¿Se debe a que falta información de seguimiento del cliente?

Respuestas (1)

Es diferente, pero solo un poco más complicado. Las transacciones de EOA (cuentas de propiedad externa, por ejemplo, la clave privada firma una transacción) tienen un destino y una cantidad. El intercambio o servicio puede monitorear el mempool y ver que la transacción es a su dirección y hacerle saber "hey, vemos su transacción, estamos esperando que se extraiga y x confirmaciones para confirmarla".

Sin embargo, las transacciones de los contratos son diferentes. Las transacciones de los contratos ni siquiera son transacciones, son "llamadas de mensajes". Dado que todas las transacciones de los contratos se inician desde las cuentas EOA, las llamadas de mensajes de los contratos no se muestran en el mempool y ni siquiera se incluyen en los bloques, solo la transacción inicial que provocó la transacción del contrato está en el bloque. Así es como funcionarían en la práctica los pagos de los contratos:

  1. Envío un tx a mi contrato Multisig diciendo "envía 1 ETH a esta dirección"

  2. El Multisig, en la misma transacción, envía una llamada de mensaje a la dirección que le dije con la cantidad de ETH que le dije que enviara.

Dado que la transacción que hace que el ETH vaya al servicio no es realmente al servicio, es al Multisig, el servicio/intercambio no puede simplemente monitorear las transacciones a su dirección. Tendrían que ejecutar cada transacción que ven y ver si se envía a su dirección. Además, es posible que el resultado de las transacciones cambie en un bloque futuro. Digamos que mi Multisig dice "si el número de bloque actual es impar, nunca envíe el ETH", pero el intercambio probó la transacción en un bloque par, estarían equivocados al obtener el ETH si se extrajo en un bloque impar.

Al final del día, el servicio/intercambio puede hacer ping para detectar cambios en el saldo de sus billeteras en lugar de tratar de escuchar las transacciones en su dirección, pero muchos simplemente no quieren hacer esto.

gracias, ¿podría proporcionar información más detallada sobre cómo identificar qué pago provino de qué cliente? Si solo controlo los cambios en el saldo de mi cuenta, ¿cómo procedo para averiguar qué sucedió?
Hay un par de formas. La forma común para los intercambios es tener direcciones separadas para cada usuario, y solo generan una nueva para cada usuario. Entonces saben quién está enviando al servicio. Otra opción es que su dirección de recepción sea un contrato que requiera que se pase algún tipo de identificador a la función de pago que es único por persona.
Gracias, eso es lo que descubrí hasta ahora. En el caso de un contrato inteligente, ¿cuáles son los problemas cuando envían desde otro contrato inteligente? ¿Es probable que la billetera del usuario no admita agregar el identificador a los datos de la transacción o en caso de que envíen desde otro intercambio?
Si tuviera que ir con el identificador en su método de contrato inteligente, entonces sí, las personas no podrían enviar directamente desde un intercambio ya que el intercambio no tendrá idea de ese identificador. Si desea una interoperabilidad total, tendrá que hacer 1 dirección por usuario y procesar transferencias tanto de EOA como de contratos.
entonces, en el caso de direcciones individuales, necesitaría mover fondos a una cuenta acumulativa porque, a diferencia de Bitcoin, no es práctico tratar con todas esas cuentas. ¿Hay una mejor práctica para esto?
¿En qué se diferencia la excepción de ether de un contrato inteligente a la de una dirección normal?
RespuestasAquíPolítica de privacidad1y, 0v