Contratos inteligentes: ¿dónde está el contrato?

Soy nuevo en los contratos inteligentes. Cuando vi algún ejemplo de Smart Contracts, me di cuenta de que son solo una pieza de código, no exactamente contratos.

Por ejemplo function sendCoin(address receiver, uint amount), hay un método definido en un contrato inteligente que toma la dirección del receptor y la cantidad para enviar monedas al receptor.

Pero el contrato no se trata de cómo enviar monedas, sino de cuánto enviar. Por ejemplo, si el material se entrega a tiempo, realice el pago total; de lo contrario, cobrará una multa del 10 % por cada semana de retraso.

Según tengo entendido, la invocación, donde se escriben estas reglas si-entonces (contrato que representa), está fuera del contrato inteligente.

¿Es correcto mi entendimiento? ¿Es engañoso el término 'contrato inteligente'?

¿Los contratos reales todavía están codificados fuera de la cadena de bloques en la aplicación que activa estas funciones? En caso afirmativo, ¿por qué los contratos inteligentes no se pueden manipular? Las aplicaciones aún pueden comprometer el contrato, por ejemplo. al no pagar según los términos del contrato.

¿Qué es lo que puede hacer una pieza de papel firmada que no puede hacer una pieza de software firmada? y ¿qué es lo que puede hacer una pieza de software firmada que no puede hacer una hoja de papel firmada?
@siid: estoy de acuerdo parcialmente ya que la invocación del contrato está fuera a través de alguna API como web3 más o menos. Aunque el fragmento de código no se ve comprometido, su parámetro de entrada puede verse comprometido, si no son parte de ethereum y se definen de antemano en el momento de la redacción del contrato. Puede ser que reformule mi pregunta: "¿Las reglas de invocación de contratos inteligentes (reglas If-Then) también son parte de ethereum o pueden formar parte de ethereum?"

Respuestas (2)

Creo que la palabra contrato viene de la programación del contrato . Es una forma de diseñar software que cumple con los requisitos de este paradigma. De hecho, Solidity admite la programación por contrato de forma nativa.

pragma solidity ^0.4.0;

contract Sharer {
    function sendHalf(address addr) public payable returns (uint balance) {
        require(msg.value % 2 == 0); // Only allow even numbers
        uint balanceBeforeTransfer = this.balance;
        addr.transfer(msg.value / 2);
        // Since transfer throws an exception on failure and
        // cannot call back here, there should be no way for us to
        // still have half of the money.
        assert(this.balance == balanceBeforeTransfer - msg.value / 2);
        return this.balance;
    } 
}

Dado este ejemplo, como puede ver requires, son las condiciones previas y las condiciones assetsposteriores. Los efectos secundarios son excepciones que revertirán el estado en el EVM.

ingrese la descripción de la imagen aquí

Gracias por la explicación. Pero, ¿cómo se activa el código? Según tengo entendido, alguien usará web3 o una API similar para invocar el código con alguna 'dirección' y 'valor'. Seguramente solo se transferirá la mitad del valor, según la implementación. Pero técnicamente, determinar el valor exacto de 'valor' también debería ser parte del contrato. Me gusta Enviar la mitad de 10 a 'mirg', si responde la pregunta. Pero con la configuración actual. uno puede manipular el valor de 'valor' e indirectamente comprometer el contrato.
entonces la palabra objeto proviene de la programación orientada a objetos o tal vez lo contrario, oop tiene sus raíces en la forma en que los humanos perciben la realidad.
@Abhinav, ¿cómo puede alguien manipular el 'valor'? Si es así, eso es un error. No entiendo tu punto. Si su contrato tiene que enviar siempre una cantidad exacta de eth, entonces este será un valor estático. Si el contrato tiene que enviar la mitad del valor, entonces el código proporcionado es correcto dado que son condiciones previas y posteriores.
@siid No lo entiendo, tal vez uso alguna palabra incorrectamente, pero el punto es sobre la programación, no sobre la gramática.
@mirg: En general, el contrato será así: si 'la entrega se realiza a tiempo', envíe el monto total de la factura. De lo contrario, deduzca $ 10 por cada semana de retraso. En tal caso, si solo tenemos la función 'transferir' que toma el valor a transferir como parámetro, entonces el invocador puede manipularlo. (Debido a que el contrato real solo tiene la función de transferir el monto en lugar de la lógica para determinar cuánto transferir) En tales casos, se sugiere escribir la función de modo que tome la fecha como entrada y luego procese el pago en lugar del valor a ser transferido?
La mayoría de los ejemplos que vi muestran funciones que son técnicas como 'transferir (dirección, monto)' sin términos de contrato y estos términos de contrato están codificados en una aplicación externa que calcula la cantidad que se transferirá y luego invoca estas funciones (por ejemplo, . transferir)
Depende del tipo de contrato y del objetivo del escritor. Si uno solo quiere crear una forma de transferir valor, entonces solo necesitará dar forma a la función para las transferencias. Los términos del contrato se pueden incluir en el contrato si se desea. Eso no significa que no encontrará estafadores tratando de engañarlo. Es por eso que el código fuente abierto y un lenguaje formal que tiene una sola interpretación lógica son más convenientes que...
@Abhinav si su negocio debe cumplir con ciertos requisitos, nadie lo detiene para almacenar la información en la cadena de bloques. p.ej. almacena la información de su producto, el precio, etc. Cuando compra un determinado artículo, solo hace referencia a su código y el contrato almacenará el precio y se lo enviará al comprador. Generalmente, la función de transferencia que siempre ves en los contratos, es del estándar de token ERC20 o de algunas billeteras, que tienen que cumplir con algunas especificaciones.

Su comprensión es exactamente correcta. Los contratos inteligentes no son ni inteligentes ni contratos. Es una palabra engañosa.

Es solo un software que se ejecuta en el EVM. No hay nada que haga cumplir lo que hacen, aparte del hecho de que el código en sí nunca se puede cambiar.

Creo que es la inmutabilidad del código y el hecho de que el código es de código abierto (y, por lo tanto, aceptado por todas las partes) lo que hace que la gente los considere contratos. No puede cambiarlos una vez implementados.

Entonces, ¿qué es un contrato?
Pienso en el contrato inteligente como solo lo que se ejecuta en el EVM. Es decir, la parte que se ejecuta en "Ethereum". Creo que la gente lo llama contrato solo porque ambas partes están de acuerdo (porque ambos pueden leer el código fuente) y no se puede cambiar (porque el código que se ejecuta en el EVM es inmutable). No hay ningún contrato legal en absoluto. "Contrato" es solo una palabra mal elegida.
@ThomasJayRush: ¡Gracias! Pero para mí, el código es solo metadatos (a menos que no dependa de ninguna variable externa), como lo que hará. Lo real sucede, cuando se invoca, cuando se pasa el parámetro real. Esta forma de permitir la invocación de contratos inteligentes desde web3 u otras API parece poco contraria a los contratos que ya están bien definidos en el momento de escribir este artículo.
si el contrato es firmado por una autoridad se convierte en un contrato legal. Incluso si un contrato no tiene que ser firmado por un tercero cuando la cadena de bloques asegura su inmutabilidad y confiabilidad
Contratos inteligentes: ¿dónde está el contrato?
RespuestasAquíPolítica de privacidad1y, 0v