Why can big.Int be parsed after RLP encoding and decoding, but hexutil.big cannot be parsed?

Question

Here are the definitions of these two types:

// big.Int
type Int struct {
    neg bool // sign
    abs nat  // absolute value of the integer
}

// hexutil.Big
type Big big.Int

This is my test code:

package main

import (
    "fmt"
    "math/big"
    "reflect"

    "github.com/ethereum/go-ethereum/common/hexutil"
    "github.com/ethereum/go-ethereum/rlp"
)

type TransactionData struct {
    Value  *hexutil.Big
    Vaule2 *big.Int
}

func main() {
    OneBig := (*hexutil.Big)(big.NewInt(1))

    data := TransactionData{
        Value:  OneBig,
        Vaule2: big.NewInt(2),
    }

    encodedData, err := rlp.EncodeToBytes(data)
    if err != nil {
        fmt.Println("Failed to encode data:", err)
        return
    }

    decodedData := TransactionData{}
    err = rlp.DecodeBytes(encodedData, &decodedData)
    if err != nil {
        fmt.Println("Failed to decode data:", err)
        return
    }

    fmt.Println("equal:", reflect.DeepEqual(data, decodedData))
    fmt.Printf("expected: %+v\n", data)
    fmt.Printf("decoded: %+v\n", decodedData)

}

This is the output after executing the code:

equal: false
expected: {Value:0x1 Vaule2:+2}
decoded: {Value:0x0 Vaule2:+2}

Answer 1

When executing rlp.EncodeToBytes, the big.Int and hexutil.Big have different processing logic:

• For big.Int: it has a direct process logic, so it is encoded.
• For hexutil.Big: it doesn't have a direct process logic. Instead, it is regarded as a struct that has neg and abs fields. However, it was found that neg and abs are not exported fields. As a result, these two fields are ignored during the encoding process.

Summary:

The key point of the problem is that hexutil.Big is not treated as a big.Int that has direct processing logic, but rather as a struct with two non-exported fields that are ignored when attempting to encode them.