Verständnis der Datennutzlast beim Vertragsanruf [Duplikat]

Ich verwende Truffles Standard-Beispiel-Metacoin:

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];
  }
}

Wenn ich die Anwendung ausführe und einige Münzen sende, generiert sie die folgende Nutzlast:

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

Ich habe 255 Meta an die Adresse 0x914e95d7b57c1899f0a77fb1f08a9ae02b012582 gesendet und angerufen sendCoin(). Dann habe ich versucht, die Datennutzlast zu verstehen, indem ich sie aufgeschlüsselt habe:

?? 0x90b98a11000000000000000000000000

address to (20 Bytes) -> 914e95d7b57c1899f0a77fb1f08a9ae02b012582

uint value (32 Bytes) -> 00000000000000000000000000000000000000000000000000000000000000ff

Der erste Teil (16 Byte) der Datennutzlast, von der ich annehme, identifiziert die sendCoinMethode innerhalb des bereitgestellten Vertrags.

  1. Wenn das so ist, wie?
  2. Identifizieren diese 32 Bytes nur den Methodennamen oder kann er noch weiter aufgeschlüsselt werden?

Antworten (1)

Vielleicht möchten Sie sich die ABI-Spezifikation ansehen , die angibt, wie Aufruf- und Rückgabeargumente codiert werden.

" 0xcdcd77c0: die Methoden-ID. Diese wird als die ersten 4 Bytes des Keccak-Hashes der ASCII-Form der Signatur abgeleitet baz(uint32,bool)." Nett! Aber was ist mit den restlichen 12 Bytes, die nur Nullen enthalten?
@HenriqueBarcelos Die Nullen sind die führenden Nullen des zweiten Arguments, der Adresse, an die die Münzen gesendet werden sollen.
Das dachte ich mir, aber warum passiert das? Scheint Datenverschwendung zu sein...
@HenriqueBarcelos Die EVM-Wortgröße beträgt 32 Bytes (256 Bit) ethereum.stackexchange.com/q/2327/42 und ist die natürliche Dateneinheit: en.wikipedia.org/wiki/Word_(computer_architecture)
Scheint in diesem Fall ein besseres Serialisierungsprotokoll zu fehlen.