Estructura de EOS.IO (Español)

Hoy me gustaría tomar un momento para explicar la estructura actual de una transacción EOS.IO para que los desarrolladores puedan entender mejor el modelo de concurrencia. A continuación se muestra una representación JSON de una transacción que transferirá moneda de Sam a Alicia. En este caso, la moneda, sam y alice son todos los nombres de cuenta; Sin embargo, se utilizan de diferentes maneras.

{
"RefBlockNum": "12",
"RefBlockPrefix": "2792049106",
"Vencimiento": "2015-05-15T14: 29: 01",
"Alcance": [
"Alicia",
Sam
],
"Mensajes": [
{
"Código": "moneda",
"Tipo": "transferencia",
"Destinatarios": [
Sam
"Alicia"
],
"Autorización": [
{
"Cuenta": "sam",
"Permiso": "activo"
}
],
"Datos": "a34a59dcc8000000c9251a0000000000501a00000000000008454f53000000000568656c6c6f"
}
],
"Firmas": []
}

Cuando se serializa a binario con una sola firma, esta transacción es de 160 bytes de tamaño que es ligeramente mayor que una transferencia Steem que es de unos 120 bytes o una transferencia BitShares que es de aproximadamente 94 bytes. Gran parte del tamaño extra proviene de tener que especificar explícitamente los destinatarios, la autorización y el ámbito que agregan 51 bytes al mensaje.

TaPoS - Transacciones como prueba de participación
Aquellos de ustedes familiarizados con Steem & BitShares reconocerán los primeros 3 campos de la transacción; Permanecen sin cambios. Estos campos son utilizados por TaPoS (Transacciones como Prueba de Estaca) y aseguran que esta transacción sólo se puede incluir después del bloque referenciado y antes de la expiración.

Alcance
El siguiente campo, "ámbito", es nuevo en EOS.IO y especifica el rango de datos que se pueden leer y / o escribir. Si un mensaje intenta leer o escribir datos fuera del ámbito, la transacción fallará. Las transacciones se pueden procesar en paralelo siempre y cuando no exista superposición en su alcance.

Una innovación clave del software EOS.IO es que el ámbito y el código son dos conceptos completamente independientes. Usted notará que el contrato de divisa no se hace referencia en el ámbito aunque estamos ejecutando una transferencia utilizando el código del contrato de divisas.

Mensajes
Una transacción puede tener uno o más mensajes que deben aplicarse en orden y atómicamente (todos tienen éxito o fallan todos). En este caso, hay exactamente un mensaje, así que vamos a mirar más de cerca el mensaje:

Código:
Cada mensaje debe especificar el código que va a ejecutar, en este caso el código del contrato de divisas se ejecutará, resultando en el siguiente método que se llama:

Currency :: apply_currency_transfer (datos)
tipo:
El campo tipo define el tipo de mensaje (e implícitamente el formato de los datos). Desde una perspectiva de programación orientada a objetos se puede ver el tipo como un método "nombre" en la clase "moneda". En este ejemplo el tipo es "transferencia" y por lo tanto explica el nombre del método que se llama:

$ {Namespace} :: apply _ $ {code} _ $ {type} (datos)
En caso de que el "espacio de nombres" sea el contrato de divisas; Sin embargo, este mismo método apply_currency_transfer también se puede llamar en otros espacios de nombres.

Destinatarios:
Además de llamar a currency :: apply_currency_transfer (data), también se llamará el método apply_currency_transfer (data) para cada destinatario listado. Por ejemplo, los siguientes métodos serían llamados secuencialmente en este orden:

Currency :: apply_currency_transfer (datos)
Alice :: apply_currency_transfer (datos)
Sam :: apply_currency_transfer (datos)

La cuenta de anotación :: especifica el contrato que implementa el método. Alice y sam pueden optar por no implementar este método si no tienen ninguna lógica especial para realizar cuando se ejecuta currency :: apply_currency_transfer. Sin embargo, si Sam era un intercambio, entonces Sam probablemente querría procesar depósitos y retirarse cuando alguna vez se haga una transferencia de moneda.

La persona que genera la transacción puede agregar cualquier número de destinatarios (siempre que se ejecuten lo suficientemente rápido). Además, algunos contratos pueden requerir que ciertas partes sean notificadas. En el caso de moneda, tanto el remitente como el receptor deben ser notificados. Puede ver cómo se especifica esto en el contrato de divisa.

Void apply_currency_transfer () {
Const auto & transfer = currentMessage (Transfer) ();
RequireNotice (transfer.to, transfer.from);
...
}
autorización:
Cada mensaje puede requerir autorización de una o más cuentas. En Steem y BitShares, la autorización requerida se define implícitamente en función del tipo de mensaje; Sin embargo, con EOS.IO el mensaje debe definir explícitamente la autorización que se proporciona. El sistema EOS.IO comprobará automáticamente que la transacción ha sido firmada por todas las firmas necesarias para conceder la autorización especificada.

En este caso, el mensaje indica que debe estar firmado por el nivel de permiso activo de sam. El código de moneda verificará que la autorización de sam fue proporcionada. Puede ver esta comprobación en el contrato de moneda de ejemplo.

Void apply_currency_transfer () {
Const auto & transfer = currentMessage (Transfer) ();
RequireNotice (transfer.to, transf