Comprensión de la carga útil de datos en la llamada de contrato [duplicado]

Estoy ejecutando Metacoin de ejemplo predeterminado de truffle:

import "ConvertLib.sol";

contract MetaCoin {
  mapping (address => uint) balances;

  function MetaCoin() {
    balances[tx.origin] = 10000;
  }

  function sendCoin(address receiver, uint amount) returns(bool sufficient) {
    if (balances[msg.sender] < amount) return false;
    balances[msg.sender] -= amount;
    balances[receiver] += amount;
    return true;
  }

  function getBalanceInEth(address addr) returns(uint){
    return ConvertLib.convert(getBalance(addr),2);
  }

  function getBalance(address addr) returns(uint) {
    return balances[addr];
  }
}

Cuando ejecuto la aplicación y envío algunas monedas, genera la siguiente carga útil:

{
    "jsonrpc": "2.0",
    "method": "eth_sendTransaction",
    "params": [{
        "from":"0x86b737b44e4b04d92ff7ee7b5604cc755e2c1124",
        "to":"0xea1ab86f57e0faccca14510d883cc660d5453995",
        "data":"0x90b98a11000000000000000000000000914e95d7b57c1899f0a77fb1f08a9ae02b01258200000000000000000000000000000000000000000000000000000000000000ff"
    }],
    "id":38
}

Envié 255 Meta a la dirección 0x914e95d7b57c1899f0a77fb1f08a9ae02b012582 llamando sendCoin(). Luego estaba tratando de entender la carga útil de datos, desglosándola:

?? 0x90b98a11000000000000000000000000

address to (20 Bytes) -> 914e95d7b57c1899f0a77fb1f08a9ae02b012582

uint value (32 Bytes) -> 00000000000000000000000000000000000000000000000000000000000000ff

Supongo que la primera parte (16 bytes) de la carga útil de datos identificará el sendCoinmétodo dentro del contrato implementado.

  1. ¿Si es así, cómo?
  2. ¿Estos 32 bytes solo identifican el nombre del método o se pueden desglosar aún más?

Respuestas (1)

Es posible que desee consultar la especificación ABI , que especifica cómo se codifican los argumentos de llamada y retorno.

" 0xcdcd77c0: el ID del método. Esto se deriva como los primeros 4 bytes del hash Keccak de la forma ASCII de la firma baz(uint32,bool)". ¡Bonito! Pero, ¿qué pasa con los 12 bytes restantes que contienen todos ceros?
@HenriqueBarcelos Los 0 son los 0 iniciales del segundo argumento, la dirección a la que enviar las monedas.
Eso es lo que pensé, pero ¿por qué sucede esto? Parece que desperdiciamos datos...
@HenriqueBarcelos El tamaño de palabra de EVM es de 32 bytes (256 bits) ethereum.stackexchange.com/q/2327/42 y es la unidad natural de datos: en.wikipedia.org/wiki/Word_(computer_architecture)
Parece falta de un mejor protocolo de serialización en este caso.