Transaction Encoding: RLP vs Amino
AdityaSripal opened this issue · comments
The transactions sent into SDK app are planned to be amino-encoded rather than RLP-encoded like it is in Ethereum. This may be relevant for web3-compatibility (RPC)
This is definitely relevant for web3-compatibility... if raw transaction data isn't encoded in RLP like it is in Ethereum then existing web3 clients will be unable to submit transactions/parse data returned from the SDK without additional processing.
I suppose we need to discuss this as it's big and important decision. The SDK uses Amino as the defacto encoding protocol and I'd like to keep Ethermint as much in line as possible with the SDK in that regard. I imagined users using the ethermint client and tooling to create transactions that are Amino serialized. (I really don't want to bring in RLP if we don't have to).
However, I do realize this may cause issues with web3. @AlexeyAkhunov has a PR open to address using existing geth RPC backend code. If this gets accepted and we're able to leverage their code, we'll use RLP for transactions. If not, we'll stick with Amino and implement the RPC ourselves.
I thinks thats a good plan @alexanderbez
Building off this, we've also slightly changed the Transaction struct to make it amino-encodable. Namely, moving V, R, and S into a seperate Signature struct. Would be useful to get input on whether this change is acceptable or if it causes serious problems to RPC compatibility before deciding on this.
Can find this new transaction format in the TxData struct in types/tx.go
Decided on using Amino