haskell - inteligentes - smart contract blockchain que es

¿Cuál es un tipo apropiado para contratos inteligentes?

Question

Me pregunto cuál es la mejor manera de expresar contratos inteligentes en idiomas escritos como Haskell o Idris (por lo que podría, por ejemplo, compilarlos para que se ejecuten en la red Ethereum). Mi principal preocupación es: ¿qué es un tipo que captura todo lo que un contrato podría hacer?

Solución ingenua: etio

Una solución ingenua sería definir un contrato como miembro de un tipo EthIO . Dicho tipo sería como el IO de Haskell, pero en lugar de habilitar las llamadas al sistema, incluiría las llamadas blockchain, es decir, permitiría leer y escribir en el estado de la blockchain, llamar a otros contratos, obtener datos del bloque, etc.

-- incrementer.contract

main: EthIO
main = do
   x <- SREAD 0x123456789ABCDEF
   SSTORE (x + 1) 0x123456789ABCDEF

Esto es claramente suficiente para implementar cualquier contrato, pero:

1. Sería demasiado poderoso.

2. Estaría muy acoplado a la cadena de bloques de Ethereum específicamente.

Solución conservadora: patrón de abastecimiento de eventos.

Bajo esa idea, un contrato se definiría como un pliegue sobre una lista de acciones:

type Contract action state = {
    act  : UserID -> action -> state -> state,
    init : state
}

Entonces, un programa se vería así:

incrementer.contract

main : Contract
main = {
    act _ _ state = state + 1,
    init          = 0
}

Es decir, usted define un estado inicial, un tipo de acciones y cómo ese estado cambia cuando un usuario envía una acción. Eso permitiría a uno definir cualquier contrato arbitrario que no implique enviar / recibir dinero. La mayoría de las cadenas de bloques tienen algún tipo de moneda y la mayoría de los contratos útiles involucran dinero de alguna manera, por lo que ese tipo sería demasiado restrictivo.

Solución menos conservadora: eventos + moneda

Podemos hacer que el tipo anterior sea consciente de las monedas codificando una lógica de moneda en el tipo anterior. Por lo tanto, obtendríamos algo como:

type Contract action state = {
    act        : UserID -> action -> state -> state,
    init       : state,
    deposit    : UserID -> Amount -> state -> state,
    withdrawal : UserID -> Amount -> state -> Maybe state
}

Es decir, el desarrollador del contrato tendría que definir explícitamente cómo tratar con los depósitos y retiros monetarios. Ese tipo sería suficiente para definir cualquier contrato autocontenido que pueda interactuar con la moneda del blockchain del host. Lamentablemente, tal contrato no podría interactuar con otros contratos . En la práctica, los contratos a menudo interactúan entre sí. Un intercambio, por ejemplo, necesita comunicarse con sus contratos de token intercambiados para consultar saldos y así sucesivamente.

Generalización: ¿Estado global?

Entonces, demos un paso atrás y reescribamos la solución conservadora como esto:

type Contract = {
    act  : UserID -> Action -> Map ContractID State -> State,
    init : State
}

Bajo esta definición, la función de act tendría acceso no solo al estado propio del contrato sino también al estado de cada otro contrato en la misma cadena de bloques. Dado que cada contrato puede leer el estado de cada uno, uno podría implementar fácilmente un protocolo de comunicación además de esto, y, por lo tanto, ese tipo es suficiente para implementar contratos que interactúan arbitrariamente. Además, si la moneda de la cadena de bloques se implementara como un contrato (posiblemente usando una envoltura), ese tipo también sería suficiente para lidiar con el dinero, a pesar de no tenerlo codificado en el tipo. Pero esa solución tiene 2 problemas:

1. Mirar el estado del otro contrato parece una forma muy "pirata" de habilitar la comunicación;

2. Un contrato definido de esta manera no podría interactuar con los contratos existentes que no tienen conocimiento de esa solución.

¿Ahora que?

Ahora estoy en la oscuridad. Sé que no estoy en la abstracción correcta para este problema, pero no estoy seguro de cuál sería. Parece que la raíz del problema es que no puedo captar el fenómeno de las comunicaciones entre contratos correctamente. ¿Qué tipo concreto sería más adecuado para definir contratos inteligentes arbitrarios?