transactions – Role of ABI-Encoding in Digital Signatures and Contract Invocation

abibytecodecontract-invocationsignaturetransactions

I have two questions regarding the ABI.

1. When does it happen?

A digital signature is made by creating a transaction data structure, RLP-encoded serializing the data, hashing it through keccak-256, and signing it with ECDSA using a private key. At which point does ABI-encoding happen?

2. What does it encode?

Does ABI-encoding only happen for the contract method invoking data or also for things like the value, nonce, etc? If latter, does that mean the transaction parameters get RLP-encoded AND ABI-encoded?

Best Answer

The ABI or the Application Binary Interface is the standard to interact with the contracts. EVM uses the ABI encoded data to understand which part of the bytecode to execute.

When does it happen? A contract interaction is just another transaction on ethereum. The payload/what-to-do is in the data field of the transaction. ABI encoding encodes the user's parameters and function signature. Then you put this in the data field of the transaction. And then you sign the transaction as proof of ownership. Then the whole transaction data is RLP encoded.

What does it encode? ABI encoding is used only in contract interactions. It is used to compute the keccak256 hash of the target function selector and then the arguments you want to supply. The process returns raw bytes which are then put into the data field of the transaction.

The whole flow :

Sender :

Decide which function to execute at a contract address
ABI encode function selector and arguments
Put the ABI encoder's output raw bytes in the data field of transaction
Put all the other values, to, value and nonce
RLP encode these fields
Sign the transaction
Again RLP encode it and send

After travelling through some wires...

Receiver/Node :

RLP decode the received transaction
Verify if valid by checking the signature
RLP decode
Execute! (EVM internally handles the ABI decode and execution)

RLP encoding is the protocol used to communicate over channels i.e your mobile's data or Ethernet or etc.., it is the low level method used to convert data before sending through transmission. Aside from Ethereum, you can also use RLP encoding for something like Mobile communication. It's just another protocol.

Related Solutions

Transactions – Hash of the Transaction VS Transaction Hash or ID

The transaction ID calculation is correct. For the signing, the arguments are still RLP encoded (the dummy "v" for EIP-155 is a bit special, see below).

Take this live transaction as an example. It has the following parameters.

nonce = 0 [RLP: 0x80]
gasPrice = 50000000000 wei (0x0BA43B7400) [RLP: 85 0BA43B7400]
gasLimit = 21000 (0x5208) [RLP: 82 5208]
to = 0x7917bc33eea648809c285607579c9919fb864f8f [RLP: 94 7917bc33eea648809c285607579c9919fb864f8f]
value = 1050000000000000 wei (0x03BAF82D03A000) [RLP: 87 03BAF82D03A000]
data = <empty> [RLP: 80]
v = 018080 (this is a place-holder value before signing, see EIP-155)

Then the input parameters for the hash is the RLP of the concatenation:

EB80850BA43B7400825208947917bc33eea648809c285607579c9919fb864f8f8703BAF82D03A00080018080

And the hash value for the signing is:

python3
>>> from Crypto.Hash import keccak
>>> keccak_hash=keccak.new(digest_bits=256)
>>> txn=bytearray.fromhex('EB80850BA43B7400825208947917bc33eea648809c285607579c9919fb864f8f8703BAF82D03A00080018080')
>>> keccak_hash.update(bytes(txn))
<Crypto.Hash.keccak.Keccak_Hash object at 0x10fb6e2e8>
>>> print(keccak_hash.hexdigest())

which gives the result

a4060d01d4add248db470b4121616cbe5b2015daf328809000ec9a1d0954d649

For the transaction ID, do Keccak hash on the final raw transaction bytes (RLP encoded as you mentioned, which are also readable from Etherscan) and it will give the same result as shown on Etherscan.

Transaction Encoding – How to Encode Empty Transaction Fields in RLP

All of these field have to be provided and should not be nil. There are generally 2 different types when encoding a transaction with RLP: 256-bit Number and a Bytes.

So if we have an empty data we would encode it as an empty bytes (e.g. 0x). In this case an empty string and an empty bytes are the same, as a string would be converted to bytes before RLP encoding.

For the address it is a little bit more tricky. It is defined as a Bytes that has a length of 20. Unless you have a creation transaction then it is an empty bytes.

You can find an example how this is implemented in the Kethereum repositors:

You can find the more formal definition in the Ethereum Yellow Paper at the beginning of page 5.

A list of all fields that should be encoded in a Transaction can for example be found in EIP-1559 for the latest format.

Best Answer

Related Solutions

Transactions – Hash of the Transaction VS Transaction Hash or ID

Transaction Encoding – How to Encode Empty Transaction Fields in RLP

Related Topic